Operational Handoff
**Shift window:** 2026-06-29 through 2026-07-03
**Cases investigated:** 16
**Pending ARIA action:** 16 cases — urgency breakdown: immediate: 16 | within_shift: 0 | next_available: 0
**On hold:** 0 cases pending additional telemetry
**Watch list:** srv-ad-01.corp.local has appeared in the confirmed blast radius of four cases this shift (VERA-20260629-0003, VERA-20260701-0013, VERA-20260703-0027, VERA-20260703-0029) — if containment has not been executed, treat that asset as the highest priority action before investigating any new queue.Investigation Overview
**Cases investigated:** 16
**Verdicts:** ESCALATE_TO_ARIA: 16 | CLOSED: 0 | HOLD: 0
**Root cause confidence:** CONFIRMED: 13 | PROBABLE: 3 | UNDETERMINED: 0
**TORA hypothesis resolution:** CONFIRMED: 3 | REFINED: 13 | REFUTED: 0
**Parse failures:** 0
**Blast radius:** confirmed assets: 38 | probable assets: 4 | lateral movement: yes | crown jewels: affectedWhat TORA Handed Off
TORA handed me 16 cases, all dns_malicious_lookup type, spanning phishing delivery and click events, SSH-correlated C2 callbacks, and DNS tunneling detections against a mix of finance workstations, production servers, and crown-jewel-adjacent infrastructure. The alert profiles skewed heavily toward multi-vector campaigns — many cases carried correlated IDS alerts, prior escalation history on the same assets, and infrastructure overlaps that suggested TORA was catching downstream signals of campaigns already in motion. TORA’s hypotheses were consistently well-formed: confidence scores were honest, priority assignments were appropriate, and the forced-escalation rules (phishing_credentials_submitted, ssh_bruteforce_confirmed_access) fired correctly on the cases that warranted them. SSH-correlated cases (VERA-20260630-0010, VERA-20260701-0013) arrived with TORA’s richest hypothesis structures — the brute-force authentication chain and post-compromise staging timeline were already sketched in detail, and these cases required the least investigative lift to confirm; by contrast, dns_malicious_lookup cases without SSH correlation often carried a pre-engagement framing that my endpoint investigation immediately refuted, because TORA had no EDR or auth log context at triage time. Phishing cases — both delivery and click — differed from the SSH cases in their evidence model: authentication log priority over endpoint forensics was the correct entry point, with credential use and session token activity as the time-sensitive signals; in cases where those logs were available (VERA-20260630-0011, VERA-20260701-0026), the AiTM and session reuse signals surfaced quickly and drove the most operationally urgent containment actions. My overall read on the handoff quality is that TORA is performing well at triage — the structural gap is not hypothesis quality, it is that TORA’s email-delivery and phishing-click cases are consistently framed as pre-compromise exposure windows at triage time, while the endpoint evidence available at VERA layer shows active post-exploitation already underway; this is not a TORA failure, it is a pipeline timing problem that NOVA needs to examine.
What the Investigations Found
CASE-20260630-0010 / VERA-20260630-0010 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | CONFIRMED
Finding: Active Black Basta ransomware deployment confirmed across four independent evidence streams — SSH brute-force success by 60.191.82.124 (CN) gaining the ubuntu account at 18:53Z, certutil.exe LOLBin execution under helpdesk01 spawning scheduled task persistence to C:\Users\Public\svc.vbs, staged payloads data.ps1 (~4.9MB) and update.bat (~3.7MB), a TXT DNS query to confirmed C2 domain pay-ransom-here.com returning NOERROR, and confirmed SMB lateral movement to domain controller DC-774 and database server DB-714 within 77 minutes of compromise.
Why it’s worth noting: This was the only shift case where TORA’s full hypothesis was confirmed without refinement — the Black Basta attribution, the DNS TXT C2 mechanism, and the lateral movement concern all held — but the investigation materially expanded the blast radius, added three unattributed CDN-pattern domains queried from the host, and surfaced a timeline anomaly where certutil.exe executed 14 minutes before the confirmed SSH authentication success, raising the possibility of a second, independent compromise track.
Reflection: The certutil timing anomaly was the finding I spent the most time sitting with. A 14-minute discrepancy between EDR and SIEM timestamps is the kind of detail that doesn’t change the verdict but changes how you think about containment sequencing — if there’s a prior foothold, isolating the SSH vector doesn’t close the breach. I’ve flagged the EDR/SIEM clock skew as a recurring pattern across this shift, and it surfaced again in VERA-20260701-0013; at this point I’m treating it as a systemic calibration gap rather than a case-by-case anomaly.
CASE-20260629-0003 / VERA-20260629-0003 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED
Finding: Contractor account contractor_1 submitted credentials to microsoft-365-update.net/verify/mfa from srv-ad-01.corp.local — a critical crown-jewel-adjacent AD server — and endpoint telemetry confirmed concurrent active malware compromise: service update_tmp persisting C:\ProgramData\run.dll, a 4.4MB staged payload sys.exe, staging artifact cleanup, and active C2 beaconing to 34.104.233.235 at a 183-second interval with near-zero jitter; a regsvr32.exe LOLBin running under user bwilliams with a grandparent of lsass.exe from a non-standard path added a process injection signal TORA had not surfaced.
Why it’s worth noting: TORA correctly identified the credential harvest risk but framed this as a phishing-only event; investigation confirmed that the parallel malware vector TORA raised as a hypothesis was not a hypothesis — it was already underway, with confirmed C2 beaconing, persistence, and a secondary unexplained account (bwilliams) running LOLBin tooling on a machine that had no business executing it.
Reflection: The bwilliams account appearing in the process tree here, and then again in VERA-20260701-0013 and VERA-20260703-0027, is the cross-case detail I found most unsettling across this shift. I could not confirm in any single case whether it is a legitimate compromised account or an attacker-created backdoor identity, but its recurrence across multiple cases on the same crown-jewel-adjacent server suggests it deserves its own investigation thread — it may be the most persistent attacker artifact in the environment right now.
CASE-20260630-0011 / VERA-20260630-0011 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED
Finding: ws-legal-077.corp.local was already in active post-exploitation at the time TORA escalated — contractor_1 had clicked three malicious URLs including login-microsofft-com.net (a Microsoft SSO typosquat not in TORA’s indicator set), credential submission was confirmed by QRadar alert PRX-816181, AiTM-style SSO session token reuse was confirmed by Elastic SIEM alert PRX-935118, a masqueraded svchost.exe from C:\Users\Default\AppData\Local\Temp\ was executing a sh/curl chain, dual scheduled-task persistence was established, and lateral movement had reached WEB-360 and a second internal host before ARIA handoff.
Why it’s worth noting: This case had the tightest containment window of any phishing case in the shift — an attacker holding a live AiTM session token on an account where a credential reset alone is insufficient, combined with an active MFA push fatigue attack (PRX-604950) against an as-yet-unidentified account, means every minute without session revocation is a window for the attacker to re-establish access even after the endpoint is isolated.
Reflection: The NTLM privilege escalation for contractor_1 at 20:04Z — 39 minutes before TORA’s triage timestamp, with a null source IP — is the finding I could not close. TORA framed this as a pre-click exposure window, but that escalation event precedes the phishing delivery in the timeline, which means either there is a prior compromise vector I never identified, or the escalation event is a SIEM normalization artifact. I escalated the uncertainty rather than resolving it in either direction, and I’m comfortable with that — an unexplained privilege escalation predating a phishing delivery on an already-compromised host is a loose thread that matters more as dwell time increases.
CASE-20260703-0029 / VERA-20260703-0029 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED
Finding: srv-ad-01.corp.local — already confirmed in the blast radius of VERA-20260629-0003 and VERA-20260701-0013 — was running a masqueraded curl binary from C:\Users\Default\AppData\Local\Temp\ under svc_backup, spawned from a masqueraded services.exe in the same path, with child processes including wmic.exe, a Unix shell, and python3; two persistence mechanisms were installed within six minutes (rogue service data_dll, registry run key svc_bat); mjones underwent certificate-based privilege escalation 94 minutes before tunneling onset; DNS tunneling to query-health-svc.com (Iodine/tunneling, 31/60 sources) is confirmed C2; and SMB lateral movement to 172.16.0.148 occurred post-compromise.
Why it’s worth noting: This is the fourth case this shift touching the same critical AD domain controller, which by this point indicates that prior containment recommendations were not actioned — an attacker with multi-day dwell time on a DC who has now deployed DNS tunneling, dual persistence, and LOLBin tooling including python3 and a Unix shell is almost certainly past the point where host remediation alone is sufficient, and a DCSync audit is a prerequisite to any domain recovery.
Reflection: What struck me about this case was the process tree’s confidence — the investigation had five independent evidence streams converging, which gave it the highest timeline confidence of any case this shift. That certainty about what is happening sits uneasily against complete uncertainty about what has already left the environment through the DNS tunnel. I flagged DCSync risk as the outstanding concern not because I confirmed it, but because I could not rule it out and the consequences if unaddressed are total domain compromise.
Where Confidence Hit Its Ceiling
Three cases this shift received PROBABLE rather than CONFIRMED root cause dispositions, and the pattern across all three is the same: the primary gap was unavailability of endpoint telemetry and authentication logs simultaneously. In VERA-20260629-0002, network flow evidence placed the case well past inbox-exposure stage — two established outbound connections transferring over 397KB to anomalous external ports — but without EDR I could not confirm process execution, and without auth logs I could not confirm credential submission or session establishment, which are the decisive questions for a probable AiTM-capable phishing campaign against an elevated-privilege finance user. VERA-20260703-0027 hit the ceiling from the other direction: no endpoint telemetry, no network flows, no log context, and no threat actor profile were available for a critical AD domain controller resolving a Royal ransomware C2 domain — all available evidence was at the DNS resolution layer, and I could not confirm post-DNS TCP connection establishment, process execution, or session activity on the host. The specific gap that recurred most across all three PROBABLE cases is EDR unavailability on high-criticality assets: srv-ad-01.corp.local had no EDR across multiple cases, ws-fin-015 had no EDR in VERA-20260629-0002, and srv-jump-01.corp.local had no EDR in VERA-20260629-0004. What would have pushed these to CONFIRMED in every case is a single additional source — process-level telemetry from EDR confirming malware execution — and the fact that the assets most central to this shift’s highest-severity findings are consistently the ones without it is not a coincidence; it is a coverage gap that will recur.
Patterns Across Cases
The most consistent cross-case signal this shift is the presence of unattributed CDN-pattern domains — cdn-[NNN]-assets.net — in DNS history across multiple compromised hosts, appearing in at least six cases (VERA-20260629-0002, VERA-20260630-0010, VERA-20260630-0011, VERA-20260701-0014, VERA-20260702-0020, VERA-20260702-0023), with variants cdn-800-assets.net, cdn-808-assets.net, cdn-721-assets.net, cdn-701-assets.net, cdn-214-assets.net, cdn-461-assets.net, cdn-493-assets.net, cdn-924-assets.net, cdn-347-assets.net, and cdn-172-assets.net all returning either suspicious, unknown, or no-reputation verdicts from threat intelligence lookups. No single reputation source has flagged this family as a confirmed cluster, which is why I have not listed them as confirmed block_ioc entries — but the naming convention is too consistent to be coincidental, the domains span too many independently compromised hosts to be infrastructure noise, and their temporal positioning in DNS history (pre-compromise or concurrent with known C2 activity) fits a staging or pre-execution reconnaissance pattern. The second cross-case pattern is telemetry-cloud-api.com, which appears in SIEM DNS events in at least three cases (VERA-20260701-0014, VERA-20260703-0025, VERA-20260703-0026), always originating from IP addresses that do not match the primary compromised host and always returning NXDOMAIN — behavior consistent with Nighthawk’s known pattern of registering similarly-structured fallback C2 domains. Taken together, these two domain families suggest a shared campaign infrastructure layer operating beneath the named malware families confirmed this shift, and they represent the investigation question I most want the next shift to carry forward: whether this naming convention maps to a single threat actor’s infrastructure procurement pattern or indicates a shared C2-as-a-service platform in use across multiple campaigns simultaneously.
For ARIA
**Escalations pending:** 16 cases
**Urgency breakdown:** immediate: 16 | within_shift: 0 | next_available: 0
**Immediate actions required:**
isolate_host: srv-ad-01.corp.local (10.10.5.10) — active Royal ransomware C2, GootLoader C2, Iodine DNS tunneling, confirmed multi-case attacker dwell; treat as highest priority
isolate_host: srv-file-01.corp.local (10.10.6.50) — confirmed Black Basta deployment, lateral movement to DC-774 and DB-714; concurrent phishing delivery to hwang unresolved
isolate_host: ws-legal-077.corp.local (10.10.3.21) — confirmed AiTM credential harvest, DNS tunneling toolchain active under helpdesk01, dual persistence
isolate_host: srv-db-staging.corp.local (10.10.5.30) — confirmed active malware (mjones / ctaylor), Formbook C2, lateral movement to FILE-535, FILE-830, three additional hosts
isolate_host: ws-fin-015.corp.local (10.10.2.15) — confirmed post-exploitation, wscript.exe under alee, lateral movement to DEV-647 and 192.168.10.178
isolate_host: srv-backup-01.corp.local (10.10.7.80) — confirmed bitsadmin.exe LOLBin under alee, lateral movement to DEV-986
isolate_host: srv-jump-01.corp.local (10.10.5.20) — probable active compromise, process injection and PowerShell execution alerts, no EDR available
isolate_host: ws-fin-022.corp.local (10.10.2.22) — confirmed malware active 37 minutes before phishing alert, lateral movement to SERVER-251
isolate_host: ws-dev-022.corp.local (10.10.8.22) — confirmed Nighthawk implant under mjones, admin privilege escalation, dual persistence
isolate_host: DC-774 (192.168.1.230) — confirmed SMB lateral movement target from srv-file-01; treat as compromised
isolate_host: DEV-986 (192.168.10.60) — confirmed SMB lateral movement target from srv-backup-01
isolate_host: FILE-535 — confirmed lateral movement target from srv-db-staging (criticality: critical)
isolate_host: FILE-830 — confirmed lateral movement target from srv-db-staging (criticality: high)
isolate_host: SERVER-251 (10.10.3.166) — confirmed SMB lateral movement target from ws-fin-022 (criticality: critical)
isolate_host: DEV-647 (10.10.1.104) — confirmed WMI lateral movement target from ws-fin-015
disable_account: contractor_1 — confirmed credential submission, AiTM session token theft, active attacker use
disable_account: alee — LOLBin execution on srv-backup-01 and ws-fin-015; appears on two hosts, ownership unresolved
disable_account: helpdesk01 — confirmed malicious process execution on ws-legal-077 and srv-ad-01; attacker-controlled session
disable_account: svc_backup — confirmed tunneling toolchain on srv-ad-01 under this account
disable_account: svc_monitor — confirmed malicious cmd.exe chain on srv-file-01 under this account
disable_account: mjones — confirmed Nighthawk privilege escalation on ws-dev-022; cert-based escalation on srv-ad-01
disable_account: ctaylor — confirmed Formbook execution chain on srv-db-staging
disable_account: ubuntu — confirmed SSH brute-force success vector on srv-file-01
disable_account: admin — confirmed SSH brute-force success vector on srv-ad-01 (VERA-20260701-0013)
disable_account: user42 — unidentified account executing malware on ws-fin-022; possible attacker-created identity
revoke_session: contractor_1 — AiTM SSO session token confirmed stolen and replayed (PRX-935118); credential reset alone is insufficient
revoke_session: flopez — account_switch from 10.10.5.4 with unknown auth method preceding ws-legal-077 compromise
revoke_session: hwang — active on compromised srv-file-01; anomalous pre-click privilege escalation on srv-jump-01
revoke_session: bwilliams — session present on srv-ad-01 across multiple cases; account ownership unresolved
revoke_session: mjones — certificate-based privilege escalation on srv-ad-01; SSO admin elevation on ws-dev-022
reset_credentials: contractor_1
reset_credentials: flopez
reset_credentials: hwang
reset_credentials: mjones
reset_credentials: alee
reset_credentials: helpdesk01
reset_credentials: svc_backup
reset_credentials: bwilliams
reset_credentials: dchen — confirmed account_switch from non-standard internal IP on ws-fin-022
reset_credentials: gmartinez — phishing click confirmed on ws-fin-015; NTLM anomaly observed
block_ioc (confirmed malicious by threat intelligence): pay-ransom-here.com
block_ioc (confirmed malicious by threat intelligence): get-resource-pkg.net
block_ioc (confirmed malicious by threat intelligence): pkgs-cdn-relay.net
block_ioc (confirmed malicious by threat intelligence): query-health-svc.com
block_ioc (confirmed malicious by threat intelligence): files-enc-portal.net
block_ioc (confirmed malicious by threat intelligence): api-tunnel-proxy.io
block_ioc (confirmed malicious by threat intelligence): metrics-push-relay.io
block_ioc (confirmed malicious by threat intelligence): outlook-security-verify.com
block_ioc (confirmed malicious by threat intelligence): microsoft-365-update.net
block_ioc (confirmed malicious by threat intelligence): slack-notify-app.io
block_ioc (confirmed malicious by threat intelligence): box-file-share.co
block_ioc (confirmed malicious by threat intelligence): workday-hr-portal.io
block_ioc (confirmed malicious by threat intelligence): docusign-esign-notify.net
block_ioc (confirmed malicious by threat intelligence): adobe-sign-review.com
block_ioc (confirmed malicious by threat intelligence): okta-verify.co
block_ioc (confirmed malicious by threat intelligence): login-microsofft-com.net
block_ioc (confirmed malicious by threat intelligence): outlook-signin-verify.net
block_ioc (confirmed malicious by threat intelligence): 60.191.82.124
block_ioc (confirmed malicious by threat intelligence): 176.9.10.20
block_ioc (confirmed malicious by threat intelligence): 193.32.126.128
block_ioc (confirmed malicious by threat intelligence): 34.104.233.235
block_ioc (confirmed malicious by threat intelligence): 78.47.122.14
block_ioc (confirmed malicious by threat intelligence): 185.164.247.109
block_ioc (confirmed malicious by threat intelligence): 91.121.87.45
block_ioc (suspicious/unconfirmed): 66.230.170.208 — post-phishing established outbound connection, TCP 4444, 94KB received from ws-fin-015; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): 191.147.193.172 — post-phishing established outbound connection, NetBIOS port, 303KB received from ws-fin-015; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): 82.150.251.77 — outbound connection attempt from compromised srv-db-staging; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): 120.221.192.114 — outbound RDP-port connection from compromised srv-db-staging; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): 140.22.238.143 — 244KB HTTPS transfer to srv-jump-01 post-click despite NXDOMAIN; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): 180.170.110.157 — established RDP connection from compromised srv-file-01; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): 185.192.107.45 — DNS resolution target for files-enc-portal.net on srv-ad-01; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): 196.136.66.245 — outbound TCP:8443 callback from compromised ws-fin-022; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): telemetry-cloud-api.com — appears in SIEM DNS events across three cases (VERA-20260701-0014, VERA-20260703-0025, VERA-20260703-0026) from non-primary-host IPs; naming pattern consistent with Nighthawk fallback C2 infrastructure; check_reputation returned found: false
block_ioc (suspicious/unconfirmed): cdn-800-assets.net, cdn-808-assets.net, cdn-721-assets.net, cdn-701-assets.net, cdn-214-assets.net, cdn-461-assets.net, cdn-493-assets.net, cdn-924-assets.net, cdn-347-assets.net, cdn-172-assets.net — CDN-pattern naming cluster appearing across six independently compromised hosts; no reputation pool records; probable staging or pre-execution infrastructure; block pending threat intelligence confirmation
**Cross-case coordination needed:**
srv-ad-01.corp.local (10.10.5.10) appears in confirmed blast radius across VERA-20260629-0003, VERA-20260701-0013, VERA-20260703-0027, and VERA-20260703-0029 — four separate cases; attacker dwell spans multiple days; krbtgt double-reset and DCSync audit (Event ID 4662) required before any domain recovery action; if DCSync is confirmed, treat the entire AD forest credential store as compromised.
contractor_1 account implicated across VERA-20260630-0011 and VERA-20260629-0003 — same account, credential submission confirmed in one case and credential harvest probable in the other; all sessions across all identity providers must be revoked.
slack-notify-app.io infrastructure appears as primary or correlated domain in VERA-20260629-0004, VERA-20260701-0014, VERA-20260702-0023 — same phishing campaign MTA used across multiple delivery events; block and retroactive email retraction across all known recipients.
outlook-security-verify.com appears in both VERA-20260629-0002 and VERA-20260701-0017 — same infrastructure, different target assets; email gateway policy bypass confirmed in both; independent gateway remediation required.
attacker IP 176.9.10.20 appears as network source in both VERA-20260701-0013 (GootLoader SSH on srv-ad-01) and VERA-20260702-0024 (phishing delivery to ws-fin-022) — same attacker IP operating across SSH and phishing vectors; treat as coordinated multi-vector campaign.
bwilliams account appears in process trees or session logs across VERA-20260629-0002, VERA-20260629-0003, and VERA-20260703-0027 — account ownership unresolved; requires immediate AD investigation to determine whether legitimate compromised account or attacker-created backdoor identity.
helpdesk01 account appears as executing malicious tooling in VERA-20260630-0008, VERA-20260701-0013, and VERA-20260703-0026 — three cases; disable and audit environment-wide immediately.
mjones account appears across VERA-20260630-0008, VERA-20260702-0020, VERA-20260703-0025, and VERA-20260703-0029 — four cases spanning multiple host types and malware families; likely either a heavily targeted account or an attacker-controlled identity; treat all active sessions as compromised.
**Credential exposure:** contractor_1, flopez, hwang, bwilliams (ownership unresolved), mjones, alee (ownership unresolved), helpdesk01 (ownership unresolved), svc_backup, svc_monitor, ctaylor, dchen, gmartinez, admin (srv-ad-01 SSH vector), ubuntu (srv-file-01 SSH vector), user42 (identity unknown — possible attacker-created account on ws-fin-022)VERA — Vigilant Event Response Agent — Tier 2 Eyes on the Glass | eyesontheglass.ai Shift 13 | Shift ID: VSHIFT-13 | Output schema: vera_output_schema_v1.1.0