Skip to content
Draft Public-source analysis. Not a forensic reconstruction.

What Would Pathros Do?

Microsoft Midnight Blizzard and the OAuth Access Path

For CISOs, IAM engineers, cloud security engineers, and security architects.

Public guidance published · January 2024

The lesson

Access risk paths are not flat. They are hierarchical.

In January 2024, Microsoft published guidance on Midnight Blizzard activity that described a modern identity incident: a legacy non-production test tenant account without MFA was compromised, OAuth applications were abused, additional OAuth applications were created and granted consent, and Exchange Online mailbox access was reached through application permissions.

The important lesson is not only that a test account was weak.

The important lesson is that the dangerous access was a path.

The path Microsoft described, in plain shape:

  1. Legacy test tenant account

    no MFA, non-production

  2. Legacy OAuth application

    elevated corporate access

  3. Additional malicious OAuth applications

    created and granted consent

  4. App-only Exchange Online permission

    full_access_as_app

  5. Corporate mailbox access

    reachable without a signed-in user

The public-shape path. Each step is a node Microsoft mentioned in public guidance.

Old question vs Pathros question

A flat IAM review asks

Which account is risky?

Pathros asks

Which identity can reach which resource through which chain of apps, grants, permissions, and inherited access?

That is the difference.

Public facts

What happened

Microsoft’s public guidance says Midnight Blizzard used password spray attacks to compromise a legacy, non-production test tenant account that did not have MFA enabled. Microsoft also describes the actor as adept at identifying and abusing OAuth applications to move laterally across cloud environments and for post-compromise activity such as email collection.

Microsoft then describes the OAuth stage: the actor identified and compromised a legacy test OAuth application with elevated access to Microsoft’s corporate environment, created additional OAuth applications, created a user account to grant consent, and used the legacy test OAuth application to grant the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.

Microsoft’s guidance after the incident tells defenders to audit the privilege level of identities, users, service principals, and applications — especially unknown, unused, no-longer-used, or overprivileged identities.

CISA later issued Emergency Directive 24-02 concerning the risk from the nation-state compromise of Microsoft’s corporate email system, further underscoring that this was not a narrow misconfiguration problem. It was an enterprise risk event tied to identity, email, credentials, and trust.

The old view

What a security team may have seen

A traditional security team may have seen separate objects:

Isolated objects as a flat IAM review would treat them.
Object Why it may look isolated
Legacy test tenant account “It is non-production.”
Missing MFA “Known hygiene issue.”
OAuth application “Application registration / service principal inventory.”
Consent grant “Admin consent record.”
App-only permission “Application permission.”
Exchange Online mailbox access “Email access / EWS / mailbox telemetry.”
Additional malicious OAuth apps “New app registrations.”

Each object is important. But the real risk appears when they connect. The path is the product.

The Pathros view

What Pathros would model

If the relevant Entra, OAuth, app-consent, service-principal, Exchange, and mailbox-scope data were ingested, Pathros would model the incident class as a connected access graph.

The same five steps as a connected graph:

  1. Legacy test tenant account

  2. Legacy test OAuth application

    via can control / modify

  3. Additional malicious OAuth applications

    via can grant / create / consent

  4. Office 365 Exchange Online full_access_as_app

    via receive app-only permission

  5. Corporate mailbox resources

    via reaches

Synthetic node and edge names. Illustrative graph mapping.

Pathros view

identity → app → grant → permission → resource

not: account list, app list, permission list, mailbox list

Incident layer → Pathros concept → Why it matters.
Incident layer Pathros concept Why it matters
Legacy non-production test tenant account Identity node Non-production does not mean non-dangerous if it connects to production trust.
OAuth application Application / service-principal node Apps are non-human identities with standing power.
Consent grant Grant edge Consent is an access path, not just an audit entry.
App-only permission Permission node App-only access can operate without a signed-in user.
Exchange mailbox access Resource node Mailboxes are sensitive resources and may contain credentials, source context, or executive communications.
Application access policy / App RBAC scope Constraint edge / scope boundary Scope determines whether app access is narrow or organization-wide.

Illustrative mapping. Synthetic node and edge names.

Path-shaped thinking

What Pathros would see differently

Five things change when the graph, not the row, is the unit of analysis.

  1. The legacy account would not be treated as harmless because it was non-production.

    Pathros would ask whether this identity reaches any production or corporate resource through any application, consent, or inherited trust path. The label “test tenant” would not end the analysis.

  2. OAuth apps would be treated as access-bearing identities.

    Pathros would not treat an OAuth application as background configuration. It would model the app as a node capable of carrying permission to resources.

  3. App consent would become a graph edge.

    Consent grants and app-role assignments are not just administrative records. They can be the bridge between an initial identity compromise and a sensitive resource.

  4. App-only mailbox access would become a resource reachability question.

    Microsoft Learn notes that applications using application permissions can access mailboxes without a signed-in user, and that application permissions such as mail permissions may grant access across all mailboxes unless scoped through application access policies or newer application RBAC. Pathros would model this as app-only permission → mailbox resource scope.

  5. The dangerous path would be visible before the incident becomes a flat alert list.

    The question changes from “Which objects are risky?” to “Which path lets this identity reach this resource?”

Severity

What Pathros would rank

A Pathros-style ranking would prioritize this class of path because it combines legacy identity exposure, missing MFA, OAuth application control, app-only permission, mailbox access, high-value corporate email resource exposure, and possible persistence through additional OAuth applications.

Illustrative Pathros-style severity

Critical

This is not a claim that Pathros scored Microsoft’s internal environment. It is a reasoned severity label for the public pattern: a legacy identity path into app-only corporate mailbox access.

Dry-run remediation

What Pathros would simulate

A Pathros remediation twin would not touch production. It would clone the access graph, apply a proposed change in memory, and ask:

If we apply this proposed permission change, does the dangerous path disappear, and what else loses access?

Proposed change → What the twin would test.
Proposal What the twin would test
Disable legacy test app credential Does the path from test tenant to corporate app access disappear?
Remove app-only mailbox permission Does the app lose reachability to mailbox resources?
Scope mailbox access through App RBAC or an application access policy Does broad mailbox access become limited to approved mailboxes?
Disable unknown / suspect service principal Does the persistence path disappear?
Require human approval for high-impact app consent Does future broad app-only access require governance?
Quarantine legacy identity Does the initial identity path lose reachability?

The Phase 1 Pathros doctrine remains

{
  "mode": "dry_run",
  "live_changes_executed": false,
  "requires_human_approval": true
}

A human decides. Nothing executes from this page or from the model.

The takeaway

What this proves

Midnight Blizzard is a powerful public example because the access path was not flat.

It was not simply:

one bad account

It was:

legacy identity → OAuth application → app consent / additional app → app-only permission → Exchange mailbox resource

Old systems review isolated objects. Pathros reasons over the path. That is why Pathros exists.

Engineering boundary

Phase 2A backlog note

This case study should not be used to rush Entra / OAuth / Exchange semantics into the product engine before Phase 2A is ready.

Instead, it creates a clear backlog for connector-era exact graph support:

  • Entra user / service principal ingestion
  • OAuth application nodes
  • App registration and service-principal relationships
  • Consent grant edges
  • App-role-assignment edges
  • App-only permission modeling
  • Exchange Online mailbox resources
  • Application Access Policy and App RBAC scope constraints
  • Cross-tenant and cross-environment boundaries
  • Stale / legacy identity flags
  • Missing MFA / conditional-access posture

The website can use the case study now. The engine should only support these semantics when Phase 2A exact graph modeling is implemented and tested.

Honest framing

Claims we can make

Bold framing on the structure of the risk. Restrained claims about Pathros itself. The next list is the things this page deliberately does NOT say.

Safe to use

  • This public incident shows why identity risk is path-shaped.
  • Microsoft’s public guidance explicitly points defenders toward auditing identities, service principals, applications, and app-only permissions.
  • Pathros is designed to model access as connected identity-to-resource paths.
  • Pathros Phase 1 proves this method on a tracer bullet across identity, GitHub, CI/CD, AWS role assumption, permission, and sensitive resource.
  • Phase 2A extends exact graph semantics toward real connector-backed enterprise identity systems.

Unsafe — do not use

These statements would overclaim. Pathros refuses them. They appear here only so the boundary is visible.

  • Pathros would have prevented Microsoft’s incident.
  • Pathros detected the Microsoft breach.
  • Microsoft would not have been breached with Pathros.
  • Pathros currently has production Entra / OAuth / Exchange connector coverage.
  • Pathros has private knowledge of Microsoft’s internal environment.

Take the next step

See the proof model. Or request a scan.

Pathros begins read-only. No write happens without explicit approval.

References

Sources

Every public document this case study draws on. All links open in a new tab.

  1. Microsoft Security Blog — Midnight Blizzard: Guidance for responders on nation-state attack

    https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/

  2. Microsoft Learn — Application Access Policies

    https://learn.microsoft.com/en-us/exchange/permissions-exo/application-access-policies

  3. Microsoft Learn — Role Based Access Control for Applications in Exchange Online

    https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac

  4. CISA ED 24-02 — Mitigating Significant Risk from Nation-State Compromise of Microsoft Corporate Email System

    https://www.cisa.gov/news-events/directives/ed-24-02-mitigating-significant-risk-nation-state-compromise-microsoft-corporate-email-system-closed