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)