Evasión de Defensas: El Doble Golpe que DORA y NIS2 no pueden ignorar

En el ajedrez sin fin de la ciberseguridad, los atacantes siempre buscan la jugada maestra, esa que permite mover pieza tras pieza sin levantar sospechas, o la que introduce una nueva pieza para cambiar las reglas del juego. MITRE ATT&CK, ese compendio casi enciclopédico de tácticas y técnicas adversarias, ha puesto el foco en una de las categorías más críticas y, a menudo, frustrantes para los defensores: la evasión de defensas. Y lo que han descubierto, o más bien formalizado con una precisión quirúrgica, es una dicotomía que debería mantener a más de un CISO despierto por las noches, repasando mentalmente sus controles.

No hablamos de una simple actualización de su ya impresionante base de datos. Hablamos de una categorización que ilustra la sofisticación y la adaptabilidad del adversario, dividiendo la evasión en dos grandes mundos: el de los que se esconden a plena vista y el de los que traen su propio arsenal, a menudo con la bendición implícita de una firma digital. Para las entidades financieras europeas, inmersas en la vorágine de DORA y NIS2, comprender esta dualidad no es un ejercicio académico ni una lectura de sobremesa; es una necesidad imperiosa para la resiliencia operativa y la gestión de riesgos en un entorno donde la confianza, incluso en los componentes más básicos del sistema, puede ser explotada.

MITRE ATT&CK: El manual de tácticas que todo CISO debería dominar

Antes de sumergirnos en la escisión de la evasión, un breve recordatorio. MITRE ATT&CK no es solo una lista de amenazas, ni un mero glosario; es un marco globalmente accesible de tácticas y técnicas adversarias basadas en observaciones del mundo real. Para los profesionales de la seguridad, es el mapa que permite entender cómo los atacantes se mueven, persistir y lograr sus objetivos, desde el acceso inicial hasta la exfiltración de datos o el impacto en la disponibilidad de los sistemas. Es la taxonomía que permite a los defensores hablar el mismo idioma, comparar notas y, lo que es más importante, anticipar y mitigar con estrategias basadas en la inteligencia de amenazas.

La categoría de Evasión de Defensas (T1562) es, por definición, el arte de evitar ser detectado o que las medidas de seguridad actúen contra el atacante. Piensen en el ladrón que desactiva las alarmas o en el espía que se mimetiza con el entorno, usando su propia indumentaria para pasar desapercibido. En el mundo digital, esto puede significar desde deshabilitar un antivirus hasta eludir la detección de un sistema de prevención de intrusiones. Pero la realidad es que esta categoría, como la vida misma y las tácticas de los ciberdelincuentes, ha crecido en complejidad, y lo que antes era un cajón de sastre, ahora exige una diferenciación crucial. Una que, por cierto, pone en jaque muchos de los controles tradicionales.

La 'Evasión de Defensas' a dos velocidades: LotL vs. BYOVD

MITRE ha puesto de manifiesto que la evasión no es un monolito homogéneo. Hay, fundamentalmente, dos grandes corrientes que los atacantes utilizan para sortear las defensas, cada una con implicaciones distintas para la detección, la respuesta y, por supuesto, la gobernanza y el cumplimiento regulatorio en un sector tan escrutado como el financiero.

1. Living off the Land (LotL): El enemigo está dentro (y usa tus cosas)

Esta táctica es la pesadilla de cualquier CISO que ha invertido años en fortificar su perímetro. Los atacantes que practican Living off the Land (LotL) no introducen herramientas exóticas o malware desconocido que el antivirus de turno podría cazar. En su lugar, explotan las herramientas y funcionalidades legítimas que ya están presentes en el sistema o la red de la víctima. Piensen en PowerShell, WMI, PsExec, el gestor de tareas (schtasks.exe), o incluso utilidades básicas del sistema operativo como cmd.exe o net.exe. Son herramientas necesarias para el funcionamiento diario de una entidad, utilizadas por administradores de sistemas y aplicaciones. Por eso, detectarlas cuando se usan con fines maliciosos es como buscar una aguja en un pajar lleno de agujas legítimas, todas ellas con un aspecto muy similar.

La ironía es palpable, casi hiriente. Gastas fortunas en soluciones EDR y SIEM de última generación, y el atacante te la juega con tu propio PowerShell, o moviéndose lateralmente con credenciales robadas a través de servicios de compartición de archivos. No traen un arma, usan una de las tuyas. El impacto en la detección es devastador: las herramientas LotL generan un ruido operativo inmenso. La actividad maliciosa se mezcla con la legítima, haciendo que los análisis de comportamiento sean mucho más complejos y propensos a falsos positivos. Los patrones de uso anómalos son la clave, pero ¿cuántas entidades tienen una línea base de comportamiento tan refinada, tan quirúrgicamente precisa, como para detectar que un administrador de sistemas usa PowerShell de una forma ligeramente distinta a la habitual, pero con intenciones nefastas? La respuesta, lamentablemente, es: muy pocas.

Caso hipotético de LotL: El 'Administrador' Fantasma

Imaginemos a 'Grupo Fénix', un actor de amenaza persistente avanzado (APT) con un objetivo claro: extraer datos de clientes de un banco de inversión europeo. Tras una fase inicial de reconocimiento y un ataque de phishing exitoso que compromete las credenciales de un empleado de nivel medio, el Grupo Fénix no descarga malware. En su lugar, utiliza PsExec para moverse lateralmente desde el puesto de trabajo comprometido a un servidor de archivos interno. Una vez allí, emplean certutil.exe (una utilidad legítima de Windows para gestionar certificados) para descargar una pequeña carga útil desde un servidor C2 externo. Esta carga útil, que no es más que un script de PowerShell obfusificado, se ejecuta en memoria y utiliza WMI para enumerar usuarios y grupos de dominio, buscando cuentas con privilegios elevados. Luego, a través de schtasks.exe, programan una tarea para ejecutar el mismo script de PowerShell de forma recurrente, asegurando la persistencia. Todo esto ocurre sin activar ninguna alarma tradicional de antivirus o EDR que busque firmas de malware. Los eventos generados son propios de la actividad de un administrador, aunque el patrón es sutilmente anómalo. El banco descubre la intrusión meses después, tras una auditoría forense post-brecha, cuando la exfiltración ya se ha consumado.

2. Bring Your Own Vulnerable Driver (BYOVD) y cargadores personalizados: La sofisticación importada

En el otro extremo del espectro de evasión encontramos tácticas que implican la introducción de nuevos componentes, a menudo con un componente de sofisticación técnica mucho mayor. Aquí, MITRE distingue entre dos variantes principales que demuestran una audacia y una capacidad de ingeniería inversa que pocos defensores pueden replicar:

• Bring Your Own Vulnerable Driver (BYOVD): Esta técnica es una evolución perversa de la evasión que explota la confianza inherente en los drivers firmados digitalmente. Los atacantes instalan un driver legítimo, pero conocido por tener una vulnerabilidad, para luego aprovechar esa vulnerabilidad y obtener privilegios elevados, a menudo a nivel de kernel. Una vez con estos privilegios, pueden deshabilitar soluciones de seguridad (EDR, antivirus), manipular la memoria, o ejecutar código malicioso indetectable a las capas de seguridad de usuario. Es una jugada maestra de ingeniería inversa social sobre el sistema operativo: si Microsoft o un fabricante de hardware ha firmado el driver, el sistema confía en él ciegamente, aunque tenga un defecto que el atacante conoce y explota sin piedad. La paradoja es que la medida de seguridad (la firma digital) se convierte en el vector de ataque más potente.
• Cargadores o módulos personalizados: Aquí, el atacante no se molesta en usar tus herramientas ni tus drivers, ni en buscar vulnerabilidades de terceros. Simplemente trae su propio malware, a menudo altamente ofuscado o polimórfico, diseñado específicamente para ser indetectable por las soluciones de seguridad existentes. Estos cargadores pueden inyectar código directamente en procesos legítimos, manipular la memoria, o utilizar técnicas de shellcode y rootkits para ejecutar sus cargas útiles sin dejar rastros obvios en disco o en los registros de eventos estándar. Su objetivo es la invisibilidad total, operando en las sombras del sistema.

La detección de BYOVD y cargadores personalizados es un desafío diferente al de LotL. No es tanto el ruido de la actividad legítima, sino la sutileza, la invisibilidad casi perfecta de la intrusión. Requiere una monitorización profunda del kernel, análisis de comportamiento a nivel de sistema, y una capacidad de detección de amenazas emergentes que no se base únicamente en firmas, sino en anomalías a bajo nivel. La clave está en observar el comportamiento de los drivers y módulos, incluso si están firmados legítimamente, y en identificar patrones de carga de código anómalos o inyecciones inesperadas en procesos críticos. Esto exige herramientas y experiencia que van mucho más allá de lo que la mayoría de las entidades tienen a su disposición.

Caso hipotético de BYOVD: El driver de confianza comprometido

Consideremos a 'Nightshade Labs', un grupo de ciberdelincuentes con motivaciones financieras que busca el acceso persistente a un broker de bolsa para manipular transacciones. Tras un punto de entrada inicial (quizás un exploit de navegador), instalan un driver legítimo de una tarjeta de red antigua, pero que es conocido por tener una vulnerabilidad de escalada de privilegios (CVE-20XX-XXXX). Una vez que el driver está cargado y el sistema operativo le ha dado su sello de aprobación debido a la firma digital válida, Nightshade Labs explota la vulnerabilidad para obtener privilegios de kernel. Con este control total, deshabilitan silenciosamente el EDR del broker, inyectan su propio rootkit en el kernel y establecen un canal de comunicación encubierto a través de tráfico DNS. Durante semanas, acceden a los sistemas de trading, modificando parámetros de órdenes y extrayendo datos de precios, todo ello sin que el EDR desactivado o el SIEM, que solo busca patrones de malware conocidos, detecte nada. El incidente solo se descubre cuando un analista de seguridad sospecha de una pequeña anomalía en el rendimiento de un servidor y decide realizar un análisis forense a bajo nivel, encontrando el driver vulnerable y el rootkit.

DORA y NIS2: ¿Preparados para la doble amenaza? Aquí está el quid.

Aquí es donde la teoría se encuentra con la cruda realidad regulatoria que tanto nos ocupa en el sector financiero europeo. DORA (Reglamento de Resiliencia Operativa Digital) y la Directiva NIS2 no son meros conjuntos de casillas a marcar o un check-list burocrático; exigen una comprensión profunda, proactiva y pragmática de los riesgos cibernéticos, y una capacidad demostrable para gestionarlos. Y las tácticas de evasión de defensas, en sus dos vertientes, ponen a prueba la médula de estas regulaciones como pocas otras amenazas.

La resiliencia operativa bajo el microscopio de LotL (DORA)

DORA exige a las entidades financieras una gestión robusta de los riesgos de TIC y, crucialmente, la capacidad de resistir, responder y recuperarse de incidentes. Pero, ¿cómo se mide la resiliencia cuando el incidente es un atacante usando PowerShell para moverse lateralmente por tu red durante semanas, sin activar una sola alarma tradicional? La respuesta no es sencilla, pero DORA nos empuja a ir más allá de las medidas superficiales:

• Gestión de riesgos TIC (Art. 5): Esto implica entender que las herramientas legítimas son vectores de riesgo. Las evaluaciones de riesgo deben contemplar el uso indebido de software interno. ¿Tienes políticas de uso de PowerShell y otras utilidades administrativas? ¿Monitorizas su ejecución fuera de los patrones esperados, en horarios inusuales o por usuarios no autorizados? ¿Se documenta y audita el uso de estas herramientas en tus procedimientos operativos estándar? La mera existencia de un control no basta si no se adapta a las nuevas realidades de la amenaza.
• Detección y gestión de incidentes (Art. 10): DORA obliga a una detección temprana y una notificación rápida. Pero, ¿qué detectas? Si tu SIEM solo busca firmas de malware conocido, LotL te pasará por delante sin inmutarse, como un fantasma en el sistema. Se necesitan capacidades avanzadas de análisis de comportamiento de usuarios y entidades (UEBA), correlación de eventos entre múltiples fuentes (logs de AD, logs de endpoints, tráfico de red) y, quizás lo más difícil, la creación de una línea base de actividad normal tan refinada que cualquier desviación levante una bandera. Esto implica una inversión significativa en personas, procesos y tecnología.
• Pruebas de resiliencia (Art. 24): Las pruebas de penetración y los ejercicios de cibersegistencia (Threat-Led Penetration Testing, o TLPT) son esenciales. Un equipo de Red Team que use tácticas LotL puede poner a prueba la verdadera madurez de tus defensas y tu capacidad de detección. Si tus ejercicios solo buscan puertos abiertos o vulnerabilidades de configuración obvias, no están haciendo bien su trabajo y DORA te pedirá cuentas. Los TLPT deben simular tácticas y técnicas de APT conocidas, y LotL es una de ellas.

El quid de la cuestión con LotL es que no puedes simplemente prohibir las herramientas. Tendrías que cerrar la mitad de tu infraestructura y paralizar tus operaciones. La solución pasa por la monitorización granular de procesos, la segmentación de red para limitar el movimiento lateral, el principio de mínimo privilegio aplicado con rigor, una higiene de credenciales impecable y la autenticación multifactorial (MFA) en todas las capas. Es un trabajo de fondo, poco vistoso, pero absolutamente vital para cumplir con el espíritu, y la letra, de DORA.

La cadena de suministro y el riesgo de BYOVD (NIS2)

NIS2, con su foco ampliado en la cadena de suministro y la responsabilidad de los proveedores de servicios esenciales y digitales, encuentra en BYOVD un adversario particularmente insidioso. Si un atacante puede explotar un driver vulnerable de un proveedor de hardware o software, la vulnerabilidad no es solo tuya, sino de toda la cadena, y la responsabilidad de mitigación se extiende mucho más allá de tu perímetro.

• Gestión de riesgos de la cadena de suministro (Art. 21): NIS2 obliga a una evaluación exhaustiva de los riesgos en tu cadena de suministro. Esto significa ir más allá de las clásicas cláusulas contractuales y pedir a tus proveedores que demuestren una gestión proactiva de vulnerabilidades en sus productos, incluyendo los drivers y los componentes de bajo nivel. ¿Hacen pruebas de seguridad exhaustivas a sus productos antes de entregarlos? ¿Tienen un programa de recompensa por errores (bug bounty) activo? ¿Cómo gestionan las vulnerabilidades descubiertas en sus componentes? La diligencia debida aquí es mucho más profunda que un simple cuestionario.
• Vulnerabilidad y gestión de parches (Art. 21): La detección de BYOVD implica una gestión de vulnerabilidades mucho más sofisticada. No basta con aplicar parches conocidos; hay que estar al tanto de los drivers legítimos que, a su vez, contienen vulnerabilidades que pueden ser explotadas para escalar privilegios. Esto requiere inteligencia de amenazas actualizada, suscripciones a bases de datos de vulnerabilidades (CVE), y una capacidad de inventario de activos granular que incluya versiones de drivers y firmware. La pasividad aquí es un lujo que NIS2 no permite.
• Seguridad por diseño (Art. 21): Aunque el Cyber Resilience Act (CRA) se centra más específicamente en los fabricantes, el espíritu de seguridad por diseño es aplicable aquí y NIS2 lo eleva a un requisito para los operadores. Las entidades deben exigir a sus proveedores que integren la seguridad desde las primeras etapas del desarrollo, minimizando la superficie de ataque, incluso en componentes aparentemente inocuos como los drivers. Esto implica un diálogo técnico constante y una capacidad para auditar el cumplimiento de estos principios.

El desafío con BYOVD es que la confianza es un arma de doble filo. Confiamos en los certificados de firma de código emitidos por autoridades reconocidas, pero si el código firmado contiene un defecto explotable, esa confianza se convierte en nuestra debilidad más crítica. La solución pasa por un escrutinio más profundo de los proveedores, la implementación de medidas de seguridad a nivel de kernel (como la integridad de código forzada o HVCI) y el uso de soluciones de seguridad que puedan detectar anomalías en la carga de drivers, incluso los firmados, analizando su comportamiento y no solo su origen. La superficie de ataque se ha expandido hasta el hardware, y los reguladores lo saben.

Más allá de la detección: Respuesta y recuperación post-evasión

DORA es meridianamente clara: una vez que se detecta un incidente, la entidad debe responder y recuperarse con celeridad para mantener la continuidad del negocio. Pero, ¿cómo se gestiona un incidente cuando el atacante ha estado usando herramientas legítimas durante semanas, o ha obtenido control a nivel de kernel, borrando sus huellas con una sofisticación casi artística? Las implicaciones para los equipos de respuesta a incidentes son profundas y exigen un cambio de paradigma:

• Contención y erradicación: Las tácticas LotL hacen que la contención sea un reto. No puedes simplemente aislar un proceso de PowerShell sin afectar la operación legítima del negocio. La erradicación se vuelve más compleja, requiriendo un conocimiento forense avanzado para distinguir la actividad maliciosa de la benigna, identificando las verdaderas fuentes de compromiso y los puntos de persistencia ocultos. Esto no es apagar un servidor; es una cirugía de precisión. Con BYOVD, si el kernel está comprometido, la erradicación puede requerir la reinstalación completa de sistemas operativos y firmware, una tarea costosa y que consume mucho tiempo, con un impacto directo en la disponibilidad de los servicios críticos.
• Análisis forense y lecciones aprendidas: La visibilidad es el santo grial. Para investigar eficazmente un incidente LotL, necesitas logs de comandos completos, telemetría de procesos y una línea base de actividad para identificar desviaciones. Para BYOVD, la visibilidad a nivel de kernel y la capacidad de analizar volcados de memoria son indispensables. DORA exige un análisis de las causas raíz y la implementación de mejoras para prevenir futuros incidentes. Si no puedes ver lo que pasó, ¿cómo vas a aprender? La respuesta a incidentes debe evolucionar de la mera reacción a una capacidad de análisis proactivo y de caza de amenazas (threat hunting).
• Comunicación y notificación: Tanto DORA como NIS2 establecen requisitos estrictos para la notificación de incidentes a las autoridades competentes y, en algunos casos, a los clientes. Un incidente LotL o BYOVD, por su naturaleza sigilosa y su potencial de impacto sistémico, suele clasificarse como un incidente grave. La capacidad de evaluar rápidamente el impacto, comprender la cadena de eventos y comunicar de forma transparente y precisa es tan crítica como la propia contención. El tiempo es oro, y la reputación, aún más.

La Hoja de Ruta del CISO: Un Plan de Acción para DORA y NIS2 frente a la Evasión

No basta con entender el problema; hay que actuar. Para un CISO en el sector financiero, la complejidad de LotL y BYOVD bajo el paraguas de DORA y NIS2 exige un enfoque multifacético y por fases. Aquí, la idea no es dar una receta mágica, sino una guía pragmática para empezar a moverse y demostrar a los reguladores que uno se toma esto en serio.

Fase 1: Visibilidad y Diagnóstico (Primeros 3-6 meses)

El primer paso, y a menudo el más subestimado, es saber qué tienes y qué está pasando. Sin visibilidad, estás luchando a ciegas.

• Inventario exhaustivo de activos y software: No hablamos solo de hardware. ¿Qué sistemas operativos tienes? ¿Qué versiones de drivers? ¿Qué aplicaciones legítimas están instaladas y cuáles son sus usos previstos? Esto incluye tanto los sistemas de producción como los de desarrollo y prueba. Necesitas saber qué tienes para poder protegerlo. (Requisito DORA Art. 5 – Gestión de riesgos TIC)
• Monitorización granular y telemetría de endpoints: Implementa o refina soluciones EDR/XDR que no solo detecten firmas, sino que capturen telemetría detallada de procesos, llamadas al sistema, uso de PowerShell y comandos ejecutados. Activa la auditoría de seguridad avanzada en Windows y Linux. Esto es crucial para detectar LotL. (Requisito DORA Art. 10 – Detección de incidentes)
• Análisis de comportamiento (UEBA): Invierte en capacidades UEBA. Necesitas una línea base de comportamiento normal para usuarios y sistemas. ¿Quién usa PowerShell, cuándo y cómo? ¿Qué drivers se cargan en qué máquinas? Las desviaciones son el aviso temprano de LotL y BYOVD. (Requisito DORA Art. 10 – Detección de incidentes)
• Auditoría de logs y SIEM: Asegúrate de que los logs relevantes de endpoints, servidores, Active Directory y soluciones de seguridad se centralizan, retienen y correlacionan eficazmente en tu SIEM. La visibilidad sin correlación es ruido. (Requisito NIS2 Art. 21 – Medidas de ciberseguridad)

Fase 2: Fortificación y Proactividad (Siguientes 6-12 meses)

Una vez que sabes lo que tienes y lo que ocurre, es momento de fortalecer tus defensas y adoptar un enfoque más proactivo.

• Endurecimiento de sistemas y aplicaciones: Aplica el principio de mínimo privilegio de forma estricta. ¿Necesita ese usuario ejecutar PowerShell como administrador? Restringe el uso de herramientas administrativas a usuarios y sistemas específicos. Deshabilita o restringe servicios innecescesarios. Implementa políticas de integridad de código (Code Integrity) para limitar la carga de drivers no firmados o de origen desconocido. (Requisito DORA Art. 5 – Gestión de riesgos TIC)
• Gestión proactiva de vulnerabilidades y parches: Va más allá de Microsoft Patch Tuesday. Suscríbete a feeds de inteligencia de amenazas que reporten vulnerabilidades en drivers legítimos (BYOVD). Prioriza los parches no solo por CVSS, sino por la explotabilidad y el impacto en tu entorno. Incluye en tus evaluaciones de riesgo las vulnerabilidades de terceros en la cadena de suministro. (Requisito NIS2 Art. 21 – Gestión de vulnerabilidades)
• Segmentación de red y microsegmentación: Limita el movimiento lateral. Si un atacante logra un pie dentro, la segmentación debe dificultar su avance. Esto es un pilar fundamental contra LotL, ya que evita que un compromiso menor se convierta en una brecha total. (Requisito DORA Art. 5 – Gestión de riesgos TIC)
• Formación y concienciación avanzada: Tus equipos de TI y seguridad deben entender estas tácticas. Realiza talleres prácticos sobre LotL y BYOVD. Forma a tus analistas para ir más allá de las alertas de firmas y buscar anomalías de comportamiento. (Requisito DORA Art. 13 – Formación)

Fase 3: Optimización y Validación (12-24 meses y más allá)

La ciberseguridad no es un destino, sino un viaje. Una vez que las bases están sentadas, la clave es la mejora continua y la validación de tus capacidades.

• Threat Hunting: Desarrolla un equipo o capacidad de threat hunting. No esperes a las alertas; busca activamente amenazas usando la inteligencia de LotL y BYOVD de MITRE ATT&CK. Busca esos patrones de uso anómalo de PowerShell o esos drivers legítimos pero vulnerables que el atacante podría explotar. (Requisito DORA Art. 10 – Detección de incidentes, NIS2 Art. 21 – Threat intelligence)
• Ejercicios de Red Team y TLPT: Invierte en ejercicios de Red Team que simulen tácticas LotL y BYOVD. Esto es la prueba de fuego de tus defensas y de tu capacidad de respuesta. Si tu equipo de Red Team no usa estas técnicas, no está evaluando tu verdadera resiliencia. DORA exige pruebas avanzadas; aquí es donde brillan. (Requisito DORA Art. 24 – Pruebas de resiliencia)
• Auditoría de la cadena de suministro: No solo evalúes a tus proveedores, audítalos. Exige informes de seguridad, resultados de pruebas de penetración y evidencia de gestión de vulnerabilidades, especialmente para componentes de software de bajo nivel. (Requisito NIS2 Art. 21 – Gestión de riesgos de la cadena de suministro)
• Plan de respuesta a incidentes (IRP) adaptado: Revisa y actualiza tu IRP para incluir escenarios específicos de LotL y BYOVD. ¿Cómo contienes un atacante que opera a nivel de kernel? ¿Cómo recuperas sistemas comprometidos con persistencia a bajo nivel? Realiza simulacros de estos escenarios. (Requisito DORA Art. 10 – Gestión de incidentes)

La Intersección con otras regulaciones: Un ecosistema complejo

La complejidad no termina con DORA y NIS2. Estas tácticas de evasión encuentran resonancia en otras piezas del puzle regulatorio europeo y global:

• Cyber Resilience Act (CRA): Aunque el CRA se centra en la seguridad de los productos con elementos digitales desde el diseño, la presencia de drivers vulnerables (el corazón de BYOVD) subraya la necesidad de que los fabricantes garanticen la seguridad a lo largo de todo el ciclo de vida del producto. Las entidades financieras, como compradores, se beneficiarán de productos más seguros, pero también tendrán la responsabilidad de exigir este nivel de seguridad a sus proveedores.
• GDPR: La exfiltración de datos personales, a menudo el objetivo final de ataques que utilizan LotL o BYOVD, cae directamente bajo el paraguas de GDPR. Un incidente de este tipo no solo tendrá consecuencias bajo DORA/NIS2, sino también las multas y la reputación devastada que implica una brecha de datos personales.
• AI Act: Aunque más incipiente, la futura Ley de IA podría tener implicaciones. Si los atacantes logran manipular sistemas de IA (por ejemplo, para fraude o manipulación de mercados) utilizando tácticas LotL para evadir la detección, la regulación de la IA también entrará en juego, exigiendo robustez y seguridad en estos sistemas.
• SOX (Sarbanes-Oxley Act): Para las empresas con presencia en EE. UU., la capacidad de garantizar la integridad y disponibilidad de los datos financieros, y de los sistemas que los procesan, es fundamental. Las tácticas de evasión que comprometen la integridad de los datos o la fiabilidad de los sistemas de reporte financiero tendrían un impacto directo en el cumplimiento de SOX.

Conclusión: La batalla silenciosa se recrudece

La era en la que las defensas perimetrales y los antivirus basados en firmas eran suficientes ha quedado, para bien o para mal, en los libros de historia. Los ciberdelincuentes han evolucionado, y con ellos, las regulaciones. DORA y NIS2 no son caprichos burocráticos; son la respuesta necesaria a un panorama de amenazas que ha madurado hasta la sofisticación. Las tácticas de Living off the Land y Bring Your Own Vulnerable Driver son la quintaesencia de esta evolución: demuestran que la confianza, ya sea en las herramientas del propio sistema o en la firma digital de un proveedor, es la nueva superficie de ataque.

Para el sector financiero, el mensaje es claro: la resiliencia operativa digital exige una visibilidad sin precedentes, una gestión de riesgos que contemple lo inesperado y una capacidad de respuesta que vaya más allá de los manuales tradicionales. Aquellas entidades que sigan pensando en la ciberseguridad como un conjunto de casillas a marcar se encontrarán, inevitablemente, en el lado perdedor de esta batalla silenciosa. La hora de la verdad ha llegado, y la evasión de defensas es el examen más duro. ¿Estás realmente preparado para aprobarlo?