hunt-2025-040 v1.0 by Paul Newton

Potential ConsentFix URL Match in Proxy

Platform

Entra

Data Sources

ProxyLogs

MITRE ATT&CK

Tactics

Initial Access

Techniques

T1566

Threat Actors

unattributed

Tags

#entra #cloud #identity #oauth #phishing

Hunt Hypothesis

Threat Actors will use token theft as a means of initial access, privilege escalation and persistence. Combined with phishing as a means for initial access.

Potential ConsentFix URL Match in Proxy

Analytic #1

This analytic looks for cases where a legitimate Microsoft Authentication URL is observed, where the format of the URL combined with the resources being accessed could indicate an attempt of ConsentFix. The analytic first focuses on the URL beginning with the usual Microsoft Authentication endpoint, followed by regex looking for the GUID used in Microsoft Client IDs. This accounts for other apps aside from Azure CLI. Finally the regex then looks for the redirect_uri being localhost, this is probably the most important part of the URL in the context of ConsentFix. To reduce further noise, the regex could be extended to also look for response_type=code. This is what forces the OAuth authorization code flow. If your proxy logs capture referrer details, you could also consider looking for rare referrers in relation to this authentication flow. The rule is written in SPL/Splunk query language.

Detection Queries

Triage Steps

  1. Identify the http_referrer domain and investigate if it's a known legitimate service or a suspicious phishing page
  2. Check the client_id (AppID) against Microsoft's list of first-party applications - Azure CLI is 04b07795-8ddb-461a-bbee-02f9e1bf7b46
  3. Review if the user reported clicking on any links or following instructions from emails or websites
  4. Correlate the timestamp with Azure sign-in logs to find the corresponding authentication events
  5. Look for the "localhost" error page visit in the user's browser history or proxy logs shortly after the Microsoft auth URL
  6. Check if multiple users accessed the same referrer domain, indicating a phishing campaign
  7. Investigate the referrer domain using threat intelligence - check domain age, registration details, and reputation
  8. Review what resources the user accessed after this authentication (check AADNonInteractiveUserSignInLogs)
  9. If confirmed phishing, block the referrer domain and notify affected users to revoke their tokens
  10. Consider implementing proxy rules to alert on localhost redirects in Microsoft authentication URLs

True Positive Example

Log Entry:
{
  "TimeGenerated": "17/12/2025, 11:55:00.000",
  "User": "Hunter",
  "url": "https://login.microsoftonline.com/common/oauth2/authorize?client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&response_type=code&redirect_uri=http://localhost&resource=https://management.azure.com/&state=REDACTED&prompt=select_account",
  "client_id": "04b07795-8ddb-461a-bbee-02f9e1bf7b46",
  "redirect_uri": "http://localhost",
  "http_referrer": "phishconsent.pages.dev/"
}
Analysis:

ConsentFix phishing URL detected in proxy logs - User Hunter visited a Microsoft authentication URL with a localhost redirect_uri, referred from phishconsent.pages.dev. The URL structure is characteristic of ConsentFix attacks: legitimate Microsoft OAuth endpoint (login.microsoftonline.com), Azure CLI client_id (04b07795-8ddb-461a-bbee-02f9e1bf7b46), authorization code flow (response_type=code), and critically, a localhost redirect. The referrer domain 'phishconsent.pages.dev' is a strong indicator of a phishing page that instructed the user to authenticate and copy/paste the localhost URL containing the authorization code. This pattern represents the initial victim interaction in a ConsentFix attack chain.

Back to all hunts