Greatness PhaaS Evolution: Integrating Device Code Phishing for MFA Bypass
Just saw the update regarding the Greatness PhaaS toolkit adding native support for device code phishing. While we've seen this technique used by APT groups like Storm-0522 for a while, its commoditization in a commercial PhaaS kit is a concerning shift.
For those catching up, this attack vector abuses the OAuth 2.0 Device Authorization Grant flow (intended for printers and IoT). Instead of a fake login page, the victim visits a legitimate site (e.g., microsoft.com/devicelogin) and enters a code provided by the attacker. Since the user authenticates directly on the real site, AiTM proxies aren't strictly necessary to bypass MFA—the attacker simply polls the token endpoint until the user logs in.
Detection is tricky because the authentication traffic looks legitimate on the IdP side. We need to focus on the polling behavior and the resource IDs used.
KQL for Sentinel/Microsoft Defender:
AADNonInteractiveUserSignInLog
| where AppDisplayName contains "Device"
| where AuthenticationRequirement == "singleFactorAuthentication"
| summarize Count = count() by UserPrincipalName, AppId, IPAddress
| where Count > 10 // Detect aggressive polling
Blocking this requires stricter Conditional Access policies. We're currently looking at blocking the "Microsoft Azure CLI" or similar legacy clients if our users don't actually utilize them.
How are you all handling the risk of device code flows? Are you blocking legacy protocols entirely, or relying on token theft detection?
We moved to block 'Device Code Flow' entirely via Conditional Access for our user base. Most of our staff don't have a legitimate use case for logging in via IoT devices or headless Linux terminals. We configured a CA policy targeting 'All cloud apps' > 'Client apps' > 'Legacy authentication clients' and set it to 'Block'.
However, the challenge is our DevOps team who actually do use Azure CLI. We've had to segregate them into a separate security group with stricter 'Require device to be marked as compliant' controls.
From a pentester's perspective, this is becoming a favorite. The beauty of Greatness adding this is the automation of the polling interval. Previously, we had to write custom scripts to hit the token endpoint. Now, low-level actors can just spin up a kit.
The hardest part for defenders is that the user interaction happens on the real Microsoft login page. It bypasses the visual inspection checks we teach users about (checking the URL for typos). You really need to rely on analyzing the LoginHint or CorrelationID in the logs to see if it matches the user's normal geolocation or device ID.
Don't forget to check for anomalous token issuance in your SIEM. Even if MFA is satisfied, the 'Audience' claim in the token might be suspicious.
For example, if you see a sudden spike in tokens issued for graph.microsoft.com coming from an IP range associated with data centers rather than residential ISPs, it's a red flag. We use a basic Python script to pull audit logs and flag high-frequency token issuances:
import requests
# Pseudocode for audit log check
logs = requests.get('https://graph.microsoft.com/v1.0/auditLogs/signIns')
for login in logs.()['value']:
if login['appDisplayName'] == 'Microsoft Azure CLI' and login['riskDetail'] == 'none':
print(f"Investigate {login['userPrincipalName']} - Device Code Flow suspected")
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access