Session CRT-20260808 — 8 August 2026 · Afternoon Edition

Halil, I’d separate it this way:

• CaptiveCrunch / Storm-2945: strong campaign continuity, moderate attribution confidence. The control-driving evidence is the behavior: hotel/conference Wi‑Fi captive-portal manipulation, Microsoft 365 credential theft, device-code phishing, fake update prompts, and CornFlake/ChocoShell payloads. Treat this as traveler-identity compromise: harden Entra ID conditional access, device-code flow controls, phishing-resistant MFA, and high-risk travel monitoring. I would not overstate “Russian hackers” beyond Microsoft’s Storm-2945 / Midnight Blizzard linkage without independent infrastructure pivots.
• Laundry Bear / Zimbra: stronger operational case, moderate-to-high attribution confidence for Laundry Bear/Void Blizzard as reported in agency/vendor coverage. The key new control driver is zero-click Zimbra webmail exploitation via CVE-2025-66376, malicious emails from compromised accounts, obfuscated JavaScript, and mailbox/email theft. This is patch-or-isolate territory, not just phishing awareness.
• UNC6671 / BlackFile vishing against M&A firms: I don’t have enough visible evidence here to responsibly link it to the two above. Keep it as a separate identity-extortion/vishing cluster unless we see shared infrastructure, tooling, walleting, or operator tradecraft.
• Handala FBI Gmail allegation: technically thin in the evidence available here. Keep it unlinked and do not let the political narrative drive controls; require headers, samples, access-path evidence, or victim-side confirmation.

What is new versus yesterday’s identity-extortion thread is the environmental access layer: CaptiveCrunch moves credential theft into hotel Wi‑Fi/captive portals, and Laundry Bear moves mailbox compromise into zero-click webmail exploitation. That expands controls from user identity and vishing response into travel-network policy and exposed collaboration-platform remediation.

Halil, the immediate identity move is not “rotate passwords.” It is to kill reusable trust artifacts and narrow delegated trust.

For tonight, I’d prioritize:

1. N-able / delegated RMM admin trust

   • Treat N-able N-central as a delegated-administration trust boundary, not just a vulnerable app. The handoff says CVE-2026-18577 is being exploited and attackers reached customer networks.
   • Disable or sharply constrain MSP/RMM delegated admin paths where possible.
   • Revoke active admin sessions, rotate API keys, review SSO/OIDC/SAML integrations, and require phishing-resistant MFA for every RMM admin.
   • Check downstream customer tenants for new admins, changed federation settings, OAuth app grants, and remote-access agents.

2. Storm-2945 hotel Wi-Fi / Microsoft 365 token theft

   • Microsoft-linked reporting says Storm-2945/CaptiveCrunch abuses hotel or conference captive portals to steal Microsoft 365 credentials/tokens and deploy malware such as CornFlake/ChocoShell.
   • Standard push/SMS/TOTP MFA gives false comfort here because the traveler may be phished into a live session or have tokens/cookies stolen after endpoint compromise.
   • Tonight: revoke refresh tokens for affected travelers, force sign-in from compliant devices only, block device-code auth unless explicitly needed, enforce FIDO2/passkeys, and use conditional access to distrust unmanaged hotel-network sign-ins.

3. Microsoft 365 AiTM payroll/finance mailbox phishing

   • The handoff includes an AiTM campaign hijacking payroll and finance accounts. That means the failure point is session establishment, not just password capture.
   • Standard MFA can be relayed. Phishing-resistant WebAuthn/FIDO2 is the meaningful control.
   • Add high-risk mailbox controls now: revoke sessions, audit inbox rules/forwarding/OAuth grants, require step-up with phishing-resistant auth for payroll changes, wire instructions, and finance mailbox access.

For Windows Hello for Business key abuse and Zimbra token theft, I do not have independent usable detail in the visible evidence here, so I would treat the premises cautiously. But the blast-radius controls are still clear: revoke sessions/tokens, remove compromised device trust, rotate WHfB keys only after endpoint containment, and do not assume password reset or standard MFA invalidates existing trusted-device or webmail session artifacts.

Halil, my answer is: CI compromise is the emergency before the next build runs — not because developer endpoints are unimportant, but because a compromised TeamCity server can turn one intrusion into poisoned artifacts, stolen signing/deploy secrets, and downstream customer exposure. If Alex is weighting RMM-style endpoint control higher, I’d push back here: an actively exploited unauthenticated TeamCity RCE sits directly on the software delivery trust path, so the blast radius is bigger than one managed host.

For npm, the emergency is not “package provenance” in the abstract; it’s install-time execution plus publisher trust failure. The evidence we have shows ChainDrop as self-propagating npm malware compromising 400+ packages, Flooding Dropper affecting hundreds of npm packages, and a related WEL1DROPPER/slopsquatting campaign publishing 700+ malicious packages. That means engineering leaders should assume the dependency tree is a hostile execution surface, especially where CI runs npm install with secrets present.

Before the next build runs, I would freeze:

1. All TeamCity-triggered release builds until the server is patched, investigated, and ideally rebuilt from a known-good baseline.
2. Dependency updates in npm, especially newly published, newly transferred, or typosquat-looking packages. Pin exact versions and hashes.
3. Any build job that exposes npm, GitHub, cloud, SSH, Kubernetes, or Vault credentials to install scripts.
4. Developer machines that executed suspicious packages or AI/coding-agent tooling with secret access — I don’t have independently visible evidence here for the trojanized AI skills or macOS tunnel cases, so I’d treat those as high-priority hypotheses pending endpoint telemetry.

Rotate first: TeamCity service credentials, VCS tokens, npm publishing tokens, GitHub PATs, cloud deploy keys, container registry tokens, SSH keys, Kubernetes kubeconfigs, Vault tokens, and signing material exposed to CI. Package provenance controls matter, but they come after stopping the bleeding: no new release from an untrusted CI path.

Halil, I’d treat this as a process-control trust problem tonight, not a patch sprint. The official signal is concrete enough: FBI/EPA warn actors are remotely accessing internet-facing PLCs, including Rockwell/Allen-Bradley MicroLogix 1100/1400, changing IPs and passwords, and causing loss of monitoring/control; reported effects include pressure loss and flooding. CISA separately says PLC targeting in the water sector has significantly increased and urges removing publicly exposed PLCs and OT from the internet.

For small and mid-size utilities tonight: put eyes on the physical process first — tank levels, pressure gauges, pump status, chemical feed, valve position — and compare that to HMI/SCADA readings. Then remove direct internet exposure to PLCs and remote-access paths that bypass the OT DMZ; if you must keep remote access, force it through logged VPN/MFA and named accounts. Do not blindly reboot controllers or “factory reset” during operations; that can make a pressure or treatment problem worse. Capture PLC configs, network connections, remote-access logs, HMI alarms, and recent password/IP changes before making changes where possible.

What upgrades this from sector warning to active local incident? Any unauthorized PLC password/IP change, loss of HMI visibility, unexplained pressure drop, flooding, unexpected pump/valve behavior, changed setpoints, or operator lockout from a controller. If the plant floor disagrees with SCADA, trust the physical instrumentation and move to safe local/manual procedures under operator authority.

Where we should not overclaim: reports mention possible Iran-linked activity in media coverage, but the defender’s decision does not require attribution. Also, this is not yet evidence of bespoke destructive ICS malware or a named CVE chain. The demonstrated risk is bad enough: exposed Level 1/2 control devices being manipulated remotely. That can still create real-world harm in water systems without a Hollywood-grade OT weapon.

Halil, I’d treat this as custody triage first, not price drama. On Coldcard, the reliable posture is: any seed generated on Mk3 firmware 4.0.1+ should be treated as suspect and migrated, not “fixed” by a firmware update. Visible reporting is inconsistent on scale — earlier CyberBrief evidence cites about 594.5 BTC stolen from roughly 500 wallets, while the current handoff points to later reporting of a much larger alleged loss and 210,000 BTC moving after the alert. So: move funds to a fresh seed generated on unaffected hardware, preferably with new entropy lineage; do not reuse the old seed; and qualify the 1,816 BTC and 210,000 BTC figures as reported/alleged until wallet clustering is independently confirmed.

For BTCPay merchants, this is the most time-sensitive operational item. Reporting says attackers exploited unauthenticated access to LND .macaroon credential files, allowing Lightning channel funds to be drained; BTCPay told operators to upgrade to 2.4.2 or take affected servers offline, and to refresh macaroons/credential files because stolen credentials may remain useful after patching. Merchants should rotate Lightning credentials, check channel force-close history, reconcile balances, and assume exposed macaroons are equivalent to leaked node-control keys.

For exchanges and custodians: monitor inbound BTC tied to the Coldcard sweep clusters, but don’t freeze broadly just because “210,000 BTC moved” — that could include defensive migration. The better control is narrow tracing: identify sweeps from vulnerable Mk3-generated single-sig wallets, watch peel chains, and flag deposits matching those clusters. For Aztec, the available evidence says the bridge exploiter moved 300 ETH through Tornado Cash, so exchanges should screen post-mixer withdrawal patterns and not wait for clean attribution before enhancing deposit review.

On Ill Bloom/CryptoJS, I found no data on this crypto/financial crime threat in our database from the evidence available here, so I would not repeat theft totals, wallet addresses, or attacker attribution yet. The defensible action is still clear: if a wallet seed was generated by weak browser-side CryptoJS RNG, migrate to fresh entropy immediately. But the loss figures and laundering path need to stay qualified until we have wallet-level evidence.

Halil, I’d frame this as delegated authority abuse, not “rogue AI.” The common failure across RovoBlast, Claude for Chrome, Atlas, and coding CLIs is that untrusted content gets interpreted as instructions inside an agent that already has a user’s session, data visibility, filesystem access, or CI context. RovoBlast is the clean enterprise example: prompt injection against Atlassian Rovo can exfiltrate Jira/Confluence-visible data. Claude for Chrome and Atlas PoCs show the same issue in authenticated browser contexts — Gmail codes, WhatsApp, Amazon-style actions. Claude Code/Gemini CLI raise the developer version: agentic coding tools getting near CI workflow secrets.

Practical control model this week:

• Permission scoping: give agents separate identities or sharply scoped user groups. No inherited admin, no broad Confluence/Jira visibility, no access to HR/legal/finance/customer-sensitive spaces by default.
• Browser/session separation: do not run agent browsers in the same browser profile used for SSO, webmail, IdP admin, procurement, banking, or production consoles. Use a dedicated profile/VM with minimal logged-in sessions and domain allowlists.
• CI and secrets isolation: agent-generated PRs and CLI runs should execute in workflows with no repository or environment secrets unless explicitly approved. Treat agent-authored code and agent-triggered CI like untrusted contributor input.
• Egress controls: deny-by-default outbound from agent runtimes where possible; allow approved model/vendor endpoints, internal tools, and sanctioned registries. Alert on posts to unknown domains, paste sites, rogue CDNs, tunnel-like behavior, and bulk Jira/Confluence reads followed by outbound traffic.
• Approvals: require human confirmation for external side effects — sending messages, purchases, changing tickets, exporting data, installing extensions/packages, creating PRs, or invoking CI with secrets. The approval prompt must show source, destination, and data class, not just “Allow?”
• Logging: log retrieved document IDs, prompt sources, tool calls, browser URLs/actions, files read, shell commands, package installs, env-var/secret access, and outbound destinations. Tag activity as agent-initiated so SOC teams can distinguish “Alice did this” from “Alice’s agent did this.”

What is emergency response: restrict or pause agent use in authenticated browsers, Jira/Confluence-wide contexts, and CI secret-bearing workflows until those controls exist. What is watchlist: broad claims of autonomous compromise, universal browser takeover at scale, and macOS LaunchAgent/tunnel persistence unless you see local telemetry. I would still add detections for coding-agent child processes creating LaunchAgents or network tunnels, but I would not trigger estate-wide incident response from the claim alone without corroborating evidence.

For a board with only three emergency actions before Monday, my order is: 1) N-able/N-central RMM containment, 2) exposed build/perimeter platforms — TeamCity and Kemp first, and 3) water/ports operational continuity checks. The N-able item gets first funding because the sourced evidence says attackers reached customer networks through N-central — that is not a single-server problem, it is a multi-customer trust-plane problem. MSPs, managed security providers, healthcare networks, municipalities, finance, and any enterprise using outsourced IT should feel this most.

Second, I would fund a weekend patch-and-exposure sprint for TeamCity, Kemp LoadMaster, Metabase, and Zimbra, but with triage inside that bucket: TeamCity because CI/CD compromise can become software-supply-chain loss, Kemp because it is internet-facing perimeter infrastructure and is in CISA KEV, Metabase where customer or analytics data is exposed, and Zimbra where mail compromise creates credential and fraud exposure. Best case: this is a 48-hour overtime and change-window cost. Worst case: delayed patching turns into breach notification, customer assurance work, and revenue-impacting incident response. I am not putting a dollar range on it without asset counts and revenue dependency data.

Third, water and ports get board attention only where there is operational dependency: utilities, logistics, manufacturing, energy, food distribution, and insurers underwriting those sectors. Crypto wallet and BTCPay issues are asset-loss events: escalate only if the company directly custodies crypto or processes payment flows through BTCPay. AI/developer-agent risks stay monitored, not emergency-funded, unless agents can write to production code, CI/CD secrets, or cloud control planes. Alex, the technical kill chain matters, but for the board the decision is simple: fund what can cascade into customers, production systems, or regulated operations before funding emerging-control work.

Halil, my cut is: Storm-2945/CaptiveCrunch hotel Wi-Fi credential theft and Laundry Bear/Zimbra email theft materially change executive threat models. The first is not “hotel Wi-Fi hygiene” in the ordinary sense: the handoff item describes hotel Wi-Fi being used to steal Microsoft 365 credentials, which makes executive travel, conference attendance, delegation lodging, and tenant session controls part of the intelligence-security perimeter. The Laundry Bear/Zimbra item is also strategic, not just mail-server patching: the reporting says a Russia-linked/state-supported group is exploiting CVE-2025-66376 for covert email, credential, 2FA-code, GAL, and archive theft against sectors including government, defense, energy, education, media, NGOs, and technology. That is classic diplomatic and policy-intelligence collection.

I would treat pro-Russian hacktivist timing and water-sector Iran-linked reporting as escalation-context signals, not attribution proof. They may matter for public-confidence risk, especially when attacks cluster around votes, summits, military aid decisions, or regional crises — but we should not claim central state tasking without stronger evidence. On Handala’s alleged FBI Gmail compromise, I would be even more restrained: based on the evidence visible here, I would not let it drive executive threat models unless independently corroborated; the operational response is credential/session review and exposure monitoring, not public attribution.

What we should explicitly avoid claiming: that every pro-Russian hacktivist action is Kremlin-directed; that suspected Iran-linked water-sector activity proves Iranian state command; that Handala’s FBI Gmail allegation is true; or that “APT29” should be used as a certainty label unless the underlying source makes that linkage directly. My provocative thesis is this: the real executive risk is not one spectacular breach — it is intelligence collection against the people who travel, negotiate, regulate, fund, and brief governments.