Arup: $25M via deepfake CFO en videollamada (Hong Kong, febrero 2024)

A finales de enero de 2024, un empleado del equipo de finanzas de Arup en Hong Kong — la consultora británica detrás de la Sydney Opera House — recibe un email del CFO en Londres pidiendo una transacción confidencial. El empleado sospecha phishing; el correo tiene la marca clásica de business email compromise. Plantea sus dudas. Le contestan invitándole a una videollamada con el CFO y otros directivos para confirmar.

El empleado asiste. Reconoce al CFO en pantalla. Reconoce a los otros directivos. Las voces son las que recuerda. La duda se disipa. Tras la llamada ejecuta 15 transferencias por un total de 200 millones de dólares de Hong Kong — unos $25,6 millones — a 5 cuentas bancarias que el “CFO” le ha indicado. La transacción tarda varios días en cuestionarse desde Londres. Cuando Arup contacta a la policía de Hong Kong, el dinero ya se ha movido.

La policía hace pública la cifra en febrero de 2024 sin nombrar a la víctima. Arup confirma que es la empresa afectada el 16 de mayo de 2024, en una declaración a CNN. Es la pieza canónica de social engineering asistido por AI del año.

Lab: el ataque completo no se reproduce contra terceros. Lo que sí se puede hacer — y se hace abajo — es montar el pipeline contra uno mismo (audio + vídeo propio, GPU consumer) para entender latencias, calidad y artefactos detectables; después pasar por un detector y medir tasa de TP/FP. Eso es lab ético y replicable.

Por qué este caso importa

Hasta finales de 2023, el corpus público de deepfakes de alta calidad servía dos casos de uso: entertainment y harassment dirigido. La frase recurrente en presentaciones de awareness era “todavía no hemos visto un BEC con deepfake en vivo a esta escala”. Arup la deja obsoleta en una operación.

La combinación que ejecuta el ataque:

• Reconocimiento previo — LinkedIn y declaraciones públicas del CFO real para perfilar voz, gestualidad, registro lingüístico, contactos directos en la jerarquía financiera.
• Pretexting por email — primer touch con el patrón clásico de “transferencia confidencial urgente” para que la víctima ya esté en el guion cuando llegue la videollamada.
• Deepfake en vivo, no diferido — el CFO y los otros directivos están en la llamada respondiendo en tiempo real. La víctima puede preguntar, los directivos responden coherentemente. La barrera psicológica de “si me responde, es real” se rompe.
• Múltiples participantes simulados — no es uno-a-uno. Hay varios directivos apoyando la decisión. La presión social del grupo trabaja para el atacante.

El detalle que sostiene el ataque no es la calidad técnica del deepfake — los deepfakes de 2024 todavía tienen artefactos detectables si se conoce el formato. Es que la víctima no estaba buscando artefactos. El empleado de finanzas tiene una tarea operativa, no una validación forense. Cuando el CFO en pantalla aprueba, el flujo cognitivo es “confirmado, ejecuto”, no “verifico si esto es deepfake”.

La cadena reconstruida

1. Recopilación pública (semanas-meses previas).
   • LinkedIn + conferencias + entrevistas → modelo de voz del CFO real (Rob Greig en aquel momento) entrenable con un par de minutos de audio limpio. Open-source: ElevenLabs, Tortoise TTS, F5-TTS, Coqui XTTS-v2.
   • Vídeo público + conference talks → modelo de cara para face-swap en tiempo real. Open-source: DeepFaceLab, SimSwap, Live Portrait. Inference en GPU consumer (RTX 4090) a 30 FPS.
2. Email de pretexto (día N).
   • Patrón BEC clásico, language matching del CFO real. Probable LLM-assisted para tono y términos internos.
   • Solicitud de transacción confidencial → trigger psicológico que el empleado va a cuestionar. Es deseable que cuestione, porque la respuesta es la videollamada.
3. Videollamada con deepfakes en vivo (día N+1 o N+2).
   • Múltiples participantes simulados: CFO + 2-3 directivos. Probablemente actores humanos detrás de cada deepfake, no agentes AI autónomos (el caso es enero 2024 — Operator y Computer Use no estaban públicos todavía).
   • Audio en tiempo real con voice cloning. Vídeo con face-swap.
   • Respuestas coherentes con el rol que cada deepfake interpreta.
4. Ejecución (días siguientes).
   • 15 transferencias a 5 cuentas. Fraccionamiento por debajo de límites internos de aprobación per-transacción. Cuentas en Hong Kong, jurisdicción con layering rápido a otras destinaciones.
5. Detección (días-semanas después).
   • Comunicación entre Hong Kong y Londres revela la disonancia. El CFO real nunca pidió la transacción.
   • Arup notifica a la policía de Hong Kong en enero. Disclosure pública en febrero (sin nombrar). Arup nombrada en mayo.

Qué no funcionó (y qué sí habría funcionado)

Lo que falló en los controles de Arup, según declaración pública del propio CIO de la firma:

• Verificación basada solo en canal de comunicación que el atacante controla. El email + videollamada son ambos canal manipulable. No hubo verificación por canal alternativo no controlado.
• Ausencia de doble autorización para transferencias de ese tamaño. $25M se ejecuta con la aprobación del empleado de Hong Kong, sin firma adicional en Londres.
• Fraccionamiento aceptable. 15 transferencias por debajo del umbral de enhanced review — el sistema solo cuestionaba transferencias únicas por encima de cierto valor.
• Trust transitiva en deepfake. El empleado validó porque “el CFO confirmó por vídeo”. El patrón “ver es creer” sigue siendo el default cognitivo, y el control técnico tiene que asumir que ese canal no es fiable.

Lo que habría parado el ataque, en orden de coste decreciente:

1. Out-of-band verification obligatoria para transacciones por encima de umbral. Llamada al CFO real al teléfono personal listado en el directorio interno (no al de la videollamada), o mensaje Slack/Teams a su cuenta real, antes de ejecutar. Cuesta minutos. Habría detectado el ataque en el paso 3.
2. Doble autorización con segregación geográfica. Cualquier transferencia >$1M requiere firma de un segundo aprobador en otra jurisdicción. Estándar en banca; no estaba aplicado en Arup operacionalmente.
3. Time-delay para transferencias de bulk a cuentas nuevas. 24-48h de hold con auto-cancel si la transacción no se confirma por canal alternativo. Habría parado todas las 15 transferencias.
4. Codeword o passphrase compartido para autorización verbal en videollamada. El CFO real y el equipo finance tienen un código rotado mensualmente. El deepfake no lo sabe. Trivial de implementar, poco común en práctica.
5. Banner de awareness técnico en clientes corporativos. “Si te piden transferencia en videollamada, asume deepfake hasta verificación out-of-band”. Cuesta cero. Cambia el default cognitivo.

Lab: pipeline ofensivo y detección, contra uno mismo

El stack reproducible para entender el coste real del ataque (todo open-source, GPU consumer, ~1 día de trabajo):

# 1) Voice cloning — XTTS-v2 (Coqui), 6 segundos de audio limpio
git clone https://github.com/coqui-ai/TTS && cd TTS
pip install -e .
tts --text "Necesito que ejecutes la transferencia hoy mismo" \
    --model_name tts_models/multilingual/multi-dataset/xtts_v2 \
    --speaker_wav samples/mi_voz_6s.wav --language_idx es \
    --out_path clone.wav
# Latencia inferencia: 200-400 ms/frase en RTX 4090
# Calidad: prosodia natural; artefactos detectables solo en sibilantes y respiración

# 2) Face-swap en tiempo real — DeepFaceLive (continuación de DeepFaceLab)
git clone https://github.com/iperov/DeepFaceLive
# Modelo DFM pre-entrenado (200K iter sobre la cara objetivo, ~6h en RTX 4090)
# Inferencia: 25-30 FPS @ 720p en RTX 4090, 10-15 FPS en RTX 3060

# 3) Inyectar el stream en una videollamada (OBS Virtual Camera)
sudo apt install obs-studio v4l2loopback-dkms
sudo modprobe v4l2loopback devices=1 video_nr=10 \
    card_label="Virtual Camera" exclusive_caps=1
# OBS → Source: DeepFaceLive → Start Virtual Camera → seleccionable en Zoom/Teams

# 4) Audio: routear XTTS-v2 al micro virtual con pipewire
pw-loopback --capture-props='node.name=tts-out' \
            --playback-props='node.name=mic-virtual'

Coste total: ~$2000 de hardware, presupuesto de cloud GPU equivalente $5-10 por sesión completa. Acceso técnico al ataque no es la barrera.

Detección — qué falla en tiempo real

Artefactos sistemáticos que persisten incluso en pipelines de 2024-2026:

Implementación mínima de detección con OpenCV + mediapipe que cualquier equipo de seguridad puede tener corriendo contra grabaciones de videollamadas críticas:

# detect_deepfake_blink.py — POC defensivo
import cv2, mediapipe as mp, numpy as np

mp_face = mp.solutions.face_mesh
face = mp_face.FaceMesh(refine_landmarks=True)

# Índices EAR (Eye Aspect Ratio) sobre los landmarks de mediapipe
LEFT_EYE  = [33, 160, 158, 133, 153, 144]
RIGHT_EYE = [362, 385, 387, 263, 373, 380]

def ear(landmarks, idx):
    p = np.array([(landmarks[i].x, landmarks[i].y) for i in idx])
    return (np.linalg.norm(p[1]-p[5]) + np.linalg.norm(p[2]-p[4])) \
           / (2.0 * np.linalg.norm(p[0]-p[3]))

cap = cv2.VideoCapture('callrecording.mp4')
blinks, prev_ear = 0, 1.0
fps = cap.get(cv2.CAP_PROP_FPS); frames = 0

while True:
    ok, frame = cap.read()
    if not ok: break
    frames += 1
    res = face.process(cv2.cvtColor(frame, cv2.COLOR_BGR2RGB))
    if not res.multi_face_landmarks: continue
    lm = res.multi_face_landmarks[0].landmark
    e = (ear(lm, LEFT_EYE) + ear(lm, RIGHT_EYE)) / 2
    if prev_ear > 0.21 and e < 0.21:   # transición ojo abierto → cerrado
        blinks += 1
    prev_ear = e

duration_min = frames / fps / 60
rate = blinks / max(duration_min, 0.001)
print(f"Blink rate: {rate:.1f}/min  ({'SOSPECHOSO' if rate < 6 else 'normal'})")

Sobre vídeo legítimo de 5 min de la misma persona, el rate típico es 10–14/min. Sobre face-swap DFL del mismo speaker, baja a 3–5/min — diferencia robusta.

Servicios SaaS de detección con APIs documentadas: Intel FakeCatcher (proprietary, PPG-based), Reality Defender (multi-modal), Sensity AI (image+video), Hive Moderation (frame-level). Latencia <10 s sobre clip de 30 s. Útil como second opinion en flujos de aprobación, no como gate único.

Lecciones operativas para 2024+

El caso Arup es proof of concept a escala industrial de tres patrones que se van a repetir:

• Identity verification de tier-1 ya no escala con plantilla outsourced + protocolo de tres preguntas. El Marks & Spencer attack de abril 2025 demuestra el mismo punto al revés: el atacante humano se hace pasar por empleado al helpdesk; en Arup, el atacante deepfake se hace pasar por directivo al empleado. El patrón atacante con voz/cara reconocible pide acción privilegiada está roto sin verificación out-of-band.
• Transacciones financieras requieren cadena de confianza fuera del canal. Cualquier proceso que dependa exclusivamente de email + voz + vídeo asume que ninguno de los tres es manipulable. En 2024 los tres lo son.
• Awareness de deepfake como threat awareness primario, no secundario. Los programas de training de awareness 2024-2025 mueven deepfake del bloque “amenazas emergentes” al bloque principal. El caso Arup es la justificación.

Los reguladores se mueven en consecuencia. El EU AI Act Art. 50 (transparencia para deepfakes y AI-generated content) entra en aplicación el 2-feb-2025. FinCEN publica advisory específico sobre deepfake-enabled fraud en noviembre de 2024. La Hong Kong Securities and Futures Commission emite circular en marzo de 2024 — el mes siguiente al caso Arup — exigiendo controles de verificación de identidad para transferencias significativas.

El reporte oficial del CIO de Arup (Rob Greig, declaraciones a CNN/Fortune en mayo de 2024) lo resume en una línea operativa:

“Like many other businesses around the globe, our operations are subject to regular attacks, including invoice fraud, phishing scams, WhatsApp voice spoofing, and deepfakes. What we have seen is that the number and sophistication of these attacks has been rising sharply in recent months.”

La cifra de $25M es el titular. El detalle es que Arup tiene un programa de seguridad maduro, departamento dedicado, controles estándar de la industria. Un atacante con presupuesto de inference GPU + recopilación pública + actores humanos lo salta. La conclusión no es “Arup hizo algo mal” — es “los controles estándar de la industria a finales de 2023 no contemplaban este vector”, y todo equipo que opere transacciones grandes en 2024+ tiene que asumirlo.

Referencias

• CNN Business, Arup revealed as victim of $25 million deepfake scam (16 mayo 2024): https://www.cnn.com/2024/05/16/tech/arup-deepfake-scam-loss-hong-kong-intl-hnk
• Fortune, A deepfake ‘CFO’ tricked British design firm Arup in $25 million scam (17 mayo 2024): https://fortune.com/europe/2024/05/17/arup-deepfake-fraud-scam-victim-hong-kong-25-million-cfo/
• CNN, Finance worker pays out $25 million after video call with deepfake CFO (4 febrero 2024, sin atribución a Arup): https://www.cnn.com/2024/02/04/asia/deepfake-cfo-scam-hong-kong-intl-hnk
• World Economic Forum, Cybercrime: Lessons learned from a $25m deepfake attack (febrero 2025 retrospec): https://www.weforum.org/stories/2025/02/deepfake-ai-cybercrime-arup/
• FinCEN, Deepfake-Enabled Fraud Advisory FIN-2024-Alert004 (13 noviembre 2024).
• Hong Kong SFC, Circular on Deepfake-Enabled Fraud (marzo 2024).
• Reglamento (UE) 2024/1689 Art. 50 — transparencia para AI-generated content.