Build1 publisherNot yet confirmed elsewhere2 min readPublished
Attackers posing as a colleague took over ASOS's push-notification console with one employee's login
ASOS shares fell 10% after attackers used one employee's stolen login to push an extortion message through its app, a dev.to account says. That single credential was enough to reach third-party messaging tools, so those consoles need production-grade access controls.
The Engineer · Build desk
What happened
- Attackers got the credentials by posing as a trusted colleague to an ASOS employee, without forcing their way past the company's server defences.
- The notification claimed the group controlled ASOS's Snowflake analytics environments and told recipients to contact a group called Xuanye over private messaging.
- ASOS confirmed the intruders reached basic customer data such as full names and contact details, and ruled out exposure of card data or account passwords.
- Connections to the affected providers were cut, and ASOS posted a warning on its own platform telling customers to ignore the fraudulent link.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Confirmed names and contact details are enough to personalise fake parcel or refund texts, and the account argues customers already confused by the first alert will be easier to fool.
- exposure An official push skips email spam filtering and lands on the lock screen under the brand's name, so whoever holds the vendor login holds the channel customers treat as verified, the author argues.
- decision Access reviews scoped to servers and databases miss this path; the author's charge that companies guard master databases but neglect marketing panels puts vendor messaging logins on the same list.
The account takes its timeline from an incident report in Infosecurity Magazine [2]. In that telling, one username and password pair was enough to open the third-party platforms connected to ASOS's commerce environment [4]. Those platforms included the external tools the retailer uses to send mass messages to phones [3].
Nothing in the delivery path broke [14]. The most reliable component in the whole incident was the push vendor. According to the account, the alert system worked as designed and the control panel's master key was in the wrong hands [14]. The message threatened to publish private records and pointed readers to an outside channel [11]. Some people who saw it assumed their own phones were infected [16].
So the question is what the console required before it would send. The dev.to author's diagnosis is a missing hardware-based second check on mass sends. One compromised account, the author argues, should not be able to write a message and send it to every device without a second supervisor signing off [8]. The proposed fix is a physical security key or a staged approval before any campaign that reaches the whole user base [9].
I'd want both, because they block different steps of this attack. A password is something an employee can be talked into handing over. A key plugged into their laptop is much harder to give to a stranger posing as a colleague. The second approver covers the case where a session is stolen anyway: one account alone can no longer reach every installed app. I'd hold a whole-audience push to the same bar as a production deploy. On the account's evidence, the bar here was one password [4].
The account does not say which system the confirmed names and contact details came from. It also does not say whether ASOS accepted the attackers' claim about its Snowflake environments [5].
What to watch
- ASOS or its messaging vendor naming the push platform and saying whether those accounts required multi-factor login.
- An ASOS statement confirming or denying the Snowflake claim; a confirmation would extend the incident beyond the messaging tools.
- Phishing texts that use ASOS customers' real names in the weeks after the alert.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence30
- Adoption
- Insufficient
- Hype gap+25
- Incentives
- Insufficient
- Confidence30
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The intruders did not force their way through ASOS's central server defences; they deceived an employee by posing as a trusted colleague to obtain the employee's internal company passwords.
- [2]
The dev.to account cites an incident report published in Infosecurity Magazine for the confirmed timeline, which showed the initial vector was direct workplace identity impersonation.
- [3]
With that access, the attackers reached the external communication tools ASOS uses to send mass messages to phones.
- [4]
That single username and password pair was enough to get through to the third-party platforms integrated into the company's commercial environment.
- [5]
The mass notification claimed the group had taken control of Snowflake analytics environments and demanded that recipients contact a group identified as Xuanye through private messaging.
- [6]
ASOS confirmed the intruders accessed basic customer information such as full names and contact details, and ruled out compromise of bank card data or personal account passwords.
- [7]
ASOS cut connections with the affected providers and published a warning on its own platform asking customers to ignore the fraudulent link.
- [8]
The dev.to author argues the case shows the absence of hardware-based secondary validation for authorising mass sends, and that a compromised account should not be able to write a message and send it to millions of devices without a dual supervisory sign-off.
- [9]
The author argues that if internal software does not require a physical security key or a staged approval before running a campaign covering the entire user base, any stolen credential can paralyse the business.
- [10]
The author argues companies protect their master databases heavily but neglect the marketing panels from which they message people's phones directly.
- [11]
The message threatened to publish private records and directed recipients to an external channel.
- [12]
The author argues that a legitimate operating-system push notification leads consumers to assume the sender is verified, and that attackers using it avoid traditional email spam filters and place the lure directly on the lock screen.
- [13]
The author argues that names and contact details let gangs build targeted impersonation campaigns, such as texts about a held parcel or pending refund that use the person's real name, and that confusion from the earlier alert makes such scams more convincing.
- [14]
The account says the alert system itself worked correctly, but the master key to the control panel was in criminals' hands.
- [16]
Thousands of users opened the alert believing their mobile device was infected, according to the account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toBrecha de datos de ASOS: aviso falso de app secuestrada
1 article · October 8, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Push notification securityFollow
- Third-Party Access RiskFollow
- Social Engineering and Voice PhishingFollow