Defending Against Malicious Microsoft Entra OAuth Apps and Token Theft

The discovery that attackers are weaponizing Microsoft Entra ID OAuth flows to gain long‑lived access to corporate mail and files is not theoretical—it’s a clear, recurring pattern that demands a rethink of how organizations govern third‑party applications, consent, and service principals across tenants.

Background / Overview​

Microsoft’s OAuth model intentionally separates a global application object (the developer’s blueprint) from local service principals (the tenant‑specific instance), and that separation is what gives attackers a reliable avenue to persist: create a convincing app in their own tenant, phish a user in the target tenant to click “Accept,” and a service principal is born inside the victim’s directory with delegated or application permissions that can survive password resets and MFA. Wiz’s analysis of multiple campaigns culminated in a detection pipeline called OAuth Apps Scout that automates detection and cross‑tenant pivoting to surface malicious OAuth apps—an operational response to a problem now corroborated by independent threat intelligence. Proofpoint documented overlapping campaigns in 2025 that impersonated Adobe, DocuSign and other productivity brands to harvest credentials and bypass MFA via AiTM (attacker‑in‑the‑middle) phishing kits.
The technical risks are straightforward and severe: OAuth grants can carry the same access as a stolen credential but without the usual authentication telemetry that tips off defenders. When the user grants consent, the attacker-controlled app can receive OAuth tokens or trigger redirects that lead to credential capture, then use delegated or application permissions to read mail, download files, and maintain persistence through casts of service principals and consent records.

How the attacks work — a short, actionable anatomy​

• The adversary registers a legitimate‑looking application in their own Entra tenant (name, logo, homepage).
• They spear‑phish targets with a link that leads to a real Microsoft sign‑in/consent page for that app.
• If the user clicks Accept—or even Cancel in some flows—the OAuth redirect completes and the attacker captures tokens or forces a redirect to an AiTM phishing flow.
• A service principal appears in the victim tenant; permissions granted persist independently of the user account.
• Attackers use the tokens or Graph API calls to enumerate mail/files and exfiltrate data, often without tripping standard anomalous sign‑in detection.

Proofpoint’s 2025 report details multiple such flows and shows how the campaigns used narrow scopes (profile/openid/email) combined with redirectors to funnel victims into Tycoon and similar AiTM kits—illustrating that permission breadth is not the only vector of harm. Narrow scopes plus a credential harvest step are often sufficient for takeover.

---

Why this is different from “normal” phishing​

Phishing that captures passwords tends to be noisy: failed login attempts, password resets, or unusual sign‑in locations. OAuth‑based abuse is quieter because:

• Consent flows happen on Microsoft domains and surface legitimate Entra branding (organization name, tenant branding).
• Tokens granted through OAuth don’t necessarily create the same authentication logs as direct password theft.
• Tokens and delegated permissions can survive MFA, and service principals are persistent objects that can be reused across months or years.

That stealth explains why attackers moved from blunt homoglyph spoofing (visual confusion) to more contextually subtle SaaS impersonation (brand impersonation of DocuSign/Adobe) and sophisticated redirect infrastructures that chain through intermediary hosting platforms. Proofpoint’s telemetry shows dozens of malicious OAuth apps and hundreds to thousands of lures distributed across email campaigns—confirming the scale and the method.

Overview of the OAuth Apps Scout approach (what worked)​

Wiz took a collections‑to‑campaign approach rather than a single‑signal detection strategy. The pipeline has four operational stages:

• Extraction and Baseline — ingest OAuth apps from many tenants, build a prevalence baseline, and filter out common, legitimate SaaS app IDs and names so the focus is on outliers.
• Enrichment — gather signals per app: publisher verification, homepage existence, reply (redirect) URLs, DNS ownership data, tenant adoption counts, and permission (scope) requests.
• Decision & Prioritization — calculate composite risk scores that combine weak signals (name similarity, rare tenant count, suspicious redirect pattern, unverified publisher, unusual scopes).
• AI‑Assisted Contextual Evaluation & Pivoting — use an AI step to reason holistically about the app metadata, then pivot across shared indicators (reply domains, owning tenant, naming patterns) to cluster apps into campaigns.

That layered, enrichment‑first model is sensible: no single feature reliably identifies malicious apps, but together they form a high‑confidence detection surface that can be prioritized for human review.

What the telemetry shows (patterns and evolution)​

• Early campaigns (examples going back to 2019, according to retrospective findings) used visual homoglyphs—substituting Cyrillic letters for Latin ones—to masquerade as Microsoft brands and trick users at a glance.
• More recent campaigns (early 2025) impersonated third‑party SaaS brands like Adobe and DocuSign, and relied on multi‑step redirectors plus AiTM kits to capture credentials and session tokens. Proofpoint observed more than two dozen similar apps and clusters using consistent reply URLs and narrow scopes to enable follow‑on credential harvest.
• Attackers frequently host redirectors or landing pages on legitimate platforms (ClickFunnels, GitHub Pages, free hosting subdomains) to evade content filters and look benign at a casual glance.

Note: claims about malicious apps dating specifically to 2019 (homoglyph clusters) come from retrospective analysis; public reconstructions of those particular homoglyph app registrations are harder to independently validate in the open record. Where public reporting on early homoglyph app registrations exists, it mostly documents the phishing technique of spoofing file‑sharing workflows rather than cross‑tenant OAuth app abuse specifically. We flag historical dates that are difficult to verify in public datasets so defenders can treat retrospective timelines with appropriate caution.

---

Why defenders can find and stop these attacks (but it’s non‑trivial)​

Even the most careful attackers must interact with the OAuth protocol and leave metadata: client IDs, reply URIs, publisher/tenant IDs, and hosting infrastructure. These are detectable signals if you look across tenants and correlate.
Key defender heuristics that work in practice:

• Tenant prevalence — legitimate SaaS integrations appear across many tenants with the same global Application ID; a brand‑like name that is only installed in a handful of tenants is suspicious.
• Publisher verification — Microsoft’s publisher verification status is a strong signal; verified publishers rarely match a random tenant.
• Reply/redirect URL analysis — redirect URIs that use free hosting, uncommon subdomains, or domains not associated with the claimed vendor are strong indicators.
• Scope sensitivity — Mail.Read or Files.ReadWrite.All should trigger high severity when requested by an external/unverified app.
• Low‑prevalence grants — apps consented by only 1–2 users in a tenant (especially high‑risk scopes) tend to be targeted phishing artifacts rather than legitimate enterprise installs.

These tactics are not theoretical: Microsoft itself moved to require admin consent for many third‑party app flows as a secure‑by‑default update in mid‑2025, making user consent to file/site access more restrictive to reduce this exact class of risk. Administrators should register and operationalize the admin consent workflow as part of standard tenant hardening.

---

Practical playbook for blue teams (immediately actionable)​

Below are prioritized, practical steps SOCs and identity teams can implement today.

• Enforce consent governance
• Restrict user consent for third‑party applications where possible; require admin approval for apps accessing files/sites.
• Implement and advertise an Admin Consent Workflow so users request apps through a tracked process. Microsoft’s mid‑2025 changes enable such defaults and should be adopted.
• Inventory and continuous audit
• Export the list of service principals, consent records, and app permissions regularly.
• Look for apps that are consented by a single user, have unusual redirect URIs, or request high privileges.
• Baseline known good apps & reply URLs
• Maintain a whitelist/baseline of commonly used app IDs and canonical reply URL patterns for your organization.
• Alert on first‑time apps that do not match the baseline, especially those with reply URIs that are not enterprise controlled.
• Monitor grant patterns and unusual token use
• Audit Graph API usage tied to newly created service principals.
• Flagd mail/files from service principals that were recently registered or consented.
• Correlate cross‑tenant signals
• Use threat intelligence feeds and internal cross‑tenant correlation to cluster apps by reply URL and tenant metadata—attackers reuse infrastructure, and pivoting reveals campaigns.
• Harden remediation and forensics
• Revoke suspicious OAuth grants and delete unused service principals.
• Rotate credentials where service principals used client secrets or certificates.
• When investigating, collect service principal creation timestamps, consent records, and sign‑in logs tied to the service principal; CISA and other agencies recommend auditing for unexpected application credential changes.
• User awareness & targeted phishing simulations
• Train users to pause at consent dialogs: check publisher verification, examine redirect URIs, and report unexpected requests to IT.
• Conduct phishing simulations that include OAuth consent flows so users learn to recognize malicious prompts.

---

Strengths and limits of the detection model​

Strengths​

• Signal fusion works: Combining weak signals (name similarity, uncommon reply URIs, low tenant prevalence) reduces false positives while surfacing real attacks.
• Cross‑tenant pivoting reveals campaigns: Many malicious apps are reused across targets; clustering by shared infrastructure yields campaign visibility that single‑tenant hunts miss.
• Actionability: The pipeline identifies discrete remediation actions (revoke grants, remove service principals), and maps to admin workflows (consent governance).

Limits & Risks​

• False positives from legitimate marketing / ad hoc integrations: Many legitimate apps use multi‑tenant hosting and third‑party platforms for redirects (e.g., marketing pages on ClickFunnels). A strict denylist would break legitimate business flows.
• Dependency on enrichment sources: Accurate DNS ownership and publisher verification data are essential; attackers can quickly register lookalike domains or move to robust hosting to hide attribution.
• Telemetry gaps: Not all tenants share telemetry; detection relies on sufficient cross‑tenant coverage to cluster activity.
• Adversary adaptation: Attackers will shift tactics—longer trusted domain chains, compromised legitimate tenants hosting redirects, or registering legitimate publisher verification via stolen accounts—which will require defenders to keep evolving the model.

Because of these limits, detection is most effective when combined with governance: block or escalate high‑risk consent flows, maintain a human‑in‑the‑loop review process, and automate the low‑noise detections.

---

Campaign case studies (what we learned)​

• Early 2025 SaaS impersonation cluster: Multiple apps impersonating Adobe/DocuSign used similar reply URI patterns and narrow scopes to funnel users into Tycoon AiTM kits. Proofpoint saw dozens of apps and multiple tenant impacts; in several clusters, the apps were present in over 20 tenants but only produced confirmed account takeovers in a handful—consistent with their role primarily as phishing lures rather than direct API compromises.
• Homoglyph legacy detections (retrospective): Analysis found Cyrillic homoglyph spoofing of Microsoft product names in older app registrations. These visual tricks were broad and noticeable, and defenders had some success detecting them at the time because they relied on simple character substitutions. However, retrospective reporting on specific OAuth app homoglyph registrations from 2019 is limited in public channels; defenders should treat older timelines cautiously while assuming the technique was in circulation.

Both patterns show that attackers trade off between obvious visual spoofing and more subtle contextual spoofing—today’s campaigns prefer subtlety because it scales and bypasses casual manual review.

---

Technical checklist for incident responders​

• Immediately export:
• ServicePrincipals (list with AppId, displayName, ownerTenantId)
• OAuth consent logs and AdminConsent recordsh permissions via Graph API
• For each suspicious app: capture
• Application (global) ID and local service principal ID
• Reply/redirect URIs (extract host/domain)
• Publisher verification state
• Tenant adoption count (how many tenants have the same global AppId)
• Consent timestamps and consenting user(s)
• Remediation steps:
• Revoke OAuth grant tokens for the service principal.
• Delete or disable the service principal if unrecognized.
• Rotate any impacted credentials and audit sign‑ins.
• Notify affected users and run focused mailbox/file exfiltration checks.
• If evidence of ATO or data theft exists, engage incident response and preserve logs for law enforcement.

CISA and other public advisories have long recommended auditing application credentials, service principal changes, and consent records as part of post‑compromise detection hygiene; these same artifacts are invaluable for proactive detection.

---

Strategic recommendations for identity hygiene (board + security leadership)​

• Enforce admin consent by default for high‑risk scopes (files, mail) and require an approval workflow for exceptions. Microsoft’s Secure by Default changes in mid‑2025 institutionalize this principle; organizations that adopted or tuned these settings reduced the attack surface for app consent abuse.
• Invest in cross‑tenant telemetry or partner with vendors that can correlate app metadata across customers—campaign visibility often requires multi‑tenant signals.
• Make OAuth governance part of your identity risk program. Include service principal hygiene in quarterly risk reviews and tabletop exercises.
• Prioritize least privilege for SaaS integrations and enforce just‑in‑time consent where possible.

---

Final assessment — what defenders must internalize​

Malicious OAuth applications are a class of attack that blends social engineering, protocol abuse, and infrastructure reuse. They are not novel in technique—phishers have long abused trusted domains and file‑sharing workflows—but the scale and persistence of multi‑stage OAuth campaigns in 2024–2025 changed the calculus: attackers now routinely gain access that bypasses MFA and survives traditional credential protections.
The good news is that this attack surface is detectable if defenders stop treating OAuth apps as opaque, one‑off approvals and start treating them as first‑class security objects: baseline normal application usage, enrich metadata, prioritize multi‑signal detections, and enforce strict consent governance. Automated pipelines like OAuth Apps Scout prove that operationalized detection is practical: detect suspicious apps early, pivot across tenants to reveal campaigns, and apply surgical remediation.
Security teams should move from reactive revocation to proactive governance: require admin consent for risky scopes, monitor first‑time app occurrences, baseline reply URLs, and correlate app metadata across environments. Those steps shift the advantage back toward defenders—because the OAuth protocol that attackers rely on also leaves breadcrumbs that we can and must use to find them.
Conclusion: treat OAuth consent as the powerful access vector it is—not a convenience UI for end users—and operationalize both human and machine controls to ensure one careless click does not yield a persistent door into your tenant.

---

Source: wiz.io Uncovering Malicious OAuth Campaigns in Entra ID | Wiz Blog