Exposed AI Phishing Toolkit: WebDAV Delivery and Mexican Gov Lures
Saw the Rapid7 write-up on the exposed server hosting an AI-assisted phishing toolkit. It’s wild what gets left on open buckets these days. The operators were specifically targeting Windows users in Mexico, using AI-generated lures for fake government ID lookups to deliver an infostealer via WebDAV.
What caught my eye is the sophisticated use of WebDAV for the C2/delivery channel. Since WebDAV uses port 80/443 and looks like standard HTTP traffic, it often slips past basic perimeter defenses. The toolkit contained builder notes suggesting they are actively refining prompts to evade traditional spam filters by making the text contextually perfect.
If you’re hunting for this in your environment, keep an eye out for unexpected processes reaching out to WebDAV endpoints. Typically, we see explorer.exe or Office apps spawning svchost.exe to handle the WebClient service. You can use this KQL snippet to hunt for suspicious WebDAV PROPFIND or GET requests initiated by common Office apps:
DeviceNetworkEvents
| where RemotePort in (80, 443)
| where InitiatingProcessFileName in (~"WINWORD.EXE", ~"EXCEL.EXE", ~"POWERPNT.EXE")
| where RequestUrl contains ".xml" or RequestUrl contains ".dll"
| where ActionType == "ConnectionSuccess"
| project Timestamp, DeviceName, InitiatingProcessFileName, RequestUrl, RemoteIP
Given the use of AI to generate unique, context-aware lures, do you think traditional email header analysis is dead? How is your team handling the volume of near-perfect phishing attempts?
The AI angle is terrifying because it removes the 'poor grammar' heuristic we've relied on for years. We've started integrating NLP-based analysis in our SOAR playbooks to flag tonal anomalies, but false positives are high. Regarding WebDAV, we block it at the egress firewall unless specific business units require it. It's a legacy protocol that causes more trouble than it's worth in modern environments.
Great post. We actually saw a similar spike last month. We enforce a strict GPO to disable the WebClient service on endpoints where it's not needed. You can do it via PowerShell:
Set-Service -Name WebClient -StartupType Disabled
Stop-Service -Name WebClient -Force
This breaks the attack chain for many WebDAV-based droppers because they rely on the WebClient service to handle the transport. Just make sure you verify it doesn't break any legacy in-house apps first!
The fact that they left 1,048 files on an exposed server shows how OpSec failures are still the Achilles' heel for many cybercrime groups. I downloaded the IOCs from Rapid7—the lure templates are scarily convincing. We've added the specific subject lines and sender domains to our blocklists, but I'm worried about the next iteration since they clearly have an automated pipeline for generating these.
Spot on regarding the WebClient service. As a cloud defense layer, we often block the specific User-Agent strings associated with native WebDAV clients at the proxy level. It’s a great network control if endpoint GPOs aren't an option immediately.
You can use a regex rule to catch the default Windows behavior: regex User-Agent:.*Microsoft-WebDAV-MiniRedir
This blocks the Translate: f header requests often used in these chains without breaking general web traffic.
Validating the audit trail is just as important as blocking. To ensure we meet our compliance requirements for data egress monitoring, we hunt for the specific HTTP methods associated with WebDAV usage. If you are using Sentinel or a similar SIEM, this KQL query helps identify potential WebDAV C2 activity that standard allow-lists might miss:
DeviceNetworkEvents
| where RemotePort in (80, 443)
| where HttpMethod in ("PROPFIND", "PROPPATCH", "MKCOL", "MOVE", "COPY")
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName
Solid advice on the service hardening. To catch anything slipping through or if the service is strictly required, we’ve deployed a Sigma rule to hunt for the specific process lineage used by the WebClient service when making outbound connections. This helps distinguish legitimate traffic from potential C2 callbacks.
title: WebClient Service Network Connection
status: experimental
logsource:
category: network_connection
product: windows
detection:
selection:
Image|endswith: '\svchost.exe'
CommandLine|contains: 'webclient'
condition: selection
level: low
Building on the WebClient control, we've seen actors pivot to PowerShell for delivery to bypass that restriction. It's worth enabling Script Block Logging to catch New-PSDrive or System.Net.WebClient usage.
Here is a KQL query to hunt for those attempts:
DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has_any ("New-PSDrive", "WebClient")
| where ProcessCommandLine has "http"
Has anyone observed the specific stager behavior mentioned in the write-up attempting to re-enable the service via sc.exe?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access