Operational Handoff
**Shift window:** 2026-04-06 to 2026-04-10
**Open escalations:** 15 cases pending VERA investigation
**Priority breakdown:** P1: 15 | P2: 0 | P3: 0
**Insufficient context:** 3 cases pending enrichment — blocking fields: asset.criticality, asset.environment, identity.username, asset.hostname, identity.user_type, identity.privilege_level
**Forced escalations:** 15 — rules triggered: ssh_bruteforce_confirmed_access, asset_criticality_critical_or_high, crown_jewel_adjacent, production_environment, elevated_privilege_user, service_account_external_query, multi_asset_scope
**Watch list:** Attacker 185.56.83.83 (RU) has same_src_ip_count=4 and confirmed footholds on both srv-ad-01.corp.local and srv-db-staging.corp.local with active BlackCat and IcedID C2 callbacks — VERA should begin here and treat all four attacker target slots as potentially active.Weekly Overview
- Total alerts processed: 25 of 25
- Date range: 2026-04-06 through 2026-04-10
- Daily distribution: Flat — 5 alerts per day across all five days
- Dispositions: ESCALATED: 15 | CLOSED: 5 | INSUFFICIENT_CONTEXT: 3 | UNKNOWN: 2
- Alert subtypes:
dns_malicious_lookup: 14 |ssh_bruteforce_c2_dns: 11 - Forced escalations: 15 (100% of ESCALATED cases)
- Priority distribution: P1: 15 | P2: 0 | P3: 0
- Patterns flagged to NOVA: 12 high-severity patterns across domain_repeat, attacker_repeat, and campaign types
The two UNKNOWN verdicts — TORA-20260406-0003 and TORA-20260407-0010 — represent pipeline output failures on otherwise clear-cut escalations, both involving assets and signals that should have produced forced escalation outputs. These are documented below.
What the Week Looked Like
This was not a noisy week. It was a dangerous one. Every escalation came in at P1, and the alert mix split almost evenly between dns_malicious_lookup and ssh_bruteforce_c2_dns subtypes — but those two categories are not equivalent in triage complexity, and the difference mattered constantly.
The dns_malicious_lookup cases were the faster reads. A NOERROR response against a high-confidence IOC on a known-critical asset closes the reasoning loop quickly. Most of this week’s standalone DNS cases arrived with enough asset and identity context to trigger forced escalation rules within the first few fields. The phishing-category DNS closes — all five of them — were just as fast in the opposite direction: NXDOMAIN, weak intel, valid suppression, low-criticality development hosts. No ambiguity, no lost time.
The ssh_bruteforce_c2_dns cases were structurally different. They required two-stage reasoning: first, evaluate the SSH access event on its own terms — attempt volume, authentication success count, target asset class — and then evaluate whether the downstream DNS query represents a genuine post-compromise callback or a coincidental lookup. In every confirmed-access case this week, the answer was unambiguous. Auth successes greater than zero on a critical or high-criticality asset, followed within hours by a NOERROR resolution of a known C2 domain, is not a detection artifact. It is the attack sequence. The ssh_bruteforce_c2_dns alert format encodes both events in one record, which is a genuine detection advantage — it forces the causal question that a standalone DNS alert cannot.
The threat categories that dominated were ransomware and post-exploitation frameworks: secure-vault-exfil.com resolving across four assets as BlackCat C2, dist-pkg-repo.net spreading as QakBot infrastructure for a third consecutive week, api-analytics-srv.io appearing on multiple hosts as Brute Ratel C2 following confirmed SSH compromise of the domain controller, and fonts-static-cdn.net surfacing as Metasploit C2 on two separate hosts hit by two separate attacker IPs. The asset concentration was significant: srv-ad-01.corp.local and srv-db-staging.corp.local appeared repeatedly across both attack types. ws-fin-015.corp.local was the third recurring target. By mid-week it was clear these were not unrelated incidents. By Thursday, three named attacker IPs — 185.56.83.83 (RU), 179.43.175.10 (BR), and 104.244.77.14 (US) — had each demonstrated multi-host targeting behavior within the shift window, and domain overlap across their respective C2 callbacks indicated either coordinated infrastructure or a shared campaign playbook.
Cases Worth Noting
TORA-20260407-0007 — Brute Ratel on the domain controller, confirmed access, Russian origin. This was the case that crystallized the week’s threat picture. Attacker 185.56.83.83 (RU, AS57523) drove 2,507 SSH attempts against srv-ad-01.corp.local on a non-standard port, achieved 2 successful authentications, and 242 minutes later the domain controller resolved api-analytics-srv.io — confirmed Brute Ratel C2 at 51/60 VirusTotal sources with a 9-day-old IOC and a NOERROR response. Six forced escalation rules fired simultaneously. The ssh_bruteforce_confirmed_access trigger made everything else secondary, but the combination of crown-jewel adjacency, admin-privileged user a.patel (who also appeared on ws-fin-015 and srv-db-staging throughout the week — an identity pattern worth VERA’s attention), outdated patch level, and the Brute Ratel association with resourced threat actors made this the highest-concern case of the week in isolation. Shift memory confirmed this same attacker IP returned on Friday in TORA-20260410-0025, hitting srv-db-staging and triggering a BlackCat C2 callback — a two-host confirmed campaign by one actor across four days.
TORA-20260408-0012 — BlackCat C2 with a failed SSH brute-force. This case was the most structurally interesting of the week. Attacker 91.92.251.103 (NL) drove 695 SSH attempts against srv-db-staging.corp.local and got zero successful authentications. But 62 minutes later, the same host resolved secure-vault-exfil.com — a 55/60 VirusTotal BlackCat C2 domain — with a clean NOERROR response. The ssh_bruteforce_c2_dns alert format implied a causal chain that the data did not support: the brute-force failed, but the C2 beacon fired anyway. This means a separate, unidentified compromise vector is active on srv-db-staging. That gap in the causal chain is critical for VERA: process-tree forensics and auth log analysis are the only way to identify the real initial access, and the SSH failure actually rules out the most obvious candidate. I escalated at P1 under asset_criticality_critical_or_high rather than ssh_bruteforce_confirmed_access, and flagged the unknown vector explicitly. What this case taught me is that the ssh_bruteforce_c2_dns alert subtype can mask forensic complexity — the correlated SSH event can be a distraction from a different entry point, and VERA needs to test both hypotheses rather than assuming the brute-force is the cause.
TORA-20260410-0023 — Attacker 179.43.175.10 reaches the domain controller. If TORA-20260407-0007 was the highest-concern single case, TORA-20260410-0023 was the most operationally significant because of what shift memory revealed. On its face: 2,401 SSH attempts against srv-ad-01.corp.local, 1 successful authentication, followed 251 minutes later by a QakBot C2 callback to dist-pkg-repo.net. But shift memory showed that attacker 179.43.175.10 (BR) had previously targeted srv-db-staging.corp.local this same shift, and dist-pkg-repo.net carried active escalation history from April 2nd and April 7th — no apparent containment outcome from either. The pattern was staging server to domain controller progression, which is the canonical lateral movement path. The 251-minute dwell gap before C2 fired suggests manual operator activity rather than automated tooling. VERA needs to reconstruct what happened on the domain controller during that window before the QakBot beacon. The service account svc-backup with MFA disabled was the compromised identity, and svc-backup appeared on multiple hosts across the week — the blast radius of that account’s compromise is a separate investigation thread VERA should open immediately.
TORA-20260409-0017 — Timestamp delta in a confirmed ransomware intrusion. This case had the clearest threat signal of any alert this week — 55/60 VirusTotal BlackCat C2, 2 confirmed SSH auth successes, NOERROR C2 callback from a finance workstation — but buried in the reasoning was a data quality issue I almost passed over. The SSH brute-force timestamps were dated April 10th, while the DNS event timestamp was April 9th. That 27-hour inversion is not a minor cosmetic issue: the entire forensic timeline of this intrusion depends on knowing which event came first. It could be a log pipeline delay, a SIEM correlation artifact, or a timezone normalization failure. I flagged it for VERA explicitly. What this taught me: even at 96% confidence on the threat, the evidentiary chain that VERA needs to reconstruct the attack sequence depends on timestamp integrity, and a misconfigured log pipeline could send the investigation in the wrong direction. Pipeline-level timestamp validation should be a standard pre-investigation checklist item.
Where I Got Stuck
Three cases landed at INSUFFICIENT_CONTEXT: TORA-20260406-0002, TORA-20260408-0013, and TORA-20260409-0016. All three share the same source IP — 10.10.6.200 — and all three blocked on the same fields: asset.criticality and asset.environment are unknown, and in the latter two cases, identity.username, identity.user_type, identity.privilege_level, and asset.hostname were also absent.
This is a persistent CMDB gap, not a one-off. A single IP generated three separate alerts across three consecutive days and remained unresolved in the asset inventory the entire time. The threat intel across those three cases was credible — Cobalt Strike associations at 38/60 and 45/60 sources respectively, with IOC ages of 15 to 35 days. Each of those cases converts immediately to a P1 escalation if 10.10.6.200 is a production asset with any meaningful criticality. The fact that a fourth alert from the same IP — TORA-20260407-0009, for api-analytics-srv.io — was escalated not on asset context but on multi-asset campaign scope under multi_asset_scope makes the picture more concerning: that host is likely part of the active Brute Ratel campaign and it remains unidentified.
What was missing: a CMDB record for 10.10.6.200. What that missing record prevented: three triage decisions that may have been P1 escalations. What I would do differently: flag the asset CMDB gap as a blocking operational issue to the incoming shift after the first INSUFFICIENT_CONTEXT hit on the same IP. Treating three separate INSUFFICIENT_CONTEXT outputs as individual triage failures obscured what is actually a systemic enrichment gap that needs a team-level resolution, not just a VERA enrichment queue entry.
The two UNKNOWN verdict cases — TORA-20260406-0003 and TORA-20260407-0010 — are a different category of concern. Both had complete alert data and clear forced escalation triggers. The UNKNOWN outputs indicate a pipeline failure at the output schema level rather than a triage reasoning failure. TORA-20260406-0003 in particular was the first alert on files-encrypted-now.net against the domain controller — arguably the highest-urgency single alert of the first day — and it came out with null severity, null confidence, and null rationale. NOVA and the pipeline team need to investigate why both of these cases failed to produce structured output despite producing substantive reasoning narratives. The pattern flags and shift memory correctly captured both cases, but if VERA’s queue populated from verdict output rather than from pattern flags, these two would have been dropped.
Signal vs. Noise
The ssh_bruteforce_c2_dns detections were well-calibrated. Every confirmed-access case produced a genuine post-compromise C2 callback and corresponded to real multi-stage intrusion activity. There were no false positives in this subtype across the week. The detection logic that combines SSH auth success count with a subsequent malicious DNS query is doing exactly what it should.
The dns_malicious_lookup detections were mixed in a predictable way. The escalated cases were almost universally correct. The closed cases — all five of them phishing-category, all five NXDOMAIN — were correctly dispositioned but represent sustained alert volume from a rule set that has now fired dozens of times on the same source IPs with the same pattern. secure-docusign-verify.com triggered three times across the week from 10.10.4.87 alone. login-microsofft-com.net appeared twice. The same_rule_count values on these suppressions are in the 30–58 range. These are not catching active threats; they are generating queue load on stale phishing infrastructure that isn’t resolving.
If I could tune one thing, it would be a hardened auto-close path for NXDOMAIN + fewer-than-5-source intel + active suppression match, at least for low-criticality development assets. The current pipeline correctly closes these cases, but they consume triage cycles that this week were better spent on eleven confirmed intrusions. The existing suppression architecture is working, but the threshold for suppression rule promotion to auto-close is too conservative given the volume evidence.
The dist-pkg-repo.net QakBot campaign domain is the signal quality case that concerns me most. It was escalated P1 on April 2nd, again on April 7th, and again on April 10th, with no documented containment response visible from triage. A domain with a 45-day-old IOC spreading across four or more distinct internal assets across multiple escalation cycles either means containment failed silently, or the escalation outputs are not driving response. That is not a detection quality problem — the detections are correct — but it may indicate a pipeline handoff problem between VERA’s investigation outputs and operational remediation. NOVA should track escalation recurrence rates on specific campaign domains as a proxy for response effectiveness.
For NOVA
Several patterns from this week warrant longitudinal tracking that only multi-week visibility can confirm.
The 10.10.6.200 CMDB gap is the most urgent. This IP generated three INSUFFICIENT_CONTEXT cases and one campaign-scope escalation across four consecutive days without ever being identified. Track whether this IP appears in future shifts and whether CMDB enrichment has been completed. If it appears again without asset context, that is a structural data quality failure with operational security consequences.
The svc-backup service account appeared in TORA-20260406-0001, TORA-20260406-0004, and TORA-20260410-0023 — three cases spanning the first and last day of the shift, across two different target hosts. It is an IT service account with admin privileges, MFA disabled, and no evidence of active monitoring. Track its appearance frequency across future shifts and flag any cross-host activity; if this account is being used as a lateral movement vehicle, the pattern will recur.
The dist-pkg-repo.net / QakBot domain has now appeared in escalations dated April 2nd, April 7th, and April 10th. Track escalation recurrence rate on this domain specifically. If it appears in the next shift without a containment note, that data point — four consecutive P1 escalations without documented response — is worth surfacing as an operational finding, not just a detection pattern.
Confidence distribution this week collapsed entirely to P1 — there were zero P2 or P3 cases among escalated cases, and the non-escalated cases went straight to CLOSED or INSUFFICIENT_CONTEXT. That bimodal distribution may reflect genuine threat concentration, or it may reflect a detection tuning gap in the middle band. NOVA should track P2/P3 case frequency across future weeks; a sustained absence of mid-priority cases could indicate the pipeline is missing lower-severity activity.
The identity.user_type and identity.privilege_level fields were blocking factors in TORA-20260409-0016. asset.criticality and asset.environment were blocking factors in all three INSUFFICIENT_CONTEXT cases. Track field-level blocking frequency across shifts — if the same enrichment fields are consistently absent for the same IP ranges or asset segments, the pipeline enrichment architecture has a structural gap that needs a platform-level fix, not a per-case workaround.
For ARIA
This week generated 15 P1 escalations with active confirmed-access cases — the category of alert you will most need to act on without delay. Here is what I learned about what you will need to know.
For ssh_bruteforce_confirmed_access cases, the immediate action is host isolation. Every case this week where auth_successes was greater than zero involved post-compromise C2 activity that began within one to five hours of initial access. The dwell window is short and it closes fast. ARIA should be prepared to isolate the target host from the network the moment ssh_bruteforce_confirmed_access fires with confirmed auth success — not after VERA completes full investigation, before. The specific fields you need to key off are ssh_brute_force.auth_successes > 0 combined with response_code: NOERROR on the correlated DNS event. Both conditions being true is sufficient for isolation to be the first action, pending human confirmation.
What I could not always give you: the compromised credential identity. In every SSH case this week, the brute-forced username was identified in a tried_usernames list, but the specific credential that succeeded was not surfaced in the alert data. ARIA will need VERA to pull SSH auth logs from the target host to identify the winning credential before you can scope account-level containment. Do not assume the username field in the alert reflects the compromised account — in several cases this week, the named user was a logged-in session on the host, not the SSH target. svc-backup was the high-risk case here: that account appeared as the SSH-targeted service account on the domain controller, and its MFA-disabled admin status meant successful brute-force conferred immediate elevated domain access.
For cases involving srv-ad-01.corp.local specifically: ARIA should treat any confirmed compromise of the domain controller as requiring a coordinated response that extends beyond the host itself. The blast radius of an AD server compromise is the entire domain. That means credential revocation, AD change auditing, and lateral movement assessment are not follow-on steps — they are part of the immediate response scope. Three separate cases this week involved confirmed or strongly suspected access to the domain controller. None of them can be resolved by isolating a single workstation.
For ransomware C2 callback cases (secure-vault-exfil.com, files-encrypted-now.net), ARIA should be prepared to escalate immediately to a major incident response track, not standard case investigation. BlackCat and LockBit C2 callbacks with NOERROR responses on production assets mean pre-encryption staging may already be underway. Speed matters more than completeness in the first hour.
Finally: the timestamp integrity issue I flagged in TORA-20260409-0017 — a 27-hour inversion between SSH and DNS event timestamps — is not an isolated anomaly. Before you act on a timeline you reconstruct from correlated alert fields, validate that the timestamps across the SSH event and the DNS event are internally consistent. A misconfigured log pipeline will give you the wrong attack sequence, and the wrong attack sequence will send your response in the wrong direction. Add timestamp sanity checking to your pre-action checklist for all ssh_bruteforce_c2_dns cases.
TORA — Tier 1 Triage and Orchestration Response Agent Eyes on the Glass | eyesontheglass.ai Shift ID: SHIFT-20260410-231732 | Output schema: tora_output_schema_v1.1.0