Víctor José González Arcos

La IA está acelerando los ciberataques. Para quienes los investigamos, el desafío ya no es solo averiguar qué ocurrió, sino ganar tiempo para impedir que el atacante siga intensificando su ataque. ______ A las 03:12, el equipo da por terminada la intervención. Ha aislado un servidor comprometido, preservado las pruebas disponibles y restaurado una copia anterior al ataque. El sistema funciona de nuevo. A las 03:47 salta otra alerta: desde el mismo servidor vuelve a establecerse una conexión sospechosa explotando ágilmente la misma vulnerabilidad. Otra vez. La escena, aunque anonimizada, plantea un problema muy conocido. La restauración ha devuelto el equipo a su estado anterior, incluida la vulnerabilidad que permitió la entrada, todavía sin dar tiempo a parchear. Todo apunta a que fuera de la organización continúa funcionando una operación automatizada que puede intentarlo de nuevo sin temor (o conciencia) de haber sido descubierto, con la única finalidad de no desviarse del objetivo que tiene fijado. Donde antes, un atacante se iría con su botín una vez sido descubierto, o probaría nuevos métodos para volver a un modo de sigilo, nuestros nuevos adversarios no “sienten” ni el pudor ni el miedo que sólo está reservado para las personas. De ahí una distinción básica, y a menudo olvidada: recuperar el servicio no equivale a expulsar al atacante. Antes de dar por cerrado el incidente hay que saber por dónde entró, qué credenciales quedaron expuestas y encontrar antes de ser utilizadas, todas sus posibles persistencias (o vías de entrada alternativas). Sin olvidar preservar las evidencias que permitan reconstruir lo sucedido. De lo contrario, sólo hemos contribuido a arreglar el síntoma, pero no el problema. Recuperar el servicio no significa haber expulsado al atacante. El ataque puede empezar mucho antes de la primera alerta En los últimos meses de 2026, durante un análisis de material filtrado, hemos examinado proyectos de reconocimiento de objetivos basados exclusivamente en Inteligencia Artificial. Este autor de los scripts (o autores) claramente no estaba centrada en una sola compañía. Reunía datos de multitud de organizaciones, principalmente de España, Alemania e Inglaterra, alguna del sector retail, pero muchas del sector salud, ¿qué inventariaban? servicios expuestos visibles desde internet, los nombres de usuarios de esas organizaciones, las posibles contraseñas conocidas, cartera completa de posibles clientes, entre otros. Para ello se observaron centenares de scripts, algunos de Github, otros propios, preparados para cada tipo de dato a extraer y scripts para abusar de esas tecnologías expuestas de cada organización. Parte de lo analizado estaba escrito en caracteres cirílicos, una vez más. Es un indicio, pero no una atribución, pues este sistema de escritura se utiliza en varias lenguas y no identifica por sí mismo ni a un país ni a los responsables de esa actividad. En aquellos inventarios convivían datos de fuentes abiertas con información procedente de filtraciones. Conviene separarlos: no son lo mismo. Lo novedoso era verlos reunidos, relacionados y organizados para estudiar muchos objetivos a la vez. La IA sin lugar a dudas, está acelerando con gran amplitud este trabajo, y en todas sus etapas. La pregunta, entonces, cambia. Cuando alguien consigue entrar en una red y parece moverse por ella con gran sigilo y soltura, ¿cuánto había investigado antes? La respuesta probablemente variará según el momento en el que se formulase: al principio respondería que llevarían varios meses, hace un año este tiempo duraba escasas semanas, a día de hoy estamos viendo que este tiempo se ha reducido a pocas horas. La IA acelera la recopilación y el cruce de información para estudiar muchos objetivos a la vez. Siete minutos, cientos de acciones En este último trimestre de 2026 hemos estudiado, dentro de un incidente que nos tocó responder, cómo un atacante comprometía todas las credenciales de la organización en menos de siete minutos desde su intrusión inicial. No es una media estadística, ni ese dato por sí solo prueba que hubiera una IA ejecutando todas las acciones. Pero sí constata la tendencia de los ataques actuales y la consiguiente gran preocupación sobre el estrecho margen que estos veloces y certeros ataques dejan a las empresas para detectarlos y contenerlos. Las cifras públicas ayudan a ponerlo en contexto. Según CrowdStrike, durante 2025 los atacantes de ciberdelincuencia tardaron una media de 29 minutos en pasar del primer equipo comprometido a realizar con éxito el primer salto de máquina; el caso más rápido observado fue de 27 segundos. Este tiempo para saltar de una máquina a otra se le conoce como tiempo de “movimiento lateral” o breakout. Tampoco demuestra por sí sólo el uso de IA. Lo que muestra es que la defensa puede llegar cuando el ataque ya ha avanzado. A esa velocidad de ataque se suma el volumen de nuevos datos a analizar. Nos hemos encontrado en otro incidente, con investigaciones que exigían revisar centenares de scripts, ¡por máquina! y distintos de los hallados en otras máquinas del mismo incidente, lo que sugiere una rápida adaptación por parte del atacante en función de los servicios que se iba encontrando en cada una de esas máquinas. Esta gran cantidad de scripts observados no basta con analizar cada uno por separado: hay que relacionarlos, averiguar cuáles se ejecutaron, con qué permisos y qué resultado tuvieron. Y hacerlo mientras el incidente todavía sigue activo y el atacante va borrando su rastro. La velocidad del ataque y el volumen de acciones reducen el margen para detectar, investigar y contener. Por no mencionar las sospechas de que ese ataque podría haber venido de una red empresarial cercana, y las evidencias confirmadas de haber saltado a una nueva red con relación a la de nuestro incidente. Esta capacidad para adaptarse, moverse entre entornos y generar nuevas herramientas con aparente gran velocidad es, probablemente, una de las características más relevantes de los incidentes a los que nos enfrentaremos en los próximos años. Otra tendencia, también poco habitual hasta este año, es encontrar varias formas de exfiltración en paralelo sobre una misma máquina, una detrás de otra. Que una falle no significa que se haya detenido la operación, lo importante es alcanzar el objetivo fijado. No sabemos, solo por observar ese comportamiento, si detrás había varios agentes de IA, un único sistema de IA o una simple automatización convencional. Lo importante es el efecto: múltiples caminos abiertos simultáneamente, centenares de scripts por analizar y apenas tiempo para reaccionar. Nuestras herramientas forenses siguen siendo eficaces, pero fueron diseñadas para otra escala de trabajo y, en cierto modo, para una época menos voraz. Lo que ya se ha documentado Hay investigaciones públicas que muestran hasta dónde puede llegar esa automatización. En noviembre de 2025, Anthropic describió una campaña de espionaje en la que, según su propia estimación, Claude Code realizó entre el 80 % y el 90 % de las tareas operativas. Los atacantes presentaban parte del trabajo como una auditoría de seguridad legítima y fragmentaban las instrucciones. El sistema acababa ayudando a realizar actividades ofensivas que no debía haber ejecutado y dejando grandes estragos a sus espaldas. Justo lo que hemos también analizado en el material filtrado que comenté antes: muchos scripts, muchos objetivos, y un histórico de comandos donde el comando “claude” era el factor común de todas las acciones llevadas a cabo. Además, en agosto de 2025, ESET dio a conocer PromptLock, un programa de ransomware capaz de generar scripts mediante un modelo de IA durante su ejecución. Después se confirmó que era un prototipo académico de la Universidad de Nueva York, no una campaña real con víctimas. Más recientemente, el 7 de octubre de 2026, CrowdStrike documentó ataques contra entidades financieras surcoreanas en los que un actor utilizó ARTEX, una herramienta de pruebas de penetración con agentes de IA, junto con modelos de lenguaje LLM. Se investigó la exfiltración de datos, aunque la autoría no quedó atribuida a un grupo conocido. En nuestra propia investigación, evidenciamos como el atacante desde la máquina filtrada, utilizaba un servidor de salto con múltiples puertos, y cada uno de esos puertos correspondería a una identidad diferente en internet para dificultar, sin duda, su detección y rastreo. Aunque las acciones las pueda realizar una IA, siempre detrás hay un humano que se tiene que seguir protegiendo. En consecuencia, tenemos situaciones diferentes: una operación investigada por el proveedor de una conocida IA, distintas conclusiones de los análisis realizados de diferentes incidentes dentro de nuestro laboratorio y ataques investigados en fugas de información, realizados contra organizaciones reales. Mezclarlas sería un error. También sería un error imaginar a la IA como un atacante infalible. Puede fallar, inventar resultados o tomar caminos inútiles que probablemente nunca sabremos. De hecho, en nuestro análisis de la filtración hemos observado algún campo de OSINT (datos recogidos de fuentes abiertas) que al no encontrar el valor real, “claude” (en este caso observado), dio rienda suelta a su imaginación para cerrar etapas en su objetivo fijado para contentar al atacante. Para no alejarnos de la explicación, el riesgo aquí está en que puede probar muchas alternativas con una rapidez que multiplica el esfuerzo de defensa primero, y también, de investigación. Aunque la información no pueda ser del todo rigurosa, hay tanta, y de tantas organizaciones, que aquí la importante calidad del dato se podría ver atenuada por la amplificación de número de objetivos a atacar. La IA puede cometer errores y, aun así, multiplicar las alternativas de ataque y el esfuerzo de defensa. La respuesta necesita tecnología, pero también criterio La primera exigencia para una organización es tener visibilidad de todo lo que suceda. No solo durante el horario de oficina. Hay que cuidar mucho todo lo expuesto en internet, también utilizar segmentación de red, con redes desmilitarizadas (DMZ) separadas del resto de la organización donde poner los servidores más expuestos evitando posibles movimientos laterales. Rotado frecuente de contraseñas robustas y segundo factor de autenticación, el conocido como zero-trust (privilegios mínimos para todos los usuarios, y administradores reservados sólo para necesidades concretas, auditables y especiales). También hay que parchear en el mismo día cualquier vulnerabilidad (el tiempo que había para probar una actualización primero en una maqueta y después en producción hoy, es valiosísimo), y advertir accesos anómalos, comportamientos extraños de cuentas, conexiones hacia destinos poco habituales, correlaciones sospechosas (los famosos casos de uso), viajes imposibles (login en España y en EEUU al mismo tiempo sin contar con las 6-8 horas de vuelo, no parece posible), movimientos de datos que se salgan de lo normal, uso de CPU, memoria o red, hay que prestar atención a estoy y cualquier otro detalle que se salgan de lo normal. Además, debe existir capacidad para actuar sin esperar a que el problema pase por una larga cadena de autorizaciones. Ya no existe el tiempo de descuento para los famosos exploits de día 0, se está viendo que desde que se publica la vulnerabilidad, mientras lees el aviso del fabricante, pueden estar tanteando hasta dos veces esa vulnerabilidad. Quienes trabajamos en respuesta a incidentes y análisis forense también tenemos que revisar nuestros métodos. Si aparecen centenares de scripts, habrá que agruparlos por comportamiento y reconstruir la secuencia sin revisarlos todos de manera aislada y detallada como antaño; o analizas “a bulto” o el bosque no te deja ver los árboles. Hay que centrarse en lo importante: contener, erradicar, recuperar y lecciones aprendidas. Si una cuenta se ha visto comprometida, será necesario valorar la revocación de sesiones y credenciales y analizar sus conexiones. Si hay que contener de inmediato, no siempre podremos realizar primero una adquisición forense completa: tendremos que decidir qué evidencia puede preservarse sin agravar el daño y dejar constancia de cada actuación. Investigar lo ocurrido sigue siendo necesario, pero frenar el ataque no puede esperar a comprender cada detalle. La automatización defensiva puede ser una gran ayuda, pero no debe convertirse en una caja negra. Una herramienta puede detectar patrones o proponer una medida; hace falta alguien que conozca la organización, entienda las consecuencias y se responsabilice de la decisión. No todo lo que parece extraño es un ataque. No toda acción rápida es una buena respuesta, pues puedes afectar a negocio, y con estas nuevas reglas de juego, estas decisiones han de tomarse casi en tiempo real. A mí me parece uno de los retos más interesantes que ha tenido este trabajo en muchos años. Nos obliga a mejorar, a compartir conocimiento y a preparar equipos capaces de investigar ataques masivos, sofisticados o especialmente intensos mientras se protege al negocio. Pero no se trata de competir con la máquina. Se trata de identificar, entre todo el ruido que hoy se genera en un ataque, aquellas acciones que debemos interrumpir a tiempo para poder frenar de forma efectiva a un adversario que, en principio, parece saberlo todo y estar siempre un paso por delante. Durante años hemos dedicado buena parte del esfuerzo a reconstruir todos los pasos que un atacante había dado. Ahora, sin abandonar esa labor, necesitamos frenar los siguientes pasos que sigue dando. Comprender cada detalle sigue siendo importante, pero ya no puede ser lo primero. Es un cambio de estrategia, y tampoco será el único al que tendremos que adaptarnos. Quizá nuestras técnicas continúen siendo válidas. Lo que también ha cambiado es la forma de aplicarlas ante estos nuevos incidentes, y el tiempo disponible para analizar, comprender y tomar decisiones. Un día cualquiera, otra vez a las 03:47, salta una nueva alerta. Se nos escala el incidente. Entramos. Estamos solos, pero ya sabemos qué tenemos delante: algo que persigue un objetivo no se detiene ante las dificultades que le pongas, tampoco le preocupa ser visto incluso repitiendo los mismos patrones, lo único que quiere es continuar con su objetivo. ______ Nota final: Las observaciones procedentes de investigaciones propias se presentan de forma anonimizada; no implican atribución pública ni una relación demostrada entre los casos. No obstante, en muchos de ellos se aprecia una tendencia que parece común: cada vez más acciones, más velocidad y menos tiempo para reaccionar. Ciberseguridad AI-Native SecOps: marco para evaluar la madurez de un SOC con Inteligencia Artificial 21 de septiembre de 2026

Como vimos en el primer post de la serie, el proceso de IR (respuesta a incidentes) en caso de ataques que utilizan ransomware es fundamental, apoyándose en el trabajo de varios grupos que, aportando distintos roles, conforman un único equipo de trabajo para ayudar a recuperarse en la menor brevedad de tiempo posible, a la empresa afectada. Nuestros servicios NextDefense, incluyen una rama específica en su propuesta para cubrir este tipo de servicios. En este segundo post de la serie, vamos a revisar el papel que juegan los integrantes del equipo de servicios DFIR (Digital Forensics and Incident Response) de Telefónica Tech dentro del proceso global de IR. Composición del equipo DFIR El equipo está formado por un conjunto de profesionales multidisciplinales, perfiles senior mayormente, donde su trayectoria profesional ha estado siempre ligada a la seguridad en cualquiera de sus especialidades. Esta diversidad de roles permite estar preparados ante cualquier evolución de las técnicas, tácticas y procedimientos ofensivos y métodos anti-forenses de los atacantes, al margen de las características concretas del actor y el ataque. En el caso que nos ocupa, incidentes de seguridad con uso de ransomware, es necesario combinar recursos de distintos grupos: DFIR Threat Hunting (ocasionalmente combinado con servicios de monitorización EDR) Threat Intel (Inteligencia de amenazas) Dentro de estas disciplinas, DFIR cuenta con tres roles diferenciados que participan de maneras muy concretas dentro del proceso de IR: Incident Handler (IH): Es quien coordina el incidente de seguridad, y hace de enlace entre el cliente y los distintos equipos para llevar un control y facilitar la comunicación, asignando tareas a las distintas partes y asegurando que todo el proceso de IR va evolucionando de la forma debida. Analista Forense: Es el especialista con capacidad de realizar investigaciones (locales y remotas) sobre cualquier sistema o soporte con información, y cuya finalidad es la obtención de evidencias que permitan avanzar durante la investigación. Analista de Malware: Es el especialista que realiza análisis estáticos y dinámicos sobre virus y otros artefactos maliciosos que se podrán encontrar en los equipos procesados por el analista forense, el role Threat-hunter o por el propio cliente. Preparación del proceso de IR Cuando se inicia un nuevo proceso de respuesta a un incidente, el equipo de servicios DFIR organiza el trabajo y prepara la realización de las primeras tareas. Se crean espacios en la nube (que se utilizarán para la compartición de evidencias) y también se aprovecha para analizar la propia nota de rescate, la extensión de los archivos cifrados e incluso qué dominio corporativo tiene la empresa que ha sido afectada. Esperando la reunión inicial con el cliente, las personas asignadas, revisan internamente la información disponible y preparan todo el contenido para esos primeros pasos con cliente. Esta primera reunión de trabajo será de las más importantes. Toda esta preparación antes de la primera reunión es utilizada para revisar el conocimiento que se pudiera tener sobre el actor concreto: Si suele realizar exfiltración de datos, qué vía de entrada suele utilizar, qué herramientas despliega e incluso si la empresa tiene credenciales exfiltradas en mercados negros. La primera jornada del proceso y en particular, la primera reunión, son fundamentales. Inicio de la respuesta Una vez se produce la primera reunión y se comienza en sí el proceso de respuesta, se crean unas líneas de trabajo iniciales dirigidas a todos los grupos (cliente y terceros incluidos) probadas en cada incidente y mejoradas al final de ellos. Algunos ejemplos: El Incident Handler tomará el control del proceso y comenzará a organizar todos los grupos de trabajo, actividades, plan de reuniones, etc. El equipo Threat Intel solicitará una serie de datos al cliente para producir inteligencia de ciberseguridad accionable (se verá en el próximo post). El analista forense recogerá todos los eventos/objetos que puedan albergar información del atacante. Ello producirá los primeros IOCs (Indicadores de Compromiso) que permitirán comenzar, por ejemplo, con los bloqueos para iniciar las fases de contención y erradicación de la amenaza. Si hay elementos de malware, un analista de esta especialidad será incorporado al equipo para realizar sus labores correspondientes. El grupo Threat Hunting (muchas veces, en combinación con otros servicios de monitorización de Telefónica TECH) irá apoyando el despliegue (cuando sea necesario) de una plataforma EDR, realizando análisis de alertas e investigación de amenazas sobre dicha plataforma. Concretamente, en el último post de la serie veremos el trabajo de este equipo. Desempeño durante el proceso de IR El proceso de respuesta a incidentes sigue una rutina de reuniones (más ejecutivas) o puntos de control (más técnicos) a lo largo del periodo de trabajo (un par de semanas, en término medio). En estas reuniones, el equipo de trabajo conjunto (cliente, equipo de Telefónica TECH y posibles terceros) irá revisando el trabajo en curso, compartiendo conocimiento y asignando nuevas tareas a todos (siendo estas revisadas en cada punto de control). Los perfiles forenses del equipo DFIR tendrán un trabajo intenso en este proceso iterativo y a lo largo del periodo de trabajo acordado: irán realizando sus investigaciones con los distintos tipos de evidencias disponibles, se apoyarán en los analistas de malware (si se diera el caso) e irán -poco a poco- creando la narrativa del incidente que será explicada al cliente en el siguiente punto de control. Irán identificando y comunicando los IOC encontrados a los distintos grupos para apoyar en la contención y erradicación, mientras trazan el timeline (línea temporal) que irá reflejado en el informe que será entregado al cliente junto con la identificación del primer sistema hallado como comprometido (pasando a ser el “paciente 0”), los vectores de entrada utilizados para enriquecer las recomendaciones que servirán como puntos de mejora de la infraestructura afectada y todo lo relevante de la red (y del atacante) que deba ser comunicado al cliente. Posteriormente y sólo en los casos donde pudiera existir una publicación de información (no todos los ataques con ransomware implican exfiltración de datos), los analistas de inteligencia de amenazas intentarán monitorizar su Hall of Shame (“salón de la vergüenza”, normalmente tablones públicos donde se divulga la información exfiltrada) de cara a poder asistir a los clientes en los aspectos más importantes concernientes a la privacidad de datos y a la norma GDPR, entre otras acciones. Este bloque de actividad se explicará en el siguiente post de la serie. En definitiva: el trabajo del grupo DFIR dentro de un incidente con ransomware, tal como lo entendemos en Telefónica TECH, es un proceso constante de investigación y de intercambio de conocimiento de los analistas de forense y de malware con otros grupos (inteligencia de amenazas y Threat Hunting, sobre todo). En cada actuación, el cliente y los demás roles y grupos conocerán los avances logrados en DFIR gracias a la intermediación del Incident Handler (quizás, un nuevo IOC o la identificación del paciente 0) y a su vez, esos grupos podrán ampliar la información a los especialistas de DFIR para refinar los siguientes pasos de su investigación. Finalización de los trabajos de análisis forense y malware Cuando se da por completado el trabajo de investigación en un proceso IR, se genera un informe final de investigación que sigue una estructura que se va revisando regularmente para asegurar la máxima utilidad al cliente. Al margen del país/región del incidente o del idioma utilizado, el informe tiene siempre el mismo formato y estructura. En algunos casos, los clientes solicitan una versión previa de dicho informe para compartir con fuerzas y cuerpos de seguridad, empresas aseguradoras, auditores, socios, proveedores o clientes. Para aportar tranquilidad, una vez que se ha compartido con el cliente el informe final de la investigación, el proceso de IR suele continuar con una monitorización en 24x7 pactada del EDR en donde todo el equipo podría volver a ser reactivado. En estos últimos compases del proceso de IR, se mantendrá una reunión final con el cliente donde se revisará con detalle el informe entregado, resolviéndose las dudas que hayan podido surgir y explicando los aspectos más importantes de la narrativa tanto del incidente como de las recomendaciones. Tal como hemos visto, el proceso de respuesta a incidentes del equipo de DFIR de Telefónica Tech trabaja de forma rápida y organizada atendiendo a una metodología específica seguida por todos los grupos, para cubrir todas las fases del proceso de IR. Estos roles y su metodología son clave para resolver este tipo de incidentes.