AWS AiTM Turns Password Resets Into Cleanup, Not Containment

Alex, take the active exploitation stack as one technical problem: Cisco Catalyst SD-WAN Manager CVE-2026-20245 with reported root access and anti-forensics, Cisco Unified CM exploitation, PTC Windchill CVE-2026-12569 web shells, FortiBleed credential harvesting, and Oracle PeopleSoft CVE-2026-35273. Which of these creates the fastest path from initial exploit to enterprise-wide control, and what concrete evidence should defenders hunt for today? I want exploit feasibility, likely post-exploit moves, and a position on what cannot wait.

Halil, fastest path to enterprise-wide control is Cisco Catalyst SD-WAN Manager CVE-2026-20245. Not because the score is scary — because SD-WAN Manager is a control-plane box. If the exploit gives root, that is not “one server popped”; that is closer to stealing the traffic cop’s radio. The handoff evidence marks it as active in the wild and high-priority, and the prompt adds reported root access and anti-forensics. That combination beats the others on blast radius.

Second tier: Cisco Unified CM CVE-2026-20230 and PTC Windchill CVE-2026-12569. Unified CM exploitation is real: unauthenticated SSRF through WebDialer, chained to file-write, rogue Apache Axis service, JSP writer, then command shell; patching alone does not remove webshells. Windchill is also real and ugly: active exploitation, unauthenticated RCE, persistent JSP webshells, remote command execution, and data exfiltration, with CISA KEV remediation pressure. But those usually give strong footholds into telecom/PLM environments; SD-WAN Manager gives a route toward network-wide control faster.

What defenders hunt today: - Cisco SD-WAN Manager: unexpected admin/root sessions, config pushes, new local users/API tokens, deleted or rotated logs, altered audit settings, unusual device-template changes, suspicious outbound tunnels from the manager, and management-plane access from non-admin IPs. - Cisco Unified CM: WebDialer exposure, rogue Apache Axis services, new/modified JSP files, first-stage JSP file-writers, second-stage command shells, Tor-originated requests, and systems patched after possible compromise. - PTC Windchill: JSP webshells, anomalous command execution from the app server, suspicious file writes under web-accessible paths, outbound exfiltration from Windchill/FlexPLM hosts, and known artifacts like GW.class, payload.bin, or dpr_<random>.jsp where applicable.

I can’t make a sourced exploitability claim on FortiBleed or Oracle PeopleSoft CVE-2026-35273 from the evidence in front of me, so I would not rank them above the sourced active-exploitation cases. What cannot wait: isolate and inspect Cisco SD-WAN Manager first, then hunt Unified CM and Windchill for persistence. Patching is table stakes. If webshells or anti-forensics are already present, you are in incident-response territory, not vulnerability management.

Marcus, focus on AWS AiTM phishing stealing console credentials and MFA codes, plus FortiBleed credential harvesting. Assume MFA has not failed cryptographically; it has been bypassed operationally through live session theft or captured authentication traffic. What must cloud/IAM owners do today beyond password resets, and where do session revocation, device trust, conditional access, access keys, and break-glass accounts fit?

Halil, my first instinct here is: stop treating this as “MFA failure.” It isn’t. The AWS AiTM reporting says the kit captures AWS console credentials and MFA codes in real time, relays authentication to the real AWS portal, and may obtain a valid session/cookie. So the control that failed is the session establishment path, not the cryptography of the MFA factor.

For cloud/IAM owners today:

• Revoke sessions first, then reset passwords. Password reset alone is incomplete if the attacker already has an active AWS console session or reusable cookie. Force sign-out wherever the IdP supports it, revoke refresh/session tokens, and invalidate federated sessions tied to the affected identities.
• Rotate access keys and inspect newly created credentials. If the attacker reached the AWS console, assume they may have created IAM users, access keys, roles, or persistence paths. Look for rogue accounts, new access keys, policy changes, and role trust-policy changes.
• Move the AWS console behind phishing-resistant authentication. Push/SMS/TOTP MFA can be operationally relayed by AiTM. For workforce access to AWS, use FIDO2/WebAuthn/passkeys through the IdP, and require device-bound trust where available.
• Tighten conditional access at the IdP layer. Require managed device posture, known network/context, impossible-travel checks, and step-up for privileged AWS roles. For AWS specifically, don’t let a successfully phished password+OTP become enough to mint a high-privilege console session.
• Review break-glass accounts now. They should exist, but they should not be normal daily-use identities. Keep them extremely limited, monitored, hardware-token protected where possible, excluded only from brittle policies—not from logging or alerting—and test their use before an incident.
• For FortiBleed, treat exposed FortiGate identity material as potentially burned. Fortinet’s own guidance says this activity involves credential harvesting, reused credentials/brute force, weak passwords/no MFA, and exposed management interfaces—not a new zero-day. Their recommended actions include terminating sessions, resetting credentials, enabling MFA, upgrading FortiOS, reviewing logs/config changes, and restricting external management access.

The FortiBleed piece is important because VPN/admin-plane compromise becomes a cloud identity problem fast: stolen VPN or firewall admin credentials can expose paths into IdPs, privileged workstations, or AWS administration flows. If FortiGate config was modified or rogue accounts were created, I would not stop at password resets; I’d treat the device as compromised, review configuration integrity, remove unauthorized accounts, terminate sessions, and follow recovery guidance.

Tomas, analyze Miasma’s npm/Go compromise, Shai Hulud’s npm/PyPI-to-AWS/Redshift path, Amazon Q Developer VS Code flaws, and the broader GitHub Actions weakness signal. What is the real blast radius for developer organizations: poisoned dependencies, workflow secrets, cloud pivots, or AI assistant tool execution? Give a prioritized containment checklist, not a recap.

The real blast radius is workflow secrets first, cloud pivots second, poisoned dependencies as the entry path, and AI assistant tool execution as an unquantified but dangerous side lane. For Miasma, the visible evidence points to compromised npm packages and Go ecosystem poisoning, including binding.gyp/node-gyp install-time execution, hidden IDE task hooks, Bun abuse, and theft of developer/CI secrets. For Shai Hulud, the stronger operational concern is the path from npm/PyPI compromise into AWS/Redshift exposure: once CI/CD tokens, GitHub credentials, cloud keys, or package-manager secrets are stolen, the dependency compromise stops being “just package malware” and becomes a cloud control-plane problem.

For developer orgs, I would prioritize containment like this:

1. Freeze and rotate secrets now — GitHub tokens, npm/PyPI publishing tokens, AWS keys, Redshift credentials, CI/CD environment secrets, Artifactory tokens, and any shell-history/file-based secrets exposed on developer machines or runners.
2. Block poisoned dependency execution paths — audit npm/Go/PyPI lockfiles for LeoPlatform/RStreams/Miasma/Shai Hulud indicators, disable lifecycle scripts where possible, rebuild only from pinned hashes, and quarantine fresh installs/rebuilds from the affected window.
3. Treat GitHub Actions as potentially exposed — review workflow runs, OIDC trust policies, self-hosted runners, repo secrets, package publish jobs, and suspicious repo creation/commits used for exfiltration. Shai Hulud evidence specifically mentions lateral-movement helpers across GitHub Actions and package ecosystems.
4. Contain cloud pivots — revoke temporary credentials, inspect AWS CloudTrail, IAM role assumptions, Redshift access, unusual S3/object reads, and CI-originated AWS API calls. If a CI runner had cloud deploy rights, assume the cloud boundary was crossed until logs prove otherwise.
5. Disable or restrict risky developer tooling — I don’t have enough sourced detail here to quantify the Amazon Q Developer VS Code flaws, so I would not rank it above the confirmed package-to-secret-to-cloud path. But as a control: disable untrusted VS Code extensions, restrict assistant tool/terminal execution, and require extension allowlisting on developer workstations.

My blunt read: the package registry compromise is the doorway, but the durable damage is stolen workflow identity. If you only remove the bad npm/Go/PyPI packages and don’t rotate CI/CD and cloud credentials, you have cleaned the floor while leaving the attacker the keys.

James, listen across the active exploitation, identity, and supply-chain lanes and give me the operational runbook for a CISO with only today and the weekend change window. What gets emergency containment before lunch, what gets hunted over 24 hours, and what can safely become next-week hardening? Be explicit about sequencing and tradeoffs.

Halil, I’d sequence this hard: before lunch, contain the perimeter and developer supply-chain blast radius, not broad “patch everything.” For FortiBleed/FortiGate, treat affected edge devices as credential-compromise points: remove exposed management where possible, enforce MFA, review configs for rogue users/changes, upgrade FortiOS in the weekend window, and begin credential rotation for accounts that traversed those devices. The tradeoff: don’t rotate every enterprise secret blindly before you know routing scope, or you’ll burn the weekend; start with VPN/admin/service accounts and anything used through FortiGate SSL-VPN. For Miasma/npm/Go, freeze risky package updates, block affected package use in CI, review developer machines and CI runners for secret theft, and rotate GitHub/workflow/cloud tokens where developers opened suspicious repos or builds ran package install hooks. Evidence points to build/IDE-triggered execution and secret theft, so containment beats waiting for a clean dependency inventory.

Over the next 24 hours, hunt narrowly: FortiGate logs for unauthorized config changes, rogue accounts, unusual VPN logins, and lateral movement after VPN access; CI/CD and GitHub audit logs for new tokens, workflow edits, suspicious package install/build activity, Bun execution where it’s not normally used, and unexpected IDE task hooks. For the identity lane, the handoff flags AWS AiTM activity, but I don’t have enough visible advisory detail here to name specific IOCs or a patch. So the safe move is high-fidelity identity hunting: new AWS access keys, MFA changes, console logins from unusual ASN/country, failed-then-successful MFA flows, and privilege escalation after fresh sessions.

Next week is hardening: formal package allowlisting, CI egress restrictions, short-lived developer/cloud tokens, FortiGate admin exposure review, VPN conditional access cleanup, and tabletop the credential-rotation playbook. Don’t let next-week work block today’s containment. Weekend change window should be: FortiGate upgrade and config review first, developer/CI token rotation second, package-lock and build pipeline controls third.

Sara, focus on the water and wastewater warning: Iranian- and Russian-linked actors abusing internet-facing PLCs, weak credentials, poor IT/OT segmentation, insecure remote access, Unitronics Vision Series PLCs, and real effects including a municipal water tank overflow. What should water utilities do today in a resource-constrained environment, and what evidence distinguishes nuisance access from preparation for physical disruption?

Halil, for a small water utility, the physical consequence is not abstract: if an attacker gets from a public-facing PLC/HMI into pump or valve control, you can get tank overflow, loss of pressure, chemical dosing errors, or forced manual operations. The evidence we have supports the core pattern: CISA says Unitronics PLCs in U.S. water/wastewater were actively exploited through poor password security and internet exposure; the FBI/CISA/partners advisory says IRGC-affiliated “CyberAv3ngers” targeted internet-accessible Unitronics Vision Series PLC/HMIs with default or no passwords; NVD ties this to default administrative password risk in VisiLogic before 9.9.00.

What should utilities do today, with little money: first, remove PLC/HMI management from the public internet — not someday, today. Put remote access behind VPN plus MFA, ideally through a jump host in a small OT DMZ; if MFA/VPN is not available immediately, disable remote access until a supervised window. Second, change all Unitronics default passwords and verify no shared operator/vendor credentials remain. Third, inventory which devices actually control pumps, tanks, lift stations, and chemical feeds, then prioritize those for password changes, firmware/software review, and network isolation. Fourth, enable basic logging where possible: VPN logins, PLC/HMI configuration changes, unusual ladder logic downloads, setpoint changes, alarm suppression, and after-hours sessions. Be careful: any firmware update or segmentation change around live PLC communications must be tested or done in a maintenance window, because breaking control comms can create the same safety event we are trying to prevent.

The line between nuisance access and preparation for physical disruption is intent plus capability. A defaced HMI screen or political message is nuisance-level evidence if there are no process changes, no persistence, and no lateral movement. It becomes preparation for disruption when you see enumeration of PLC tags, repeated logins to engineering interfaces, VisiLogic project upload/download activity, setpoint or alarm threshold changes, new remote-access accounts, scheduled tasks, tunneling tools, or access to historian/SCADA servers that bridge Purdue Level 3 to Level 1/2 control. If the attacker touches pump start/stop logic, tank level thresholds, valve states, chlorine/chemical dosing parameters, or alarm logic, treat it as an operational incident, not just an IT compromise.

My blunt advice: spend the first dollar on removing public exposure and killing default credentials, not on a shiny monitoring platform. Then add low-cost monitoring around the few chokepoints that matter: vendor remote access, engineering workstation access, PLC programming ports, and SCADA-to-field communications. For water utilities, those are the doors between nuisance graffiti and physical consequence.

Elena, give us the geopolitical lens without over-attributing every incident. For water utilities, ASIO’s warning about sabotage preparation, Turla/STOCKSTAY, CL-STA-1062, Gamaredon, and counterfeit USBs against Japan’s Self-Defense Forces: what is the strategic pattern, and where should executives be careful not to jump from technical compromise to state intent?

Halil, the strategic pattern is pre-positioning: access that can be used for espionage today, coercion tomorrow, and sabotage if a crisis escalates. ASIO’s warning is the clearest case: it reported foreign hackers compromising an Australian infrastructure provider, obtaining credentials, mapping the network, and maintaining access for possible sabotage. That is not “just compromise”; it is battlefield preparation in the gray zone — below open conflict, but designed to create leverage.

But executives must not turn every technical intrusion into a declared act of state sabotage. Water utilities hit through weak credentials and internet-facing PLCs may reflect Russian- or Iranian-linked activity, but the intent could range from opportunistic disruption to strategic signaling. Turla/STOCKSTAY sits more naturally in intelligence collection, not necessarily destructive intent. The Japanese Self-Defense Forces counterfeit USB case reads as espionage tradecraft against military networks. For CL-STA-1062 and Gamaredon, I do not have enough current visible evidence here to make a confident geopolitical judgment beyond saying they belong in the state-linked campaign bucket only if attribution and tasking are separately supported.

So my executive takeaway: treat these as strategic warning indicators, not automatic proof of imminent sabotage. The dangerous pattern is not one incident; it is the convergence of access to water systems, defense ecosystems, and critical infrastructure credentials at a moment when states want crisis options without crossing the threshold into war.

Pierre, translate today’s incidents into business impact. Compare the likely board-level exposure of Cisco SD-WAN control-plane compromise, AWS AiTM cloud takeover risk, Miasma/Shai Hulud CI/CD secret theft, water utility PLC exposure, and supplier-driven ransomware in Europe. I need a ranked impact view with concrete consequences, not a broad risk range.

Halil, my ranked board view is:

So if I’m advising a board today: fund AWS identity containment first, Cisco SD-WAN exposure second, CI/CD secret hunting third. The other two may be material, but I cannot responsibly rank them above the first three without current incident-specific evidence.

Sofia, identify the genuinely material regulatory triggers today — not every possible notification. Cover water utilities/critical infrastructure obligations, exposed national-security personnel data in the Dialog incident, healthcare/vendor breaches such as Huntsville/Cerner, and supplier/CI-CD compromises that may expose personal or operational data. What does a legal/compliance lead need to do in the first 24 hours?

Halil, I would narrow this to four genuinely material triggers. First: water utilities/critical infrastructure — the material trigger is not “data breach”; it is operational risk to essential services, especially where internet-facing PLCs, weak credentials, or state-linked activity affect treatment, safety, continuity, or public confidence. Second: Dialog — exposed registrant data and login tokens involving national-security personnel is high-risk personal-data exposure plus credential compromise; the practical trigger is identity, safety, and government-security risk, not merely privacy notice volume. Third: Huntsville/Cerner — patient personal and medical data means the covered-entity/vendor chain must treat this as a healthcare breach workflow immediately. Fourth: supplier/CI-CD compromise — PTC/Windchill-style exploitation, FortiGate credential theft, or supplier extortion becomes legally material when it exposes customer personal data, credentials, regulated operational data, or disrupts essential services.

In the first 24 hours, the legal lead should run one triage table: entity type, jurisdiction, data class, operational impact, regulator/contract notice owner, and evidence gap. For water and other critical infrastructure, notify internal crisis management and preserve evidence for sectoral reporting; for Dialog-type exposure, identify whether government, defence, or national-security contacts are affected and revoke tokens before public messaging; for Huntsville/Cerner, activate the business-associate/vendor notification path and demand field-level PHI scope; for CI/CD suppliers, require customer-impact mapping, credential/token exposure review, SBOM/build-system integrity evidence, and a customer notice decision. Do not wait for perfect forensics if the facts already show patient data, credentials, or essential-service disruption.

One caveat: from the sources visible here, I can verify the incident categories, but not the current statutory text, exact deadlines, or penalty ceilings. So the first-24-hour instruction is: prepare notices now, verify the precise jurisdictional clocks before sending, and document why each notice was sent or withheld. The compliance failure I would worry about most today is under-scoping — treating these as isolated IT events when they are actually regulated service-continuity, sensitive-personnel, healthcare, and supply-chain incidents.