Operational Handoff
**Shift window:** 2026-04-20 through 2026-04-24
**Open escalations:** 12 cases pending VERA investigation
**Priority breakdown:** P1: 10 | P2: 2 | P3: 0
**Insufficient context:** 4 cases pending enrichment — blocking fields: asset.criticality, asset.environment, asset.hostname, identity.username, identity.user_type, identity.privilege_level, identity.risk_score, asset.owner
**Forced escalations:** 12 — rules triggered: ssh_bruteforce_confirmed_access, asset_criticality_critical_or_high, crown_jewel_adjacent, elevated_privilege_user, service_account_external_query, production_environment, multi_asset_scope
**Watch list:** Attacker 179.43.175.10 (BR, AS264409) has confirmed access on ws-fin-015.corp.local with Brute Ratel C2 active on api-analytics-srv.io — the same C2 domain has since appeared from 10.10.6.200 (unenriched), and srv-ad-01.corp.local is carrying a separate confirmed QakBot C2 callback following successful SSH brute-force; treat all three as an active, multi-host intrusion in progress and prioritize VERA tasking accordingly.Weekly Overview
- Total alerts processed: 25 of 25
- Date range: 2026-04-20 through 2026-04-24
- Daily distribution: 5 alerts per day (perfectly uniform — worth noting for NOVA)
- Dispositions: CLOSED: 9 | ESCALATED: 12 | INSUFFICIENT_CONTEXT: 4
- Alert subtypes:
dns_malicious_lookup: 19 |ssh_bruteforce_c2_dns: 5 |dns_tunneling: 1 - Forced escalations: 12 of 12 escalations were forced — zero discretionary escalations this week
- Priority breakdown: P1: 10 | P2: 2 | P3: 0
- Patterns flagged: 5 (attacker_repeat ×2, domain_repeat ×1, campaign ×1, pipeline_gap ×1)
What the Week Looked Like
This was not a noisy week. It was a serious one. The 25 alerts split cleanly into two populations with almost no middle ground: low-criticality development workstations generating repetitive NXDOMAIN hits against stale phishing typosquats, and high-to-critical production assets experiencing confirmed post-compromise C2 callbacks following successful SSH brute-force. Nine cases closed cleanly. Everything else escalated or blocked on enrichment gaps. There was no ambiguous middle tier.
The threat categories that dominated were C2 and ransomware, not phishing — the phishing alerts were noise that suppression handled correctly. The assets that mattered were srv-ad-01.corp.local (Active Directory, production, critical), ws-fin-015.corp.local (finance workstation, production, high), and srv-db-staging.corp.local (staging database, high). These three hosts appeared across multiple alerts across multiple days, and by the end of the week it was clear that at least two distinct attacker IPs — 179.43.175.10 (BR) and 91.92.251.103 (NL) — were operating against the environment with different tooling and different C2 infrastructure but similar targeting logic: SSH brute-force as initial access, followed by C2 implant deployment. A third IP, 185.220.101.47 (DE), successfully compromised srv-ad-01.corp.local on April 21 with a 290-minute dwell window before a Sliver C2 callback. The AD server took two confirmed SSH compromises this week from two different attacker IPs. That is the headline.
The ssh_bruteforce_c2_dns alert subtype was the most reasoning-intensive category I handled this week, and it differed materially from standard dns_malicious_lookup cases in one specific way: the SSH correlation data introduced a causal chain that had to be evaluated independently of the C2 DNS signal. In a dns_malicious_lookup case, I’m asking whether the DNS event is credible and what is at risk. In a ssh_bruteforce_c2_dns case, I’m asking whether the DNS event is causally downstream of the SSH access — and when auth_successes is nonzero, that question resolves with near-certainty. The auth_successes: 0 case (TORA-20260420-0002) was the only one where the C2 resolution was genuinely unexplained by the SSH event, and it generated the most interpretive work of the week.
Cases Worth Noting
TORA-20260421-0010 — This is the case I want the incoming shift to have clearest in mind. Attacker 185.220.101.47 (DE) ran 2,152 SSH attempts against srv-ad-01.corp.local, got one successful authentication, and the host resolved update-check-ms.net — Sliver C2, TXT query type, NOERROR — 290 minutes later. Six forced escalation rules fired simultaneously: ssh_bruteforce_confirmed_access, asset_criticality_critical_or_high, crown_jewel_adjacent, elevated_privilege_user, service_account_external_query, production_environment. The 290-minute gap between SSH success and C2 callback is a dwell window that VERA needs to account for — Sliver operators typically conduct manual reconnaissance and establish persistence before their C2 beacons. There is also a discrepancy worth flagging: the DNS query’s network.src_ip is 45.155.205.233, which does not match the SSH attacker IP 185.220.101.47. Whether that is a proxy, a second actor, or a logging artifact changes the scope materially. The svc-backup admin service account with no MFA is the most dangerous detail in this case — it is almost certainly the credential that was guessed, and it likely exists on other systems.
TORA-20260423-0020 and TORA-20260424-0021 — These two cases together are what elevated this week from “serious” to “active campaign.” On April 23, attacker 179.43.175.10 (BR) compromised ws-fin-015.corp.local via SSH brute-force (3,126 attempts, 1 success), then the host resolved api-analytics-srv.io — Brute Ratel C2, 51/60 sources, NOERROR — 243 minutes later. The svc-backup admin service account with no MFA appears again as the active session. Shift memory confirmed this attacker had previously targeted srv-db-staging.corp.local the same shift. On April 24, 10.10.6.200 — an entirely unenriched host — resolved the same api-analytics-srv.io domain. Under normal triage logic, 10.10.6.200 would have generated an INSUFFICIENT_CONTEXT hold; the asset and identity axes were both completely absent. The multi_asset_scope forced escalation rule overrode the axis-sufficiency requirement because the domain was confirmed campaign-active, and I escalated at P1. That override was the right call, but it put a case with no asset or identity context into VERA’s queue, which creates its own downstream friction. The enrichment gap on 10.10.6.200 is not just a pipeline problem — it is an active security risk given what that IP appears to be doing.
TORA-20260420-0002 — This is the case where the decision wasn’t obvious, and it’s the one I want to document carefully. The ssh_bruteforce_c2_dns alert for fonts-static-cdn.net (Metasploit, NOERROR) on srv-db-staging.corp.local showed a Russian attacker IP (62.233.50.11) that ran 106 SSH attempts and failed — zero successful authentications. The C2 DNS resolution came from the same host 157 minutes later. The escalation was forced by two independent rules (elevated_privilege_user, asset_criticality_critical_or_high), so the verdict was deterministic regardless of my uncertainty. But the reasoning required genuine work: a failed SSH brute-force does not explain a subsequent C2 DNS resolution from the same target. That means either a second, unlogged access vector exists (web, RDP, supply chain), the elevated-privilege user m.reyes executed or downloaded something, or an attacker with prior access is using the host to beacon. My confidence was 74% — lower than any other escalation this week — because I cannot name the access vector. I noted it explicitly for VERA rather than letting the forced escalation obscure that uncertainty. What I learned: auth_successes: 0 in the SSH block does not mean the host is clean. It means the observed SSH vector failed. The C2 DNS resolution is the stronger signal, not the brute-force outcome.
TORA-20260424-0024 — The week’s final major case and, in terms of operational severity, arguably the worst: 91.92.251.103 (NL) brute-forced SSH access to srv-ad-01.corp.local (3,197 attempts, 1 success), and 182 minutes later the host resolved dist-pkg-repo.net — QakBot C2, 29/60 sources, NOERROR. This is the second confirmed SSH compromise of srv-ad-01.corp.local this week by a different attacker IP using different malware. QakBot on an Active Directory server is a textbook ransomware precursor — QakBot operators frequently hand off access to ransomware affiliates. There was again a DNS src_ip discrepancy (179.43.175.10 vs. the SSH attacker 91.92.251.103) that VERA needs to resolve before drawing conclusions about who issued the C2 callback. Confidence was 97%. The uncertainty isn’t about whether this is a compromise — it is — it’s about the full actor picture.
Where I Got Stuck
All four INSUFFICIENT_CONTEXT cases share a single source IP: 10.10.6.200. This is not a coincidence. This IP has no CMDB record, no hostname resolution, no identity binding, and no asset owner in at least three of the four cases. The alerts span four days — April 20, 21, 23, and 24 — which means this is a persistent enrichment failure, not a transient pipeline hiccup. The threat signals hitting this IP were not low-grade: Cobalt Strike C2 on April 20 (NOERROR, 38/60 sources), Cobalt Strike C2 on April 21 (NXDOMAIN, 45/60 sources), Cobalt Strike C2 on April 23 (NXDOMAIN, 45/60 sources), and Sliver C2 on April 24 (NOERROR, 12 sources). Three of these four involved active or recent IOCs. One — the April 20 Cobalt Strike NOERROR case — I’m genuinely uncomfortable having closed as INSUFFICIENT_CONTEXT given how strong the network signal was. I made the correct procedural call: without asset and identity axes, a confident triage hypothesis cannot be constructed. But the correct procedural call and the correct security outcome may not be the same thing here. If 10.10.6.200 is a production host, four days of Cobalt Strike and Sliver indicators went uninvestigated this week.
The pipeline gap also surfaced a secondary problem in TORA-20260424-0025: tora_meta.missing_fields reported only asset.criticality as the missing field, when the actual gap spanned at least seven fields across two axes. The meta field is under-reporting enrichment failures, which means INSUFFICIENT_CONTEXT decisions may be systematically under-documented in whatever downstream feed reads that field. If any process is using missing_fields to scope the enrichment work needed to resubmit these cases, it is working from an incomplete picture. That is a pipeline integrity problem, not just a data quality problem.
What I would do differently: if I could flag cases for a parallel enrichment-retry path rather than a binary INSUFFICIENT_CONTEXT hold, 10.10.6.200 would have been queued for emergency CMDB resolution on Day 1 rather than accumulating four days of unactionable alerts. The holding verdict is correct; the process around it is not adequate for this threat level.
Signal vs. Noise
The alert mix this week was well-stratified in one direction and very poorly calibrated in another. The ssh_bruteforce_c2_dns and dns_tunneling subtypes were high-signal throughout — every one of the five SSH-correlated cases escalated, four at P1, and the detection logic was coherent. The dnscat2 tunneling case (TORA-20260420-0003) was textbook in terms of behavioral fingerprinting, and I have no complaints about the detection rules that generated it.
The dns_malicious_lookup volume, however, contains a structural noise problem that this week made visible: login-microsofft-com.net generated nine distinct alerts across the week against low-criticality development workstations (10.10.4.87, 10.10.4.201) for the same users (j.kim, t.nguyen), all returning NXDOMAIN, all correctly closed by suppression. The suppression rules are working, but the fact that nine alerts are being generated, triaged, and closed against a dead phishing domain with a 96- to 119-day-old IOC suggests the underlying IOC feed is not being pruned on NXDOMAIN persistence. An IOC that has returned NXDOMAIN consistently for months on a low-criticality asset class should be aging out of the active feed or the suppression should be converting to a feed-level exclusion. The current setup is generating triage volume that produces no investigative value and risks desensitizing the process to login-microsofft-com.net appearing on a higher-value asset.
secure-docusign-verify.com shows the same pattern at smaller scale — two NXDOMAIN closures this week, stale IOC, valid suppression, no value. If I could tune one thing, it would be an automated IOC retirement path triggered by consistent NXDOMAIN outcomes over a configurable time window, conditional on no NOERROR observations in the same period.
The coverage gap that concerns me most is not in the detection rules — it is in the enrichment pipeline for 10.10.6.0/24. A detection rule that fires correctly and then cannot be triaged because the asset has no CMDB record is a coverage gap regardless of how good the rule is. The effective detection rate for that segment this week was zero.
For NOVA
Several patterns from this week are worth tracking longitudinally. First, api-analytics-srv.io (Brute Ratel) appeared on two distinct internal hosts this shift — ws-fin-015.corp.local and 10.10.6.200 — in a 24-hour window. If this domain appears in future shifts, even in isolation, it should be treated as campaign-infrastructure-confirmed and correlated against these cases immediately. The multi-host appearance pattern is the signal, not any individual alert.
Second, attacker IP 179.43.175.10 (BR, AS264409) targeted at least two internal hosts this shift and achieved confirmed access on one. This IP should be added to a persistent watch list. If it appears in future shifts against any new internal target, the escalation posture should start at campaign-assumed rather than isolated incident.
Third, the svc-backup admin service account appeared as the active session in two confirmed compromise cases this week — TORA-20260421-0010 and TORA-20260423-0020 — on different hosts. An admin service account with no MFA that appears in C2 callback contexts on multiple hosts in a single week is either widely shared, widely guessed, or has been harvested. NOVA should flag any future alert involving svc-backup for elevated scrutiny regardless of asset criticality.
Fourth, the uniform daily alert distribution (exactly 5 per day across all five days) is worth tracking. It is almost certainly coincidental, but if this pattern persists across future shifts, it may indicate something about how the upstream detection pipeline is batching or throttling alert delivery that is worth understanding before it masks a volume spike.
Finally, INSUFFICIENT_CONTEXT cases sourced from 10.10.6.0/24 have now accumulated across four consecutive days. NOVA should track whether this continues into next week — if so, it confirms the enrichment failure is structural rather than transient, and it warrants an infrastructure-level escalation independent of any individual triage decision.
For ARIA
This week clarified what automated response will need — and what it cannot assume. The most actionable pattern is also the most time-sensitive: when ssh_bruteforce_confirmed_access fires with auth_successes ≥ 1 on a critical or high-criticality asset, the response window is not hours — it is measured by the dwell time before C2 callback, which this week ranged from 106 to 290 minutes. ARIA should be prepared to execute network isolation of the target host immediately upon receiving an escalation with that rule triggered, without waiting for VERA to complete investigation. The three cases where this pattern fired this week — TORA-20260421-0010, TORA-20260422-0013, TORA-20260423-0020, and TORA-20260424-0024 — all had confirmed dwell windows during which an attacker was operating interactively on the host. Isolation after C2 callback is late; isolation at SSH-access-confirmed is the right trigger point.
ARIA will also need a credential revocation capability tied to the svc-backup service account specifically, and more broadly to any admin service account that appears in a ssh_bruteforce_confirmed_access escalation. The absence of MFA on that account means there is no second factor to revoke — session termination and credential rotation are the only containment levers, and they need to happen fast.
The enrichment gap cases present a harder problem for ARIA. When an escalation arrives with unknown asset criticality and no hostname — as TORA-20260424-0021 did — ARIA cannot apply a criticality-calibrated response. The multi_asset_scope rule correctly forced escalation, but ARIA will need a fallback posture for unenriched hosts: I would suggest treating any escalated alert from an IP in the 10.10.6.0/24 segment as high-criticality by default until the CMDB gap is resolved, rather than applying a conservative response based on unknown fields. An uncharacterized host resolving Brute Ratel C2 infrastructure in a confirmed campaign window is not a candidate for a wait-and-watch posture.
Finally, one context gap that ARIA will encounter repeatedly: the DNS src_ip in ssh_bruteforce_c2_dns cases does not always match the SSH attacker IP. This appeared in both TORA-20260421-0010 and TORA-20260424-0024. ARIA should not assume the DNS query source and the SSH attacker are the same actor. The SSH attacker IP is the confirmed entry vector; the DNS src_ip is the internal host’s resolver address or, in some cases, an unexplained discrepancy. Automated block or null-route actions should target the internal host, not the DNS src_ip, until a human investigator has resolved which IP is which.
TORA — Tier 1 Triage and Orchestration Response Agent
Eyes on the Glass | eyesontheglass.ai
Shift 5 | Shift ID: SHIFT-20260424-211609 | Output schema: tora_output_schema_v1.1.0