claudetools/clients/cascades-tucson/reports/2026-04-20-eight-user-breach-check.md

Cascades Tucson — 8-User Breach Check (Read-Only)

Date: 2026-04-20 (UTC) Tenant: Cascades Tucson (cascadestucson.com, 207fa277-e9d8-4eb7-ada1-1064d2221498) Scope: Read-only breach check across all 7 users targeted in Mike's 04-20 phishing sweep + JD Martin (named by Howard; previously a false-positive) App used: Legacy Claude-MSP-Access Graph API app (fabb3421-8b34-484b-bc17-e46de9703418). New tiered ComputerGuru Security Investigator app vault files do not yet exist in D:/vault/msp-tools/ — provision those before next run. Operator: Howard Enos (ACG-TECH03L) Posture: Investigate + document only. No remediation actions taken.

---

Per-User Verdicts

User	Verdict	Immediate action needed?
John Trozzi	CLEAN	No (re-confirms 04-20 AM check)
Megan Hiatt	CLEAN but actively attacked via SMTP AUTH	Yes — disable SMTP AUTH
Dax Howard	CLEAN, 1 disabled external-forward rule to verify	Clarify w/ Dax
Lois Lane	CLEAN	No
Meredith Kuhn	CLEAN, 1 dormant rule with attacker-signature name	Yes — delete .... rule
Anna Pitzlin	Account disabled/offboarded; stale risky-user record	Low — clean up Identity Protection
Ann Dery	CLEAN but no MFA, 0 recent sign-ins, stale risky-user record	Yes — enroll MFA or disable
JD Martin	CLEAN	No (confirms false-positive exclusion from sweep)

Bottom line: No active compromise on any of the 8 mailboxes. Two dormant concerns to resolve (Meredith's .... rule, Dax's disabled forward). Two account-hygiene gaps (Ann no-MFA, Anna stale offboarding state). One active attack vector that needs tenant-level control (SMTP AUTH credential stuffing against Megan).

---

10-Point Check Matrix

All checks per .claude/skills/remediation-tool/references/checklist.md. [OK] = within normal parameters, [!] = needs attention, [?] = ambiguous.

#	Check	John	Megan	Dax	Lois	Meredith	Anna	Ann	JD
01	Visible inbox rules (Graph)	0 OK	1 OK	3 OK	0 OK	3 OK	0 OK	0 OK	0 OK
02	Auto-reply	off	off	off	off	off	alwaysEnabled (legit offboarding)	off	off
03a	Hidden inbox rules (EXO REST)	1 system	4 OK	4 (1 flag)	1 system	6 (1 flag)	3 system	3 system	1 system
03b	Non-SELF mailbox permissions	0	0	0	0	0	0	0	0
03c	Non-SELF SendAs	0	0	0	0	0	0	0	0
03d	Mailbox forwarding fields	null	null	null	null	null	null	null	null
04a	OAuth grants	2 OK	4 OK	1 OK	0	2 OK	1 OK	2 OK	0
04b	App role assignments	1 (BlueMail)	3 (iOS/Alignable/Adobe)	3 (SurveyMonkey/Zoom/CalendarBridge)	0	2 (iOS/ReadMtg)	1 (Template.net [?])	1 (BlueMail)	0
05	Auth methods	5 (phone, Auth, FIDO2)	2 (pw, Auth)	2 (pw, Auth)	2 (pw, Auth)	2 (pw, Auth)	1 (pw only)	1 (pw only) [!]	2 (pw, Auth)
06	Interactive sign-ins 30d (non-US / legacy)	12 / 0 / 0	122 / 106 / 108	0 / 0 / 0	11 / 0 / 0	0 / 0 / 0	0 / 0 / 0	0 / 0 / 0	0 / 0 / 0
07	Directory audits 30d	41 (our 04-16 reset)	1	2	2	1	4	0	0
08	Risky user / detections	none / 0	none / 0	none / 0	none / 0	none / 0	low/atRisk stale 2023-11	low/atRisk stale 2020-12	none / 0
09	Sent items recent 25	normal	normal	normal	normal	normal	none post-disable	normal	normal
10	Deleted items recent 25	normal	normal	normal	normal	normal	none post-disable	normal	normal

No MFA-challenge, password-reset, sign-in-alert, or bounce-notification messages found in any Deleted Items across the 8 accounts (would indicate attacker cleanup). All legitimate sign-ins are from US IPs — for those who signed in interactively during the 30-day window.

---

Detailed Findings

1. John Trozzi — CLEAN (re-verified)

Matches Mike's 04-20 AM breach check. 12 interactive sign-ins all US/Phoenix (184.191.143.62). 5 auth methods (phone, 2x Authenticator, FIDO2). 41 directory audits — all from our 04-16 remediation cycle (password reset, disable/re-enable). Phishing emails from 04-20 were deleted in the sweep.

2. Megan Hiatt — CLEAN mailbox, ACTIVE credential-stuffing attack

Mailbox state: No malicious rules, no forwarding, no non-SELF delegates. 14 successful sign-ins all from her two known US IPs (184.191.143.62, 72.211.21.217) via Browser.

Active attack: 108 Authenticated SMTP sign-in attempts over 30 days, geographically distributed:

Country	Attempts	Failure codes
GB (UK)	48	50053 (smart lockout)
DE (Germany)	30	50053
NL (Netherlands)	18	50053
LT (Lithuania)	6	50053 / 50126 (bad password)
CH (Switzerland)	4	50053
US	2	50053

Every single attempt failed. Smart lockout (50053) triggered repeatedly — Entra is correctly blocking. BUT: if the attacker ever guesses a correct password, SMTP AUTH bypasses MFA because it uses Basic Authentication. This is the highest-risk attack surface still exposed on this tenant.

3. Dax Howard — CLEAN, dormant external-forward rule

3 inbox rules total:

• Two "Arizona ALFA" rules forwarding newsletters from info+azalfa.org@ccsend.com (Constant Contact) to Meredith Kuhn — legitimate business. Duplicate (one is (1)) — consolidation opportunity, not a security issue.
• One disabled rule "Copy of which is a meeting invitation or update" forwarding meeting requests to dax@megaloscapital.com. Currently OFF. megaloscapital.com is Megalos Capital — likely Dax's personal/other-company email. Needs user confirmation.

0 interactive sign-ins in 30d, auth methods include Authenticator but with createdDateTime: null (possible duplicate-entry pattern like John had). Authenticator creation date null is low-risk but worth cleaning up.

4. Lois Lane — CLEAN

No custom rules. 11 interactive sign-ins all US. 2 auth methods (password, Authenticator). No anomalies.

5. Meredith Kuhn — CLEAN, DORMANT attacker-signature rule

Primary flag — rule named ....:

• Disabled (Enabled: false)
• Action: mark as read, move to RSS Subscriptions, stop processing more rules
• No From / SubjectContainsWords filter — applies to everything if re-enabled
• Owner: meredith.kuhn
• Priority: 3

This matches the textbook attacker-persistence pattern (short-or-blank name, silent move to obscure folder, stop further processing). BUT it is disabled. Get-InboxRule doesn't return creation date, so we can't confirm whether this was ever active or when it was turned off. Two possibilities:

• (A) Someone (Meredith, prior IT) found it and disabled it but didn't delete it.
• (B) Meredith created it herself and gave up on it — Outlook occasionally ships templates that can produce odd-named rules.

Either way, leaving it in place is a latent risk: if her account is ever compromised, re-enabling it is one click away. Recommend deleting it outright after confirming with Meredith she didn't create it.

Other 5 hidden rules: system defaults (Junk, 2 disabled OOF templates) + two disabled legitimate rules (support@focushr.net, results@j2labs.com).

6. Anna Pitzlin — ACCOUNT DISABLED (offboarded)

• accountEnabled: false
• lastPasswordChangeDateTime: null
• Auto-reply set to "We regret to inform you that Anna Pitzlin is no longer employed here. Please direct any future correspondence to Meredith Kuhn." (effective 04-20 18:00 UTC → 04-21 18:00 UTC; almost certainly configured then left indefinitely with a non-terminal schedule)
• Risky-user record: low / atRisk, last updated 2023-11-16 — this is stale. Identity Protection never cleared the signal after offboarding.

Anna received 2 phishing emails in the 04-20 sweep because the account is still licensed and accepting inbound mail for the auto-reply. Not a compromise vector (no interactive auth possible, no MFA method configured, password disabled). The stale atRisk signal is noise.

Side issue: Verify with Mike whether Anna should be converted to a shared mailbox (cheaper, no license) or fully deleted after the retention window expires. Keeping a disabled user account licensed just to run an auto-reply is not standard.

7. Ann Dery — CLEAN mailbox, unused/unprotected account

• accountEnabled: true, lastPasswordChangeDateTime: null — account never had a password changed (implying it predates the forced-change policy or was exempted)
• Only 1 auth method: password. No MFA, no Authenticator, no FIDO2.
• 0 interactive sign-ins in 30d.
• Risky-user: low / atRisk, last updated 2020-12-07 — 5+ year old stale signal.
• 2 OAuth grants to BlueMail (same as John) — likely from original device pairing, dormant.

This is a dormant, enabled, non-MFA-protected account that received 2 phishing messages. If an attacker ever gets her password, there's no second factor to stop them. Recommend Mike confirm whether Ann still uses this account:

• If yes → enforce MFA enrollment
• If no → disable the account (don't delete — keep mailbox for historical access)

8. JD Martin — CLEAN

No custom rules, no forwarding, 0 non-SELF permissions, normal OAuth (none). Confirms JD was NOT targeted in the phishing campaign — his presence in the sweep was the false-positive HR-thread reply Mike correctly excluded. The HR thread from Ashley Jensen (HRPYDBRUNFOC...xlsx) was and remains legitimate internal payroll correspondence.

---

Why this keeps happening — root causes

Howard's question was "what can we do to prevent this." The phishing is landing because four layers of defense are not fully engaged:

Gap	Impact	Fix
DMARC is p=none	Receiving servers (Microsoft) have no instruction to junk/reject mail that spoofs cascadestucson.com. SPF fails silently, mail lands.	Publish p=quarantine pct=25 for 1 week → observe DMARC reports → p=reject. See _dmarc.cascadestucson.com TXT.
SMTP AUTH still enabled	Megan is being credential-stuffed daily across 5 countries. 108 attempts in 30d. An eventual guess bypasses MFA entirely.	Set-TransportConfig -SmtpClientAuthenticationDisabled $true (tenant-wide) + per-mailbox Set-CASMailbox -SmtpClientAuthenticationDisabled $true. Coordinate with any legacy scanners/MFPs on-site first.
No tenant-wide anti-impersonation/anti-phish policy tuned for cascadestucson.com	Lookalike-domain tricks (zoom.nl instead of zoom.us) and display-name spoofing get through.	Defender for Office 365 anti-phishing policy → add cascadestucson.com as protected domain + key users (Meredith, CEO/admin tier) as protected users. Requires Defender P1 or M365 Business Premium.
No URL/IP blocklist from this campaign	Same attacker infrastructure can hit again tomorrow on different users.	Exchange TABL: IP block 139.28.37.117, 104.168.101.10, 207.189.10.75, 91.244.70.212. URL block zoom.nl, *.awstrack.me.

User-level hygiene also matters:

• Ann Dery — no MFA method at all. If her account is active, enroll MFA today. If inactive, disable.
• Anna Pitzlin — offboard cleanup: convert to shared mailbox or remove license.
• Meredith Kuhn — delete the dormant .... inbox rule.
• Dax Howard — confirm the dax@megaloscapital.com external-forward rule is Dax's own, still disable/delete either way.
• Megan, Meredith, Ann, Anna — none have FIDO2 or hardware tokens. Authenticator-push is sufficient for most, but for Meredith (finance/admin role) consider FIDO2 like John has.

---

Prioritized Action List

P1 — Tenant-level prevention (highest leverage)

1. Publish DMARC p=quarantine pct=25 → 1 week observation → p=reject. Coordinate with Meredith and verify DKIM signing is healthy first. Blocks ~all external-hosting spoofs going forward.
2. Disable SMTP Client Authentication tenant-wide. Megan's active attack ends the moment this is off. Check first with Mike whether any on-site devices (copier, HR scanner) use SMTP AUTH to send — if so, migrate them to App Password / Modern Auth or SMTP relay.
3. Add TABL IP blocks + URL blocks from the 04-20 sweep (4 IPs + zoom.nl + *.awstrack.me).

P2 — User-level cleanup (read-only; ask before acting)

4. Delete Meredith's .... inbox rule after a 30-second confirmation with Meredith that she didn't create it.
5. Enroll Ann Dery in MFA (or disable account if she's no longer using it).
6. Clarify Dax's megaloscapital.com forwarding — delete the disabled rule regardless once confirmed benign.
7. Offboarding tidy-up for Anna Pitzlin — consider converting to shared mailbox; clear the stale atRisk signal.

P3 — Defensive posture

8. Defender for Office 365 anti-phishing policy for cascadestucson.com (needs SKU confirmation — does Cascades have M365 Business Premium or E3+Defender?).
9. Baseline sweep of remaining 38 mailboxes not hit this month (per sweep report recommendation — attackers may cycle to fresh targets).
10. Template.net OAuth grant (Anna Pitzlin) — publisher not verified. Low severity because account is disabled, but review if that app pattern appears on any active accounts during a re-sweep.

---

Raw Artifacts

All 8 users' raw JSON under:

/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/user-breach/{user}_cascadestucson_com/

Files per user:

• 00_user.json — profile
• 01_inbox_rules.json — Graph visible rules
• 02_mbox_settings.json — mailbox settings (auto-reply)
• 03a_hidden_rules.json — EXO Get-InboxRule with -IncludeHidden
• 03b_mbox_perms.json — Get-MailboxPermission
• 03c_recip_perms.json — Get-RecipientPermission (SendAs)
• 03d_mailbox.json — Get-Mailbox (forwarding fields)
• 04a_oauth.json — oauth2PermissionGrants
• 04b_approles.json — appRoleAssignments
• 05_auth_methods.json — authentication/methods
• 06_signins.json — 30d interactive sign-in log
• 07_audits.json — 30d directoryAudits where user is target
• 08a_risky.json — identityProtection/riskyUsers
• 08b_risk_det.json — identityProtection/riskDetections
• 09_sent.json — last 25 sentitems
• 10_deleted.json — last 25 deleteditems

Tooling notes for next session

• Fixed in this session: user-breach-check.sh referenced old tier names graph/exchange; updated to investigator/investigator-exo to match the rewritten get-token.sh.
• Not fixed: the new tiered app vault files (computerguru-security-investigator.sops.yaml et al) do not exist at D:/vault/msp-tools/. The skill's new 5-app architecture is not provisioned yet. This session fell back to inline curl calls using the legacy Claude-MSP-Access app. Mike should provision the new vault files before retiring the legacy app.