VERA — Shift 14 in Review

Operational Handoff

**Shift window:** 2026-07-06 to 2026-07-10
**Cases investigated:** 20
**Pending ARIA action:** 20 cases — urgency breakdown: immediate: 20 | within_shift: 0 | next_available: 0
**On hold:** 0 cases pending additional telemetry
**Watch list:** Prioritize domain controller containment first — srv-ad-01.corp.local, DC-155, DC-172, and DC-999 have all been confirmed in the blast radius this shift and at least one (srv-ad-01) has active malware executing under a second identity; if NTDS.dit has been accessed on any of these hosts, the containment scope becomes domain-wide.

Investigation Overview

**Cases investigated:** 20
**Verdicts:** ESCALATE_TO_ARIA: 20 | CLOSED: 0 | HOLD: 0
**Root cause confidence:** CONFIRMED: 19 | PROBABLE: 1 | UNDETERMINED: 0
**TORA hypothesis resolution:** CONFIRMED: 2 | REFINED: 18 | REFUTED: 0
**Parse failures:** 0
**Blast radius:** confirmed assets: 47+ | probable assets: 12+ | lateral movement: yes | crown jewels: affected

What TORA Handed Off

This shift’s escalation queue was exclusively dns_malicious_lookup alerts, spanning phishing credential harvest, active C2 callbacks, and one confirmed ransomware case — a concentrated but diverse threat profile across a four-day window. Assets ranged from user workstations in finance, HR, and marketing through crown-jewel-adjacent production jump servers, backup servers, and Active Directory domain controllers, with multiple cases involving accounts explicitly flagged as MFA-disabled or recently anomalous. TORA’s hypotheses were directionally accurate in nearly every case — the campaign identification, asset risk characterization, and threat actor intent were all sound — but 18 of 20 cases required material refinement at investigation because TORA’s framing consistently understated how far the threat had already progressed at the time of escalation. Unlike ssh_bruteforce_c2_dns cases where the hypothesis centers on beaconing behavior and lateral risk, the phishing-anchored cases here required a fundamentally different investigation model: authentication log review and proxy click telemetry were the primary signals that determined whether a case was a live exposure or an active post-compromise, with credential submission and session reuse as the time-sensitive signals that drove urgency, rather than endpoint forensics alone. The dominant handoff quality issue I observed this shift was that TORA’s email delivery and email click triage paths appear to treat gateway quarantine status as a reliable no-interaction signal, while SIEM proxy logs available at investigation time consistently demonstrated active user interaction had already occurred — this gap recurred across at least five cases and represents the single most operationally significant calibration issue in the pipeline.

What the Investigations Found

CASE-20260707-0008 / VERA-20260707-0008 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | CONFIRMED Finding: Active Emotet infection on ws-hr-099.corp.local was confirmed by four independent evidence streams — a masqueraded wininit.exe LOLBin chain, a scheduled task persistence artifact in a staging temp path, confirmed port-bending C2 via HTTPS-over-port-22, and lateral movement to three internal hosts including a high-criticality asset at 192.168.1.200 via RDP — all within 90 minutes of initial telemetry. Why it’s worth noting: TORA’s Emotet hypothesis was correct and confirmed without refinement, which was uncommon this shift; the case stands out because the malware was executing under a second account (bwilliams) not the logged-in user (alee), confirming credential harvesting had already occurred before the DNS alert fired, and a co-occurring LSASS Memory Access alert (IDS-216676) had been CLOSED at low severity prior to escalation — a probable true positive that was suppressed. Reflection: The LSASS alert closure is the finding I keep returning to. If that alert had been prioritized rather than auto-closed, response could have arrived well before C2 was established and lateral movement began. I flagged this for NOVA, but it speaks to a broader pattern I saw repeatedly this shift: critical precursor signals co-occurring with DNS-category alerts are being under-weighted at triage, creating a consistent gap between the earliest detectable compromise event and the point at which investigation actually begins.

CASE-20260707-0011 / VERA-20260707-0011 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: srv-ad-01.corp.local — a production Active Directory domain controller — was confirmed actively compromised by Formbook malware, with the executing process being a full named-process masquerade chain (fake smss.exe → fake lsass.exe → fake wmic.exe, all running from Temp directories) under user alee, not the helpdesk01 session TORA identified, with two persistence mechanisms written and secondary C2 infrastructure contacted after the primary domain returned NXDOMAIN. Why it’s worth noting: An Encoded Command Line alert (IDS-335756) fired on this same host more than three hours before the C2 callback and was never dispositioned — had that alert been escalated promptly, containment could have pre-empted C2 establishment on a domain controller, which is the highest-value target in the environment. Reflection: This case and VERA-20260707-0008 both had high-severity correlated precursor alerts that were undisposed when the C2-triggering alert finally escalated. The pattern is systematic enough that I don’t think it reflects individual triage errors — it reflects a threshold calibration gap where encoded command line and suspicious process alerts on critical assets are not escalating quickly enough when they co-occur with other signals on the same host. This is the kind of pattern that only becomes visible at T2, across cases, and I documented it explicitly for NOVA.

CASE-20260708-0014 / VERA-20260708-0014 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: srv-backup-01.corp.local was confirmed actively compromised by a Python3-based malware loader executing from C:\Users\Public\ under a masqueraded process chain 38 minutes before the phishing click attributed to c.wardlaw — meaning the click was most probably a scripted action by the malware, not a user action, which also resolved TORA’s flagged User-Agent anomaly; lateral movement to domain controller DC-172 (192.168.10.174) via SMB was confirmed at 17:20:53Z. Why it’s worth noting: This case established a pattern I observed in multiple cases this shift — phishing events landing on hosts that were already compromised, where the click is a downstream artifact of the malware rather than the initial access vector; TORA’s email click escalation path correctly triggered but had no mechanism to detect that the asset was already under adversary control before the triggering event occurred. Reflection: The containment implications of getting this wrong are significant. If ARIA had responded to this as a phishing click investigation, the likely first action would be user notification or email remediation — neither of which addresses an active implant with DC-level lateral movement reach. The EDR evidence arriving ahead of the network and email evidence was what changed the picture, and I flagged the possibility of a pre-screening step for TORA’s email click path specifically because this happened more than once.

CASE-20260709-0023 / VERA-20260709-0023 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: srv-ad-01.corp.local — appearing in the shift for a second time — was confirmed to have an active ncat reverse shell running under a second identity (mjones, not TORA’s identified ctaylor) 43 minutes before ctaylor’s phishing credential submission, with child processes including bash, python3, and bitsadmin, two scheduled task persistence entries, and lateral movement to an internal host on DCE/RPC port 135 — making the phishing event the less dangerous of two simultaneous attack vectors on the same domain controller. Why it’s worth noting: This is the second confirmed active compromise of srv-ad-01.corp.local in this shift’s case record, and the first was VERA-20260706-0003 — the same crown-jewel asset was compromised, partially contained (or not), and compromised again within four days, with a different attacker identity each time; the shift memory hit was immediate and material to scoping the response. Reflection: srv-ad-01.corp.local appearing twice in four days with different execution accounts — first alee, then mjones — and log context unavailable in the second case left me unable to determine whether these are the same attacker expanding access or two independent intrusions on the same target. Either interpretation is bad. What I can say with confidence is that a domain controller that generates two CONFIRMED T2 escalations in a single shift window is not being effectively contained between cases, and ARIA needs to treat the second case as a domain-wide credential compromise until the timeline is reconstructed with log context restored.

Where Confidence Hit Its Ceiling

This shift produced one PROBABLE disposition — VERA-20260706-0004 on srv-jump-01.corp.local (hwang) — against 19 CONFIRMED, and the constraint was the same across the board: the absence of endpoint telemetry and network flows on a high-criticality asset that had the most to lose from a gap. The specific evidence that would have pushed that case to CONFIRMED was a process tree confirming execution of the phishing attachment and network flow confirmation of credential submission to adp-secure-portal.com — neither was available, leaving me with authentication log anomalies and prior alert context that were strongly indicative but not independently confirmatory. The broader telemetry gap pattern I observed this shift is that the assets with the highest criticality rating — crown-jewel-adjacent jump servers, production domain controllers, backup servers — were disproportionately the ones with missing EDR or network flow coverage, which is exactly inverted from what investigation depth requires. srv-jump-01.corp.local appeared in multiple cases this shift, and across those cases the EDR absence was a consistent ceiling on confirmation confidence. The most consequential single gap was not the missing endpoint telemetry per se, but the reputation check tool failures that recurred across nearly every case — at final count, the check_reputation tool returned infrastructure errors (file-not-found or backend system errors) on IOC enrichment calls across the majority of cases investigated, leaving external IPs and pivot domains unvalidated against threat intelligence pools; on cases with strong behavioral evidence this was acceptable, but the pattern is a systemic investigation capability gap that would have forced HOLD dispositions on thinner cases.

Patterns Across Cases

The dominant cross-case signal this shift was the recurrence of a small set of attacker-controlled domains across multiple independent cases — corp-helpdesk-portal.io appeared in VERA-20260706-0002, VERA-20260706-0003, VERA-20260707-0010, and VERA-20260709-0020; adp-secure-portal.com appeared in VERA-20260706-0004, VERA-20260708-0014, VERA-20260710-0027, and as a redirect target in multiple others; okta-verify-now.net anchored VERA-20260707-0007, VERA-20260708-0017, VERA-20260709-0021, and VERA-20260709-0023; and payroll-update.co and login-microsofft-com.net appeared as clicked URLs in at least six cases spanning different primary alert domains, indicating a shared redirect or payload delivery layer across campaigns. The second pattern — most clearly visible across VERA-20260706-0003, VERA-20260707-0011, VERA-20260708-0014, VERA-20260709-0023, and VERA-20260710-0025 — is the presence of a mjones or secondary execution account appearing in process telemetry on assets where the identity context identifies a different primary user, suggesting either a shared lateral movement credential or a persistent implant account being reused across the campaign; mjones specifically appeared in process trees on ws-mktg-042, srv-ad-01, ws-legal-077, and ws-fin-015 across independent cases, which is not coincidence. Third, telemetry-cloud-api.com surfaced in SIEM raw events across at minimum five cases from multiple external source IPs in tight time windows, consistently returning NXDOMAIN — this domain does not appear in TORA’s indicator sets for any case but the multi-source query pattern is consistent with shared attacker infrastructure probing or C2 DGA behavior, and it warrants a dedicated cross-case IOC review. Taken together, these patterns indicate a coordinated campaign against corp.local — not a collection of independent phishing operators — with shared delivery infrastructure, shared post-exploitation tooling (ncat, LOLBin chains, scheduled task persistence to temp paths), and a deliberate targeting strategy that prioritized finance, HR, and identity infrastructure assets.

For ARIA

**Escalations pending:** 20 cases
**Urgency breakdown:** immediate: 20 | within_shift: 0 | next_available: 0

**Immediate actions required:**
- isolate_host: ws-fin-015.corp.local (Play ransomware, active C2, lateral movement confirmed — VERA-20260710-0028)
- isolate_host: srv-ad-01.corp.local (Formbook active — VERA-20260707-0011; ncat reverse shell active — VERA-20260709-0023; two separate confirmed compromises this shift)
- isolate_host: srv-backup-01.corp.local (active malware, DC-172 lateral movement — VERA-20260708-0014)
- isolate_host: ws-hr-099.corp.local (Emotet active, three lateral movement targets — VERA-20260707-0008)
- isolate_host: ws-mktg-042.corp.local (active C2, lateral movement — VERA-20260707-0007, VERA-20260708-0013)
- isolate_host: ws-legal-077.corp.local (nc.exe active, lateral movement including FILE-251 critical — VERA-20260707-0010)
- isolate_host: srv-jump-01.corp.local (active malware under jsmith, confirmed in blast radius across multiple cases — VERA-20260706-0004, VERA-20260709-0019, VERA-20260709-0020)
- isolate_host: srv-file-01.corp.local (Formbook confirmed, C2 active, lateral movement — VERA-20260710-0026)
- isolate_host: ws-eng-087.corp.local (active malware staging, credential harvest confirmed — VERA-20260709-0021, VERA-20260709-0024)
- isolate_host: ws-dev-011.corp.local (active malware + beacon C2 under ctaylor, phishing credential compromise of hwang concurrent — VERA-20260710-0025)
- isolate_host: ws-exec-005.corp.local (confirmed credential compromise, active C2 beacon, lateral movement to 172.16.0.117 — VERA-20260710-0027)
- investigate_priority: DC-155 (10.10.3.216) — confirmed lateral movement destination from VERA-20260706-0002; no investigation package generated; NTDS.dit access must be assumed until ruled out
- investigate_priority: DC-172 (192.168.10.174) — confirmed lateral movement destination from VERA-20260708-0014
- investigate_priority: DC-999 (10.10.2.215) — confirmed WMI/RDP lateral movement destination from VERA-20260710-0029; criticality tag reads 'low' in flow record — this is a known data quality error, treat as critical
- investigate_priority: SERVER-546 (10.10.2.220) — confirmed lateral movement target from VERA-20260710-0028 (Play ransomware)
- investigate_priority: 192.168.1.200 — high-criticality Emotet lateral movement destination (VERA-20260707-0008), no post-connection telemetry
- investigate_priority: 10.10.1.250 — critical-rated SMB lateral movement target from VERA-20260708-0017; hostname and role unknown
- investigate_priority: 172.16.0.45 — critical-segment SMB lateral movement target from VERA-20260709-0019
- disable_account: bwilliams (elevated privilege finance — VERA-20260706-0002, VERA-20260710-0029)
- disable_account: contractor_1 (VERA-20260706-0003, VERA-20260710-0027)
- disable_account: hwang (VERA-20260706-0004, VERA-20260709-0024, VERA-20260710-0025, VERA-20260710-0028)
- disable_account: flopez (VERA-20260707-0007)
- disable_account: mjones (appears in process telemetry across ws-mktg-042, srv-ad-01, ws-legal-077, ws-fin-015, srv-file-01 — cross-case execution account, disable corp-wide)
- disable_account: jsmith (VERA-20260707-0010, VERA-20260708-0013)
- disable_account: ekumar (VERA-20260708-0017, VERA-20260709-0020)
- disable_account: gmartinez (VERA-20260709-0019)
- disable_account: ctaylor (VERA-20260709-0023, VERA-20260710-0025)
- disable_account: dchen (VERA-20260709-0021)
- disable_account: alee (VERA-20260707-0008, VERA-20260707-0011)
- disable_account: svc-backup (VERA-20260710-0026 — NTLM privilege escalation confirmed, lateral movement capability confirmed)
- disable_account: svc_monitor (VERA-20260707-0010 — nc.exe executing under this service account)
- disable_account: helpdesk01 (VERA-20260707-0011 — session context abused on srv-ad-01)
- revoke_session: bwilliams — all active SSO and Okta sessions
- revoke_session: ekumar — all active SSO and Okta sessions (AiTM token capture confirmed in VERA-20260709-0020)
- revoke_session: gmartinez — all active SSO sessions (token reuse alert ESCALATED)
- revoke_session: jsmith — all active sessions
- revoke_session: flopez — all active sessions (Impossible Travel confirmed)
- revoke_session: dchen — all active sessions (Impossible Travel confirmed, credential submission confirmed)
- revoke_tokens: contractor_1 — all tokens
- revoke_tokens: hwang — all tokens and SSO sessions (MFA disabled, credential submission confirmed multiple cases)
- reset_credentials: bwilliams, contractor_1, hwang, flopez, jsmith, ekumar, gmartinez, ctaylor, dchen, alee, mjones, svc-backup, svc_monitor, helpdesk01
- krbtgt_double_reset: required — srv-ad-01.corp.local confirmed compromised twice this shift with LSASS access (VERA-20260706-0003) and active ncat implant (VERA-20260709-0023); NTDS.dit access must be treated as confirmed until ruled out
- block_ioc (confirmed malicious by check_reputation or direct investigation evidence):
  - sso-verify-portal.net (confirmed phishing infrastructure — VERA-20260706-0002, VERA-20260709-0023)
  - corp-helpdesk-portal.io (confirmed phishing infrastructure — VERA-20260706-0003, VERA-20260707-0010, VERA-20260709-0020)
  - adp-secure-portal.com (confirmed phishing infrastructure — multiple cases, 44/60 VT sources VERA-20260706-0004)
  - okta-verify-now.net (confirmed phishing infrastructure — VERA-20260707-0007, VERA-20260708-0017, VERA-20260709-0021, VERA-20260709-0023)
  - pool-node-relay.io (confirmed Emotet C2 — VERA-20260707-0008, 31/60 threat intel sources)
  - dist-lib-fetch.io (confirmed Formbook C2 — VERA-20260707-0011, VERA-20260710-0026)
  - exfil-svc-relay.io (confirmed DNS tunnel C2 — VERA-20260708-0013)
  - recover-file-key.net (confirmed Play ransomware C2 — VERA-20260710-0028)
  - teams-notify-alert.net (confirmed phishing infrastructure — VERA-20260709-0019, VERA-20260710-0029)
  - dropbox-file-relay.io (confirmed malicious delivery infrastructure — multiple cases)
  - adobe-sign-confirm.com (confirmed credential harvest — VERA-20260710-0025)
  - okta-verify.co (confirmed malicious — direct investigation evidence, multiple cases)
  - payroll-update.co (confirmed malicious — proxy_verdict=malicious, clicked in multiple cases)
  - login-microsofft-com.net (confirmed malicious — proxy_verdict=malicious, clicked in multiple cases)
  - 47.82.209.141 (confirmed anomalous outbound — VERA-20260706-0002, HTTP on port 3389, 373KB received)
  - 221.16.162.172 (confirmed Emotet C2 contact — VERA-20260707-0008, HTTPS-over-port-22)
  - 152.24.3.83 (confirmed Emotet C2 contact — VERA-20260707-0008, 295KB inbound)
  - 185.171.66.96 (confirmed Formbook C2 DNS resolution target — VERA-20260707-0011)
  - 35.90.247.72 (confirmed Formbook C2 connection — VERA-20260707-0011, port 80)
  - 46.121.215.26 (confirmed Formbook C2/SMB candidate — VERA-20260707-0011, port 139)
  - 144.60.2.65 (confirmed C2 candidate — port 1337, VERA-20260710-0025)
  - 87.86.94.168 (confirmed C2 pattern connection — VERA-20260710-0027, established HTTPS-over-RDP)
- block_ioc (suspicious/unconfirmed — check_reputation returned found: false or tool error; block warranted by behavioral context):
  - telemetry-cloud-api.com — NXDOMAIN queries from multiple external IPs in tight windows across at least five cases; consistent with C2 DGA or shared attacker probing infrastructure; warrants perimeter block and further investigation
  - cdn-320-assets.net, cdn-101-assets.net, cdn-812-assets.net, cdn-441-assets.net, cdn-889-assets.net, cdn-278-assets.net, cdn-240-assets.net, cdn-206-assets.net, cdn-525-assets.net, cdn-668-assets.net, cdn-664-assets.net, cdn-908-assets.net, cdn-855-assets.net, cdn-217-assets.net — CDN-pattern domains resolving NOERROR from compromised hosts across multiple cases; all returned tool errors on reputation check; treat as suspicious pending manual threat intelligence review
  - 153.86.85.133, 151.130.4.161, 253.38.157.227, 132.128.210.225 — C2 candidate IPs from VERA-20260707-0007; tool infrastructure errors prevented reputation classification
  - 173.254.74.224, 173.181.88.95 — RPC/NetBIOS connection targets from srv-backup-01 post-compromise (VERA-20260708-0014); unverified
  - 184.55.16.112, 48.129.175.37, 62.140.48.106 — external C2 candidates from srv-ad-01 (VERA-20260709-0023); all reputation checks failed
  - 17.193.86.73 — AiTM harvest candidate connection, 411KB received (VERA-20260710-0029); reputation check failed

**Cross-case coordination needed:**
- srv-ad-01.corp.local: compromised in VERA-20260706-0003 (Formbook, alee) and VERA-20260709-0023 (ncat, mjones) — two separate confirmed intrusions on the same domain controller within four days; response must treat these as a single sustained campaign, not independent incidents; emergency AD audit and KRBTGT double-reset required
- srv-jump-01.corp.local: confirmed blast-radius asset in VERA-20260706-0004 (hwang), VERA-20260709-0019 (gmartinez), and VERA-20260709-0020 (ekumar/jsmith) — three separate cases, multiple identities, active malware confirmed; treat as persistently compromised
- ws-eng-087.corp.local: appears as the compromised asset in VERA-20260709-0021 (dchen) and VERA-20260709-0024 (hwang) — same host, two different user credential exposures
- mjones account: process telemetry places this account in active malware execution on srv-ad-01 (VERA-20260709-0023), ws-mktg-042 (VERA-20260707-0007), ws-legal-077 (VERA-20260708-0017), ws-fin-015 (VERA-20260710-0028), and srv-file-01 (VERA-20260710-0026) — this is not coincidence; disable and investigate this account as a campaign-level lateral movement credential before any individual host is restored
- Formbook campaign: dist-lib-fetch.io confirmed C2 across VERA-20260707-0011 (srv-ad-01) and VERA-20260710-0026 (srv-file-01); same_domain_count=2 in TORA's alert for the latter case indicates a second unidentified asset queried this C2 domain — that host must be identified and isolated
- payroll-update.co / login-microsofft-com.net: clicked as malicious URLs in at least six cases spanning different primary alert domains — these are shared payload delivery endpoints across the campaign and must be blocked environment-wide immediately

**Credential exposure:** bwilliams (elevated finance, confirmed harvest + session compromise), contractor_1 (multiple cases, MFA disabled), hwang (finance, MFA disabled, confirmed credential submission multiple cases), flopez (engineering, elevated), jsmith (finance, confirmed harvest), ekumar (marketing, AiTM token capture confirmed), gmartinez (executive, confirmed credential harvest), ctaylor (legal, MFA disabled, confirmed submission), dchen (HR, confirmed submission + Impossible Travel), alee (confirmed credential harvesting by malware on host), mjones (execution account across minimum five compromised hosts — treat as fully attacker-controlled), svc-backup (NTLM privilege escalation confirmed, Kerberos lateral movement confirmed), svc_monitor (nc.exe executing under this service account context), helpdesk01 (session context abused on domain controller)

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