Kratos Takedown: Dissecting the Mechanics of this M365 PhaaS
It’s encouraging to see a significant win against PhaaS operations with the takedown of Kratos. German and US authorities, alongside Indonesian police, dismantled the core infrastructure and arrested the developer. This kit was notorious for its effectiveness in stripping Microsoft 365 sessions.
Kratos wasn't just a static clone; it operated as a sophisticated Reverse Proxy (Adversary-in-the-Middle). By relaying traffic between the target and the legitimate O365 login page, it allowed attackers to steal session cookies after the user completed MFA, effectively bypassing Conditional Access policies that rely solely on MFA compliance.
We've been hunting for similar AiTM patterns. A key indicator we found was a mismatch between the DeviceId used during authentication and the subsequent resource access, or successful logins from known hosting providers rather than residential IPs.
Here is a basic KQL query for Sentinel/M365 Defender to identify potential AiTM activity, focusing on successful logins with suspicious authentication details:
SigninLogs
| where ResultType == 0
| where ConditionalAccessStatus == "success"
| where AppDisplayName contains "Office 365"
| extend RiskDetail = coalesce(RiskDetail, "None")
| summarize Count = count() by UserPrincipalName, IPAddress, RiskDetail, Location
| where Count > 5 and RiskDetail == "None"
| project-away Count
Does anyone else have specific IoCs for Kratos they are currently scrubbing from their environments? I'm curious if anyone is seeing a shift toward adversary-controlled TLS termination to evade proxy detection since the news broke?
Great share. We actually saw a spike in alerts related to legacy authentication protocols attempting to bind to modern endpoints, which is a common evasion for these kits. We've been enforcing 'Block Legacy Authentication' at the tenant level for a while now, which stops the initial entry, but the AiTM vector on modern auth is still tricky.
For those on-prem or hybrid, check your ADFS logs for unusual relying party trusts. We found a fraudulent trust added during a test run of a similar kit last year.
The terrifying part of Kratos was the ease of deployment—it lowered the barrier to entry significantly. While the takedown helps, the technique remains valid.
We pushed FIDO2 hardware keys to our admin tier immediately after seeing the first AiTM reports. It's the only reliable defense against session cookie theft currently. For standard users, we've started looking at 'Number Matching' in Microsoft Authenticator to disrupt the automated approval workflows these kits rely on.
Agreed, disrupting the infrastructure is a massive win. On the defensive side, while FIDO2 is ideal, we must still hunt for these AitM attempts in the meantime. These proxy kits often fail to fully spoof device compliance states.
You can use this KQL snippet in Sentinel to flag sign-ins where the device claims to be compliant but originates from a known hosting provider:
SigninLogs
| where DeviceDetail.isCompliant == true
| where IPAddress in (external_data(hunting_provider="HostingProviders"))
| project Time, UserPrincipalName, IPAddress, AppDisplayName
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access