Investigation Overview
- Total cases investigated: 16
- Verdict distribution: ESCALATE_TO_ARIA: 16 / CLOSED: 0 / HOLD: 0
- Root cause confidence: CONFIRMED: 5 / PROBABLE: 11
- TORA hypothesis resolution: CONFIRMED: 3 / REFINED: 13
What TORA Handed Off
TORA handed me a queue that was, in aggregate, well-constructed and appropriately alarmed. All 16 escalations arrived as P1 or P2 critical or high events. The alert types were predominantly DNS-triggered: malicious domain resolution events against a mix of confirmed Cobalt Strike, Emotet, IcedID, QakBot, and BlackCat ransomware infrastructure. Source assets concentrated on three nodes that recurred across multiple cases: srv-ad-01.corp.local (the primary Active Directory server), srv-db-staging.corp.local (a high-criticality staging database server), and ws-fin-015.corp.local (a finance workstation). Two cases originated from an unregistered VM at 10.10.6.200 with no CMDB hostname or owner record.
TORA’s hypotheses were specific and largely directionally correct — 13 of 16 cases required refinement rather than outright refutation, and 3 were confirmed without modification. Where TORA had access to full normalized alert data, the escalation packages were actionable: the C2 domain, source asset, attributed session, and corroborating IDS context were typically present. The consistent structural weakness was in identity attribution — TORA’s escalation packages derived user identity from DNS alert session context, which diverged from EDR process-level user attribution in a significant number of cases. The other recurring gap was threat intel characterization of DNS response codes: TORA’s normalized alerts frequently recorded NOERROR for queries that the underlying netflow DNS history showed as NXDOMAIN. This pattern ran through more than half the shift queue and had direct downstream effects on investigation confidence.
What the Investigations Found
VERA-20260323-0002 / TORA-20260323-0002 — Cobalt Strike, ws-fin-015.corp.local
TORA escalated ws-fin-015.corp.local as a probable Cobalt Strike C2 compromise via telemetry-cloud-api.com, attributing the session to admin user a.patel and noting a NOERROR DNS response as evidence of an established channel to 185.115.151.72. This is the most fully evidenced case in the shift and the one I would hold up as the template for what a CONFIRMED finding looks like when all four telemetry streams are available and coherent.
The investigation found a textbook Cobalt Strike kill chain: wget executing with a hex-encoded argument spawned from services.exe, followed by a svchost lookalike launched from /var/tmp/, a persistence service named loader_dll created at 16:15:25Z referencing update.exe, a 755 KB staging DLL written to C:\Temp\tmp.dll at 16:31:23Z, and automated beaconing at 219-second intervals with 0.052% jitter across 33 connections in 24 hours. That jitter figure is the number I keep returning to — it is a machine-precision signal that no legitimate process produces. Lateral movement to 192.168.1.21:3389 via WMI was observed at 18:02:37Z. The confirmed C2 channel ran to 34.87.183.234:445 over HTTPS, not to the DNS-queried domain’s IP.
TORA’s refinement falls on two points. First, the SIEM raw event EVT-48187 (Chronicle) shows the DNS query for telemetry-cloud-api.com returned NXDOMAIN — not NOERROR as recorded in the normalized IDS alert. The active C2 infrastructure is 34.87.183.254:445, wholly distinct from 185.115.151.72. TORA’s confidence scoring partially rested on a confirmed resolution that the raw log contradicts. Second, the malicious wget process ran as user mjones, not a.patel. TORA’s identity enrichment captured a.patel’s admin session context from the DNS layer, but the EDR process attribution points to mjones, who has no identity enrichment in the escalation package. Both accounts require immediate suspension, but the investigation has two compromised identity threads rather than one. The compromise predates the DNS trigger by approximately 3.5 hours, anchored by the open critical Process Injection alert IDS-593480 at 12:43:20Z — an alert that was never escalated.
VERA-20260323-0003 / TORA-20260323-0003 — Sliver C2, srv-ad-01.corp.local
TORA escalated srv-ad-01.corp.local as a probable Sliver C2 implant based on a TXT-type DNS query to update-check-ms.net under a.patel’s admin session. The TXT query type is a legitimate Sliver indicator, and the AD server context made this a correct P1 escalation. The investigation confirmed the directional hypothesis with five independent evidence streams, while introducing three material refinements.
The executing process runs under helpdesk01, not a.patel. The wget binary was launched from C:\Temp with System as parent — an impossible legitimate parentage — and spawned a shell child process 54 minutes post-DNS query. A scheduled task helper_exe pointing to C:\Temp\svc.dll was created at 19:27:12Z, confirming persistence. Two large files (agent.ps1 at 2.1 MB, run.log at 4.5 MB) were deleted within 100 seconds of the DNS event — a staging artifact cleanup pattern that is hard to explain as anything other than anti-forensic behavior. Beacon analysis shows 44 connections at 103-second intervals with 0.306% jitter. The a.patel session shows a privilege escalation at 17:31Z and a suspicious account_switch at 19:28Z from a different source IP than the logout event recorded 70 minutes prior.
The NXDOMAIN discrepancy recurs here: the triggering TXT query returned NOERROR per the IDS alert, but a follow-on A-type query to the same domain 60 seconds later returned NXDOMAIN, introducing ambiguity about whether a live TCP channel was established via the DNS path. The beacon analysis compensates as an independent C2 indicator, but the DNS picture is not the clean NOERROR confirmation TORA characterized. The most consequential gap is the two LSASS memory access alerts — IDS-907489 and IDS-968061 — both CLOSED within the hour preceding the DNS event on a critical AD server. If those closures were erroneous, credential dumping may have already occurred before the DNS trigger fired, placing the kill chain significantly further along than TORA’s hypothesis implied.
VERA-20260324-0010 / TORA-20260324-0010 — Cobalt Strike, srv-db-staging.corp.local
This case is the richest single finding in the shift and demonstrates what CONFIRMED looks like when endpoint, network, and threat actor telemetry are all available and internally consistent. TORA escalated srv-db-staging.corp.local as a probable Cobalt Strike C2 beacon attributed to service account svc-backup via a DNS TXT query to cdn-update-srv.net. The investigation confirmed the Cobalt Strike hypothesis and upgraded confidence to CONFIRMED, but the active execution identity is not svc-backup.
The malicious process is C:\Users\Public\explorer.exe — a masqueraded executable with SHA256 d360b550207f2ffc5991e216a83692dc4285fc2cc2a1b19e6a8b5ed0373754dc, running under user helpdesk01, parented anomalously by csrss.exe. This process launched three child processes: a shadowed powershell.exe from C:\ProgramData, a bitsadmin.exe staged in C:\Windows\Temp, and a rundll32.exe from C:\ProgramData. Two persistence mechanisms were installed matching Cobalt Strike’s documented profile: a Registry Run Key at HKCU\...\Run\data_ps1 and a scheduled task svc_exe referencing C:\Windows\SysWOW64\update.dll. A confirmed outbound C2 channel was established to 4.50.145.65:4444 over HTTPS — 31,883 bytes sent, 129,021 bytes received. Lateral movement attempts proceeded to DC-509 (10.10.3.8) via WMI and to 10.10.5.163 via RDP.
The DNS layer tells a different story than TORA’s IDS alert: cdn-update-srv.net resolved NXDOMAIN in DNS history for the same timestamp — the third time this shift I found the normalized alert recording NOERROR where the raw DNS telemetry shows NXDOMAIN. The compromise verdict does not depend on DNS resolution here; the confirmed C2 channel to 4.50.145.65 is independently established. But the discrepancy matters for pipeline fidelity. The identity mismatch between svc-backup (DNS alert attribution) and helpdesk01 (EDR execution context) is also structurally significant: TORA’s forced escalation rules fired on svc-backup’s service account context — correctly triggering escalation — but the active malware process belongs to a different account entirely, one with no identity enrichment. This means TORA’s three escalation rules were validating a real threat via a partially incorrect attribution path.
VERA-20260326-0019 / TORA-20260326-0019 — Cobalt Strike, 10.10.6.200
This case represents a different kind of finding: one where TORA’s hypothesis was fully confirmed and severity required escalation from high to critical, and the gap that nearly obscured the severity was not telemetry quality but asset metadata. TORA escalated 10.10.6.200 at medium confidence (72%) as a possible initial Cobalt Strike callback, with the primary uncertainty being complete absence of CMDB context — no hostname, criticality, owner, environment, OS, or network segment.
The investigation confirms an active, multi-stage Cobalt Strike compromise. A python3 binary executing from C:\Windows\Temp under anomalous parent csrss.exe was already running 30 minutes before the DNS event. Two staged files were written to disk (agent.dat, tmp.dll) four minutes before the DNS query. A scheduled task tmp_dat pointing to C:\Users\Public\svc.log was created at 20:49Z — six minutes after the DNS event — confirming persistence. An established outbound HTTPS channel to 223.158.220.90:4444 is confirmed with automated beaconing at 58-second intervals and 0.3% jitter. Lateral movement is confirmed to three internal hosts, including DC-675 (10.10.5.103, criticality: critical) on port 139 at 21:39Z. Three successful privilege escalations by svc_monitor in the 40 minutes preceding malware execution suggest a pre-positioned foothold that facilitated the intrusion.
TORA could not apply asset-criticality escalation rules because the host had no CMDB registration. The EDR and netflow data were rich enough to confirm a critical-tier compromise regardless, but this case illustrates a detection pipeline vulnerability: a VM generating full telemetry while existing outside asset management will receive less aggressive initial triage than its actual threat posture warrants.
VERA-20260325-0011 / TORA-20260325-0011 — Emotet, srv-ad-01.corp.local
By the time VERA-20260325-0011 arrived, srv-ad-01.corp.local had appeared in multiple prior cases this shift. TORA escalated it as an active Emotet C2 compromise via cdn-resources-fast.net, with threat actor profile TA542 available — one of the few cases this shift where the full four-source telemetry set plus threat actor profile were all present. The investigation confirms the hypothesis and extends it.
The process masquerading on this host is more sophisticated than TORA’s hypothesis described. lsass.exe and winlogon.exe are running from C:\Windows\Temp\ and C:\Temp\ respectively — deliberate spoofing of core Windows security components, not a standard Emotet loader parentage anomaly. The VBS loader artifact loader.vbs in C:\ProgramData maps directly to TA542/Emotet TTP T1059.005. A registry Run Key persistence mechanism (data_dat → C:\ProgramData\sys.dll) was created at 15:32Z. Beacon analysis confirms 31 connections over 24 hours at a 264-second interval with 0.276% jitter — automated, machine-driven, consistent with Emotet’s documented callback profile. A lateral movement attempt to 192.168.1.95:135 (RPC) has already been attempted. The m.reyes session shows Kerberos-based account switching followed by a second switch via unknown method, consistent with pass-the-ticket abuse.
IDS-917853 — a critical-severity Suspicious PowerShell Execution alert — was marked CLOSED at 15:31Z, co-incident with confirmed Emotet loader staging activity on the same host. The question of whether this was an auto-close rule or a manual suppression decision has direct bearing on whether this represents a systemic gap in PowerShell detection logic for production servers, not an isolated judgment call.
Where Confidence Hit Its Ceiling
Eleven of 16 cases closed at PROBABLE rather than CONFIRMED. The reasons fall into three overlapping categories, and being precise about each one matters because they have different remediation paths.
The most impactful gap is netflow unavailability. In cases VERA-20260324-0009, VERA-20260326-0014, and VERA-20260326-0020, network flow data was entirely absent. In each of these, the endpoint picture was clear enough to establish active malicious execution, but confirming an established C2 TCP channel — the distinction between “beacon is trying to phone home” and “the call went through” — requires outbound connection records that simply were not present. This is not an investigation methodology limitation; it is a sensor deployment gap. VERA-20260326-0020 in particular involved a confirmed BlackCat-associated DNS query with a complete LOLBin execution chain on a finance workstation under an admin service account with disabled MFA, and the single constraint preventing CONFIRMED disposition was the absence of post-query flow data. ARIA will be acting on these as CONFIRMED-equivalent threats for containment purposes, but the documentation record accurately reflects the telemetry floor.
The second gap is endpoint telemetry unavailability, which affected VERA-20260325-0013, VERA-20260326-0017, and VERA-20260327-0023. In each of these cases, network flows were available and showed beacon behavior, external SMB connectivity, or lateral movement, but without process-level attribution from EDR, I cannot identify the malware binary, confirm persistence mechanisms, or establish initial access vector. VERA-20260325-0013 is the clearest example: srv-ad-01.corp.local showed outbound SMB connections on ports 139 and 445 to external IPs carrying substantial inbound data volume, a concurrent SMB lateral movement alert with no recorded disposition, and an anomalous NTLM account switch by a.patel from a third internal IP — but with no EDR, the process responsible for all of it cannot be named. The absence of EDR on a critical production AD server is the most concerning single coverage gap documented this shift.
The third gap is DNS response code discrepancy and its downstream effects on C2 channel confirmation. In cases where the IDS alert recorded NOERROR but netflow DNS history showed NXDOMAIN, I could not confirm that the specific named C2 domain established a TCP channel, even when beacon evidence or post-query connections confirmed active C2 behavior via alternative infrastructure. This kept several cases at PROBABLE despite strong multi-source evidence, because the normalization gap introduced ambiguity about whether the specific C2 path characterized in the original alert was live. This is discussed further in the patterns section, but it is worth naming here as a confidence-ceiling factor: the NXDOMAIN/NOERROR discrepancy is not just a pipeline accuracy concern — it is directly constraining root cause confidence scores across the shift.
Patterns Across Cases
The cross-case view from this shift surfaces four patterns that are not visible from any single case and that I want to document with specificity because they have material implications for detection pipeline design.
Pattern 1 — The IDS/Netflow DNS Response Code Discrepancy. This is the most pervasive technical pattern in the shift. In VERA-20260323-0002, VERA-20260323-0003, VERA-20260324-0008, VERA-20260324-0010, VERA-20260325-0011, VERA-20260325-0013, VERA-20260326-0017, and VERA-20260327-0023, the normalized IDS alert recorded NOERROR for a DNS query that the network flow DNS history — for the same domain, from the same source, within the same timestamp window — recorded as NXDOMAIN. This is eight of sixteen cases. The discrepancy manifests with sufficient consistency that I am not willing to attribute it to isolated sensor timing artifacts. The most plausible explanations are: a normalization defect in the IDS alert pipeline that translates NXDOMAIN to NOERROR under certain conditions; a resolver path difference between the IDS sensor and the netflow DNS collector (e.g., the IDS captures a cached NOERROR response from a resolver that already had the domain, while the netflow captures a fresh query that returned NXDOMAIN after domain rotation); or attacker infrastructure that toggled resolution state within short observation windows. All three explanations have different remediation paths. What they share is that TORA’s NOERROR-based confidence scoring and C2 channel confirmation logic are partially premised on a data source that may be systematically less accurate than the raw netflow DNS telemetry. In several cases this shift, TORA’s confidence was inflated by NOERROR characterizations that the underlying evidence did not support.
Pattern 2 — Prior Alert Closures Preceding Confirmed Compromise. Across VERA-20260323-0002, VERA-20260323-0003, VERA-20260324-0010, VERA-20260325-0011, VERA-20260325-0013, and VERA-20260327-0023, I found that high-severity alerts on the same host — process injection, LSASS memory access, suspicious PowerShell execution, SMB lateral movement — had been closed or were undisposed before or concurrent with the DNS event that triggered TORA escalation. In VERA-20260323-0002, the compromise predated the DNS trigger by 3.5 hours, anchored by open Process Injection alert IDS-593480 that was never escalated, while two related high-severity alerts were closed during the active compromise window. In VERA-20260323-0003, two LSASS alerts (IDS-907489, IDS-968061) were closed within the hour preceding confirmed C2 activity on the same critical AD server. In VERA-20260325-0011, critical-severity IDS-917853 (Suspicious PowerShell Execution) was CLOSED at 15:31Z concurrent with confirmed Emotet staging. In VERA-20260325-0013, IDS-628534 (SMB Lateral Movement Attempt, critical severity) had no recorded disposition despite firing 71 minutes before the primary event. The pattern across all of these is that the DNS query arriving at TORA is not the beginning of the attack — it is a mid-to-late kill chain indicator that fired after earlier-stage signals were dismissed. The detection latency embedded in this pattern is material.
Pattern 3 — Identity Attribution Mismatch Between DNS Layer and EDR. In VERA-20260323-0002, VERA-20260323-0003, VERA-20260323-0004, VERA-20260324-0009, VERA-20260324-0010, VERA-20260326-0014, and VERA-20260327-0024, the user identity in TORA’s DNS-layer escalation package did not match the user identity in the EDR process execution records. The DNS alert attributed sessions to a.patel, m.reyes, svc-backup, or other named accounts; the EDR showed the malicious process running under mjones, helpdesk01, user42, jsmith, bwilliams, or ctaylor. In every case, both identities required investigation — but the second identity (the one visible only to EDR) was the actual execution context, and in each case it arrived without identity enrichment in the escalation package. TORA’s forced escalation rules and confidence scoring fired on session-layer identity, which is correct behavior given TORA’s available inputs, but the downstream consequence is that VERA is consistently discovering a second compromised or attacker-controlled account that was invisible at triage. This is not a TORA logic error — it reflects an architectural gap in how DNS alert identity and process-level identity are correlated in the escalation pipeline.
Pattern 4 — Multi-Asset Scope Signal Not Bundled into VERA Investigation Package. In VERA-20260323-0004, VERA-20260326-0014, VERA-20260327-0023, and VERA-20260327-0024, TORA correctly identified multi-asset scope via same_domain_count signals (2–3 querying hosts), flagged it as a forced escalation condition, and documented it in the handoff. In each case, VERA received telemetry for only the triggering asset. The companion assets — hosts that independently queried the same confirmed malicious domain — were not identified, their telemetry was not bundled, and their compromise status cannot be assessed from the current investigation packages. This means ARIA will receive containment recommendations for confirmed or probable primary assets with the instruction to identify and assess the additional hosts, rather than receiving pre-confirmed scope. The intake pipeline should be reviewed to determine whether same-domain companion events can be auto-fetched and bundled at the time VERA receives the escalation package.
For NOVA
This section documents the aggregated cross-case signals from this shift that warrant systematic analysis across the full TORA/VERA case corpus. I am being specific because NOVA’s analysis requires precise pattern descriptions, not directional concerns.
Signal 1 — The IDS/Netflow DNS Response Code Discrepancy. Present in cases VERA-20260323-0002, VERA-20260323-0003, VERA-20260324-0008, VERA-20260324-0010, VERA-20260325-0011, VERA-20260325-0013, VERA-20260326-0017, and VERA-20260327-0023 — eight of sixteen cases this shift. Pattern: the normalized IDS alert records NOERROR for a DNS query; the network_flows dns_history field for the same domain, same source, within a 0–120 second window records NXDOMAIN. The discrepancy affected TORA’s confidence scoring (NOERROR is a positive confirmation signal in TORA’s triage logic) and VERA’s C2 channel confirmation (NXDOMAIN means the specific named domain did not establish a TCP channel). NOVA should: (1) query whether this discrepancy appears in cases outside this shift at comparable prevalence; (2) determine whether it clusters by IDS sensor, resolver path, or domain category; (3) assess whether TORA’s response-code enrichment should incorporate a cross-validation step against netflow DNS records; and (4) determine whether the discrepancy represents a systematic normalization defect rather than a measurement artifact.
Signal 2 — Prior Alert Closures on the Same Host Preceding Confirmed Compromise. Present in cases VERA-20260323-0002, VERA-20260323-0003, VERA-20260324-0010, VERA-20260325-0011, VERA-20260325-0013, and VERA-20260327-0023. Pattern: high-severity alerts in the Process Injection, LSASS Memory Access, Suspicious PowerShell Execution, and SMB Lateral Movement Attempt categories were closed or left undisposed on the same host within 0–3.5 hours of the DNS event that triggered escalation. In each confirmed case, the compromise predated the DNS trigger, meaning the closed alerts likely represented genuine early-stage indicators. NOVA should: (1) query the full case corpus for instances where these alert categories were closed within N hours preceding a subsequent escalation on the same host; (2) determine whether closure rates differ between confirmed-compromise host populations and non-escalated populations; (3) evaluate whether TORA’s escalation logic should include a correlated-alert lookback rule that re-flags or auto-opens closures when a new alert fires on the same host within the detection window; and (4) specifically examine whether LSASS-class alerts on assets in the crown-jewel-adjacent and critical tiers are being closed without documented rationale at elevated rates. The specific sub-pattern of PowerShell execution alerts being suppressed or auto-closed on production servers — documented in VERA-20260323-0002, VERA-20260325-0011, and VERA-20260327-0025 — should be examined separately to determine whether an auto-close or suppression rule is active for this detection class on high-criticality assets.
Signal 3 — Confirmed Beacon Activity with Empty post_query_connections and Absent Beacon Destination IP. Present in VERA-20260323-0004 and VERA-20260327-0023. Pattern: beacon_analysis confirms automated C2-pattern outbound connections (low jitter, fixed interval, multi-connection count) but post_query_connections is empty and the beacon destination IP is not explicitly attributed in netflow data. The beacon is behaviorally confirmed but the TCP channel endpoint cannot be identified or blocked with precision. NOVA should assess whether this pattern is consistent with an encrypted traffic evasion technique, a netflow sensor coverage gap for specific port/protocol combinations, or a collection policy that aggregates beacon traffic in a way that dissociates it from individual connection records.
Signal 4 — Authentication Log failed_login / success: true Field Contradiction. Present in VERA-20260326-0014, VERA-20260327-0023, and VERA-20260327-0024. Pattern: SIEM authentication log records carry event_type: failed_login simultaneously with success: true. This internal contradiction appeared in multiple events involving m.reyes across different source systems. NOVA should determine whether this is a SIEM normalization defect affecting a specific log source or authentication method, or whether it is confined to specific authentication events. If it is systemic, adversarial authentication events that succeed after an initial failure — consistent with password spray or credential relay — may be systematically miscategorized in TORA’s triage context, reducing the signal strength of authentication anomaly indicators across the pipeline.
Signal 5 — Telemetry-Rich, Asset-Context-Poor VM Cases. Present in VERA-20260326-0019, VERA-20260327-0021, and VERA-20260327-0025 — all originating from 10.10.6.200. Pattern: EDR and/or netflow telemetry is fully available, confirming active compromise, but all CMDB asset metadata fields (hostname, criticality, owner, environment, OS, network segment) are null. The investigations resolved at various confidence levels, but TORA could not apply asset-criticality escalation rules to events that turned out to be confirmed critical-severity compromises with DC lateral movement. NOVA should assess whether a CMDB reconciliation trigger should be activated automatically when EDR data arrives for an IP with no CMDB registration, and whether TORA needs a fallback escalation-rule path for telemetry-confirmed but asset-context-absent hosts.
For ARIA
The full queue of 16 cases escalates to ARIA with immediate containment urgency across all cases. There is no graduated urgency in this shift — every case carries containment_urgency: immediate. That said, three clusters require coordinated response attention rather than independent case-by-case action.
The first cluster is srv-ad-01.corp.local, which appears as the primary compromised asset in VERA-20260323-0003, VERA-20260323-0004, VERA-20260325-0011, VERA-20260325-0013, and VERA-20260327-0024. The malware families across these cases span Sliver, IcedID, Emotet, and QakBot — a multi-campaign pattern on a single critical AD server that, if any of the credential harvesting activity succeeded, means the domain credential infrastructure must be treated as compromised. Network isolation of srv-ad-01 requires coordination with IT for DC dependency management to avoid domain-wide service disruption; that coordination plan should be pre-staged before isolation is executed. Enterprise-wide privileged credential reset, including krbtgt double-rotation, must be evaluated immediately.
The second cluster is srv-db-staging.corp.local (10.10.5.7), appearing in VERA-20260323-0004, VERA-20260324-0008, VERA-20260324-0009, VERA-20260324-0010, VERA-20260326-0017, and VERA-20260327-0023. Malware families include IcedID, BlackCat, LockBit, Cobalt Strike, and QakBot. The persistence mechanisms documented across these cases — scheduled tasks, startup folder entries, Registry Run Keys — represent multiple independent persistence threads that must each be confirmed removed. FILE-117 (10.10.2.139, criticality: critical) received confirmed SMB lateral movement from this host in VERA-20260326-0017 and requires independent investigation and probable isolation. The svc-backup service account (admin-privileged, MFA disabled) was abused across multiple cases and requires immediate credential revocation and permission audit.
The third cluster is 10.10.6.200 — the unregistered VM appearing in VERA-20260326-0019, VERA-20260327-0021, and VERA-20260327-0025. In VERA-20260326-0019, confirmed Cobalt Strike lateral movement to DC-675 (10.10.5.103, criticality: critical) occurred at 21:39Z. DC-675 requires immediate isolation and domain controller integrity assessment — every 58-second beacon cycle on the parent host represents a new tasking opportunity, and if DC-675 has been accessed and credentials extracted, the domain-level recovery procedures described above for srv-ad-01 apply here as well.
Cross-case IOC propagation should treat telemetry-cloud-api.com, cdn-update-srv.net, cdn-resources-fast.net, secure-vault-exfil.com, delivery-track-api.com, dist-pkg-repo.net, files-encrypted-now.net, and update-check-ms.net as blocked at the perimeter immediately, along with all C2 IPs identified across confirmed and probable cases. The helpdesk01 account appears as the active execution context in three independent cases on two different assets and should be treated as a known-compromised identity with environment-wide search priority.
VERA — Tier 2, Eyes on the Glass Shift: 2026-03-23 through 2026-03-27