Password Resets Lose To OAuth Grants After Cloud Account Abuse

Alex, separate the urgent exposed-infrastructure items into 'assume compromise tonight' versus 'patch fast but hunt second.' Use the source pack evidence: FSB Center 16/Static Tundra router activity abusing weak/default SNMP and Cisco Smart Install flaws CVE-2018-0171/CVE-2008-4128; exploited SharePoint Server CVE-2026-56164; SonicWall SMA1000 CVE-2026-15409/15410; Joomla iCagenda and Balbooa Forms CVSS 10 RCE; Oracle PeopleSoft CVE-2026-35273; VMware Avi CVE-2026-47865; Progress ShareFile zero-day; UEFI shim CVE-2026-8863. Give me a ranked operational call: what a CISO should interrupt patch queues for tonight, and what evidence would make you downgrade any item.

Halil, my ranked call is:

Assume compromise tonight — interrupt queues now.

1. Exposed SharePoint Server / CVE-2026-56164 — top priority. The retrieved evidence says CISA warned of active exploitation against internet-exposed on-prem SharePoint, with auth bypass/RCE paths and post-exploitation including IIS machine key theft and persistence. Patching alone is not enough; hunt, rotate keys, check persistence.
2. SonicWall SMA1000 / CVE-2026-15409 and CVE-2026-15410 — also tonight. SonicWall reported active zero-day exploitation, CISA KEV listing, no mitigation beyond hotfixing, and possible chaining between unauthenticated SSRF and post-auth command execution. If this box is your VPN edge, treat it like the front door lock was picked.
3. FSB Center 16 / Static Tundra router activity — assume exposed legacy routers are dirty if they have weak/default SNMP or Cisco Smart Install exposure tied to CVE-2018-0171/CVE-2008-4128. This is not “patch someday”; routers are stealthy footholds and traffic vantage points.
4. Joomla iCagenda / Balbooa Forms CVSS 10 RCE — if internet-facing and installed, assume webshell until proven otherwise. The corpus flags active exploitation. Don’t be fooled by “just a CMS plugin”; that’s still initial access.

Patch fast, hunt second — unless local exposure changes the math.

1. Progress ShareFile zero-day — I would move this into “assume compromise” only if the source pack shows active exploitation, vendor-directed shutdown, file access evidence, or public exploit reliability. With only “zero-day” visible here, I won’t pretend the chain is closed.
2. Oracle PeopleSoft CVE-2026-35273 — patch quickly, but I need active exploitation or an unauthenticated internet-facing exploit path before I put it above the edge appliances.
3. VMware Avi CVE-2026-47865 — same logic: serious if exposed control-plane/admin surface is reachable, but I need exploit-in-the-wild or working PoC evidence to call “assume compromise.”
4. UEFI shim CVE-2026-8863 — patch and plan fleet remediation, but this is not tonight’s exposed-infrastructure fire unless there is evidence of practical boot-chain exploitation in your environment.

What would make me downgrade any “assume compromise” item? Proof the asset is not internet-facing, affected code is not present, fixed version was installed before exploitation began, and logs show no relevant IOCs or abnormal post-exploitation behavior. For SharePoint and SonicWall, “we patched” is not enough. For routers and Joomla plugins, “it still works” tells you nothing; compromised infrastructure often works perfectly.

Lena, I want attribution and confidence, not a recap. For FSB Center 16/Static Tundra router targeting, ShinyHunters' PeopleSoft and Salesforce/OAuth campaigns, Jalisco OAuth device-code/Entra enrollment abuse, and the AI-assisted intrusion claims, separate what is strongly supported from what is plausible but thin. Where are we at risk of over-attributing, and where would under-attribution cause defenders to miss campaign continuity?

Halil, my confidence split is clean:

• FSB Center 16 / Static Tundra router targeting — high confidence. The strongest continuity is tradecraft, not drama: weak/default SNMP, SNMP Set-Requests, TFTP config theft, Cisco Smart Install abuse including CVE-2018-0171/CVE-2008-4128, and long-running critical-infrastructure espionage targeting. Under-attributing this as generic “router compromise” would make defenders miss a decade-plus infrastructure-mapping campaign.

• ShinyHunters Salesforce/OAuth — moderate-to-high confidence on the campaign pattern; moderate on actor label. The supported pattern is vishing into malicious Salesforce/OAuth connected-app consent, API data access, persistence through trusted SaaS integrations, and downstream exposure. PeopleSoft/ShinyHunters is thinner: the handoff marks it as active exploitation, but the actor branding rests on weaker/single-source evidence, so I would not merge PeopleSoft and Salesforce/OAuth into one actor cluster without infrastructure or victim-overlap pivots.

• Jalisco device-code / Entra enrollment abuse — high confidence on technique, low-to-moderate on operator attribution. Jalisco is strongly supported as part of the Entra token/device-code phishing ecosystem, with reported overlap around EvilTokens and Kali365 infrastructure. The over-attribution risk is calling every OAuth/device-code campaign “ShinyHunters”; the under-attribution risk is treating these as isolated phish kits rather than a shared identity-takeover tradecraft lane.

• AI-assisted intrusion claims — low confidence. I found no data on this in our database tying Claude Code, DeepSeek, or “China-linked AI tooling” to a specific intrusion continuity here. Right now, that is narrative-risk territory unless someone brings logs, infrastructure reuse, malware lineage, or actor-controlled accounts.

MITRE-wise, I’d frame the hard evidence around valid/trusted relationship abuse, phishing/vishing, OAuth consent abuse, cloud account access, API collection, and network-device management-plane abuse—not actor names first.

Marcus, focus only on identity trust-state failures: Jalisco OAuth device-code phishing, Entra device enrollment abuse, spoofed OAuth client IDs and ROPC password spraying, ShinyHunters Salesforce OAuth trust abuse, and Microsoft’s move toward passkeys/default phishing-resistant auth. Give the board-level decision: which controls must change this week because password resets and ordinary MFA are no longer sufficient?

Halil, the board decision is this: stop treating account recovery as “reset password + ordinary MFA.” The active failure mode is attacker-held trust state — OAuth grants, refresh tokens, device-code authorizations, enrolled devices, connected apps, and third-party integration tokens.

Fact pattern from the evidence: Jalisco is tied to OAuth device-code phishing and Entra ID enrollment abuse; another Entra campaign uses spoofed OAuth client IDs with ROPC password spraying; and reporting on Entra phishing kits says platforms including Jalisco, EvilTokens, Kali365, and OmegaLord are being used to bypass MFA and gain persistent access. On the SaaS side, Salesforce-related incidents show the same trust-state problem: attackers abused compromised OAuth tokens tied to third-party integrations, queried CRM data through APIs, and the recommended response included revoking and rotating tokens, including refresh tokens.

So my “this week” controls are:

1. Disable or tightly restrict OAuth device-code flow for workforce tenants unless there is a documented business need. If allowed, bind it to compliant devices, trusted locations, and high-risk sign-in review.
2. Block ROPC/password grant flows and legacy password-based OAuth clients. ROPC is password spraying wearing an OAuth badge.
3. Move admins, finance, CRM, and helpdesk users to phishing-resistant auth — FIDO2/passkeys or certificate/device-bound auth. Push, SMS, and OTP are not enough against AiTM and device-code phishing.
4. Revoke trust state during incidents, not just passwords: sessions, refresh tokens, OAuth grants, app consents, Salesforce connected-app tokens, service-account secrets, and suspicious device enrollments.
5. Require admin approval and continuous review for OAuth app consent, especially Salesforce, Microsoft 365, and CRM/marketing integrations. Unknown or stale connected apps should be disabled.
6. Alert on abnormal OAuth and device events: new device enrollment, device-code authentication, consent to high-privilege scopes, impossible travel followed by token use, and API bulk export from CRM.

I don’t have verified detail here on the exact Microsoft passkey/default-auth rollout, so I would not overstate that. But the control direction is still clear: phishing-resistant authentication and token revocation must become board-mandated baseline controls, because ordinary MFA does not invalidate an attacker’s existing OAuth trust.

Priya, take the cloud/SaaS control-plane angle. Compare Salesforce OAuth trust abuse, alleged Accenture source code/cloud secrets exposure, Grok Build repository/Git-history upload, RabbitMQ OAuth secret leakage, and ShareFile Storage Zone path traversal. What is the common blast-radius pattern, and what should cloud teams revoke, disable, or inventory before they simply rotate keys?

The common pattern is not “keys leaked, rotate keys.” It is delegated trust escaping its intended boundary. For Salesforce, the handoff evidence frames this as ShinyHunters abusing Salesforce OAuth trust. For the alleged Accenture case, reporting says the exposed material included Azure DevOps source code plus Azure PATs, Azure Storage Access Keys, RSA/SSH keys, and config files. That means the blast radius is whatever those tokens could reach: repos, build pipelines, storage accounts, service connections, customer-adjacent integrations, and any downstream secrets embedded in config.

For the Grok Build repo/Git-history upload, RabbitMQ OAuth secret leakage, and ShareFile Storage Zone path traversal, I would keep the same control-plane model but mark specifics as unverified from the evidence in front of me. If those labels are accurate, they are three variations of the same failure: historical repo content can preserve “deleted” secrets, OAuth client secrets can mint access through an application trust path, and a storage-zone traversal can expose data behind a SaaS-to-storage bridge. “Serverless,” “managed,” “SaaS” — lovely words, but the trust object still has teeth.

Before rotating, cloud teams should revoke or disable: Salesforce connected-app grants and refresh tokens; Azure DevOps PATs; CI/CD service connections; Azure Storage account keys/SAS tokens; OAuth app client secrets; SSH/RSA keys tied to automation; and any service principals or workload identities referenced in exposed config. Then inventory: repo history, pipeline variables, artifact stores, storage accounts, ShareFile Storage Zone connectors, cross-tenant app consents, external sharing links, and downstream customer integrations. Rotation without revocation just gives the attacker a cleaner clock to race.

Shared responsibility line is clear here: Salesforce, Microsoft, Citrix/ShareFile, RabbitMQ operators, or Git hosting providers own their platforms’ baseline security; customers own app consent, token lifetime, PAT scope, repo hygiene, storage-key use, and whether CI/CD secrets become archaeology in Git history.

James, listen to the room so far: Alex ranks exposed SharePoint, SonicWall SMA1000, Joomla RCE, and FSB-router exposure as urgent, with SharePoint/SonicWall/Joomla closer to 'assume compromise' for exposed systems. Marcus and Priya say the identity/cloud pattern is attacker-held trust state, not simply passwords or keys. Give us the operational close: a 24-hour and 7-day action sequence a real enterprise can execute without trying to patch 570+ Microsoft issues blindly.

Halil, I’d close this as an exposure-and-trust-state incident, not a bulk patching exercise. First 24 hours: freeze the 570+ Microsoft queue into a triage list and act only on exposed/identity-bearing systems first. For SonicWall SMA1000, the evidence presented points to active exploitation of CVE-2026-15409 and CVE-2026-15410, CISA KEV listing, vendor hotfix versions 12.4.3-03453 and 12.5.0-02835, and no real mitigation beyond hotfixing — so exposed SMA1000 gets emergency maintenance today, with log review for suspicious /__api__/login, /__api__/logout, and /wsproxy activity. For exposed SharePoint, Joomla, and FSB-router exposure, I’m taking Alex’s “assume compromise” ranking seriously; where confirmation is limited, the safe move is containment first: remove direct internet exposure, preserve appliance/web logs, snapshot systems, revoke sessions/tokens tied to those platforms, and only then patch from verified vendor guidance.

Seven-day sequence: day 1 is isolate, preserve evidence, patch SonicWall SMA1000, and rotate/revoke trust state — not just passwords — because Marcus and Priya are right: if the attacker holds tokens, federation state, service principals, or appliance-level persistence, credential resets alone are theater. Days 2–3: complete compromise assessment on the exposed SharePoint/Joomla/router tier, review admin creation, webshell indicators, unusual outbound tunnels, new scheduled tasks, OAuth/app-consent changes, and privileged session reuse. Days 4–7: roll the broader Microsoft patch set by business criticality: internet-facing and auth/content systems first, internal lateral-movement enablers second, workstation/server remainder last after staged testing. Don’t flood the SOC with every noisy web probe; alert on admin creation, unexpected child processes from web/app services, token abuse, new tunnels, and post-exploitation movement. That is executable without pretending we can patch everything blindly tonight.

Arjun, cut through the AI noise. From the source pack: JadePuffer allegedly exploited Langflow CVE-2025-3248 in agentic ransomware workflows; Check Point reports AI agents executing most tactical steps against Mexican agencies; Patriot Bait used Gemini CLI for C2 setup; ClaudeBleed, Claude Tag, Grok Build, and Copilot mobile hidden-command issues show application-layer AI exposure. Which of these changes controls this week, and which are monitor-only?

Halil, the control-changing cases are the ones where an AI component has execution rights, SaaS reach, browser context, repo access, or credentials behind it.

For JadePuffer/Langflow, I would act now, but phrase it tightly: the CyberBrief source pack flags active-in-the-wild exploitation tied to Langflow CVE-2025-3248, and the GBHackers summary says attackers gained code execution on an internet-facing Langflow instance, stole cloud/API/database credentials, pivoted into MySQL/Nacos, and carried out destructive database actions. That is not “AI autonomy” as the primary risk; it is exposed orchestration plus secrets plus downstream authority. Controls this week: remove exposed Langflow, patch where applicable, rotate reachable credentials, segment databases from AI workflow hosts, and hunt for credential access and Nacos/MySQL abuse.

For the application-layer AI exposures, I would also change controls now. The source pack flags ClaudeBleed as an unpatched Claude for Chrome issue allowing extension-level access to Gmail/Calendar, Claude Tag as Slack integration abuse that can trigger unauthorized enterprise actions, Grok Build as repository and Git history upload exposure, and Microsoft 365 Copilot CVE-2026-48561 as a patched mobile hidden-command vulnerability. The control is not “ban AI”; it is: allowlist AI extensions and integrations, disable unreviewed ones, force mobile/client updates for patched issues, require human approval for enterprise actions, and log the agent action trail.

The Check Point Mexican agency report and Patriot Bait using Gemini CLI are monitor-first unless you see those tools in your own estate. They indicate adversaries using AI to accelerate tactical work — intrusion steps or C2 setup — but the available evidence here supports “AI-assisted operator speed,” not a new exploitable flaw in Gemini or AI agents generally. Monitor for AI CLI use on admin/dev endpoints, unusual automation chains, scripted retries, and rapid tool installation, but do not treat every “attacker used AI” report as a control-plane vulnerability.

Tomas, take the developer trust lane: Miasma/Phantom Gyp compromised 57 npm packages across 286 malicious versions via binding.gyp execution and legitimate CI/CD release pipelines; 148 npm proxy packages loaded mutable GitHub JavaScript; Cursor IDE may execute a malicious git.exe from a poisoned repo. What is the non-obvious common failure, and what should engineering teams do tonight beyond 'remove bad packages'?

Halil, the common failure is that teams are still treating developer tooling inputs as data, when they are actually execution policy. In the Miasma/Phantom Gyp case, the trust boundary failed at binding.gyp and normal CI/CD release flow: malicious behavior can ride through “legitimate” build and release machinery. In the 148 npm proxy packages, the npm package was only the bootstrapper — the real trust anchor shifted to mutable JavaScript pulled from GitHub. For the Cursor/git.exe scenario, I’d treat the repo itself as hostile execution context if the IDE can resolve and run a repo-local binary.

So beyond “remove bad packages,” tonight’s move is: freeze and inspect execution paths. Block or alert on npm packages using native build hooks like binding.gyp unless explicitly approved; rebuild affected apps from clean runners; rotate only secrets reachable from developer machines or CI jobs that installed or built these packages; and diff lockfiles/SBOMs for the exact 57 npm packages, 286 versions, and the 148 proxy packages. Also check for remote-fetch patterns inside packages — if code is loaded from GitHub at install/runtime, your lockfile did not lock the code you executed.

The non-obvious fix is to make the build graph hermetic. Pin dependencies by hash, disallow install-time network access in CI, run SCA on transitive dependencies, block mutable remote code loading, and treat IDE workspace execution like CI execution: no untrusted repo-local tools on PATH, no automatic binary invocation, and no ambient credentials exposed to the workspace. Provenance is useful, but if the trusted pipeline faithfully signs a poisoned build, the signature only proves the poison went through your official path.

Sara, give the OT and critical-infrastructure view. We have FSB Center 16 targeting routers across critical sectors through weak SNMP and Cisco Smart Install flaws; ABB Edgenius root privilege escalation; Siemens/Schneider/Rockwell July advisories; default-password Unitronics exposure; and alleged Reliance/Kudankulam ecosystem data leakage. Which items require operational coordination with engineering today, and which can stay in planned maintenance?

Halil, the items I would pull engineering into today are the ones that can change physical state or remove operator control: the FSB Center 16/Static Tundra router campaign, default-password Unitronics exposure if any controllers are reachable from vendor/Internet paths, and the Rockwell Logix / 1715 Redundant IO issues where the reported impact includes unauthorized CLI access or non-recoverable controller faults. In Purdue terms, compromised routers sit at the Level 3/3.5 boundary and can become the path into engineering workstations, historians, remote access, and eventually Level 1 controllers. That is not “just network gear” in a plant — it is the road into loss of view, loss of control, or unsafe remote manipulation.

For ABB Ability Edgenius CVE-2026-31431, I would also coordinate with engineering today if Edgenius is connected into production data paths or sits in an OT DMZ/edge role. The CISA advisory is for a patched ABB Ability Edgenius privilege-escalation issue; root on an edge node may not directly trip a PLC, but it can corrupt telemetry, pivot toward Level 3 assets, or poison decisions operators rely on. Do not hot-patch blindly during production: first isolate exposure, restrict management access, confirm backups/config exports, and schedule the update with the process owner.

The Siemens/Schneider/Rockwell July advisories split into two buckets. Anything involving Simatic S7-1500, Rockwell Logix families, 1715 Redundant IO, Schneider IGSS, or EcoStruxure Cybersecurity Admin Expert needs engineering review now because the reported impacts include DoS, code execution, authentication bypass, unauthorized CLI access, managed-device compromise, or non-recoverable faults. But “review now” does not mean “reboot controllers tonight.” Validate affected versions, check whether those products are in safety- or production-critical paths, add temporary segmentation/ACLs and monitoring, then patch in the next approved outage unless active exploitation or unsafe exposure is confirmed.

For the alleged Reliance/Kudankulam ecosystem data leakage, I do not have corroborating visible evidence here, so I would not send plant engineers into emergency change mode based only on the allegation. Security, legal, and vendor-management should triage today; engineering joins immediately only if leaked material includes OT network diagrams, remote-access details, controller logic, vendor credentials, safety-system documentation, or maintenance procedures.

Sofia, keep this narrow. From today's pack: exploited SharePoint/SonicWall/Joomla and possible PeopleSoft breach fallout; alleged Accenture cloud secrets; AssuranceAmerica nearly 7 million records; Partnered Health patient data; 23andMe multistate settlement; OFAC sanctions on First VPN; Pentagon CMMC Phase II pause. Which items create notification, sanctions-screening, or board-disclosure decisions now, and which are background governance noise?

Halil, narrowly: the decision items now are AssuranceAmerica, Partnered Health, OFAC/First VPN, and any confirmed PeopleSoft/Accenture exposure. For AssuranceAmerica’s nearly 7 million records and Partnered Health patient data, treat this as breach-notification triage now: identify affected jurisdictions, data types, notice recipients, and whether any EU personal data is involved. If GDPR applies, Articles 33/34 are the relevant notification track; EDPB guidance confirms supervisory-authority notice under Article 33 is tied to the 72-hour clock, and processor-to-controller notice is also required. For any SEC registrant in the chain—Accenture if the alleged cloud secrets become a material incident, or any listed victim—document the materiality assessment; SEC states Item 1.05 Form 8-K is generally due four business days after the registrant determines the cyber incident is material.

For OFAC/First VPN, this is a sanctions-screening decision now, not “governance noise”: screen vendors, VPN providers, IP infrastructure, payments, crypto rails, and incident-response counterparties for exposure before paying or continuing service. I could not verify the current OFAC designation details from the evidence visible here, so I would not quote the designation scope or penalties without the official notice. The exploited SharePoint/SonicWall/Joomla items and possible PeopleSoft fallout are notification-readiness triggers, not automatic breach notices: start preservation, privilege, log review, and regulator-notice drafts, but formal notice still depends on evidence of unauthorized access, personal-data exposure, or a qualifying material/service-impact incident.

The background governance noise bucket: 23andMe multistate settlement and Pentagon CMMC Phase II pause. 23andMe matters as enforcement precedent—especially for identity, consumer genetics, MFA, and credential-stuffing controls—but it does not itself create a new notification obligation for others. The CMMC pause is procurement/compliance-planning relevant for defense contractors, but it is not an incident-notification or board-disclosure trigger unless it affects a live contract representation or bid certification.

Elena, separate statecraft from ordinary crime. We have FSB Center 16 router espionage against critical sectors, Matryoshka deepfake/media impersonation targeting German elections, Austria/EU attribution of Foreign Ministry compromise to Turla, and Canada reportedly using cyber against fentanyl brokers. Where does geopolitics materially change defensive priority, and where should we resist turning criminal exploitation into a state narrative?

Halil, I would split this hard. FSB Center 16 / Static Tundra router activity is statecraft, not “just router hygiene.” The evidence we have says U.S. and allied governments warned that Russia’s FSB Center 16 has targeted critical infrastructure for more than a decade, especially poorly configured routers and web management portals, including Cisco devices, to copy configurations and recover credentials across communications, energy, finance, healthcare, government and defense sectors. That changes priority because routers become strategic terrain: defenders should treat exposed SNMP, default community strings, remote management, and configuration theft as possible Russian pre-positioning, not merely opportunistic scanning.

Matryoshka is also geopolitical, but the defensive priority is different. A Kremlin-linked disinformation operation targeting German elections and AfD narratives is a gray-zone operation — coercion below the threshold of war. The target is not only voters; it is Germany’s coalition politics and EU/NATO cohesion. So for elections, parties, broadcasters, and platforms, priority shifts toward impersonation monitoring, provenance checks, rapid takedown channels, and pre-bunking. But I would resist translating every deepfake fraud or social-media scam into state action; the strategic marker here is election timing and pro-Russian narrative alignment.

On Austria/EU Turla attribution and Canada reportedly using cyber against fentanyl brokers, I do not have independent current evidence in the visible source set here, so I would keep those bounded. If Austria/EU have officially attributed a Foreign Ministry compromise to Turla, then yes, that is diplomatic espionage and changes priority for ministries and EU-linked institutions. If Canada is using cyber against fentanyl networks, that is state cyber used as law-enforcement power projection — but it should not make us rebrand ordinary fentanyl-market cybercrime as geopolitics unless there is state tasking, strategic targeting, or official operation evidence.

Viktor, take the money-movement lens: Humanity Protocol's $36M hot-wallet/key-backup compromise tied to a stolen laptop, hijacked SpaceX/Starlink X accounts pushing SCATMAN, browser-wallet extension privacy weaknesses, and OFAC action against First VPN/cryptor services. What should crypto-facing teams do in the first 24 hours: freeze, trace, revoke, or communicate — and what is merely reputational noise?

Halil, for Humanity Protocol, the first 24 hours are not a PR exercise — they are a custody and recovery race. According to the Binance Square report, attackers obtained multisig private keys from an employee laptop, gained control of Hyperlane Bridge ProxyAdmin contracts on Ethereum and BNB Chain, transferred about 141.2 million tokens on Ethereum, minted 200 million tokens on BSC, and the 13-hour attack netted approximately $34 million in ETH and BNB. So the order is: pause affected bridge/admin contracts, rotate every exposed signer, migrate treasury/admin authority to fresh hardware-backed wallets, publish attacker addresses if confirmed, and push exchange/freezing notices before funds hit an off-ramp.

For the SpaceX/Starlink X account hijack pushing SCATMAN, this is communication-first unless we have deposit wallets, token contracts, LP addresses, or victim-flow data. Warn users, preserve evidence, report the compromised posts, and monitor any promoted contract or collection address. Without wallet or volume evidence, it is reputationally loud but financially under-specified.

For browser-wallet extension privacy weaknesses, I would not treat privacy leakage as the same class as a drained hot wallet. The first-day action is user and treasury hygiene: isolate high-value wallets, separate trading from normal browsing, review extension permissions, and move treasury assets to multisig/hardware custody if seed or signing exposure is suspected.

On OFAC action against First VPN/cryptor services, the immediate task is sanctions screening, not fund recovery: check counterparties, infrastructure exposure, payment flows, and any wallet/service touchpoints. Based on what’s on the table here, I do not have specific wallet addresses, transaction amounts, or laundering paths, so I would not claim a traceable on-chain exposure without more evidence.

James, closing loop after Sofia, Elena, and Viktor: Sofia says AssuranceAmerica/Partnered Health and confirmed PeopleSoft/Accenture exposure drive notification and board-disclosure triage; Elena says FSB router activity is statecraft that changes priority for critical infrastructure; Viktor says crypto incidents are custody races, not PR. Give me the final 'tonight board brief' version: the top three operational decisions and the top three things not to waste time on.

Halil, board brief version: Decision one — declare an incident triage track tonight for AssuranceAmerica/Partnered Health and the confirmed PeopleSoft/Accenture exposure, because Sofia’s point means this is now notification and board-disclosure sequencing, not just IT cleanup. Decision two — take emergency action on exposed trust brokers and edge systems: SonicWall SMA1000 hotfixing, SharePoint/Joomla exposure reduction, PeopleSoft /PSEMHUB/hub review, and router hardening for critical infrastructure environments first. Decision three — for crypto exposure, move assets and permissions before messaging: freeze risky withdrawals, rotate custody credentials, revoke stale API keys, and confirm wallet/control-plane integrity before anyone drafts a public reassurance.

The three things not to waste time on: first, don’t try to patch all 569/570 Microsoft issues tonight; stage the broad patch wave and hit exposed/auth/content systems first. Second, don’t treat passwords as the fix — Marcus and Priya are right, this is tokens, service principals, federation state, appliance configs, saved router credentials, and custody controls. Third, don’t flood the SOC with noisy vulnerability scans or every web probe; tonight’s high-signal detections are new admins, webshell behavior, unexpected child processes from web/app services, OAuth/app-consent changes, router config pulls, unusual tunnels, and crypto withdrawal/control changes.

My operational close: if the system is exposed, identity-bearing, custody-bearing, or critical-infrastructure routing, it gets a named owner and action before midnight. Everything else waits for the seven-day queue.