claudetools/clients/cascades-tucson/reports/2026-04-16-john-breach-check.md

# John Trozzi - Credential Stuffing Breach Check

**Date:** 2026-04-16
**Tenant:** Cascades Tucson (cascadestucson.com, 207fa277-e9d8-4eb7-ada1-1064d2221498)
**User:** John Trozzi (john.trozzi@cascadestucson.com, a638f4b9-6936-4401-a9b7-015b9900e49e)
**Tool:** Claude-MSP-Access Graph API (remediation tool)

## Summary

- **No breach artifacts detected** — across 9 of 10 planned checks (Exchange REST now working). Mailbox is clean: no hidden rules, no delegates, no forwarding, no SendAs grants, no new OAuth consents, no new auth methods, no foreign-geo sign-ins, no anomalous sent/deleted items.
- Sign-in history (last 30d visible via v1.0): **11 sign-ins, 100% from 184.191.143.62 (Phoenix, AZ — Cox local IP)**. Only 1 failure (benign "Keep me signed in" interrupt).
- Directory audit shows clean IR sequence by sysadmin@cascadestucson.com: disable -> reset password -> enable. John then self-changed password at 16:04:46 UTC.
- **1 check still blocked**: Identity Protection (Risky Users / Risk Detections) — IdentityRiskyUser permission exists in app manifest but was not granted in the re-consent attempt. See Gap #2.
- **Confirm target:** We investigated John **Trozzi** (only John in tenant). If the victim is a different John, re-run.

## John's Account

| Field | Value |
|-|-|
| UPN | john.trozzi@cascadestucson.com |
| Object ID | a638f4b9-6936-4401-a9b7-015b9900e49e |
| Account Enabled | true |
| Created | 2022-02-18T18:31:39Z |
| Last Password Change | **2026-04-16T15:45:55Z** (sysadmin reset), then 2026-04-16T16:04:46Z (John self-change) |

## Per-Check Findings

### 1. Inbox Rules (Graph v1.0) - CLEAN
`/users/{upn}/mailFolders/inbox/messageRules` -> `value: []` (no rules).
Note: this endpoint does NOT show hidden rules. See Gap #1 below.

### 2. Mailbox Forwarding / Settings - CLEAN
- User object: no `forwardingSmtpAddress`, no `forwardingAddress`.
- mailboxSettings: no forwarding configured.
- Auto-reply: **status=disabled** (off); scheduled 2026-04-16 16:00 UTC to 2026-04-17 16:00 UTC but reply bodies empty. Likely residual stub or John preparing OOO. Not active.

### 3. Delegates / Mailbox Permissions / Hidden Rules (Exchange REST) - CLEAN (after role assigned)
After Exchange Administrator role was granted to ComputerGuru - AI Remediation SP at ~16:35 UTC:

- **Get-InboxRule -IncludeHidden**: 1 rule found — "Junk E-mail Rule" (system default). No Forward/Redirect/Delete/Move actions. **CLEAN.**
- **Get-MailboxPermission**: only `NT AUTHORITY\SELF` (FullAccess+ReadPermission) — the owner. **No external full-access delegates.**
- **Get-RecipientPermission** (SendAs): only `NT AUTHORITY\SELF`. **No external SendAs.**
- **Get-Mailbox** forwarding fields:
  - ForwardingAddress: null
  - ForwardingSmtpAddress: null
  - DeliverToMailboxAndForward: false
  - GrantSendOnBehalfTo: []
  - HiddenFromAddressListsEnabled: false
  - WhenChanged: 2026-04-16T16:05:31Z (recent — likely from the password reset / session revoke)
- **CLEAN** at mailbox level.

### 4. OAuth Consents + App Role Assignments - CLEAN
Single user-consented app:
- **BlueMail** (3508ac12-63ff-4cc5-8edb-f3bb9ca63e4e)
  - Scope 1: `User.Read` (on Microsoft Graph)
  - Scope 2: `EAS.AccessAsUser.All Exchange.Manage` (on Office 365 Exchange Online, 072df88c-...)
  - App role assignment created **2022-02-18T21:59:50Z** (same day as account creation — longstanding, legitimate)
- No new consents in attack window.

### 5. Authentication Methods - CLEAN
| Method | Created | Notes |
|-|-|-|
| Password | 2026-04-16T15:45:55Z | Reset today (expected) |
| Phone +1 5203658200 (mobile) | unknown (old) | |
| MS Authenticator - Samsung SM-F731U | 2026-02-12T01:25:40Z | Pre-attack |
| MS Authenticator - SM-F731U (SoftwareToken) | null | Old |
| FIDO2 "Authenticator: Default Profile" (Android) | 2026-02-12T01:23:45Z | Pre-attack |

All non-password methods predate the attack window. **Attacker did not register a new auth method.**

### 6. Sign-Ins (v1.0 - interactive only) - 30-day window - CLEAN
- Count: 11
- Unique IPs/geos: **only 184.191.143.62 / Phoenix, AZ, US** (Cox Communications, local)
- Failures: 1 (errorCode 50140, KMSI interrupt - benign)
- Apps: Microsoft Authentication Broker, Microsoft Office, My Profile, My Signins, Microsoft Account Controls V2
- No anomalous client apps (no IMAP/POP/legacy)

Note: v1.0 `/auditLogs/signIns` shows interactive sign-ins only. Non-interactive / service-principal sign-ins would require `/beta/auditLogs/signIns?$filter=signInEventTypes/any(t:t eq 'nonInteractiveUser')`. Not fetched in this pass.

### 7. Directory Audits (targetResources = John) - CLEAN
31 events, all 2026-04-16. Timeline:
- 15:41:46 -> 15:41:52: sysadmin disables account (initial IR)
- 15:44:06 -> 15:44:19: enable / disable cycle (sysadmin)
- 15:45:55: **Reset user password** by sysadmin + token refresh invalidation
- 15:47:36 -> 15:47:42: enable account, updates
- 15:53:52: Azure MFA StrongAuthenticationService update (MFA state)
- 16:04:46: **User changed password** (John self-change post-reset)

All initiators are `sysadmin@cascadestucson.com`, `Azure MFA StrongAuthenticationService`, `Microsoft Substrate Management`, or John himself. **No unauthorized changes.**

### 8. Risky Users / Risk Detections - BLOCKED (403)
`/identityProtection/riskyUsers` and `/identityProtection/riskDetections` returned Forbidden. App is missing `IdentityRiskyUser.Read.All` Graph permission. See Gap #2.

### 9. Sent Items (last 25) - CLEAN
All legitimate business correspondence: vendor replies (door veneer, master plan, pool table lighting, Model 1 Commercial Vehicles), internal fwds to coworkers (accounting, frontdesk, lauren.hasselman). Most recent 2026-04-16T15:28 to wpeterson@unwiredengineering.com (legitimate vendor). **No unusual recipients, no blast/phishing patterns.**

### 10. Deleted Items (last 25) - CLEAN
Normal marketing/promo (Wayfair, BestBuy, Spotify, FloorAndDecor, Ring) + voicemails (8x8) + Zoom invites + legitimate business from arcstudiosinc.com. **Nothing security-relevant (no password-reset notices, no security alerts being hidden).**

## Gaps - Checks We Could Not Complete

### Gap #1: Exchange REST (403)
Cascades Tucson tenant does not have Exchange Administrator role assigned to Claude-MSP-Access SP. Missing checks:
- **Hidden inbox rules** (`Get-InboxRule -IncludeHidden` — attackers commonly create hidden rules that Graph v1.0 can't see)
- **Mailbox permissions / delegates** (attacker could have granted FullAccess or SendAs to an external/compromised account)
- **Mailbox-level forwarding flags** (`ForwardingAddress`, `ForwardingSmtpAddress`, `DeliverToMailboxAndForward`)

**Remediation:** In Entra portal > Roles and administrators > Exchange Administrator > Add "Claude-MSP-Access" service principal (App ID: fabb3421-8b34-484b-bc17-e46de9703418). Then re-run Check 3.

### Gap #2: Identity Protection (403)
App is missing `IdentityRiskyUser.Read.All` Graph permission. Missing checks:
- Risky user classification (low/medium/high/none)
- Risk detections (unfamiliar location, atypical travel, malware-linked IP, leaked credentials, password spray events)

**Remediation:** In Entra portal > App registrations > Claude-MSP-Access > API permissions > add `IdentityRiskyUser.Read.All` (application) + grant admin consent. Then re-run Check 8.

### Gap #3: Non-interactive sign-ins
v1.0 endpoint hides non-interactive and service-principal sign-ins. Attacker using refresh tokens or IMAP/SMTP would show up under `/beta/auditLogs/signIns` with `signInEventTypes` filter. Worth running once Gap #2 is resolved.

## Next Actions

1. **Confirm victim identity** — we investigated John **Trozzi**. Only one "John" in the tenant. If this is correct, proceed.
2. **Assign Exchange Administrator role** to Claude-MSP-Access in this tenant (5 min in Entra portal) so we can check hidden inbox rules + delegates — attackers' #1 persistence mechanism post-credential-stuffing.
3. **Add IdentityRiskyUser.Read.All** Graph permission to confirm Azure Identity Protection didn't flag John.
4. **Check the scheduled auto-reply** (16:00 UTC 04-16 to 16:00 UTC 04-17) with John — confirm he set it.
5. **Review Cascades Tucson Conditional Access policies** — session log 2026-04-01 noted 8 policies all enabled (MFA all users, legacy auth blocked). That's good defense; if credential stuffing targeted this tenant it likely bounced off MFA.
6. **Ask John** where he was when he noticed the breach signals (e.g., alert email, unfamiliar sign-in prompt). Origin of his suspicion may tell us whether the attack actually succeeded or was only attempted.
7. **Optional:** Pull `/beta/auditLogs/signIns?$filter=userId eq '<id>' and signInEventTypes/any(t:t eq 'nonInteractiveUser')` to cover non-interactive tokens.

## Tenant-Wide Findings (all 46 enabled accounts)

Expanded sweep 2026-04-16 ~16:45 UTC.

### PRIORITY: Megan Hiatt is under active credential-stuffing attack
- **126 failed sign-in attempts in last 30 days** — 8 unique IPs across CH, DE, GB, LT, NL, US
- Active TODAY: 23 failures at 15:58–16:01 UTC from **80.94.92.102 (Belfast, GB)** via **Authenticated SMTP** to Office 365 Exchange Online
- Earlier bursts: 2026-04-15 (Hamburg DE), 2026-04-13 (Belfast GB), and older activity noted in 2026-03-31 session log
- Block reason: "Sign-in was blocked because it came from an IP address with malicious activity" / account lockouts
- **Megan is NOT compromised** — every attempt blocked by IP reputation + MFA + account lockout. But:
  - **Password last changed 2026-02-18** (~2 months old — attackers clearly have a stale but valid credential or are brute-forcing)
  - Only 1 MFA method (MS Authenticator on iPhone 13)
  - Mailbox checks CLEAN: no inbox rules beyond default/system + 1 legitimate "Cascade of Tucson" folder-move rule, no forwarding, no delegates
  - Successful sign-ins all from AZ (Phoenix/Scottsdale/Glendale) — legitimate
- **Recommendations:**
  1. Force Megan password reset NOW (credential is known-targeted)
  2. Disable SMTP AUTH for Megan specifically (`Set-CASMailbox -SmtpClientAuthenticationDisabled $true`) — or tenant-wide
  3. Consider adding a tenant-wide CA policy blocking legacy auth (likely already in place per 2026-04-01 log)
  4. Monitor — attacker appears to retry in bursts every 1–3 days

### External guest invite: dunedolly21@gmail.com — likely legitimate, worth confirming
- Invited 2026-04-14 23:57 UTC by **lauren.hasselman@cascadestucson.com** (from her mobile, Phoenix IP)
- Accepted 2026-04-15 01:10 UTC
- No group memberships, no app role assignments — guest has no meaningful access
- Lauren's own sign-ins are clean (100% AZ, MFA via iPhone 16 Pro Max, password reset 2026-03-31)
- **Action:** confirm with Lauren why she invited "dunedolly21" gmail — likely her personal/vendor/family account, but validate

### Other accounts — clean
- **John Trozzi** — no foreign sign-ins, no breach artifacts (primary report above)
- **sysadmin@cascadestucson.com** — 17 "failures" are all benign: our own ComputerGuru-AI-Remediation consent flow errors (65001 not-consented, 50126 typos during onboarding) and one CA-policy MFA prompt. No attacker activity.
- **accounting@cascadestucson.com** — 1 isolated failure 2026-03-25 from Chennai, India (143.110.255.52), wrong password, never retried. Noise-level threat.
- **lois.lane, nurse, alyssa.brooks, christina.dupras, sharon.edwards, susan.hicks, karen.rossini, etc.** — only US-based failures, low counts, typical typos/MFA prompts. None show attacker patterns.

### Locations profile (successful sign-ins, 30d)
Every successful sign-in across all 46 accounts was from a US city in Arizona (Phoenix, Scottsdale, Glendale, Tucson) or one Bethlehem PA user (veronica.feller — remote worker). **Zero foreign successful sign-ins tenant-wide.**

### Directory audit signals - clean
- No unauthorized OAuth consents (the 4 "Consent to application" events today are our own ComputerGuru - AI Remediation re-consents)
- No unauthorized role assignments
- No new auth methods added outside expected MFA setup flows
- Microsoft system actors (Substrate Management, MFA StrongAuthenticationService, B2B Admin Worker) made routine updates

## Data Artifacts

Raw JSON responses saved under `/tmp/bc/`:
- 01_inbox_rules.json, 02a_user_obj.json, 02b_mailbox_settings.json
- 04a_oauth_grants.json, 04b_app_role_assignments.json, 05_auth_methods.json
- 06_signins.json (today only), 06b_signins30d.json
- 07_dirAudits.json, 08a_riskyUser.json (error), 08b_riskDetections.json (error)
- 09_sent.json, 10_deleted.json
- 03a_InboxRule.json, 03b_MbxPerm.json, 03c_Mailbox.json (all 403)