ASOS Cyberattack 2026: 6 Social Engineering Simulations to Prepare Your Team

What happened in the ASOS cyberattack?

At around 10am on 6 October 2026, ASOS app users received a push notification titled "ASOS HACKED". It was addressed to the company's data protection officer and IT team, claimed the sender had compromised ASOS data and threatened to leak it unless ASOS made contact through a Telegram channel.

ASOS later told customers that an unauthorised party gained access to an employee account by impersonating a trusted contact to obtain login credentials. The attacker used those credentials to access information on third-party platforms ASOS uses, including the platform that sent the push notification. According to ASOS, names, contact details and certain non-personal account information were accessed. No payment card information or account passwords were accessed.

ASOS says the affected platforms were locked down and that it is working with law enforcement and regulators. Its website and app remained safe to use. The company asks customers to stay cautious of unexpected messages or calls claiming to be from ASOS and says it will never ask for passwords, security codes or payment details that way. As a precaution, the UK's National Cyber Security Centre advises ASOS customers to assume they could be affected, even without receiving the notification.

Reported, not confirmed by ASOS: The attackers sent the BBC a data sample that contained more than basic contact details, including home addresses, customer numbers and search history.

Claimed by the attackers: The notification said the attackers had "fully compromised" ASOS's Snowflake instance, meaning the company's own data environment hosted on Snowflake. ASOS has not confirmed that this environment was accessed. Snowflake has disputed that its own platform was compromised. The attackers also told the BBC they reached the data through a marketing platform connected to Snowflake.

Still unclear: which channel the attacker used to impersonate the trusted contact, which platforms beyond the notification service were accessed and how many customers are affected.

Why it matters

The attacker didn't need to find a vulnerability in ASOS's website. According to the company, they impersonated someone an employee trusted and obtained their login credentials. Those credentials were then used to access third-party platforms, including the service responsible for sending notifications to ASOS customers.

That last part is particularly concerning. Customers received an attacker-controlled message through the company's own app, a channel they would normally consider trustworthy.

For security teams, this raises two questions. How much access can a single employee account provide across connected services? And would employees recognise an attempt to steal those credentials if the request appeared to come from someone they already knew?

Phishing-resistant MFA and tighter access controls help limit the damage. But employees also need to practise checking requests that seem entirely routine.

6 simulations that prepare employees for attacks like this

ASOS has yet to disclose exactly how the attack was carried out. The six common social engineering scenarios below show how similar attacks can unfold and how you can prepare your employees for them. They are illustrative and not a reconstruction of the ASOS attack.

1. Spear Phishing: A Trusted Contact Asks You to Sign In

An email arrives from a familiar supplier asking an employee to review a shared document. The sender knows the company's current projects, refers to an actual business relationship and uses the right terminology. Nothing about the message immediately looks suspicious.

The attacker doesn't necessarily need access to internal systems to make it convincing. Supplier announcements, company websites and even public procurement information can reveal enough to construct a believable request, as our analysis of OSINT-based spear phishing explains.

A useful simulation tests whether employees verify a familiar-looking request before acting on it.

2. Helpdesk Vishing: "IT Support" Calls About Your Account

Imagine opening your inbox to hundreds of unexpected emails. Newsletter confirmations, subscription notices and automated messages keep arriving. Then someone claiming to be from IT calls and offers to fix the problem.

The timing makes the call believable. What the employee doesn't know is that the attacker deliberately flooded their inbox before contacting them.

This technique, known as spam bombing, has been used alongside fake IT support calls and requests to launch remote-access tools. The supposed technician appears to be responding to a problem the employee is already experiencing.

A simulation can recreate that pressure and test whether employees follow the caller's instructions or verify the support request through their company's official IT channels.

3. Multi-Channel Phishing: An Email Followed by a Call

An employee receives an email about an upcoming access review. A calendar invitation arrives shortly afterwards, followed by a call from someone claiming to be responsible for the review.

Each contact seems to confirm the previous one. The caller knows what was written in the email, and the calendar invitation makes the process look organised.

But all three contacts could come from the same attacker.

Multichannel attacks deserve more attention than isolated phishing emails, because the employee has to judge several interactions that appear to support each other.

A realistic simulation tests whether employees still verify the request independently when multiple channels reinforce the same story.

4. Smishing: A Text That Moves the Conversation Off Email

A text message claims to come from a colleague with a new number, a delivery service or an account team. Once the employee replies, the conversation shifts to a link, a request for a code or a call. Messengers are used the same way, outside the reach of email filters.

On a phone, requests feel personal and get answered quickly, often outside working hours. The wrong-number scam shows how an innocent first text turns into a longer conversation, and messaging apps have become a common channel for the same tactics. SMS exercises let employees practise stopping at the first unexpected request and reporting it.

5. Breach-Themed Phishing: Fake Security Alerts After an Incident

The phishing risk can continue long after the original attack.

Once a breach becomes public, attackers have a ready-made reason to contact employees, customers and business partners. A message claiming to contain an urgent security update is much easier to believe when everyone has already heard about the incident.

The attacker might impersonate the IT department and demand an immediate password reset. Customers might receive messages about refunds or account verification. Business partners could be asked to reconfirm their access to shared systems.

As explored in When Breach Notifications Become the Breach, fake security notices exploit the expectation that people should respond quickly to a genuine incident.

This makes breach-related phishing particularly useful for awareness simulations. Employees need to distinguish a legitimate security instruction from someone exploiting the news, without becoming reluctant to respond to real alerts.

6. Deepfake CEO Fraud: An Executive on a Video Call

There is no indication that video played a role at ASOS. It belongs on this list because trusted-contact impersonation no longer stops at email and phone. A finance or operations employee joins a short video meeting with what looks and sounds like a senior executive, who asks for an urgent transfer or access change.

A familiar face on screen is not verification, and approvals follow the agreed process whoever asks. Deepfake exercises in live meetings let teams feel that pressure in a safe setting, and our analysis of CEO fraud losses shows what is at stake when the process gives way.

What security teams should test after the ASOS incident

The ASOS breach raises a practical question for security teams: would employees recognise an impersonation attempt if the attacker used accurate information and contacted them through a familiar channel?

Three exercises are worth considering:

1. Test familiar-contact impersonation. Use a realistic supplier or colleague pretext and measure whether employees verify unexpected login requests through an established channel.
2. Test multichannel escalation. Follow an email with a related phone call or collaboration message. Does the second contact increase compliance, or do employees still verify the request independently?
3. Test reporting behaviour. Check whether employees report suspicious requests, how quickly they do so and whether those behaviours improve over successive simulations.

These exercises should complement phishing-resistant authentication, least-privilege access and monitoring across connected SaaS platforms.

The aim is to find out whether employees recognise an attempt to exploit trust before it turns into unauthorised access.

How revel8 helps build a human firewall

Attacks like this succeed because the request looks familiar. revel8 Threat Intelligence & OSINT shows which details about your organisation and its people are publicly available, and simulations use those details so each lure resembles what a real attacker would send.

The Awareness Playlist runs these scenarios automatically across email, SMS, AI voice calls and deepfake video, including attacks that start in the inbox and continue with a phone call. AI voice personas place live calls and leave voicemails, deepfake video clones join live meetings, and scenarios follow current attack methods. Each interaction is followed by a short interactive training, and results are reported at group level so security teams can follow how reporting and verification develop over time.

Book a demo to see a simulation, or hear how convincing a cloned voice sounds with the free voice phishing tool.

FAQ

How did attackers get into ASOS?

According to ASOS, an unauthorised party gained access to an employee account by impersonating a trusted contact to obtain login credentials. Those credentials were then used to access information on third-party platforms ASOS uses. ASOS has not said which channel was used for the impersonation.

What customer data was affected in the ASOS breach?

ASOS says names, contact details and certain non-personal account information were accessed, and that no payment card information or account passwords were accessed. The BBC reports that a data sample sent by the attackers contained more, such as home addresses and search history, which ASOS has not confirmed.

Was ASOS's Snowflake account hacked?

The attackers claimed to have compromised ASOS's Snowflake environment. ASOS has not confirmed this. Snowflake has denied that its own platform was compromised.

What should ASOS customers watch out for?

Be cautious of unexpected emails, texts or calls claiming to be from ASOS, especially requests for passwords, security codes or payment details. ASOS says it will never ask for these through an unsolicited message or call. Open the ASOS app or website directly instead of using links.

How can companies prepare employees for trusted-contact impersonation?

Regular simulations that use realistic pretexts across email, phone, SMS and video let employees practise verifying requests through known channels. Clear callback rules, an easy way to report suspicious contact and phishing-resistant MFA support that practice.