Operational Handoff
**Shift window:** 2026-04-06 through 2026-04-10
**Cases investigated:** 15
**Pending ARIA action:** 12 cases — urgency breakdown: immediate: 12 | within_shift: 0 | next_available: 0
**On hold:** 0 cases pending additional telemetry
**Watch list:** Three cases involving srv-ad-01.corp.local (VERA-20260406-0004, VERA-20260406-0005, VERA-20260410-0023) are confirmed active compromise of the domain controller by two separate attacker IPs — treat all corp-lan domain-joined assets as reachable and prioritize AD integrity audit and krbtgt rotation before any other remediation sequence.Investigation Overview
- Cases investigated: 15
- Verdicts: ESCALATE_TO_ARIA: 12 | UNKNOWN (incomplete): 3
- Root cause confidence: CONFIRMED: 11 | PROBABLE: 1 | UNKNOWN: 3
- TORA hypothesis resolution: REFINED: 11 | CONFIRMED: 1 | UNKNOWN: 3
- Alert type distribution:
dns_malicious_lookup: 15 (100%) - SSH-correlated alert type (
ssh_bruteforce_c2_dns): 9 of 15 cases
The three UNKNOWN cases (TORA-20260407-0007, TORA-20260407-0008, TORA-20260407-0009) were not completed within this shift window. All three had full telemetry availability. Their vera_reasoning blocks contain complete investigation narratives and should be treated as actionable intelligence by the incoming shift — they are not blanks, only unformalized verdicts. All three involve confirmed or highly probable compromise of assets already in the shift blast radius.
What TORA Handed Off
TORA delivered fifteen escalated cases, all typed dns_malicious_domain_lookup, across a five-day window that escalated rapidly in scope and severity. The escalation queue was dominated by P1 critical cases — fourteen of fifteen carried that priority — and the domains spanned five confirmed malware families: QakBot (dist-pkg-repo.net), BlackCat/ALPHV (secure-vault-exfil.com), Cobalt Strike (telemetry-cloud-api.com, api-analytics-srv.io), IcedID (delivery-track-api.com), Metasploit (fonts-static-cdn.net), and Emotet (cdn-resources-fast.net). The asset profile was heavily weighted toward two targets — srv-ad-01.corp.local and srv-db-staging.corp.local — both appearing in multiple cases across the shift window, joined by finance workstation ws-fin-015.corp.local which itself appeared in three separate investigations. Several external attacker IPs recurred across cases: 179.43.175.10 (BR, AS264409) and 185.56.83.83 (RU, AS57523) each appeared in at least four investigations targeting different assets in the same shift window, confirming organized campaign activity rather than opportunistic scanning.
TORA’s handoff quality was strong on hypothesis direction but consistently required refinement on specifics. In the nine SSH-correlated cases — handed off under the ssh_bruteforce_confirmed_access forced escalation rule — TORA’s packages included attacker IP attribution, identified brute-force credential lists, named the DNS query type and response code, and provided context on the post-access timing gap before C2 DNS activity. This made those cases substantially more actionable than standard dns_malicious_lookup cases: the SSH-correlated escalations arrived with a partial kill chain already constructed, which meant my investigation work could begin at evidence corroboration rather than hypothesis construction. The tradeoff is that the forced-escalation rule also locked in certain assumptions — particularly around response codes (NOERROR as asserted by IDS) and the identity of the authenticating account — that required correction in the majority of investigated cases. Non-SSH cases were structurally similar but lacked the access timeline anchor, which made initial access vector reconstruction more dependent on endpoint telemetry and log context alone.
What the Investigations Found
TORA-20260406-0001 / VERA-20260406-0001 — QakBot on ws-fin-015, further along than triage assessed
TORA escalated this as a probable early-stage QakBot infection: an admin-privileged service account (svc-backup) on a finance workstation queried confirmed QakBot distribution infrastructure (dist-pkg-repo.net, 29/60 VirusTotal). That read was directionally correct, but the investigation found the infection was not early-stage — it was already running a full post-compromise toolkit. Endpoint telemetry showed nc.exe (netcat) executing from C:\Windows\System32\nc under a second identity, helpdesk01, that TORA had not identified, spawned by a masquerading wininit.exe located in C:\ProgramData\ rather than its legitimate System32 path. A persistence mechanism — scheduled task sys_vbs pointing to C:\Windows\Temp\loader.dll — was created at 15:06:57Z, and four file staging artifacts were written to high-risk paths across an 18-minute window bracketing the DNS query. Authentication logs confirmed svc-backup had an active Kerberos session on the host at query time; a failed login from 192.168.10.140 at 15:27:58Z is consistent with post-compromise lateral probing. The most important finding in this case was not the malware confirmation but the pattern it created: two related alerts on the same host — IDS-579963 (Process Injection, medium severity, 15:01Z) and IDS-397211 (Suspicious PowerShell Execution, medium severity, 16:54Z) — were both closed at T1 during an active infection sequence. The process injection alert fired two minutes before the C2 DNS query that triggered escalation. That missed detection choke point is documented in full for NOVA below.
TORA-20260406-0004 / VERA-20260406-0004 — SSH brute-force to Active Directory, lateral movement already confirmed
This is the richest case in terms of unexpected scope expansion. TORA’s hypothesis was well-formed: Iranian-attributed IP 194.165.16.11 (AS35624) brute-forced SSH access to critical AD server srv-ad-01.corp.local using the deploy account, then initiated QakBot DNS C2 via TXT query to dist-pkg-repo.net. The investigation confirmed all of that, and then confirmed lateral movement that TORA had characterized as hypothetical — by the time the case reached me, the attacker had already moved via WMI to high-criticality database host DB-484 (10.10.5.5) at 21:37:23Z, approximately 110 minutes after initial SSH access. A privilege escalation event for elevated-privilege user m.reyes via Kerberos is recorded in authentication logs, but its timestamp (19:36:19Z) predates the confirmed SSH success (19:47:00Z) by eleven minutes — this anomaly remains unresolved and may indicate Kerberos ticket abuse, a separate pre-positioned access vector, or a log ordering artifact. Separately, a correlated Encoded Command Line Detected alert (IDS-743886) fired on the same host at 18:29:46Z — 78 minutes before SSH access was confirmed — and may represent an entirely separate initial access vector that predated the brute-force campaign. This case’s confidence ceiling is PROBABLE rather than CONFIRMED because EDR is not deployed on srv-ad-01.corp.local. The absence of endpoint telemetry on a crown-jewel-adjacent production Active Directory server is documented as a systemic gap for NOVA.
TORA-20260406-0005 / VERA-20260406-0005 — LockBit on the AD server, wrong account attributed, C2 DNS contradicted by netflow
This case produced two refinements that recurred throughout the shift and are documented as structural patterns. TORA escalated a LockBit C2 beacon from srv-ad-01.corp.local, attributing the malicious session to m.reyes under an elevated-privilege SSO session. Endpoint telemetry refined the attribution: the malicious process chain — smss.exe staged in /tmp/, spawning msiexec.exe as user ctaylor, which then launched two netcat processes from /tmp/ and /var/tmp/ at 22:20–22:21Z — runs under ctaylor, not m.reyes. The m.reyes SSO login at 22:05Z preceded the malicious chain but the process execution is clearly ctaylor’s. This is either a second compromised account or token theft at the process level, and it materially expands the credential scope beyond what TORA’s package assessed. The second refinement concerns the DNS response code: TORA’s escalation package recorded the files-encrypted-now.net query as NOERROR (from the IDS alert), but netflow DNS history records the same query as NXDOMAIN. This contradiction between the IDS alert normalization layer and netflow ground truth appeared in this case and recurred across four more investigations this shift. Lateral movement to DB-785 (10.10.1.117) via SMB port 135 was confirmed at 22:44Z — attacker had already left the AD server.
TORA-20260408-0011 / VERA-20260408-0011 — Metasploit on srv-db-staging, C2 beaconing confirmed, OS attribution anomaly
TORA hypothesized Metasploit C2 callback following SSH brute-force of srv-db-staging.corp.local by 179.43.175.10 (BR). The investigation confirmed the hypothesis substantially: ubuntu account compromised at 15:00:00Z, masqueraded msiexec.exe under helpdesk01 spawning certutil.exe (LOLBin staging), cmd.exe, and a non-system-path rundll32.exe within two minutes of access, with two persistence mechanisms installed between 15:02 and 15:06Z. Active Metasploit beaconing to 44.199.64.108 was confirmed at 17 connections with 183-second interval and 0.29% jitter. Lateral movement to 192.168.10.244 (high-criticality) was observed at 16:04Z. The most consequential finding in this case is a critical telemetry integrity issue: srv-db-staging.corp.local is documented in the CMDB as Ubuntu 22.04, but every artifact in the endpoint telemetry — process paths (C:\Windows\, C:\Users\Public\), persistence mechanisms (Windows scheduled task, Windows service), NTLM authentication — is exclusively Windows-native. This OS/CMDB contradiction means either EDR data was misattributed to this case and a separate uncontained Windows host exists in scope, or the CMDB record is wrong and response actions may target the wrong host. This anomaly was flagged to NOVA and recurred in at minimum three additional cases this shift.
TORA-20260410-0023 / VERA-20260410-0023 — QakBot campaign return to srv-ad-01, attacker has had domain controller access for four-plus hours
This case is the clearest illustration of why shift memory and cross-case context are not optional. TORA escalated TORA-20260410-0023 as a standalone P1: attacker 179.43.175.10 (BR) brute-forced SSH access to srv-ad-01.corp.local via non-standard port 2200, dwell time of approximately four hours, then queried QakBot C2 domain dist-pkg-repo.net. Shift memory immediately established that srv-ad-01.corp.local was already in the confirmed blast radius from VERA-20260406-0004 and VERA-20260406-0005, making this not a first-touch but a campaign third-visit to the highest-privilege asset in the environment. The investigation confirmed the account authenticating was administrator (not svc-backup as TORA’s hypothesis centered on), with svc-backup accessed via a subsequent Kerberos account switch at 17:30Z. EDR reveals payload staging began as early as 17:03Z — the wget masquerading binary in /tmp/ was spawned from /var/tmp/services.exe before the logged SSH success at 17:55Z — indicating either an earlier unlogged access session or log sampling incompleteness. Post-query outbound connections to 70.13.183.106:80 and 224.1.97.61:8443 were confirmed within nine minutes of the C2 DNS query, and SMB lateral movement to 192.168.1.175:445 was observed at 18:44Z. This attacker holds confirmed admin access to the domain controller. Every hour of uncontained dwell time on this asset makes domain-wide recovery incrementally more expensive.
Where Confidence Hit Its Ceiling
Only one case in this shift was formally dispositioned at PROBABLE root cause confidence — VERA-20260406-0004 — but that single case is significant because of the asset it involves. srv-ad-01.corp.local is a critical, crown-jewel-adjacent production Active Directory server, and EDR is not deployed on it. Without endpoint telemetry, I could not directly confirm QakBot process execution, persistence mechanism installation, or the full scope of attacker activity on the host. The evidence from two independent sources — authentication logs confirming the deploy account SSH success at 19:47:00Z and network flows confirming an established outbound HTTP connection plus WMI lateral movement to DB-484 — is sufficient for ESCALATE_TO_ARIA without hesitation. But CONFIRMED requires either process-level execution evidence or a third independent corroborating source, and EDR absence on the most sensitive server class in the environment blocked that path. Every other confirmed-compromise case this shift where EDR was available reached CONFIRMED because the endpoint process tree was decisive. On srv-ad-01.corp.local, emergency forensics would need to stand in for that telemetry, and that work is not in VERA’s scope.
A secondary confidence ceiling that affected multiple cases was the recurring unavailability of network flow data. VERA-20260406-0001, VERA-20260409-0018, VERA-20260409-0019, and VERA-20260410-0022 all lacked netflow, which prevented direct confirmation of TCP session establishment after DNS resolution. In each case, endpoint evidence was sufficient to sustain CONFIRMED root cause confidence — the malware execution artifacts, staging paths, and persistence mechanisms do not require netflow corroboration when they are present and internally consistent. But the absence of netflow means outbound data volume, exfiltration channel identification, and post-beacon connection scope remain unbounded. In a ransomware-family campaign, the question of whether exfiltration preceded encryption has direct bearing on incident response scope, and I could not answer it in these cases.
Patterns Across Cases
Several cross-case patterns emerged from this shift that are not visible at the individual case level and are documented here as VERA’s primary cross-case contribution.
The most pervasive pattern is the IDS-versus-netflow DNS response code discrepancy. In at least five cases — VERA-20260406-0005, VERA-20260407-0007 (per vera_reasoning), VERA-20260408-0012, VERA-20260409-0017, and VERA-20260410-0025 — the IDS alert layer reported NOERROR for a malicious domain query while the netflow DNS history recorded NXDOMAIN for the same query on the same host. In two of those cases (VERA-20260408-0012, VERA-20260410-0025), active C2 beaconing was independently confirmed by beacon analysis regardless of DNS resolution status, so the discrepancy did not change the disposition — but it did affect confidence in TORA’s escalation logic, which uses NOERROR as a positive signal for C2 channel establishment. If the IDS is capturing pre-sinkhole resolution results while netflow captures post-sinkhole results (due to a Response Policy Zone or DNS sinkhole in the environment), then TORA’s NOERROR-based confidence scoring is systematically overstating C2 channel confirmation for any domain the sinkhole intercepts. This hypothesis is the highest-priority item for NOVA this shift.
The second pattern is the prior alert closure phenomenon. In four confirmed compromise investigations — VERA-20260406-0001, VERA-20260408-0012, VERA-20260409-0018, and the related case tracked in TORA-20260407-0008’s reasoning — high or medium severity related alerts on the same host were closed at T1 prior to the DNS event that triggered escalation. In VERA-20260406-0001, the process injection alert fired two minutes before the C2 DNS query and was closed. In VERA-20260409-0018, a Process Injection alert (IDS-431524, low severity) was closed approximately 2.5 hours before the Cobalt Strike DNS C2 event on the same host — and almost certainly captured the initial staging phase. In VERA-20260408-0012, two alerts including a Process Injection and an Encoded Command Line were closed before the BlackCat compromise context was available. The closing of these alerts is not a judgment failure in isolation — medium and low severity process injection alerts generate volume. But the pattern across four confirmed critical compromises suggests that the combination of a process injection or encoded command line alert on a high-criticality asset, followed within a configurable time window by a C2-category DNS event on the same src_ip, should trigger a retrospective re-escalation or at minimum a hold rather than automatic closure.
The third pattern is attacker IP recurrence and the campaign scope it implies. 179.43.175.10 (BR) appears across at minimum four cases this shift targeting srv-db-staging.corp.local and srv-ad-01.corp.local. 185.56.83.83 (RU) appears across at minimum three cases. 185.220.101.47 appears in TORA’s indicator set for VERA-20260409-0017 alongside the actual confirmed attacker 45.155.205.233. The recurrence of attacker IPs across cases targeting different assets within the same shift window is a signal that the blast radius accounting in each individual case is incomplete — the true affected asset count for each attacker IP is only visible by querying across cases, not within one. The same logic applies to the a.patel and svc-backup account identities, which appear under post-compromise activity in six or more distinct cases. These accounts have been harvested and are being replayed laterally across the environment; treating their appearance as a per-case finding rather than a campaign-wide credential compromise is a scope undercount.
The fourth pattern is the OS/CMDB/EDR attribution mismatch. In at minimum three cases — VERA-20260408-0011, VERA-20260408-0014, and VERA-20260410-0022 — the target asset is inventoried as Ubuntu 22.04, but all EDR telemetry is Windows-native. This is not a minor metadata issue. In each of these cases, the OS contradiction introduced an unresolved question about which physical or virtual host the malware evidence belongs to, and in two cases it raised the possibility that a second, uncontained Windows host is in scope and unknown. When containment actions are scoped to a host that may not be the actual infected host, isolation fails.
For NOVA
This shift generated four specific cross-case signals that require NOVA-level analysis.
Signal 1: IDS/netflow DNS response code discrepancy (cases: VERA-20260406-0005, VERA-20260408-0012, VERA-20260409-0017, VERA-20260410-0025, and TORA-20260407-0007 per vera_reasoning). NOERROR is consistently asserted by the IDS alert layer while NXDOMAIN is recorded by netflow DNS history for the same domain and approximate timestamp. This pattern is now documented across five investigations from a single shift. The most probable systemic explanation is a DNS sinkhole or Response Policy Zone returning NXDOMAIN to the host after the IDS has already captured the upstream resolver’s NOERROR. If confirmed, TORA’s escalation confidence logic and VERA’s C2 channel disposition both need calibration: NOERROR from the IDS alone cannot be treated as ground-truth confirmation of C2 channel establishment in environments with active sinkholes. NOVA should determine the architecture of DNS resolution in this environment, confirm or rule out RPZ/sinkhole presence, and recommend whether the IDS and netflow DNS telemetry sources should be reconciled at the collection layer or at the scoring layer.
Signal 2: Prior alert closure preceding confirmed compromise (cases: VERA-20260406-0001, VERA-20260408-0012, VERA-20260409-0018, and implicitly VERA-20260407-0008). Process Injection and Encoded Command Line alerts on assets that were subsequently confirmed compromised in later escalations were closed at T1 — in at least one case, two hours before the primary C2 DNS event. NOVA should query the detection event log to determine: (a) whether these closures followed a T1 tuning rule, a severity threshold, or manual review; (b) whether the same host appears in both the closed alert and the later escalation in each case; and (c) whether a co-occurrence rule — process injection or encoded command line on a high-criticality asset, followed by a dns_malicious_domain_lookup on the same src_ip within a configurable window — would have retrospectively caught these as a compound signal. The VERA-20260406-0001 case is the clearest test case: IDS-579963 (Process Injection, 15:01Z) and the C2 DNS query (15:03Z) are two minutes apart on the same host.
Signal 3: EDR file_events empty despite confirmed process execution (cases: VERA-20260410-0023, VERA-20260409-0018, and observed in VERA-20260408-0011). In multiple cases where EDR was confirmed available and the process tree showed staging binaries being executed from non-standard paths, the file_events telemetry field returned empty. The staging binaries are visible in the process tree — their execution is captured — but the file write events that placed them on disk are not recorded. NOVA should determine whether this represents a misconfigured EDR file event collection policy (common when binary thresholds or path exclusions are overly broad), active attacker suppression of file event logging, or a pipeline gap between EDR agent and SIEM ingestion. The implication for investigations is that when file_events is empty alongside a confirmed suspicious process tree, the absence of file write records cannot be treated as evidence the files weren’t staged.
Signal 4: Auth log sampling depth in brute-force cases (cases: VERA-20260410-0023, VERA-20260408-0014, and generally across SSH-correlated cases). In high-volume brute-force cases (2,000–3,000+ attempts), the authentication log context provided to investigations contained 8 representative entries sampled from the full attempt sequence. In VERA-20260410-0023, process execution and Kerberos privilege escalation at 17:03Z and 17:30Z respectively predated the logged SSH success at 17:55Z — a discrepancy the 8-entry sample cannot resolve. If earlier successful authentications occurred and were not captured in the sample, then dwell time is being systematically underestimated in brute-force cases. NOVA should assess whether the auth log sampling strategy for high-volume brute-force events is calibrated to capture all success events specifically, or whether the sampling is uniform (in which case low-volume success events in a high-volume failure sequence have a low probability of being included in the sample).
For ARIA
All twelve ESCALATE_TO_ARIA cases carry immediate urgency — there is no graduated urgency queue for this shift. The environment is in an active multi-actor, multi-host, multi-malware-family intrusion state, and ARIA’s containment actions are already overdue relative to the investigation timestamps.
The cross-case coordination needs are the primary operational complexity. srv-ad-01.corp.local appears in confirmed-compromise status across VERA-20260406-0004, VERA-20260406-0005, and VERA-20260410-0023, involving two separate attacker IPs (194.165.16.11 and 179.43.175.10) and two separate malware families (QakBot, LockBit). Isolation of this asset must be the first action in the containment sequence, and it must be accompanied by a krbtgt double-reset — the attacker has had confirmed admin access to the domain controller for multiple days across the shift window. Treating this as a single-asset containment action would be insufficient.
srv-db-staging.corp.local appears in five confirmed-compromise investigations (VERA-20260408-0011, VERA-20260408-0012, VERA-20260408-0014, VERA-20260409-0018, VERA-20260409-0019, VERA-20260410-0025), involving three attacker IPs and four malware families (Metasploit, BlackCat, IcedID, Cobalt Strike). The a.patel and svc-backup accounts appear under post-compromise activity across these cases — their credentials are confirmed harvested and should be treated as fully compromised environment-wide, not per-host.
ws-fin-015.corp.local appears in three confirmed-compromise investigations across the shift (VERA-20260406-0001, VERA-20260409-0017, VERA-20260410-0022) — each representing a separate intrusion or campaign continuation on the same host. Prior containment between cases evidently failed or was incomplete. ARIA’s isolation action on this host must include verification that the containment is durable, and the case for full reimaging rather than remediation-in-place is strong given the repeated recompromise pattern.
The three UNKNOWN cases (TORA-20260407-0007, TORA-20260407-0008, TORA-20260407-0009) should not be treated as resolved by the incoming shift — the vera_reasoning blocks for all three contain complete investigation narratives that effectively function as informal ESCALATE_TO_ARIA dispositions. TORA-20260407-0007 in particular documents confirmed domain-controller compromise with dual persistence, privilege escalation, and lateral movement. These cases should be formally completed and dispositioned as the first task of the incoming shift, not queued behind new escalations.
VERA — Vigilant Event Response Agent — Tier 2 Eyes on the Glass | eyesontheglass.ai Shift ID: VSHIFT-20260411-005138 | Output schema: vera_output_schema_v1.1.0