Threat intel

At around 10am UK time on Tuesday, October 6, ASOS app users received a push notification titled "ASOS HACKED". It was addressed to the retailer's data protection officer and IT team and read: "Dear Asos DPO and IT, we have fully compromised the Snowflake instance. Engage with us, or we will leak it." It was signed "xuanyewengateway" and linked to a Telegram channel. In a statement through the London Stock Exchange, ASOS said it is investigating "unauthorised activity involving third-party platforms that we use to communicate with customers" and had restricted access to those notification platforms.

ASOS says names and contact details may have been accessed, and that it does not believe payment card details or account passwords were affected. The Snowflake theft claim comes only from the attacker and has not been verified. Snowflake told the BBC it has "found no compromise of the Snowflake platform", and no sample of the data has been published. Any company that sends push, email or in-app messages through a marketing platform should ask the same question ASOS now faces: who, or which key, can send one message to every customer?

How push platforms work

A shopping app registers each phone with Apple Push Notification service (APNs) or Google's Firebase Cloud Messaging (FCM) and gets back a device token, an address for that app on that phone. The token goes to the brand's customer engagement platform, the system marketing teams use to build campaigns. That platform also holds the brand's push credentials: an APNs authentication key (a .p8 file) and an FCM service account key. When it sends, Apple and Google check that the credential belongs to the app. They do not judge the content.

So there are three ways to send as the brand. A person logs into the platform dashboard, picks a segment such as "all users" and presses send. A backend system calls the platform's REST API with an API key that carries send permission. Or someone holding the APNs or FCM key talks to Apple and Google directly, skipping the platform entirely. Each path delivers the message under the app's own name and icon, which is why a push alert carries more trust than a random email.

The same platform usually stores the profile attributes used for targeting: names, email addresses, phone numbers, purchase history and device tokens. Dashboard users and API keys with export rights can pull that data out. That fits what ASOS has disclosed so far, contact details at risk and payment data not, though ASOS has not said how the sender got in or which vendor was involved.

What attackers did, and what is still unknown

The sender reached ASOS's customer messaging tooling and used it to deliver an extortion demand to the people least able to act on it: customers. The message was aimed at ASOS staff, but pushing it to customers made the incident public at once and put pressure on the company. ASOS shares fell on the day. Reuters reported a drop of about 10%, while other outlets tracked an intraday fall of as much as 13%.

Several things are unconfirmed. ASOS has not named the third-party platforms or said how many customers received the alert or had data accessed. The signature appears to belong to a new actor, reported by some outlets as the Xuanye Group, with no known history on leak sites. Snowflake's denial covers its own platform. It does not rule out access to an ASOS Snowflake account with stolen credentials, which is how the 2024 campaign worked: Mandiant found that a group it tracks as UNC5537 logged into at least 165 Snowflake customers' accounts with passwords stolen by infostealer malware, on accounts that had no multi-factor authentication (MFA). Whether anything like that happened here is not known.

What to do on your own platform

Limit who can send to everyone

List every human and machine identity that can send. In the dashboard, that is each user with a role allowed to launch campaigns. On the API side, it is each key with send or campaign-trigger permission. Look for agency logins nobody uses, accounts of people who have left, and keys created for a test and never deleted.

Then cut the list down:

• Put dashboard login behind your single sign-on (SSO) provider with MFA enforced, and turn off local passwords where the platform allows it.
• Split drafting from sending, and require a second approver for any campaign whose audience is the full user base, if your platform offers approval workflows.
• Scope each API key to the endpoints its integration calls, and set an IP allowlist so a leaked key fails from anywhere else.
• Keep the APNs .p8 key and FCM service account JSON in a secrets manager, with access logged. Anyone holding them can send directly through Apple and Google, and your platform logs will not show it.

Detect a rogue send

Export the platform's audit or security event log to your SIEM (security information and event management system) and alert on: new dashboard users, new or edited API keys, logins from countries your team does not work from, bulk exports, and any send to the full audience that was not on the campaign calendar. Track daily push volume too. A send to millions of devices at 10am on a Tuesday with no scheduled campaign behind it should page someone within minutes.

Respond in the first hour

1. Stop the live campaign and pause every scheduled one, so a second message does not go out while you investigate.
2. Revoke all platform API keys and end all dashboard sessions, then reissue keys only to integrations you have checked.
3. Rotate the APNs authentication key in the Apple Developer account and the FCM service account key in Google Cloud. This closes the direct path if those were taken.
4. Review the audit log for exports, segment downloads and changes to user attributes, and treat whatever was exported as exposed.
5. If the attacker names another system, as with the Snowflake claim here, check it directly. In Snowflake, query SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY for logins from unknown IP addresses or without MFA, and QUERY_HISTORY for large SELECT or COPY INTO statements in the same window.
6. Tell customers plainly what happened and that they should ignore links in the message, as ASOS did. Expect phishing in your brand's name using any contact details that were taken.

Marketing tools are production systems

Customer engagement platforms tend to belong to the marketing team. They sit outside the identity reviews, key rotation and logging that cover production cloud accounts, yet they can message every customer and hold their contact details. Bring them into the same access review cycle, with the same MFA and logging rules, and include them in incident response exercises.

Our safeguarding and hardening work reviews roles, API keys and SSO settings on third-party platforms like these, and security operations can watch their audit logs alongside the rest of your estate. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: BleepingComputer, SecurityWeek, Help Net Security, The Record, Infosecurity Magazine, Cybernews, CyberInsider, TechNadu, Dark Reading on the 2024 Snowflake campaign, BankInfoSecurity on UNC5537.