Cómo red-team un flujo de Business Email Compromise con IA sin exponer buzones reales ni enseñar a atacar producción

Paso 1 — Construye un buzón completamente sintético con relaciones creíbles. Crea identidades ficticias, proveedores inventados, facturas sin valor real, calendarios y conversaciones que representen el negocio sin copiar datos de empleados o clientes. Incluye jerarquías, aprobaciones y algunos mensajes irrelevantes para que el ejercicio tenga contexto. Marca por separado la verdad del escenario: quién aprueba pagos, qué cuenta bancaria es válida y qué cambios deberían considerarse sospechosos. El objetivo no es producir una demo cinematográfica, sino un dataset seguro donde podamos medir qué información puede inferirse. Usa dominios reservados, identidades no resolubles y ningún secreto real. El entorno debe ser imposible de confundir con producción incluso si un componente intenta seguir un enlace.

Paso 2 — Define únicamente objetivos defensivos de observación. La prueba puede preguntar qué roles, relaciones y tipos de información son visibles en el buzón, sin pedir instrucciones para comprometer cuentas reales ni explotar sistemas externos. Simula que la sesión ya está dentro del entorno y mide cuánto tarda un analizador en identificar procesos de alto riesgo. Registra consultas, mensajes leídos y señales generadas. Esta estructura permite comprender el problema post-compromiso sin convertir el laboratorio en una guía de intrusión. También ayuda a privacidad: podemos descubrir qué categorías de datos deberían retenerse menos tiempo o separarse mejor, porque vemos cuánto valor estratégico entrega el correo cuando se agrega automáticamente.

Paso 3 — Inyecta controles de identidad y detección dentro del escenario. Modela una sesión nueva con patrones anómalos, acceso masivo a conversaciones antiguas o cambios de aplicación autorizada y comprueba qué señales generan los controles. No necesitas reproducir técnicas ofensivas contra proveedores reales. Basta un event stream sintético que represente autenticación, tokens y acceso. Define tiempos: detección, revocación y confirmación. Una defensa madura debe ser capaz de revocar todas las sesiones de la identidad y no solo cambiar una contraseña ficticia. El ejercicio muestra si el runbook contiene pasos completos y si la organización sabe quién puede ejecutarlos sin esperar aprobaciones confusas durante un incidente.

Paso 4 — Crea una transacción señuelo y exige un segundo canal. Introduce una conversación donde parece razonable cambiar datos de pago o solicitar una transferencia. El sistema puede preparar la acción, pero el workflow debe bloquear cualquier ejecución hasta recibir confirmación desde una identidad o canal independiente del buzón. En el laboratorio, esa confirmación puede ser un token firmado por un servicio de simulación. Mide si el agente respeta el bloqueo incluso cuando el contenido del correo es convincente. Este es el corazón de la prueba: demostrar que comprender un inbox no equivale a autoridad financiera. Si el mismo contexto puede generar la solicitud y aprobarla, el diseño falla aunque la detección de phishing sea excelente.

Paso 5 — Puntúa consecuencia evitada y tiempo, no calidad del mensaje fraudulento. Las métricas útiles son cuánto contexto crítico quedó expuesto, cuánto tiempo tardó la detección, si se revocaron sesiones, cuántas acciones sensibles pidieron verificación externa y si alguna consecuencia cruzó el límite. No necesitas evaluar qué tan persuasivo fue el copy del atacante. Eso desvía el ejercicio hacia contenido ofensivo. También registra falsos positivos: un control que bloquea cada factura legítima será ignorado. Repite con diferentes roles y volúmenes de correo. El objetivo es encontrar una arquitectura robusta bajo variación, no una única historia de incidente que todos aprenden a superar después del primer ensayo.

Paso 6 — Convierte hallazgos en cambios de proceso y vuelve a ejecutar. Cada brecha observada debe producir una acción concreta: reducir retención, limitar scope de un conector, acelerar revocación, registrar un canal secundario o cambiar el workflow financiero. Después repite exactamente el escenario para comprobar que el riesgo disminuyó. Guarda un BECsimulationreceipt con dataset, versión de políticas, métricas y outcome. En Goatify, este playbook puede convertirse en un assessment vendible para clientes con correo conectado a agentes. La demo no necesita atacar nada real. Mostramos cómo una IA extrae contexto de un entorno ficticio y, más importante, cómo el sistema impide que ese conocimiento se transforme en una transferencia o cambio irreversible.