TL;DR

Last week, while investigating some suspicious Microsoft Outlook activity for a client at iZOOlogic, I stumbled upon something that made my heart sink for a while. What started as a routine incident response engagement turned into the discovery of one of the most sophisticated OAuth phishing campaigns I’ve seen in my experience so far of security research.

Here’s the kicker - this attack doesn’t steal your password. It doesn’t care about your MFA. Instead, it tricks you into granting a malicious application complete access to your mailbox, and it does it so smoothly that most users won’t think twice before clicking “Accept.”

Let me walk you through what I found.

The Attack Landscape: Beyond Traditional Phishing

In my little years of security research, I’ve watched attackers evolve from simple credential theft to something far more sophisticated. The modern attack doesn’t break down the front door anymore - it walks right in through the reception area with a visitor’s badge.

Microsoft 365 has become the perfect hunting ground. Why? Because it’s not just an email platform - it’s an interconnected ecosystem of productivity tools that are essentially a treasure trove of corporate intelligence.

The new attack methodology is brutally simple yet incredibly complex. Imagine an attack that:

  • Completely bypasses traditional security controls
  • Maintains persistent access even after password resets
  • Uses the platform’s own authentication mechanisms against itself

Here’s how these advanced Adversary-in-the-Middle (AiTM) attacks work:

  1. An attacker sends a meticulously crafted phishing email - so good it would make a social engineer weep with joy.
  2. The victim clicks a link that looks legitimate, landing on what appears to be a standard Microsoft login page.
  3. A threat actor-controlled proxy server sits in the middle, capturing every single authentication request and token.
  4. Multifactor authentication? Doesn’t matter. These proxies can forward MFA tokens in real-time.

The most terrifying part? Microsoft 365’s default session token configuration gives attackers a 90-day window of opportunity. Ninety. Entire. Days. Of. Access.

This isn’t theoretical. This is happening right now, to organizations who think they’re protected.

The Attack That Keeps Me Up at Night

It started with a suspicious OAuth consent screen that one of our clients’ employees reported. At first glance, it looked like any other Microsoft application requesting access - clean interface, professional design, all the hallmarks of legitimacy. But something felt off.

virustotal Source : Virustotal Scan

I got zero detection over Virustotal which made me excited in the first place.

Digging into the HTTP traffic, I found the initial redirect chain:

http://nqvntxrfe6yx.deusgolf.com/account-lock-with-token/?em=[redacted]

Now, if you’re in security, alarm bells should be ringing. That subdomain is clearly generated by DGAs. But what caught my attention was where it led.

💡 Domain Generation Algorithms (DGAs) are sophisticated techniques used by threat actors to dynamically generate a large number of domain names. If one domain is blocked, hundreds of backup domains are ready.

  • Generates domains algorithmically using:
    • Time-based seeds
    • Cryptographic hash functions
    • Predefined generation rules
  • Evasion advantage:
    • Constantly rotating domains makes tracking difficult
    • Bypasses traditional IP/domain blacklisting
    • Reduces detection probability by security tools

The attackers had set up an intricate infrastructure that leveraged Microsoft’s own OAuth endpoints. They weren’t trying to steal credentials - they were after something far more valuable: persistent mailbox access through OAuth permissions.

Down the Rabbit Hole

outlookpage

The more I dug, the more impressed and concerned too I became. The attack flow is brilliant in its simplicity:

  1. The victim receives an urgent email about their account being locked
  2. Clicking the link takes them through a legitimate Microsoft login flow
  3. They’re presented with a consent screen requesting mailbox permissions
  4. Once granted, the attacker has persistent access - even if the victim changes their password

But here’s where it gets really interesting. Looking at the OAuth permission request: burp2

{
  "requested_permissions": [
    "User.Read",
    "offline_access",
    "Mail.ReadWrite"
  ]
}

See that offline_access scope? That’s the real danger here. It allows the attacker to obtain refresh tokens that don’t expire. Even if the victim realizes something’s wrong and changes their password, the attacker retains access until those OAuth permissions are explicitly revoked.

Flow of the attack

💡 Switch to light mode for more visibility

stateDiagram-v2
    [*] --> VictimEmail : Receives Urgent Email
    note right of VictimEmail
        Fabricated message about 
        account lock
    end note

    VictimEmail --> MicrosoftLoginPage : Clicks Malicious Link
    
    MicrosoftLoginPage --> OAuthConsentScreen : Legitimate Microsoft Login
    note right of OAuthConsentScreen
        Carefully crafted consent screen
        requesting mailbox permissions
    end note

    OAuthConsentScreen --> AttackerAccess : User Grants Permissions
    note right of AttackerAccess
        Attacker gains:
        - Mail.ReadWrite access
        - Offline refresh tokens
    end note

    AttackerAccess --> PersistentAccess : Maintains Access
    note right of PersistentAccess
        Access remains even if:
        - Password changed
        - MFA enabled
    end note

    PersistentAccess --> [*] : Ongoing Mailbox Compromise

The Infrastructure

The attackers weren’t amateurs. Their infrastructure showed careful planning:

The callback domain - c.oinbase.top - is a clever piece of typosquatting. Notice the missing ‘c’ in what should be ‘coinbase’? In a consent screen URL, that’s easy to miss. The single-character subdomain further minimizes suspicion.

burp1

They also implemented sophisticated browser fingerprinting. Here’s a snippet of what they collect:

burp3

{
  "deviceMemory": 8,
  "hardwareConcurrency": 12,
  "timezone": "Asia/Calcutta",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36",
  "platform": "Win32",
  "language": "en-US",
  "languages": ["en-US"],
  "cookiesEnabled": true,
  "extensions": "No extensions detected",
  "screen": {
    "width": 1920,
    "height": 1080,
    "availWidth": 1920,
    "availHeight": 1032,
    "colorDepth": 24,
    "pixelDepth": 24
  },
  "window": {
    "innerWidth": 1044,
    "innerHeight": 944,
    "outerWidth": 0,
    "outerHeight": 0
  },
  "timezoneOffset": -330,
  "maxTouchPoints": 0,
  "referrer": "https://account.live.com/",
  "battery": null,
  "mediaDevices": null,
  "permissions": {},
  "plugins": [
    "PDF Viewer",
    "Chrome PDF Viewer", 
    "Chromium PDF Viewer",
    "Microsoft Edge PDF Viewer",
    "WebKit built-in PDF"
  ],
  "mimeTypes": [
    "application/pdf",
    "text/pdf"
  ]
}

This isn’t just for show - it’s actively used to detect and evade security sandboxes and automated analysis tools. If the fingerprint doesn’t match their target profile, the attack simply doesn’t trigger.

Why This Keeps Me Awake at Night

From the beginning of Jan 2024, I’ve seen countless phishing campaigns. But this one’s different. Here’s why:

  1. It completely bypasses MFA - because you’re logging into a legitimate Microsoft page from your regular browser.
  2. Password changes don’t help - the OAuth tokens persist
  3. It’s nearly impossible to detect with traditional security tools
  4. Most organizations aren’t monitoring for suspicious OAuth grants

The worst part? This campaign is still active, and it’s evolving. We’ve seen the attackers rotate through different domains and adjust their tactics to evade detection.

Protecting Your Organization

So what can you do? Here’s what I recommend:

  1. Implement strict OAuth governance. Microsoft 365 lets you restrict which applications can request OAuth permissions. Use it. Here’s a PowerShell script to help you audit your current OAuth grants:
Connect-AzureAD
Get-AzureADServicePrincipal -All $true | 
Where-Object {$_.AppId -eq "7a420f30-3dbf-4023-898f-f61bcb8cf6c5"} |
Select DisplayName, AppId, PublisherName
  1. Monitor for suspicious OAuth activities. Look for:
  • New application consent grants, especially those requesting mail access
  • Applications with unusual redirect URIs
  • Multiple consent grants from the same application in a short time period
  1. Apply the following Sigma Rule:
   title: Suspicious OAuth App Consent
   description: Detects suspicious OAuth consent grants
   status: experimental
   author: CyFun
   logsource:
     product: azure
     service: auditlogs
   detection:
     selection:
       eventType: 'Add OAuth2PermissionGrant'
       permissions: 
         - 'Mail.ReadWrite'
         - 'offline_access'
     condition: selection
   falsepositives:
     - Legitimate mail migration tools
     - Approved third-party email clients
   level: high

Finally, train your users. They need to understand that permissions matter just as much as passwords. A legitimate Microsoft application shouldn’t be asking for mailbox access unless there’s a clear business need.

IOCs

For the blue teamers out there, here are the key indicators we’ve observed:

  • Domain: nqvntxrfe6yx.deusgolf.com
  • OAuth callback: c.oinbase.top
  • Client ID: 7a420f30-3dbf-4023-898f-f61bcb8cf6c5

Final Thoughts

This campaign represents a significant evolution in phishing tactics. It’s sophisticated, effective, and unfortunately, likely to be widely copied. The days of simple credential phishing are giving way to more sophisticated OAuth-based attacks.

I’ll update this post as we discover more about this campaign. In the meantime, check your OAuth permissions, implement proper monitoring, and stay safe out there.

❗ The post above reflects my personal perspective, which is based on the analysis shared in my iZOOlogic Threat Advisory titled OAuth Exploited: Silent Takeover of Microsoft Outlook Accounts.