m365-entra-attack

When to use this skill

Trigger when:

• Target uses M365 / Entra ID (autodiscover.* records, login.microsoftonline.com redirects, "Microsoft Office 365" in tech-stack notes)
• You have a list of corporate emails or stealer-leaked creds
• Engagement involves "credential spray", "password spray", "Entra attack", "ATO via M365"
• You see *.onmicrosoft.com, *-my.sharepoint.com, enterpriseregistration.*, enterpriseenrollment.* in recon
• Client mentions "Conditional Access", "MFA bypass", "compliant device"

DO NOT use for:

• On-prem-only Active Directory (use a separate AD-attack skill)
• Service-to-service token attacks (different threat model)
• Phishing-required attack chains (covered by phishing skills) — but you can prep for the credential-validation step here

Tenant discovery (msftrecon)

# For each owned domain
msftrecon -d client.example
msftrecon -d clientltd.example
msftrecon -d sister-brand-school.example

Key fields in output:

• Tenant ID (different domains may share OR have separate tenants — always test all owned domains)
• Federation Information.Namespace Type = Managed (cloud-only, ROPC works) | Federated (ADFS, different attack)
• SharePoint Detected (Yes = OneDrive enum vector available)
• Communication Services Teams/Skype (post-auth lateral targets)
• Admin Consent Endpoint accessible (consent-phishing surface)

Red flag: if the org has multiple Entra tenants for sister domains, each is a separate attack surface with its own user list, lockout policy, and CA configuration. Don't assume one spray covers all.

AADSTS code reference (memorize)

Critical insight: any code in {53003, 50076, 50079, 50158, 530003} means the password is correct — Microsoft only returns these AFTER successful credential validation. Document as a confirmed-valid finding even if you can't get a token.

Smart Lockout math (the cap discipline)

Microsoft default policy:

• 10 failed sign-ins in 10 minutes → 1-minute lockout
• 20 failed sign-ins → progressively longer lockouts (exponential backoff)
• Counter shared across ALL auth flows (ROPC + SAML + IMAP + EWS + SMTP + device-code)

Engagement discipline:

• Hard cap: ≤2 password attempts per user lifetime per engagement (some engagements: 1)
• State file with atomic writes — never let two test runs race the counter
• Kill switch: stop run if more than N LOCKED responses observed (suggests pre-existing attacker activity OR you miscounted; either way pause)

Mathematical guarantee: with 1 attempt per user, you cannot cause Smart Lockout (1 < 10). Any AADSTS50053 you see is therefore pre-existing → use this for active-attacker detection (see mid-engagement-ir-detection skill).

User enumeration — vectors + hardening status (May 2026)

❌ HARDENED (no longer differential)

GET /getuserrealm.srf?login=<email>&xml=1

Returns identical XML for any email matching tenant's owned domain. Tenant-level only, not user-level.

POST /common/GetCredentialType
{"username":"<email>", "isOtherIdpSupported":true, ...}

Returns AADSTS1659001 (missing flowToken) without proper session — can't enumerate.

GET /autodiscover/autodiscover.json/v1.0/<email>?Protocol=AutodiscoverV1

Returns identical 200 + same JSON body for any address. Hardened ~2024.

✅ STILL WORKS (May 2026 — track shelf life)

OneDrive personal-site differential:

GET /personal/<user>_<domain>_com/_layouts/15/onedrive.aspx HTTP/1.1
Host: <tenant>-my.sharepoint.com

• 302 → user EXISTS (auth-required redirect to Authenticate.aspx)
• 404 → user does NOT exist (404 FILE NOT FOUND)
• ZERO authentication attempt → ZERO lockout impact
• Bonus: Sprequestduration header faster (~40ms) for existing users vs ~600ms for non-existent — secondary timing oracle

Caveats:

• Only works if SharePoint is provisioned for the tenant (check msftrecon SharePoint Detected: Yes)
• Microsoft is hardening these endpoints over time — re-verify before relying on it
• Some users may exist in Entra without OneDrive provisioning (license-dependent) — false negatives possible

2026-05-17 re-verification (authorized-engagement revalidation): The OneDrive enum primitive STILL WORKS as of 2026-05-17. Calibration: licensed users return HTTP 200 with ~57KB body; nonexistent users / shared-mailbox accounts return 404 with 0 bytes. The /personal/ root path (without /_layouts/15/onedrive.aspx) returns the same differential.

Killer use case: license differential = account-class signal. Cross-reference OneDrive 200/404 with ROPC AADSTS50034/50126:

The OneDrive-404 + ROPC-50126 combination is the signal for "functional account that might bypass MFA" — admins frequently exempt these from CA policies because they're used by automation that can't satisfy MFA. Discovered usefulness on authorized-engagement revalidation: identified noreply@, purchase@, accounts@, postmaster@, transport@ as functional-account candidates (typical for any conglomerate tenant).

ROPC AADSTS50034 / AADSTS50126 differential:

• AADSTS50034 (user not exist) does NOT increment Smart Lockout counter
• AADSTS50126 (wrong password) DOES increment
• So a 1-attempt-per-user spray can be used as a coarse user-existence enumerator (each AADSTS50034 = miss, each AADSTS50126 = hit + 1 attempt burned)

Conditional Access bypass options (most blocked, document anyway)