The most alarming thing about the ASOS incident is how little the attacker had to do. Reaching customers' phones took the ability to send a message, not to break into the retailer. On 6 October, customers of the UK fashion retailer received a push notification titled “Asos hacked” that, in the reported wording, said the retailer's Snowflake instance had been fully compromised and demanded it engage or face a leak. ASOS says it is investigating unauthorised activity involving third-party platforms it uses to communicate with customers.
Much is still unknown. What is clear is that a messaging channel customers trust was used by someone else, and that the keys behind that channel deserve the same care as a password.
What ASOS has said
ASOS says an unauthorised customer notification was sent and that it is investigating unauthorised activity on third-party communication platforms. It says names and contact details may have been accessed, and that it does not believe payment card details or account passwords were affected. The company has around 17 million active customers worldwide. Its share price fell sharply after the notification, by roughly 10% to 15% depending on the time of day in the reporting we reviewed.
What is only a claim
- The Snowflake statement. The notification text asserts that ASOS's Snowflake instance was fully compromised. That is the sender's claim. Reporting we read says Snowflake found no compromise of its platform, and ASOS has not confirmed a Snowflake breach.
- The attacker's identity. No source names who sent the message, and the demand for contact is not evidence of who is behind it.
- That data was stolen. ASOS says data “may have been” accessed, and nobody has published a sample or confirmed an extraction.
It would be a mistake to treat the attacker's wording as a finding. An alarming message is a cheap thing to send; the confirmed event is that a notification went out that ASOS did not authorise.
What is not yet known
Which platform was involved, how the attacker got the ability to send, and whether any data was read are all unpublished. The possibilities range from a stolen API key or access token to a compromised account at a supplier. Until ASOS or its vendor says more, any of those is a guess.
Why the sending key is a credential
A push or email platform typically authenticates your systems with an API key, token or service account. Whoever holds it can usually send to every device or address registered with you, and often can read the audience list as well. That makes it a credential with reach that is easy to underestimate: it speaks with your brand's voice to every customer.
These keys tend to live in places that get less attention than passwords: build pipelines, mobile app configuration, backend environment variables, marketing tools and the laptops of whoever set the integration up. Several teams, including contractors and agencies, may hold copies. This is the same vendor-chain exposure we described after the Daiwa Securities incident, with the difference that here the data moved in the other direction: the attacker used the channel to talk to customers, not just to read about them.
What to do if you run a customer messaging channel
- Inventory every platform that can message your customers: push, email, SMS, in-app, support tools. For each, list who holds an API key or admin login and where the key is stored.
- Narrow what each key can do. Use a separate key per integration, give it send-only or read-only scope where the platform allows, and restrict it by source address if possible.
- Require strong sign-in for human access. Admin accounts on those platforms should use multi-factor authentication or single sign-on, and shared logins should be replaced by named ones.
- Put a brake on bulk sends. Require a second approver or a rate limit for messages to the whole audience, and alert on any send outside your normal schedule.
- Rotate on suspicion, not on proof. If a vendor reports unauthorised activity, rotate the keys and tokens you gave it, then review the send logs and audience exports for use you cannot explain.
- Have the holding statement ready. A short message that tells customers what happened, what they should not do and how to reach you through a known channel is worth more at 10am than a perfect one at noon. Remind them you will never ask for a password or card number in a message.
- Plan how new keys reach the people who install them. During an incident the replacement key goes to an engineer or an agency, and that handover is where it tends to leak into chat or tickets.
If you are an ASOS customer
Do not respond to the notification and do not follow any link in it. Treat messages about the incident, including ones that look like official follow-ups, with suspicion, and go to the ASOS app or website yourself. Because ASOS says names and contact details may have been accessed, expect phishing aimed at those details. Change the password on any account that reuses your ASOS password, even though ASOS says passwords were not affected.
Where Secretus fits, and where it does not
Secretus helps with step 7. The sender encrypts a short text secret in the browser, such as a replacement API key, and shares a link that stops working after the expiry they set or the first successful open, so the value is not left in a chat log or ticket. Team Split can require several holders to reconstruct a high-value text secret.
It is not a messaging-platform security tool. It cannot restrict what a push key can do, stop a bulk send, tell you whether your supplier has been breached or verify the attacker's claims. Those controls belong in the platforms and your incident process; a one-time link covers the moment a person hands the next key to another.