Detect Email Attachment Forces Outbound SMB Authentication to Harvest NTLM Hashes in Splunk
Rather than delivering an executable payload, actors such as TA577 email a ZIP attachment containing an HTML file (or, in earlier waves, a direct .url/.search-ms file) whose sole purpose is to reference a remote UNC path (e.g. \\attacker-server\share\file). When the victim opens the attachment, Windows automatically attempts SMB authentication to the attacker-controlled server to resolve the path — leaking the user's NetNTLMv2 challenge-response hash over the wire without ever executing malicious code on the endpoint. The captured hash is then cracked offline or relayed (NTLM relay) to gain credentials or a foothold. Because no payload runs and no persistence is established, this is reconnaissance/information-gathering via a phishing lure (T1598.002 — Phishing for Information: Spearphishing Attachment) rather than a delivery mechanism for malware; the objective is purely to elicit authentication material from the target. Detection focuses on the anomaly that outbound SMB (ports 445/139) is almost never legitimate when it originates from a user-facing application (browser, archive utility, Office app, or Explorer) and targets a public, non-RFC1918 IP address, especially when that connection follows shortly after a ZIP/HTML/ISO attachment was delivered to the same mailbox.
MITRE ATT&CK
- Tactic
- Reconnaissance
SPL Detection Query
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
DestinationPort IN (445, 139)
Image IN ("*\\explorer.exe", "*\\iexplore.exe", "*\\msedge.exe", "*\\chrome.exe", "*\\firefox.exe",
"*\\WINWORD.EXE", "*\\EXCEL.EXE", "*\\POWERPNT.EXE", "*\\7zFM.exe", "*\\WinRAR.exe")
NOT (
cidrmatch("10.0.0.0/8", DestinationIp)
OR cidrmatch("172.16.0.0/12", DestinationIp)
OR cidrmatch("192.168.0.0/16", DestinationIp)
OR cidrmatch("169.254.0.0/16", DestinationIp)
OR cidrmatch("127.0.0.0/8", DestinationIp)
)
| eval SuspicionReason="OutboundSMBToPublicIPFromUserApp"
| stats count as ConnCount, values(DestinationIp) as RemoteIPs, min(_time) as FirstSeen by host, User, Image, SuspicionReason
| sort - FirstSeenSysmon Event ID 3 (network connection) detection for outbound SMB (445/139) initiated by a user-facing process to a public, non-RFC1918 destination — the core anomaly generated when an opened attachment forces the OS to authenticate to an attacker-controlled SMB server. Requires Sysmon network-connection logging enabled and CIDR-aware filtering (cidrmatch) rather than plain string matching to correctly exclude internal ranges.
Data Sources
Required Sourcetypes
False Positives & Tuning
- VPN/SD-WAN split-tunnel setups where an internal SMB share resolves via a public-routed IP
- Cloud file-share gateways presenting as public IPs to on-prem clients
- Authorized phishing-simulation platforms testing forced-auth attachment lures
- Legitimate third-party backup/sync agents reaching an external SMB-over-internet service
Other platforms for THREAT-Recon-AttachmentForcedSMBAuthNTLMHarvest
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Outbound SMB Connection Attempt to External IP from Browser Process
Expected signal: Sysmon Event ID 3 / DeviceNetworkEvents showing powershell.exe (or its child network stack) initiating a connection to 203.0.113.10 on port 445 from the test host.
- Test 2Explorer UNC Path Navigation to External Host
Expected signal: Sysmon Event ID 3 showing explorer.exe initiating an outbound connection to 203.0.113.10 on port 445; likely followed by a failed/timeout connection since no real share exists at the test IP.
- Test 3Simulated Attachment Delivery Followed by Outbound SMB Within Correlation Window
Expected signal: A synthetic JSON record simulating an EmailAttachmentInfo entry (FileType=zip) for [email protected], plus a genuine Sysmon Event ID 3 outbound connection to 203.0.113.10:445 within the same minute.
Response Playbook
Triage
- Identify the user and endpoint that made the outbound SMB connection, and pull the full process tree to confirm which application (browser, Office app, archive tool, Explorer) initiated it.
- Check the user's mailbox for a recently delivered ZIP, HTML, ISO, or IMG attachment in the 60 minutes preceding the SMB connection, and retrieve the attachment for analysis if it still exists in the mail store or quarantine.
- Extract and inspect the attachment contents (if recoverable): look for an embedded UNC path, file:// reference, or search-ms:// URI pointing at the same remote IP the SMB connection targeted.
- Determine whether the SMB connection resulted in a successful NTLM handshake (Security Event ID 4776/4624 Type 3, or Sysmon Event ID 3 completing rather than being blocked) — a completed handshake means the NTLMv2 challenge-response was sent to the attacker.
- Check whether the destination IP/domain has been seen in threat intelligence feeds associated with TA577 or generic NTLM-relay/forced-authentication infrastructure.
- Determine the privilege level of the affected account — a domain-joined workstation account leaking NTLM hashes for a privileged user is materially higher risk than a low-privilege standard user.
Containment
- Block the destination IP/domain at the firewall and proxy, and add it to DNS sinkhole/blocklist to prevent further outbound SMB attempts from other mailboxes that received the same lure.
- Force a password reset for the affected account via an out-of-band verified channel, since the captured NetNTLMv2 hash can be cracked offline or relayed to authenticate as the user.
- If outbound SMB (445/139) to the internet is not already blocked at the perimeter firewall, implement that block organization-wide — this single control prevents the entire forced-auth class of attack regardless of lure vector.
- Search all mailboxes for the same attachment hash/filename and purge/quarantine any un-opened copies before additional users trigger the same forced-authentication chain.
- If NTLM relay (rather than offline cracking) is suspected, review authentication logs on internal servers for the same time window for any successful logon using the affected account's NTLM hash from an unexpected source.
Evidence Collection
- DeviceNetworkEvents / Sysmon Event ID 3 records for the outbound SMB connection: source device, initiating process, destination IP/port, and timestamp.
- The original email and attachment (from mail store, quarantine, or EmailAttachmentInfo/EmailUrlInfo telemetry), including sender address and attachment hash.
- Security Event ID 4776 (NTLM authentication) or 4624 (logon Type 3) on the destination if it is internal, or netflow/proxy logs if the destination is external, confirming whether the NTLM handshake completed.
- WHOIS/passive DNS history for the destination IP/domain, establishing hosting provider and any prior association with phishing infrastructure.
- The full parent-child process tree on the endpoint at the time of the connection, to confirm the attachment-opening application initiated the SMB request rather than a legitimate business process.
Escalation Criteria
- !The affected account holds privileged access (domain admin, service account with broad permissions) and the NTLM handshake is confirmed to have completed.
- !Multiple users across the organization triggered outbound SMB connections to the same external IP within a short window, indicating an active, wide-scale phishing wave rather than an isolated click.
- !Evidence of NTLM relay (a successful internal authentication event using the affected account's credentials from an unexpected host) rather than simple offline hash capture.
- !The destination infrastructure correlates with known TA577 or NTLM-relay toolkit indicators in threat intelligence feeds.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
DeviceNetworkEvents/Sysmon Event ID 3 showing the outbound SMB connection from the endpoint to the external IP. - >
EmailAttachmentInfo/EmailUrlInfo entries showing the ZIP/HTML/ISO attachment delivered to the affected mailbox and its sender. - >
Security Event ID 4776/4624 on any domain controller or server the connection may have traversed, if the traffic was internally relayed. - >
The attachment file itself (recoverable from quarantine or the mail store), containing the embedded UNC/file:// reference to the attacker infrastructure. - >
Proxy/firewall egress logs showing the destination IP, port 445/139, and connection outcome (accepted vs. blocked).
Tuning Guidance
Start by validating that outbound SMB (445/139) to the internet is not already blocked at the perimeter firewall — if it is, this entire attack class is already neutralized and the detection serves only to catch policy exceptions or misconfigurations. Where outbound SMB is permitted (e.g., for legitimate cloud file-share gateways), maintain an explicit allowlist of those known-good destination IPs/CIDR ranges to suppress Pillar 1 noise. Pillar 2 (attachment-then-SMB correlation) is the higher-fidelity signal for catching an active phishing wave in progress and should be prioritized for real-time alerting; Pillar 1 alone is better suited to a lower-urgency, human-reviewed queue given its higher false-positive surface from VPN/SD-WAN configurations. Extend the FileType list in Pillar 2 as new lure formats are observed (actors have iterated from .zip to .html to .svg wrappers over time), and periodically review whether the 60-minute correlation window is wide enough for your mail-delivery-to-open latency.
Hunting Queries
Broad 30-day hunt for any outbound SMB connection to a public IP, independent of the initiating-process and attachment-correlation narrowing used in the primary detection — useful for retroactive campaign scoping once a specific forced-auth destination has been identified, and for catching lures delivered via non-email channels (USB, chat apps) that the attachment-correlation pillar cannot see.
// Hunt: All outbound SMB (445/139) connection attempts to public IPs over the last 30 days, regardless of initiating process
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemotePort in (445, 139)
| where not(ipv4_is_in_range(RemoteIP, "10.0.0.0/8")
or ipv4_is_in_range(RemoteIP, "172.16.0.0/12")
or ipv4_is_in_range(RemoteIP, "192.168.0.0/16")
or ipv4_is_in_range(RemoteIP, "169.254.0.0/16")
or ipv4_is_in_range(RemoteIP, "127.0.0.0/8"))
| summarize AttemptCount=count(), Devices=dcount(DeviceName), FirstSeen=min(Timestamp), SampleDevices=make_set(DeviceName, 10) by RemoteIP
| order by FirstSeen descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 DestinationPort IN (445, 139)
NOT (
cidrmatch("10.0.0.0/8", DestinationIp) OR cidrmatch("172.16.0.0/12", DestinationIp)
OR cidrmatch("192.168.0.0/16", DestinationIp) OR cidrmatch("169.254.0.0/16", DestinationIp)
OR cidrmatch("127.0.0.0/8", DestinationIp)
)
| stats count as AttemptCount, dc(host) as Devices, earliest(_time) as FirstSeen, values(host) as SampleDevices by DestinationIp
| sort - FirstSeenAtomic Red Team Tests
Simulates a browser process attempting to resolve a UNC-style path pointing at an external IP over port 445, replicating the network signature generated when an HTML attachment forces the OS to authenticate to attacker infrastructure.
Command
powershell.exe -Command "Test-NetConnection -ComputerName 203.0.113.10 -Port 445"Expected Telemetry
Sysmon Event ID 3 / DeviceNetworkEvents showing powershell.exe (or its child network stack) initiating a connection to 203.0.113.10 on port 445 from the test host.
Expected Detection
KQL/SPL Pillar 1 fires because the destination IP (203.0.113.10, a TEST-NET-3 documentation address) falls outside all excluded RFC1918/loopback ranges and the port matches 445, SuspicionReason=OutboundSMBToPublicIPFromUserApp. Substitute InitiatingProcessFileName filtering to include powershell.exe for this specific atomic, or run via explorer.exe UNC navigation for a closer-to-real simulation.
Uses Windows Explorer to navigate to a UNC path referencing an external IP, replicating the exact user action (opening a file/folder reference embedded in a lure attachment) that triggers automatic SMB authentication.
Command
explorer.exe \\203.0.113.10\testshareExpected Telemetry
Sysmon Event ID 3 showing explorer.exe initiating an outbound connection to 203.0.113.10 on port 445; likely followed by a failed/timeout connection since no real share exists at the test IP.
Expected Detection
KQL/SPL Pillar 1 fires with InitiatingProcessFileName=explorer.exe and SuspicionReason=OutboundSMBToPublicIPFromUserApp, matching the primary detection's process list directly.
Writes a synthetic email-attachment-delivery record for a test recipient, then immediately generates an outbound SMB connection attempt from the same account, exercising the Pillar 2 attachment-to-SMB correlation logic end to end.
Command
powershell.exe -Command "$evt = [pscustomobject]@{Timestamp=(Get-Date).ToString('o'); RecipientEmailAddress='[email protected]'; FileName='invoice_details.zip'; FileType='zip'; SenderFromAddress='[email protected]'}; $evt | ConvertTo-Json | Out-File -FilePath $env:TEMP\atomic_email_attachment.json -Encoding utf8; Test-NetConnection -ComputerName 203.0.113.10 -Port 445"Cleanup
Remove-Item -Path $env:TEMP\atomic_email_attachment.json -ErrorAction SilentlyContinueExpected Telemetry
A synthetic JSON record simulating an EmailAttachmentInfo entry (FileType=zip) for [email protected], plus a genuine Sysmon Event ID 3 outbound connection to 203.0.113.10:445 within the same minute.
Expected Detection
This atomic validates the shape and timing of data the Pillar 2 correlation query expects. In a live environment with real EmailAttachmentInfo ingestion, the join on RecipientEmailAddress within the 60-minute window would fire SuspicionReason=AttachmentDeliveryFollowedByOutboundSMB; the synthetic file here confirms the timing relationship without requiring a real mail flow.