claudetools/clients/cryoweave/reports/2026-07-08-breach-check.md

CryoWeave — M365 Compromise Check

• Date (UTC): 2026-07-08
• Tenant: cryoweave.com / 44705a37-b5d8-4bb1-882d-e18775612ada
• Analyst: Mike Swanson (GURU-5070), ComputerGuru remediation suite
• Scope: All 3 enabled accounts. Read-only investigation.

Verdict: NOT COMPROMISED — active targeted password-spray in progress, all attempts failing

greg@cryoweave.com is under an active, distributed, targeted credential-stuffing / password-spray attack, but the tenant's controls are holding: every foreign/tooling sign-in attempt is failing, and every successful authentication traces to Greg's own two US IPs via legitimate clients. No account takeover. No malicious persistence.

Accounts reviewed

Account	Role	Finding
greg@cryoweave.com	Owner (Greg Schickling)	Under active attack, not breached — see below
admin@cryoweave.onmicrosoft.com	Default admin	Clean — 0 sign-ins/rules/grants in 30d
sysadmin@cryoweave.com	ACG management (ours)	Expected — created 2026-06-15, clean

The attack (greg@cryoweave.com)

Distributed failed sign-ins across many countries in a tight window, all against Greg's account:

Time (UTC)	Result	IP	Geo	Client
07-03 20:54	50126 bad-password	2605:6400:...	US/Las Vegas	Azure CLI
07-08 01:12–01:13 (6x, ~21s)	50053 locked	216.26.237.44 / .251.189 / 45.3.41.51 / 65.111.27.198 / 65.111.21.228	US-Atlanta, CA-Toronto x2, DE x2	Azure CLI
07-08 06:46	50053 locked	194.5.52.22	US/LA	AAD PowerShell
07-08 (non-interactive)	50053 locked	149.19.29.218 / 89.10.221.226 / 2a09:bac5:... / 38.22.88.23	NZ, NO, RU, CA	"Microsoft Online Services"

• Error 50126 = invalid credentials; 50053 = account locked by smart lockout (too many bad attempts). Attacker does not have the password.
• Client apps abused: Azure CLI, AAD PowerShell, Microsoft Online Services — first-party IDs commonly used by spray tooling (pre-consented, scriptable).
• Targeting is account-specific (Greg's UPN hammered globally), i.e. his address + likely an old password sit on a credential-stuffing list.

Did any attempt pass the password and get denied at MFA? — NO

Checked every sign-in's per-step authenticationStepResultDetail and the full error-code set across interactive + non-interactive logs (30d):

• Every attacker attempt resolved to "Incorrect password" / "Invalid username or password" at the password step. None reached the MFA step.
• Error codes on attack traffic: only 50126 (bad password) and 50053 (lockout caused by bad passwords).
• Zero MFA-stage codes (50074/50076/500121/50079) — i.e. no "password correct → MFA denied" event anywhere.
• 968 successful (err=0) authentications in 30d, all from Greg's own IPs (68.0.180.209 workstation + 2600:1011:* Verizon mobile). No successful auth from any attacker IP.

Conclusion: the password itself is holding — MFA was never even tested by the attacker. Greg's credential is not currently valid to the attacker (as opposed to "compromised but MFA-blocked").

Spray scale (context): sustained 2026-07-03 → 07-08 from ~20 countries (JP, HR, ES, HK, ZA, TW, RO, FI, SG, IE, GB, NL, SE, NO, RU, CA, NZ, US, …) via "Microsoft Online Services".

Why this is NOT a compromise

• 0 successful sign-ins from any non-Greg IP. All err=0 events originate from Greg's own IPs: 68.0.180.209 (US workstation) and 2600:1011:b077:... (US Verizon mobile), via legit apps (Outlook, Windows/Office services, Gmail mobile app).
• Security Defaults = ENABLED → MFA enforced tenant-wide + legacy auth blocked. A correct password guess still hits an MFA challenge to Greg's phone (+1 520…, Tucson AZ — consistent).
• Inbox rules (3): benign — all sort Alignable (small-business networking) mail into folders. No forward/delete/external-redirect, no hidden rules.
• OAuth grants (1): benign — "Gmail" app (EAS.AccessAsUser.All + offline_access), consented 2022-10-15, only ever used from Greg's US IPs = Greg's own phone Gmail app pulling his mailbox.
• No malicious forwarding, mailbox delegates, SendAs, or app-role grants.

Recommendations

1. Reset Greg's password (precautionary, recommended) — his account is being sprayed globally, so his credential is likely on a breach/stuffing list. Rotate to a strong unique password.
2. Revoke sessions after the reset (invalidateAllRefreshTokens) — standard hygiene; low risk (only legit tokens observed).
3. Confirm the MFA phone +1 520… is Greg's and under his control.
4. Security Defaults is already on — the correct baseline for a no-premium tenant. No CA change required. (Optional future: Entra ID P1 for named-location/geo-block Conditional Access if spray volume persists.)
5. No action needed on the failing spray traffic itself — smart lockout + MFA are handling it.

Coverage limitations

• Tenant has no Entra ID Premium (P1/P2) — tenant-wide sign-in logs and Identity Protection (risky users) are unavailable; per-user interactive + non-interactive sign-in logs (used above) remain accessible.
• AuditLog.Read.All (userRegistrationDetails) and SharePoint (Sites.Read.All) scopes not held by the suite in this tenant — not required for this assessment.