ASOS, the global online fashion retailer, has confirmed a data breach after attackers gained access through the compromise of Simon AI, an agentic marketing platform used by the retailer. According to the attackers' own claims, the intrusion did not begin with a vulnerability in ASOS infrastructure — it began with stolen employee credentials at a third-party SaaS vendor that held trusted access to ASOS data.
This is the defining breach pattern of 2025–2026: the initial access vector is no longer your perimeter. It is the expanding web of SaaS platforms, AI-driven marketing tools, customer data platforms (CDPs), and automation agents that hold API keys, OAuth tokens, and federated credentials into your environment. When a vendor like Simon AI is compromised, every downstream customer that granted it access becomes a target.
For defenders, the ASOS incident is a forcing function. If your organization uses AI-powered marketing, analytics, or customer engagement platforms — and nearly every mid-to-large enterprise does — you need to assume those platforms are in-scope for your threat model today. This post breaks down the attack pattern, provides detection content for credential abuse and anomalous SaaS access, and delivers concrete remediation steps.
Technical Analysis
What Happened
Based on the public reporting:
- Victim: ASOS (online fashion retailer)
- Initial access vector: Compromised employee credentials at Simon AI, an agentic (AI-driven) marketing platform
- Attack type: Third-party / supply-chain compromise leveraging legitimate credentials — no malware or zero-day required
- Claimed by: The attackers themselves publicly attributed the ASOS intrusion to the Simon AI compromise
The Attack Chain (Defender's Perspective)
While full technical details have not been disclosed, this class of breach follows a well-documented chain that maps cleanly to MITRE ATT&CK:
- Credential harvesting (T1078 – Valid Accounts): Attackers obtain Simon AI employee credentials — typically via infostealer malware, phishing, or credential-stuffing against reused passwords. Infostealer logs sold on underground markets remain the dominant source of SaaS credential compromise in 2026.
- SaaS platform access: Using valid credentials, attackers authenticate to the vendor's platform. Because the login is "legitimate," it bypasses most perimeter controls. The absence of enforced phishing-resistant MFA at the vendor is almost always the enabling weakness.
- Abuse of trusted integrations: Agentic marketing platforms hold persistent, privileged connections into customer environments — OAuth tokens, API keys, webhooks, and data sync pipelines into CRMs, customer databases, and data warehouses. Attackers pivot through these trust relationships (T1550 – Use Alternate Authentication Material, T1098.001 – Additional Cloud Credentials).
- Data access/exfiltration (T1530 – Data from Cloud Storage): Customer data reachable through the integration is queried, staged, and exfiltrated — often through the same API paths the integration legitimately uses, making exfiltration blend into normal traffic.
Why Agentic AI Platforms Raise the Stakes
"Agentic" platforms are not passive dashboards. They autonomously act on customer data — reading audiences, writing campaigns, calling downstream APIs. This means:
- Broader scopes: OAuth grants for these tools frequently include read/write access to customer records, order histories, and behavioral data.
- Persistent tokens: Refresh tokens and service accounts that rarely expire and are rarely rotated.
- Weak audit trails: Activity logs live at the vendor, not in your SIEM — unless you deliberately ingest them.
Exploitation Status
- CVE: None assigned — this is credential abuse and third-party trust exploitation, not a software vulnerability. No CVE is claimed in reporting.
- Status: Confirmed active breach with public attacker claims. ASOS has acknowledged the incident.
- CISA KEV: Not applicable (no CVE).
The correct defensive framing is technique-based detection, not signature-based patching.
Detection & Response
The detections below target the observable behaviors in this attack class: anomalous SaaS/OAuth token use, impossible-travel and off-hours cloud API access, credential-stuffing indicators against your own SSO, and bulk data reads through integration service accounts. Tune thresholds to your baseline before production deployment.
Sigma Rules
---
title: Anomalous OAuth Token Use by Third-Party Integration
tid: 3f8a1c92-7b4d-4e51-9a63-2c5d8f1e7a90
status: experimental
description: Detects service accounts or OAuth app registrations associated with third-party SaaS integrations performing data access from unusual sources or at unusual volume, consistent with vendor-compromise pivoting (e.g., Simon AI / ASOS pattern).
references:
- https://attack.mitre.org/techniques/T1550/001/
- https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/06/09
tags:
- attack.initial_access
- attack.t1078
- attack.t1550.001
logsource:
product: azure
service: auditlogs
detection:
selection:
operationName|contains:
- 'Consent to application'
- 'Add service principal credentials'
- 'Add app role assignment to service principal'
filter_known_admins:
initiatedBy.user.userPrincipalName|contains:
- '@yourdomain.com'
condition: selection and not filter_known_admins
falsepositives:
- Legitimate application onboarding by developers or vendors during integration work
level: high
---
title: Bulk Data Export via Service Principal or API Integration
tid: 8c2e4f17-3a9b-4d62-b7e1-5f0a9c3d6e82
status: experimental
description: Detects bulk export, list, or query operations performed by non-interactive service principals against data stores, a hallmark of data theft via compromised third-party marketing/analytics platform credentials.
references:
- https://attack.mitre.org/techniques/T1530/
- https://www.infosecurity-magazine.com/news/asos-data-breach-stolen-employee/
author: Security Arsenal
date: 2026/06/09
tags:
- attack.collection
- attack.exfiltration
- attack.t1530
logsource:
product: azure
service: auditlogs
detection:
selection:
identityType: 'ServicePrincipal'
operationName|contains:
- 'Export'
- 'BulkDownload'
- 'List secrets'
- 'StorageBlobRead'
condition: selection
falsepositives:
- Scheduled ETL and backup jobs running under service principals; whitelist known job identities and schedules
level: medium
---
title: Credential Stuffing or Password Spray Against SSO Portal
tid: 1d5b8e34-6c2f-4a73-9d08-7e4b1f6a3c95
status: experimental
description: Detects high-volume failed authentication attempts followed by a success from a previously unseen source IP, consistent with credential stuffing of employee SSO accounts — the initial access technique in the Simon AI compromise.
references:
- https://attack.mitre.org/techniques/T1110/004/
- https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/06/09
tags:
- attack.credential_access
- attack.t1110.004
logsource:
category: authentication
product: azure
detection:
selection:
ResultType:
- '50126' # invalid username or password
- '50053' # account locked
- '50055' # expired password
ResultCount|gte: 10
condition: selection
falsepositives:
- Misconfigured legacy email clients; corporate VPN egress IPs shared by many users
level: high
KQL — Microsoft Sentinel / Defender
Hunt for anomalous third-party app access and impossible-travel sign-ins against your identity provider. This query assumes Entra ID sign-in and audit logs are ingested into Sentinel — extend AppDisplayName values with your own approved marketing/CDP/AI SaaS integrations.
// Hunt: Third-party SaaS app access from unusual IPs or with unusual data volume
// Relevant to vendor-compromise pivoting (Simon AI / ASOS pattern)
let Lookback = 14d;
let KnownIntegrationApps = dynamic(["Simon AI", "Salesforce Marketing Cloud", "Braze", "Segment", "HubSpot"]);
let Baseline =
SigninLogs
| where TimeGenerated > ago(30d) and TimeGenerated < ago(Lookback)
| where AppDisplayName in (KnownIntegrationApps)
| summarize BaselineIPs = make_set(IPAddress) by AppDisplayName, UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(Lookback)
| where AppDisplayName in (KnownIntegrationApps)
| extend IsServicePrincipal = iff(Identity contains "#", true, false)
| summarize SigninCount = count(),
UniqueIPs = dcount(IPAddress),
IPs = make_set(IPAddress),
Locations = make_set(Location),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by AppDisplayName, UserPrincipalName, Identity, ResultType
| where UniqueIPs > 3 or ResultType != "0"
| join kind=leftouter Baseline on AppDisplayName, UserPrincipalName
| extend NewIPActivity = iff(set_has_element(BaselineIPs, tostring(IPs[0])), "Known", "NEW SOURCE IP")
| where NewIPActivity == "NEW SOURCE IP" or SigninCount > 50
| project LastSeen, AppDisplayName, Identity, ResultType, SigninCount, UniqueIPs, IPs, Locations, NewIPActivity
| order by LastSeen desc;
// Companion: OAuth grants and credential additions to service principals in the last 7 days
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Consent to application", "Add service principal credentials", "Add app role assignment")
| mv-expand TargetResources
| extend ModifiedProps = TargetResources.modifiedProperties
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
TargetApp = tostring(TargetResources.displayName), ModifiedProps, CorrelationId
| order by TimeGenerated desc;
Velociraptor VQL
Infostealer-derived credentials are the most common upstream source in vendor compromises. This artifact hunts endpoints for indicators of infostealer staging — browser credential store access by non-browser processes — on your own fleet, since the same technique threatens your employees' SaaS credentials.
-- Hunt: Non-browser processes accessing browser credential stores (infostealer behavior)
-- Source of stolen employee SaaS credentials in third-party compromise campaigns
LET browser_paths = {
'Chrome': 'C:/Users/*/AppData/Local/Google/Chrome/User Data/*/Login Data',
'Edge': 'C:/Users/*/AppData/Local/Microsoft/Edge/User Data/*/Login Data',
'Firefox':'C:/Users/*/AppData/Roaming/Mozilla/Firefox/Profiles/*/logins.json'
}
SELECT Pid,
Name,
Exe,
CommandLine,
Username,
CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(Login Data|logins\.json|Cookies|Local State|key4\.db)'
AND NOT Exe =~ '(?i)(chrome\.exe|msedge\.exe|firefox\.exe|defender|sentinel|crowdstrike|msmpeng)'
ORDER BY CreateTime DESC
Remediation Script
Use this PowerShell to audit your Entra ID tenant for third-party application consent grants, service principals with credential material, and risky OAuth permission scopes — the exact trust relationships abused in the ASOS/Simon AI pattern. Requires the Microsoft.Graph module and Application.Read.All + Directory.Read.All scopes.
# Third-Party SaaS App Audit — Run after a vendor breach disclosure
# Identifies high-risk OAuth grants and stale service principal credentials
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","AuditLog.Read.All" -NoWelcome
$reportPath = ".\ThirdPartyAppAudit_$(Get-Date -Format yyyyMMdd).csv"
$highRiskScopes = @('Mail.Read','Mail.Send','full_access_as_app','Sites.ReadWrite.All','Files.ReadWrite.All','Directory.Read.All','User.Read.All')
# 1) Enumerate all service principals with delegated permission grants
$results = foreach ($sp in (Get-MgServicePrincipal -All)) {
$grants = Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $sp.Id -All -ErrorAction SilentlyContinue
foreach ($g in $grants) {
[PSCustomObject]@{
AppDisplayName = $sp.DisplayName
AppId = $sp.AppId
PublisherName = $sp.PublisherName
Verified = $sp.VerifiedPublisher.Verified
ConsentType = $g.ConsentType # AllPrincipals = tenant-wide = high risk
Scopes = $g.Scope
HighRiskScope = [bool]($highRiskScopes | Where-Object { $g.Scope -match [regex]::Escape($_) })
CreatedDateTime = $sp.AdditionalProperties.createdDateTime
}
}
}
$results | Sort-Object HighRiskScope -Descending | Export-Csv $reportPath -NoTypeInformation
# 2) Flag unverified publishers with tenant-wide consent
$results | Where-Object { $_.ConsentType -eq 'AllPrincipals' -and $_.Verified -ne $true } |
Format-Table AppDisplayName, Scopes, HighRiskScope -AutoSize
# 3) Find service principals with secrets/certificates older than 180 days (rotate!)
$cutoff = (Get-Date).AddDays(-180)
foreach ($sp in (Get-MgServicePrincipal -All | Where-Object { $_.PasswordCredentials.Count -gt 0 })) {
foreach ($cred in $sp.PasswordCredentials) {
if ($cred.StartDateTime -lt $cutoff) {
Write-Warning "STALE SECRET: $($sp.DisplayName) — secret created $($cred.StartDateTime). Rotate immediately."
}
}
}
# 4) Review sign-in activity for named third-party apps (adjust list to your vendors)
$vendors = @('Simon AI','Braze','Segment','HubSpot','Salesforce')
foreach ($v in $vendors) {
$signins = Get-MgAuditLogSignIn -Filter "appDisplayName eq '$v'" -Top 50 -ErrorAction SilentlyContinue
if ($signins) {
$signins | Select-Object CreatedDateTime, UserPrincipalName, IPAddress,
@{N='Location';E={"$($_.Location.City), $($_.Location.CountryOrRegion)"}}, Status |
Format-Table -AutoSize
}
}
Write-Host "Audit complete. Full report: $reportPath" -ForegroundColor Green
Remediation
This incident has no patch — remediation is architectural and procedural. Prioritize the following:
Immediate (0–72 hours) if you use Simon AI or were notified as an affected customer:
- Revoke and rotate all credentials associated with the compromised vendor: OAuth tokens, API keys, webhooks secrets, and any service accounts the vendor's platform used to reach your environment. Assume all material held by the vendor is exposed.
- Audit vendor platform activity logs for unauthorized access, bulk exports, or configuration changes covering at least the last 90 days. Request the vendor's forensic findings and IOCs in writing.
- Force password resets and MFA re-verification for any employee accounts that authenticated to the vendor platform — infostealer-harvested sessions often include session cookies, so revoke active sessions too (in Entra ID:
Revoke-MgUserSignInSession). - Review your notification obligations — GDPR, state breach laws (e.g., Texas, given many retail operations), and PCI-DSS §12.8 if payment-adjacent data is involved. ASOS operates globally; your exposure depends on what data the integration touched.
Short-term (30 days):
- Inventory every third-party SaaS integration with access to customer or employee data. Run the audit script above quarterly. You cannot defend trust relationships you haven't cataloged.
- Enforce least-privilege OAuth scopes. Marketing platforms rarely need
User.Read.Allor write scopes tenant-wide. Re-consent with the minimum viable permission set and use admin consent workflows with approval gates. - Mandate phishing-resistant MFA (FIDO2/passkeys) contractually for vendors with access to your data, and require evidence — this is the single control that would have broken this attack chain at step one.
- Ingest vendor SaaS logs into your SIEM. Blind trust in vendor-hosted audit trails is how these breaches go undetected for months.
Strategic:
- Treat agentic AI platforms as privileged access systems. Anything that autonomously acts on your customer data deserves the same governance as a domain admin: continuous monitoring, token lifetime limits, IP allowlisting on API keys, and break-glass revocation runbooks.
- Add third-party compromise to your IR playbooks and tabletop exercises. The ASOS incident shows the breach notification may come from the attackers' public claims before the vendor's disclosure — your playbook must handle that ambiguity.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.