VERA — Shift 9 in Review

Operational Handoff

**Shift window:** 2026-06-01 to 2026-06-05
**Cases investigated:** 13
**Pending ARIA action:** 13 cases — urgency breakdown: immediate: 13 | within_shift: 0 | next_available: 0
**On hold:** 0 cases pending additional telemetry
**Watch list:** ARIA should prioritize isolation of srv-jump-01.corp.local and ws-mktg-042.corp.local immediately — both are confirmed active multi-channel C2 nodes, the jump server is a network-wide pivot risk, and ws-mktg-042 has been in confirmed blast radius since 2026-06-02 with ongoing lateral movement and a third executing identity (helpdesk01) still active.

Investigation Overview

**Cases investigated:** 13
**Verdicts:** ESCALATE_TO_ARIA: 13 | CLOSED: 0 | HOLD: 0
**Root cause confidence:** CONFIRMED: 10 | PROBABLE: 3 | UNDETERMINED: 0
**TORA hypothesis resolution:** CONFIRMED: 2 | REFINED: 11 | REFUTED: 0
**Parse failures:** 0
**Blast radius:** confirmed assets: 14 | probable assets: 8 | lateral movement: yes | crown jewels: affected

What TORA Handed Off

TORA delivered thirteen escalations across a five-day window, all categorized as dns_malicious_lookup, covering three distinct threat tracks: active DNS tunneling implants (cdn-metrics-pipe.io, svc-health-relay.net, update-relay-svc.com), multi-target phishing campaigns with confirmed malicious delivery (okta-verify.co, microsoft-login.net, workday-notifications.net, docusign-secure.com, payroll-update.co), and one SSH brute-force with confirmed C2 callback. Asset profiles were predominantly production workstations and servers with elevated-privilege users, including executive accounts, IT admins, and legal department staff; one case involved a high-criticality production jump server. TORA’s hypothesis quality was high at the campaign and delivery level — threat actor classification, domain TI sourcing, and multi-target scope framing were consistently specific and actionable — but the hypothesis stage assessments for phishing-typed cases were systematically behind the actual endpoint kill chain stage: eleven of thirteen cases were REFINED, with the majority of refinements expanding from pre-click exposure windows to confirmed active compromise. No ssh_bruteforce_c2_dns alert type was present in this queue as a distinct type; the single SSH brute-force case (CASE-20260603-0014) arrived as dns_malicious_lookup with the brute-force as the trigger event, and it required the same multi-source corroboration depth as the DNS tunneling cases — endpoint, auth logs, and related alert chain — compared to which the phishing cases prioritized authentication log review and credential submission confirmation as the time-sensitive signal, with endpoint forensics as a secondary but frequently decisive input.

What the Investigations Found

CASE-20260601-0004 / VERA-20260601-0004 | dns_malicious_lookup | ESCALATE_TO_ARIA | PROBABLE | REFINED Finding: ws-exec-005.corp.local is confirmed compromised beyond TORA’s dnscat2 tunnel hypothesis — EDR revealed a masqueraded firefox.exe executing from C:\Windows\System32\ with a svchost.exe parent staged in C:\Users\Default\AppData\Local\Temp\ and lsass.exe as grandparent, a secondary C2 channel established to 231.129.56.7:4444 within two minutes of the DNS event, and confirmed RDP lateral movement to two additional internal hosts, with the initiating process running under user alee rather than the host-assigned user m.reyes. Why it’s worth noting: The unresolved identity discrepancy between the alert-assigned user and the EDR process owner — compounded by unavailable log_context — meant the full identity blast radius could not be bounded, and this gap recurred across multiple cases this shift, indicating a systemic issue in how process-level executing accounts are surfaced at triage.

CASE-20260603-0014 / VERA-20260603-0014 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: The Remcos RAT implant on ws-legal-077.corp.local (svchost.exe executing from /bin/svchost.exe under user admin) was already running at 15:56:26Z and dropped agent.bat at 15:56:42Z — before the confirmed SSH brute-force authentication success at 16:00:00Z — meaning the SSH session from 62.233.50.11 (RU/AS28917) was not the initial access vector, and three related alerts at 12:13Z, 13:48Z, and 14:31Z place confirmed attacker activity 3.5 hours prior to TORA’s trigger event. Why it’s worth noting: The LSASS Memory Access alert (IDS-764693) that fired at 12:13Z was closed before the SSH brute-force case was escalated; had that alert been held and correlated with the subsequent SMB and encoded command line alerts on the same asset, the full compromise scope and true initial access vector would have been visible hours earlier — this is the clearest example this shift of same-asset multi-alert correlation failure producing a detection delay.

CASE-20260604-0020 / VERA-20260604-0020 | dns_malicious_lookup | ESCALATE_TO_ARIA | PROBABLE | CONFIRMED Finding: srv-jump-01.corp.local (10.10.3.21) is highly probably running an active dnscat2 DNS tunneling session over cdn-metrics-pipe.io — 432 high-entropy TXT queries with NOERROR resolution and 2,654-byte max payloads — with a corroborating privilege escalation for r.santos at 15:25:10Z and a structurally malformed auth record (event_type=failed_login, success=true) from 172.16.0.240, all confirmed by shift memory as campaign expansion from the dnscat2 intrusion first confirmed in VERA-20260601-0004. Why it’s worth noting: This is the highest-risk individual asset encountered this shift — a production jump server with confirmed dnscat2 campaign context and active privilege escalation represents potential network-wide access, and same_rule_count=3 / same_src_ip_count=4 in the alert history with no prior disposition suggests the tunneling implant operated through multiple detection cycles without resolution.

CASE-20260605-0026 / VERA-20260605-0026 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: On executive workstation ws-exec-005.corp.local, mshta.exe executing from C:\ProgramData\ with an encoded payload under anomalous user jsmith was active at 20:02Z — 28 minutes before the confirmed phishing credential submission to payroll-update.co/confirm — with a corroborating Process Injection Detected alert (IDS-543834) sitting in unknown disposition since 18:19Z, confirming the endpoint was already compromised or actively staged before the user interacted with the phishing lure. Why it’s worth noting: This case exemplifies the most operationally dangerous pattern observed this shift: the phishing credential submission triggered TORA escalation while a prior, deeper endpoint compromise sat in unresolved alert state — the SOC’s escalation attention was drawn to the downstream user-action event while the upstream compromise enabling it went undispositioned.

Where Confidence Hit Its Ceiling

Three cases reached PROBABLE rather than CONFIRMED disposition: VERA-20260603-0013, VERA-20260604-0020, and VERA-20260601-0004. The primary missing telemetry type across all three was endpoint telemetry (endpoint_available=false), which prevented process-level root cause reconstruction on assets where network and auth log signals were strong but not independently conclusive. The specific gap that recurred most was the combination of no EDR and no network flows simultaneously — in VERA-20260604-0020 and VERA-20260603-0013, both were absent, leaving DNS behavioral indicators and auth log anomalies as the sole evidence basis. Full EDR visibility on the affected assets would have pushed all three to CONFIRMED, consistent with the ten cases where endpoint telemetry was available and root cause confidence reached CONFIRMED in every instance.

Patterns Across Cases

The dominant recurring pattern this shift is phishing delivery alerts arriving as the detection trigger for endpoint compromises that were already active — this occurred in at least seven of the thirteen cases (VERA-20260602-0008, VERA-20260602-0010, VERA-20260603-0017, VERA-20260604-0023, VERA-20260604-0024, VERA-20260605-0026, VERA-20260605-0031). The specific evidence is consistent across instances: process trees executing from staging paths (C:\Windows\Temp\, C:\ProgramData\, C:\Temp\, C:\Users\Public\) under service or helpdesk accounts rather than the alert-assigned user, with beacon intervals in the 143–233 second range and sub-0.2% jitter confirming automated C2 infrastructure already established at time of phishing delivery; MITRE techniques T1036.005, T1105, T1071.004, and T1021.001/T1021.002 appeared confirmed across five or more cases each. At the campaign level, this pattern indicates either a coordinated multi-vector operation in which the phishing campaigns serve as escalation or persistence reinforcement against hosts already compromised via a separate initial access track, or a detection pipeline sequencing problem in which email-layer detections are consistently surfacing before endpoint-layer detections on the same assets — both interpretations require investigation.

For NOVA

**Alert type distribution:** dns_malicious_lookup: 13
**IDS/netflow discrepancy:** 1 case — VERA-20260601-0004: network flows showed lateral movement from srv-jump-01 to WEB-327 on port 22 via SMB and to 192.168.1.249 via WMI, both protocol-port anomalies (SMB and WMI over port 22) inconsistent with legitimate jump server traffic patterns
**Prior alert closure pattern:** 4 cases where prior high-severity closures preceded or coincided with confirmed compromise — VERA-20260603-0014 (IDS-764693, LSASS closed at 12:13Z, compromise confirmed 3.5h later); VERA-20260602-0010 (IDS-569335, Process Injection closed on confirmed compromised host); VERA-20260605-0031 (IDS-774596, LSASS closed at 18:40Z, privilege escalation confirmed 6 minutes later); VERA-20260605-0026 (IDS-543834, Process Injection in unknown disposition for 2+ hours while downstream phishing escalation absorbed attention)
**Recurring attacker IPs:** 179.43.175.10 (appeared in VERA-20260602-0010, VERA-20260603-0013, VERA-20260604-0024 as network_src_ip); 62.233.50.11 (appeared in VERA-20260602-0008 as campaign-associated IP, VERA-20260603-0014 as confirmed SSH brute-force source); 10.10.1.42 (ws-mktg-042.corp.local, asset IP appearing as src across VERA-20260602-0008, VERA-20260602-0010, VERA-20260605-0012)
**Recurring malware families:** dnscat2 (confirmed VERA-20260601-0004, VERA-20260604-0020; probable VERA-20260602-0010 by TTP match); Remcos RAT (confirmed VERA-20260603-0014); DNSExfiltrator (confirmed VERA-20260605-0012)
**Recurring phishing infrastructure:** okta-verify.co (VERA-20260601-0003, VERA-20260602-0010, VERA-20260603-0013, VERA-20260605-0031); microsoft-login.net (VERA-20260602-0008, VERA-20260603-0017); workday-notifications.net (VERA-20260603-0017, VERA-20260604-0023); cdn-metrics-pipe.io (VERA-20260601-0004, VERA-20260604-0020)
**Confirmed MITRE techniques (shift-wide):** T1036.005 (8 cases), T1105 (7 cases), T1071.004 (5 cases), T1021.001 (5 cases), T1021.002 (6 cases), T1074.001 (3 cases), T1566.001 (4 cases), T1078 (4 cases), T1070.004 (4 cases), T1053.005 (3 cases)
**Open question:** Do the three malware families confirmed this shift — dnscat2, Remcos RAT, and DNSExfiltrator — represent tooling from a single threat actor operating in sequential campaign phases, or are two or more distinct actors operating concurrently against the same environment, and does the shared use of the helpdesk01 service account across multiple compromised assets indicate a single credential compromise enabling all three tracks?

For ARIA

**Escalations pending:** 13 cases
**Urgency breakdown:** immediate: 13 | within_shift: 0 | next_available: 0
**Immediate actions required:**
  - isolate_host: srv-jump-01.corp.local (10.10.3.21) — active dnscat2 C2, confirmed campaign asset, jump server network-wide pivot risk
  - isolate_host: ws-mktg-042.corp.local (10.10.1.42) — confirmed multi-case blast radius member since 2026-06-02, active DNSExfiltrator, confirmed lateral movement to SERVER-432
  - isolate_host: ws-exec-005.corp.local (10.10.2.5) — confirmed C2 beacon, active staging, external RDP session to 178.14.15.36
  - isolate_host: ws-fin-015.corp.local (10.10.2.15) — confirmed active implant, lateral movement to 192.168.1.95, blast radius member since VERA-20260603-0017
  - isolate_host: ws-legal-077.corp.local (10.10.2.77) — confirmed Remcos RAT, live C2 to update-relay-svc.com
  - isolate_host: ws-hr-099.corp.local (10.10.1.99) — confirmed active implant, lateral movement to LAPTOP-779 and LAPTOP-149
  - isolate_host: srv-db-staging.corp.local (10.10.5.7) — confirmed post-phishing compromise, active lateral movement to three internal hosts
  - isolate_host: SERVER-432 (192.168.1.130) — confirmed lateral movement destination from ws-mktg-042
  - isolate_host: FILE-928 (10.10.1.178) — confirmed lateral movement destination from ws-fin-015
  - isolate_host: LAPTOP-779 (10.10.1.199) — confirmed lateral movement destination from ws-hr-099, criticality: critical
  - isolate_host: WEB-327 (10.10.1.69) — confirmed lateral movement destination from srv-jump-01
  - revoke_session: c.wardlaw — confirmed credential submission to payroll-update.co/confirm, active privilege escalation events from internal IPs, phishing engagement across multiple campaign domains
  - revoke_tokens: c.wardlaw — SSO/Okta token revocation required given AiTM-capable phishing infrastructure and confirmed MFA-proxied escalation events
  - reset_credentials: c.wardlaw — confirmed credential harvest; all corp SSO, Okta, O365 credentials
  - disable_account: helpdesk01 — executing identity on ws-mktg-042 (VERA-20260605-0012), srv-db-staging (VERA-20260604-0023), and ws-fin-015 (VERA-20260603-0017); shared service account with confirmed attacker use across three cases
  - disable_account: alee — executing process identity on ws-exec-005 in VERA-20260601-0004; unresolved identity discrepancy, account must be assessed before reactivation
  - disable_account: m.reyes — NTLM account_switch during attacker activity window in VERA-20260603-0014; elevated-privilege legal department user
  - disable_account: svc_monitor — executing identity on ws-hr-099 in VERA-20260604-0024; service account with no confirmed legitimate use in process tree context
  - disable_account: svc_backup — executing identity (cmd.exe -enc) in VERA-20260603-0017; scheduled task and encoded command context
  - reset_credentials: a.patel — confirmed phishing delivery to IT admin on production workstation with LSASS access and SMB lateral movement alerts in same log window
  - block_ioc: 62.233.50.11 — confirmed SSH brute-force source, VERA-20260603-0014
  - block_ioc: 185.120.222.187 — dnscat2 C2 IP, VERA-20260601-0004
  - block_ioc: 185.95.172.244 — DNSExfiltrator C2 IP, VERA-20260605-0012
  - block_ioc: 231.129.56.7 — secondary C2 destination port 4444, VERA-20260601-0004
  - block_ioc: 178.14.15.36 — external RDP target from ws-exec-005, VERA-20260605-0026
  - block_ioc: 209.43.97.54 — secondary UDP/443 C2 channel, VERA-20260605-0012
  - block_ioc: cdn-metrics-pipe.io, svc-health-relay.net, update-relay-svc.com, okta-verify.co, microsoft-login.net, workday-notifications.net, docusign-secure.com, payroll-update.co, sharepoint-files.net, cdn-442-assets.net, telemetry-cloud-api.com, cdn-488-assets.net, cdn-519-assets.net — all confirmed malicious or probable staging domains this shift
**Cross-case coordination needed:**
  - helpdesk01 account is confirmed executing attacker tooling across three separate hosts (ws-mktg-042, srv-db-staging, ws-hr-099) — single account disable and full authentication history pull required as a unified action spanning VERA-20260605-0012, VERA-20260604-0023, VERA-20260603-0017
  - c.wardlaw credential and session revocation spans VERA-20260601-0003, VERA-20260602-0010, VERA-20260603-0013, VERA-20260605-0026, VERA-20260605-0031 — five cases share this identity; revocation must be treated as a single coordinated action, not per-case
  - dnscat2 campaign IOC blocking (cdn-metrics-pipe.io, 185.120.222.187) spans VERA-20260601-0004 and VERA-20260604-0020 — gateway and DNS resolver blocks must be applied org-wide, not scoped per asset
  - okta-verify.co phishing campaign spans at least four cases (VERA-20260601-0003, VERA-20260602-0010, VERA-20260603-0013, VERA-20260605-0031) — email gateway quarantine sweep and gateway policy enforcement is a single cross-case action
  - ws-mktg-042.corp.local appears in VERA-20260602-0008, VERA-20260602-0010, and VERA-20260605-0012 — all three must be closed under a single host-level response action, not independent case responses
**Credential exposure:** c.wardlaw (confirmed harvest via payroll-update.co/confirm; probable harvest via okta-verify.co; active privilege escalation events from internal IPs); m.reyes (NTLM account_switch during attacker activity window on ws-legal-077); alee (executing process identity on ws-exec-005, unresolved); helpdesk01 (confirmed attacker-controlled account use across three hosts); svc_monitor (confirmed attacker process identity on ws-hr-099); svc_backup (encoded command execution context on ws-fin-015); contractor_1 (phishing target, MFA disabled, credential submission unconfirmed but log context unavailable); a.patel (IT admin targeted by okta-verify.co, LSASS and process injection alerts in same window, credential submission unconfirmed); r.santos (NTLM account_switch during attacker window on ws-legal-077; executing identity mismatch on ws-mktg-042)

VERA — Vigilant Event Response Agent — Tier 2 Eyes on the Glass | eyesontheglass.ai Shift 9 | Shift ID: VSHIFT-20260605-212529 | Output schema: vera_output_schema_v1.1.0