Marks & Spencer y la wave UK retail: cuando el helpdesk del proveedor es el camino más corto

El 25 de abril de 2025 Marks & Spencer suspende todas las compras online en su web y app móvil. El comunicado del CEO Stuart Machin describe un «cyber incident», sin detalle del vector. Cuatro días antes, durante el fin de semana de Pascua (19-21 abril), los pagos contactless y el Click & Collect habían empezado a fallar de forma intermitente en tiendas; el 23 de abril, Machin recibió un mensaje desde una cuenta de email corporativa de M&S — controlada ya por los atacantes — confirmando que la red estaba cifrada. Hasta el 27 de abril M&S no usa la palabra «ransomware» en público.

El vector se hace público entre el 1 y el 5 de mayo: social engineering al helpdesk IT de Tata Consultancy Services (TCS), proveedor outsourced de M&S, para conseguir reset de credenciales y MFA de empleados internos. El acceso se atribuye a Scattered Spider como initial access broker; el ransomware desplegado, a DragonForce, en su nuevo modelo de cartel afiliado. Microsoft trackea al grupo como Octo Tempest. Tres semanas después, Co-op confirma el mismo vector (29 abril), y Harrods contiene un intento (1 mayo). Tres retailers UK, mismo playbook, dos semanas.

Lab: el PoC de este post se centra en el control compensatorio, no en la ofensa. Active Directory mínimo en VM, simulación de la llamada al helpdesk con script de reset PowerShell, y demostración de: (a) el flujo «estándar» que funciona contra Scattered Spider, (b) tres controles compensatorios que rompen el playbook. Todo en VM cerrada.

El vector — lo que ya sabíamos desde MGM 2023

El playbook no es nuevo. En septiembre de 2023, MGM Resorts y Caesars Entertainment caen con el mismo método: llamada al helpdesk IT, suplantación de empleado, reset de password y MFA token. Atribuido entonces a Scattered Spider (UNC3944 según Mandiant). MGM pierde ~$100M operativos en una semana. Caesars paga $15M de rescate documentado.

Lo que cambia en 2025 no es la técnica, sino la escala industrial:

• Tres victimas conocidas en dos semanas en el mismo sector geográfico (retail UK), todas con el mismo vector inicial. El grupo opera por sector — concentra fuerza, satura medios, después rota.
• Outsourcing del helpdesk como multiplicador. M&S, como muchas grandes UK retail, no opera su tier-1 IT internamente. Lo subcontrata a TCS. El operador del helpdesk no es empleado M&S — es contratista TCS con acceso a herramientas M&S. La verificación de identidad del «empleado» que llama depende de procesos definidos contractualmente entre dos organizaciones, no de relación personal del operador con el solicitante.
• DragonForce como cartel afiliado, no operador único. DragonForce rebrand en 2025 ofrece 80 % de payout a sus afiliados, sin operativa propia. Scattered Spider monta el acceso inicial; DragonForce provee el encryptor y el portal de extorsión. La especialización divide la cadena.

El factor outsourcing es el que vuelve el patrón sistémico. En 2023 con MGM, el helpdesk atacado era interno. En 2025 con M&S y Co-op, el helpdesk es de TCS — el mismo proveedor para ambos. Un solo set de procesos de verificación, un solo conjunto de operadores entrenados con los mismos manuales, un solo vector reutilizable contra cualquier cliente del proveedor.

La cronología documentada

Lo verificable a fecha de cierre del incidente (mayo 2025), agregando fuentes públicas:

• 22 abril 2025 — Actividad sospechosa detectada en redes M&S: logins anómalos, intentos de escalada. El CSIRT M&S empieza investigación interna.
• 23 abril — El CEO Stuart Machin recibe el mensaje del grupo de extorsión desde una cuenta @marksandspencer.com comprometida, firmado por DragonForce. La cuenta había sido aprovechada vía el reset de MFA conseguido vía helpdesk.
• 25 abril — Click & Collect desactivado nacional. Comunicado público breve, sin atribución.
• 27 abril — Machin confirma «ransomware» en comunicación interna filtrada. La red interna queda parcialmente cifrada.
• 29 abril — Co-op Group anuncia haber detectado un compromiso similar y haber «taken systems offline» preventivamente. La rapidez de detección de Co-op (24-48 horas tras la intrusión inicial) limita el daño a back-office y call-center.
• 1 mayo — Harrods anuncia intento de intrusión contenido sin disrupción operativa. Mismo vector reportado, contención temprana.
• 2 mayo — M&S sigue con online suspendido. Estimación de pérdida: £3.8M de revenue online por día.
• 8 mayo — El NCSC UK publica blog post con guidance específica sobre helpdesk impersonation, sin nombrar directamente a los retailers afectados.
• mediados-mayo — Recuperación parcial de M&S ecommerce. Recuperación completa anunciada para julio.
• 21 mayo — M&S guida estimación de impacto operativo: ~£300M en operating profit del año fiscal.
• 6 julio — Confirmación pública de la atribución Scattered Spider + DragonForce vía investigación del Cyber Monitoring Centre (CMC), que clasifica el conjunto M&S + Co-op como «single combined cyber event» con impacto agregado entre £270M y £440M.

Lo que el M&S annual report posterior añade: la intrusión inicial penetra alrededor del 17 abril, aproximadamente 8 días antes de la suspensión online. La ventana entre acceso inicial y exfiltración + cifrado es donde se juega la contención — donde se gana o se pierde el incidente.

El playbook técnico — paso a paso

El flujo Scattered Spider documentado por Microsoft (Octo Tempest), Mandiant (UNC3944) y NCSC, reconstruido para M&S:

1. Reconnaissance — LinkedIn + breach data

El operador identifica un empleado real M&S con perfil objetivo: idealmente IT, finance, o privileged user. LinkedIn es la fuente primaria — nombre, rol, equipo, manager. Breach data agregada (Have I Been Pwned, dehashed.com, telegramas tipo «cocoricos») da personal info: número de teléfono privado del empleado, email personal alternativo, fecha de nacimiento aproximada. En las versiones más cuidadas del playbook, el operador llama al objetivo previamente con un pretexto (encuesta, falsa entrega) para confirmar voz y disponibilidad.

2. Llamada al helpdesk

El operador llama al número público del helpdesk (TCS Service Desk en el caso M&S). Suplanta al empleado identificado. El guion estándar — capturado en grabaciones de incidentes anteriores y reportado por defenders que han trabajado el lado azul:

> Helpdesk: TCS Service Desk, how can I help you?
> Operador: Hi, this is [Nombre] from [Equipo]. I'm trying to log in
            from home and my password isn't working. I think I locked
            it after too many attempts.
> Helpdesk: Sure, can I verify your employee ID?
> Operador: It's [4-digit ID estimado o sacado de LinkedIn URL].
> Helpdesk: And your date of birth?
> Operador: [Fecha de nacimiento de breach data].
> Helpdesk: Last thing, your manager?
> Operador: [Manager de LinkedIn].
> Helpdesk: OK, I'm resetting your password. New temporary password
            is [...]. You'll need to change it on first login.
> Operador: Great, thanks! Oh, and I lost my phone yesterday — can
            you also reset my MFA? I haven't had time to enrol a new
            device.
> Helpdesk: Sure, MFA reset. You'll see the enrollment flow next login.
> Operador: Perfect, thank you!

Tres minutos. Sin verificación cruzada por canal alternativo. Sin checkpoint a manager. Sin verificación biométrica (voiceprint, cosa que algunos vendors tier-1 ofrecen pero pocas organizaciones implementan).

3. Login + persistence

Con password y MFA reset, el operador entra vía VPN corporativa o Citrix gateway. Configura su propio MFA (Microsoft Authenticator o YubiKey, según política). Desde ese momento, es el empleado desde el punto de vista del sistema. Lo siguiente es el playbook estándar de post-explotación:

• Mapeo del Active Directory (BloodHound, SharpHound).
• Enumeración de cuentas privilegiadas, grupos de admin, GPOs.
• Pivoteo a otra cuenta más privilegiada vía Kerberoasting, abuse de delegations, o repetir el mismo trick al helpdesk con otro empleado más senior.
• Carga del implantes de C2 (Cobalt Strike, Sliver, o Brute Ratel en operaciones recientes).
• Detección de ESXi en la red — Scattered Spider tiene preferencia documentada por encriptar hypervisores (boletín y noticias técnicas de 2024).

4. Exfil + cifrado

Antes del cifrado, exfiltración a infraestructura del atacante. En el caso M&S la cifra reportada es de 150 GB de datos corporativos vía MEGA y otros servicios de file-sharing. Después, despliegue del binario DragonForce contra hosts y ESXi. M&S reporta decenas de miles de hosts afectados.

El control compensatorio que funciona

La parte interesante operativa: el bug no es el reset en sí, sino el proceso de verificación de identidad del solicitante. Cualquier helpdesk de empresa con >500 empleados resetea credenciales todos los días, operación legítima. La pregunta es: ¿cómo sabe el operador que la persona al otro lado es quien dice ser?

Las preguntas de seguridad estándar (employee ID, DOB, manager) son public knowledge en 2025: LinkedIn + breach data agregada cubre los tres campos para el 90 % de los empleados de cualquier multinacional. La verificación basada en eso no es verificación.

Tres controles compensatorios que rompen el playbook, en orden de fricción creciente:

Control 1 — Verificación por canal alternativo (out-of-band)

El operador del helpdesk no resetea por la información que el solicitante da. Inicia un challenge en un canal independiente que sólo el empleado real puede responder. Implementación mínima en lab:

# helpdesk-verify-oob.ps1 — control compensatorio out-of-band
param(
    [Parameter(Mandatory=$true)][string]$EmployeeId,
    [Parameter(Mandatory=$true)][string]$RequestType  # "password" | "mfa" | "both"
)

# 1) Resolver email y Teams ID del empleado desde AD (no de lo que dice el caller)
$user = Get-ADUser -Filter "EmployeeID -eq '$EmployeeId'" `
    -Properties Mail, Title, Manager, OfficePhone

if (-not $user) {
    Write-Error "Empleado no encontrado en AD"
    exit 1
}

# 2) Generar challenge code de 6 dígitos
$challenge = (Get-Random -Minimum 100000 -Maximum 999999).ToString()

# 3) Enviarlo al canal corporativo que registra AD — no al que dice el caller
# Aquí simulamos con Send-MailMessage; en producción, Teams DM via Graph API
Send-TeamsDirectMessage -UserPrincipalName $user.UserPrincipalName `
    -Message "Code de verificación de helpdesk: $challenge. " +
             "Si NO has solicitado un reset, ignora este mensaje y reporta " +
             "a security@empresa.com."

# 4) Esperar a que el caller diga el code de vuelta
Write-Host "Esperando code de verificación..."
$caller_code = Read-Host "Code dictado por el caller"

if ($caller_code -ne $challenge) {
    Write-Error "Code incorrecto. Reset DENEGADO. Loggeando intento."
    Add-Content -Path "C:\Security\HelpdeskAttempts.log" `
        -Value "$(Get-Date -Format o) | DENIED | $EmployeeId | $RequestType"
    exit 1
}

# 5) Si llega aquí, proceder con el reset
Write-Host "Verificación OK. Procediendo con $RequestType reset..."
# ... reset real ...

El operador del helpdesk no decide a quién pertenece el Teams DM — decide AD. Si el atacante ha conseguido también acceso al Teams del empleado real, el control falla — pero estamos un escalón más arriba. La barra ya no es «conocer el employee ID»; es «tener acceso al Teams corporativo del empleado».

Control 2 — Manager checkpoint para reset de privilegiadas

Reset de credenciales de usuarios normales: control 1 es suficiente. Reset de credenciales privilegiadas (admin AD, accesos a producción, cuentas de servicio): segundo factor humano. El operador del helpdesk no puede auto-aprobar el reset; debe escalar a manager directo del solicitante.

# helpdesk-privileged-reset.ps1 — checkpoint adicional
param(
    [Parameter(Mandatory=$true)][string]$EmployeeId,
    [Parameter(Mandatory=$true)][string]$Reason
)

$user = Get-ADUser -Filter "EmployeeID -eq '$EmployeeId'" `
    -Properties Mail, Manager, MemberOf

# Es privileged?
$is_privileged = $user.MemberOf | Where-Object {
    $_ -match "Domain Admins|Enterprise Admins|Privileged Users"
}

if ($is_privileged) {
    Write-Host "Cuenta privilegiada. Requiriendo aprobación de manager."

    $manager = Get-ADUser -Identity $user.Manager -Properties Mail
    $approval_token = New-Guid

    Send-TeamsDirectMessage -UserPrincipalName $manager.UserPrincipalName `
        -Message ("Reset de PRIVILEGED account solicitado para " +
                  "$($user.Name). Reason: $Reason. " +
                  "Aprueba: https://helpdesk.internal/approve/$approval_token. " +
                  "Si NO esperas esta solicitud, denied + alert security@.")

    # Polling hasta que manager apruebe o timeout 30 min
    Write-Host "Esperando aprobación de manager (timeout 30 min)..."
    # ... polling con Wait-ApprovalToken ...
}

Control 3 — Time-delay automático para resets de tier-2+

Configurable: cualquier reset que afecta cuentas privilegiadas o que se solicita fuera de horario laboral espera 45 minutos entre la solicitud y la activación. Durante esos 45 minutos, el empleado real recibe notificación por email + Teams + SMS. Si la solicitud es legítima, espera; si no lo es, dispara cancelación + alert.

Implementación simple: encolar el reset en una tabla, scheduled task que procesa cada 5 minutos consultando si se ha cancelado. Si el atacante depende de velocidad (y depende — la ventana entre reset y detección del usuario real es donde gana), 45 minutos es letal para el playbook.

Lo que NCSC pide a los retailers UK

El blog post del NCSC del 8 de mayo recoge tres acciones que cualquier empresa con helpdesk outsourced debe revisar:

1. Auditar el proceso de verificación de identidad del helpdesk. Cómo se autentica el solicitante. Si la verificación se basa en información pública o semi-pública (employee ID, DOB, manager name), es vulnerable por defecto. Implementar out-of-band challenge.
2. Revisar quién puede resetear cuentas privilegiadas. En muchos setups el tier-1 helpdesk tiene los mismos permisos para todas las cuentas. Diferenciación: tier-1 resetea usuarios normales con out-of-band; tier-2 + manager checkpoint resetea privilegiadas; cuentas críticas (Domain Admins, root de prod) requieren ticket aprobado por seguridad + presencia física.
3. Logging y alerting sobre patrón de resets. Múltiples resets en ventana corta de cuentas relacionadas (mismo manager, mismo equipo) deben disparar review automática. El playbook Scattered Spider deja firma — comparte patrón temporal.

NCSC añade un cuarto punto operativo: revisar contratos con proveedores IT outsourced para que los procesos de verificación del helpdesk del proveedor cumplan el estándar del cliente, no el del proveedor. La verificación que basta para resetear una cuenta de @cliente-pequeño.com no basta para @marks-and-spencer.com.

Lo que pasa después

Las consecuencias se cierran a lo largo del año:

• Julio 2025 — Arrestos en UK de cuatro individuos relacionados con la operación. Tres en su veintena, uno menor. Charges relacionadas con conspiración, fraud, money laundering. El NCA británica + FBI cooperan.
• Agosto 2025 — M&S confirma rotura del contrato con TCS por el helpdesk. Migra el servicio a otro proveedor con SLA renegociado.
• Septiembre-diciembre 2025 — Litigation civil arrancando: customers afectados, accionistas, regulatory probes por la FCA. ICO investiga el handling de datos personales.

El último impacto operativo, no cuantificable de momento: el patrón Scattered Spider + DragonForce afiliado se replica en otros sectores durante el verano de 2025 — Coca-Cola European, Allianz Life, multiples hospitality y aviation. Octo Tempest expande su targeting a aviación. El playbook helpdesk no es exclusivo de UK retail; está disponible para cualquier sector con outsourcing de tier-1 IT.

Lo que retener

Cuatro puntos para un CISO que quiere salir del año sin caer en la misma trampa:

1. El helpdesk es identity perimeter. Más que el firewall, más que el WAF. Es el control que regula quién puede ser quién dentro del directorio. Tratarlo como service ops (cumplir SLA de resets/hora) en lugar de security ops (verificar identidad correctamente) es la decisión que se paga después.
2. Outsourcing IT requiere contractual hardening específico. El proveedor no implementa controles de seguridad gratis. Si quieres out-of-band verification, manager checkpoint, time-delay — escríbelo en el contrato con SLAs medibles, y audita el cumplimiento.
3. Public knowledge ≠ verificación. Cualquier «secret question» derivada de información que cualquier breach data aggregator puede vender está rota desde 2023. Tu helpdesk no puede verificar identidad con datos comprables online.
4. Detection latency es lo que separa M&S de Co-op. Co-op detectó en 24-48 horas y contuvo. M&S detectó en 5+ días y perdió £300M. La diferencia operativa no está en la prevención inicial sino en la rapidez con la que el azul reconoce el patrón post-acceso.

Referencias

• M&S Group, comunicado público de Stuart Machin (25-abr-2025): https://corporate.marksandspencer.com/media/press-releases/2025/cyber-incident
• NCSC UK, Incidents impacting retailers — recommendations from the NCSC (8-may-2025): https://www.ncsc.gov.uk/blog-post/incidents-impacting-retailers
• Microsoft Threat Intelligence, Octo Tempest (referencia operativa): https://www.microsoft.com/en-us/security/blog/2023/10/25/octo-tempest-crosses-boundaries-to-facilitate-extortion-encryption-and-destruction/
• Mandiant, perfil UNC3944 / Scattered Spider (actualizado 2025): https://cloud.google.com/blog/topics/threat-intelligence/unc3944-targets-saas-applications
• Cyber Monitoring Centre, M&S + Co-op classified as single combined cyber event (julio 2025): https://cybermonitoring.org/cmc-reports/2025-uk-retail-event
• BleepingComputer, Deep dive into DragonForce ransomware and its Scattered Spider connection: https://www.bleepingcomputer.com/news/security/deep-dive-into-dragonforce-ransomware-and-its-scattered-spider-connection/
• BBC News, cobertura del incidente M&S con detalle del vector helpdesk (mayo 2025): https://www.bbc.co.uk/news/business-cyber
• Computer Weekly, M&S suspends all online sales as cyber attack worsens (25-abr-2025): https://www.computerweekly.com/news/366623085/MS-suspends-all-online-sales-as-cyber-attack-worsens
• The Hacker News, Scattered Spider Behind Cyberattacks on M&S and Co-op (junio 2025): https://thehackernews.com/2025/06/scattered-spider-behind-cyberattacks-on.html
• CISA, Scattered Spider Joint Advisory AA23-320A (actualización 2025): https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a