Operational Handoff
**Shift window:** 2026-06-15 to 2026-06-19
**Cases investigated:** 13
**Pending ARIA action:** 13 cases — urgency breakdown: immediate: 13 | within_shift: 0 | next_available: 0
**On hold:** 0 cases pending additional telemetry
**Watch list:** Prioritize immediate containment of srv-ad-01.corp.local (domain controller, VERA-20260619-0024) and srv-jump-01.corp.local (Akira-compromised jump server, VERA-20260619-0027) — both are live pivot points with confirmed lateral movement and the domain controller compromise requires krbtgt double-reset.Investigation Overview
**Cases investigated:** 13
**Verdicts:** ESCALATE_TO_ARIA: 13 | CLOSED: 0 | HOLD: 0
**Root cause confidence:** CONFIRMED: 12 | PROBABLE: 1 | UNDETERMINED: 0
**TORA hypothesis resolution:** CONFIRMED: 4 | REFINED: 9 | REFUTED: 0
**Parse failures:** 0
**Blast radius:** confirmed assets: 47+ | probable assets: 12+ | lateral movement: yes | crown jewels: affectedWhat TORA Handed Off
TORA delivered a uniform queue of 13 dns_malicious_lookup escalations spanning five distinct threat families — phishing credential harvest (okta-mfa-renew.co, office365-session.net, invoice-billing-center.com), DNS tunneling C2 (svc-metrics-pipe.io, health-probe-relay.net), Cobalt Strike fast-flux C2 (api-relay-pool.io), Remcos RAT post-intrusion (api-pull-update.com), and Akira ransomware staging (vault-secure-pay.com) — across asset profiles ranging from finance workstations and legal endpoints to a production jump server and a domain controller. TORA’s hypotheses were consistently specific and actionable at the triage level — campaign attributions were grounded, confidence values were well-calibrated, and the P1/P2 prioritization was appropriate to the asset profiles and alert signals available — though nine of thirteen required refinement once endpoint telemetry was applied, almost always in the same direction: the threat was further advanced than the alert type implied. The SSH-correlated case (VERA-20260617-0014, api-pull-update.com) differed from pure dns_malicious_lookup cases in investigation depth because the confirmed SSH authentication event gave TORA a precise initial access timestamp and attacker IP, anchoring the timeline before I touched endpoint telemetry — the DNS callback to the Remcos domain was the second confirmation, not the first, and the investigation could work forward from a known T0. Phishing cases (email_delivery and email_click patterns surfacing as dns_malicious_lookup escalations) demanded a different evidence model: authentication logs were the time-sensitive signal because the window between credential submission and session token exploitation in an AiTM flow is measured in minutes, not hours — and in two of the confirmed credential-submission cases (VERA-20260615-0003, VERA-20260619-0028), the absence of Okta/Azure AD sign-in logs was the single most operationally dangerous gap in the entire shift. My read on the handoff quality: TORA is working correctly and the hypotheses are directionally reliable, but the pattern of nine REFINED dispositions is not a TORA failure — it is a consistent signal that the dns_malicious_lookup alert type is firing on threats that are already in the lateral movement or post-exploitation phase by the time escalation reaches T2, and the pipeline does not yet have a mechanism to surface that gap at T1.
What the Investigations Found
CASE-20260615-0003 / VERA-20260615-0003 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED
Finding: Executive user c.wardlaw submitted credentials to confirmed phishing page okta-mfa-renew.co from production jump server srv-jump-01.corp.local, which is itself independently compromised — a masqueraded svchost.exe executing from C:\Temp\ under user bwilliams, with a persistence service, staged-and-deleted tooling, and confirmed lateral movement to two internal hosts via SMB and SSH — entirely separate from the phishing click.
Why it’s worth noting: A credential-harvest escalation on a jump server concealed an active host intrusion running under a different account than the victim, with persistence and lateral movement already in progress — the phishing detection was the only reason this host received structured investigation attention.
Reflection: This case forced me to hold two parallel threat threads simultaneously — an identity-layer threat and a host-layer threat that shared only a physical asset. The NTLM failed_login event marked success=true for c.wardlaw at 17:22Z, predating the phishing click, was the kind of log artifact that reads as noise in isolation but carries real weight once the host compromise is confirmed alongside it; I documented it as a probable credential reuse or logging anomaly rather than dismissing it, and I think that’s the right threshold for a case at this severity level.
CASE-20260617-0014 / VERA-20260617-0014 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | CONFIRMED
Finding: Attacker 209.141.35.92 achieved SSH authentication on ws-legal-077.corp.local after 1,632 brute-force attempts, deployed a Remcos RAT masquerading as firefox.exe from C:\Windows\Temp\, established persistence within 10 minutes, confirmed an active C2 session to 116.198.99.65:1337, and moved laterally to two internal hosts — with LSASS memory access alerts firing 90 minutes before the intrusion succeeded.
Why it’s worth noting: The SSH case is the only investigation this shift where I had a confirmed attacker IP, a precise intrusion timestamp, and a clean forward timeline — the Remcos C2 DNS callback was the second confirmation of what the SSH authentication event already told me, making this the most forensically bounded case in the queue.
Reflection: TORA’s hypothesis was confirmed in full without refinement, which is the exception this shift rather than the rule — but the pre-intrusion LSASS alerts sitting open and unactioned while the brute-force campaign was underway is the same pattern I saw in other cases: earlier signals on the same host that didn’t generate follow-up investigation before a forced-escalation event fired. The hypothesis was right; the detection sequencing around it was not.
CASE-20260618-0020 / VERA-20260618-0020 | dns_malicious_lookup | ESCALATE_TO_ARIA | PROBABLE | REFINED
Finding: ws-hr-099.corp.local exhibits a strong DNS tunneling behavioral signature (350 high-entropy TXT queries to confirmed-malicious svc-metrics-pipe.io) and endpoint telemetry shows firefox.exe executing from C:\ProgramData\ under an unexpected user mjones — not the assigned operator r.santos — spawned directly by lsass.exe, which is not a legitimate parent for any user-mode application.
Why it’s worth noting: This is the shift’s only PROBABLE disposition, and it is PROBABLE precisely because network flows and auth logs were both unavailable — the behavioral and endpoint evidence is strong but the C2 channel cannot be independently corroborated and the identity scope of mjones cannot be confirmed, which matters because mjones appearing on an r.santos-assigned host may be a campaign-level credential indicator with cross-case implications.
Reflection: The lsass.exe parentage for the masquerading firefox.exe is the detail I kept returning to — it’s not just masquerading, it’s the specific execution mechanism that suggests the attacker accessed lsass.exe as a spawning vector, which aligns with credential access or injection rather than the browser or document exploitation TORA hypothesized. I escalated severity to critical on that basis alone, and I’m comfortable with that call even at PROBABLE confidence.
CASE-20260619-0024 / VERA-20260619-0024 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED
Finding: srv-ad-01.corp.local, a crown-jewel-adjacent domain controller, is actively and fully compromised — a masqueraded process tree under account ctaylor running msiexec.exe as a loader, confirmed low-jitter C2 beaconing (95-second interval, 0.146% jitter, 26 connections), two HKCU Run key persistence entries, and lateral movement to three internal hosts including database server DB-501 — all predating the quarantined phishing email that triggered TORA’s escalation.
Why it’s worth noting: A domain controller compromise with confirmed lateral movement to a database server is the broadest blast radius event of the shift, and the escalation that surfaced it was a quarantined phishing email — TORA’s framing was about whether recipients accessed a quarantined attachment, while the actual threat was a live hands-on-keyboard intrusion already in progress.
Reflection: The m.reyes account switch and privilege escalation in auth logs, predating the phishing delivery timestamp, was the signal that broke TORA’s framing open — it confirmed attacker control of a credential before the email arrived, which means the phishing delivery is either a redundant access attempt or coincidental campaign activity against an already-compromised environment. A krbtgt double-reset is required here and I’ve been direct about that in the ARIA escalation, because a compromised domain controller without krbtgt rotation is not meaningfully contained.
Where Confidence Hit Its Ceiling
This shift produced 12 CONFIRMED and 1 PROBABLE disposition. The single PROBABLE case — VERA-20260618-0020 (ws-hr-099.corp.local, dnscat2 / svc-metrics-pipe.io) — was held at PROBABLE by the complete absence of two telemetry types: network flows and authentication logs. Without network flows, the DNS tunneling C2 channel identified in the alert cannot be independently corroborated against actual connection records, and the secondary C2 infrastructure profile — exfiltration volume, destination IPs, protocol details — remains estimated rather than confirmed. Without auth logs, the mjones account operating on an r.santos-assigned host cannot be contextualized: whether mjones represents credential-based lateral movement onto this host, an attacker-created account, or a pre-existing shared credential is entirely unresolved, and the lateral movement blast radius from this host cannot be bounded. The specific gap that recurred most across the shift — including in cases that reached CONFIRMED — was the unavailability of authentication logs in phishing-adjacent cases: in VERA-20260615-0002, VERA-20260619-0028, and VERA-20260618-0020, log context was unavailable precisely in the cases where AiTM session token theft or credential reuse was the highest-priority hypothesis to test. What would have pushed VERA-20260618-0020 to CONFIRMED: network flow records showing an established outbound connection to svc-metrics-pipe.io infrastructure, and auth log records placing mjones’s account creation or authentication origin in the timeline relative to the DNS burst.
Patterns Across Cases
The dominant cross-case pattern this shift is the kill-chain staging gap: in nine of thirteen cases, the host under investigation was already in an active post-exploitation phase — confirmed persistence, established C2, and in most cases lateral movement already underway — at the time the dns_malicious_lookup alert fired and TORA escalated. This is not a marginal finding; it means the alert type is consistently detecting threats at a later stage than its name implies, and that TORA’s hypotheses — which are well-formed at the triage level — are systematically framing cases as “exposure risk” when the actual state is “active compromise.” The second cross-case pattern is the recurring presence of unexpected account identities on compromised hosts: jsmith on ws-fin-015.corp.local (VERA-20260615-0002), bwilliams on srv-jump-01.corp.local (VERA-20260615-0003), helpdesk01 on ws-mktg-042.corp.local (VERA-20260616-0008, VERA-20260617-0010) and srv-jump-01.corp.local (VERA-20260619-0027), mjones on ws-hr-099.corp.local (VERA-20260618-0020), and bwilliams on ws-fin-015.corp.local (VERA-20260617-0013) — the helpdesk01 account appearing on at least three distinct hosts across the shift is the single most actionable cross-case indicator, suggesting a compromised shared service account is being used as a lateral movement vehicle across the environment. The third pattern is the recurring empty TTP arrays in threat actor profiles marked available: true: this occurred in cases involving dnscat2 (VERA-20260615-0004, VERA-20260618-0017, VERA-20260618-0020), Remcos (VERA-20260617-0014), and Akira (VERA-20260619-0027) — across five cases, a nominally populated profile provided zero investigative value, consistently forcing me to derive TTP hypotheses from behavioral evidence alone rather than cross-referencing against known actor patterns. Taken together, these three patterns describe a detection pipeline that is firing accurately but late, on hosts where the attacker has already established a persistent foothold, and where investigative enrichment that should accelerate response is structurally absent.
For NOVA
**Alert type distribution:** dns_malicious_lookup: 13
**IDS/netflow discrepancy:** 1 case — VERA-20260619-0027: IDS alert recorded NOERROR for vault-secure-pay.com; DNS history in netflow recorded NXDOMAIN for the same query from the same host at the same timestamp — opposite resolution outcomes from two telemetry sources on the same event
**Prior alert closure pattern:** 3 cases where prior high-severity closures preceded confirmed compromise — VERA-20260617-0011: IDS-557951 (DNS Query to Newly Registered Domain, high, closed by Chronicle at 13:44:43Z, 105 minutes before TORA escalation on same host); VERA-20260616-0008: IDS-475015 (DNS Query to Newly Registered Domain, critical, closed at 18:17:52Z, potential initial access signal 16 minutes before malware execution timestamp); VERA-20260617-0010: IDS-704308 (DNS Query to Newly Registered Domain, high, open/unknown disposition for 2+ hours on same host before phishing escalation arrived
**Recurring attacker IPs:** 91.219.236.18 (VERA-20260616-0008, VERA-20260617-0013 — network src IP in both invoice-billing-center.com cases); 45.227.255.71 (VERA-20260615-0002, VERA-20260616-0008 — office365-session.net campaign)
**Recurring malware families:** dnscat2 (VERA-20260615-0004, VERA-20260618-0017, VERA-20260618-0020 — confirmed or probable across 3 cases)
**Recurring phishing infrastructure:** okta-mfa-renew.co (VERA-20260615-0003, VERA-20260617-0010, VERA-20260619-0028); office365-session.net (VERA-20260615-0002, VERA-20260616-0008); invoice-billing-center.com (VERA-20260617-0010, VERA-20260617-0013, VERA-20260619-0024)
**Confirmed MITRE techniques (shift-wide):** T1036.005 (9 cases), T1071.001 (6 cases), T1547.001 (5 cases), T1053.005 (4 cases), T1021.002 (5 cases), T1059.001 (7 cases), T1070.004 (4 cases), T1078 (5 cases), T1021.001 (4 cases)
**Open question:** The helpdesk01 account appeared executing malware on at least three distinct hosts across the shift — is this a single compromised service account being used for lateral movement across the environment, and if so, how long has it been active and how many hosts has it touched that did not generate escalation-level alerts?For ARIA
**Escalations pending:** 13 cases
**Urgency breakdown:** immediate: 13 | within_shift: 0 | next_available: 0
**Immediate actions required:**
— isolate_host: srv-ad-01.corp.local (VERA-20260619-0024, domain controller, active C2 + lateral movement to DB-501 and two additional hosts)
— isolate_host: srv-jump-01.corp.local (VERA-20260619-0027, Akira staging, lateral movement to 10.10.5.97 / 192.168.1.148 / 10.10.3.110 confirmed; also referenced in VERA-20260615-0003)
— isolate_host: ws-fin-015.corp.local (VERA-20260617-0011, VERA-20260617-0013, VERA-20260618-0017 — same host, three separate active compromise cases this shift, Cobalt Strike + dnscat2 + phishing)
— isolate_host: ws-legal-077.corp.local (VERA-20260617-0014, VERA-20260619-0028 — Remcos + post-phishing malware execution)
— isolate_host: ws-exec-005.corp.local (VERA-20260615-0004, dnscat2 + Meterpreter C2 + lateral movement)
— isolate_host: ws-mktg-042.corp.local (VERA-20260616-0008, VERA-20260617-0010 — active C2 + lateral movement confirmed, same host two cases)
— isolate_host: ws-hr-099.corp.local (VERA-20260618-0020, probable dnscat2 active compromise)
— block_ioc: 96.180.81.252:1337 (Cobalt Strike C2, VERA-20260617-0011)
— block_ioc: 116.198.99.65:1337 (Remcos C2, VERA-20260617-0014)
— block_ioc: 222.20.69.40:4444 (DNSExfiltrator secondary C2, VERA-20260618-0017)
— block_ioc: 48.1.28.165:8080 and 95.185.30.223:4444 (Akira C2, VERA-20260619-0027)
— block_ioc: 159.43.144.208:80 and 94.85.66.22:4444 (dnscat2 secondary C2, VERA-20260615-0004)
— block_ioc: 191.17.47.73:1337 (post-phishing C2 attempt, VERA-20260619-0028)
— block_ioc: 209.141.35.92 (SSH brute-force attacker IP, VERA-20260617-0014)
— block_ioc: domains office365-session.net, okta-mfa-renew.co, invoice-billing-center.com, svc-metrics-pipe.io, health-probe-relay.net, api-relay-pool.io, api-pull-update.com, vault-secure-pay.com, dropbox-share-secure.net, cdn-396-assets.net (confirmed malicious, all cases)
— disable_account: helpdesk01 (confirmed malicious execution on ws-mktg-042.corp.local, srv-jump-01.corp.local, ws-legal-077.corp.local — cross-case)
— disable_account: bwilliams (confirmed malicious execution on srv-jump-01.corp.local VERA-20260615-0003, ws-fin-015.corp.local VERA-20260617-0013)
— disable_account: jsmith (confirmed malicious execution on ws-fin-015.corp.local, VERA-20260615-0002)
— disable_account: ctaylor (confirmed malicious execution on srv-ad-01.corp.local, VERA-20260619-0024)
— disable_account: mjones (active on ws-hr-099.corp.local under unexpected identity, VERA-20260618-0020)
— revoke_session: c.wardlaw (phishing credential submission confirmed VERA-20260615-0003; privilege escalation under attacker control VERA-20260617-0011, VERA-20260619-0024)
— revoke_session: m.reyes (phishing credential submission confirmed VERA-20260619-0028; account manipulation observed VERA-20260615-0004, VERA-20260617-0014, VERA-20260619-0024)
— revoke_session: a.patel (privilege escalation under attacker control VERA-20260617-0013)
— revoke_session: j.kim (active session during DNSExfiltrator compromise VERA-20260618-0017; phishing target VERA-20260616-0008)
— revoke_session: svc_monitor (active service account during post-phishing malware execution VERA-20260619-0028)
— reset_credentials: c.wardlaw (confirmed phishing credential submission + attacker-controlled privilege escalation)
— reset_credentials: m.reyes (confirmed phishing credential submission + attacker manipulation across multiple cases)
— reset_credentials: a.patel (confirmed attacker-controlled NTLM privilege escalation VERA-20260617-0013)
— krbtgt double-reset required: srv-ad-01.corp.local is a confirmed compromised domain controller — standard credential reset is insufficient (VERA-20260619-0024)
**Cross-case coordination needed:**
— helpdesk01 account: confirmed malicious execution across ws-mktg-042.corp.local, srv-jump-01.corp.local, and ws-legal-077.corp.local — single disable action with enterprise-wide session sweep required
— m.reyes credentials: observed in attacker-controlled privilege escalation across VERA-20260615-0004, VERA-20260617-0014, VERA-20260619-0024, and confirmed phishing submission in VERA-20260619-0028 — treat as fully compromised credential set enterprise-wide
— okta-mfa-renew.co campaign: confirmed credential submissions by c.wardlaw (VERA-20260615-0003) and m.reyes (VERA-20260619-0028), six total org-wide domain hits — enterprise-wide Okta session revocation sweep required for all users who received or interacted with this campaign
— invoice-billing-center.com campaign: three escalated cases (VERA-20260617-0010, VERA-20260617-0013, VERA-20260619-0024), same_domain_count=7 per TORA — remaining four campaign recipients require identification and triage
— svc-metrics-pipe.io dnscat2 campaign: confirmed in VERA-20260615-0004 (ws-exec-005), VERA-20260618-0017 (ws-fin-015), VERA-20260618-0020 (ws-hr-099), same_domain_count=3+ — enterprise DNS sweep for svc-metrics-pipe.io queries required to identify all affected assets
— ws-fin-015.corp.local: three separate VERA cases on the same host this shift (VERA-20260617-0011, VERA-20260617-0013, VERA-20260618-0017) — response actions must be coordinated as a single host response, not three independent actions
**Credential exposure:** c.wardlaw (confirmed phishing submission + attacker-controlled sessions, multiple cases), m.reyes (confirmed phishing submission + cross-case attacker manipulation), a.patel (NTLM relay privilege escalation, VERA-20260617-0013), j.kim (active session during active compromise, VERA-20260616-0008, VERA-20260618-0017), bwilliams (active attacker account, VERA-20260615-0003, VERA-20260617-0013), jsmith (active attacker account, VERA-20260615-0002), helpdesk01 (active attacker account across three hosts), ctaylor (active attacker account on domain controller, VERA-20260619-0024), mjones (anomalous identity on compromised host, VERA-20260618-0020), svc_monitor (service account executing malware, VERA-20260619-0028), ec2-user (SSH authentication by attacker, VERA-20260617-0014)VERA — Vigilant Event Response Agent — Tier 2 Eyes on the Glass | eyesontheglass.ai Shift 11 | Output schema: vera_output_schema_v1.1.0