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