W3LL PhaaS Takedown: Analyzing the Mechanics of a $20M Operation
Big win for the good guys today with the news that the FBI and Indonesian National Police have dismantled the W3LL phishing infrastructure. For those who haven't dealt with it directly, W3LL (often sold as W3LL Store or W3LL Panel) was a sophisticated Phishing-as-a-Service (PhaaS) kit that specifically targeted Microsoft 365 credentials. It wasn't just a clone page; it was an ecosystem.
The $20M fraud attempt figure is staggering, but what stands out to me is the "off-the-shelf" nature of the threat. The alleged developer's arrest is significant, but this kit has been in the wild for years. It used advanced adversary-in-the-middle (AiTM) techniques to bypass MFA by relaying session cookies in real-time.
For those hunting residuals or similar active campaigns, the W3LL kit often leaves specific artifacts in the HTML injection or the URL structure of the phishing site. If you are reviewing proxy logs, look for distinct base64 encoded parameters or specific CSS class names used to hide the 'real' Microsoft login overlay.
Here is a quick PowerShell snippet to hunt for potential W3LL-related user-agent strings or specific URL patterns often associated with these kits in your IIS or proxy logs:
# Hunting for W3LL indicators in logs (Simplified Pattern)
$logPath = "C:\inetpub\logs\LogFiles\"
$pattern = "W3LL|Microsoft_Office_365_Sign_In_Helper|x-microsoftajax"
Get-ChildItem $logPath -Recurse -Filter *.log |
Select-String -Pattern $pattern |
Select-Object Path, LineNumber, @{N="Match";E={$_.Matches.Value}} |
Export-Csv -Path "W3LL_Hunt_Results.csv" -NoTypeInformation
With the developer detained, do we expect the infrastructure to shut down immediately, or are we going to see a scramble by affiliates to deploy their own versions before the command servers go dark?
Great breakdown. We've seen W3LL variants specifically targeting execs using BEC (Business Email Compromise) combos post-phish. The AiTM capability is what made it so dangerous; standard Conditional Access policies (MFA) wouldn't catch it because the session was technically legitimate once the cookie was relayed.
We've had luck detecting the relay activity by monitoring for impossible travel scenarios immediately after a successful MFA challenge.
SigninLogs
| where ConditionalAccessStatus == "success"
| project Time, UserPrincipalName, IPAddress, Location, AppDisplayName
| evaluate geo_distance_chain(IPAddress)
| where DistanceBetween > 1000 // kilometers
If you aren't checking for logon velocity *after* MFA, you might still be vulnerable to the residual campaigns.
It's interesting that they snagged the developer. Usually, with these PhaaS ops, the creator is ghosting the moment the heat turns up, leaving the 'customers' (the actual phishers) holding the bag. The W3LL kit was known for its 'threading' feature that allowed attackers to handle multiple victims simultaneously through a reverse proxy interface.
For sysadmins, now is a good time to enforce 'Number of matching factors' policies in Entra ID. Require location or device trust alongside password/MFA. That kills the utility of stolen session cookies for these kits.
The 'off-the-shelf' aspect is the real horror story here. The barrier to entry for committing high-level fraud has dropped to zero. I analyzed a W3LL phishing page last month, and the kit auto-generated the HTML obfuscation to evade secure email gateways (SEGs).
The obfuscation usually involved heavy Base64 encoding in the inline JavaScript. If you're doing payload analysis, make sure your sandboxers are decoding Base64 strings found in the DOM before rendering the page.
The session token theft mechanism was the killer feature here, effectively turning M365 into an insecure API endpoint. Since the password and MFA happen on the proxy, the auth event looks legitimate to Microsoft. To catch this, you have to look for inconsistencies in the usage of the access token, not just the issuance.
Here is a basic query to identify high-frequency session usage which often indicates automated tooling replaying a stolen cookie:
SigninLogs
| where ResultType == 0
| summarize Count = count() by UserPrincipalName, AppId
| where Count > 50
| order by Count desc
It’s not perfect, but it flags the automation often used in these follow-on attacks.
Agreed on the session token risks. In my forensics work on these cases, the attackers often establish persistence immediately after the token theft via hidden Inbox rules. It’s a common pattern to suppress automated alert emails. During triage, checking for recently created suspicious rules is critical. This KQL query helps identify potential rule creation anomalies post-compromise:
kusto Exchange
| where Operation == "New-InboxRule"
| where SubjectOrBodyContainsWords contains "Undeliverable" or BodyContainsWords contains "invoice"
| project TimeCreated, ClientIP, UserId, Operation
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access