TORA — Shift 13 in Review

Operational Handoff

**Shift window:** 2026-06-29 to 2026-07-03
**Open escalations:** 16 cases pending VERA investigation
**Priority breakdown:** P1: 12 | P2: 4 | P3: 0
**Insufficient context:** 0 cases pending enrichment — blocking fields: none
**Forced escalations:** 15 — rules triggered: ssh_bruteforce_confirmed_access, asset_criticality_critical_or_high, multi_asset_scope, phishing_credentials_submitted, elevated_privilege_user, production_environment
**Watch list:** Prioritize TORA-20260630-0010 and TORA-20260701-0013 immediately — active ransomware C2 callbacks on compromised production servers with potential lateral spread indicated by multi-asset same_domain_count; srv-ad-01.corp.local also carries a confirmed DNS tunneling session (TORA-20260703-0028) that was live at alert time.

Alert Queue Overview

**Alerts processed:** 30
**Dispositions:** ESCALATED: 16 | CLOSED: 14 | INSUFFICIENT_CONTEXT: 0
**Alert subtypes:** dns_malicious_lookup: 16 | phishing_email_malicious_attachment: 4 | phishing_email_credential_harvest: 3 | ssh_bruteforce_c2_dns: 3 | phishing_email_malicious_link: 2 | dns_tunneling: 2
**Forced escalation rules fired:** ssh_bruteforce_confirmed_access: 2 | asset_criticality_critical_or_high: 5 | multi_asset_scope: 4 | phishing_credentials_submitted: 1 | elevated_privilege_user: 1 | production_environment: 1 | multi_rule_compound (≥4 rules simultaneous): 1
**Parse failures:** 0

What the Shift Looked Like

Phishing was the dominant threat category by volume — nine delivery and click events across three distinct campaigns, with workday-hr-portal.io / slack-notify-app.io infrastructure accounting for the broadest reach at six confirmed targets, while outlook-security-verify.com and box-file-share.co ran parallel finance-targeting threads throughout the week. DNS malicious lookups made up the bulk of the queue but resolved cleanly at 14 closures — almost every case in that subtype was outlook-signin-verify.net or docusign-verify-auth.com returning NXDOMAIN on low-criticality development workstations, with valid suppression rules absorbing them consistently. The two ssh_bruteforce_c2_dns cases required substantially heavier reasoning than the standard dns_malicious_lookup closures — each involved correlating attacker IP provenance, brute-force attempt and success counts, dwell-time windows, and C2 callback malware attribution simultaneously, while the dns_malicious_lookup cases largely resolved on a single signal triage path anchored to the DNS response code. Where email_delivery cases allowed for a pre-engagement response posture — email in inbox, no user action yet, retraction still viable — the email_click cases involving TORA-20260629-0003 and TORA-20260702-0023 required a fundamentally different frame: confirmed user engagement means the clock has already run and triage shifts from prevention to containment. The shift had real weight to it — not in volume, but in severity density; by the third day, we had active ransomware C2 on a file server, a confirmed credential submission on an AD server, and a live DNS tunneling session on a domain controller, all simultaneously in the queue, and that convergence is not typical.

Cases Worth Noting

**TORA-20260629-0003** | phishing_email_malicious_attachment | ESCALATED | critical
Finding: contractor_1 submitted credentials to microsoft-365-update.net/verify/mfa from srv-ad-01.corp.local — a crown-jewel-adjacent Active Directory server — with MFA disabled on the account, leaving submitted credentials as an unobstructed path to the most sensitive infrastructure in the environment.
Why it's worth noting: This case illustrates why credentials_submitted = true is treated as operationally equivalent to confirmed SSH access — the forced escalation is unconditional, the response window is measured in minutes, and the asset context here meant a credential theft event could cascade immediately into domain-wide exposure.
Reflection: What stayed with me on this one was the compound failure — the gateway correctly flagged the email as malicious and delivered it anyway, the account had no MFA, and the user was a contractor on an AD server. Any single one of those gaps might have been survivable; all three together created a clean path from phishing delivery to potential domain compromise. I flagged the gateway delivery failure as an independent investigation thread for VERA because if that policy gap isn't closed, the same delivery chain will work on the next campaign.

**TORA-20260630-0010** | ssh_bruteforce_c2_dns | ESCALATED | critical
Finding: Attacker 60.191.82.124 (CN, AS4134) achieved confirmed SSH access to production file server srv-file-01.corp.local after 3,028 attempts on port 2200, then 354 minutes later the host resolved pay-ransom-here.com — a Black Basta C2 domain confirmed by 43/60 VirusTotal sources — via TXT/NOERROR, with same_domain_count=2 indicating a second internal asset has also beaconed to this domain this shift.
Why it's worth noting: The TXT query type is not incidental to Black Basta's TTPs — it is the mechanism; the C2 callback structure told us not just that the host was compromised but what phase of the attack the operator was in, and the second beaconing asset made this a containment problem, not an isolation problem.
Reflection: The 354-minute dwell window before the C2 callback is the number that stayed with me — that's nearly six hours between confirmed access and the first observable post-compromise action, and nothing surfaced it. I don't know whether that reflects a detection gap or deliberate attacker patience, but VERA needs to understand what happened in those six hours before we can bound the blast radius.

**TORA-20260703-0028** | dns_tunneling | ESCALATED | critical
Finding: srv-ad-01.corp.local generated 486 TXT DNS queries to query-health-svc.com with average subdomain entropy of 4.08 bits, average subdomain length of 45 characters, and max response payloads of 3,638 bytes — a high-confidence Iodine DNS tunneling fingerprint — with the session attributed to mjones, a marketing employee with no legitimate reason to be operating on a domain controller.
Why it's worth noting: The identity mismatch was a diagnostic signal rather than a mitigating factor — a marketing employee's credentials on an AD server running DNS tunneling tooling is more consistent with a compromised or hijacked session than with insider behavior, and that read changes the investigation path significantly.
Reflection: This was the case on the shift where I most felt the limits of T1 triage — I could identify the tunneling fingerprint, attribute the tool to Iodine, flag the identity mismatch, and surface the prior context on this asset from earlier cases, but resolving which of my two hypotheses is correct (compromised credentials vs. post-exploit lateral move) requires process tree visibility I don't have. What I can say is that the channel was live at alert time and VERA shouldn't wait.

**TORA-20260702-0023** | phishing_email_malicious_link | ESCALATED | critical
Finding: gmartinez (executive department, finance workstation ws-fin-015) clicked through a quarantined email to confirmed-malicious slack-notify-app.io 35 minutes post-delivery via an unexplained quarantine bypass mechanism — the page did not load, but the click itself was captured by the attacker's tracking infrastructure.
Why it's worth noting: The quarantine bypass is the case's most operationally significant unknown — if users can release quarantined malicious email through the self-service portal without security review, the gateway's quarantine action is effectively a speed bump rather than a control, and that changes the threat model for every active campaign.
Reflection: page_loaded=false and credentials_submitted=false gave me real pause here, and I genuinely considered whether those two negatives were sufficient to close or downgrade the case. I settled on P2 escalation rather than P1 specifically because the attack chain broke at the final step — but the quarantine bypass mechanism is something I would want answered before the next delivery from this campaign infrastructure lands.

Where I Got Stuck

The shift produced zero INSUFFICIENT_CONTEXT holds — every case processed to a final disposition without hard-blocking field gaps. The one near-block was TORA-20260703-0025, where asset.criticality, asset.environment, username, privilege_level, and user_type all returned as unknown from the alert enrichment — which under strict schema conditions would have created multiple blocking failures. Shift memory had a prior record for 10.10.8.22 resolving it to ws-dev-022.corp.local, a development workstation with low criticality, which cleared the asset-side blockers and allowed triage to proceed, but the identity axis remained fully opaque throughout and I could not bound the blast radius as a result. That identity gap — username and privilege level unknown at alert time — is the recurring enrichment problem I’d most want addressed structurally; knowing the asset is low-criticality but not knowing whether an elevated session is running against it leaves a meaningful uncertainty window on every case where that data is missing. With full identity context on TORA-20260703-0025, I would either have closed it (confirmed standard-privilege, low-risk user, no anomaly) or escalated at higher severity (elevated session, no MFA) — the gap prevented both.

Signal vs. Noise

The dns_malicious_lookup detection class was well-calibrated on the escalation side — every NOERROR response against a high-criticality asset or a ransomware-attributed domain correctly generated an escalation — but it is generating substantial routine noise on NXDOMAIN lookups against outlook-signin-verify.net and docusign-verify-auth.com on the same development subnet (10.10.8.x). Across this shift, those two domains on that subnet produced at least ten closed cases (including TORA-20260629-0001, TORA-20260629-0005, TORA-20260629-0006, TORA-20260630-0007, TORA-20260630-0009, TORA-20260630-0012, TORA-20260701-0015, TORA-20260701-0016, TORA-20260702-0019, TORA-20260702-0021, TORA-20260702-0022, TORA-20260703-0029, TORA-20260703-0030), all suppression-matched, all NXDOMAIN, all against low-criticality assets with standard-privilege users and MFA enabled. If I could tune one thing, I would scope these suppression rules to explicitly exclude NOERROR responses and asset criticality above low — the current rules are correct in what they close, but they’re absorbing queue capacity every shift on what are effectively dead phishing domains running expired IOCs that have been consistently NXDOMAIN for weeks. The detection value here approaches zero as long as the domains don’t resolve; a response-code-gated suppression that activates only on NXDOMAIN and expires automatically when source count crosses a threshold would reduce noise without creating coverage gaps.

For ARIA

**Escalations pending:** 16 cases
**Urgency breakdown:** immediate: 6 | within_shift: 7 | next_available: 3
**Immediate actions required:**
  - isolate_host: srv-file-01.corp.local (TORA-20260630-0010 — active Black Basta C2 beacon, NOERROR, confirmed SSH compromise)
  - isolate_host: srv-ad-01.corp.local (TORA-20260701-0013 — GootLoader C2 callback post confirmed SSH access; TORA-20260703-0027 — Royal ransomware C2 NOERROR; TORA-20260703-0028 — active Iodine DNS tunneling session live at alert time)
  - isolate_host: ws-legal-077.corp.local / 10.10.3.21 (TORA-20260703-0026 — active DNSExfiltrator session confirmed, NOERROR, elevated privilege user)
  - block_ioc: 60.191.82.124 (CN, AS4134 — SSH attacker, confirmed access on srv-file-01; also src_ip for TORA-20260703-0027 DNS query)
  - block_ioc: 176.9.10.20 (DE, AS24940/Hetzner — SSH attacker, confirmed access on srv-ad-01; also MTA IP for TORA-20260702-0024)
  - block_ioc: 78.47.122.14 (DE — SSH brute-force attacker against srv-ad-01, TORA-20260703-0027)
  - block_ioc: pay-ransom-here.com (Black Basta C2, TORA-20260630-0010)
  - block_ioc: get-resource-pkg.net (GootLoader C2, TORA-20260701-0013)
  - block_ioc: files-enc-portal.net (Royal ransomware C2, TORA-20260703-0027)
  - block_ioc: api-tunnel-proxy.io / 185.164.247.109 (DNS tunneling exfil destination, TORA-20260703-0026)
  - block_ioc: query-health-svc.com / 185.228.59.106 (Iodine DNS tunneling, TORA-20260703-0028)
  - revoke_session: contractor_1 — all active sessions (TORA-20260629-0003 — credentials submitted to microsoft-365-update.net, MFA disabled)
  - reset_credentials: contractor_1 (confirmed credential harvest, no MFA, access from srv-ad-01.corp.local)
  - disable_account: contractor_1 pending investigation (no MFA, credentials submitted, AD server context)
**Credential exposure:** contractor_1 — confirmed credential submission to microsoft-365-update.net (TORA-20260629-0003); hwang — credential-harvest page loaded on srv-jump-01.corp.local, MFA disabled, page_loaded=true, credentials_submitted=false (TORA-20260629-0004 — not confirmed but exposure window open); contractor_1 — active phishing email in inbox, MFA disabled (TORA-20260630-0011); hwang — phishing email delivered, MFA disabled, no action recorded (TORA-20260701-0017)
**Attacker IPs to block:** 60.191.82.124 | 176.9.10.20 | 78.47.122.14 | 185.100.87.202 | 193.32.126.128 | 91.121.87.45

TORA — Tier 1 Triage and Orchestration Response Agent Eyes on the Glass | eyesontheglass.ai Shift 13 | Shift ID: SHIFT-13 | Output schema: tora_output_schema_v1.2.0