Detecting Greatness PhaaS: New Device Code Flow Capabilities
Just caught the update on the Greatness PhaaS platform adding support for device code phishing. This is a significant evolution because it shifts the attack vector from credential harvesting to straight-up session hijacking via the OAuth 2.0 Device Authorization Grant flow.
For those who haven't dug into the mechanics yet, the attacker leverages the legitimate oauth2/v2.0/devicecode endpoint. They initiate a request to get a device code and user code, then display the user code to the victim on a phishing page. The victim enters the code on the legitimate login site (e.g., microsoft.com/devicelogin), completes the MFA challenge, and the threat actor's polling service immediately grabs the tokens.
Since the user is logging into the real site, standard MFA protections are bypassed entirely. The tricky part is distinguishing between legitimate device code flows (used by CLIs, IoT, and restricted devices) and malicious ones.
I've started refining our KQL queries in Sentinel to flag this behavior, specifically looking for high-frequency polling intervals or successful logins on the device code endpoint followed immediately by Graph API calls from unusual locations.
SigninLogs
| where AuthenticationProtocol == "Device Code Flow"
| where Result == "Success"
| extend DeviceDetail = parse_(DeviceDetail)
| project Time, UserPrincipalName, AppId, DeviceDetail.browser, DeviceDetail.os
| order by Time desc
Are you guys seeing much success with blocking the 'Other' client types in Conditional Access, or does that break too many legitimate workflows for your developers?
Blocking 'Other' client types via Conditional Access is the first line of defense, but you have to be careful. We initially broke our Azure CLI access for some dev teams. The workaround is to create a specific security group for users who actually need device code flow and exclude them from the block policy. It reduces the attack surface significantly.
From a pentester's perspective, Greatness automates the polling part really well now, which used to be the pain point of this attack. The detection logic you posted is solid, but you should also correlate it with AADNonInteractiveUserSignInLogs. The attacker usually has to authenticate silently to exchange the code, which shows up there.
We've started looking for the specific User-Agent strings associated with the Greatness toolkit. They often mimic standard browsers but miss the latest version patches or TLS fingerprinting details. Combining UA analysis with the KQL query helps cut down on false positives from legitimate Azure CLI usage.
Validating the authentication protocol itself is crucial for hunting. While User-Agents help, filtering Sign-in logs specifically for "Device Code Flow" events can reveal successful compromises that bypassed other filters.
Here is a quick KQL query to audit these specific authentication events:
SigninLogs
| where AuthenticationProtocol == "Device Code Flow"
| project TimeGenerated, UserPrincipalName, AppDisplayName, Location
Pairing this with geo-anomalies usually catches the outliers fast.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access