'Engage With Us, or We Will Leak It': The ASOS Breach Arrived Through Its Own App

On October 6, people who had the ASOS app on their phones got a push notification that wasn't meant for them. It was addressed to the retailer's data protection officer and IT department. It said the company's data on Snowflake had been "fully compromised," pointed readers to a Telegram channel, and ended with a line TechCrunch quoted in full: "Engage with us, or we will leak it."

Two days later ASOS confirmed it in a London Stock Exchange filing. According to the statement quoted by BleepingComputer and The Record, "an unauthorised party gained access to an ASOS employee account by impersonating a trusted contact to obtain log in credentials." Those credentials were "then used to access information on certain third-party platforms used by ASOS." The Record reported the share price fell more than 10% after the notification went out.

ASOS's website puts its customer base at 17 million. It hasn't said how many were affected.

I've run enough of these investigations to know that the first week of disclosure is mostly about what the company can't say yet. So rather than retell the press release, I want to go through the questions ASOS hasn't answered, because each one maps to something you can check in your own environment this week, before anyone sends a notification through your app.

What we actually know

Keep the confirmed facts separate from the claims. It matters here more than usual.

Confirmed by ASOS (via BleepingComputer, The Record and TechCrunch):

• One employee account was compromised through impersonation of a "trusted contact."
• That login was used to reach data on third-party platforms ASOS uses to communicate with customers.
• Names, contact details and "certain non-personal account related information" were accessed. Payment card data and account passwords were not.
• The affected platforms have been "locked down," and the investigation with external experts is expected to run "for several weeks."

Reported by BBC News (as cited by TechCrunch): the data includes home addresses, phone numbers, email addresses and customer profile notes such as website search queries.

Claimed by the attackers, unverified: Xuanye Group says it compromised ASOS's Snowflake environment, and told BBC News it got in through Simon AI, a marketing service that runs on top of Snowflake. Snowflake says its own systems weren't breached. Simon AI didn't respond to The Record.

About the group: Bloomberg, citing Group-IB's Anastasia Tikhonova, reported that Xuanye Group first showed up on Telegram in early September. The Record says researchers who track extortion crews hadn't seen it before.

That's a thin record for a company of this size. Here's what's missing and why each gap is worth your attention.

Question 1: Who was the "trusted contact"?

ASOS chose its words carefully. Not "a phishing email." Not "a fake IT helpdesk call." The attacker impersonated someone the employee already trusted.

In practice that usually means one of three things: a colleague (often senior), a supplier the employee works with every day, or internal IT. The second is the one I see most in retail. Marketing and CRM teams live in constant contact with agencies, platform account managers and freelance campaign builders. A message from "your account manager at the CDP vendor" asking you to re-authenticate after a "migration" is completely routine. Nobody escalates it.

We wrote about a version of this at Revolut, where a request from a real government mailbox passed every verification step because the process checked the sender's channel instead of the request itself. The ASOS case is the same failure in a different department. The employee checked who the message seemed to come from. Nothing checked whether that person would ever ask for a login.

What to check: List the external parties your marketing, CRM and customer service staff talk to weekly. For each, ask: is there any legitimate reason this party would ever ask for our credentials or an MFA approval? If the answer is no, say so to staff, in writing, by name. "Our Braze account manager will never ask you to log in through a link" lands far better than generic phishing training.

Question 2: Why did one employee login reach the customer data?

This is the question I'd most like ASOS to answer, and the one regulators will push hardest on. The UK Information Commissioner's Office has said it's assessing the situation.

One login reaching a warehouse full of customer records suggests one or more of the following, all of which I've seen in real retail environments:

• The marketing platform had its own local login outside corporate SSO, so the identity provider's conditional access and phishing-resistant MFA never applied.
• The platform held a long-lived service credential to the data warehouse, so anyone inside the marketing tool inherited read access to everything that connector could see.
• The employee's role was broad by default. Marketing ops people are frequently given admin on the tools they configure, because vendor onboarding is faster that way and nobody goes back to trim it.

TechCrunch flagged that it's unclear whether ASOS's Snowflake instance enforced MFA. That should sound familiar. The 2024 Snowflake customer intrusions, which hit AT&T, Ticketmaster and others, ran almost entirely on single-factor credentials stolen by infostealers. Two years on, the lesson most companies took was "turn on MFA for Snowflake users." The weaker spot is the layer above: the SaaS tools that hold their own credentials into the warehouse and present their own login page to your staff.

What to check: For every tool that reads from your customer data warehouse, find out three things. Does a human log into it through your IdP, or through its own form? Does it connect to the warehouse with a key, a password or OAuth, and when was that rotated? Which of your people hold admin in it? If you can't answer within a day, that's the finding.

Question 3: How did the attacker get the push channel?

Reading customer records is one capability. Sending a message to every phone with your app installed is a different one, and arguably more dangerous.

TechCrunch noted that in-app push is usually run by a third-party service. In most retail stacks, the customer data platform syncs audiences into an engagement tool (Braze, Iterable, Airship, OneSignal and the like), and the engagement tool holds the keys to APNs and Firebase. If the compromised employee had access to the campaign tool, sending a message is a matter of minutes. If the attacker only reached the data layer, then something else gave them the send button, and ASOS hasn't said what.

Either way, think about what the notification proves. Your app's push channel is the most trusted line you have into a customer's pocket. People who'd delete a suspicious email will tap a notification from an app they bought shoes from last week. This time the attacker used it as a megaphone to pressure the company. The next one will use it to send a "verify your account" link to millions of people who have every reason to believe it.

That isn't hypothetical. Earlier this year Betterment had a third-party marketing platform compromised, and the attackers used it to send customers a crypto scam in Betterment's name, as TechCrunch noted in its ASOS coverage. ASOS got the extortion version. Betterment got the fraud version. Same channel.

We covered a related pattern in the BigCommerce Ribon breach, where a borrowed app key gave attackers write access to storefronts for four days. Customer-facing tools with send or write rights belong in the same tier as your production deployment pipeline. Very few companies treat them that way.

What to check: Who can send a push, SMS or email campaign to your full audience without a second person approving it? In most engagement platforms the answer is "anyone with the Marketer role." Turn on approval workflows for sends above a size threshold, and restrict API keys that can trigger sends to known IP ranges.

Question 4: How long were they inside before the notification?

ASOS hasn't published a timeline. The push went out October 6. We don't know when the employee's credentials were taken.

That gap matters more than people think. In the extortion cases I've worked, the loud moment (the ransom note, the leak-site post, the push notification) is the attacker telling you their collection phase is done. The quiet days before it are when the data moved. If your first alert is the attacker's announcement, you're running incident response with the attacker already holding the timeline.

The Veradigm incident showed this from another angle: a vendor credential was used against the same patient data twice in 21 months, and both times the discovery came well after the access. Third-party platforms are where your own logging is thinnest. You get whatever audit trail the vendor exposes, at whatever retention their plan tier includes, and often you only learn its limits mid-incident.

What to check: Pull the audit log export settings for your CDP, warehouse and engagement tools today. Confirm retention is at least 90 days and that the logs land somewhere the vendor's admin can't delete them. Then look at what a bulk export or a large audience query actually generates in those logs. If it's nothing, or one undifferentiated "API call" line, you won't see the collection phase.

Question 5: Is the data real, and how would ASOS know?

Xuanye Group hasn't posted samples publicly, though The Record reports it shared some with BBC News. It has said it will hold the data for an "unspecified period." ASOS's statement describes what was "accessed," not what was copied.

This is where most breached companies find themselves stuck in week one. Investigators know the attacker reached a system. They can't easily prove which rows left it. So the disclosure gets written conservatively, the regulator assumes the worst, and every customer gets the same letter.

There's a cheap way to make this question answerable in advance, and it's the part of the deception playbook I wish more retail and SaaS teams would take up. Seed your customer data with records that belong to nobody: decoy customer profiles with unique email addresses and phone numbers that you control and that no legitimate process should ever contact outside your normal campaign schedule.

They do three jobs.

1. Early warning. If a decoy address receives a message your marketing team didn't send, someone else is mailing your list. That alert arrives before the extortion note.
2. Proof of exfiltration. If a decoy record appears in a leak sample or a dark web listing, you know which dataset left, from which system (if you seed differently per platform), and roughly when.
3. Scoping. Different decoys in the warehouse, the CDP and the engagement tool tell you which layer the attacker actually reached. ASOS currently can't say publicly whether the attacker was in Snowflake, in Simon AI, or only in a downstream tool. Per-platform decoys would answer that in hours.

The same thinking applies to the credential side. A fake service account for the warehouse, sitting in a place an attacker browsing a marketing ops employee's workspace would find it (a shared doc, a notes field, an old integration config), produces exactly zero legitimate logins. Any use of it is the attacker. We explain how those identity decoys and canary records fit together on our solutions page.

The part ASOS got right

To be fair, the response has some things worth copying. ASOS disclosed within two days of the notification, through the stock exchange, with a specific description of the initial access method. That's faster and more candid than most. Its customer guidance was concrete: it "would never ask for passwords, security codes or payment details" through an unsolicited message or call. That's the right warning to give when attackers now hold names, addresses, phone numbers and browsing context for a lot of your customers. Expect follow-on phishing that quotes people's own search history back at them.

My read

The story getting the headlines is the push notification, because it's novel and embarrassing. The part I'd take away is less exciting: a single employee identity in a marketing function reached customer data and, by some route, a channel to millions of phones. That's an identity architecture decision someone made years ago, probably to make onboarding a vendor easier.

Marketing technology has grown into a second production environment, with its own data stores, its own credentials and its own path to the customer, and it's mostly governed like a set of productivity apps. Attackers have noticed. Xuanye Group, a crew nobody had heard of in August, didn't need a zero-day or an infostealer log. It needed one convincing message to one person.

If you want to see what a decoy customer record and a fake warehouse credential look like in your own stack, and how fast they alert when someone touches them, book a Mine2 demo and we'll walk through it on a setup that looks like yours.