m365-entra-attack

⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

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)

…