Simulated Initial Access: Macros, LNK and ISO in an Isolated Windows 11 Lab

Initial access is where most real intrusions begin, and it is the phase defenders understand worst because they rarely get to watch it safely. The answer is a fully isolated lab where you replay the delivery techniques attackers actually use, macros, LNK shortcuts and ISO containers, against an instrumented Windows 11 machine you own, so you can see the telemetry each one produces and write the detections that catch them. This guide from the Basilisk team is defensive by design: every payload here is a benign proof-of-execution (it pops calc or writes a marker file) and everything runs air-gapped. The point is not to build malware, it is to understand the delivery chain well enough to break it.

Why simulate initial access at all

You cannot write a good detection for a technique you have never seen fire. Vendors ship generic rules, but your environment has its own baseline of normal Office activity, its own EDR, its own logging gaps. Replaying the technique in a lab lets you answer the only questions that matter: what process tree does it create, what command line, what file writes, what network callback, and which of those your sensors actually record. This is standard red-team and purple-team practice, it maps directly to MITRE ATT&CK techniques under Initial Access (T1566 Phishing) and Execution (T1204 User Execution), and it is the fastest way to turn a vague fear into a concrete, testable rule.

Building the isolated Windows 11 lab

Stand up a Windows 11 VM in VirtualBox or Hyper-V with a single host-only adapter and no route to the internet; delivery simulations must never be able to reach a real command-and-control host. Install Sysmon with a well-tuned config (the SwiftOnSecurity or Olaf Hartong base configs are the standard starting point), enable PowerShell script block logging and module logging via Group Policy, and turn on Windows Defender in audit mode so you see what it would have blocked without it interfering with your telemetry. Snapshot the clean state before every run. A second small Linux VM on the same host-only network acts as your fake payload host and a Sysmon-to-Sigma collection point, so nothing leaves the lab.

Vector one: VBA macros

The classic office-document macro still teaches the most. Build a document whose Document_Open or Workbook_Open handler simply launches calc.exe or writes %TEMP%\marker.txt. The interesting part is not the macro, it is the telemetry: Sysmon Event ID 1 will show winword.exe spawning a child process, which is the single most reliable macro-execution signal, because Office spawning cmd, powershell or wscript is almost never legitimate. Since Microsoft now blocks macros in files marked with the internet zone by default, note how the mark-of-the-web on the downloaded file changes the behavior, which is exactly why attackers pivoted to containers, covered below.

Vector two: LNK shortcut files

A Windows shortcut can carry an arbitrary target and arguments while displaying an innocent icon, which makes it a favorite modern delivery wrapper. In the lab, craft a .lnk whose target is powershell.exe with a harmless argument that writes your marker file, and observe the process tree: explorer.exe launching powershell.exe with a suspicious command line is the detection anchor. Note the fields that distinguish a weaponized shortcut from a normal one, an oversized command-line, a target that does not match the icon, arguments containing encoded or download-like strings, and record which of them your Sysmon config captures so you can build a Sigma rule around the reliable ones.

Vector three: ISO and IMG containers

Attackers moved to ISO, IMG and VHD containers precisely because mounting one and running a file inside historically did not propagate the mark-of-the-web to the contents, sidestepping the macro and SmartScreen protections. In the lab, package a benign LNK or script inside an ISO, mount it, and watch how the execution originates from a mounted volume drive letter rather than the Downloads folder. The detections here are container-aware: a process launched from a freshly mounted ISO, or an explorer.exe child originating from a drive that appeared seconds earlier, are strong signals. Recent Windows builds propagate mark-of-the-web into containers, so also test the patched behavior and confirm your defenses assume both.

Detection engineering with Sysmon and Sigma

Turn each observed behavior into a rule. The highest-value detections from these three vectors are: Office applications (winword, excel, powerpnt) spawning a shell or scripting host; explorer.exe launching powershell/wscript with an encoded or download-style command line; and process execution whose image path is a removable or mounted-container volume. Write these as Sigma rules against Sysmon Event ID 1, then deploy them into your SIEM and re-run the simulations to confirm each fires and produces a low false-positive rate against your normal-activity baseline. A detection you have not fired in the lab is a hypothesis, not a control.

Mitigation: closing the delivery chain

Detection is half the job; the other half is making the technique fail. Enable Microsoft's Attack Surface Reduction rules, especially block all Office applications from creating child processes and block executable content from email and webmail, which neutralizes the macro vector directly. Keep macros from internet-zone files blocked by policy, and use the newer Windows behavior that propagates mark-of-the-web into mounted containers. Restrict or log .lnk and script-host execution, deploy application control (WDAC or AppLocker) so unsigned scripts and binaries from user-writable paths do not run, and confirm each mitigation in the lab by re-running the matching simulation and seeing it blocked.

Common pitfalls in a delivery lab

The recurring mistakes: giving the Windows VM any real network path, so a mistyped payload could actually reach out; testing with Defender fully enabled so it blocks the sample before you can study its telemetry (use audit mode instead); forgetting to snapshot and losing your instrumented baseline; and drawing conclusions from a single run instead of confirming the detection fires reliably across reboots and user contexts. The subtlest trap is testing only the unpatched behavior: if your Windows build is old, you will see mark-of-the-web gaps that modern endpoints no longer have, and your rules will be tuned for a threat model that has moved on.

Lab checklist

Before you call the exercise done, verify: the Windows 11 VM is host-only with no internet route; Sysmon, script-block logging and Defender audit mode are on; a clean snapshot exists; all three vectors (macro, LNK, ISO) have been run and their process trees captured; at least three Sigma rules are written, deployed and confirmed firing; ASR rules and application control have been enabled and each mitigation verified by a blocked re-run; and every payload used was benign. If a vector produced no telemetry, your instrumentation is the finding, fix it before moving on.

FAQ: Is running these simulations legal and safe?

Yes, when it is entirely inside a lab you own with benign payloads and no real command-and-control. The techniques are documented in MITRE ATT&CK and used daily by defensive teams. What crosses the line is delivering any of this to a person or system you are not authorized to test, or using a live payload that phones home. Keep it air-gapped, keep the payloads harmless, and keep written scope if you ever move this to a sanctioned engagement against a real environment.

FAQ: Do I need a real EDR to learn this?

No. Sysmon plus PowerShell logging plus Defender in audit mode gives you the core telemetry for free, and Sigma rules translate to most SIEMs and EDRs later. A commercial EDR adds richer process-lineage and memory signals, which is worth adding once you understand the fundamentals, but starting with the free stack forces you to understand exactly which event proves which behavior, and that understanding transfers to any tool.

Running it as a purple-team drill

The lab reaches its full value when you stop treating it as solo practice and run it as a purple-team drill, with someone playing attacker and someone playing defender against the same telemetry. Map each of the three vectors to its MITRE ATT&CK technique so both sides speak one language: T1566.001 for the macro-bearing attachment, T1204.002 for the user double-clicking a malicious file, and T1027 for the obfuscation the container adds. The attacker runs a vector without warning; the defender works only from the SIEM and tries to reconstruct what happened, then both compare notes against the ground truth you captured. This exercise surfaces the gaps no checklist finds: an alert that fired but nobody triaged, a process-tree field your dashboard hides, a detection that fires on the benign test but would drown in false positives at scale. Track each gap as a ticket with an owner, re-run after the fix, and you have a measurable feedback loop instead of a one-off demo. Over a few cycles this is how a team moves from reacting to alerts to actually understanding its own attack surface, which is the entire point of simulating initial access in the first place.

Practical takeaway: build the isolated Windows 11 lab, run macro, LNK and ISO delivery with benign payloads, capture the process trees, and turn each into a Sigma detection you confirm actually fires. Then enable ASR and application control and prove each vector is blocked. Do this quarterly as the platform changes, because mark-of-the-web propagation and default macro blocking keep shifting the ground. Simulated initial access is not about building better lures, it is about knowing your delivery chain so well that no real one gets past your sensors unseen.