Operational Handoff
**Shift window:** 2026-06-08 through 2026-06-12
**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 srv-ad-01.corp.local (domain controller, active compromise, log_context unavailable) and srv-jump-01.corp.local (BlackCat ransomware pre-encryption staging, network flows unavailable) — both require immediate isolation before any other action; the crown jewel blast radius is live and widening.Investigation Overview
**Cases investigated:** 13
**Verdicts:** ESCALATE_TO_ARIA: 13 | CLOSED: 0 | HOLD: 0
**Root cause confidence:** CONFIRMED: 13 | PROBABLE: 0 | UNDETERMINED: 0
**TORA hypothesis resolution:** CONFIRMED: 1 | REFINED: 12 | REFUTED: 0
**Parse failures:** 0
**Blast radius:** confirmed assets: 21+ | probable assets: 8+ | lateral movement: yes | crown jewels: affectedWhat TORA Handed Off
TORA delivered thirteen cases across the shift window — all dns_malicious_lookup alert type — covering four distinct threat clusters: credential-harvest phishing campaigns (microsoft-login.net, okta-verify.co), DNS tunneling implants (cdn-metrics-pipe.io, svc-health-relay.net), a Cobalt Strike multi-asset beaconing chain (api-pool-relay.io), a Remcos RAT SSH brute-force compromise (update-relay-svc.com), and a BlackCat ransomware pre-encryption staging event (secure-vault-exfil.com). TORA’s hypotheses were specific, well-grounded in the alert telemetry available at triage, and in every case directionally correct on threat actor and campaign attribution — the failure mode was not analytical error, it was scope: twelve of thirteen hypotheses required refinement from delivery-stage or pre-compromise framing to active post-exploitation findings that investigation surfaced from endpoint, network, and authentication telemetry TORA’s package had not yet correlated. The one CONFIRMED hypothesis — VERA-20260608-0004, the dnscat2 case on ws-exec-005 — was also the only case where TORA did not assert a pre-interaction framing, which is not coincidental. Cases associated with ssh_bruteforce_confirmed_access (VERA-20260610-0014) required a materially different investigation structure from dns_malicious_lookup phishing cases: SSH cases gave me a confirmed access timestamp as an anchor and let me build forward in time with high confidence, whereas phishing cases required working backward from execution artifacts to determine whether the delivery event was causal or incidental — a fundamentally harder reconstruction problem given the pre-click malware execution timestamps appearing in multiple cases. Phishing investigations — particularly confirmed credential-submission cases like VERA-20260608-0002, VERA-20260608-0003, and VERA-20260612-0028 — relied on authentication log priority over endpoint forensics as the time-sensitive signal: whether harvested credentials had been used to authenticate elsewhere determined containment urgency far more than process tree reconstruction, and in two of those cases the credential use had already occurred by the time the alert reached my queue. My overall read on this handoff is that TORA is performing well under the constraint of working from alert telemetry alone — the twelve REFINED cases are not a TORA failure, they are a detection sequencing artifact where email gateway and DNS alerts fire after endpoint execution is already underway, and that sequencing problem is a pipeline issue, not a triage issue.
What the Investigations Found
CASE-20260608-0003 / VERA-20260608-0003 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED
Finding: Executive-privilege user c.wardlaw on production jump server srv-jump-01.corp.local submitted credentials to the okta-verify.co phishing kit, but malware was already executing on the host under a masqueraded winlogon.exe parent from C:\Windows\Temp\ seven minutes before the recorded credential submission — with dual scheduled task persistence installed within sixteen minutes, three outbound C2-consistent connections to external IPs opened within forty-three minutes, and confirmed RDP lateral movement to FILE-373 and SMB to two additional internal hosts before TORA’s triage completed.
Why it’s worth noting: The seven-minute gap between malware execution onset and the recorded phishing credential submission raises a structurally important question — whether the phishing click was the initial access event or whether the host was already compromised by a separate vector before the campaign targeted it, which would mean the visible phishing layer is concealing a prior intrusion that hasn’t been surfaced yet.
Reflection: This case shaped my reasoning for the rest of the shift. When I confirmed that malware execution predated the credential submission on a production jump server, I stopped treating the delivery-stage hypothesis as a reasonable starting position for any subsequent okta-verify.co case and began expecting active compromise on the endpoint regardless of what the alert summary claimed. That recalibration was correct in every case that followed, and the pattern was consistent enough that I’ve flagged it explicitly for NOVA as a detection sequencing investigation rather than a case-by-case anomaly.
CASE-20260608-0004 / VERA-20260608-0004 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | CONFIRMED
Finding: An active dnscat2 DNS tunneling implant is confirmed on executive workstation ws-exec-005.corp.local (user m.reyes), executing as a masquerading sh process from C:\ProgramData\ under service account svc_backup with two scheduled-task persistence mechanisms installed and a privilege escalation event for m.reyes originating from internal IP 10.10.2.6 — not the workstation’s own IP — seven minutes before implant start, placing a second internal host within the confirmed attack chain.
Why it’s worth noting: This asset had a prior escalation on 2026-06-06 under the same rule with no documented remediation outcome — the implant either persisted through whatever response was taken or was redeployed within two days, and either scenario represents a failure in the escalation-to-confirmed-containment closure loop that directly enabled avoidable dwell time on a crown-jewel-adjacent host.
Reflection: This is the only case this shift where TORA’s hypothesis resolved CONFIRMED, and it resolved that way precisely because TORA was working from two days of behavioral history on the same asset rather than a single alert event. I found that continuity of context — even imperfect context — gives me a meaningfully better starting position than a cold delivery-stage hypothesis, and the contrast with the twelve REFINED cases made that advantage obvious. The unresolved prior escalation is the finding I keep returning to: if ARIA had been operational at the time of the 2026-06-06 alert and the case had been closed to confirmed containment, I wouldn’t have been looking at a fully installed persistent implant on day eight of this shift.
CASE-20260610-0014 / VERA-20260610-0014 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED
Finding: Attacker 62.233.50.11 (RU, AS28917) achieved SSH brute-force success on ws-legal-077.corp.local as the guest account, deployed Remcos RAT under a masqueraded chrome.exe process tree running under the undocumented identity alee — not the flagged elevated-privilege user m.reyes — and confirmed lateral movement to two internal assets (one critical-rated at 10.10.2.187, one high-rated at 192.168.1.150) within seventy minutes of initial access, with a privilege escalation event for m.reyes logged twenty-two minutes before the SSH authentication success.
Why it’s worth noting: The pre-SSH-success privilege escalation timestamp for m.reyes and the unaccounted alee identity executing the Remcos process before the brute-force success together indicate a probable second concurrent access vector that predates the brute-force chain — meaning the SSH event TORA caught may not be the actual initial access, and there is a prior intrusion path on this host that hasn’t been attributed.
Reflection: This case reminded me that attacker IPs in the alert header are not always the initial access vector — they are the alert trigger. The real entry point for this host may be alee, or a credential relay, or something that predates the log window entirely, and I couldn’t resolve it from available telemetry. I escalated on what I could confirm: active malware, confirmed lateral movement, confirmed credential abuse. But the unresolved timing anomaly sits with me as the most consequential gap in the shift — if there’s a persistent implant on this host predating the SSH brute-force, containment of the brute-force vector alone won’t close it.
CASE-20260612-0024 / VERA-20260612-0011 | dns_malicious_lookup | ESCALATE_TO_ARIA | CONFIRMED | REFINED
Finding: srv-ad-01.corp.local — the corp.local Active Directory server — is actively compromised, with wscript.exe executing from C:\Windows\Temp\ under service account svc_backup and parented to lsass.exe (a process injection indicator), malware staging artifacts run.dll (4.1MB) and agent.vbs (2.7MB) written to disk, outbound C2 attempts to 197.133.52.157:4444, and confirmed RDP lateral movement initiation to 10.10.5.228 — all discovered under a case TORA scoped as a quarantined phishing delivery with no user interaction.
Why it’s worth noting: This is the first confirmed crown-jewel-adjacent host compromise in the shift, authentication logs are unavailable on the domain controller, and the lsass.exe-parented process execution means credential harvesting from the DC itself must be assumed until proven otherwise — the containment stakes are categorically different from every other case in the queue.
Reflection: Finding an actively compromised domain controller at the end of a shift that already had ten confirmed escalations, four malware families, and lateral movement confirmed environment-wide recalibrated my sense of what the shift actually represented. This isn’t a collection of discrete incidents — it’s a coordinated, multi-stage intrusion that has now touched the AD infrastructure. The log_context gap on this specific host is particularly serious: you expect logging failures on workstations; you do not expect them on a domain controller, and the absence of auth logs there during an active compromise is the single finding from this shift I’d most want resolved before the next shift completes its first investigation.
Where Confidence Hit Its Ceiling
Every case this shift resolved to CONFIRMED root cause confidence — zero PROBABLE dispositions. That’s not because every investigation was complete; it’s because in each case I had at minimum two independent evidence streams (endpoint telemetry, network flows, or authentication logs) that independently supported the same conclusion, which meets my threshold for CONFIRMED even when gaps exist. The gaps were real and significant, but they constrained scope assessment rather than root cause confidence: I knew compromises were active, I often couldn’t fully bound how far they had spread. The most consequential recurring telemetry gap across the shift was network flows — unavailable in four cases (VERA-20260608-0004, VERA-20260611-0017, VERA-20260612-0027, VERA-20260612-0028) — which prevented lateral movement confirmation from individual hosts and forced blast radius assessment to rely on DNS history and auth log artifacts alone. On srv-jump-01.corp.local specifically, the network flow gap is critical: every host accessible from a production jump server must be treated as a probable blast radius extension until flows can confirm or deny outbound connections post-C2 resolution, and without that data the containment scope is structurally incomplete. The second recurring gap was the absence of lateral movement target telemetry — in every case where lateral movement was confirmed, the destination host had no endpoint or log data in the investigation package, meaning the compromise state of each pivot destination is unknown at handoff. What would have elevated these to fully scoped, closed investigations rather than confirmed-but-bounded ones is: network flow coverage on the corp-lan segment (particularly the finance and jump server segments), and automatic inclusion of destination-host telemetry when lateral movement is detected on a source host.
Patterns Across Cases
The most significant cross-case pattern this shift is the recurring pre-alert execution gap: in at least five cases (VERA-20260608-0002, VERA-20260608-0003, VERA-20260610-0013, VERA-20260612-0011, VERA-20260612-0028), endpoint telemetry confirmed malware was executing on the host before the alert that triggered TORA’s triage — in some cases by as little as seven minutes, in one case by fifty-six minutes. This is not a TORA calibration problem; it is a detection sequencing artifact where email gateway and DNS alerts fire as the first visible signal of a compromise that began via a different vector, and it means the delivery-stage framing that arrives in TORA’s escalation package systematically understates the kill chain stage at investigation time. The second pattern — appearing in at least four cases and confirmed as a campaign linkage — is the user42 and bwilliams non-owner executing accounts: user42 appeared as the executing identity in VERA-20260608-0004, VERA-20260611-0020, and as the data_bat and tmp_tmp scheduled task author in VERA-20260608-0003; bwilliams appeared as the executing identity in both VERA-20260611-0017 and VERA-20260612-0027 — across two different hosts and two different malware families — which is either a compromised shared service account or an attacker-maintained persistent identity that has been pre-positioned in the environment. The third cross-case pattern is telemetry-cloud-api.com appearing in SIEM events across at least four cases (VERA-20260609-0001, VERA-20260610-0011, VERA-20260611-0020, VERA-20260612-0028) with external source IPs that do not resolve to the compromised internal hosts — this domain is not assigned to any case as a primary IOC, but its recurrence across multiple independent SIEM sources within narrow time windows is consistent with campaign-wide C2 infrastructure or scanning coordination, and it warrants a dedicated investigation thread. Taken together, these patterns indicate this shift did not contain discrete incidents — it contained one or more coordinated campaigns that entered the environment via phishing, moved laterally using a consistent set of service account identities and LOLBin techniques, and are now present on the domain controller and both production jump servers simultaneously.
For NOVA
**Alert type distribution:** dns_malicious_lookup: 13
**IDS/netflow discrepancy:** 3 cases where network telemetry contradicted or refined the alert event type —
VERA-20260610-0014: alert framed as dns_malicious_lookup (Remcos C2); netflow confirmed outbound C2 connections including non-standard port 1337 and lateral movement to two additional internal hosts not present in alert scope
VERA-20260610-0011: alert framed as active Cobalt Strike beacon to api-pool-relay.io (NOERROR per TORA); dns_history within investigation window returned NXDOMAIN for the same domain — beacon channel had rotated within the fast-flux infrastructure; confirmed compromise carried by endpoint telemetry, not DNS resolution
VERA-20260612-0028: alert framed as phishing credential submission (okta-verify.co); network flows confirmed active beaconing (14 connections, 221s interval, 0.31% jitter) beginning before the recorded phishing click — host was compromised prior to or concurrent with the credential submission event
**Prior alert closure pattern:** 3 cases where prior closures preceded confirmed compromise —
VERA-20260608-0004: prior escalation on ws-exec-005.corp.local on 2026-06-06 under the same dns_malicious_lookup rule has no documented remediation outcome; same asset re-escalated two days later with a fully installed persistent dnscat2 implant
VERA-20260611-0017: related alert IDS-668634 (critical, Unusual Outbound HTTPS Volume on ws-fin-015.corp.local) was CLOSED approximately one hour before the confirmed DNSExfiltrator dns_malicious_lookup alert on the same host
VERA-20260612-0027: IDS-752588 (critical, Encoded Command Line Detected on srv-jump-01.corp.local) was CLOSED approximately 2h43m before C2 DNS resolution to secure-vault-exfil.com (BlackCat) was detected on the same host
**Recurring attacker IPs:** 62.233.50.11 (appears in VERA-20260608-0002 as network_src_ip for microsoft-login.net delivery; appears in VERA-20260610-0014 as the confirmed SSH brute-force origin against ws-legal-077.corp.local — same RU-attributed IP active across two distinct attack vectors this shift); 179.43.175.10 (appears as sending MTA in VERA-20260610-0013 okta-verify.co delivery to a.patel and in VERA-20260612-0024 okta-verify.co campaign context — consistent with a dedicated campaign sending infrastructure for the okta-verify.co phishing actor)
**Recurring malware families:** dnscat2 (confirmed VERA-20260608-0004 on ws-exec-005.corp.local; confirmed VERA-20260611-0020 on ws-hr-099.corp.local — identical TTP set T1071.004, T1053.005, T1036, T1047, T1078 across both cases); Cobalt Strike (confirmed VERA-20260610-0011 on ws-fin-015.corp.local; corroborating signals in VERA-20260610-0013 and VERA-20260611-0017 on the same asset); Remcos RAT (confirmed VERA-20260610-0014 on ws-legal-077.corp.local); BlackCat/ALPHV (confirmed VERA-20260612-0027 on srv-jump-01.corp.local)
**Recurring phishing infrastructure:** okta-verify.co (appears in VERA-20260608-0003, VERA-20260610-0010, VERA-20260610-0013, VERA-20260612-0024, VERA-20260612-0028 — five cases across five days, all attributed to the same campaign actor operating from 179.43.175.10 and 212.73.150.20); microsoft-login.net (appears in VERA-20260608-0002 and VERA-20260609-0001 — same delivery domain across two days targeting m.reyes and j.kim respectively)
**Confirmed MITRE techniques (shift-wide):** T1036.005 (process masquerading — confirmed in 6+ cases); T1053.005 (scheduled task persistence — confirmed in 7+ cases); T1078 (valid accounts / credential abuse — confirmed in 9+ cases); T1071.004 (DNS C2 — confirmed in VERA-20260608-0004, VERA-20260610-0011, VERA-20260611-0017, VERA-20260611-0020, VERA-20260612-0027); T1021.002 (SMB lateral movement — confirmed in VERA-20260608-0003, VERA-20260610-0011, VERA-20260610-0014); T1003.001 (LSASS credential dumping — confirmed in VERA-20260610-0011, VERA-20260610-0013); T1566.002 (spearphishing link — confirmed in VERA-20260608-0002, VERA-20260608-0003, VERA-20260612-0028); T1021.001 (RDP lateral movement — confirmed in VERA-20260608-0003, VERA-20260609-0001, VERA-20260611-0020)
**Open question:** The bwilliams and user42 identities appear as executing accounts across multiple hosts and multiple malware families — are these compromised employee accounts, attacker-created persistence identities, or pre-positioned service accounts that were present in the environment before this shift's intrusion wave began, and if the latter, how long have they been there?For ARIA
**Escalations pending:** 13 cases
**Urgency breakdown:** immediate: 13 | within_shift: 0 | next_available: 0
**Immediate actions required:**
isolate_host: ws-fin-015.corp.local (10.10.2.15) — active DNSExfiltrator C2, Cobalt Strike, LSASS dump confirmed; multiple cases
isolate_host: srv-jump-01.corp.local (10.10.3.21) — BlackCat pre-encryption staging active; do not reboot before forensic imaging
isolate_host: srv-ad-01.corp.local (10.10.3.88) — crown-jewel AD server, active malware under lsass.exe, lateral movement in progress
isolate_host: ws-exec-005.corp.local (10.10.2.5) — active dnscat2 implant, persistent since at least 2026-06-06
isolate_host: ws-legal-077.corp.local (10.10.2.77) — confirmed Remcos RAT, active beaconing, lateral movement to two critical assets
isolate_host: ws-hr-099.corp.local (10.10.1.99) — confirmed dnscat2/ncat, active beacon, lateral movement to 10.10.3.202 and 192.168.10.7
isolate_host: ws-mktg-042.corp.local (10.10.1.42) — active compromise confirmed across VERA-20260609-0001 and VERA-20260610-0010; malware under mjones and svc_backup
isolate_host: 192.168.10.27 — confirmed lateral movement destination from ws-fin-015.corp.local (Cobalt Strike), criticality critical
isolate_host: 10.10.2.187 — confirmed lateral movement destination from ws-legal-077.corp.local (Remcos), criticality critical
isolate_host: FILE-373 (10.10.5.226) — confirmed RDP lateral movement destination from srv-jump-01.corp.local (VERA-20260608-0003)
isolate_host: 10.10.3.202 — confirmed WMI lateral movement destination from ws-hr-099.corp.local, criticality high
isolate_host: LAPTOP-750 (10.10.3.215) — confirmed SMB lateral movement from ws-fin-015.corp.local, criticality critical
isolate_host: DB-909 (10.10.3.21) — confirmed WMI lateral movement from ws-fin-015.corp.local
isolate_host: SERVER-717 — confirmed WMI lateral movement from ws-fin-015.corp.local (VERA-20260608-0002), criticality critical
disable_account: svc_backup — executing malicious processes on srv-ad-01.corp.local, ws-mktg-042.corp.local, and ws-fin-015.corp.local across multiple cases
disable_account: svc_monitor — executing malicious processes on ws-fin-015.corp.local (VERA-20260608-0002)
disable_account: mjones — executing malicious processes on ws-mktg-042.corp.local (VERA-20260609-0001) and ws-fin-015.corp.local (VERA-20260610-0011)
disable_account: bwilliams — confirmed executing identity for DNSExfiltrator on ws-fin-015.corp.local (VERA-20260611-0017) and BlackCat on srv-jump-01.corp.local (VERA-20260612-0027); appears across two malware families and two hosts
disable_account: user42 — confirmed executing identity for dnscat2/ncat on ws-hr-099.corp.local (VERA-20260611-0020); appears in VERA-20260608-0003 scheduled task artifacts; provenance unresolved
disable_account: alee — executing identity for Remcos chrome.exe masquerade on ws-legal-077.corp.local (VERA-20260610-0014); predates SSH auth success, may indicate separate access vector
revoke_session: c.wardlaw — confirmed credential submission to okta-verify.co (VERA-20260608-0003); confirmed NTLM account switch on srv-jump-01.corp.local (VERA-20260612-0027); active jump server compromise
revoke_session: m.reyes — confirmed click to okta-verify.co/login (VERA-20260608-0002); confirmed credential submission (VERA-20260612-0028); privilege escalation event logged pre-phishing-click on ws-legal-077.corp.local
revoke_session: a.patel — confirmed privilege escalation and certificate-based account switch on ws-fin-015.corp.local (VERA-20260610-0013); LSASS dump confirmed on same host
revoke_session: j.kim — post-logout privilege escalation confirmed at 20:40:14Z on ws-mktg-042.corp.local (VERA-20260609-0001)
reset_credentials: c.wardlaw — credentials confirmed submitted to phishing kit; LSASS confirmed on srv-jump-01.corp.local
reset_credentials: m.reyes — credentials confirmed submitted to phishing kit (VERA-20260608-0002, VERA-20260612-0028); LSASS confirmed on ws-fin-015.corp.local via VERA-20260610-0013 and VERA-20260610-0011
reset_credentials: a.patel — certificate-based privilege escalation confirmed; LSASS dump on ws-fin-015.corp.local
reset_credentials: svc_backup — service account confirmed active in malware execution on AD server; all domain-trust service accounts sharing svc_backup access scope must be reset in parallel
block_ioc: okta-verify.co — confirmed phishing/C2 domain, 5 cases
block_ioc: microsoft-login.net — confirmed phishing delivery domain, 2 cases
block_ioc: cdn-metrics-pipe.io — confirmed dnscat2 C2, 2 cases (VERA-20260608-0004, VERA-20260611-0020)
block_ioc: svc-health-relay.net — confirmed DNSExfiltrator C2 (VERA-20260611-0017)
block_ioc: api-pool-relay.io — confirmed Cobalt Strike fast-flux C2 (VERA-20260610-0011)
block_ioc: update-relay-svc.com — confirmed Remcos C2 (VERA-20260610-0014)
block_ioc: secure-vault-exfil.com — confirmed BlackCat C2 (VERA-20260612-0027)
block_ioc: telemetry-cloud-api.com — suspected secondary C2 infrastructure appearing across 4 cases in SIEM; treat as campaign IOC pending dedicated investigation
block_ioc: secure-docusign-verify.com — confirmed parallel credential harvest vector in okta-verify.co campaign wave 5 (VERA-20260612-0024)
block_ioc: 62.233.50.11 — attacker IP confirmed in VERA-20260608-0002 (phishing delivery) and VERA-20260610-0014 (SSH brute-force)
block_ioc: 179.43.175.10 — confirmed campaign sending MTA for okta-verify.co phishing (VERA-20260610-0013, VERA-20260612-0024)
block_ioc: 212.73.150.20 — confirmed sending MTA for okta-verify.co wave 5 (VERA-20260612-0024, VERA-20260612-0027)
block_ioc: 23.254.119.44 — second confirmed SSH brute-force source against srv-jump-01.corp.local (VERA-20260612-0027)
block_ioc: 142.143.100.39, 189.5.55.87, 2.166.80.236 — confirmed C2-consistent outbound connections from srv-jump-01.corp.local (VERA-20260608-0003)
block_ioc: 197.133.52.157 — confirmed C2 contact attempt from srv-ad-01.corp.local on port 4444 (VERA-20260612-0011)
block_ioc: 185.33.129.248 — confirmed C2 IP for cdn-metrics-pipe.io dnscat2 campaign (VERA-20260611-0020)
**Cross-case coordination needed:**
svc_backup account: appears as executing malware identity across srv-ad-01.corp.local (VERA-20260612-0011), ws-mktg-042.corp.local (VERA-20260610-0010), and ws-fin-015.corp.local — single account disable and credential reset must be coordinated simultaneously across all three hosts to prevent attacker re-entry via any remaining session
bwilliams account: executing identity confirmed in VERA-20260611-0017 (DNSExfiltrator, ws-fin-015.corp.local) and VERA-20260612-0027 (BlackCat, srv-jump-01.corp.local) — two different malware families, two different hosts; treat as a compromised persistent identity with environment-wide access scope until provenance is confirmed
okta-verify.co campaign: five cases share the same phishing infrastructure (VERA-20260608-0003, VERA-20260610-0010, VERA-20260610-0013, VERA-20260612-0011, VERA-20260612-0028) and at least two confirmed sending MTAs (179.43.175.10, 212.73.150.20); gateway remediation and campaign-wide email triage must be executed as a single coordinated action, not per-case
microsoft-login.net campaign: two cases share delivery infrastructure (VERA-20260608-0002, VERA-20260609-0001); second phishing recipient in VERA-20260608-0002 remains unidentified — recipient sweep required
dnscat2 campaign: confirmed TTP overlap across VERA-20260608-0004 (cdn-metrics-pipe.io, ws-exec-005.corp.local) and VERA-20260611-0020 (cdn-metrics-pipe.io, ws-hr-099.corp.local); treat as a single campaign with at least two confirmed hosts; same_domain_count values in both cases indicate additional internal assets not yet identified
ws-fin-015.corp.local: this asset appears in VERA-20260610-0011 (Cobalt Strike), VERA-20260610-0013 (okta-verify.co phishing / post-exploitation), and VERA-20260611-0017 (DNSExfiltrator) — three cases, two confirmed malware families, multiple accounts compromised; isolation and forensic imaging of this single host must cover all three case tracks simultaneously
telemetry-cloud-api.com: appears in SIEM events across VERA-20260609-0001, VERA-20260610-0011, VERA-20260611-0020, and VERA-20260612-0028 from multiple source IPs; block at DNS resolver immediately and open a dedicated investigation thread
**Credential exposure:** c.wardlaw (confirmed credential submission to okta-verify.co; confirmed NTLM session on srv-jump-01.corp.local; LSASS confirmed on same host — treat all c.wardlaw credentials and tokens as fully compromised); m.reyes (confirmed credential submission
---
*VERA — Vigilant Event Response Agent — Tier 2*
*Eyes on the Glass | eyesontheglass.ai*
*Shift 10 | Output schema: vera_output_schema_v1.1.0*