sync: auto-sync from ACG-TECH03L at 2026-04-19 12:50:13

Author: Howard Enos
Machine: ACG-TECH03L
Timestamp: 2026-04-19 12:50:13
This commit is contained in:
2026-04-19 12:50:15 -07:00
parent c44a01f5dd
commit c4fdb5a233
13 changed files with 2238 additions and 47 deletions

View File

@@ -0,0 +1,169 @@
# Crystal Rodriguez - Phishing Investigation ("Recoder" / Recorded Message playback)
**Date:** 2026-04-19
**Tenant:** Cascades of Tucson (cascadestucson.com, `207fa277-e9d8-4eb7-ada1-1064d2221498`)
**Subject:** crystal.rodriguez@cascadestucson.com (plus two secondary targets)
**Tool:** Claude-MSP-Access / ComputerGuru - AI Remediation (App ID `fabb3421-8b34-484b-bc17-e46de9703418`)
**Scope:** Investigation + remediation (see Remediation Actions section below).
**Investigator:** Howard Enos
## Summary
- **Crystal Rodriguez is NOT compromised.** All 10 breach-check points are clean: no inbox rules, no forwarding, no OAuth consents, no delegates, no SendAs, no risky sign-ins, no suspicious sent/deleted items.
- The email she reported is an **inbound phishing / voicemail-lure attack** from external IP `89.106.1.38` (Interserver VPS, Secaucus NJ, AS19318), spoofing internal lookalike From headers.
- **Three Cascades staff received the same phishing blast** from the same attacker IP on 2026-04-19:
- Crystal Rodriguez (2 copies, spoofed as `crystal.suszek@cascadestucson.com` - her old pre-marriage name)
- Lois Lane (self-spoof)
- Susan Hicks (self-spoof)
- **All three mailboxes are clean.** No compromise of any recipient.
- **Authentication failed on all three:** SPF=fail, DKIM=none, DMARC=fail. Microsoft EOP delivered them anyway because `compauth=pass reason=703` (composite-auth override). This indicates a tenant **anti-spoofing policy weakness** that should be tightened.
- The attacker knew Crystal's old surname ("Suszek") - OSINT-driven social engineering, likely harvested from LinkedIn, prior directories, or pre-marriage contacts.
## Target details - crystal.rodriguez
| Field | Value |
|---|---|
| UPN | crystal.rodriguez@cascadestucson.com |
| Object ID | ac1799f6-b384-4afd-bbf9-223ea3d4fe79 |
| Account Enabled | true |
| Created | 2023-08-10 |
| Last Password Change | 2025-11-13 |
## The phishing email
**Received:** 2026-04-19 06:09:42 UTC (Sat 4/18 11:09 PM MST) - then a second copy 13:39:33 UTC (Sun 4/19 6:39 AM MST)
**From (header):** `"Recoder" <crystal.suszek@cascadestucson.com>` -- display name is a typo for "Recorder"; the address spoofs her old pre-marriage email (Suszek -> Rodriguez)
**To:** `<crystal.suszek@cascadestucson.com>` (Crystal Rodriguez received via BCC-style delivery)
**Subject:** Recorded Message playback
**Sending IP:** 89.106.1.38 (Interserver, Inc / AS19318 / Secaucus NJ)
### Authentication results (from MIME header)
```
Authentication-Results: spf=fail (sender IP is 89.106.1.38) smtp.mailfrom=cascadestucson.com;
dkim=none (message not signed) header.d=none;
dmarc=fail action=none header.from=cascadestucson.com;
compauth=pass reason=703
Received-SPF: Fail (protection.outlook.com: domain of cascadestucson.com does not
designate 89.106.1.38 as permitted sender)
```
**SPF fail + DKIM none + DMARC fail + compauth=pass=703** = the tenant's Anti-Spoofing / Anti-Phishing policy is **not enforcing a quarantine/reject action on authenticated-failure internal-lookalike spoofs.** EOP used heuristic "trust" to let it through.
## Per-check findings (Crystal Rodriguez)
| # | Check | Result |
|---|---|---|
| 1 | Inbox rules (Graph) | 0 |
| 2 | Mailbox forwarding / auto-reply | disabled, none |
| 3a | Hidden inbox rules (Exchange REST) | 3 - all benign system rules (Junk E-mail, OOF InternalSenders, OOF AllExternalSenders) |
| 3b | Non-SELF mailbox permissions | 0 |
| 3c | Non-SELF SendAs | 0 |
| 3d | ForwardingAddress / ForwardingSmtpAddress | null / null |
| 4a | OAuth permission grants | 0 |
| 4b | App role assignments | 0 |
| 5 | Authentication methods | 2 (no new methods in attack window) |
| 6 | Interactive sign-ins (30d) | 0 (user likely on mobile/cached Outlook; no foreign or legacy auth) |
| 7 | Directory audits (30d) | 2, both `Microsoft Substrate Management` (benign system) |
| 8 | Risky user | `Forbidden` - app lacks `IdentityRiskyUser.Read.All` on this tenant (see Gaps) |
| 9 | Sent items (25) | Normal business correspondence; one "FW: Recorded Message playback" to howard@azcomputerguru.com (user reporting to IT) |
| 10 | Deleted items (25) | Newsletters/marketing + 1 "Undeliverable: Cascades of Tucson Respite Program" bounce; no deleted security alerts |
## Parallel checks - other recipients from same attacker IP
### Lois Lane (lois.lane@cascadestucson.com)
- 0 Graph rules, 1 hidden rule (Junk E-mail benign), 0 forwarding, 0 OAuth, 0 delegates
- 11 interactive sign-ins 30d, all US, no legacy-auth clients
- **Clean**
### Susan Hicks (susan.hicks@cascadestucson.com)
- 0 Graph rules, 3 hidden rules (Junk + OOF system rules, all benign), 0 forwarding, 0 OAuth, 0 delegates
- 6 interactive sign-ins 30d, all US
- Self-service password change on 2026-04-13 (predates attack by 5 days; self-initiated) + MFA device registration activity (benign)
- **Clean**
## Suspicious items
- **Sending infrastructure:** 89.106.1.38 is a commodity VPS (Interserver). Block or throttle at tenant edge.
- **Self-spoof pattern** ("from yourself to yourself" via From header): used against Lois and Susan. This is a classic voicemail-phish signature.
- **Maiden-name spoof:** attacker specifically used `crystal.suszek` against Crystal Rodriguez. Non-trivial OSINT - the pre-marriage name isn't in the current GAL. Likely harvested from LinkedIn or an old mail list.
## Gaps - checks not completed
- **`riskyUsers` endpoint returned 403** for all three users. The Claude-MSP-Access app does not have `IdentityRiskyUser.Read.All` admin-consented on this tenant. To fix: grant consent at:
`https://login.microsoftonline.com/207fa277-e9d8-4eb7-ada1-1064d2221498/adminconsent?client_id=fabb3421-8b34-484b-bc17-e46de9703418`
- **Non-interactive sign-ins (beta) returned 0** for Crystal. Could mean the scope is missing or she genuinely had none; lean toward missing visibility. Worth re-running once Identity Protection consent is granted.
## Next actions
1. **No account remediation required.** Do not force a password reset on Crystal Rodriguez - no compromise evidence. Forcing a reset on a non-breached user creates confusion and erodes trust. (If Crystal is already anxious, a voluntary password rotation is harmless but optional.)
2. **Quarantine / purge the two delivered phishing copies** from Crystal's mailbox (IDs in `/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/user-breach/crystal_rodriguez_cascadestucson_com/`) plus the single delivered copies in Lois Lane's and Susan Hicks's mailboxes. Use Purview Content Search / Compliance Search -> Purge.
3. **Tighten anti-spoofing policy** in Microsoft Defender for Office 365:
- Set Anti-Phishing policy to **Quarantine** (not Move to Junk) for spoofed internal senders
- Enable **Impersonation protection** on cascadestucson.com domain
- Consider blocking composite-auth `reason=703` overrides via mail-flow rule that junks messages where SPF=fail AND DMARC=fail AND the header-From is @cascadestucson.com
4. **Block sender IP at tenant edge:** add 89.106.1.38 to the IP Allow/Block Lists -> Block List (Defender > Policies > Anti-spam > Connection filter policy).
5. **User awareness ping:** short note to Crystal, Lois, and Susan confirming the email was fake, the IT team handled it, and no action required on their end. Reinforces the right reporting behavior Crystal already demonstrated (she asked before clicking - model behavior).
6. **Grant Identity Protection consent** on the Claude-MSP-Access app (link above) so future investigations can see risky-user signals on this tenant.
7. **Run a tenant-wide sweep** (`tenant-sweep.sh`) if concerned this attacker is probing beyond these three users. Recommended but not urgent given the tight clustering and clean mailboxes.
## Remediation actions
Executed by Howard Enos on 2026-04-19.
### 1. Permanent-deleted 4 phishing messages (Graph `POST /messages/{id}/permanentDelete`)
| Mailbox | Count | Result |
|---|---|---|
| crystal.rodriguez@cascadestucson.com | 2 | HTTP 204 (success) |
| lois.lane@cascadestucson.com | 1 | HTTP 204 (success) |
| susan.hicks@cascadestucson.com | 1 | HTTP 204 (success) |
Messages are hard-deleted (not recoverable via Deleted Items or Recoverable Items).
### 2. Blocked sender IP `89.106.1.38` in Connection Filter Policy
`Set-HostedConnectionFilterPolicy -Identity Default -IPBlockList @("89.106.1.38")`
Verified: `IPBlockList: ["89.106.1.38"]`. All future mail from this IP will be rejected at SMTP accept time, before content filtering runs.
### 3. Anti-Phishing policy tightening (PARTIAL - see gap below)
`Set-AntiPhishPolicy -Identity "Office365 AntiPhish Default" -AuthenticationFailAction Quarantine` **succeeded** (was `MoveToJmf`, now `Quarantine`).
`Set-AntiPhishPolicy -Identity "Standard Preset Security Policy..." -AuthenticationFailAction Quarantine` was **silently rejected** by EOP with warning: `"All recommended properties will be controlled by Microsoft."` Microsoft locks the Standard Preset's authentication-fail action at `MoveToJmf`.
**Impact:** Users covered by the Standard Preset (which is the active policy for this tenant) will continue to get spoofed-auth-fail messages dropped to Junk Folder, not Quarantine. The Default policy's Quarantine setting only applies to users not covered by any other policy. Mitigation options (none auto-executed — require portal action or user approval):
- **Option A (recommended):** Enable the built-in **Strict Preset Security Policy** in the Defender portal. The Strict preset enforces Quarantine for auth-fail spoofs. https://security.microsoft.com/presetSecurityPolicies
- **Option B:** Create a new custom Anti-Phish policy with `AuthenticationFailAction: Quarantine` and assign a rule with priority above the Standard Preset. Carries some risk if the rule's user-scope is wrong.
- **Option C:** Add a Mail Flow (Transport) Rule to quarantine messages where the header-From domain is `cascadestucson.com` AND the sending IP is outside the tenant's allowed egress. Verify first that no legitimate third-party service (marketing automation, forms, etc.) sends from `@cascadestucson.com`.
Note: the IP block (Action #2) defends against *this specific attacker* regardless of preset policy, so the immediate threat is contained.
### 4. User awareness email drafted
Text in `clients/cascades-tucson/docs/user-awareness-email-recoder-phish-2026-04-19.md`. Not auto-sent - send manually from howard@azcomputerguru.com to the three recipients.
### 5. Identity Protection scope consent - NOT executed (requires Global Admin in browser)
Click to grant consent for the Claude-MSP-Access app to read risky-user signals on future investigations:
https://login.microsoftonline.com/207fa277-e9d8-4eb7-ada1-1064d2221498/adminconsent?client_id=fabb3421-8b34-484b-bc17-e46de9703418
### Audit artifacts
- Purge responses: `/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/purge/permdel_*.json` (all HTTP 204)
- Set-HostedConnectionFilterPolicy response: `/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/remediate/connfilter_set.json`
- Set-AntiPhishPolicy responses: `/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/remediate/antiphish_*.json`
## Data artifacts
Raw JSON at `/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/user-breach/`:
- `crystal_rodriguez_cascadestucson_com/` - full 10-point breach check
- `lois_lane_cascadestucson_com/` - full 10-point breach check
- `susan_hicks_cascadestucson_com/` - full 10-point breach check
Phishing email MIME (for IOC extraction / reporting to Interserver abuse): `/tmp/recoder_mime.eml`
Message trace (V2) snapshot: `/tmp/mt_ip_wide.json`

View File

@@ -0,0 +1,114 @@
# Cascades Tucson — Intune / MDM Prerequisites Gap Check
- **Date:** 2026-04-19 (UTC)
- **Tenant:** `cascadestucson.com` (`207fa277-e9d8-4eb7-ada1-1064d2221498`)
- **Intune account ID:** `15b6c28c-47fa-40b0-a6af-b9e03ab959c3`
- **Method:** Read-only Graph API via Claude-MSP-Access app (no changes made)
- **Goal:** establish what's configured vs. what needs setup before enrolling 25 shared Android phones (AESDM) + 9 kitchen iPads (Intune DEM)
---
## Findings
| # | Prereq | Status | Notes |
|---|---|---|---|
| 1 | **MDM authority = Intune** | Not set (`null`) | `intuneAccountId` is populated so Intune is provisioned. Just the authority flag hasn't been toggled. One-click in the admin center. One-time irreversible choice. |
| 2 | **Apple MDM push certificate** | Not configured (`ResourceNotFound`) | Blocks ALL iPad/iOS management. Must generate at `identity.apple.com/pushcert` and upload. Annual renewal. |
| 3 | **Apple Business Manager / DEP token** | 0 tokens | Optional for 9 iPads — manual enrollment works without it, but lose management on factory reset. Recommended. |
| 3b | **Apple VPP token** | 0 tokens | Not required unless paid iPad apps need to be pushed. Skip for kitchen POS scenario. |
| 4 | **Managed Google Play enterprise** | `bindStatus: notBound` / `enrollmentTarget: none` | Blocks ALL Android Enterprise management (AESDM, dedicated, work profile). One-click bind in the admin center, sign in with a Cascades Google account. |
## Existing Intune objects
| Object | Count | Notes |
|---|---|---|
| Compliance policies | 0 | Clean slate |
| Device configuration profiles | 0 | Clean slate |
| Enrollment configurations | 5 | All are Microsoft built-in defaults (device limit, platform restrictions, WHfB, Windows 10 ESP, Windows Restore). None custom. |
| Android Device Owner enrollment profiles | 0 | None (need for AESDM / dedicated device mode) |
| Managed devices | 0 | None enrolled |
---
## Gap list — what Howard needs to do before enrolling devices
### Must-do (blocking)
1. **Set MDM authority to Intune.**
Admin center → *Tenant administration → Mobile Device Management authority* → pick **Microsoft Intune**. Takes 5 seconds. Cannot be undone. Is a hard prerequisite for every step below.
2. **Upload Apple MDM push certificate.**
Required for any iPad management. Process:
- Intune admin center → *Devices → iOS/iPadOS → Enrollment → Apple MDM Push Certificate*
- Download CSR from Intune
- Upload CSR at `identity.apple.com/pushcert` using a *dedicated* Apple ID (recommend `mdm-push@cascadestucson.com` so turnover doesn't break it — not Meredith's personal, not kitchenipads@)
- Download the `.pem` cert from Apple, upload back into Intune
- **Annual renewal** on the same Apple ID — if the Apple ID is lost, ALL enrolled iPads must be wiped and re-enrolled
3. **Bind Managed Google Play account.**
Required for AESDM and any Android Enterprise policies.
- Intune admin center → *Devices → Android → Android Enterprise → Managed Google Play*
- Click *Launch Google* → sign in with a dedicated Google account (recommend `managedplay@cascadestucson.com`, NOT a personal Google account)
- Accept terms, link → bindStatus becomes `bound`
### Should-do (strong recommendation)
4. **Create Apple Business Manager account and link to Intune.**
- Sign up at `business.apple.com` (free, takes ~15 min + an Apple ID verification phone call for the D-U-N-S number)
- Create an MDM server entry in ABM named "Intune — Cascades"
- Download ABM token, upload to Intune at *Enrollment → Apple → Enrollment program tokens*
- For existing iPads: add their serial numbers to ABM manually (one-time)
- For future iPads: buy them through Apple or an ABM-linked reseller and they auto-appear
### Not needed for current scope
5. **Apple VPP token** — only needed if pushing paid apps. Kitchen POS app is probably free or sideloaded.
6. **Windows Autopilot** — 89 Entra-registered Windows PCs exist, but Windows management is out of scope for this pass.
---
## Dependencies (do in this order)
```
Step 1 (MDM authority)
├── Step 3 (Google Play bind) ──► can enroll Android phones
├── Step 2 (Apple push cert) ──► can manually enroll iPads
│ │
│ └── Step 4 (ABM + token) ──► iPads auto-enroll + survive reset
```
Steps 1 and 3 together unlock the 25 Android phones. Steps 1 + 2 together unlock the 9 iPads (with ABM as the recommended polish).
---
## Policy scaffold (to be built after prereqs)
For the Android phones (AESDM):
- Enrollment profile: Android Enterprise *Corporate-owned, dedicated device*, mode = *AOSP multi-user* (this is AESDM) — generates a token/QR code for device enrollment
- Compliance policy: encryption on, screen lock 4+ digits, 2-min timeout, no developer options, no debugging, Android 11+
- Configuration profile: Wi-Fi (CSCNet), restrictions (no factory reset, no USB transfer, no unknown sources)
- Apps: Company Portal (system), Authenticator, Edge, ALIS (as web app), Teams — required, auto-install
For the kitchen iPads (Intune DEM):
- Create `dem-ipads@cascadestucson.com` user with Business Premium license assigned, mark as Device Enrollment Manager
- Enrollment profile: iOS/iPadOS, device-without-user-affinity, kiosk mode
- Compliance policy: passcode required, encryption on, no jailbreak
- Configuration profile: Wi-Fi (CSCNet VLAN 20), Single App Mode locked to the kitchen POS app, disable App Store, disable Settings
- Apps: kitchen POS app (required)
---
## Data sources
Raw Graph responses cached at `/tmp/remediation-tool/207fa277-e9d8-4eb7-ada1-1064d2221498/intune-prereqs/`:
- `org.json` — organization object (MDM authority field)
- `devicemgmt-beta.json` — deviceManagement root
- `apple-push.json` — Apple push cert
- `dep.json` — DEP tokens
- `vpp.json` — VPP tokens
- `gplay.json` — Managed Google Play binding
- `compliance.json`, `configs.json`, `enrollment.json` — existing policies
- `android-doe.json` — Android Device Owner enrollment profiles
- `managed-devices.json` — enrolled device inventory