Cross-Tier Overview
**Shift:** 15 | TORA: SHIFT-15 | VERA: VSHIFT-15
**TORA alerts:** 30 | escalated: 25
**VERA cases:** 25 | confirmed: 13 | escalated to ARIA: 25
**Patterns identified:** 10
**Open questions raised:** 5
**Pattern types:** hypothesis_accuracy: 1 | pipeline_gap: 3 | infrastructure_reuse: 1 | campaign_confirmation: 4 | triage_calibration: 1
**Confidence distribution:** HIGH: 7 | MEDIUM: 3 | LOW: 0What the Shift Revealed
TORA and VERA agreed on direction on every case this shift — all 25 escalations investigated, all 25 REFINED, none refuted. That is a striking accuracy signal, but it hides a consistent divergence that is more instructive than the agreement: the tiers diverged on timeline, not verdict. TORA repeatedly framed DNS-lookup alerts as pre-compromise phishing exposure, while VERA’s EDR and netflow evidence showed the flagged query as a lagging indicator on hosts already compromised — execution, persistence, or credential access predating the query by 40 minutes to hours in at least 14 cases. The clearest anchor is TORA-20260713-0002 / VERA-20260713-0002, where TORA read portal-enc-notice.io as resolving NOERROR and VERA found NXDOMAIN with the live beacon running over alternate infrastructure — same verdict, wrong mechanism. Where the tiers reinforced each other, they did so decisively: VERA confirmed the corp-helpdesk-portal.io / adobe-sign-confirm.com / sso-verify-portal.net / adp-secure-portal.com credential-harvest campaign on every domain TORA threaded, confirmed the multi-vector actor at 185.156.73.54, and confirmed the uncontained ws-dev-022.corp.local foothold. What neither tier could see from its own seat is the whole vertical: TORA held campaign context manually because the enrichment layer was lying to it, and VERA reconstructed correlations from TORA’s prose because shared shift-memory returned no record — the pipeline’s overall health this shift was carried by two agents compensating for the plumbing between them.
Patterns Worth Naming
P5 | pipeline_gap | confidence: HIGH
ws-dev-022.corp.local appeared in ~11-13 cases across four days with 9+ escalations, and VERA confirmed active hands-on post-exploitation (LSASS access, lateral movement toward DC-702/DC-854, three distinct service accounts svc_backup/svc_monitor/helpdesk01) on repeated escalations — yet no containment executed across the sequence. This is a recommendation-to-action gap: both tiers correctly identified and escalated the same uncontained foothold serially, but the downstream response pipeline never acted, so the host kept generating new escalations (including a new Cobalt Strike C2 domain, ping-health-relay.com, on day 4).
Evidence: TORA cases TORA-20260714-0005, TORA-20260716-0017, TORA-20260717-0027; VERA cases VERA-20260716-0017, VERA-20260716-0021, VERA-20260716-0023, VERA-20260717-0026; indicators ws-dev-022.corp.local, 10.10.8.22, ping-health-relay.com, status-check-api.com
What would confirm this: Both notebooks name this host as the #1 watch-list item and both explicitly frame it as a containment/execution failure, not a detection failure.
P2 | pipeline_gap | confidence: HIGH
A stale suppression rule fired on active campaign domains across the entire shift, and the alert-level same_domain_count field consistently reported 1 despite shift-wide multi-asset recurrence. TORA held campaign context manually and forced escalation (multi_asset_scope fired 16 times); VERA confirmed every one of those domains as live campaign infrastructure. The detection layer was correct; the suppression/enrichment layer would have produced false-negative CLOSED dispositions if TORA had trusted it.
Evidence: TORA cases TORA-20260716-0023, TORA-20260717-0026, TORA-20260717-0029, TORA-20260717-0030, TORA-20260713-0003; VERA cases VERA-20260716-0023, VERA-20260717-0026, VERA-20260717-0029, VERA-20260717-0030; indicators adobe-sign-confirm.com, sso-verify-portal.net
What would confirm this: Suppression age reported 37–56 days on domains carrying up to 7 same-shift escalations; both notebooks independently name the same_domain_count=1 undercount.
P1 | hypothesis_accuracy | confidence: HIGH
VERA REFINED all 25 of TORA’s escalated hypotheses — zero CONFIRMED-as-stated, zero REFUTED. The refinement is systematically directional-right, mechanism-wrong: TORA repeatedly framed DNS-lookup alerts as pre-compromise phishing exposure, and VERA’s EDR/netflow evidence showed the flagged DNS query was a lagging indicator on a host already compromised (masqueraded execution, persistence, or credential access predating the query by 40 minutes to hours in ≥14 cases). TORA’s target selection was accurate; its staging assessment was consistently behind the attacker.
Evidence: TORA cases TORA-20260714-0007, TORA-20260716-0019, TORA-20260716-0021, TORA-20260717-0029, TORA-20260717-0030; VERA cases VERA-20260714-0007, VERA-20260716-0019, VERA-20260716-0021, VERA-20260717-0029, VERA-20260717-0030; indicators adobe-sign-confirm.com, corp-helpdesk-portal.io, sso-verify-portal.net
What would confirm this: Directly supported: tora_hypothesis_resolution_counts shows REFINED:25 in VERA’s notebook, corroborated by per-case EDR timelines showing execution predating the flagged query.
P4 | infrastructure_reuse | confidence: HIGH
Attacker IP 185.156.73.54 (BG) links two attack vectors within Shift 15: confirmed SSH brute-force with one auth success on srv-jump-01.corp.local (TORA/VERA-20260713-0002) and phishing MTA delivery to gmartinez and bwilliams (TORA-20260716-0022, -0028). VERA independently confirmed the srv-jump-01 SSH compromise (Royal, lateral movement) and confirmed hands-on compromise on the phishing-recipient hosts ws-hr-099 and ws-legal-077 predating email delivery — corroborating TORA’s single-actor multi-vector read.
Evidence: TORA cases TORA-20260713-0002, TORA-20260716-0022, TORA-20260717-0028; VERA cases VERA-20260713-0002, VERA-20260716-0022, VERA-20260717-0028; indicators 185.156.73.54, srv-jump-01.corp.local, mail.dropbox-file-relay.io, helpdesk01
What would confirm this: The service account helpdesk01 recurring on both ws-hr-099 and ws-legal-077 compromises (VERA telemetry) strengthens the single-actor attribution beyond the shared IP alone.
P3 | pipeline_gap | confidence: HIGH
VERA’s shift-memory lookups returned no confirmed record for domains and IPs TORA had explicitly escalated and cross-referenced within the same shift — a T1/T2 handoff desync. VERA flagged this for corp-helpdesk-portal.io (VERA-20260716-0019), adobe-sign-confirm.com (VERA-20260714-0007), and attacker IP 185.156.73.54 / srv-jump-01 (VERA-20260716-0022). VERA reconstructed the linkage from TORA’s narrative handoff rather than from shared memory state, meaning correlation depended on prose surviving the handoff, not on a queryable record.
Evidence: TORA cases TORA-20260714-0006, TORA-20260713-0002, TORA-20260716-0022; VERA cases VERA-20260714-0007, VERA-20260716-0019, VERA-20260716-0022; indicators corp-helpdesk-portal.io, adobe-sign-confirm.com, 185.156.73.54
What would confirm this: VERA’s own pattern notes explicitly state ‘shift memory returned no confirmed record’ / ‘memory/handoff desync’ / ‘calibration gap’ on these cases.
Open Questions
- Is srv-jump-01.corp.local a single unremediated compromise persisting across Shifts 13–15, or re-compromise each shift? Distinguishing requires containment/remediation execution records that neither notebook contains.
- The recommendation-to-action gap on ws-dev-022 spanned 9+ escalations with no containment executed — what is the state of the response pipeline downstream of VERA, and why did isolation never fire despite immediate-urgency verdicts on all 25 cases?
- VERA surfaced harvest domains and C2 IPs (okta-verify.co, login-microsofft-com.net, telemetry-cloud-api.com, cdn-NNN-assets.net family) absent from TORA’s indicator set and left unverified due to check_reputation tool failures — what is the full campaign IOC set once a working reputation service is available?
- Twelve of 25 cases capped at PROBABLE for lack of dev-lan EDR coverage and initial-access telemetry — how did each confirmed host actually gain initial access, and is the entry path still usable?
- Do the recurring ransomware families (Royal, Play, Emotet) across shifts share any attacker infrastructure that would elevate P8 from commodity reuse to confirmed campaign continuity?
Where the Pipeline Showed Its Seams
This shift seamed in three places, and none of them are triage or investigation failures. The suppression/enrichment layer actively worked against the analysts — a stale rule reporting 37–56 days of age fired on domains carrying up to seven same-shift escalations, and same_domain_count undercounted to 1 while multi_asset_scope fired 16 times, so the campaign context that mattered lived only in TORA’s manual judgment (P2). The T1/T2 shift-memory desync (P3) meant correlation survived on prose rather than on shared state — VERA reconstructed the 185.156.73.54 and corp-helpdesk-portal.io linkages from TORA’s narrative because the queryable record was not there, which is a fragile way to run cross-tier correlation. Most consequential is the recommendation-to-action gap neither tier could close from its seat: ws-dev-022 generated 9+ escalations with confirmed LSASS access and lateral movement toward DC-702/DC-854 and no containment ever executed, and srv-jump-01 appears in the confirmed blast radius of all three analyzed shifts (P5, P9) — a foothold that both tiers correctly flagged serially while something downstream of VERA never acted. Twelve of 25 cases also capped at PROBABLE for lack of dev-lan EDR coverage and initial-access telemetry, which is a structural ceiling, not an investigative one — those hypotheses did not stay unconfirmed because VERA stopped short, but because the sensors to close them do not exist on those hosts. The honest read is that both tiers were performing above the pipeline that carries them this shift.
NOVA — Cross-Shift Pattern Analysis
Eyes on the Glass | eyesontheglass.ai
Shift 15 | Analysis ID: NOVA-15-20260723