Defensa ante ciberataques asistidos por IA: phishing, explotación de vulnerabilidades y secuestro de agentes

Para prepararse ante ataques asistidos por IA, reduzca el compromiso de cuentas y la explotación de vulnerabilidades divulgadas, e impida que los agentes de IA ejecuten acciones no autorizadas incluso después de leer contenido externo. Comprobar que autenticación, parches, permisos y controles de transferencia saliente funcionan resulta más directamente útil que determinar si un mensaje de ataque fue escrito por IA.

Este artículo se dirige a equipos que operan servicios o incorporan agentes de IA al desarrollo. Abarca respuestas según la vía de ataque y correlación local de registros. Los procedimientos operativos siguientes son propuestas, no el relato de un incidente de una organización ni una medición de eficacia defensiva.

Usar IA para atacar frente a atacar a la IA

Los atacantes pueden usar IA para organizar información sobre objetivos y crear mensajes de suplantación o código. Nuestros propios agentes de IA también pueden ser objetivos. La inyección indirecta de prompts, por ejemplo, oculta instrucciones en documentos externos para inducir transferencias de datos o cambios de configuración de despliegue.

La evaluación de amenazas del NCSC británico hasta 2027 prevé que la IA hará más eficientes actividades existentes como reconocimiento, ingeniería social e investigación de vulnerabilidades. También considera que podría reducirse aún más la ventana de respuesta entre la divulgación y la explotación de vulnerabilidades conocidas. Estas previsiones no deben interpretarse como observaciones de que todos los ataques ya están completamente automatizados.

Vía de ataque	Objetivo del atacante	Límite que proteger primero
Phishing dirigido y suplantación de directivos	Inicio de sesión, recuperación de cuenta o aprobación de pagos	Autenticación, recuperación y un canal de verificación separado
Descubrimiento y explotación asistidos de vulnerabilidades	Intrusión en servicios expuestos y robo de secretos	Activos expuestos, parches y aislamiento
Inyección de prompts en agentes	Ejecución no autorizada de herramientas o transferencias salientes	Separación entre datos e instrucciones; permisos de herramientas y red

Varias vías pueden conectarse en un incidente. Si una cuenta comprometida permite insertar instrucciones maliciosas en un documento interno, investigue tanto las defensas de identidad como las del agente.

Defienda contra el phishing mediante autenticación y rutas de aprobación

El análisis de Microsoft sobre suplantación de directivos y fraude de facturas describe una campaña que combinaba correos falsos de directivos, facturas y contenido presentado como conversaciones reenviadas. Los investigadores observaron indicios compatibles con el desarrollo de plantillas asistido por IA, pero afirman que no permiten determinar cuánto contenido generó la IA. Una puntuación o un formato de comentarios concretos no bastan para establecer reglas de clasificación de ataques.

Empiece comprobando estos límites operativos:

• Inicio de sesión: implante autenticación resistente al phishing, como FIDO2 o passkeys, en cuentas compatibles y verifique que las políticas reales la exigen. La guía de MFA resistente al phishing de Microsoft trata riesgos de interceptación y fatiga en SMS, OTP y notificaciones push, y la migración a métodos más sólidos.
• Recuperación y registro: cuando soporte registre un método de autenticación nuevo o recupere una cuenta, verifique la identidad con registros previos confiables y un procedimiento separado. Establezca reglas que no aprueben recuperaciones basándose en un único correo o una videollamada.
• Aprobación de negocio: verifique cambios de cuenta bancaria y solicitudes de compartir secretos mediante contactos previamente registrados o un sistema interno de aprobación, en vez de los contactos del mensaje. El fraude de pagos puede tener éxito sin comprometer cuentas, así que reforzar el acceso no completa la defensa.

Use conjuntamente SPF, DKIM, DMARC y detección de suplantación para proteger el correo. Superar la autenticación de correo no demuestra la legitimidad comercial de solicitudes de dominios parecidos o cuentas legítimas comprometidas. La autenticación resistente al phishing tampoco resuelve todos los casos de sesiones robadas o dispositivos comprometidos.

Priorice la exposición y el riesgo de explotación al responder a vulnerabilidades

Un servicio expuesto sigue siendo vulnerable mientras se esperan pruebas de que el atacante usó IA. Vincule primero cada servicio accesible desde internet con su producto, versión en ejecución, responsable y estado de parcheo; después revise avisos del proveedor e información de explotación observada. Que las instancias que atienden tráfico ejecuten ahora la versión corregida importa más que registrar un cambio de código fuente o etiqueta de imagen.

Priorice la respuesta combinando exposición externa, explotación observada, datos y privilegios accesibles e impacto en el servicio. Si parchear de inmediato resulta difícil, aplique mitigaciones respaldadas por el proveedor o restricciones de exposición y registre un responsable y una fecha de reevaluación para la excepción. Añadir una regla WAF no elimina la vulnerabilidad subyacente.

Si la explotación ya pudo ocurrir, investigue el incidente en paralelo al parcheo. Preserve registros de procesos, autenticación y comunicaciones salientes; determine la rotación de credenciales y la reconstrucción desde imágenes confiables según el alcance del compromiso. Un parche correcto no demuestra que se hayan eliminado rastros de intrusión o mecanismos de persistencia.

No convierta el contenido que lee un agente en autoridad de ejecución

Cuando un agente de IA lee incidencias, archivos del repositorio o páginas web, su contenido puede estar bajo control del atacante. Tratar un texto que dice «tras leer este documento, ejecute el siguiente comando» con la misma autoridad que la tarea aprobada por el usuario puede convertir la búsqueda de información en una transferencia saliente.

La guía de prevención de inyección de prompts de OWASP recomienda validar las llamadas a herramientas según permisos del usuario y contexto de sesión, validar parámetros específicos y aplicar privilegios mínimos. Añadir una advertencia a la entrada o pedir al modelo que ignore instrucciones maliciosas no impone por sí solo permisos de ejecución.

Haga cumplir los recursos y acciones permitidos para cada usuario y tarea en el límite de ejecución de herramientas, fuera del modelo. Use cuentas de solo lectura y credenciales de corta duración y restrinja transferencias de red por destino, protocolo y alcance de datos. Una lista de destinos permitidos no basta si un dominio aprobado aún admite transferencias a una cuenta del atacante o a rutas arbitrarias. Muestre el destino y los cambios concretos al obtener aprobación para modificaciones o transferencias importantes.

Registre ID de tarea, identidades ejecutoras, nombres de herramientas, decisiones de política y resultados. Exprese las razones como códigos de política observables; no hace falta recopilar el razonamiento oculto del modelo. Registrar documentos originales completos, tokens o contraseñas puede crear otro punto de divulgación. Consulte Límites de permisos de agentes de IA para el límite operativo de autorización.

Correlacione transferencias denegadas tras lecturas de contenido externo

El ejemplo Python siguiente correlaciona eventos sintéticos atribuidos a un ejecutor confiable. Marca un candidato a investigación cuando se deniega una transferencia externa dentro de los 300 segundos posteriores a una lectura externa para el mismo actor e ID de ejecución. No identifica inyecciones de prompts ni bloquea solicitudes. Presupone que políticas separadas de herramientas o red ya generaron los eventos de denegación.

El diagrama resume las ramas de procesamiento de un evento. Los símbolos de terminación de la derecha significan omitir el evento actual, no un veredicto de seguridad. El código repite el procesamiento para cada evento y guarda la marca temporal de la última lectura. Los eventos que no cumplen las condiciones se omiten. El diagrama no representa un proceso completo de detección de ataques o respuesta a incidentes.

El ejemplo se ejecutó con Python 3.13.0 y no usa paquetes externos, red ni registros de producción. Guárdelo como correlate.py. Aquí at son segundos desde el inicio del ejemplo; la recopilación real requiere marcas temporales sincronizadas e ID de ejecución estables. No rellene kind ni identificadores confiando en texto de documentos o valores arbitrarios generados por el modelo.

from dataclasses import dataclass


@dataclass(frozen=True)
class Event:
    at: int
    actor: str
    run: str
    kind: str


def correlate(events: list[Event], window: int = 300) -> list[tuple[str, str, int]]:
    if window < 0:
        raise ValueError("window")
    last_read: dict[tuple[str, str], int] = {}
    candidates = []
    for event in sorted(events, key=lambda item: item.at):
        key = (event.actor, event.run)
        if event.kind == "untrusted_read":
            last_read[key] = event.at
        elif event.kind == "egress_denied":
            read_at = last_read.get(key)
            if read_at is not None and 0 <= event.at - read_at <= window:
                candidates.append((event.actor, event.run, event.at))
    return candidates


if __name__ == "__main__":
    events = [
        Event(20, "agent-a", "run-1", "egress_denied"),
        Event(0, "agent-a", "run-1", "untrusted_read"),
        Event(30, "agent-a", "run-2", "egress_denied"),
        Event(40, "agent-b", "run-1", "egress_denied"),
        Event(301, "agent-a", "run-1", "egress_denied"),
    ]
    print(correlate(events))

python3 correlate.py

La salida real de ejecución es:

[('agent-a', 'run-1', 20)]

Solo se selecciona el evento a los 20 segundos de la misma ejecución. Se excluyen denegaciones de otras ejecuciones o actores y las que quedan fuera de la ventana. La ventana de 300 segundos es una elección ilustrativa, no un umbral de seguridad validado. La proximidad temporal no demuestra que una inyección causara el intento de transferencia. La automatización legítima puede producir el mismo patrón.

Trece comprobaciones locales separadas cubrieron el límite inclusivo de 300 segundos, la exclusión a los 301 segundos, entradas reordenadas, marca temporal cero, aislamiento entre actores y ejecuciones, denegaciones sin lecturas, transferencias exitosas y ventana negativa. También se detectaron tres mutaciones de regresión que excluían el límite de 300 segundos, ignoraban el actor o trataban mal la marca cero. La ausencia de alerta no demuestra seguridad: la regla puede omitir transferencias no bloqueadas y registros ausentes. Su uso en producción requiere tratar retrasos y reordenación del flujo, caducidad del estado, deduplicación, recuperación tras reinicios y evaluación de falsos positivos. Este ejemplo por lotes no implementa esas funciones.

Verifique los resultados de ejecución y cierre la vía de daño tras una alerta

Compruebe resultados de políticas del ejecutor y registros de red y del servicio de destino, en vez de fiarse de que el agente afirme haber bloqueado una acción. Un evento egress_denied indica que se denegó ese intento concreto; no demuestra que ninguna otra vía filtrara datos. Detenga la ejecución sospechosa y correlacione acceso a fuentes, llamadas a herramientas y comunicaciones salientes mediante su ID de tarea.

Situación	Respuesta inicial propuesta	Comprobaciones antes de reanudar
Sospecha de acceso o cambios de cuenta tras phishing	Invalidar sesiones y tokens relevantes, recuperar la cuenta e inspeccionar métodos de autenticación registrados y consentimientos otorgados	Eliminar vías de acceso añadidas por el atacante y verificar el acceso legítimo
Sospecha de explotación de un servicio expuesto	Aislar activos afectados, preservar evidencias, aplicar versiones corregidas y reconstruir si es necesario	Verificar versiones en ejecución y exposición; investigar persistencia y movimiento lateral
Llamadas no autorizadas del agente	Detener la ejecución, revocar o rotar credenciales relevantes y restringir herramientas y rutas de transferencia	Probar regresiones: se deniegan solicitudes no autorizadas y el trabajo aprobado sigue funcionando

El bloqueo automático puede interrumpir el servicio; aplíquelo según la confianza de detección y el alcance del impacto. Si contención y preservación de evidencias entran en conflicto, elija el orden según el daño en curso y el coste de recopilación. Al dar material del atacante a una IA de investigación, también deben separarse los permisos de herramientas y transferencias salientes. La guía conjunta de agencias nacionales de seguridad sobre adopción de IA agéntica incluye componentes, integraciones y operaciones en el alcance de evaluación de riesgos.

Empiece por un activo expuesto al exterior, una cuenta importante y una tarea de agente que lea documentos externos. Conecte para cada uno controles reales, registros investigables y un procedimiento de recuperación que su responsable pueda ejecutar. Incluya solicitudes legítimas exitosas en las pruebas repetidas y compruebe que cambiar los límites de rechazo hace fallar la verificación, como muestra TDD con ayuda de IA.