sync: auto-sync from ACG-TECH03L at 2026-04-17 11:26:41

Author: Howard Enos Machine: ACG-TECH03L Timestamp: 2026-04-17 11:26:41
2026-04-17 11:26:43 -07:00
parent ac4ceb65c0
commit 32888ea9d4
4 changed files with 484 additions and 0 deletions
--- a/.claude/memory/MEMORY.md
+++ b/.claude/memory/MEMORY.md
@@ -25,6 +25,7 @@
 - [ACG-5070 Workstation Setup](reference_workstation_setup.md) - Windows 11 Pro clean install 2026-03-30, replaced CachyOS. All tools installed.

 ## Project
+- [MasterBooter Side Project](project_masterbooter.md) — Howard's Rust+Slint Windows deployment toolkit at C:\MasterBooter, separate from client work. Do not log to clients/.
 - [Audio Processor Architecture](project_audio_processor_architecture.md) - Segment-first pipeline: detect breaks before transcription for complete content capture
 - [Neptune Email Routing Issues](project_email_routing_neptune.md) - Multiple clients (devcon, Sorensen/rieussetcorp) have email not routing properly from Neptune
 - [Neptune SBR Email Routing Setup](project_neptune_sbr_email_routing.md) - Full SBR routing chain, config file locations, MailProtector integration, access methods
--- a/.claude/memory/project_masterbooter.md
+++ b/.claude/memory/project_masterbooter.md
@@ -0,0 +1,31 @@
+---
+name: MasterBooter Side Project
+description: Howard's personal side project at C:\MasterBooter — Windows deployment toolkit, separate from client/MSP work. Do not mix with clients/ content.
+type: project
+---
+
+MasterBooter is Howard's personal Rust + Slint Windows deployment toolkit at `C:\MasterBooter`. Single-portable-EXE targeting IT/MSP/repair-shop techs. Four modes: Backup/Restore, Windows Deploy, WinPE Builder (WinRE-based), System Prep. Public GitHub repo: `Howweird/Masterbooter`.
+
+**Why:** Side project separate from Arizona Computer Guru client work. Howard is learning Rust through it — code is heavily commented by design. Not a commercial product yet, no paying customers.
+
+**How to apply:**
+- When Howard mentions MasterBooter, WinPE builder, winpe.rs, deploy.rs, etc., context is `C:\MasterBooter`, NOT the `clients/` folder in ClaudeTools.
+- Don't log MasterBooter sessions to `clients/` — they are personal project work, not customer engagements.
+- Project has its own `C:\MasterBooter\CLAUDE.md` with its own rules. Follow those when in that directory.
+- Heavy comments are intentional (learning), not tech debt.
+
+**Key docs in C:\MasterBooter:**
+- `VISION.md` — goals, 4 modes
+- `REQUIREMENTS.md` — feature tracking (sections 1-10 complete, Section 11 added 2026-04-17 with F1-F25 planned)
+- `DECISIONS.md` — ADRs (ADR-001 through ADR-014, Rust/Slint switch is ADR-005)
+- `EXPANSION_PLAN.md` — full roadmap added 2026-04-17, phased execution plan
+- `TODO_CLEANUP.md` — refactor backlog from March 2026 code review
+- `CHANGELOG.md` — actively maintained
+
+**Current status (2026-04-17):** v0.2.1 released. Phase 1 reliability work starting — logging, tempfile, DISM /English, quick-xml, tests, CLI, GHA. Then 26 new features (F1-F25) across 4 tiers + tool swaps.
+
+**Reference programs Howard studies for ideas** (all in `C:\Users\howar\ClaudeSourceFiles\` or `C:\`):
+- AMPIPIT (C:\AMPIPIT) — primary Rust+Slint reference
+- GhostWin — Rust WIM/deploy reference
+- d7x (C:\Users\howar\ClaudeSourceFiles\d7x) — MSP tool catalog inspiration (55+ bundled tools)
+- Windows Setup Helper, Unattend Generator, SysprepPreparator, PhoenixPE
--- a/clients/cascades-tucson/reports/2026-04-17-breach-check-megan-hiatt.md
+++ b/clients/cascades-tucson/reports/2026-04-17-breach-check-megan-hiatt.md
@@ -0,0 +1,381 @@
+# 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.
--- a/session-logs/2026-04-17-howard-session.md
+++ b/session-logs/2026-04-17-howard-session.md
@@ -0,0 +1,71 @@
+# 2026-04-17 Session Log — Howard
+
+## User
+- **User:** Howard Enos (howard)
+- **Machine:** ACG-TECH03L
+- **Role:** tech
+
+---
+
+## [FOR MIKE] Vault hygiene — Cascades pfSense password
+
+While troubleshooting John Trozzi's WiFi issue at Cascades, I pulled the pfSense creds from the vault and the password was wrong.
+
+- **Stale entry (leave as-is for now):** `clients/dataforth/cascades-router.sops.yaml` contained `admin / a6A6c6fe` — this does not work on the actual Cascades pfSense.
+- **Correct password:** `Th1nk3r^99`
+- **New entry created:** `clients/cascades-tucson/pfsense-firewall.sops.yaml` — verified encrypts/decrypts correctly with the right password.
+- **Also misfiled:** the stale entry is under `clients/dataforth/` but the device belongs to Cascades, not Dataforth. Likely a copy-paste leftover from the Dataforth work.
+
+**Action item for you:** decide whether to update the dataforth entry with the correct password, rename/move it, or delete it. Left untouched at your request pending your call.
+
+---
+
+## Cascades — ongoing work (in progress)
+
+### 1. Folder Redirection silent-skip (Sharon Edwards)
+**Status:** Root cause likely identified; parked to chase John's WiFi issue.
+
+Investigation confirmed:
+- FR CSE runs cleanly, fires events 1000 → 1006 (`Documents has to be redirected`, flags `0x1231`) → 1007 (`no folders previously redirected`) → 1001 with **nothing in between** and **no `fdeploy.log` entry** even after fixing permissions on `C:\Windows\Debug\UserMode\` (ACL had Users read-only, fixed to Modify).
+- Ruled out: OneDrive KFM (not installed), Offline Files service (running), ownership on `D:\Homes\sharon.edwards` + `\Documents` (both owned by `CASCADES\Sharon.Edwards`), stale history (contradicted by 1007 firing).
+
+**Leading hypothesis:** the `0x200` bit in the flag word `0x1231` indicates **"Redirect folders on primary computers only"** is enabled somewhere in the GPO tree. When FR evaluates that policy and the user's `msDS-PrimaryComputer` attribute is empty or doesn't include the current machine, FR silently skips — no error, no debug log entry. Fits the fingerprint exactly.
+
+**Howard's note on design intent:** Cascades wants classic "log in anywhere, files follow you" FR. "Primary computer only" is the **opposite** of that design and should NOT be set. So the fix is to find the GPO enabling that policy and disable it, not to populate Sharon's `msDS-PrimaryComputer`.
+
+**Next step when we resume:**
+1. Run ADSI check to confirm `msDS-PrimaryComputer` is empty on Sharon and capture DESKTOP-DLTAGOI's DN (Howard has the command ready).
+2. `Get-GPResultantSetOfPolicy -User CASCADES\sharon.edwards -Computer DESKTOP-DLTAGOI` then grep for `PrimaryComputer` to find which GPO sets it.
+3. Disable that single setting in the offending GPO (Not Configured).
+4. Sign Sharon out/in, watch for event 1013.
+
+Full playbook: `C:\Users\howar\.claude\plans\immutable-imagining-spring.md`
+
+---
+
+### 2. John Trozzi WiFi (MAINTENANCE-PC)
+**Status:** Working at EOD but root cause not nailed down — fragile.
+
+Symptoms:
+- Machine connects to CSCNet (VLAN 20 INTERNAL, 10.0.20.0/24), hostname `MAINTENANCE-PC`, MAC `0c:ef:15:76:84:09`
+- Gets IP (`10.0.20.96`) but initially bounces APs at strong signal (-55 to -60 dBm) and DNS times out
+- Works fine on legacy CSC ENT (192.168.0.0/22)
+- Built-in Realtek 8822CE NIC disabled (`Not Present`) — known flaky. Replaced with TP-Link USB MU-MIMO adapter one week ago
+- Today the driver was updated on the TP-Link; immediately after, adapter went to APIPA (`169.254.232.130`)
+- pfSense had an active lease for his MAC at 10.0.20.96 the whole time
+- After some combination of actions (driver settle / release/renew / Windows healing), internet started working again — **exact trigger unknown**
+
+**Why this is fragile:** The TP-Link USB adapter has a 2019-era driver (per version string). USB WiFi adapters on UniFi with modern SSID features (802.11r/k/v, PMF, band steering) are a chronic pain point — the bouncing-at-strong-signal fingerprint points squarely at client-side roaming/driver behavior. Worked fine on CSC ENT because that SSID is simpler/legacy.
+
+**Recommended hardening before it recurs:**
+1. On John's PC: Device Manager → TP-Link adapter → Power Management tab → uncheck "Allow the computer to turn off this device to save power."
+2. Windows WiFi settings → CSCNet → Properties → set "Random hardware addresses" to **Off** (pin his MAC).
+3. Pull the latest TP-Link driver from tp-link.com for his exact model (HardwareID still not captured — do this next time onsite).
+4. In UniFi Controller, check CSCNet SSID advanced settings: Fast Roaming (802.11r), Minimum RSSI, Band Steering, PMF. Something recent changed that triggered this today after a week of stable operation.
+5. Long-term: replace the TP-Link USB with a known-good enterprise USB adapter, OR get the built-in Realtek functional with a current driver (preferred — PCIe beats USB for WiFi every time).
+
+---
+
+## Conversation thread — Claude coordination
+
+- Ollama integration discussion (earlier): Howard's laptop (Dell Inspiron 14 5441, Snapdragon X Plus, 16 GB RAM, ARM64, no CUDA) is NOT a good fit for Mike's documented Ollama setup (`qwen3:14b`, `codestral:22b`). Recommended remote Ollama on Mike's workstation + Tailscale, or small-models-local only. Parked.