claudetools/clients/cascades-tucson/reports/2026-04-17-breach-check-megan-hiatt.md

Breach Check — megan.hiatt@cascadestucson.com + tenant sweep

Date: 2026-04-17 Tenant: Cascades of Tucson (cascadestucson.com, 207fa277-e9d8-4eb7-ada1-1064d2221498) Subject: Megan Hiatt + all 46 enabled mailboxes Tool: Claude-MSP-Access / ComputerGuru - AI Remediation (App ID fabb3421-8b34-484b-bc17-e46de9703418) Scope: Read-only investigation. No remediation executed yet — pending user approval. Triggered by: Megan reported receiving an email "from herself" she did not send.

Summary

• Spoofed email identified. The "email from herself" is the phishing message FW: HR Documents – Approval Pending Review Ref/ID#: 0f70944da81f4cc4a095d339750bc709 7955433689, forwarded by Megan to info@azcomputerguru.com at 2026-04-17 17:37/17:38 UTC. Classic external spoof — attacker forged the From header to match her own address. The email was not sent from her account.
• Active credential-stuffing campaign against this mailbox. 119 failed sign-ins over 30 days from 7 foreign IPs across GB, DE, NL, CH, LT. Primary attacker IP: 80.94.92.102 (Belfast, GB). All 119 attempts blocked by Microsoft threat intel (error 50053, malicious IP).
• No compromise indicators. No malicious inbox rules, no forwarding, no non-SELF delegates/SendAs, no unfamiliar OAuth consents, no sign-ins from outside the US succeeded, no password change the user didn't initiate.
• MFA is working. Microsoft Authenticator registered on Megan's iPhone 13 since before the attack window.
• Legacy protocols on this mailbox are ENABLED (SMTP AUTH, IMAP, POP, EWS, ActiveSync) — this is the most important finding from a hardening standpoint and is how attackers can eventually bypass MFA if creds are ever captured.
• Tenant sweep clean. 46 enabled users. Only one other isolated probe (accounting@ from IN, 1 attempt, blocked). No suspicious B2B invites, consents, or role changes.

Target details — Megan Hiatt

Field	Value
UPN	megan.hiatt@cascadestucson.com
Display name	Megan Hiatt
Object ID	ab306d53-6d6c-4f8f-a982-f4f571722178
Account Enabled	true
Created	2018-08-19T06:51:55Z
Last Password Change	2026-02-18T16:30:24Z (~2 months ago)
Proxy addresses	megan.hiatt@cascadestucson.com (primary), megan.hiatt@NETORGFT4257522.onmicrosoft.com

Per-check findings (Megan)

1. Inbox rules (Graph, visible)

1 rule, clean. Cascade of Tucson — moves messages from web@cascadestucson.com to Inbox folder. No forward/redirect/delete actions. Benign user rule.

2. Mailbox settings / auto-reply

Auto-reply disabled. No forwarding flags at Graph level.

3. Exchange REST (hidden rules, delegates, SendAs, mailbox forwarding)

• 4 hidden rules, all benign:
  • Junk E-mail Rule (Microsoft system default, no actions)
  • Microsoft.Exchange.OOF.InternalSenders.Global (disabled, system)
  • Microsoft.Exchange.OOF.KnownExternalSenders.Global (disabled, system)
  • Cascade of Tucson (user rule — same as visible; moves from web@cascadestucson.com to Inbox)
• Mailbox permissions: 0 non-SELF entries. No delegates.
• SendAs permissions: 0 non-SELF entries.
• Forwarding: ForwardingAddress=null, ForwardingSmtpAddress=null. Not forwarding.

4. OAuth consents + app role assignments

4 OAuth grants, all consistent with normal user activity over several years:

Client ID	Scope	Consent type	Assessment
ba93b9c1-1762-4136-8ff5-4f467a60207d	User.Read	Principal	Outlook Mobile (Microsoft first-party, Accompli)
ba93b9c1-1762-4136-8ff5-4f467a60207d	full_access_as_user (O365 Exchange)	Principal	Outlook Mobile
9f08ec8b-740f-4cbc-b0cb-901db88bda57	email offline_access openid profile	Principal	Third-party SSO login (standard OIDC scopes only)
24f0d580-56c3-4cb2-9bec-aa53cd974a4b	offline_access Contacts.Read	Principal	Third-party — Contacts.Read scope worth reviewing with user

App role assignments (SSO sign-ins): iOS Accounts (2018), Alignable (2021), Adobe Identity Management OIDC (2024). All dates predate attack window.

5. Authentication methods

• passwordAuthenticationMethod
• microsoftAuthenticatorAuthenticationMethod — registered device: iPhone 13

Both predate the 30-day attack window (no new method added during the attack). MFA coverage confirmed.

6. Sign-ins (last 30 days, interactive)

Total: 137 attempts. Breakdown by outcome:

Error code	Count	Meaning
0 (success)	16	All from US (Phoenix/Scottsdale/Glendale, AZ)
50053 (blocked)	119	Blocked because source IP flagged as malicious
50126 (invalid creds)	2	Bad password

Legitimate sign-ins (all 16 success events): IPs 184.191.143.62 and 72.211.21.217, US/Phoenix/Scottsdale/Glendale, Windows 10 + Edge 146–147, apps: One Outlook Web / OfficeHome / SharePoint Online. This is Megan.

Malicious sign-in attempts — countries & attacker IPs:

Country	Attempts
GB (Belfast)	48
DE	36
NL	19
CH	10
LT	6

Primary attacker IP observed on 2026-04-16 between 16:00–16:01 UTC: 80.94.92.102 (GB, Belfast), attempting Office 365 Exchange Online. Microsoft blocked every attempt.

7. Directory audits (30d targeting Megan)

0 entries. No admin touched her account, no password reset, no method change initiated by another principal.

8. Risky users / risk detections

Call returned Forbidden — the remediation tool's Entra app does not have IdentityRiskyUser.Read.All consented for this tenant. Gap, not a red flag.

9. Sent items (recent 25)

Reviewed all 25 recent sent messages. All are normal business correspondence: Matt.Hermes@kold.com (Fair Tix, digital stats), partnersuccess@caring.com, accounting@cascadestucson.com, crystal.rodriguez@cascadestucson.com, meeting RSVPs, Cascade-internal messages. Top two entries (2026-04-17 17:37 and 17:38) are Megan forwarding the phishing email to info@azcomputerguru.com (and info@azcomputeguru.com — typo, bounced back) asking for help. No blast-send, no external exfil pattern.

10. Deleted items (recent 25)

Routine newsletter/marketing deletions (Frys, Facebook updates, argentum.org, modernpostcard, appfolio). Only noteworthy deleted item: the postmaster bounce from the typo'd azcomputeguru.com send — consistent with Megan trying to forward to us.

Tenant sweep (all cascadestucson.com mailboxes, 30d)

Enabled user count: 46

P1 — Foreign failed sign-ins

User	Attempts	Unique IPs	Countries	First	Last
megan.hiatt	119	7	CH, DE, GB, LT, NL	2026-03-18	2026-04-16
accounting	1	1	IN	2026-03-25	2026-03-25

P1 — Successful foreign sign-ins

None. No mailbox in the tenant has had a successful login from outside the US in the 30-day window. No one else is compromised at the auth layer.

P2 — B2B guest invites (30d)

Date	Inviter	Target	Result
2026-04-14	lauren.hasselman@cascadestucson.com	dunedolly21@gmail.com	success
2026-03-31	lois.lane@cascadestucson.com	eugenie.nicoud@helpany.com	success

Both appear legitimate but confirm with the inviters — personal gmail invites are a known persistence mechanism.

P3 — Consent / role / auth method changes

All entries are expected: Microsoft Defender/Universal Print/Windows Update SPs auto-provisioning, PowerApps Service principals, and sysadmin@cascadestucson.com onboarding the ComputerGuru - AI Remediation app (our tool) on 2026-03-31 and 2026-04-16. No unauthorized end-user consent events.

Suspicious items (flagged)

• SMTP AUTH enabled on megan.hiatt mailbox (SmtpClientAuthenticationDisabled: false). Combined with IMAP/POP/EWS/ActiveSync all enabled. Credential-stuffing campaigns exist specifically to feed legacy auth endpoints that do not always enforce modern MFA. Recommend disabling all legacy protocols on her mailbox immediately.
• OAuth grant to 24f0d580-56c3-4cb2-9bec-aa53cd974a4b with Contacts.Read — unresolved app identity. Low risk (read-only, no Mail scope) but worth asking Megan what this is and revoking if unrecognized.
• Active/ongoing attacker interest — Megan specifically is being targeted across 7 distinct European/UK IPs. Even though MFA is holding, rotate the password to invalidate anything she may have typed into the phishing page. We don't know what the HR-Documents phish was actually asking for.

Gaps — checks not completed

• Risky user / risk detections blocked. Forbidden on /identityProtection/riskyUsers. To enable:
  1. Portal → Entra admin center → Enterprise applications → ComputerGuru - AI Remediation → Permissions → Grant admin consent for IdentityRiskyUser.Read.All (scope already in manifest).
• Unified Audit Log (Purview) not pulled. This tool does not access UAL. If we need a definitive timeline of mailbox operations (message opens, downloads, exports) for incident documentation, escalate to Purview Content Search.

Recommended remediation actions

Presented in two tiers. Actions require explicit YES in chat before execution — nothing below has been performed yet.

Tier 1 — do now (lockdown Megan)

1. Reset Megan's password (forcing change on next sign-in). Kills any stolen credential.
2. Revoke all refresh tokens / sign-in sessions for Megan. Forces every device (phone, PC, browser) to re-authenticate with the new password + MFA.
3. Disable SMTP AUTH + IMAP + POP on Megan's mailbox. Removes the legacy-auth MFA bypass avenue the attacker is clearly probing for.
4. (Optional, if user prefers belt-and-suspenders) Temporarily block sign-in on Megan's account until she is reachable to reset password in her presence.

Tier 2 — hardening (tenant-wide, recommend scheduling)

5. Disable SMTP AUTH tenant-wide at the OrganizationConfig level (Set-OrganizationConfig -SmtpClientAuthenticationDisabled $true). Review any service accounts (scan-to-email, line-of-business apps) that may still rely on it first.
6. Conditional Access: geo-block (US-only sign-in, or require approved devices outside US). The attack volume on Megan justifies this.
7. Confirm the 2 B2B guest invites with Lauren Hasselman and Lois Lane. Personal-gmail targets merit a human sanity check.
8. Grant IdentityRiskyUser.Read.All admin consent so future investigations get Entra's risk signals (see Gaps).
9. User-security training refresher — Megan should be commended for escalating the phishing to us; reinforce the behavior.

Remediation actions executed

2026-04-17 17:55 UTC — Antispam hardening (tenant Default policy)

Executed:

Set-HostedContentFilterPolicy -Identity Default
  -MarkAsSpamSpfRecordHardFail On
  -MarkAsSpamFromAddressAuthFail On

Before / After:

Setting	Before	After
MarkAsSpamSpfRecordHardFail	Off	On
MarkAsSpamFromAddressAuthFail	Off	On

Any future inbound message with a hard SPF fail or a From-address authentication failure against any recipient in the tenant will now be routed to Junk automatically, independent of the sender domain's DMARC policy.

2026-04-17 17:55 UTC — Anti-phish hardening (tenant Default policy)

Executed:

Set-AntiPhishPolicy -Identity "Office365 AntiPhish Default"
  -EnableMailboxIntelligenceProtection $true
  -MailboxIntelligenceProtectionAction Quarantine
  -EnableFirstContactSafetyTips $true
  -PhishThresholdLevel 2

Before / After:

Setting	Before	After
EnableMailboxIntelligenceProtection	false	true
MailboxIntelligenceProtectionAction	NoAction	Quarantine
EnableFirstContactSafetyTips	false	true
PhishThresholdLevel	1 (Standard)	2 (Aggressive)
HonorDmarcPolicy	true (unchanged)	true
EnableSpoofIntelligence	true (unchanged)	true

Result: Microsoft Defender for Office 365 will now actively detect and quarantine messages that impersonate users in the tenant or Megan's frequent contacts. The "You don't often get email from this sender" banner will appear for first-time senders. The phishing-detection threshold is raised one level.

Note on the Standard Preset Security Policy: Creation of the Standard/Strict preset requires a one-time Microsoft-side bootstrap that only happens when an admin opens Defender portal → Email & Collaboration → Policies → Preset Security Policies and toggles Standard on. The REST API cannot create the preset from scratch — it can only scope existing preset policies, and none exist yet in this tenant. Recommendation: Mike or Howard opens https://security.microsoft.com/presetSecurityPolicies and toggles Standard to On for "All recipients." The settings we've applied to the Default policies above are the same key values the preset would set, so there is no immediate protection gap — the preset is best-practice baseline alignment that Microsoft updates over time.

2026-04-17 17:43 UTC — Legacy protocols disabled on Megan's mailbox

Executed against megan.hiatt@cascadestucson.com:

Set-CASMailbox -Identity megan.hiatt@cascadestucson.com
  -SmtpClientAuthenticationDisabled $true
  -ImapEnabled $false
  -PopEnabled $false

Before:

SmtpClientAuthenticationDisabled: false
ImapEnabled: true
PopEnabled: true

After (verified):

SmtpClientAuthenticationDisabled: true
ImapEnabled: false
PopEnabled: false

ActiveSync, OWA, MAPI, EWS remain enabled (those are modern-auth capable). This removes the primary basic-auth paths that could bypass MFA.

---

Phishing message forensic analysis — "HR Documents – Approval Pending Review"

Message identification

Field	Value
Original Message-ID	<f22d03d2-7140-7827-6261-f32155e8792a@cascadestucson.com> (spoofed)
Microsoft Network-Message-Id	4d99782d-3416-4b42-fd0b-08de9ca1f095 (useful for Purview / eDiscovery lookup)
Date sent	2026-04-17 16:54:05 UTC (09:54 Arizona time)
Subject	Re: HR Documents – Approval Pending Review Ref/ID#: 0f70944da81f4cc4a095d339750bc709 7955433689
From header	megan.hiatt@cascadestucson.com (spoofed)
Envelope / Return-Path	megan.hiatt@cascadestucson.com (spoofed)
To	megan.hiatt@cascadestucson.com
HTML title	Payment Request
Attachments	None (inline images only)
Location in mailbox	Deleted Items (Megan deleted it after forwarding to info@azcomputerguru.com)
Raw MIME saved	/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/phish/original.eml (282 lines)

Where the message actually came from

Received: from [127.0.0.1] (91.244.70.212) by BN2PEPF000044A9.mail.protection.outlook.com
X-Forefront-Antispam-Report: CIP:91.244.70.212 ; CTRY:AT ; PTR:customer.evolus-ix.com ; HELO:[127.0.0.1]

• Source IP: 91.244.70.212
• Country: AT (Austria)
• PTR / reverse DNS: customer.evolus-ix.com (Evolus IX, Austrian ISP — ASN 34321) — a customer-leased IP, not a mail service provider
• HELO banner: [127.0.0.1] — fraudulent; sender claimed "localhost"
• TLS: TLS 1.3 AES-256-GCM used (modern encryption, but that just means the attacker has a reasonably competent mailer)

The 91.244.70.0/24 block is not the same attacker as the credential-stuffing IPs (80.94.92.x GB, DE/NL/CH/LT) — this is a separate infrastructure, which is consistent with the two-stage pattern: phish from one set of hosts, credential-stuff (testing captured creds) from another.

Email authentication verdict

Authentication-Results:
  spf=fail (sender IP is 91.244.70.212) smtp.mailfrom=cascadestucson.com
  dkim=none (message not signed) header.d=none
  dmarc=fail action=none header.from=cascadestucson.com
  compauth=pass reason=703

Check	Result	What it tells us
SPF	FAIL	91.244.70.212 is not in cascadestucson.com's SPF record (current SPF: v=spf1 ip4:72.194.62.5 include:spf.protection.outlook.com -all). SPF was configured correctly and it did its job.
DKIM	none	Message carried no DKIM signature. The attacker never attempted to sign it (and couldn't, without the domain's private key).
DMARC	FAIL	Both SPF and DKIM alignment failed. But action=none — Microsoft's DMARC enforcement was instructed by the DOMAIN OWNER's own DMARC policy to take no action.
compauth	pass (reason=703)	Microsoft's composite heuristic ("does this message look bad based on content + history?") voted Pass. Reason code 703 = "not phishy by content heuristics." This overrode the auth failures in delivery.
SCL	1	Spam Confidence Level 1 — below the 5 threshold that would move to Junk.

The malicious link

The body contains one user-facing call to action ("Review Document →") that chains through URL shields to disguise the destination:

linklock.titanhq.com/analyse
  ↳ url-shield.securence.com (r=oramirez@ymflawllp.com, sid=1776430900850-010-00062214)
    ↳ secure-web.cisco.com (base64-obfuscated cisco secure-email-gateway wrapper)
      ↳ td.viewydigital.com/gin/index.html  ← final destination (credential-harvest page)

The URL has a query-string parameter ?a38372829=bWVnYW4uaGlhdHRAY2FzY2FkZXN0dWNzb24uY29t. Base64-decoded: megan.hiatt@cascadestucson.com. The phishing page pre-fills her email address so the victim only has to enter a password — a hallmark of modern AitM (Adversary-in-the-Middle) phishing kits (e.g., EvilProxy, Tycoon 2FA).

Observations:

• oramirez@ymflawllp.com (Ortega Ramirez at YM Flaw LLP) appears in the URL shield parameters — this is a reused / hijacked URL rewrite from a legitimate email originally sent to that recipient. The attacker likely has access to a mailbox that received a URL-shielded Securence message and is repackaging that shielded URL to ride its reputation.
• The final destination td.viewydigital.com is an attacker-controlled domain hosting the AitM phishing page. viewydigital.com looks like a lookalike of design/marketing tool brands; should be reported to MDO/SmartScreen and blocked at Safe Links.
• No attachment — attacker relies entirely on URL click.

Why Microsoft delivered it

Four controls all leaned permissive at the same time. Each one alone could have been the stop:

1. Domain DMARC policy is p=none. Current _dmarc.cascadestucson.com TXT record: v=DMARC1; p=none; pct=100; rua=mailto:info@cascadestucson.com; ruf=mailto:info@cascadestucson.com; ri=86400; fo=1;. p=none = monitor only, do not quarantine or reject.
2. Anti-spam MarkAsSpamSpfRecordHardFail is Off. SPF hard-fail is a reliable phishing signal and flipping this to On would have sent the message to Junk.
3. MDO Anti-Phish EnableMailboxIntelligenceProtection is false with action NoAction. This is the feature designed to catch exactly this pattern — "email appears to come from a user in your own tenant / from yourself / from someone you communicate with regularly." It's off.
4. MDO Anti-Phish EnableFirstContactSafetyTips is false. The banner that reads "You don't often get email from this sender" would have been a tip-off for Megan.

Note that HonorDmarcPolicy: true is already set on the Anti-Phish policy. That means as soon as the domain's DMARC policy is tightened, Microsoft will start enforcing. The ball is in the domain owner's court.

Note also that DKIM signing IS enabled and valid for cascadestucson.com (both selectors). Legitimate outbound mail from the tenant will continue to pass DMARC at receiving servers if DMARC is tightened.

Prevention plan (to stop this from happening again)

Ordered by impact-per-effort. Items 1–3 would have stopped the specific HR Documents phish; the rest harden the broader surface.

Tier A — fix the four gaps that let this one through (do this week)

#	Control	Exact change	Impact
A1	DMARC policy	Update DNS record _dmarc.cascadestucson.com TXT from p=none → p=quarantine; pct=100; fo=1; rua=mailto:info@cascadestucson.com; ruf=mailto:info@cascadestucson.com; ri=86400;. After 2 weeks of clean rua reports, advance to p=reject.	Any future forged @cascadestucson.com mail auto-lands in Junk (quarantine) or bounces (reject). Would have stopped this phish at delivery.
A2	Anti-spam: SPF hard-fail	Set-HostedContentFilterPolicy -Identity Default -MarkAsSpamSpfRecordHardFail On	Even with DMARC at p=none, SPF hard-fails get routed to Junk.
A3	Anti-spam: auth-fail	Set-HostedContentFilterPolicy -Identity Default -MarkAsSpamFromAddressAuthFail On	Any From-address auth failure routed to Junk.
A4	Anti-Phish: mailbox intelligence protection	Set-AntiPhishPolicy -Identity "Office365 AntiPhish Default" -EnableMailboxIntelligenceProtection $true -MailboxIntelligenceProtectionAction Quarantine -EnableFirstContactSafetyTips $true -PhishThresholdLevel 2	MDO actively flags messages that impersonate your own users / frequent contacts, quarantines them, and shows the first-contact banner on unknown senders.

After A1 is live for ≥2 weeks without clean-mail hits, tighten further:

• p=quarantine → p=reject on DMARC
• PhishThresholdLevel 2 (Aggressive) → 3 (More Aggressive) if false-positive rate is tolerable

Tier B — Defender for Office 365 "Strict preset" (10 minutes, tenant-wide)

Microsoft ships pre-built policy bundles that embody current best practice. Assign the Standard (or Strict) preset to all users:

1. Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Preset Security Policies.
2. Turn on Standard protection (or Strict) → apply to "All recipients" for all six policy types (anti-phish, anti-spam, anti-malware, Safe Links, Safe Attachments, user impersonation).
3. The preset overrides the custom-tuned "Default" policies with Microsoft's current best values. This is the fastest way to close multiple gaps at once.

Tier C — identity + endpoint hardening (next 30 days)

#	Control	Purpose
C1	Conditional Access: US-only sign-in (or require compliant/hybrid-joined device from foreign geos)	Breaks the credential-stuffing playbook entirely. 119 attempts from EU would never have reached the auth endpoint.
C2	Tenant-wide SmtpClientAuthenticationDisabled=$true at the OrganizationConfig level (after inventorying scan-to-email/LOB senders)	Eliminates basic auth as a tenant-wide MFA bypass vector. We've already done this for Megan's individual mailbox.
C3	Disable POP/IMAP tenant-wide — same inventory caveat	Same rationale.
C4	Enable Unified Audit Logging (if not already on) and retain for 1 year	Purview Content Search / eDiscovery needs this. Essential for any future incident that needs message-level timeline reconstruction.
C5	Grant IdentityRiskyUser.Read.All admin consent to the ComputerGuru - AI Remediation app	Lets this tool pull Entra's risky-user signal on future investigations.
C6	Bitdefender / EDR deployment on Megan's workstation + any other frontline mailbox	Stops post-credential-compromise tooling (token stealers, cookie dumpers) even if a user does enter credentials on an AitM page.

Tier D — human layer (next 60 days)

#	Control	Purpose
D1	Praise Megan publicly for reporting this.	Reinforces reporting behavior. She is the control that worked today.
D2	Anti-phishing awareness refresh for Cascades staff — focus on: email-from-yourself spoofs, fake DocuSign/HR/signature-request lures, URL shield/redirector chains	Measured via a post-training phishing simulation.
D3	"Report Phishing" button (Outlook built-in or MDO Report Message add-in) deployed to all users	One click to submit to MS + IT. Faster than Megan's current workflow of forwarding to info@azcomputerguru.com.
D4	Intake alias — consider phish@cascadestucson.com that forwards to us and auto-replies with "thanks, we've received it." Closes the loop for users.	Quality-of-life.

Tier E — offensive cleanup of this specific campaign

#	Action	Who
E1	Submit td.viewydigital.com and the final destination URL to Microsoft Defender Submissions (phish/malicious URL).	Us
E2	Add td.viewydigital.com and the staging IP 91.244.70.212 to Tenant Allow/Block List as blocked.	Us
E3	Check MDO → Explorer → "Phish" view for any OTHER users in the tenant who received mail from 91.244.70.212 in the past 7 days (this tool can't query Explorer — do in portal).	Us
E4	Notify ymflawllp.com (Ortega Ramirez) that their URL shield output appears to have been captured and is being repurposed in phishing campaigns. They may have a compromised mailbox of their own.	Us, courteously

Raw artifacts (phishing investigation)

/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/phish/:

• search.json — mailbox search for "HR Documents"
• original.eml — raw MIME of the original phishing message (282 lines, includes full Received: chain)
• forward.eml — Megan's forward to info@azcomputerguru.com (raw MIME)
• forward_body.json — plain-text body of the forward

Data artifacts

Raw JSON at /tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/:

• user-breach/megan_hiatt_cascadestucson_com/00_user.json .. 10_deleted.json
• user-breach/megan_hiatt_cascadestucson_com/03a_InboxRule_hidden.json .. 03d_Mailbox.json
• sweep/users.json, failed_signins.json, success_signins.json, success_nonus.json, dir_audits.json, risky_users.json, guest_invites.json

Keep these until the incident ticket is closed.