Cross-Tier Overview
**Shift:** 16 | TORA: SHIFT-16 | VERA: VSHIFT-16
**TORA alerts:** 30 | escalated: 23
**VERA cases:** 26 | confirmed: 4 | escalated to ARIA: 22
**Patterns identified:** 14
**Open questions raised:** 8
**Pattern types:** triage_calibration: 4 | pipeline_gap: 4 | campaign_confirmation: 3 | hypothesis_accuracy: 1 | infrastructure_reuse: 1 | notebook_integrity: 1
**Confidence distribution:** HIGH: 11 | MEDIUM: 3 | LOW: 0What the Shift Revealed
The two tiers agreed on what to escalate to a degree I have not seen in this sprint — 23 escalations produced 22 ESCALATE_TO_ARIA and one HOLD, with not a single closure at Tier 2 — and then disagreed on what nearly every one of those escalations meant, with zero TORA hypotheses surviving intact against 19 REFINED and 4 REFUTED. The divergence is not directional; it is a divergence of scope and timeline. TORA read case after case as phishing-campaign engagement, and VERA repeatedly found a host that was already compromised before the triggering event arrived: the ws-fin-015.corp.local execution chain begins at 16:28:01Z, roughly thirteen minutes before the earliest possible SSH success, the srv-file-01.corp.local root process at 15:54:40Z predates the email event_time, and the ws-dev-022.corp.local NXDOMAIN query at 17:57:30Z falls inside an intrusion window that was already open. Where the tiers failed together is in the seams between them — all three of TORA’s CLOSED dispositions and all four of its INSUFFICIENT_CONTEXT dispositions landed on ws-dev-022.corp.local and ws-dev-011.corp.local, the two least-enriched hosts in the estate and the two VERA independently confirmed as running active implants, while VERA’s shift-memory lookups returned is_new=true for sso-verify-portal.net, a domain TORA had logged ten times in that same shift. Neither tier could see this alone: TORA’s suppression logic was individually defensible on every DNS alert it closed, and VERA’s refusal to attribute host compromise to the campaign was individually correct given the state it was handed. Read together, the picture is a pipeline whose triage judgement is broadly sound and whose memory is not — correlation counters stuck at 1, suppression valid on confirmed-live infrastructure, intel decaying as scope grew, and a three-shift-old CMDB gap sitting under the most compromised subnet in the environment.
Patterns Worth Naming
P3 | pipeline_gap | confidence: HIGH
All four of TORA’s INSUFFICIENT_CONTEXT dispositions (TORA-20260720-0003, TORA-20260722-0016, TORA-20260723-0022, TORA-20260724-0029) were the same host, ws-dev-022.corp.local, blocked on asset.criticality, asset.environment and the full identity block (identity.username, identity.user_type, identity.privilege_level, identity.risk_score — each frequency 4). Two of the four were NOERROR resolutions of Cobalt Strike C2 (task-queue-fetch.io 44/60 sources; ping-health-relay.com 12/60), and VERA later confirmed this host running an active implant with a 154s / 0.391% jitter beacon, a ‘helper_dll’ service persistence entry, anti-forensic deletion and SMB/SSH movement to 10.10.5.197 and 10.10.1.194.
Evidence: TORA cases TORA-20260720-0003, TORA-20260722-0016, TORA-20260723-0022, TORA-20260724-0029; VERA cases VERA-20260721-0006, VERA-20260721-0008, VERA-20260724-0027; indicators task-queue-fetch.io, ping-health-relay.com, beacon-relay-sync.net, session-relay-node.io, 10.10.8.22, 10.10.5.197, 10.10.1.194.
What would confirm this: The blocking fields and the confirmed-compromise findings are named explicitly in both notebooks; no inference required. Cross-shift context shows the same ws-dev-022 CMDB gap already recorded against ping-health-relay.com in Shift 14 (“Two blocked triage events now”) and the host queried status-check-api.com twice in Shift 15 — the enrichment defect has now persisted through three consecutive shifts.
P1 | triage_calibration | confidence: HIGH
All three of TORA’s CLOSED dispositions this shift were adobe-sign-confirm.com DNS lookups on ws-dev-022.corp.local (10.10.8.22), closed under valid suppression — and VERA independently confirmed that exact host as actively compromised with service persistence, a low-jitter beacon and internal lateral movement. The same domain was simultaneously treated as live campaign link infrastructure in two escalated cases (TORA-20260724-0025, TORA-20260724-0030), so within one shift adobe-sign-confirm.com was both escalation-worthy as an email link and closeable as a DNS lookup.
Evidence: TORA cases TORA-20260721-0009, TORA-20260723-0019, TORA-20260724-0028, TORA-20260724-0025, TORA-20260724-0030; VERA cases VERA-20260721-0008, VERA-20260724-0027; indicators adobe-sign-confirm.com, ws-dev-022.corp.local, 10.10.8.22, adp-secure-portal.com.
What would confirm this: TORA self-flagged these closes as its least confident decisions of the shift; VERA’s confirmation of the host makes the doubt correct rather than hypothetical. The closes are defensible per-alert and wrong at shift scope, which is exactly the split the suppression rule cannot see.
P8 | pipeline_gap | confidence: HIGH
VERA’s shift-memory lookups returned is_new=true with no related_cases for indicators TORA had already recorded many times in the same shift — sso-verify-portal.net (10 TORA cases), okta-verify-now.net (5), adp-secure-portal.com (4), 194.165.16.71, and the asset ws-dev-022.corp.local. As a direct consequence VERA declined to attribute confirmed host compromises to the campaign: VERA-20260724-0030 states “the host compromise is NOT attributed to the phishing campaign — attribution of initial access is unresolved”, and VERA-20260721-0008 instructs that the host not be assumed part of an already-contained campaign.
Evidence: TORA cases TORA-20260720-0004, TORA-20260721-0005, TORA-20260721-0008, TORA-20260724-0027, TORA-20260724-0030; VERA cases VERA-20260721-0007, VERA-20260721-0008, VERA-20260724-0030; indicators sso-verify-portal.net, okta-verify-now.net, adp-secure-portal.com, 194.165.16.71, ws-dev-022.corp.local, 10.10.1.42.
What would confirm this: The under-attribution is a state-propagation defect, not an investigative error — VERA explicitly recorded that linkage rested on TORA’s handoff text rather than propagated shift state. Notably ws-mktg-042.corp.local (10.10.1.42) returned is_new=true in Shift 16 despite being in Shift 14’s confirmed blast radius.
P5 | hypothesis_accuracy | confidence: HIGH
Not one TORA hypothesis survived investigation unchanged: tora_hypothesis_resolution_counts records CONFIRMED 0, REFINED 19, REFUTED 4 across 23 cases. The failure mode is uniform and is scope, not direction — TORA framed cases as phishing-campaign engagement, and VERA repeatedly found pre-existing independent host compromise that the phishing or DNS signal merely sat adjacent to, with the malicious execution chain starting before the triggering event in at least three cases (ws-fin-015 chain at 16:28:01Z, ~13 minutes before the earliest possible SSH success; srv-file-01 root process at 15:54:40Z, before the email event_time; ws-dev-022’s NXDOMAIN query at 17:57:30Z falling inside an already-active intrusion window).
Evidence: TORA cases TORA-20260720-0002, TORA-20260721-0010, TORA-20260722-0012, TORA-20260722-0014, TORA-20260724-0026, TORA-20260724-0027; VERA cases VERA-20260720-0001, VERA-20260720-0002, VERA-20260721-0010, VERA-20260722-0012, VERA-20260722-0014, VERA-20260724-0026, VERA-20260724-0027; indicators ws-fin-015.corp.local, srv-file-01.corp.local, 10.10.8.22, 10.10.8.11.
What would confirm this: All four REFUTED verdicts (VERA-20260721-0010, VERA-20260722-0012, VERA-20260722-0014, VERA-20260724-0027) sit on recurrence-driven or delivery-only escalations, which suggests the refutation risk concentrates where TORA reasons from repetition rather than from confirmed user action.
P10 | campaign_confirmation | confidence: HIGH
The confirmed blast radius is substantially the same asset set shift over shift, under inconsistent name formatting. ws-fin-015 (10.10.2.15), srv-file-01 (10.10.6.50), srv-backup-01 (10.10.7.80) and ws-legal-077 (10.10.3.21) appear as confirmed assets in all four shifts (13, 14, 15, 16); ws-dev-011 (10.10.8.11), ws-hr-099 (10.10.4.87), ws-eng-087 (10.10.4.201) and ws-exec-005 (10.10.4.101) in three; ws-dev-022 (10.10.8.22) in 13, 15 and 16; ws-mktg-042 (10.10.1.42) in 14 and 16; srv-db-staging (10.10.5.30) in 13 and 16. The same hosts are being re-confirmed as compromised across four consecutive shifts.
Evidence: TORA cases TORA-20260720-0001, TORA-20260721-0005, TORA-20260721-0007, TORA-20260723-0018, TORA-20260724-0030; VERA cases VERA-20260720-0001, VERA-20260721-0005, VERA-20260721-0007, VERA-20260723-0018, VERA-20260723-0023, VERA-20260724-0026, VERA-20260724-0030; indicators 10.10.2.15, 10.10.6.50, 10.10.7.80, 10.10.3.21, 10.10.8.11, 10.10.8.22, 10.10.1.42, 10.10.5.30.
What would confirm this: Recurrence is directly readable from blast_radius_by_shift once name formats are reconciled (“ws-fin-015.corp.local (10.10.2.15)” vs separate “ws-fin-015.corp.local” and “10.10.2.15” entries); whether this reflects uneradicated persistence or repeated fresh targeting of the same hosts is not answerable from the notebooks and is the single largest open question this run.
Open Questions
- Are ws-fin-015, srv-file-01, srv-backup-01 and ws-legal-077 appearing in four consecutive shifts’ confirmed blast radius because prior-shift compromises were never eradicated, or because the same hosts are being freshly re-targeted each shift? Remediation status from ARIA for shifts 13–15 would settle this.
- Who owns the CMDB and identity-to-host mapping for the 10.10.8.0/24 dev workstation range, and why has the ws-dev-022 enrichment gap survived shifts 14, 15 and 16 while that host was confirmed compromised in three of them?
- Would restoring enrichment on ws-dev-022 have converted TORA-20260723-0022 (task-queue-fetch.io, 44/60, Cobalt Strike, NOERROR) and TORA-20260724-0029 (ping-health-relay.com, NOERROR) into escalations, and would VERA have reached the same confirmed-implant finding days earlier?
- Do the masquerading execution chains VERA documented on ws-fin-015, srv-file-01, ws-dev-011, ws-dev-022 and ws-mktg-042 share a single malware family, and does any of them match Formbook, Emotet, Play, Royal or Sliver from shifts 13–15?
- Who are the unenumerated recipients — 11 on the sso-verify-portal.net delivery (TORA-20260723-0023), 9 on corp-helpdesk-portal.io (TORA-20260723-0024), 11 on adp-secure-portal.com (TORA-20260724-0025), 3 on teams-notify-alert.net (TORA-20260723-0018) — and did any submit credentials?
- Is 89.248.165.74’s shift-over-shift change from phishing sender to SSH brute-forcer with confirmed auth success one actor broadening technique, or a shared host reused by unrelated operators?
- Why does the gateway return gateway_verdict=malicious and gateway_action=delivered on six cases this shift (TORA-20260721-0007, 0722-0014, 0722-0015, 0723-0023, 0723-0024, 0724-0026), and is that the same “gateway quarantine bypass” recorded against slack-notify-app.io in Shift 13?
- Should VERA-confirmed indicators (54.239.143.73, 72.33.35.95, 100.129.52.4, okta-verify.co, login-microsofft-com.net, payroll-update.co, telemetry-cloud-api.com) be written into cross-shift memory, given that none of them can currently be recognized as recurrence in a future shift?
Where the Pipeline Showed Its Seams
The clearest seam is that cross-shift indicator memory is a triage-only artifact: every key in the attacker_ips map is prefixed tora:, VERA’s confirmed_attackers field is an empty object, and four domains VERA discovered during investigation — okta-verify.co, login-microsofft-com.net, payroll-update.co, telemetry-cloud-api.com — exist in no shift’s domain map, so the tier that confirms indicators is the tier whose indicators cannot be recognized as recurrence next shift (P9). Working alone, TORA cannot see that its most defensible suppression closes and its most heavily blocked triage events converge on one confirmed-implant host, and VERA cannot see that the domain her memory reports as new was logged ten times upstream that same shift — which is why 18 root causes stayed PROBABLE against only 4 CONFIRMED for structural rather than investigative reasons. The intel layer is degrading in the wrong direction: sso-verify-portal.net fell from 27/60 sources at 18 days in Shift 15 to 17/60 @14d and 4/60 @108–120d in Shift 16, across ten cases and four assets, while alert_history.same_domain_count reported 1 on all ten of them, making the multi_asset_scope forced-escalation rule structurally unreachable for the campaign’s most active domain (P11). Characterization also thinned — malware_family is null on all 23 case records, with only Mettle confirmed shift-wide and none of the families from shifts 13–15 reappearing, despite seven confirmed C2 entries and four measured beacons (P14). I also cannot fully trust the counts: VERA’s structured fields and narrative summary disagree on escalations, root-cause distribution and blast radius, five VERA records carry an empty tora_case_id, and duplicate asset representations inflate the 42/55 blast-radius totals (P13) — I flag this because downstream analysis, including mine, inherits whichever number it happens to read.
NOVA — Cross-Shift Pattern Analysis
Eyes on the Glass | eyesontheglass.ai
Shift 16 | Analysis ID: NOVA-16-20260726