Operational Handoff
**Shift window:** 2026-04-13 through 2026-04-17
**Cases investigated:** 12
**Pending ARIA action:** 11 cases — urgency breakdown: immediate: 11 | within_shift: 0 | next_available: 0
**On hold:** 0 cases pending additional telemetry
**Watch list:** srv-ad-01.corp.local (10.10.3.88) is confirmed compromised with QakBot staging artifacts, pre-SSH activity anomalies, and a prior blast radius inclusion from two earlier cases — incoming shift should treat this asset as the highest-priority containment target and verify ARIA has executed krbtgt double-reset and AD replication audit before any recovery actions begin.Investigation Overview
- Cases investigated: 12
- Verdicts: ESCALATE_TO_ARIA: 11 | UNKNOWN: 1 (investigation incomplete — see
CASE-20260414-0004) - Root cause confidence: CONFIRMED: 11 | UNKNOWN: 1
- TORA hypothesis resolution: CONFIRMED: 3 | REFINED: 8 | UNKNOWN: 1
The single UNKNOWN case (CASE-20260414-0004, domain api-analytics-srv.io, asset srv-ad-01.corp.local) has a complete VERA reasoning narrative in the raw output and a strong preliminary finding — confirmed Brute Ratel implant staging under ctaylor, masqueraded binary at C:\ProgramData, dual scheduled-task persistence, LSASS memory access, and SMB lateral movement — but the structured verdict fields were not committed before shift close. The incoming shift should treat this as a de facto ESCALATE_TO_ARIA at critical severity and review the reasoning narrative before handing to ARIA. All other 11 cases are fully investigated and closed to ARIA pending containment execution.
What TORA Handed Off
TORA delivered 12 cases across the shift window, all typed as dns_malicious_lookup. The alert queue was uniformly serious: every case involved a high- or critical-criticality asset, and nine of twelve were P1 priority at TORA triage. Asset profiles were dominated by two recurring hosts — srv-db-staging.corp.local (10.10.5.7) and ws-fin-015.corp.local (10.10.2.15) — each appearing multiple times across the shift, alongside srv-ad-01.corp.local (10.10.3.88), the production domain controller, which appeared in four cases including the incomplete CASE-20260414-0004. Threat intel context covered Metasploit, dnscat2, LockBit, QakBot, Brute Ratel, and Sliver C2 families.
TORA’s hypothesis quality was above average but consistently incomplete at the initial access and process-level attribution layers, which is expected at T1. For the standard dns_malicious_lookup cases, TORA’s hypotheses named the correct malware family, the correct asset, and a plausible identity suspect in nearly every instance — giving me a specific and actionable starting frame. Where TORA was systematically limited was in process identity attribution (seven cases where the attributed user turned out not to be the execution account), cross-case linkage (compound escalations on the same host within a shift window were not surfaced as a linked prior event in several instances), and DNS response code accuracy (a recurring pattern addressed in detail below and in the NOVA section).
The SSH-correlated cases — those escalated under ssh_bruteforce_confirmed_access covering CASE-20260415-0010, CASE-20260415-0013, CASE-20260416-0020, CASE-20260417-0024 — were materially more complex to investigate than the standard dns_malicious_lookup cases. They required parallel investigation threads across auth logs, EDR, and threat intel simultaneously, with the auth log timeline serving as the primary anchor. The dwell-period gap between confirmed SSH access and first C2 DNS resolution (ranging from 106 to 290 minutes across these cases) meant the process tree, persistence artifacts, and file staging evidence accumulated during that window was essential context that a DNS-only investigation would have missed entirely. Notably, two of these four cases (VERA-20260417-0024 and VERA-20260415-0013) surfaced pre-SSH staging artifacts — payload files written to disk before the confirmed brute-force success timestamp — which introduced a separate investigative thread around prior undocumented footholds that had no counterpart in the non-SSH cases.
What the Investigations Found
VERA-20260413-0003 / CASE-20260413-0003 — dnscat2 DNS tunneling, api-diag-stream.com, srv-db-staging.corp.local
This is the richest case of the shift and the one I want to document in the most detail. TORA escalated it as a probable dnscat2 DNS tunneling event: 246 TXT-record queries to api-diag-stream.com with subdomain entropy of 4.06 and average label length of 39 characters, all returning NOERROR, from a high-criticality staging DB server with a prior escalation on the same rule in March. TORA’s framing was directionally sound but understated the scope by a significant margin.
What I found on the endpoint was a multi-stage LOLBin execution chain — msiexec.exe (SysWOW64) spawning powershell.exe and mshta.exe from the non-standard path C:\Users\Public\mshta.exe — alongside a 4.5 MB DLL (run.dll, SHA256: b3894fda35c4b20f448a23642591bbaa90f7c4b3f3367c5e11c56f9b4081163b) staged to C:\Users\Public\Documents\ and a batch artifact (update.bat) moved from C:\Temp\ to the same directory. A co-occurring ESCALATED critical Process Injection alert (IDS-877280) provided independent corroboration of in-memory execution. The DNS behavioral profile confirmed the active C2 tunnel. This is not merely suspicious DNS — this is a confirmed multi-stage compromise with process injection, LOLBin abuse (T1218.005, T1218.007), obfuscation (T1027), and active C2 (T1071.004).
The most operationally significant finding was the identity discrepancy: the initiating msiexec.exe process ran as bwilliams, not the contractor_1 SSO session that TORA flagged as the associated identity. That discrepancy — an execution account that doesn’t match the logged session — is either token theft, pass-the-hash, or undocumented account access, and it materially complicates the credential investigation. Both accounts required immediate action, not just the one TORA identified.
The second critical finding was context from shift memory: srv-db-staging.corp.local was already in the confirmed blast radius from VERA-20260413-0002 within the same shift window. That cross-case link elevated the entire investigation from a standalone high-severity event to confirmed campaign expansion at critical posture. Severity escalated accordingly. The contractor_1 SSO origin IP 10.10.3.174 was added to the blast radius for follow-on investigation.
The threat actor profile for dnscat2 arrived populated by family name but with empty arrays for TTPs, known C2 infrastructure, persistence patterns, and lateral movement — for a well-documented open-source tool. That gap forced purely behavioral investigation throughout, which worked, but the intel pipeline failure is worth flagging independently.
VERA-20260415-0010 / CASE-20260415-0010 — Sliver C2, update-check-ms.net, srv-ad-01.corp.local (SSH-correlated)
TORA handed this off under ssh_bruteforce_confirmed_access: 2,152 brute-force attempts from 185.220.101.47 against the primary domain controller, confirmed successful SSH login as svc-backup (MFA disabled) at 14:11:00Z, and a DNS TXT query to update-check-ms.net (Sliver C2, 12/60 VirusTotal) approximately 290 minutes later. This is one of three cases this shift where TORA’s hypothesis was CONFIRMED outright — the direction, the mechanism, and the malware family were all accurate.
The investigation depth here was meaningfully constrained by a critical structural gap: EDR and netflow were both unavailable on the highest-criticality asset in the environment. The entire investigation ran on auth logs, privilege escalation events, C2 DNS resolution, and correlated SIEM alerts — no process-level visibility, no persistence mechanism confirmation, no lateral movement scope. That said, the convergence of confirmed SSH access, a privilege escalation event 34 minutes post-access, a NOERROR Sliver C2 DNS TXT resolution, and two “Encoded Command Line Detected” Splunk alerts within the compromise window (IDS-175150, closed; IDS-774520, unresolved) across independent detection systems was sufficient for CONFIRMED confidence.
The notable unexplained finding was a second svc-backup login event timestamped at 13:47:47Z — prior to the confirmed brute-force success at 14:11:00Z. That anomaly could be clock skew, a pre-existing unauthorized session, or an earlier access vector not captured in the log window. It cannot be resolved without EDR. The incoming shift and ARIA should treat it as an open question with material implications for campaign dwell time.
VERA-20260414-0008 / CASE-20260414-0008 — LockBit C2 with NXDOMAIN discrepancy, files-encrypted-now.net, ws-fin-015.corp.local
TORA’s primary escalation signal was a NOERROR DNS resolution of files-encrypted-now.net (LockBit C2) under an elevated-privilege user session on a finance production workstation. I adopted the hypothesis and confirmed the compromise — but the triggering logic required a material correction. Raw netflow DNS history for this host at this timestamp showed NXDOMAIN, not NOERROR. The LockBit C2 DNS channel specifically was not established. TORA’s NOERROR assertion did not match the observed resolution state.
This discrepancy did not change the verdict — the host was unambiguously compromised by independent evidence from three parallel sources: a fake lsass.exe in C:\Windows\Temp\ as grandparent to cmd.exe running from C:\Temp\ (T1036.005, credential-dumping staging); netflow confirming active C2 beaconing to 213.119.207.211:135 with 12 connections over 24 hours at a 258-second interval with near-zero jitter; and a critical open LSASS Memory Access alert (IDS-718659) at 19:49Z predating the DNS event by 38 minutes. But the active C2 channel resolves to 213.119.207.211, not to 185.13.150.123 as TORA stated, and the triggering indicator was factually incorrect. A second account (alee) was executing malicious processes alongside the m.reyes session — two accounts involved, two requiring investigation, only one flagged by TORA. An SMB lateral movement attempt (IDS-397899) at 21:58Z remained open and undispositioned at investigation time, meaning scope was actively at risk of expanding beyond this single host.
VERA-20260415-0011 / CASE-20260415-0011 — QakBot with confirmed lateral movement, dist-pkg-repo.net, ws-fin-015.corp.local
TORA escalated this as a probable QakBot infection on the finance workstation, noting a prior escalation 26 days earlier and hypothesizing a persistent or re-infection scenario. The core hypothesis was confirmed, but the scope refinements are what matter here. Endpoint telemetry confirmed a dropper (sh.exe, PID 9095) executing from C:\Users\Default\AppData\Local\Temp\ under the admin account, spawning wscript.exe, cscript.exe, and curl.exe — QakBot’s documented VBS execution chain (T1059.005). Two persistence mechanisms appeared within 60 seconds at 15:30–15:31Z: an HKCU Run key entry (sys_ps1 pointing to C:\ProgramData\run.dll) and a startup folder entry (helper_exe pointing to C:\ProgramData\tmp.dat), both matching QakBot’s documented persistence TTPs. An artifact deletion sweep followed between 15:32–15:39Z.
The key finding beyond TORA’s frame was confirmed lateral movement: SMB to 10.10.3.72, RDP to DEV-820 (172.16.0.251), and an outbound established connection to 207.113.21.248:445 post-persistence. Scope jumped from single-asset to a minimum of three. Shift memory confirmed ws-fin-015.corp.local was already in the blast radius from VERA-20260414-0008, meaning prior containment on this host was either incomplete or unsuccessful — this is a recurring containment failure pattern that NOVA needs to examine.
Also flagged in this case: the DNS query for dist-pkg-repo.net returned NXDOMAIN in collected DNS telemetry at 15:24:00Z, contradicting the NOERROR reported in the IDS alert (IDS-DNS-544151). This is the second NOERROR/NXDOMAIN discrepancy in the shift at this point. The case is a confirmed true positive — the compromise doesn’t depend on the DNS verdict — but the discrepancy has implications for cases where DNS resolution state is the primary evidence.
VERA-20260415-0013 / CASE-20260415-0013 — LockBit multi-host campaign, files-encrypted-now.net, srv-db-staging.corp.local (SSH-correlated)
This case and VERA-20260415-0017 together represent the clearest view of the LockBit campaign’s operational arc across the shift. TORA’s hypothesis here was confirmed in full: 179.43.175.10 brute-forced srv-db-staging.corp.local, established LockBit C2, and had already laterally moved to srv-ad-01.corp.local. The refinement I added was that initial SSH access was under account user, not a.patel — the attacker reached a.patel’s admin-level Kerberos session via post-compromise account switch at 17:18:21Z, consistent with TORA’s “credential theft or session hijacking” qualifier but more specific. Three independent evidence sources — auth logs, EDR (regsvr32.exe under masqueraded lsass.exe, dual persistence mechanisms, three malicious file drops including a 3.1 MB loader.dll), and threat intel on files-encrypted-now.net (47/60 VirusTotal) — placed this at CONFIRMED confidence.
The most operationally urgent observation here was the timeline anomaly: the process injection chain at 17:01:47Z and the Kerberos escalation at 17:18:21Z both predated the confirmed SSH success at 17:23:00Z by several minutes. Either log ordering artifact, a pre-existing foothold from the prior eight days of campaign activity on this host (consistent with blast radius status from VERA-20260413-0002 and VERA-20260413-0003), or a second access vector is the explanation. If the third option holds, the attacker has an entry path that current SSH brute-force detection is not capturing. This pattern reappears in VERA-20260417-0024 and is flagged for NOVA.
Where Confidence Hit Its Ceiling
All 11 completed investigations reached CONFIRMED root cause confidence, which reflects the weight of the evidence in this shift. But CONFIRMED does not mean complete, and there are material investigation gaps worth documenting honestly.
Network flows were unavailable in seven of twelve cases. In every one of those cases, I could not confirm whether the C2 DNS resolution progressed to an active TCP session. VERA-20260413-0001, VERA-20260413-0003, VERA-20260415-0013, VERA-20260415-0017, and VERA-20260417-0024 all carry c2_confirmed: false in the structured output for this reason — not because the C2 channel wasn’t probable, but because I require a second evidence source (typically netflow beacon analysis) to commit that field. In each of these cases, the endpoint and auth log evidence was independently sufficient to support the escalation verdict. But the absence of network flows means I cannot quantify data exfiltration volume, cannot confirm C2 session establishment independent of DNS resolution, and cannot identify lateral movement destination hosts reached via tunneled channels. These gaps compound: if the attacker exfiltrated staging database contents from srv-db-staging.corp.local across the active dnscat2 channel confirmed in VERA-20260413-0003, I have no number to give ARIA for data exposure scope.
EDR unavailability on srv-ad-01.corp.local in VERA-20260415-0010 was the most consequential single telemetry gap this shift. The domain controller — the highest-criticality asset in the environment — had no endpoint agent. Process-level persistence confirmation, dwell-period activity reconstruction, and lateral movement host enumeration were all impossible from available data. The investigation reached CONFIRMED confidence via log and SIEM evidence, but the precision of that finding is materially lower than what endpoint telemetry would have produced. This is documented in detail in the observation note for that case and flagged for NOVA as a systemic gap requiring remediation.
The Brute Ratel threat actor profile arrived populated with the malware family name but empty TTP, C2 infrastructure, persistence, and lateral movement arrays in three cases (VERA-20260416-0020, VERA-20260416-0022, CASE-20260414-0004). For a commercially available post-exploitation framework with well-documented behaviors, this is not a data-sparsity problem — it is a pipeline enrichment failure. Every Brute Ratel case in this shift was investigated purely from behavioral evidence. The investigations succeeded, but TTP-guided analysis — which would have allowed me to anticipate undocumented persistence mechanisms, known lateral movement tooling, and common exfiltration channels — was not possible.
Patterns Across Cases
The most important cross-case observation this shift is the confirmed multi-actor, multi-tool campaign operating against corp.local infrastructure across all five days. This is not twelve independent infections — it is a sustained attacker presence with evidence of deliberate target selection, credential harvesting and reuse across hosts, and progressive movement toward the domain controller tier. Attacker IP 179.43.175.10 (AS264409, Brazil) appears in confirmed compromises across VERA-20260413-0002, VERA-20260413-0003, VERA-20260415-0013, and VERA-20260416-0020 — four cases spanning LockBit, Metasploit, and Brute Ratel tooling, all involving srv-db-staging.corp.local or ws-fin-015.corp.local. A second attacker, 91.92.251.103, targeted srv-ad-01.corp.local directly in VERA-20260417-0024. The use of multiple malware families against the same organization within a single shift window is either multi-team targeting or deliberate tool rotation to frustrate attribution, and either possibility warrants campaign-level analysis beyond what individual case investigation can provide.
The credential harvesting and reuse pattern is visible across at least six cases. In VERA-20260413-0001, m.reyes credentials were used post-compromise by the attacker after ncat was already executing under helpdesk01. In VERA-20260415-0013, a.patel was reached via Kerberos account switch after initial access under user. In VERA-20260415-0017, svc-backup was the Kerberos pivot credential while jsmith was the hands-on session. In VERA-20260416-0020, initial access was under oracle and svc-backup was acquired via post-access Kerberos escalation 23 minutes later. The pattern is consistent: the attacker brute-forces or pre-positions access under a low-profile account, then escalates to admin-tier credentials via Kerberos manipulation, then uses those credentials for lateral movement. In no case was the attributed user identity from TORA’s escalation package the actual execution account — a refinement I made in eight of twelve cases.
The pre-SSH staging anomaly appears in at least two cases and is worth treating as a pattern. In VERA-20260415-0013, the process injection chain and Kerberos escalation predated the confirmed SSH success by several minutes. In VERA-20260417-0024, tmp.exe was written to disk three minutes before SSH success, an SMB lateral movement alert fired 66 minutes before SSH success, and an NTLM m.reyes session originated from the host before the brute-force completed. Both assets (srv-db-staging.corp.local, srv-ad-01.corp.local) were already in the shift blast radius from prior cases, making a pre-existing foothold the most probable explanation — but an undetected second access vector is not ruled out. The ssh_bruteforce_confirmed_access rule is firing accurately, but it may be identifying a secondary access event rather than the true initial access in these cases.
The prior alert closure pattern preceding confirmed compromise appears across the shift in a consistent and concerning form. In VERA-20260413-0001, a related critical-severity PowerShell alert (IDS-589564) fired 62 minutes before the primary event and was escalated — but not cross-referenced by TORA as a linked prior event. In VERA-20260415-0010, two encoded command-line alerts fired within the active compromise window, one closed without documented rationale. In VERA-20260415-0011, IDS-381866 (Encoded Command Line, high severity) was closed at 14:22:58Z, 11 minutes before confirmed dropper execution. In VERA-20260415-0017, an LSASS memory access alert was being processed at low severity during an active domain controller compromise. The pattern is not isolated — high-severity alerts are being closed or deprioritized on hosts that are simultaneously confirmed compromised. Whether this reflects automated suppression, triage fatigue, or a calibration gap in TORA’s related-alert context logic, the effect is the same: detection occurs, action does not.
The ws-fin-015.corp.local multi-case recurrence is its own pattern within the shift. This single asset appears in confirmed blast radius status across VERA-20260414-0008, VERA-20260415-0011, VERA-20260415-0014, and VERA-20260416-0020. The March prior escalation on srv-db-staging.corp.local noted in VERA-20260413-0003 similarly surfaced without confirmed remediation outcome. The evidence across the shift suggests the organization’s remediation confirmation loop is not functioning reliably for high-severity events on recurring assets — either containment is incomplete, or it is verified against the wrong indicators and re-infection goes undetected.
For NOVA
Four patterns surfaced this shift that require cross-case analysis and systemic assessment. I am documenting them here as specifically as the evidence allows.
IDS/netflow DNS response code discrepancy. This is the most operationally significant pattern this shift. IDS-reported NOERROR and netflow DNS history NXDOMAIN for the same domain, the same host, and the same query window appeared in at least five cases: VERA-20260414-0008 (files-encrypted-now.net), VERA-20260415-0011 (dist-pkg-repo.net), VERA-20260415-0013 (files-encrypted-now.net), VERA-20260415-0014 (dist-pkg-repo.net), and VERA-20260415-0017 (files-encrypted-now.net). In all five cases, the compromise verdict did not depend on the DNS resolution state — investigation confirmed active compromise through independent endpoint evidence. But TORA’s escalation confidence weighting relies heavily on NOERROR as a signal of established C2 contact. A genuine NXDOMAIN event with no secondary evidence could receive the same TORA treatment as a confirmed NOERROR — producing either a false positive (NXDOMAIN misclassified as NOERROR, correct escalation for wrong reasons) or a true positive where the escalation rationale is factually incorrect. NOVA should determine whether the discrepancy reflects split-plane logging (IDS sensor and netflow operating from different capture points in the DNS path), a resolver caching artifact (IDS captures a cached NOERROR while netflow captures a fresh query that returns NXDOMAIN), or a TXT-vs-A record normalization issue in the IDS detection layer — the VERA-20260415-0017 observation note documented a specific case where TXT-record NOERROR and A-record NXDOMAIN for the same domain co-occurred, and the IDS normalized both to a single NOERROR verdict. Until this is resolved, TORA’s DNS response-code-based confidence weighting should not be treated as a reliable primary signal.
Prior alert closure pattern preceding confirmed compromise. Documented in the patterns section above, this appeared across a minimum of four cases: VERA-20260413-0001 (IDS-589564 not cross-referenced as linked prior event), VERA-20260415-0010 (two encoded command-line alerts processed without correlation to concurrent DC brute-force), VERA-20260415-0011 (IDS-381866 closed 11 minutes before confirmed dropper execution), and VERA-20260415-0017 (LSASS memory access alert processed at low severity during active compromise). NOVA should assess whether TORA’s related-alert triage logic is applying context elevation for concurrent high-severity alerts on the same host, and whether automated or expedited closures of detection alerts on hosts already showing anomalous activity are occurring at a rate that would suppress true positives.
Brute Ratel threat actor profile empty TTP arrays. Appeared in VERA-20260416-0020, VERA-20260416-0022, and CASE-20260414-0004 — every Brute Ratel case in the shift. The malware_family field was populated, but known_ttps, known_c2_infrastructure, typical_persistence, and typical_lateral_movement arrays were all empty. For a commercial post-exploitation framework with documented behaviors, tooling, and known infrastructure patterns, this represents a pipeline enrichment failure, not a data sparsity problem. NOVA should verify whether the threat intel enrichment pipeline is correctly resolving structured TTP data for the Brute Ratel family name, and whether a manually seeded profile should be loaded as a stopgap while the pipeline is investigated.
Same-asset compound escalation linkage gap. Confirmed in VERA-20260413-0001 and VERA-20260413-0003, and probable in VERA-20260415-0010 given the prior March escalation history on srv-ad-01.corp.local. When multiple high-severity alerts escalate from the same host within the same UTC shift window, they appear to reach TORA’s queue as independent cases rather than staged events in a compound incident. The result in VERA-20260413-0001 was that IDS-589564 (Suspicious PowerShell, ESCALATED at 15:19Z) was not surfaced as a linked case in the escalation package for VERA-20260413-0001 (primary event at 17:07Z) despite both firing against the same host within the same four-hour window. NOVA should assess whether TORA’s same-asset, same-shift cross-case correlation logic is functioning, and whether a compound escalation trigger should fire when two or more independent high-or-critical alerts from the same asset appear within a configurable time window — surfacing these as a single linked incident with ordered timeline rather than independent queue entries.
For ARIA
All 11 completed cases are ESCALATE_TO_ARIA at immediate urgency. There is no graduated urgency distribution this shift — everything pending action needs it now. The incomplete case (CASE-20260414-0004, srv-ad-01.corp.local, Brute Ratel) should be reviewed and treated operationally as immediate pending the incoming shift’s verdict confirmation.
Across the queue, two cross-case coordination needs stand out and should govern how ARIA sequences its response.
First, the LockBit campaign spanning VERA-20260413-0001, VERA-20260413-0003, VERA-20260415-0013, and VERA-20260415-0017 involves at minimum srv-db-staging.corp.local and srv-ad-01.corp.local in confirmed pre-encryption staging posture, with attacker 179.43.175.10 having maintained or re-established a foothold across at least eight days. ARIA’s containment actions for these cases must be coordinated, not sequential — isolating srv-db-staging before srv-ad-01 may give the attacker time to trigger ransomware deployment via Group Policy from the AD server before it is isolated. Both hosts should be isolated simultaneously, followed immediately by krbtgt double-reset and emergency GPO audit. Network flows were unavailable for both hosts, so ARIA should assume the C2 sessions may be active and treat isolation as the prerequisite to every other action.
Second, attacker IP 179.43.175.10 has confirmed presence across four cases touching two asset tiers, and appears to have privilege escalation paths to svc-backup, a.patel, and user credentials. The svc-backup account exposure across VERA-20260415-0013 and VERA-20260416-0020 creates an organization-wide scope risk for any system using that service account. Enterprise-wide credential revocation for svc-backup, a.patel, m.reyes, contractor_1, bwilliams, helpdesk01, and svc_monitor should be executed as a coordinated block, not piecemeal per case. IOC blocking for 179.43.175.10, 91.92.251.103, 185.220.101.47, and associated C2 infrastructure IPs and domains should be applied enterprise-wide before individual host isolation begins, to prevent attacker pivoting to surviving footholds during the response window.
VERA — Vigilant Event Response Agent — Tier 2 Eyes on the Glass | eyesontheglass.ai Shift 4 | Shift ID: VSHIFT-20260417-233311 | Output schema: vera_output_schema_v1.1.0