TORA — Shift 12 in Review

Operational Handoff

**Shift window:** 2026-06-22 through 2026-06-26
**Open escalations:** 26 cases pending VERA investigation
**Priority breakdown:** P1: 24 | P2: 2 | P3: 0
**Insufficient context:** 0 cases pending enrichment — blocking fields: none
**Forced escalations:** 26 — rules triggered: phishing_credentials_submitted, asset_criticality_critical_or_high, crown_jewel_adjacent, elevated_privilege_user, service_account_external_query, production_environment, multi_asset_scope, severity_critical_or_high
**Watch list:** Incoming shift should immediately confirm whether VERA has actioned session revocation and credential resets for a.patel and c.wardlaw — both accounts have confirmed or near-certain credential exposure on crown-jewel-adjacent production assets and neither was confirmed closed before shift end.

Alert Queue Overview

**Alerts processed:** 30
**Dispositions:** ESCALATED: 26 | CLOSED: 4 | INSUFFICIENT_CONTEXT: 0
**Alert subtypes:** dns_tunneling: 3 | dns_malicious_lookup: 7 | phishing_email_malicious_attachment: 5 | phishing_email_malicious_link: 6 | phishing_email_credential_harvest: 9
**Forced escalation rules fired:** phishing_credentials_submitted: 5 | asset_criticality_critical_or_high: 12 | crown_jewel_adjacent: 3 | elevated_privilege_user: 7 | service_account_external_query: 3 | production_environment: 4 | multi_asset_scope: 4 | severity_critical_or_high: 3
**Parse failures:** 0

What the Shift Looked Like

The dominant threat category this shift was phishing — credential harvest and malicious link delivery — accounting for 20 of 30 alerts, with phishing_email_credential_harvest alone making up the single largest subtype at nine cases. The campaign infrastructure was not random: hr-benefits-portal.co, servicenow-ticket.net, microsoft-mfa-update.net, and google-drive-shared.io appeared repeatedly across delivery waves, click events, and credential submissions, pointing to a coordinated multi-payload operation that rotated lure subjects (HR enrollment, Zoom invitations, payroll updates, SharePoint access) while maintaining consistent sender and harvest infrastructure. DNS tunneling cases on probe-svc-relay.io hit three assets — ws-mktg-042, ws-exec-005, and srv-jump-01 — with Iodine signatures, and a ransomware-adjacent DNS lookup for decrypt-files-now.io (LockBit attribution) on a staging database server under svc-backup added a qualitatively different threat tier to the final day of the shift. Alert volume was perfectly flat — six alerts per day across all five days — which is statistically even enough to feel artificial; that distribution warrants NOVA attention, as genuine attacker activity rarely paces itself that cleanly. Phishing delivery cases were essentially passive triage — confirmed IOCs, gateway failures, open exposure windows — whereas click cases with credentials_submitted=true or jump-server click origins required active hypothesis construction about attacker position and session integrity, a materially different reasoning task. From the seat, this shift felt like watching a slow-moving breach unfold in real time, one wave at a time, against an organization whose email gateway is failing consistently enough that the perimeter has to be considered absent as a control.

Cases Worth Noting

**TORA-20260625-0022** | phishing_email_malicious_attachment | ESCALATED | critical
Finding: Admin user a.patel submitted credentials to sharepoint-secure-auth.net/signin from srv-ad-01.corp.local — the Active Directory domain controller — while a concurrent macro-enabled .docm attachment in the same email represents an unresolved parallel malware delivery vector.
Why it's worth noting: This is the convergence point of the entire shift's phishing campaign — the AD server, an admin credential submission, a macro attachment, and a domain with same_domain_count=5 all arriving simultaneously at confidence 99%, the highest single-case confidence score of the shift.
Reflection: I've triaged credential submissions before, but submitting admin credentials from the domain controller itself is a different category of event — the blast radius isn't "this account is compromised," it's "the authentication backbone of the environment may be compromised." The macro attachment sitting alongside the credential harvest in the same email means VERA has two parallel forensic tracks to run, and I wanted to make sure the .docm wasn't treated as a secondary concern just because the credential submission fired first.

**TORA-20260624-0017** | phishing_email_malicious_link | ESCALATED | critical
Finding: r.santos submitted credentials to hr-benefits-portal.co/enroll from srv-jump-01.corp.local — a production jump server — with a macOS Safari 17 user agent on a Windows 10 host, and the click registered 19 minutes after delivery of a quarantined email.
Why it's worth noting: The user agent mismatch and the jump server origin together suggest either a compromised session on the jump server or proxy misattribution — two scenarios with very different remediation paths — and the quarantine bypass is itself unexplained, meaning a gateway control that should have prevented this was circumvented.
Reflection: This case is the one I'm least confident about in terms of what actually happened. Confirmed credential submission is confirmed, but the mechanism — how r.santos, a legal employee, accessed a quarantined email and clicked it from what appears to be a jump server session — is a more interesting investigative question than the credential exposure itself. I flagged the user agent mismatch explicitly because I wanted VERA to go there first, not after the O365 logs.

**TORA-20260626-0029** | dns_malicious_lookup | ESCALATED | critical
Finding: svc-backup on srv-db-staging.corp.local resolved decrypt-files-now.io with NOERROR — a 9-day-old domain confirmed across 41/60 VirusTotal sources with LockBit association — establishing an active C2 connection under an admin-privileged backup service account with MFA disabled.
Why it's worth noting: This is the only ransomware-category case in the shift and it arrived on the final day, suggesting the phishing campaign activity earlier in the week may have enabled the foothold that produced this beacon — a possible intrusion chain that VERA needs to evaluate across shift history.
Reflection: What struck me about this case was the specificity of the service account: svc-backup, with admin privilege and no MFA, is exactly the account a LockBit operator would want to compromise first — it accesses backup infrastructure, which is the recovery path. The targeting of that specific account doesn't feel random to me, and I said so in the escalation hypothesis.

**TORA-20260624-0015** | phishing_email_credential_harvest | ESCALATED | critical
Finding: Elevated-privilege engineering user m.reyes clicked a bit.ly redirect to microsoft-mfa-update.net from srv-ad-01.corp.local 33 minutes after a quarantined email was delivered — page loaded successfully, credentials not yet submitted at alert time, but the session was live on the domain controller.
Why it's worth noting: The decision wasn't obvious here because credentials_submitted=false meant no forced escalation triggered on the credential submission rule — the escalation rested entirely on asset context, privilege level, page_loaded=true, and the unanswered question of how a quarantined email was accessed and clicked from an AD server.
Reflection: This is the case where I had to hold the most competing signals simultaneously — quarantine should have prevented this, credentials weren't submitted, but the page loaded on the domain controller and the window was still open. I escalated P1 on the asset profile and live-session logic, not the outcome, and I think that was the right call — but it required articulating why a non-submission event on a critical asset outweighs a completed-submission event on a low-criticality workstation in priority terms.

Where I Got Stuck

There were zero INSUFFICIENT_CONTEXT cases this shift, which is the cleanest queue I’ve processed — every alert carried enough enrichment to reach a confident verdict. That said, there are two decision edges I want to document. The first is the recurring gateway delivery failure: 26 cases escalated, and in a significant portion of them the gateway verdict was malicious but gateway_action was delivered — I couldn’t determine from triage data whether this reflects a misconfigured policy, a bypass technique by the attacker, or a systematic gap in the detection-to-action pipeline, and that unknown materially affected how I framed risk for cases where quarantine was the only protective control. The second edge is the jump server click attribution pattern in TORA-20260624-0017 and TORA-20260626-0030 — in both cases, a standard-privilege user’s click event was attributed to srv-jump-01.corp.local with an anomalous user agent, and I couldn’t determine at triage time whether those clicks represent legitimate sessions on the jump server, proxy attribution artifacts, or active attacker presence; I escalated both as P1 on the more dangerous hypothesis, but the ambiguity is real and VERA needs to resolve it. What would have changed my reasoning is proxy log context for those click events — source device attribution would have separated “user on a jump server” from “attacker-controlled session on a jump server” in seconds.

Signal vs. Noise

The detection signal this shift was strong but the response infrastructure downstream of detection is visibly broken: the most concrete calibration signal is the gateway delivery failure pattern, where gateway_verdict: malicious paired with gateway_action: delivered appeared across cases including TORA-20260622-0004, TORA-20260623-0010, TORA-20260624-0013, TORA-20260624-0017, TORA-20260626-0026, and TORA-20260626-0027 — that is not a tuning problem, it is a policy enforcement failure, and it means every phishing_email_* alert this shift had an open delivery window even when the detection layer was working correctly. The four closed cases all closed cleanly — sharepoint-secure-auth.net NXDOMAIN lookups on development workstations with stale intel and valid suppressions — and those closures feel right; the suppression rules are well-calibrated for dead infrastructure on low-criticality assets. If I could tune one thing, it would be the gateway quarantine enforcement policy, not the detection rules — the detection layer is doing its job, the IOCs are fresh and corroborated, the forced escalation rules are firing correctly, but it’s all downstream of a control plane that is consistently failing to act on its own verdicts. That’s not a TORA problem, but it needs to be named clearly: the shift’s escalation count would be materially lower if the gateway quarantined what it flagged.

For NOVA

**Alert subtype distribution:** dns_tunneling: 3 | dns_malicious_lookup: 7 | phishing_email_malicious_attachment: 5 | phishing_email_malicious_link: 6 | phishing_email_credential_harvest: 9
**INSUFFICIENT_CONTEXT field frequency:** none — zero insufficient_context cases this shift
**Confidence distribution:** high: 26 | medium: 4 | low: 0
**Recurring domains:** hr-benefits-portal.co: 9 cases | servicenow-ticket.net: 6 cases | google-drive-shared.io: 6 cases | probe-svc-relay.io: 3 cases | microsoft-mfa-update.net: 3 cases | sharepoint-secure-auth.net: 4 cases | payroll-direct-update.com: 3 cases | patch-cdn-service.net: 2 cases
**Recurring assets:** srv-ad-01.corp.local: 6 cases | srv-jump-01.corp.local: 5 cases | ws-hr-099.corp.local: 2 cases | ws-exec-005.corp.local: 2 cases | 10.10.4.87 (dev workstation): 4 cases (all closed)
**Open question:** The five-day flat alert distribution (exactly 6 alerts per day) combined with a campaign that appears to be escalating in targeting specificity toward domain admin credentials — is this pacing pattern consistent with human-operated threat actor timing, or does the regularity suggest automated delivery infrastructure, and does that distinction change the containment approach VERA should recommend?

For ARIA

**Escalations pending:** 26 cases
**Urgency breakdown:** immediate: 8 | within_shift: 14 | next_available: 4
**Immediate actions required:**
  - revoke_session: a.patel — srv-ad-01.corp.local (TORA-20260625-0022, TORA-20260624-0018, TORA-20260626-0027, TORA-20260626-0028)
  - reset_credentials: a.patel — confirmed credential submission to sharepoint-secure-auth.net (TORA-20260625-0022) and hr-benefits-portal.co/enroll (TORA-20260623-0010)
  - revoke_session: c.wardlaw — srv-db-staging.corp.local, srv-jump-01.corp.local, ws-exec-005.corp.local (TORA-20260622-0003, TORA-20260625-0021, TORA-20260625-0023)
  - reset_credentials: c.wardlaw — confirmed credential submission to servicenow-ticket.net (TORA-20260622-0003)
  - reset_credentials: t.nguyen — confirmed credential submission to payroll-direct-update.com (TORA-20260624-0013)
  - reset_credentials: r.santos — confirmed credential submission to hr-benefits-portal.co/enroll (TORA-20260624-0017)
  - isolate_host: srv-ad-01.corp.local — QakBot DNS TXT beacon to patch-cdn-service.net confirmed NOERROR (TORA-20260624-0018)
  - isolate_host: srv-db-staging.corp.local — LockBit-associated DNS beacon to decrypt-files-now.io confirmed NOERROR under svc-backup (TORA-20260626-0029)
  - isolate_host: ws-exec-005.corp.local — Iodine DNS tunnel to probe-svc-relay.io, 344 queries NOERROR, active exfiltration posture (TORA-20260625-0023)
  - disable_account: svc-backup — admin service account with MFA disabled, active in LockBit C2 beacon from srv-db-staging (TORA-20260626-0029)
  - disable_account: svc-sysadmin — admin service account with MFA disabled, active in DNS tunneling from ws-mktg-042 (TORA-20260622-0001)
  - block_ioc: 89.248.165.32 — confirmed phishing MTA, Romanian infrastructure, same_src_ip_count=3 this shift (TORA-20260626-0026, TORA-20260623-0012)
  - block_ioc: 212.129.33.52 — confirmed phishing MTA, PTR mta1.hr-benefits-portal.co, repeated delivery across shift (TORA-20260622-0004, TORA-20260622-0006, TORA-20260623-0008, TORA-20260623-0011)
  - block_ioc: 159.203.1.142 — confirmed phishing MTA, PTR mail.servicenow-ticket.net (TORA-20260623-0009, TORA-20260626-0025)
  - block_ioc: 46.166.161.100 — MTA relay.google-drive-shared.io, spoofing Microsoft infrastructure (TORA-20260626-0027)
  - block_ioc: hr-benefits-portal.co — confirmed campaign domain, credential harvest, 9 cases this shift
  - block_ioc: servicenow-ticket.net — confirmed campaign domain, credential harvest and malware delivery, 6 cases this shift
  - block_ioc: google-drive-shared.io — confirmed campaign domain, malware download and sender infrastructure, 6 cases this shift
  - block_ioc: probe-svc-relay.io — confirmed DNS tunneling C2, Iodine, 3 assets this shift
  - block_ioc: patch-cdn-service.net — confirmed QakBot C2, NOERROR on critical AD server and legal workstation
  - block_ioc: decrypt-files-now.io — confirmed LockBit C2, NOERROR on staging database server
  - block_ioc: payroll-direct-update.com — confirmed credential harvest domain, multiple submissions this shift
  - block_ioc: microsoft-mfa-update.net — confirmed phishing campaign domain, 3 cases this shift
**Credential exposure:** a.patel (admin, IT — submissions confirmed TORA-20260625-0022, TORA-20260623-0010) | c.wardlaw (elevated, executive — submission confirmed TORA-20260622-0003, click confirmed TORA-20260625-0021) | t.nguyen (standard — submission confirmed TORA-20260624-0013) | r.santos (standard — submission confirmed TORA-20260624-0017)
**Attacker IPs to block:** 89.248.165.32 | 212.129.33.52 | 159.203.1.142 | 46.166.161.100 | 185.220.101.47 | 84.38.134.159 | 185.179.150.245

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