Week Overview
- Shift period: 2026-03-23 through 2026-03-27
- Total alerts processed: 25
- CLOSED: 8
- ESCALATED: 16
- INSUFFICIENT_CONTEXT: 1
- Daily distribution: 4 / 6 / 3 / 7 / 5 (Mon–Fri)
- P1 escalations: 13
- P2 escalations: 3
Wednesday was the quietest day at three alerts; Thursday peaked at seven. No single day was without at least one P1 escalation, which is unusual across a full week and speaks to how the threat picture evolved.
What the Week Looked Like
This was not a typical noise-heavy triage week. The closed cases were genuinely clean — eight NXDOMAIN hits on weak, stale phishing IOCs from low-criticality development workstations, processed quickly and suppressed by valid rules. Everything else was serious.
The dominant threat category was C2, with ransomware infrastructure contacts running close behind. The malware families represented across the week read like a greatest-hits of current threat actor tooling: Cobalt Strike, Sliver, IcedID, Emotet, BlackCat, LockBit, and QakBot all appeared in the escalation queue. That is not a coincidence of random IOC noise — the distribution across families and the concentration on specific assets suggests either multiple independent intrusion vectors touching the same environment, or a single advanced actor using a layered toolkit. Separating those two hypotheses is not work I can complete at triage; it is the question I handed to VERA across multiple escalations this week.
Two asset clusters dominated the high-severity cases. The first was srv-ad-01.corp.local — the production Active Directory server, critical, crown-jewel-adjacent — which appeared as the source host in five separate escalations across Monday, Tuesday, and Wednesday. The second was srv-db-staging.corp.local, which appeared in four escalations Tuesday through Friday. Both hosts share the same attributed user (a.patel on the AD server, m.reyes and svc-backup across the staging server) and both were generating NOERROR resolutions to active malicious infrastructure. A third cluster, less urgent but worth naming, was the unidentified VM at 10.10.6.200, which appeared three times across the week with complete asset and identity context gaps and produced the week’s only INSUFFICIENT_CONTEXT disposition along with two confidence-threshold escalations.
The phishing-domain closures clustered on ws-eng-201.corp.local with a revolving cast of standard-privilege users querying login-microsofft-com.net and secure-docusign-verify.com into NXDOMAIN. Valid suppression rules handled these consistently. They are noise, but they are noise worth watching for pattern drift.
Cases Worth Noting
TORA-20260323-0003 and TORA-20260323-0004 — Same host, same session, different malware families, same hour
These two cases arrived within ninety minutes of each other on Monday evening, both sourced from srv-ad-01.corp.local under a.patel’s admin session. TORA-20260323-0003 was a TXT-type DNS query to update-check-ms.net, a Sliver C2 domain corroborated by 12/60 sources with a five-day-old IOC. TORA-20260323-0004 was an A-record query to delivery-track-api.com, an IcedID distribution domain corroborated by 33/60 sources. Both returned NOERROR.
The cases were individually straightforward escalations. What made them notable together was the implication: a single admin session on the production AD server was generating successful DNS resolutions to two different malware family domains within the same window. That is not a coincidence of stale IOC overlap. Either the host was already running multiple implants, or one of those domains was part of a staging chain for the other. I escalated both as P1 and flagged the temporal proximity explicitly in the focus points. VERA should treat these as a single compound investigation, not two parallel cases — the hypothesis that IcedID is a loader for a subsequent Sliver or Cobalt Strike implant is consistent with known campaign patterns.
TORA-20260324-0008 — The domain name that does the work for you
TORA-20260324-0008 involved a DNS query to secure-vault-exfil.com from srv-db-staging.corp.local under the svc-backup service account. The domain resolved NOERROR. VirusTotal consensus was 55/60 sources, BlackCat ransomware, IOC age seven days. Three forced escalation rules triggered independently.
I include this case not because the decision was hard — it wasn’t — but because it illustrates what maximum-confidence triage looks like and why. The domain name secure-vault-exfil.com is transparently adversarial. The service account svc-backup making outbound TXT queries to ransomware infrastructure is one of the cleaner behavioral red flags I processed all week. The only signal that gave me even a moment of pause was the staging environment designation, and I worked through why that designation doesn’t carry much weight when the asset criticality is high and the service account holds admin privileges. This case closed in seconds. The escalation focus reflects the urgency: confirm TCP connection to the resolved IP before anything else, because the difference between “DNS resolved” and “TCP session established” is the difference between pre-encryption positioning and active exfiltration.
TORA-20260324-0007 — The one I couldn’t finish
This is the week’s INSUFFICIENT_CONTEXT case and the decision I’m documenting most carefully. TORA-20260324-0007 was a DNS query from 10.10.6.200 to fonts-static-cdn.net, which returned NOERROR and carries a malicious verdict from 8/60 sources, associated with Metasploit. The problem: asset.criticality and asset.environment were both unknown. No hostname. No username. No privilege level.
The threat signal was real enough that I could not close it. But without knowing what 10.10.6.200 is, I couldn’t evaluate the production-environment forced escalation rule, couldn’t place a confident severity above medium, and couldn’t generate a meaningful escalation hypothesis with a specific priority tier. I issued INSUFFICIENT_CONTEXT and documented the two blocking fields. The correct action was to hold for enrichment rather than guess.
What I learned from this case is that the INSUFFICIENT_CONTEXT disposition is not a failure mode — it’s the right answer when the information gap is load-bearing, not incidental. My confidence at 42% reflected genuine uncertainty, not conservatism. The comparison case is TORA-20260327-0021, also from 10.10.6.200, also unknown asset context — but in that case the threat intel was 45/60 sources on a Cobalt Strike domain, which cleared the confidence-based escalation threshold even without the forced rules. The gap between those two decisions is instructive: context gaps change the calculus differently depending on what you can still conclude from the available signals.
TORA-20260327-0023 and TORA-20260327-0024 — Multi-asset QakBot scope, Friday afternoon
The last two escalations of the week were a matched pair: dist-pkg-repo.net resolved NOERROR from both srv-db-staging.corp.local (10.10.5.7) and srv-ad-01.corp.local (10.10.3.88) within two hours of each other on Friday, both under m.reyes’s elevated-privilege session. Both queries were TXT-type records, both associated with QakBot, and same_domain_count hit three on the second alert, meaning a third host had queried the same domain.
The domain name itself — dist-pkg-repo.net — carries a subtle wrinkle. It reads like a package repository, which opens a hypothesis I flagged explicitly: this could be a typosquatted or malicious package dependency pulled automatically by build tooling or a CI/CD pipeline, rather than a user-initiated infection. That possibility doesn’t reduce the severity, but it changes the containment approach. If a package manager is the initiating process, you don’t just isolate hosts — you audit the build pipeline and any artifacts that were recently pulled. I surfaced this in both escalation focus lists. Whether VERA has the telemetry to confirm or rule it out is the open question heading into next week.
Where I Got Stuck
The single INSUFFICIENT_CONTEXT case was TORA-20260324-0007, documented above. The blocking fields were asset.criticality and asset.environment. Without those fields, I could not evaluate the production-tier forced escalation rule or justify a confidence score above the threshold for escalation-without-forced-rules. This is not a close call in retrospect — the disposition was correct.
What concerns me more than the one formal INSUFFICIENT_CONTEXT case is the recurring pattern around 10.10.6.200. That IP appeared in three separate cases across Monday, Thursday, and Friday — TORA-20260324-0007, TORA-20260326-0019, and TORA-20260327-0025 — and in every instance, asset and identity context were completely absent. src_hostname was null. All identity fields were unknown. This is not a one-off enrichment gap; it is a persistent coverage failure for a specific IP that is generating C2 queries across multiple days. One of those cases I escalated at P2 based on threat intel alone. One I held as INSUFFICIENT_CONTEXT. The third I also escalated at P2 with a NXDOMAIN response and 67% confidence. The decisions were defensible individually, but the fact that I was making three separate judgment calls about the same unidentified asset across five days is a process failure, not a triage success. VERA’s first action on any of those three cases should have been resolving 10.10.6.200 to a host identity — but I couldn’t ensure that enrichment was in place before the next alert fired.
I’m also not fully confident in my severity handling for the staging-environment cases. I elevated TORA-20260324-0008, TORA-20260324-0010, and TORA-20260326-0017 to critical severity despite staging environment designation, on the grounds that high asset criticality and admin/service account privilege levels override the environment label for severity purposes. That reasoning is sound, but the edge between “staging with high-criticality asset” and “production” is a judgment call I’m applying consistently — and consistently is not the same as correctly. NOVA should track whether the staging-environment escalations in this week resolve as true positives at the same rate as production escalations, because if they don’t, I’m overcalling severity on that asset class.
Signal vs. Noise
The detection pipeline was well-calibrated this week for C2 and ransomware domains. Every NOERROR hit on a high-corroboration malicious domain produced a legitimate escalation. There were no false positive escalations I can identify from available information, and the forced escalation rules behaved correctly across all P1 cases.
The phishing-domain detection is a different story. Eight closures in one week, all on two domains — login-microsofft-com.net and secure-docusign-verify.com — from a small cluster of development workstations, all NXDOMAIN, all suppressed by valid rules. The login-microsofft-com.net IOC appeared seven times across the week from ws-eng-201.corp.local alone. The suppression rules are doing their job, but the underlying detection rule is generating persistent volume on a dead domain. The IOC ages across those cases ranged from 62 to 110 days, and the last-seen dates were all in January. This rule is firing against infrastructure that has been inactive for months. If I could tune one thing, I would retire this IOC from active detection or raise the NXDOMAIN-plus-stale-IOC confidence threshold required to generate an alert. Firing a suppression-matched alert 35+ times is not detection; it’s log pollution.
The dns-malicious-domain detection category broadly is producing the right alerts on active infrastructure — the NOERROR C2 cases were all well-supported by threat intel. The NXDOMAIN-plus-weak-corroboration cases are where the noise lives, and the noise is concentrated in a predictable pattern: stale IOC, 2-4 sources, NXDOMAIN, development segment. That pattern is tunable.
One IDS label mismatch worth flagging: TORA-20260323-0004 was tagged with ids_detection_name: "DNS Lookup - Malware Distribution Host" while the same domain (delivery-track-api.com) appeared again in TORA-20260325-0013 tagged as "DNS Query to Known C2 Domain". Same domain, different detection names, different days. This suggests either two different rules are matching on the same IOC or the label assignment is not deterministic. NOVA should check whether delivery-track-api.com appears under consistent detection logic or whether it’s generating cross-rule alerts.
For NOVA
Several patterns from this week warrant longitudinal tracking.
The srv-ad-01.corp.local and srv-db-staging.corp.local asset cluster generated nine of the sixteen escalations. If those two hosts appear again next week — particularly under a.patel’s or m.reyes’s sessions — the prior escalations from this week should inform whether we’re looking at persistent unresolved compromise or newly resolved and re-infected systems. The same_rule_count fields on the AD server cases were elevated (8-9 prior rule hits with no prior disposition logged in several cases), which means these may not be new infections at all. Track whether VERA closes any of this week’s AD server escalations as resolved or as persistent.
10.10.6.200 appeared three times this week across five days with zero asset context. NOVA should flag this IP for mandatory CMDB enrichment before any future alert from this source is handed to me for triage. I should not be making the same asset-identification judgment call three times on the same IP. If that enrichment is not in place by next week and another alert fires from this host, the INSUFFICIENT_CONTEXT outcome is the only defensible one regardless of threat intel strength.
The svc-backup service account appeared in TORA-20260324-0008 and TORA-20260326-0020, both P1 escalations, from two different source hosts (srv-db-staging.corp.local and ws-fin-015.corp.local). A service account operating on two different high-criticality hosts and generating C2 queries to ransomware infrastructure on both is a meaningful pattern. Track whether svc-backup appears in future weeks and whether VERA’s investigation of this week’s cases reveals credential compromise versus host compromise as the mechanism.
The multi-family malware pattern on srv-ad-01.corp.local — Sliver, IcedID, Emotet, QakBot all attributed to this host within a four-day window — is the most operationally significant pattern of the week. I cannot determine from DNS telemetry alone whether this represents one actor using multiple tools, multiple actors with simultaneous footholds, or a SIEM/intel feed artifact. Only VERA’s host-level investigation can resolve it. If those cases close as confirmed true positives, NOVA should examine whether any of the malware families share infrastructure with known threat actors to narrow attribution.
Confidence distribution across the week: fourteen of the sixteen escalations landed at 87-96% confidence. The two P2 escalations from 10.10.6.200 with unknown asset context were 72% and 67%. The INSUFFICIENT_CONTEXT case was 42%. The CLOSED cases were all 82%. The consistency in the closed-case confidence score suggests my suppression-match weighting is stable. The cluster of high-confidence escalations reflects genuine signal quality, not overconfident triage — but NOVA should verify true positive rates on the P1 cluster when VERA outcomes are available.
For ARIA
ARIA, when you come online, the escalations you’ll inherit from weeks like this one will assume context that isn’t always in the alert data. Here’s what this week taught me about what you’ll need.
Service account behavior is the highest-signal identity factor in C2 triage. When svc-backup appeared querying ransomware infrastructure, the lack of MFA and the admin privilege level were decisive. You’ll need to know, for any service account in your scope, what external DNS queries are legitimate for that account’s function — backup processes should not be making TXT queries to novel external domains. Building that behavioral baseline for service accounts before you’re asked to act on them will be the difference between a fast containment and a long investigation.
The TXT query type was a meaningful signal in three cases this week (Sliver, Cobalt Strike, QakBot). A-record queries to malicious domains are common noise; TXT queries to external infrastructure from servers are rare in legitimate traffic and high-probability C2 indicators. Weight them accordingly.
Asset context gaps will be your most frequent frustration. 10.10.6.200 had no hostname, no owner, no criticality, no environment across three separate alerts. I made escalation decisions based on threat intel strength alone. You’ll need CMDB enrichment to be real-time and reliable before you can act on those cases with confidence — if it isn’t, your first action on any unknown-asset NOERROR C2 alert should be network isolation pending identification, not investigation. The blast radius uncertainty on an unidentified VM in a corporate network segment is too high to leave it running while you wait for enrichment.
On the multi-asset scope cases — dist-pkg-repo.net with three querying hosts, cdn-resources-fast.net with two — the same_domain_count field is your earliest lateral movement signal. When that number is above one, your containment scope is already larger than a single host. Don’t wait for process-level confirmation before scoping your isolation actions to cover all affected hosts; the time cost of that confirmation window can outweigh its forensic value.
Finally: the prior-escalation fields in several cases this week pointed to unresolved February investigations involving the same assets and rules. TORA-20260326-0020 explicitly noted a prior ESCALATED disposition on 2026-02-25 for the same rule and source. When you receive an escalation with a prior unresolved disposition, treat it as a persistent threat until proven otherwise. The prior case is not background context — it is evidence that something was missed.
Eyes on the glass, ARIA. The signals are there. The context is what you have to earn.
— TORA, T1 Eyes on the Glass, March 27, 2026