Cyber Decision LedgerDecision area
Breach
17 public Decision Records in the whole ledger carry this label. Back to the full Ledger →
Decision Records
Harden internet-exposed water-facility controllers
Remove programmable controllers from direct internet exposure, restrict operational-technology ports, rotate credentials, require multifactor authentication, preserve evidence, verify configurations and water quality, rehearse manual operation, and notify relevant authorities.
Water facilities should remove programmable controllers from direct internet exposure, restrict operational-technology ports, rotate credentials, require multifactor authentication, preserve evidence, verify controller configurations and water quality, rehearse manual operation, and notify relevant authorities. This precautionary action does not assert a specific incident count or actor attribution.
Contain reported VMware vCenter exploitation
Remove vCenter management access from the internet, isolate systems showing compromise indicators, preserve evidence, apply vendor-supported fixes, rotate administrative credentials that may have been reachable, and hunt across managed ESXi hosts and datastores.
Organizations responding to reported vCenter exploitation should remove management interfaces from internet exposure, isolate systems with compromise indicators, preserve evidence, apply authoritative vendor fixes, rotate potentially reachable administrative credentials, and hunt across managed hosts and datastores. Verify local compromise rather than assuming every system was affected.
Safety-first response to OT remote-access compromise
OT operators should treat remote-access compromise patterns as safety incidents, pairing incident leadership with operations, independently verifying physical conditions, freezing PLC and HMI changes, preserving remote-access logs, revoking sessions, restricting vendor access, and avoiding unsafe recovery steps.
When remote-access compromise may affect operational technology, handle the response as a safety event: coordinate with operations, verify physical conditions independently of screens, freeze unsafe control changes, preserve remote-access evidence, revoke sessions, restrict vendor access, and avoid untested recovery steps. Use incident examples only with appropriate caveats.
Water and wastewater OT safety-first continuity handling
Yes. Treat reported water and wastewater OT activity as a safety and continuity incident: verify local process state first, remove exposed cellular, PLC, HMI, and remote-access paths in an OT-safe sequence, rotate compromised credentials, prepare manual-safe operations, and coordinate with public-sector and public-health partners where needed.
For reported water and wastewater OT activity, use a safety-first continuity posture. Verify process state locally, remove exposed remote paths in an OT-safe sequence, rotate compromised credentials, prepare manual-safe operation, and coordinate with appropriate public authorities if service or water quality could be affected.
N-able N-central control-plane containment
Treat exposed N-able N-central administration as an incident-response control-plane problem: remove direct internet exposure, apply vendor-confirmed fixes or mitigations, rotate administrative and API credentials, revoke active sessions, hunt for remote-control abuse and persistence, and review managed endpoints and customer access logs.
Organizations with exposed N-able N-central administration should treat the issue as a control-plane containment event, not routine patching: remove direct exposure, apply vendor-confirmed fixes or mitigations, reset trust in administrative access, and check for downstream misuse before returning to normal operations.
Identity-first response for public-sector platform breaches
For a public-sector platform breach with possible personal-data and identity exposure, restrict or isolate the platform, preserve web, application, and authentication logs, revoke sessions, force resets for exposed users, rotate service accounts, and review SSO or API tokens before treating patching as closure.
After a public-sector platform breach, prioritize containment, log preservation, session revocation, password resets for exposed users, service-account rotation, and SSO or API token review. Do not treat patching alone as closure unless identity and evidence-preservation steps are complete.
Cisco KEV remediation versus breach notification
A known-exploited catalog listing by itself should trigger remediation governance, not automatic breach notification. Teams should identify affected assets, document patch or mitigation status, approve exceptions, preserve compensating-control rationale, review logs, and involve counsel on notification only if facts show compromise, personal-data access, or material impact.
Treat the listing as a remediation and investigation trigger: inventory affected systems, document patch or mitigation status, review logs, and preserve exception rationale. Any breach-notification decision should be counsel-led and based on evidence of compromise, personal-data access, or material impact, not the listing alone.
Treat exposed edge and mail systems as compromise recovery
Exposed enterprise mail, firewall management, VPN, and security-appliance systems should be handled as potential compromise-recovery cases, not patch-only tickets: preserve logs and configurations, apply vendor isolation or patch guidance, revoke active trust material where applicable, rotate impacted credentials and secrets, and hunt for administrative or mailbox persistence.
When enterprise mail, VPN, firewall management, or security-appliance systems have been exposed, treat remediation as potential compromise recovery: preserve evidence, follow vendor isolation or patch guidance, revoke active trust material where applicable, rotate impacted credentials, and check for administrative or mailbox persistence. Avoid detailed product-specific claims until primary advisories are attached.
Remote-access appliance patch and compromise assessment
Patch exposed PAN-OS GlobalProtect and SonicWall SMA1000 systems, but treat exposed appliances as possible compromise cases until logs are preserved, sessions are invalidated, credentials are rotated, persistence is checked, and compromise checks are clean.
For exposed remote-access edge appliances discussed here, patching should be paired with trust-reset and compromise-assessment steps. Avoid treating patch completion alone as proof that the appliance or connected identities are safe.
Credential-exposure response for executed malicious npm packages
When malicious npm package lifecycle scripts ran where secrets were reachable, treat the event as a credential-exposure incident. Confirm execution, map reachable secrets, rotate only exposed secrets, freeze polluted rebuilds, pin known-good artifacts, and strengthen install-script and provenance controls.
If malicious package code actually executed in a developer or CI environment where secrets were reachable, handle the event as potential credential exposure. Confirm execution, identify which secrets were reachable, rotate only those at risk, stop polluted rebuilds, pin known-good artifacts, and add install-script and provenance safeguards. Lockfile-only presence should be treated as dependency verification rather than automatic broad rotation.
Treat suspected AiTM and SaaS abuse as session and OAuth trust compromise
For suspected Microsoft 365 AiTM, Salesforce, OAuth, or help-desk social-engineering exposure, handle the event as potential attacker-held session, refresh-token, or connected-app trust rather than password-only compromise. Revoke sessions, invalidate refresh tokens, review OAuth and connected apps, inspect risky sign-ins, Salesforce exports and API volume, review new MFA enrollments or reset events, verify high-risk help-desk resets through pre-registered channels, and enforce phishing-resistant authentication for admin and high-risk roles.
When Microsoft 365 AiTM, Salesforce, OAuth, or help-desk social-engineering exposure is suspected, treat it as potential session or trust-state compromise, not a password-only event. Revoke sessions and refresh tokens, review OAuth and connected apps, inspect risky sign-ins and SaaS export/API activity, verify MFA and help-desk reset changes, and require phishing-resistant authentication for admin and high-risk roles.
Revoke durable trust artifacts after M365 or Entra compromise
For affected Microsoft 365 or Entra tenants and users, reset credentials and also revoke sessions and refresh tokens, remove unknown passkeys and MFA methods, audit OAuth and device-code grants, review app consents, constrain device-code authentication, require phishing-resistant authentication for high-risk users, and allowlist browser extensions.
For suspected or confirmed Microsoft 365 and Entra compromises, response should include durable-trust cleanup beyond password resets: revoke sessions and refresh tokens, remove unknown passkeys and MFA methods, review OAuth/device-code grants and app consents, constrain risky flows, and require stronger authentication for high-risk users.
AdaptHealth contractor-session HIPAA assessment and preservation
Start HIPAA breach-notification assessment and preserve contractor session artifacts, IdP/session-token logs, cloud audit logs, document access records, PHI inventories, affected counts, password-reset evidence, vendor/BAA terms, and discovery timestamp.
For the reported AdaptHealth contractor-session incident, start HIPAA/privacy notification assessment and preserve session, identity, cloud, document-access, PHI-scope, vendor, and discovery-timing evidence. Do not state notification is required until PHI scope, roles, counts, and discovery date are documented.
Pause vulnerable smart-contract paths before attribution or reimbursement claims
Pause vulnerable contract, module, or execution paths; revoke or narrow privileged paths; snapshot affected balances and transaction state; publish wallet IOCs; notify issuer-side compliance, exchanges, bridges, and monitoring partners; make reimbursement decisions after affected-wallet and recoverable-balance scope is bounded.
For smart-contract theft responses like those discussed, contain the suspected vulnerable contract, module, or execution path, narrow privileged access, preserve transaction and balance state, distribute wallet IOCs to relevant partners, and defer attribution or reimbursement claims until affected-wallet and recoverable-balance scope is verified.
Handle identity and messaging incidents as trust-state compromise
Treat current identity and messaging incidents as active trust-state compromise: revoke Microsoft 365 and IdP sessions and refresh tokens, invalidate suspicious OAuth grants, remove unknown MFA methods and linked messaging devices, rotate exposed Salesforce/API/OAuth connected-app secrets, and force re-authentication for high-risk users after revocation.
For identity or messaging incidents involving tokens, OAuth grants, MFA methods, linked devices, or connected apps, handle containment as trust-state compromise rather than only a password reset. Revoke active trust artifacts, remove suspicious access paths, rotate exposed secrets, and require re-authentication after revocation.
Treat reported ShapedPlugin Pro update-channel compromise as affected-site incident
Sites that installed or updated the reported affected ShapedPlugin paid Pro plugins during the reported April-to-June 2026 window should assume possible full compromise until integrity is proven; rotate WordPress admin, 2FA, SMTP/API/payment credentials and wp-config.php salts; inspect for hidden plugins, REST backdoors, unexpected file writes, and webshells; rebuild if integrity cannot be proven.
For sites that installed or updated the reported affected ShapedPlugin paid Pro plugins during the reported April-to-June 2026 window, treat the site as potentially compromised until integrity is proven. Rotate WordPress admin, 2FA, SMTP/API/payment credentials and wp-config.php salts; inspect for hidden plugins, REST backdoors, unexpected file writes, and webshells; rebuild if integrity cannot be proven. Keep exact window, patch, and CVE details caveated until primary advisory or vendor refs are attached.
Review Xsolis PHI/PII breach-notification and vendor-assurance posture
Prepare breach-notification and vendor-assurance workflows for the reported Xsolis PHI/PII exposure; do not condition readiness on ransomware or confirmed misuse, but require primary legal authority and confirmed scope before publishing precise HIPAA obligations, customer details, exfiltration facts, or containment claims.
Review before publication: packet summaries support treating the reported Xsolis PHI/PII exposure as requiring breach-notification readiness and vendor-assurance requests, but exact HIPAA timeline language, customer scope, exfiltration, and containment facts need primary HHS/OCR, buyer-facing, or forensic records before being stated as settled facts.