A Wake-Up Call for Retail

In May 2025, both M&S and Co-op were hit with ransomware attacks that brought parts of their operations to a standstill. M&S suspended online shopping for weeks, and Co-op had to take systems offline while facing ransom demands over stolen customer and employee data. Millions of pounds in revenue were lost, and consumer trust has taken a serious hit.

The suspected culprits? A group known as Scattered Spider – young hackers coordinating through Discord and Telegram, using DragonForce, a decentralised and fragmented group providing pre-built access to hacking toolkits and infrastructure, to gain access through social engineering and poorly secured internal systems.

What happened?

From a technical perspective, the Scattered Spider attacks on M&S and Co-op exhibited several commonalities, reflecting their well-established playbook:

Initial Access via IT Service Desk Impersonation and MFA Bypass:

• Social engineering was the main technical initial access vector. Instead of exploiting software vulnerabilities, Scattered Spider directly manipulated IT help desk operators (or a third-party supplier for M&S). They convinced service desk personnel to reset passwords for targeted accounts, gaining legitimate login credentials. Scattered Spider is also known for using SIM swapping or repeatedly sending MFA push notifications to overwhelm and trick users into approving login attempts, bypassing multi-factor authentication. This allows them to use the newly acquired credentials.

Leveraging Legitimate Access for Lateral Movement:

• The attackers exploited Active Directory (AD) and exfiltrated the NTDS.dit database file, containing hashed passwords for all domain users. This allowed them to perform offline password cracking, gaining access to numerous accounts, including those with elevated privileges. Scattered Spider uses legitimate tools and living-off-the-land techniques like PowerShell, RDP, and command-line utilities for lateral movement and persistence, making it harder for security solutions to detect their activity.

Deployment of DragonForce Ransomware:

• In both incidents, Scattered Spider operated as an affiliate within the Ransomware-as-a-Service (RaaS) model, utilising the DragonForce ransomware payload and infrastructure provided by DragonForce RaaS operators. The M&S attack specifically targeted VMware ESXi hosts, a common tactic to maximise disruption by encrypting multiple virtual machines simultaneously - a capability DragonForce possesses, though not explicitly confirmed for Co-op. The primary technical effect of this ransomware was the encryption of files and systems, effectively rendering them inaccessible.

Data Exfiltration for Double Extortion (T1041 / T1537):

• Before or during the deployment of ransomware, attackers methodically stole sensitive data from victim networks by identifying valuable assets such as customer databases and internal documents, staging them, and exfiltrating via methods like SFTP, WebDAV, and cloud storage services. This technical process underpins their double extortion strategy, which, while non-technical in nature, relies heavily on the capability to efficiently move and copy large volumes of data.

1. Evading Detection (Defense Evasion — T1562):

• While specific details are often kept confidential for security reasons, Scattered Spider is known for sophisticated evasion techniques, including:
• — Using valid credentials to blend in with legitimate network traffic.
• — Potentially disabling or tampering with security software (Endpoint Detection and Response — EDR) if they gain sufficient privileges (though specific to these attacks, this is a known Scattered Spider TTP).
• — Clearing event logs post-encryption (a feature of DragonForce ransomware) to hinder forensic analysis.

Security Failures Are Platform Failures

From a platform engineering standpoint, these breaches represent more than just lapses in endpoint protection. They reveal a lack of security-in-depth and insufficient adoption of policy-based security controls.

In a cloud-native world, where containers, microservices, and ephemeral workloads dominate, security needs to be enforced automatically and declaratively – not manually.

How can platform engineering help?

While platform engineering and an internal developer platform (IDP) cannot completely eliminate the risk of social engineering (as it fundamentally targets human psychology), they create a much more robust, automated, and secure environment that drastically reduces the technical opportunities for attackers to exploit initial compromises and execute devastating attacks like those seen with M&S and Co-op. They shift the security burden from individual developers and manual processes to automated, code-driven guardrails.

This isn’t theoretical. These kinds of policies could have helped prevent or mitigate the access paths likely exploited in the M&S and Co-op incidents.

Here’s how:

Strengthening Identity and Access Management (IAM) and Reducing Social Engineering Success:

• Standardised & Automated IAM Policies: An IDP, built through platform engineering principles, would enforce standardised IAM policies from the ground up. This means:
• Automated Least Privilege: Developers and operations teams would be provisioned with only the minimum necessary access for their roles, enforced by the platform. This limits the blast radius if an account is compromised. Service desk personnel would have strictly defined permissions, making it harder for attackers to trick them into granting broad access.
• Consistent MFA Enforcement: The platform would bake in robust Multi-Factor Authentication enforcement across all internal applications and services. If MFA is a consistent, non-bypassable part of the platform’s design, it significantly hinders the attackers’ ability to gain access even with stolen credentials.
• Privilege Access Management (PAM) Integration: An IDP can integrate tightly with PAM solutions, ensuring that highly privileged accounts are managed and accessed only through secure, audited, and time-bound mechanisms, reducing the chance of attackers compromising admin credentials.
• Automated De-provisioning: When an employee leaves or changes roles, their access is automatically adjusted or revoked by the platform, preventing “privilege creep” and dormant accounts from being exploited.
• Reduced Cognitive Load: By automating routine provisioning and access management tasks, the service desk would have less need to manually intervene in sensitive operations like password resets, reducing the attack surface for social engineering. Any exceptions would be subject to more rigorous, multi-level verification processes. 

Enhancing Network Segmentation and Security by Design:

• Automated, Secure Network Provisioning: Platform engineering emphasises “golden paths” and “paved roads” for infrastructure provisioning. This means network segments (e.g., for development, testing, production, or sensitive data) would be created with secure-by-default configurations and consistent firewall rules, making lateral movement much harder for attackers.
• Infrastructure as Code (IaC) with Security Checks: All infrastructure (including network configurations, server builds, and virtual machine setups) would be predefined in code. This IaC would be subject to automated security checks (linters, static analysis) before deployment, catching misconfigurations that could create vulnerabilities. Then made available for other teams to reuse without the cognitive burden of having to learn new and complex concepts.
• Immutable Infrastructure: By promoting immutable infrastructure (where new versions are deployed rather than existing ones modified), the platform ensures that changes are consistently secure and prevents attackers from making persistent modifications to systems without being detected.

Accelerating Patching and Vulnerability Management:

• Automated Patch Management: An IDP would centralise and automate patching for underlying infrastructure, operating systems, and common software components that developers use. This drastically reduces the window of vulnerability that attackers like Scattered Spider exploit.
• Standardised Environments: By providing standardised development and production environments, the platform reduces the diversity of systems, simplifying patch management and vulnerability scanning. This also allows for more effective and automated incident response playbooks, as the expected state of systems is well-defined.
• Continuous Security Scans: Platform engineering embeds security into the software delivery process. This means automated vulnerability scanning, software composition analysis (SCA), and static application security testing (SAST) are run on code and dependencies as they are built, catching vulnerabilities before they reach production.

Improving Incident Response and Observability:

• Centralised Logging and Monitoring: An IDP would consolidate logs and metrics from all platform components and applications into a central system. This provides a unified view of the environment, making it easier to detect anomalous activity (like a compromised account moving laterally or accessing unusual resources).
• Automated Alerting: Security alerts could be automatically triggered by the platform based on predefined rules, enabling faster detection and response to potential breaches.

Secure Supply Chain Management:

• Approved Components and Dependencies: An IDP can enforce the use of approved, pre-vetted components and dependencies (e.g., libraries, base images) from a centralised catalog. This reduces the risk of developers introducing vulnerable open-source components into applications.
• Software Bill of Materials (SBOM): The platform could automatically generate SBOMs, providing a clear inventory of all software components, which is crucial for identifying and patching vulnerabilities across the application portfolio.

Final Thoughts

In summary, the attacks revolve around the initial human-centric vector, the subsequent abuse of legitimate IT infrastructure (especially Active Directory), and the deployment of a specific RaaS payload (DragonForce) combined with a critical data exfiltration phase.

While platform engineering and an IDP wouldn’t entirely eliminate the human element of social engineering, they would significantly harden the technical environment and reduce the impact of such attacks by:

• Making it much harder for attackers to escalate privileges or move laterally after initial access.
• Reducing the opportunity for human error in security configurations.
• Enabling rapid detection and response when a breach does occur.
• Ensuring security is “baked in” by default rather than bolted on as an afterthought.

The breaches at M&S and Co-op are not outliers-they’re warnings. Cyber threats are growing faster than many organisations can adapt. The answer isn’t just better security tools. It’s a culture of platform security: policy-driven, automation-first, and built into the very infrastructure your business runs on.

Don’t wait for your organisation to make the headlines.

At Mesoform, we help companies modernise their platforms with security-first engineering practices, including OPA Gatekeeper implementation, policy-as-code adoption, and secure platform design from the ground up.

Don’t wait for your organisation to make the headlines. Get in touch today and find out how policy-based platform engineering can protect your future.