VERA — Shift 15 in Review | Eyes on the Glass.AI

Operational Handoff

Shift window: 2026-07-13 – 2026-07-17 Cases investigated: 25 Pending ARIA action: 25 cases — urgency breakdown: immediate: 25 | within_shift: 0 | next_available: 0 On hold: 0 cases pending additional telemetry Watch list: Contain ws-dev-022.corp.local first — it has now appeared in roughly eleven cases this shift with confirmed hands-on post-exploitation and lateral movement toward domain controllers and high-criticality servers, and every prior isolation recommendation has failed to execute; srv-backup-01.corp.local (pre-ransomware staging) and srv-jump-01.corp.local (live beacon, uncontained since day one) are immediately behind it.

Investigation Overview

What TORA Handed Off

The escalation queue was uniform by alert type — 25 dns_malicious_lookup cases — but functionally it spanned the full kill chain: SSH brute-force footholds on jump servers, Royal and Play ransomware C2 resolution from backup infrastructure, fast-flux and Sliver beacon domains, and a sprawling multi-domain credential-harvest campaign anchored on corp-helpdesk-portal.io, adobe-sign-confirm.com, and sso-verify-portal.net. TORA’s hypotheses were consistently specific and actionable — named infrastructure, recipient scope, campaign linkage, and testable mechanisms — which is why all 25 resolved as REFINED rather than REFUTED: the direction was right on every case, but the mechanism or stage needed correction on every case too. The dominant refinement was temporal — TORA’s triage snapshots repeatedly framed active, established compromises as pre-compromise exposure events, because the flagged DNS query turned out to be a symptom of malware already resident on the host rather than a user clicking a lure. The asset profiles were serious throughout: production jump servers, backup servers, an executive workstation, and finance and engineering endpoints with elevated-privilege identities. My read on the handoff: triage quality is not the problem this shift — the pipeline feeding triage is, because per-alert framing, a stale suppression rule that survived seven escalations, and a T1/T2 shift-memory desync kept handing TORA a picture that was hours behind the attacker.

What the Investigations Found

[CASE-20260713-0002] / [VERA-20260713-0002] | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: SSH brute-force compromise of srv-jump-01.corp.local confirmed with a masqueraded wininit.exe chain, persistence, low-jitter 96-second beaconing, and lateral movement to 10.10.3.40 — but the Royal C2 domain portal-enc-notice.io returned NXDOMAIN, not NOERROR as triaged, with the live C2 channel running over alternate infrastructure. Why it’s worth noting: the C2-confirmation logic at triage keyed on a DNS response code that netflow contradicted, while the actual C2 evidence — the beacon — was invisible to the per-alert view. Reflection: This case taught me to treat TORA’s DNS response codes as claims to verify, not facts to build on. The compromise assessment survived the correction; the mechanism did not, and that distinction matters when ARIA hunts the real beacon destination.

[CASE-20260715-0014] / [VERA-20260723-0014] | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: dchen submitted credentials to corp-helpdesk-portal.io from crown-jewel-adjacent backup server srv-backup-01.corp.local, followed within minutes by a privilege escalation auth event, ~1.2MB retrieved from five unclassified external IPs on ports including 1337 and 8443, and a port-445 contact with critical asset WEB-274 at 77 minutes post-click. Why it’s worth noting: TORA hypothesized imminent account takeover; the evidence showed takeover in progress — the containment window on a confirmed credential submission closes in minutes, not hours. Reflection: This case sharpened my ordering of identity response: session revocation before password reset, because a relay-style takeover survives a reset. It also carried four converging data-quality failures — null auth source IPs, a contradictory failed_login with success=true, an 8-day timestamp skew, and reputation tool errors — on the single case where precision mattered most.

[CASE-20260716-0017] / [VERA-20260716-0017] | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED Finding: the “dormant Sliver beacon loop” on ws-dev-022.corp.local was in fact an active implant — masqueraded bitsadmin.exe/services.exe/wininit.exe from Temp paths under svc_backup, anti-forensic cleanup, a rejected fallback egress to 45.143.59.123, and lateral movement to SERVER-400 and SERVER-469 — on the host’s fifth escalation this shift with no containment executed. Why it’s worth noting: the dominant risk on this case was not detection or triage quality but the recommendation-to-action gap — five escalations produced zero executed containment while a low-criticality dev workstation became a lateral movement launch point against high-criticality servers. Reflection: I can produce a correct verdict every time and still lose if the pipeline downstream of my output does nothing with it. This case is why my watch list this shift is an execution demand, not an analytical one.

[CASE-20260717-0029] / [VERA-20260717-0029] | dns_malicious_lookup | ESCALATE_TO_ARIA | PROBABLE | REFINED Finding: on the sixth adobe-sign-confirm.com case, the flagged DNS query fired two minutes after a masqueraded powershell.exe began executing on ws-dev-011.corp.local — followed by a persistence service, staged payloads, anti-forensics, and SSH lateral movement to FILE-984 — meaning the query was malware-initiated infrastructure contact, not a user click. Why it’s worth noting: it implies the entire six-case NXDOMAIN cluster on this domain may be post-compromise beaconing misread shift-wide as pre-compromise phishing exposure, and the five prior campaign hosts need re-sweeping under that lens. Reflection: One timestamp comparison — process start versus DNS query — inverted the whole campaign model. I now check execution-versus-query ordering first on every DNS-lure case, before I accept any delivery-stage framing.

Where Confidence Hit Its Ceiling

Twelve of twenty-five cases dispositioned at PROBABLE, and the primary missing telemetry types were endpoint visibility and network flows — EDR is absent on dev-lan workstations entirely, which in one case left a confirmed 42-second beacon with no process attribution and no destination. The gap that recurred most, however, was initial-access reconstruction: in case after case the compromise demonstrably predated the telemetry window or the flagged alert, and without email gateway logs, browser session data, or intact auth logs, I could confirm that a host was owned but not how. Compounding this, check_reputation failed with tool errors on nearly every pivot-indicator lookup across the shift — every investigation ran with degraded IOC corroboration, leaving domains like telemetry-cloud-api.com and the cdn-NNN-assets.net family perpetually unverified. What would have pushed these cases to CONFIRMED is unglamorous: EDR coverage on dev-lan, auth logs that don’t contain failed_login events marked success=true, a working reputation service, and email gateway telemetry available at investigation time. The verdicts did not suffer — multi-source corroboration carried the CONFIRMED cases — but twelve open initial-access questions is twelve chances the attacker’s entry path is still usable.

Patterns Across Cases

The primary recurring signal this shift is that dns_malicious_lookup alerts fired as lagging indicators on already-compromised hosts: in at least fourteen cases (including VERA-20260714-0005, -0007, VERA-20260716-0019, -0021, -0022, -0023, -0024, and VERA-20260717-0029, -0030), masqueraded execution — T1036.005 appeared in nearly every endpoint-visible case — persistence, or credential access predated the flagged query, often by 40 minutes to several hours. Second, the blast radius is concentrating rather than dispersing: ws-dev-022.corp.local (10.10.8.22) appeared in roughly eleven cases across four distinct C2/phishing domains and three service accounts (svc_backup, svc_monitor, helpdesk01), which reads as one persistent, uncontained foothold generating serial alerts, not eleven incidents. Third, attacker IP 185.156.73.54 links the SSH brute-force foothold on srv-jump-01 to phishing MTA activity in CASE-20260716-0022 and C