The ASOS Hack Arrived on Customers’ Lock Screens. Sent From ASOS’s Own App.

01 What ASOS has confirmed, day by day

The public record is still thin, and some of what circulated in the first hours came from the attackers. Here is what each party has actually said.

Two numbers are missing. ASOS has not said how many of its 16.5 million customers are affected [ Out-Law ] , and it has not said whether data was copied out. Under Article 33 of the UK GDPR a controller reports a notifiable personal data breach to the ICO within 72 hours of becoming aware of it [ UK GDPR Art. 33 ] . The ICO has not commented publicly, so we cannot tell you whether that report has been made.

02 The send button is a privileged system

Security teams rank their systems by what they hold. The database with card data gets the controls, the pentest and the audit. The tool marketing uses to schedule Friday’s push campaign usually gets a shared login and a spreadsheet of who has access.

ASOS shows what that ranking misses. A customer messaging platform holds something worth more to an attacker than most databases: the brand’s voice, delivered to every customer’s phone, with every bit of trust the brand has built. A customer who would delete a strange email will open a notification from an app they chose to install. The attackers here used that channel for extortion and publicity. A quieter crew would have sent a “your order is on hold, confirm your payment” link to a few million people and been paid long before anyone noticed.

In our engagements, these platforms rarely appear on the scope sheet. Clients list their web app, their cloud tenancy and their office network. The push provider, the SMS gateway and the email platform sit outside, owned by marketing or CRM, configured by an agency, and reached through a browser login that nobody in security has looked at. When we do get them in scope, we usually find at least one of the following within a day: an account without MFA, a former agency user who still has access, an API key with send rights committed to a repository, or a single role that can write and publish to the whole audience with no second pair of eyes.

03 The way in was a conversation

“Impersonating a trusted contact” tells you the attacker did not need a software flaw. Someone convinced an ASOS employee that they were a person the employee already worked with, and the employee handed over access. ASOS has not said who was impersonated or over which channel. In our own social engineering work the pretext that lands most often is the same few people: a colleague, an IT helpdesk agent or a supplier contact who seems to need something urgently.

MFA helps less than people hope against this. A one-time code can be read out over the phone. A push approval can be tapped because the caller said it was coming. Phishing-resistant methods such as passkeys and hardware keys hold up better, because the employee has nothing to read out or approve for a stranger. They only protect the systems that actually enforce them, and SaaS tools bought by a single department often sit outside the company’s single sign-on altogether.

Pinsent Masons’ Laura Gillespie called the incident “at a very early stage of investigation” [ Out-Law ] . Fair. You do not need the final report to test whether the same conversation would work on your own staff.

04 Five checks for your own messaging stack

1. List every tool that can send to customers. Push, SMS, email marketing, in-app messaging, CRM journeys, and the agency accounts attached to them. Marketing will know about tools security has never heard of.
2. Put them behind single sign-on with phishing-resistant MFA. Where a tool cannot do that, record who owns the exception and when it gets reviewed.
3. Separate writing from sending. A message to the whole audience should need a second person to approve it. Most platforms support this, and few companies switch it on.
4. Find the API keys. Search repositories, CI variables and shared drives for send-capable keys. Rotate any you find, and scope new ones to the smallest audience that works.
5. Test the trusted-contact call. A social engineering exercise against the people who administer these tools tells you whether your helpdesk and marketing team would hand access to a convincing stranger. That has to be in the scope explicitly, because no scanner will tell you.

ASOS will publish more as the investigation runs, and some of this may change. The question for your own business will stay the same. If an attacker got hold of the one account that can reach every customer’s phone, would anyone on your team know before your customers did?