# 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.
