Amplificando Vulnerabilidades con IA

amplificando vulnerabilidades con IA

A pesar del título, este no es un post sobre una nueva técnica de explotación, ni sobre un exótico zero-day, ni un método de hacking que vas a poder probar en tu próximo CTF. Es una invitación a repensar cómo gestionamos riesgo en una era donde el atacante ya no necesita explotar tu zero-day, le basta con un titular bien escrito y una IA con buena prosa.

Pasa más seguido de lo que nos gustaría admitir. Una empresa puede tener parcheo al día, MFA en todo, SOC 24/7, ISO 27001, SOC 2, lo que quieras. Y aún así perder cientos de millones en valor de marca en 72 horas. ¿La razón? El atacante moderno ya no compromete servidores. Compromete la narrativa.

Y la narrativa, hoy, es escalable.

El experimento que me puso a pensar

A finales del año pasado, un equipo de la Universidad Ludwig-Maximilians de Múnich publicó algo (Kennedy, Parker, Liu y Schütze) que me dejó dándole vueltas durante semanas. Tomaron la misma noticia y la metieron en 9 modelos LLM con cuatro instrucciones distintas: fiel al original, centrista, con orientación de izquierda y con orientación de derecha.

Resultado: con un único prompt, los modelos generan versiones marcadamente sesgadas del mismo hecho. La técnica funciona.

Y si funciona con orientación política, funciona con narrativa hostil contra una marca. Misma mecánica, distinto vector.

Esa fue la chispa. Si una IA puede reescribir un hecho con la inclinación que le pidas, ¿qué le impide reescribir el reporte de un hallazgo trivial como una crisis de seguridad? Spoiler: nada.

Ser seguros y parecerlo no son lo mismo

Aquí va una distinción que en la mayoría de organizaciones nadie hace explícita.

Ser seguros es lo que el CISO le reporta a la junta. Parches, controles, MFA, monitoreo. Lo mide la auditoría: ISO, SOC 2, un pentest, un informe de cumplimiento. Es el piso obligatorio.

Parecer seguros es otra cosa. Es lo que ven los clientes cuando googlean tu marca. Lo que dicen los medios y las redes. Lo que aparece indexado en buscadores cuando alguien escribe el nombre de tu empresa al lado de la palabra *”hackeo”*. Esto no lo mide la auditoría. Lo mide el mercado: clientes que se van, contratos que no se firman, valor de marca que cae.

Y la trampa: una organización puede estar al 100% del lado izquierdo (técnicamente blindada) y al mismo tiempo estar perdiendo en el lado derecho. O al revés: estar muy bien en relaciones públicas y tener el motor en llamas por dentro.

El orden importa, porque esto no es teatro de seguridad: primero ser, después parecer. Nunca al revés. Parecer seguros sin serlo no resiste la más mínima revisión, y mucho menos una crisis real. Lo que estoy planteando es que ser seguros ya no alcanza. Hay que poder evidenciarlo en cualquier momento, no solo en la víspera de la auditoría externa.

Las medias y bajas también cuentan

Durante años, los equipos de seguridad priorizamos por severidad: lo crítico primero, lo alto después, las medias y bajas casi siempre quedan en backlog. Tenía sentido cuando el atacante necesitaba explotar la vulnerabilidad para causar daño.

Pero el atacante moderno no quiere explotar. A veces solo quiere mostrar. Y la IA cambió radicalmente lo que se puede hacer con material de severidad baja.

El pipeline es así:

low technical severity + AI amplification = high perceived severity

El resultado es la fórmula que cierra todo este planteo: severidad técnica baja + amplificación con IA = severidad percibida alta. Y la severidad percibida es la que mueve clientes, acciones y reguladores.

Daño sin falla: tres casos reales

Para no quedarme en lo abstracto, tres casos de los últimos años. En los tres, el reclamo fue público, masivo y verificablemente falso. Y en los tres, la marca atacada tuvo que defenderse igual.

Caso 1 — Europcar (enero 2024): el caso paradigmático

Un actor anónimo apareció en un foro de hacking ofreciendo vender los datos de 48.6 millones de personas supuestamente robados de Europcar, la empresa europea de alquiler de autos. Una brecha de ese tamaño habría sido una de las mayores del año.

Europcar respondió rápido y con precisión técnica: la “muestra” de datos publicada estaba claramente fabricada. Tras verificación interna y consulta con servicios de threat intelligence, la compañía confirmó públicamente que el anuncio era falso.

Pero el daño narrativo ya había arrancado. Y aquí va la cita que define el momento, recogida por Dark Reading: gracias a las nuevas herramientas que aprovechan IA y machine learning, falsificar datos supuestamente robados es más fácil que nunca, dejando a los humanos la tarea de fact-checking y de frenar la propagación.

Este es el caso paradigmático del riesgo nuevo: una crisis pública sin un incidente real detrás, construida con datos sintéticos que parecen auténticos.

Caso 2 — Colonial Pipeline (octubre 2023): cuando el atacante se monta sobre tu historia previa

En octubre de 2023, un grupo apareció en Telegram afirmando haber tomado “control total” de los sistemas de Colonial Pipeline, con enlaces de torrent supuestamente con backups exfiltrados. Colonial confirmó horas después que las afirmaciones eran infundadas.

Pero el truco está en el nombre. Colonial Pipeline había sufrido en 2021 una brecha real famosísima — la que paralizó el suministro de combustible en la costa este de Estados Unidos y forzó al gobierno a declarar emergencia. Esa cobertura de 2021 quedó en la memoria pública. Cuando alguien busca *”Colonial Pipeline hackeada”*, esa historia sigue en primera página.

El atacante de 2023 se apoyó en eso. La gente recuerda *”Colonial Pipeline = hackeada”* y no necesita verificar mucho más. Colonial tuvo que volver a desmentir algo que para muchos lectores ya era verdad por inercia histórica.

Esto agrega una dimensión nueva al problema: las víctimas anteriores son blanco más fácil. Si te pasó una vez, los próximos reclamos parecen más creíbles aunque sean falsos. La narrativa pública trabaja a favor del atacante.

Caso 3 — Dollar Tree (julio 2025): cuando ni siquiera son tus datos

INC Ransom reclamó haber comprometido a Dollar Tree, una de las cadenas de retail de descuento más grandes de Estados Unidos. Publicaron muestras de datos.

Dollar Tree investigó y respondió con un giro inesperado: los datos eran reales, pero no eran suyos. Pertenecían a 99 Cents Only Stores, una cadena de descuento competidora que se había declarado en bancarrota y cerrado el año anterior. El atacante había confundido (o quiso confundir) marcas similares del mismo sector.

Dollar Tree tuvo que defenderse de una brecha que ni siquiera era suya. 99 Cents Only no podía defenderse (ya no existe).

Y esto suma otra dimensión más al problema: el atacante puede dañar tu marca con datos que ni siquiera son tuyos, simplemente porque tu marca es más conocida que la del verdadero origen. La asimetría es brutal: a Dollar Tree le costó tiempo, atención mediática y comunicación corporativa demostrar que era una confusión. A ti te puede pasar mañana.

El patrón en los tres casos

En los tres, ninguna falla técnica. En los tres, un reclamo público y masivo. En los tres, la víctima tuvo razón en el desmentido. Y en los tres, el daño narrativo igual ocurrió: cobertura mediática, ansiedad de clientes, ruido en redes, indexado permanente en buscadores.

La defensa aquí no es técnica (sus infraestructuras estaban bien). La defensa es comunicacional y rápida: monitoreo de menciones en foros y dark web, capacidad técnica para verificar autenticidad de datos en pocas horas, vocero técnico disponible, declaración pública precisa, y un playbook narrativo pre-aprobado. Si eso no está listo, pierdes esa pelea aunque tu infraestructura sea perfecta.

Pero, ¿qué pasa cuando sí fallaste?

Hasta acá hablamos del daño cuando no hay incidente real. Pero hay otro extremo del problema, completamente distinto, y vale la pena nombrarlo con la misma seriedad: cuando sí hubo una falla, y la rendición de cuentas pública es legítima.

El caso que mejor ilustra esto es RIBridges, el sistema de servicios sociales del estado de Rhode Island operado por Deloitte. En diciembre de 2024 sucedió algo muy distinto a los tres anteriores. Aquí no hay reclamos sin sustento ni narrativa exagerada. Aquí hay una falla real, y conviene nombrarla con la gravedad que tiene.

• El acceso fue por una VPN de no-producción que tenía conectividad hacia datos sensibles. Eso ya es un problema de diseño.
• CrowdStrike, contratado para investigar, encontró que el firewall había generado cientos de alertas durante los 18 días en que se exfiltraron datos. Las alertas no se atendieron.
• 657 mil personas notificadas inicialmente. Y no son cualquier persona: son beneficiarios de programas de bienestar social, mucha gente en situación vulnerable, con datos sensibles expuestos.

Esto no es un detalle técnico menor que la prensa amplificó. Es gestión deficiente con consecuencias proporcionales. Cualquiera de los tres puntos por separado ya es serio. Los tres juntos durante 18 días es negligencia operativa, y de un proveedor cuya promesa de valor es justamente saber gestionar este tipo de sistemas.

Por eso el gobernador del estado señaló a Deloitte por nombre. No fue ruido mediático. Fue rendición de cuentas pública legítima.

Y aquí va lo importante: ningún playbook narrativo te salva. Si fallaste de verdad, lo único que te salva es haber hecho el trabajo bien antes. Y poder demostrarlo.

Dos daños, dos tres escenarios

El daño reputacional viene por dos caminos opuestos. Uno te ataca cuando no fallaste (Europcar, Colonial, Dollar Tree). El otro te expone cuando sí fallaste (RIBridges). Esos son los dos vectores del problema, y la IA amplifica ambos.

Pero el lugar donde la crisis te encuentra no depende solo del atacante. Depende también de tus capacidades. Y ahí aparecen tres escenarios operativos distintos, no dos. El que faltaba es el más común y el peor de todos.

Escenario 1 — Sin falla, con capacidad de demostrarlo. El caso Europcar. Defensa comunicacional rápida sostenida por verificación técnica. Monitoreo de narrativa, playbook comunicacional, voceros técnicos listos, simulacros de crisis, capacidad de verificar autenticidad de datos en pocas horas.

Escenario 2 — Con falla, con capacidad de explicarla. El caso RIBridges. Sin playbook narrativo que valga; lo único que cuenta es haber hecho el trabajo bien antes y poder demostrarlo. Logs, tickets, decisiones firmadas, controles vivos, validación independiente. Cuando el gobernador llama por teléfono, no estás peleando contra una narrativa: estás respondiendo por una falla real. Y la diferencia entre “suenas creíble” y “suenas a excusa” la marca la evidencia auditable que construiste antes.

Escenario 3 — Sin saber en qué escenario estás. El agujero negro.

Suena el teléfono, pregunta el periodista, y la respuesta interna honesta no es *”es falso”* ni *”es real”. Es *no lo sabemos**. No lo sabemos porque los logs del sistema afectado tienen retención de 7 días y el supuesto incidente fue hace dos meses. No lo sabemos porque ese activo no estaba en el inventario actualizado. No lo sabemos porque la telemetría nunca cubrió esa pieza. No lo sabemos porque jamás corrimos un ejercicio de threat hunting sobre ese tipo de ataque. No lo sabemos porque las capacidades para responder con certeza nunca se construyeron.

Y “no lo sabemos” es la peor posición de las tres. Peor que Europcar, donde puedes desmentir con datos. Peor incluso que RIBridges, donde al menos puedes mostrar que conoces el alcance y estás respondiendo. En el vacío, el titular del atacante gana por default. Cualquier silencio se interpreta como confirmación. Cualquier evasiva alimenta el titular. Cualquier intento de ganar tiempo se traduce en *”la empresa no responde”*.

Pero hay un costo aún más concreto, que muchas veces se subestima en estas conversaciones. Cuando no podemos determinar si fuimos comprometidos o no, la decisión defensiva por defecto suele ser bajar la palanca: apagar sistemas, aislar redes, suspender servicios hasta poder asegurar que el ambiente está limpio. Y eso, en una organización moderna, significa parar operaciones. Significa ventas perdidas por hora, SLAs incumplidos con clientes, contratos en riesgo, equipos enteros sin poder trabajar. El “no saber” deja de ser un problema de comunicación y se convierte en pérdida medible en estados financieros. Y peor: la prensa que ahora cubre por qué estás apagado, los clientes que reciben notificaciones de servicio interrumpido, los reguladores que empiezan a hacer preguntas sobre tu nivel de preparación. El daño reputacional se multiplica, y la responsabilidad regulatoria se vuelve concreta. Lo que empezó como una llamada de un periodista termina como una crisis operativa, financiera y de cumplimiento al mismo tiempo.

La crisis pública no genera la deuda técnica. Solo la expone, en horas, después de años de acumulación. Y ese es el verdadero examen al que la mayoría de organizaciones todavía no se ha sentado: ¿podríamos hoy, si llamaran ahora, responder con certeza a la pregunta básica de qué ocurrió en nuestros sistemas durante un período determinado? Si la respuesta sincera es *”depende del sistema”* o *”tendríamos que averiguar”*, el problema reputacional es solo cuestión de tiempo.

¿Y por qué este escenario no aparece en los titulares si es el más común? Porque las organizaciones que lo atraviesan no salen a hablar. No pueden. Algunas empresas también podrían estar en este escenario sin saberlo todavía, descubriéndolo solo cuando un periodista pregunta por un activo que nadie tiene mapeado, por un sistema cuyos logs vencieron, o por un incidente del que no quedó traza. Algunas podrían responder a la llamada con silencio prolongado mientras internamente intentan reconstruir lo que pasó — y ese silencio, en la era de las redes y la IA generativa, se interpreta como confirmación. Algunas podrían llegar a pagar acuerdos extrajudiciales o asumir el daño reputacional sin pelear, simplemente porque no tienen con qué defenderse. Y otras podrían terminar emitiendo declaraciones genéricas que ni confirman ni niegan, optando por aguantar el ciclo mediático en lugar de defender una postura que no pueden sostener con datos. Ninguno de esos desenlaces aparece en los reportes de ransomware ni en las estadísticas de brechas, porque no son brechas — son fallas de capacidad expuestas. Pero el costo lo paga la organización igual.

Por qué funciona: el cerebro humano

Esto no funciona porque la IA sea mágica. Funciona porque nuestro cerebro está cableado para que funcione. El sesgo de negatividad y la velocidad de difusión de noticias falsas están bien documentados (Cacioppo, Hanson; Vosoughi et al., MIT, Science 2018): la amígdala se obsesiona con lo negativo, el reflejo social premia lo novedoso, y las noticias falsas viajan mucho más rápido que las verdaderas. Un titular alarmante sobre tu marca, generado por IA, cumple las dos condiciones perfectamente.

El atacante no necesita engañar a tu organización. Aprovecha cómo está cableado el cerebro de quien lee la noticia.

Los números confirman

Por si alguien todavía cree que esto es discurso futurista, algunos datos sólidos del último año:

• 82.6% de los emails de phishing analizados ya muestran señales de generación con IA (KnowBe4 / SlashNext, 2025).
• 11 minutos de tiempo medio entre la detección de un dato expuesto y el primer intento de explotación automatizada (comparado con horas o días en la era pre-IA).
• USD 200M+ en pérdidas reportadas por fraude con deepfakes solo en Q1 2025 en Estados Unidos (FinCEN, Wall Street Journal).

Hay otras cifras circulando (“+1265% en phishing post-ChatGPT”, “+680% en voz clonada”) que vienen mayormente de reportes de vendors con metodología poco transparente. Las uso con cautela y prefiero quedarme con las que tienen método verificable. Pero el patrón es claro incluso conservadoramente: la IA no inventó el ataque. Lo abarató, lo masificó y lo aceleró.

¿Y si la noticia llega a un medio serio?

Esta es la pregunta que más miedo debería darnos, y aplica para los dos tipos de daño. Son las 9 AM. Un diario nacional (o una agencia de noticias) recibe un correo: capturas de pantalla, un archivo de “muestra”, el enlace al post del foro dark donde alguien dice tener un terabyte de datos suyos. O un dato filtrado de un incidente real. El periodista cubre tecnología pero no es de ciberseguridad. No distingue entre brecha real y reclamo. Está convencido de tener una primicia. Quiere publicar hoy.

Y acá está el cambio cualitativo. Antes podíamos ver noticias falsas en la prensa amarilla, no en la seria, porque los medios serios tenían un proceso de verificación humano que filtraba lo más burdo. En la era de la IA, ya no es novedad ver noticias falsas presentadas como serias. ¿La razón? El periodista, por más profesional que sea, simplemente no tiene las herramientas perceptivas para distinguir un video real de uno generado por IA. Lo mismo aplica al audio clonado, al screenshot fabricado, al PDF con membrete falso. La línea defensiva que tradicionalmente separaba al medio serio del tabloide se corrió, y el atacante lo sabe.

Cinco cosas pasan al mismo tiempo:

• El medio le da credibilidad institucional al rumor o al hecho.
• El periodista no tiene marco para distinguir reclamo de brecha confirmada — ni herramientas para detectar contenido sintético.
• Las capturas, archivos, audios y videos parecen evidencia.
• El plazo editorial corre más rápido que el plazo legal.
• Una vez publicado, otros medios replican sin verificar.

¿Cuántos de ustedes tienen un protocolo, hoy, para esa llamada de las 9 AM?

El checklist antes de comunicar

Antes de hablar con el periodista, antes de redactar la declaración, antes de notificar a clientes, hay una pregunta que tienes que poder responder con un sí. ¿Tienes la evidencia para sustentar lo que vas a decir?

Y atención al matiz: el checklist sirve para los dos tipos de daño. Si es un caso tipo Europcar (no fallaste), la evidencia te permite sostener tu defensa con datos verificables y demostrar que la “muestra” del atacante es falsa. Si es un caso tipo RIBridges (sí fallaste), la evidencia te permite mostrar que conoces el alcance, que estás respondiendo, y que no estás improvisando. En ambos casos, sin evidencia, cualquier respuesta pública es una declaración sin respaldo. Y una declaración sin respaldo es la mejor manera de convertir un incidente en una crisis cuando la versión empieza a contradecirse con los hechos.

• Logs del sistema afectado, conservados y accesibles.
• Ticket de gestión con responsable asignado.
• Decisión y aprobador trazables (quién, cuándo, por qué).
• Estado de parches y controles al momento del incidente.
• Comunicaciones internas documentadas durante la respuesta.
• Validación independiente (pentest reciente, auditor, SOC).

Si no puedes mostrar evidencia de cómo se gestionó algo, para fines prácticos no se gestionó. La buena gestión de ciberseguridad no se declara: se evidencia.

Ignorarlo o gestionarlo

El riesgo reputacional por IA es real, está cuantificado y está creciendo. La pregunta no es si nos afecta. Es qué vamos a hacer al respecto. Y solo hay dos respuestas posibles.

Ignorarlo significa esperar al primer incidente, asumir que a nosotros no nos toca, reaccionar improvisando bajo presión cuando suene el teléfono a las 9 AM. Costo cuando ocurre: incalculable.

Gestionarlo significa preparar la evidencia auditable hoy, construir el playbook antes de necesitarlo, entrenar voceros técnicos, simular crisis. Costo de la inversión: planificable.

Ignorarlo también es una decisión, aunque la organización no la haga consciente. La omisión es decisión. La pregunta es si queremos que sea explícita o por defecto.

Tres frentes para mañana

Si todo lo anterior se reduce a algo accionable el lunes a las 9 AM, son tres frentes. En este orden.

1. Evidencia auditable, continua y a la mano.
Logs, tickets, parches, decisiones aprobadas con quién y cuándo, validación independiente. Disponible en cualquier momento, no solo en la víspera de la auditoría externa. Cuando llamen, lo único que distingue una respuesta creíble de una excusa improvisada es la evidencia que hayas construido antes. Esto es la base. Sin esto, el resto es decoración.

2. Entrenar, entrenar y entrenar.
Table tops periódicos para los tres escenarios: el reclamo falso amplificado (tipo Europcar), la falla real expuesta (tipo RIBridges) y (el más incómodo) el escenario donde no podemos responder con certeza si fallamos o no. Y no solo el equipo técnico, también comunicaciones, legal y dirección. Las cuatro funciones, juntas, en el simulacro. Practicar cómo suena el vocero técnico al teléfono con un periodista a las 2 AM. Practicar cómo se redacta la declaración en 90 minutos. Practicar quién decide qué, sin esperar al comité. Y practicar qué hacer cuando ni nosotros mismos sabemos lo que pasó. Lo que no se entrena, no se ejecuta bajo presión.

3. Repensar la priorización en sistemas expuestos.
La criticidad sigue mandando, esto no es “parchar todo”, eso es inviable y nadie lo va a hacer. Pero las vulnerabilidades medias y bajas en activos expuestos a internet tienen que empezar a subir en la cola de remediación. Por dos razones que se acumulan:

• Riesgo reputacional inmediato. Son la materia prima que un atacante necesita para construir una media verdad amplificable. Sin un insumo verificable mínimo, el atacante tiene que inventar puro, y lo puro es más fácil de desmentir. Cerrar las medias y bajas expuestas le quita munición a la narrativa hostil antes de que se escriba.
• Riesgo operativo creciente. El tiempo juega para el atacante. Esa media o baja olvidada en backlog tiende a encadenarse, reweaponizarse o acumularse con otras hasta convertirse en el vector de un compromiso real. Lo que hoy es CVSS 4.3 (information disclosure) mañana puede ser el primer eslabón de una cadena que termina en RCE.

La inversión es la misma. El retorno es doble: protege del titular hostil hoy y del compromiso técnico mañana.

Sé que esto cuesta. Construir capacidades de evidencia continua, monitoreo de narrativa y simulacros cruzados no es gratis, y muchas áreas de seguridad están peleando por presupuesto base, no por presupuesto nuevo. Pero el costo de la primera crisis sin esto es órdenes de magnitud mayor, y ese cálculo, traducido a impacto en valor de marca, en pérdida de contratos, en horas de directorio y en pago de asesoría legal externa, es la conversación que vale la pena tener con el CFO antes de que la llamada del periodista la abra por nosotros.

Lo que tenemos que repensar

Y acá está la conclusión incómoda. Si lo anterior tiene sentido, entonces los tiempos típicos de remediación ya no nos sirven. Pues esos SLAs fueron diseñados para una era donde el atacante era exclusivamente técnico y necesitaba explotar para causar daño.

El atacante moderno no opera con esos tiempos. Arma una campaña narrativa amplificada por IA en horas. Y mientras esperamos el ciclo de parcheo del próximo mes o trimestre, esa misma vulnerabilidad puede aparecer en un titular pasado mañana.

Vamos a tener que repensar dos cosas a la vez:

• Cómo remediamos. Procesos, ciclos, automatización. Más rápido, con menos fricción operativa.
• Cómo priorizamos lo expuesto. Un nuevo factor en la matriz: visibilidad pública del activo. No para reemplazar CVSS, sino para complementarlo.

Una dirección, no una receta cerrada: para activos expuestos a internet con materia prima narrativamente útil (subdominios públicos, repositorios accesibles, endpoints que devuelven errores informativos, integraciones con terceros visibles) las ventanas de remediación tendrían que medirse en días, no en meses, incluso cuando el CVSS sea bajo. Lo que rompe esto no es la severidad técnica del bug. Es la combinación de exposición pública más insumo narrativo plausible. Y esa combinación define una clase de riesgo que las matrices tradicionales no ven.

Las amenazas que vienen ya no son solo técnicas. Son técnicas, narrativas, sociales y de percepción, todas al mismo tiempo. Si seguimos midiendo el riesgo solo con la regla de hace diez años, vamos a llegar tarde a la próxima crisis. Y el próximo titular no espera al sprint del mes que viene.

¿Cuántas veces han visto en sus organizaciones esa frase de *”si no es crítico, lo dejamos en backlog”* convertirse en la base de una crisis pública meses después?