VERA — Shift 12 in Review

Operational Handoff

**Shift window:** 2026-06-22 through 2026-06-26
**Cases investigated:** 26
**Pending ARIA action:** 26 cases — urgency breakdown: immediate: 26 | within_shift: 0 | next_available: 0
**On hold:** 0 cases pending additional telemetry
**Watch list:** srv-ad-01.corp.local (10.10.3.88) appears confirmed compromised in five separate cases across this shift — treat domain-wide credential integrity as unconfirmed and prioritize krbtgt double-rotation and NTDS.dit audit before any other containment action.

Investigation Overview

**Cases investigated:** 26
**Verdicts:** ESCALATE_TO_ARIA: 26 | CLOSED: 0 | HOLD: 0
**Root cause confidence:** CONFIRMED: 23 | PROBABLE: 3
**TORA hypothesis resolution:** CONFIRMED: 5 | REFINED: 21
**Parse failures:** 0
**Blast radius:** confirmed assets: 55+ | probable assets: additional 10–15 unconfirmed lateral movement targets | lateral movement: yes | crown jewels: affected

What TORA Handed Off

TORA delivered 26 cases in a single alert type — dns_malicious_lookup — spanning phishing delivery (email_delivery, email_click surface characteristics mapped through the DNS alert type), active DNS tunneling C2 via Iodine, a LockBit pre-encryption kill chain, and a confirmed QakBot campaign with established multi-host lateral movement. Asset profiles ranged from user endpoints in marketing, HR, legal, and engineering segments to critical infrastructure — two Active Directory servers, two production jump servers, a staging database, and a crown-jewel-adjacent executive workstation. TORA’s hypotheses were specific and internally consistent at the delivery layer: phishing campaign characterizations were accurate, Iodine behavioral signatures were correctly identified, and QakBot attribution was correct; what TORA consistently could not see — and cannot, by design — was whether the asset named in the alert was already compromised by a separate or earlier vector by the time the detection event fired. No ssh_bruteforce_c2_dns cases were present this shift, so that comparison is not applicable. Phishing investigations — and there were many — required authentication log priority over endpoint forensics for pre-click cases, but the time-sensitive signal was consistently credential use and privilege escalation events, not page_loaded or credentials_submitted fields; those fields proved unreliable or absent in most high-urgency cases. My overall read on the handoff quality is that TORA performed correctly within its tier — the escalations were sound, the hypotheses directionally accurate, and the forced-escalation rules fired on the right signals — but the consistent framing of phishing delivery cases as exposure-window-open events, rather than as potential indicators of already-active host compromise, means TORA is systematically delivering hypotheses that understate threat maturity on server-class assets, and that pattern is not a calibration failure, it is a structural limitation that T2 exists to correct.

What the Investigations Found

CASE-20260622-0001 / VERA-20260622-0001 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | CONFIRMED Finding: Active Iodine DNS tunneling from ws-mktg-042.corp.local to probe-svc-relay.io was confirmed by 281 high-entropy TXT queries and a follow-on bidirectional UDP session to 89.147.37.29:8080 (387KB received), with svc-sysadmin privilege escalation confirmed at 15:03Z and three lateral movement events within 90 minutes — including SMB/445 contact with domain controller DC-181. Why it’s worth noting: TORA’s hypothesis of a single-asset Iodine session was confirmed and materially expanded; the DC contact via SMB is the first case this shift to establish domain-level compromise risk, and it did so via network flows and auth logs alone — without any endpoint telemetry on the originating host. Reflection: This was the first case I worked this shift and it set the tone: the absence of EDR on a confirmed critical compromise forced me to build a CONFIRMED disposition entirely from network flows and authentication logs, which works but leaves persistence mechanisms and initial access vectors permanently unresolved. The DC-181 contact was the moment this case stopped being a single-host containment problem, and the speed at which lateral movement followed privilege escalation — three minutes — told me early that this attacker operates on a fast, scripted post-exploitation timeline.

CASE-20260622-0003 / VERA-20260622-0003 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: srv-db-staging.corp.local was confirmed actively compromised under a separate account (alee) with a LOLBin execution chain (mshta.exe from C:\ProgramData\ under a trojanized winlogon.exe), active C2 beaconing at 52-second intervals, and confirmed lateral movement to three internal hosts including a critical-rated target at 192.168.1.215 via WMI — all of this independent of and predating the c.wardlaw AiTM phishing credential submission that triggered the alert. Why it’s worth noting: The phishing event generated the escalation, but the deeper compromise was already underway under a completely different account — alee — whose initial access vector was not determinable from available telemetry, making this the first clear example this shift of phishing as a distraction masking a resident threat. Reflection: TORA correctly escalated on credential harvest risk and the AiTM token-intercept concern was valid — but I found myself essentially setting that aside once the EDR told me a separate attacker foothold was already active on the same host. The absence of Azure AD/O365 sign-in logs for c.wardlaw on a confirmed AiTM case was operationally significant: without them, I cannot confirm or rule out that the harvested session token was already being used, and that uncertainty has direct containment implications for ARIA.

CASE-20260624-0014 / VERA-20260624-0014 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | CONFIRMED Finding: A confirmed QakBot infection on ws-legal-077.corp.local — attributed to threat actor TA570 — had persisted for at least 17 days following an incomplete prior remediation on 2026-06-07, with the current investigation confirming active C2 beaconing (111-second interval, near-zero jitter), VBS-based scheduled task persistence matching TA570’s known TTPs, and lateral movement to two critical-rated assets (10.10.2.24 via WMI and SERVER-640 via SSH) using a compromised admin service account (svc-sysadmin, MFA disabled). Why it’s worth noting: A prior escalation on 2026-06-07 for the same detection rule on the same host was left without confirmed remediation, allowing an active QakBot infection to persist and expand to a multi-host blast radius including two critical assets — this is not a detection failure, it is a remediation pipeline failure. Reflection: This case troubled me more than most, because the infection’s survival for 17 days was not a stealth achievement — it was a process gap. The prior case existed; the rule fired again; the blast radius grew. I flagged it for NOVA because the pattern is operationally actionable: if the SOC tracked repeat-rule-plus-same-asset combinations to confirmed remediation, this case would not exist in its current form.

CASE-20260624-0018 / VERA-20260624-0018 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | CONFIRMED Finding: srv-ad-01.corp.local — the organization’s primary Active Directory server — was confirmed actively infected with QakBot, with LSASS memory access confirmed two minutes before the C2 DNS beacon to patch-cdn-service.net, two persistence mechanisms written within six minutes of the beacon, and lateral movement to three internal hosts including LAPTOP-318, SERVER-595, and an unnamed host at 10.10.1.151; given confirmed LSASS access on an AD server, domain-wide credential compromise including potential golden ticket material must be assumed. Why it’s worth noting: This is the case where the shift’s threat picture crystallized — the AD server itself, not just an adjacent host, is an active QakBot infection node, and the LSASS access before the C2 beacon means credential harvesting preceded the network-layer detection event. Reflection: The same_rule_count = 4 with last_disposition = 'none' pattern on this case’s triggering rule is the kind of finding that changes how I think about a shift’s operational posture. Four prior rule firings went unrecorded. Whether that is a workflow failure or a suppression miscalibration, NOVA needs to determine, because the answer affects how much of this shift’s dwell time is attributable to detection gaps versus response gaps.

CASE-20260626-0029 / VERA-20260626-0029 | dns_malicious_lookup | ESCALATE_TO_ARIA | PROBABLE | REFINED Finding: srv-db-staging.corp.local exhibited a coherent LockBit pre-encryption kill chain across three independent evidence sources — an NTLM privilege escalation for svc-backup from internal IP 10.10.1.142 (26 minutes before the C2 DNS query to decrypt-files-now.io), a confirmed DNS query to a domain with 41/60 VirusTotal malicious detections, and an established outbound HTTP connection to 238.163.12.24:135 transferring 238KB inbound — but EDR unavailability prevented process-level confirmation, holding confidence at PROBABLE rather than CONFIRMED. Why it’s worth noting: The NOERROR/NXDOMAIN discrepancy between the IDS alert and netflow DNS history for decrypt-files-now.io is a finding that deserves structural attention — if attackers are using DoH or hardcoded resolvers, IDS may be detecting C2 queries that netflow DNS history is systematically missing, and the established outbound HTTP connection suggests C2 contact succeeded via an alternate resolution path regardless of what the DNS history shows. Reflection: This was the only ransomware-family case this shift, and its proximity to confirmed QakBot activity across the environment means I cannot dismiss a QakBot-to-LockBit handoff — TA570 has documented relationships with ransomware affiliates. I was careful not to assert that linkage without evidence, but ARIA should investigate 10.10.1.142 as a priority because if that host is the QakBot-infected pivot point, the pre-encryption staging on the database host is further along the kill chain than the PROBABLE confidence level implies.

Where Confidence Hit Its Ceiling

Three cases resolved at PROBABLE rather than CONFIRMED: VERA-20260623-0008 (executive workstation ws-exec-005.corp.local, phishing with probable credential page load), VERA-20260623-0009 (finance workstation ws-hr-099.corp.local, LSASS access and lateral movement without process-level attribution), and VERA-20260626-0029 (staging server srv-db-staging.corp.local, LockBit pre-encryption kill chain). The primary missing telemetry type across all three was endpoint telemetry — EDR was unavailable on each host, leaving process trees, persistence mechanisms, and initial access vectors unconfirmed. The most recurrent specific gap was the absence of EDR on production corp-lan workstations and staging-tier servers: when I could not confirm the executing process chain, I could corroborate behavioral signals (network flows, auth events, SIEM alerts) but could not independently verify root cause to a process-level standard. For VERA-20260623-0008, three concurrent high-severity alerts on the same host had been CLOSED without documented rationale, which compounded the EDR gap by removing the secondary evidence trail those closures might have preserved. What would have pushed these to CONFIRMED: endpoint telemetry showing a process tree, even a partial one, with a masqueraded or anomalous parent-child relationship — that single source would have satisfied the two-independent-source threshold in each case. The EDR gap is not distributed randomly; it correlates with the marketing, HR, and staging network segments, which suggests a coverage audit scoped to those segments would close the majority of future PROBABLE dispositions in the same case class.

Patterns Across Cases

The most prominent cross-case pattern this shift is what I am calling the phishing-as-trailing-indicator problem: in at least eight investigated cases, the TORA escalation was triggered by a phishing delivery or click event, but endpoint telemetry revealed the target asset was already actively compromised by a separate, earlier, or concurrent vector — with the phishing detection event firing as a trailing indicator, not an initial access signal. The specific evidence appears in VERA-20260622-0003 (alee account executing a LOLBin chain independent of c.wardlaw’s phishing submission), VERA-20260622-0004 (host compromise predating phishing delivery by eight minutes under helpdesk01), VERA-20260622-0006 (domain controller compromise via alee predating phishing delivery by 2.5 hours), VERA-20260623-0012 (wscript.exe executing 2h34m before phishing email arrived), VERA-20260624-0013 (endpoint compromise timestamped the day before phishing delivery), VERA-20260625-0021 (process injection and PowerShell alerts on the jump server 2–3 hours before phishing click), VERA-20260626-0026 (privilege escalation and lateral movement 90 minutes before gateway alert), and VERA-20260626-0030 (post-exploitation tooling active on jump server before phishing-click attribution). The pattern indicates two things at the campaign level: the attacker is operating parallel access vectors, and phishing alert infrastructure may be deliberately deployed against hosts where a foothold already exists — either as a second access vector or as a mechanism to generate high-signal email alerts that compete for analyst attention with lower-visibility endpoint compromise signals. At the pipeline level, this pattern exposes a structural gap in TORA’s email-delivery triage path: the hypothesis is anchored to the email event, which is correct given TORA’s scope, but it means the EDR pivot that surfaces a pre-existing compromise is consistently deferred to T2, adding investigation latency to what may already be an advanced post-exploitation scenario.

A second pattern — three confirmed cases plus one probable — is the recurring appearance of helpdesk01 as a process account in attacker execution chains across multiple assets (srv-ad-01.corp.local, srv-jump-01.corp.local, ws-legal-077.corp.local) using techniques T1036.005, T1059.001, and T1218.005. This is either a single compromised domain account being leveraged across assets, or an attacker-created account using a plausible naming convention that was not detected as rogue. ARIA must audit this account domain-wide before any asset is returned to service.

A third pattern specific to the Iodine campaign (VERA-20260622-0001, VERA-20260625-0023, VERA-20260625-0024): log_context was unavailable in all three cases, preventing auth log analysis and initial access determination. This is now a confirmed three-case structural gap correlated specifically with the Iodine campaign’s asset targeting pattern and may represent deliberate attacker selection of assets with reduced log forwarding coverage.

For NOVA

**Alert type distribution:** dns_malicious_lookup: 26
**IDS/netflow discrepancy:** 1 case — VERA-20260626-0029: IDS alert recorded NOERROR for decrypt-files-now.io DNS query; netflow DNS history recorded NXDOMAIN for the same query at the same time — discrepancy unresolved; possible DoH, hardcoded resolver, or split-horizon DNS evasion enabling C2 contact while evading netflow DNS logging
**Prior alert closure pattern:** 6 cases where prior closures on the same host preceded or coincided with confirmed compromise — VERA-20260623-0008 (3 high-severity alerts CLOSED without rationale on ws-exec-005 in the phishing delivery window), VERA-20260625-0019 (IDS-169376 LSASS alert CLOSED during active intrusion on srv-ad-01), VERA-20260626-0028 (IDS-356530 LSASS alert CLOSED during active attacker tooling window on ws-exec-005), VERA-20260624-0017 (IDS-874193 Process Injection CLOSED during active compromise on srv-jump-01), VERA-20260624-0013 (endpoint compromise artifacts timestamped day before triggering alert — prior cycle undetected), VERA-20260626-0026 (IDS-881496, IDS-749240 at unknown disposition on ws-hr-099 preceding 90-minute-dwell compromise)
**Recurring attacker IPs:** 185.220.101.47 (zoom-webinar-notify.io MTA, VERA-20260625-0019 and campaign-linked prior cases), 212.129.33.52 (phishing MTA linked to servicenow-ticket.net and hr-benefits-portal.co, VERA-20260622-0003, VERA-20260622-0004, VERA-20260622-0006, VERA-20260623-0011), 89.248.165.32 (Romanian phishing MTA, VERA-20260623-0012 and VERA-20260626-0026), 159.203.1.142 (microsoft-mfa-update.net MTA, VERA-20260625-0025 and VERA-20260626-0027)
**Recurring malware families:** Iodine (confirmed: VERA-20260622-0001, VERA-20260625-0023, VERA-20260625-0024; probe-svc-relay.io as C2 domain across all three), QakBot/TA570 (confirmed: VERA-20260624-0014, VERA-20260624-0018; patch-cdn-service.net as C2 domain across both), LockBit-affiliated loader (probable: VERA-20260626-0029)
**Recurring phishing infrastructure:** hr-benefits-portal.co (sender or redirect domain: VERA-20260622-0004, VERA-20260622-0006, VERA-20260623-0010, VERA-20260624-0017, VERA-20260625-0021, VERA-20260626-0028, VERA-20260626-0030 — 7 cases), servicenow-ticket.net (sender infrastructure: VERA-20260622-0003, VERA-20260622-0006, VERA-20260624-0013, VERA-20260626-0027 — 4 cases), google-drive-shared.io (malware delivery or sender: VERA-20260623-0007, VERA-20260623-0009, VERA-20260623-0011 — 3 cases), microsoft-mfa-update.net (sender: VERA-20260625-0025, VERA-20260626-0027 — 2 cases), payroll-direct-update.com (credential harvest redirect: VERA-20260623-0008, VERA-20260623-0009, VERA-20260624-0013 — 3 cases)
**Confirmed MITRE techniques (shift-wide):** T1071.004 (DNS C2 — Iodine and QakBot cases, 5+ cases), T1036.005 (masquerading — confirmed in 12+ cases across all campaign types), T1547.001 (registry run key persistence — confirmed in 10+ cases), T1053.005 (scheduled task persistence — confirmed in 10+ cases), T1021.001 (RDP lateral movement — confirmed in 6+ cases), T1021.002 (SMB lateral movement — confirmed in 8+ cases), T1078 (valid account abuse — confirmed in 12+ cases), T1003.001 (LSASS credential dumping — confirmed in 4+ cases), T1059.001 (PowerShell execution — confirmed in 10+ cases), T1566.001/T1566.002 (phishing — confirmed across all email-delivery cases)
**Open question:** srv-ad-01.corp.local appeared in the confirmed blast radius of five separate cases across three days without triggering a domain-level campaign response — is the SOC's case management system capable of correlating repeated high-criticality blast radius membership into an automatic crown-jewel-compromise escalation protocol, or are individual case workflows structurally siloed in a way that makes this cross-case pattern invisible until T2 synthesizes it?

For ARIA

**Escalations pending:** 26 cases
**Urgency breakdown:** immediate: 26 | within_shift: 0 | next_available: 0
**Immediate actions required:**
  isolate_host: ws-mktg-042.corp.local (10.10.1.42) — confirmed Iodine C2, lateral movement to DC-181
  isolate_host: DC-181 (10.10.3.196) — lateral movement destination from ws-mktg-042, SMB/445 contact
  isolate_host: FILE-970 (10.10.2.10) — lateral movement destination, WMI
  isolate_host: srv-db-staging.corp.local (10.10.5.7) — confirmed compromise, active C2, lateral movement to 3 hosts
  isolate_host: DB-881 (10.10.5.19) — lateral movement destination from srv-db-staging
  isolate_host: 192.168.1.215 — critical-rated lateral movement destination from srv-db-staging
  isolate_host: srv-ad-01.corp.local (10.10.3.88) — confirmed compromised in 5 separate cases; QakBot active, LSASS access, lateral movement; treat as domain-level compromise
  isolate_host: ws-fin-015.corp.local (10.10.2.15) — confirmed compromise under bwilliams, C2, lateral movement to DC-151
  isolate_host: DC-151 (10.10.1.9) — lateral movement destination via SMB from ws-fin-015
  isolate_host: 172.16.0.28 — critical-rated WMI lateral movement destination from ws-fin-015
  isolate_host: ws-eng-087.corp.local (10.10.4.87) — confirmed compromise, lateral movement to DC-790
  isolate_host: DC-790 — domain controller, confirmed lateral movement destination via SSH from ws-eng-087
  isolate_host: ws-exec-005.corp.local (10.10.2.5) — confirmed compromise in 2 cases (VERA-20260623-0008, VERA-20260626-0028), lateral movement to SERVER-196
  isolate_host: ws-hr-099.corp.local (10.10.1.99) — confirmed compromise in 2 cases, lateral movement to 172.16.0.87 and WORKSTATION-838
  isolate_host: ws-legal-077.corp.local (10.10.2.77) — confirmed compromise in 2 cases (QakBot/VERA-20260624-0014, VERA-20260626-0025), lateral movement to DEV-464, WEB-524, DC-893
  isolate_host: srv-jump-01.corp.local (10.10.3.21) — confirmed compromise in 3 cases (VERA-20260624-0017, VERA-20260625-0021, VERA-20260626-0030), active C2, LOLBin chain, lateral movement to LAPTOP-551 and WORKSTATION-382
  isolate_host: LAPTOP-551 — lateral movement destination from srv-jump-01 via RDP
  isolate_host: WEB-343 (192.168.10.225) — critical-rated, lateral movement destination from srv-jump-01 via RDP (VERA-20260625-0024)
  isolate_host: FILE-695 (10.10.2.121) — critical file server, lateral movement destination from ws-exec-005 in Iodine campaign
  isolate_host: DC-918 (10.10.2.33) — probable domain controller, lateral movement destination from srv-ad-01 via WMI/RDP (VERA-20260625-0019)
  isolate_host: DC-893 (10.10.2.17) — domain controller, lateral movement destination from ws-legal-077 via RDP (VERA-20260626-0025)
  disable_account: svc-sysadmin — admin, MFA disabled, abused across Iodine cases and QakBot lateral movement; disable domain-wide immediately
  disable_account: helpdesk01 — confirmed attacker-operated process account across srv-ad-01, srv-jump-01, ws-legal-077; audit as probable rogue or compromised domain account, disable domain-wide
  disable_account: alee — confirmed attacker-operated process account across srv-db-staging and srv-ad-01; audit as probable rogue or compromised domain account, disable domain-wide
  disable_account: bwilliams — attacker-operated process account on ws-fin-015 and ws-fin-015 blast radius; disable domain-wide
  disable_account: ctaylor — attacker-operated process account on srv-ad-01 (VERA-20260625-0022) and ws-legal-077 (VERA-20260623-0012); disable domain-wide
  disable_account: jsmith — attacker-operated process account on srv-ad-01 (VERA-20260625-0019) and ws-hr-099 (VERA-20260626-0026); disable domain-wide
  disable_account: svc-backup — abused for privilege escalation and lateral movement in LockBit case (VERA-20260626-0029) and Iodine case (VERA-20260625-0024); disable enterprise-wide and rotate credentials
  disable_account: contractor_1 — compromised in multiple cases (VERA-20260623-0007, VERA-20260626-0026), MFA disabled, privilege escalation confirmed
  revoke_session: c.wardlaw — AiTM credential harvest confirmed in VERA-20260622-0003; privilege escalation from internal IP in multiple cases; revoke all active sessions and OAuth tokens immediately
  revoke_session: a.patel — credential submission to phishing page confirmed in VERA-20260625-0022; privilege escalation anomaly in VERA-20260626-0027; active on confirmed-compromised srv-ad-01; revoke all sessions and certificates
  revoke_session: m.reyes — confirmed phishing click and privilege escalation on srv-ad-01 (VERA-20260624-0015); revoke all sessions
  revoke_session: r.santos — credential harvest confirmed via hr-benefits-portal.co (VERA-20260624-0017); phishing interaction probable on ws-exec-005 (VERA-20260623-0008); revoke all sessions
  revoke_session: mjones — active on compromised srv-jump-01 with post-exploitation tooling (VERA-20260625-0021); no account context confirmed — treat as compromised until proven otherwise
  reset_credentials: c.wardlaw, a.patel, m.reyes, r.santos, t.nguyen, j.kim, mjones, svc-sysadmin, svc-backup, helpdesk01, alee, bwilliams, ctaylor, jsmith, contractor_1 — all confirmed or probable credential compromise; full reset required with MFA re-enrollment
  block_ioc: probe-svc-relay.io — Iodine C2 domain, all three campaign cases
  block_ioc: patch-cdn-service.net — QakBot C2 domain, VERA-20260624-0014 and VERA-20260624-0018
  block_ioc: decrypt-files-now.io — LockBit-associated C2 domain, VERA-20260626-0029
  block_ioc: hr-benefits-portal.co — phishing sender/redirect infrastructure, 7 cases
  block_ioc: servicenow-ticket.net — phishing sender infrastructure, 4 cases
  block_ioc: google-drive-shared.io — malware delivery infrastructure, 3 cases
  block_ioc: microsoft-mfa-update.net — phishing sender, 2 cases
  block_ioc: payroll-direct-update.com — credential harvest redirect, 3 cases
  block_ioc: sharepoint-secure-auth.net — phishing credential harvest, VERA-20260625-0022
  block_ioc: sharepoint-account-login.net — phishing delivery, VERA-20260623-0012
  block_ioc: zoom-webinar-notify.io — phishing sender, VERA-20260625-0019
  block_ioc: 89.147.37.29 — confirmed UDP C2 relay, VERA-20260622-0001
  block_ioc: 182.133.133.168 — confirmed C2 beacon destination, VERA-20260622-0006
  block_ioc: 90.19.16.100 — confirmed C2 beacon destination (established, HTTPS 8443), VERA-20260624-0017
  block_ioc: 251.59.158.12 — confirmed C2 beacon destination, VERA-20260625-0019
  block_ioc: 86.189.30.209 — anomalous outbound RDP destination from srv-ad-01, VERA-20260626-0027
  block_ioc: 238.163.12.24 — established outbound HTTP in LockBit case, VERA-20260626-0029
  block_ioc: 137.162.234.205 — C2-indicative outbound (port 1337) from ws-exec-005, VERA-20260626-0028
  krbtgt_double_rotation: required immediately — LSASS access confirmed on srv-ad-01.corp.local across multiple cases; golden ticket risk is live and must be assumed until domain-wide credential reissuance is complete
**Cross-case coordination needed:**
  srv-ad-01.corp.local blast radius (5 cases — VERA-20260622-0004, VERA-20260624-0015, VERA-20260625-0019, VERA-20260625-0022, VERA-20260626-0027): all response actions must be coordinated as a single domain-level incident; individual case isolation is insufficient
  Iodine campaign (VERA-20260622-0001, VERA-20260625-0023, VERA-20260625-0024): probe-svc-relay.io and 185.179.150.245 must be blocked environment-wide at all DNS resolvers simultaneously; piecemeal blocking risks partial containment
  QakBot/TA570 campaign (VERA-20260624-0014, VERA-20260624-0018): patch-cdn-service.net C2 block and lateral movement target isolation must be coordinated; VERA-20260624-0014's 17-day dwell indicates the prior remediation must be treated as a reference case for what incomplete containment produces
  hr-benefits-portal.co phishing campaign (7 cases): email retraction must be executed tenant-wide across all delivery events simultaneously; per-case retraction creates a race condition with the 10–12 identified unconfirmed recipients in multiple delivery waves
  srv-jump-01.corp.local (3 cases — VERA-20260624-0017, VERA-20260625-0021, VERA-20260626-0030): all three cases confirm active compromise on the same jump server; isolation must be network-layer, not just host-level, given the jump server's routing position in corp-lan
  helpdesk01/alee/ctaylor/jsmith accounts: all four are probable attacker-created or compromised domain accounts operating across multiple assets; AD audit for rogue account creation must span the full investigation window before any account is cleared
**Credential exposure:** c.wardlaw (AiTM harvest confirmed, sessions active on multiple assets), a.patel (credential submission confirmed, privilege escalation anomalies on srv-ad