Description
Link to Rule
Rule Tuning Type
None
Description
During emulation testing for the initial OAuth flow phishing, I noticed this rule -- specifically written for the testing I was doing -- did not trigger. The reason being it required post-compromise MS Graph API calls from the same session.
Background:
Volexity reported an advanced adversary doing targeted OAuth phishing where they crafted custom MSFT auth URLs with parameters that included Microsoft Authentication Broker as the client and Device Registration Service (DRS) as the target resource. Authentication happens by the user opening the link and authenticating, but an OAuth auth code is returned in the redirect which is given to the adversary by the victim whom then hits MSFT's auth server to exchange it for an access token and refresh token. This token is then subsequently used to register a device in Entra ID, receiving a device certificate and private key that is then used with the refresh token to obtain a Primary Refresh Token. The PRT is the main goal as it serves as a token-granting token.
Issue:
Requiring MS Graph requests within the same hour could have several negative implications:
- We cannot guarantee that after the PRT is obtained, they will get a new token and access MS Graph, especially within the same hour --> Thus we are skipping to the end of the attack chain from initial access without truly knowing expected dwell or operation time
- We allow the target resource to be AAD as well, however, DRS is the only target we should scope this too. Adding AAD may include additional activity out-of-scope.
- We need to be explicit with the timing. ES|QL has no deduplication in the detection engine, therefore we should lookback 61 minutes every 60 minutes and aggregate on a 30-minute rolling window. This should capture shared URL to victim opening to sharing the auth code to requesting an access token as the phishing is direct communication with the victim.
- To help mitigate false-positives, we should include logic on at least one of the auth sessions being brower-based which would indicate the victim clicking and opening the link, while the adversary could be programmatic, fake user agent or not. (non-interactive and interactive reported would be a red flag)
- We need to aggregate on session ID and ensure there is only 1 for the same activity from separate addresses. This ensures that the phishing is tied to a single user for a single session where MAB and DRS are reported for OAuth --> Huge red flag.
Example Data
Example of ESQL output
{
"target_time_window": "2025-06-10T15:15:00.000Z",
"user_display_name": "Terrance DeJesus",
"user_principal_name": "[email protected]",
"session_id": "REDACTED",
"unique_token_id": [
"bK2imDHxdkKAbgjiMkaQAA",
"3UwqnHMy4kmStLkgT8toAA"
],
"city_name": [
"Brussels",
"Massillon"
],
"country_name": [
"Belgium",
"United States"
],
"region_name": [
"Brussels Capital",
"Ohio"
],
"source_ip": [
"94.x.x.x",
"REDACTED"
],
"ip_count": 2,
"autonomous_system": [
"Global Layer B.V.",
"REDACTED"
],
"auth_protocol": "none",
"auth_requirement": "multiFactorAuthentication",
"is_interactive": [
false,
true
],
"token_type": "none",
"token_session_status": "unbound",
"session_id_count": 1,
"client_app_display_name": "Microsoft Authentication Broker",
"client_app_ids": "29d9ed98-a469-4536-ade2-f981bc1d605e",
"target_resource_ids": "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9",
"target_resource_display_name": "Device Registration Service",
"app_owner_tenant_id": "REDACTED",
"resource_owner_tenant_id": "REDACTED",
"conditional_access_status": "notApplied",
"risk_state": "none",
"risk_level_aggregated": "none",
"browser": [
"Python Requests 2.32",
"Chrome 137.0.0"
],
"os": "MacOs",
"user_agent": [
"python-requests/2.32.3",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36"
],
"has_browser": 1,
"auth_count": 2
}