ASOS Cyber Attack: What We Know So Far and What Organisations Can Do Now

ASOS Cyber Attack: What We Know So Far – and What Organisations Can Do Now

ASOS customers have received an unusual push notification today. Apparently sent by the attackers themselves through ASOS's own app.

That matters hugely.

This wasn't a breach first revealed through a dark-web post, a regulatory disclosure or a company statement. A message claiming that ASOS had been compromised appeared directly on customers' phones through a channel they trust.

The message, addressed to ASOS's Data Protection Officer and IT team, claimed that the attackers had "fully compromised" the company's Snowflake instance and threatened to leak information unless ASOS engaged with them.

The notification has been reported by many major news outlets although Reuters noted that it had not independently verified the alleged breach. ASOS said it was aware of the reports but, at the time of reporting, had not confirmed the attackers' claims.

ASOS is investigating and, at the time of writing, there is still a lot we don't know. The group claiming responsibility has reportedly said that payment information is not affected, but claims about the extent of any compromise remain unverified.

We also don't know how the attackers gained access in the first place. While the incident is still unfolding, it's important not to speculate.

But regardless of what the investigation ultimately finds, the apparent use of a trusted customer communication channel raises some important questions for every organisation.

The Trust Problem Organisations Shouldn't Overlook

The push notification is arguably one of the most interesting aspects of this incident.

When organisations think about their "crown jewels", attention naturally goes towards customer databases, payment infrastructure, intellectual property and production systems. But customer communication platforms hold something equally valuable: trust.

Email platforms, SMS gateways, mobile notifications and customer portals allow an organisation to speak directly to its customers. If an attacker gains control of one of those channels, they potentially gain the ability to speak as the organisation.

Imagine the ASOS notification hadn't announced a claimed breach. Imagine instead that customers received an official app notification telling them:

"We've detected suspicious activity on your account. Please sign in again to secure it."

A link follows.

Coming through the genuine application, how many customers would question it?

A compromised communication channel doesn't just announce a breach…it can create one.

That's why customer communication platforms shouldn't simply be considered marketing or communications tooling. They're part of the organisation's wider attack surface and need appropriate access controls, monitoring and governance.

These platforms can also sit outside the security team's direct ownership, creating a potential blind spot if responsibilities and controls aren't clearly understood. Organisations should know who can use them, which identities and integrations enable that access, what controls exist around high-impact actions and whether unusual activity would actually be detected.

What Do We Actually Know?

The attackers specifically reference Snowflake, a cloud data platform used by organisations to store, process and analyse large volumes of information.

What we don't currently know is whether the attackers' claims are accurate, how any initial access was achieved or how the apparent access to ASOS's customer notification channel relates to the claimed Snowflake compromise.

It could involve multiple identities, shared administrative access, integrations between platforms or another route entirely. Equally, some of the attacker's claims may prove inaccurate.

We simply don't know yet.

But it highlights something we regularly encourage organisations to consider: don't look at individual technologies in isolation. Look at the paths between them.

A platform can be well configured in its own right while an identity, API key, service account or integration creates an unexpected route into it. In many environments, integrations are one of the least understood parts of the attack surface.

The important question isn't simply whether each individual system is secure. It's what an attacker could reach if one part of the environment was compromised.

Sometimes Attackers Don't Break In. They Log In.

In 2024, Mandiant investigated a significant campaign attributed to a financially motivated threat actor it tracks as UNC5537. According to Mandiant, it found no evidence that the unauthorised access it investigated resulted from a compromise of Snowflake's own enterprise environment. Instead, every incident Mandiant responded to as part of that campaign was traced back to compromised customer credentials.

In one case, credentials used to access a victim's Snowflake environment had previously been stolen through infostealer malware. The affected account did not have multi-factor authentication enabled, allowing the attacker to use those legitimate credentials to access the customer's Snowflake instance and ultimately exfiltrate data.

To be absolutely clear, there is currently no evidence that this is what has happened to ASOS. Until more information becomes available, we shouldn't assume they share the same root cause.

What the previous instance does demonstrate is a much wider issue. An attacker doesn't necessarily need a sophisticated exploit or an unknown vulnerability if they can obtain a legitimate identity with enough access.

Sometimes attackers don't need to break in.

They can simply log in.

Identity, Attack Paths and the Blast Radius

Cloud infrastructure, SaaS applications, APIs, suppliers and machine-to-machine integrations have fundamentally changed the traditional idea of a network perimeter. Identity is now a critical part of it.

MFA is an obvious control, but good identity security can't stop at switching MFA on and considering the problem solved. Organisations need to understand which identities have privileged access, whether that access is genuinely necessary and what an attacker could do if one of those identities was compromised.

Non-human identities deserve the same scrutiny. Service accounts, API keys and integration tokens can provide significant access but are easily overlooked, with permissions accumulating long after their original purpose has changed.

The same happens between systems. New platforms, suppliers and integrations are added over time and, while each decision may make sense individually, collectively they can create attack paths nobody intended.

This is where Zero Trust becomes useful rather than simply another cyber buzzword: assume compromise and limit what happens next.

One compromised identity shouldn't automatically provide access to everything around it. Administrative identities should be separated, privilege kept to the minimum necessary and service-to-service access properly controlled.

These principles also align with Snowflake's own current security guidance, which recommends MFA, network policies, modern authentication methods, least privilege and Privileged Access Management (PAM). For machine identities, Snowflake recommends moving away from static credentials towards approaches including key-pair authentication, OAuth and workload identity federation.

No organisation can realistically guarantee that it will never be compromised. The objective is to make compromise difficult, detect it quickly and stop one successful attack becoming an organisation-wide incident.

Successful Authentication Doesn't Mean Legitimate Activity

There is another challenge with credential-based attacks: from the platform's perspective, an attacker using legitimate credentials can initially look exactly like the real user.

The username is correct. The password is correct. Authentication succeeds.

Nothing has technically failed.

That's why monitoring needs to continue beyond the login. Organisations need enough visibility to identify activity that might be technically permitted but operationally abnormal.

That could be a sudden spike in data exports, an administrator creating new identities, an unexpected privilege change or a service account accessing information it has never previously touched. The same principle applies to customer communication platforms: a legitimate account being used in an illegitimate way should still generate attention.

The question shouldn't simply be "Did this person successfully authenticate?"

It should also be "Does what they're doing make sense?"

What Should Organisations Do Now?

We don't need to know the eventual root cause of the ASOS incident to take something useful from it. If you're responsible for security or technology within an organisation, there are some sensible checks worth making now:

• Check MFA coverage. Make sure it is genuinely enforced across privileged, cloud and SaaS accounts rather than simply being available.
• Review privileged access. Identify who has administrative access, whether they still need it and whether privileged identities are separated from everyday accounts.
• Review service accounts and API credentials. Understand what they can access, where credentials are stored and when they were last rotated.
• Map critical integrations and attack paths. Understand which systems trust or connect to one another and what an attacker could reach if one were compromised.
• Check your monitoring. Make sure unusual authentication, privilege changes, significant data exports and abnormal administrative behaviour would actually be visible.
• Protect customer communications. Treat email, SMS, push notifications and other trusted communication channels as security-sensitive systems.
• Test your response. Make sure you can revoke credentials, isolate affected services and continue communicating if one of your normal channels becomes untrusted.

None of this requires assuming that your organisation is already compromised. It's about using incidents like this as a prompt to validate the controls you already have and identify any gaps before somebody else does.

This Is Solvable

A story like this can understandably make organisations question their own exposure. That's not a bad question to ask, but the answer isn't to panic and it isn't necessarily to buy more technology.

Most organisations aren't starting from zero. They already have many of the controls they need. The challenge is understanding whether those controls work together effectively and whether there are gaps between them.

In many cases, the right first step is much simpler: understand what you have, how it connects, who can access it and whether the controls you believe are protecting it actually work.

If you can answer those questions confidently, you're already in a much stronger position. Keep testing those assumptions, because environments change.

If some of the answers are closer to "we think so", "probably" or "we're not sure", that doesn't mean you're about to suffer a breach. It simply means you've identified somewhere worth looking.

The issues highlighted by incidents like this:

• identity governance
• privileged access
• SaaS integrations
• monitoring
• segmentation
• incident preparedness

Are all things organisations can understand, test and improve.

You don't need perfect security. You need to understand your risk, make sensible decisions about it and know how you'll respond when something doesn't go according to plan.

Not Sure Where You Stand? Talk to P3M Works

That's a significant part of how we approach cyber resilience at P3M Works. We help organisations understand where their genuine exposure sits, identify attack paths, strengthen identity and privileged access, apply Zero Trust principles and improve their ability to detect, contain and recover from incidents.

Sometimes that work identifies gaps that need addressing. Sometimes it provides assurance that the controls already in place are doing exactly what they're supposed to do. Both are valuable outcomes.

So, if what's happening at ASOS has made you question your own environment, don't panic. But don't ignore the question either.

You may already have the right controls in place. If you're not sure, we can help you establish that.

Whether you want to understand the attack paths across your environment, review identity and privileged access, assess the resilience of your existing controls or simply get an independent view of where you stand, come and speak to the P3M Works team.

Our approach is straightforward: understand the environment, identify the genuine risks and focus effort where it will make a meaningful difference.

Cyber security is about making compromise difficult. Cyber resilience is about making sure you're ready when prevention isn't enough.

Sources

Sky News – live ASOS incident coverage
Reuters – ASOS cybersecurity breach report
Mandiant – UNC5537 Snowflake investigation
Snowflake – Security & Governance guidance

Information regarding the ASOS incident is correct according to publicly available reporting at the time of publication on 6 October 2026. The incident remains under investigation and this article distinguishes reported facts from unverified attacker claims. Updates will be posted when more information becomes available.

Header image: Getty Images