A ransom note sent through ASOS’s own app, and what it does and doesn’t prove

from the extortion channel’s first post to the push notification

≈90 min

posts in the group’s main channel on 6 October — none with a data sample

4

active ASOS customers, by the company’s own count

16.5m

from Betterment’s rogue message to its data on a leak site, in January

14 days

At about 10:00 on 6 October 2026, people with the ASOS app on their phones received a notification headed “ASOS HACKED”. It was not addressed to them. It was addressed to the company’s data protection officer and IT team: “we have fully compromised the Snowflake instance. Engage with us, or we will leak it.” Malwarebytes and others reported it within hours, and that afternoon ASOS told the London Stock Exchange that names and contact details may have been accessed. This analysis adds the attackers’ side from our own collection — every post in their channels, with timestamps — separates what the notification proves from what the attackers claim, and sets it against the last time a company’s own customer channel was turned against it.

What happened on 6 October

The notification went out at about 10:00 British Summer Time, by ASOS’s own account; BleepingComputer, whose readers sent it in, put it at about 5:00 a.m. Eastern. Customers’ reports suggest it reached many, if not all, app users. It carried a link to a Telegram channel. By late afternoon the app was showing its own notice telling customers to disregard the alert and not to follow the link.

ASOS’s stock-exchange announcement at 15:15 confirmed “an unauthorised customer notification”, said the company was investigating “unauthorised activity involving third-party platforms that we use to communicate with customers”, and said it had restricted access to “the notification platforms”. It added that basic personal information “including name and contact details may have been accessed”, that it did not believe payment-card information or passwords were affected, and that its website and app were operating normally. The NCSC published guidance the same day telling every ASOS customer to assume they were affected, whether or not they had received the notification.

What the attackers’ channel shows

Our collection holds the group’s output from 6 October: four posts in its main channel and one in the “gateway” channel that points to it. Their timestamps put the channel ahead of the notification, not behind it.

Source: FireIntel DDW Advance · captured 7 Oct 2026Open full image ↗

Three things stand out. First, it was planned. The gateway was posting by 08:30 and the main channel had welcomed readers by 09:23, about 90 and 37 minutes before the notification. The welcome post warns of impersonators and promises that a replacement link will appear in the gateway if the channel is removed: the group expected a takedown and prepared for one before it acted.

Source: FireIntel DDW Advance · captured 7 Oct 2026Open full image ↗

Second, it spoke early. Within the hour the channel was telling readers that payment information was not affected; ASOS said the same about payment cards in its announcement at 15:15. Third, it offered nothing that can be checked. None of the posts carries a sample, a file listing or a count. The final statement sets a deadline without a date — “a designated period” — and casts the whole episode as a disclosure for which readers should be grateful. BleepingComputer, trying to reach the group, found that the only contact point required payment.

The name is the only other clue, and a weak one. Xuanye (玄燁) was the personal name of the Kangxi Emperor, who ruled China from 1661 to 1722, as Computer Weekly noted; a name costs nothing to adopt. Computer Weekly described the group as previously unobserved, and the earliest post we found from either channel is the gateway post at 08:30 on 6 October. We make no attribution.

What the notification proves, and what it doesn’t

The notification and the claim point at different systems. In a June 2025 interview published by Simon AI, ASOS’s CRM lead described how the company’s marketing messages are built: behavioural, transactional and demographic data in one customer profile in Simon, which runs on Snowflake; audiences defined in SQL; and those audiences passed “straight into Braze, where we have pre-configured campaigns ready to activate.”

To put a message on every customer’s lock screen, an attacker needs the ability to launch a campaign in the messaging layer: an account or an API key with send rights. That is what ASOS’s own words describe — unauthorised activity involving “third-party platforms that we use to communicate with customers”, and restricted access to “the notification platforms”. It does not require the data warehouse. Conversely, holding Snowflake data would not let anyone send a push. The notification proves the first kind of access; the group asserts the second.

Snowflake’s response should be read the same way. It told Sky News it had “found no compromise of the Snowflake platform”. In 2024 that was also true, and Mandiant still found about 165 organisations whose Snowflake instances had been entered with stolen credentials — at least 79.7% of the accounts used had prior credential exposure, mostly through infostealer malware; none of the instances required MFA, and some credentials had not been changed for four years. Snowflake has since begun retiring single-factor password sign-ins. Its statement rules out a flaw in the platform; it neither confirms nor rules out stolen credentials used against ASOS’s own account.

It has happened before, and this is what followed

The first well-known case was a prank. In July 2021 the official Formula 1 app sent users “foo”, then “Hmmmm, I should check my security.. :)”. F1 said the targeted attack “was limited to the Push Notifications Service” and that it had “no reason to believe that any customer data has been accessed”.

The closest precedent is nine months old, and the company concerned has published the full sequence. On 9 January 2026 a caller spoofing “Betterment IT” obtained an employee’s credentials and a one-time code (T1566.004), registered a new device with the company’s Okta single sign-on (T1098.005) and opened the web applications Betterment uses for marketing and operations. At 17:46 Eastern a fake crypto offer went to about 460,000 customers by email and push. The account in the marketing application was suspended 19 minutes later. Betterment’s report lists what followed.

An extortion demand came on 12 January, a denial-of-service attack on the 13th, threats to employees from the 14th to the 16th, and on the 23rd the data — names, or names and email addresses, for most of the 1.4 million customers and business contacts affected — appeared on a .onion leak site. Our collection picks it up three days later, reposted on the Spear forum under the title “Betterment Database | ShinyHunters” and described as 20,000,000 lines. Leak titles inflate, and a group name in a thread title is a claim, not evidence. Nothing links the January attackers to Xuanye.

The ASOS message differs in one respect that matters. Betterment’s attacker used the channel to defraud customers; the ASOS message used it to embarrass the company in front of them — extortion in public rather than in private, with the audience as the lever. For any brand the lesson is the same. The systems that can message every customer at once can do as much damage as a payment system, and deserve the same identity controls.

ASOS accounts were already for sale

Separately from this incident — we found nothing that connects the two — ASOS customer accounts have been a commodity on criminal forums all year. A search of the forums in our collection on 7 October returns posts from January to September 2026 offering ASOS accounts or ASOS-specific credential lists.

Source: FireIntel DDW Advance · captured 7 Oct 2026Open full image ↗

The offers take three forms. Ready-made accounts: on Exploit in April, a seller priced ASOS accounts in any country at $5 from what the post calls a private base of logs — infostealer logs, harvested from infected computers. Credential lists: an automated account on XForums posted ASOS login lists in February and June, the second of 130 lines of login URL, email and password, and a list billed as a 22K ASOS “mix” appeared on Dark Net Army in March. And ASOS as one name among many in multi-million-line shopping combolists and aged-account shops.

On 28 July ASOS detected credential stuffing against US customer accounts. Its notification letters, dated 21 August, said attackers had used login credentials “sourced from outside ASOS” and may have seen names, addresses, phone numbers, dates of birth and partial card details (CyberInsider). Lists like those above are the raw material for that kind of attack. They also mean that any contact data taken now lands in a market that already holds passwords for some of the same people — the conditions for convincing phishing about “the ASOS hack”.

Mapped to MITRE ATT&CK

IDs follow MITRE ATT&CK version 19.2 and were checked against MITRE’s published data. “Claimed” records what the attackers say, not what is known; “Assessed” is our inference from ASOS’s statement.

What to do

If you run a customer-messaging stack

• Put every marketing and messaging platform behind single sign-on with phishing-resistant MFA, and remove local logins. After January, Betterment retired every MFA method that was not hardware-based.
• Treat a new MFA factor or device registration as a high-risk event. At Betterment it was the step between a phone call and the marketing platforms; alert when one is followed by access to messaging tools.
• Scope API keys narrowly and pin them to known addresses. Braze, for example, lets a REST API key carry only the permissions it needs and only accept requests from listed IP addresses. Neither can be changed after the key is created, so audit keys made for agencies and pilots that have outlived their purpose.
• Separate the right to send from the right to export. An account that launches campaigns rarely needs to export audiences, and the reverse.
• Watch the platform’s own audit trail — sign-ins, new users, new API keys, campaigns launched outside a schedule — in your SIEM, not only in the vendor’s console. Braze can export its security events to cloud storage daily.
• Know your kill switch: who can revoke platform access and pause every campaign, and how quickly. Betterment suspended the attacker’s marketing-application account 19 minutes after the rogue send; rehearse doing it faster.

If your customer data is in Snowflake

Whether or not ASOS’s Snowflake account was touched, the claim is a reminder of the 2024 pattern. The queries below hunt for it in Snowflake’s own account-usage views: password-only sign-ins and sign-ins from new addresses; sessions that stage and unload data the way Mandiant described; and client applications appearing for the first time — the 2024 attackers used DBeaver Ultimate, which identifies itself in the session’s client environment. Each query was parsed with a Snowflake-dialect SQL parser and every column checked against Snowflake’s documentation for its view. None has been run against live data for this post; treat the results as leads to review, not alerts.

WITH logins AS (
  SELECT event_timestamp, user_name, client_ip, reported_client_type,
         first_authentication_factor, second_authentication_factor
  FROM snowflake.account_usage.login_history
  WHERE event_timestamp > DATEADD(day, -120, CURRENT_TIMESTAMP())
    AND UPPER(is_success) = 'YES'
),
first_seen AS (
  SELECT user_name, client_ip, MIN(event_timestamp) AS first_login
  FROM logins
  GROUP BY user_name, client_ip
)
SELECT l.event_timestamp, l.user_name, l.client_ip, l.reported_client_type,
       l.first_authentication_factor, l.second_authentication_factor,
       l.event_timestamp = f.first_login AS new_address_for_user
FROM logins AS l
JOIN first_seen AS f
  ON f.user_name = l.user_name AND f.client_ip = l.client_ip
WHERE l.event_timestamp > DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND ((l.first_authentication_factor = 'PASSWORD' AND l.second_authentication_factor IS NULL)
       OR l.event_timestamp = f.first_login)
ORDER BY l.event_timestamp DESC;

SELECT session_id, user_name, role_name,
       MIN(start_time) AS first_statement, MAX(start_time) AS last_statement,
       COUNT_IF(query_text ILIKE '%temporary stage%' OR query_text ILIKE '%temp stage%') AS temporary_stages,
       SUM(rows_unloaded) AS rows_unloaded,
       COUNT_IF(query_text ILIKE 'get %') AS downloads
FROM snowflake.account_usage.query_history
WHERE start_time > DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND UPPER(execution_status) = 'SUCCESS'
GROUP BY session_id, user_name, role_name
HAVING COUNT_IF(query_text ILIKE '%temporary stage%' OR query_text ILIKE '%temp stage%') > 0
   AND SUM(rows_unloaded) > 0
ORDER BY rows_unloaded DESC;

WITH s AS (
  SELECT created_on, user_name, client_application_id,
         PARSE_JSON(client_environment):APPLICATION::STRING AS application
  FROM snowflake.account_usage.sessions
  WHERE created_on > DATEADD(day, -120, CURRENT_TIMESTAMP())
)
SELECT COALESCE(application, client_application_id) AS client,
       MIN(created_on) AS first_seen,
       COUNT(DISTINCT user_name) AS users,
       ARRAY_AGG(DISTINCT user_name) AS user_names
FROM s
GROUP BY COALESCE(application, client_application_id)
HAVING MIN(created_on) > DATEADD(day, -30, CURRENT_TIMESTAMP())
ORDER BY first_seen DESC;

• Require MFA for every human user, and key-pair or OAuth authentication for service users; Snowflake is retiring single-factor passwords for people, and users of type SERVICE cannot sign in with a password at all.
• Use network policies so that each account can be reached only from the addresses you expect. None of the instances in the 2024 campaign had them.
• Rotate credentials that have not changed in years. Mandiant found some in the 2024 campaign unchanged for four.

If you are an ASOS customer

• The UK’s National Cyber Security Centre advises every ASOS customer to assume they are affected, whether or not they received the notification.
• Do not open the Telegram link in the notification. ASOS’s in-app notice says the same.
• Expect phishing that uses this incident: messages about refunds, compensation or “securing your account”. Go to the app or the website directly rather than following a link.
• If you use your ASOS password anywhere else, change it there too. ASOS credential lists were circulating before this incident.

Method, confidence and limits

This analysis was written on 7 October 2026, the day after the incident began, and will date quickly. ASOS’s account comes from its stock-exchange announcement; Snowflake’s from its statement to Sky News, as reported by InternetRetailing; ASOS’s marketing stack from its 2025 interview with Simon AI; Betterment’s sequence from its own post-incident report; and the 2024 Snowflake campaign from Mandiant. The Telegram posts, the Betterment forum repost and the ASOS account market come from FireIntel’s DDW Advance collection, queried on 7 October 2026.

Confidence follows common intelligence practice. High confidence means the judgment rests on direct observation or on several independent sources that agree. Moderate means the evidence is credible but incomplete, or comes from one source or from a party with a motive to exaggerate. “No assessment” means we lack an independent basis to judge.

Screenshots were captured from the FireIntel console on 7 October 2026. The group’s channel link and record source links, and the sellers’ contact details, are covered with bars, because they lead to the extortionists and the sellers; beyond choosing and ordering which posts to show, nothing in them was altered. There are no technical indicators to publish: the only attacker infrastructure we observed is the two channels.