Notifications
Clear all
Topic starter
09/07/2026 3:19 pm
TL;DR: The M&S ransomware incident reportedly began with a reset of a privileged employee credential at an external service provider, then moved into Active Directory compromise and months of disruption, with costs reaching hundreds of millions of dollars, according to IS Decisions. The case shows how authentication, reset processes, MFA, and account monitoring remain the decisive controls, not just the ransomware response itself.
NHIMG editorial — based on content published by IS Decisions: the M&S ransomware attack and lessons for defending Active Directory
Questions worth separating out
Q: What breaks when privileged account resets can be socially engineered?
A: When privileged resets are weakly verified, the reset process becomes an attack path rather than a recovery control.
Q: Why do third-party support identities increase ransomware risk?
A: Third-party support identities often have broad reach, but limited visibility and weaker governance than internal privileged accounts.
Q: How can security teams tell whether AD is too exposed?
A: Look for excessive group membership, privileged accounts that are rarely reviewed, and reset or support paths that can reach domain assets without separate approval.
Practitioner guidance
- Harden privileged reset workflows Require strong step-up verification, dual approval where risk is high, and audited context checks before any privileged account reset is accepted.
- Constrain third-party administrative paths Map every external support and service-provider identity that can influence AD or privileged systems, then remove standing access that is not time-bound and explicitly approved.
- Add session-aware monitoring for AD Alert on unusual IP addresses, out-of-hours activity, unexpected machine context, and administrative prompt abuse so identity misuse can be blocked before lateral movement completes.
What's in the full article
IS Decisions' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on strengthening on-prem Active Directory defence with MFA and contextual access controls.
- Practical examples of real-time session monitoring, alert tuning, and account blocking for suspicious activity.
- Implementation detail for reducing lateral movement through user account control and SSO integration.
- Operational considerations for keeping identity workflows on-premises in hybrid AD environments.
👉 Read IS Decisions' analysis of the M&S ransomware attack and AD defence →
M&S ransomware and privileged identity gaps: what teams missed?
Explore further
09/07/2026 3:37 pm
Privileged credential resets are a governance failure, not an operational footnote. The M&S case shows that when reset processes can be socially engineered, the organisation has effectively moved a privileged trust decision outside its control boundary. That is an IAM and PAM problem before it becomes a ransomware problem. Practitioners should treat privileged resets as high-risk identity events that require explicit governance.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the same study.
A question worth separating out:
Q: Who is accountable when a service provider reset leads to ransomware impact?
A: Accountability sits with the organisation that allowed the privileged path to exist, the supplier that operated it, and the governance process that failed to constrain it. In practice, this is where IAM, PAM, and third-party risk management must intersect. If any one of those functions owns the problem alone, the control model is incomplete.
👉 Read our full editorial: M&S ransomware shows why privileged identity controls still fail
