Del antivirus que no funcionó al informe pericial: el trabajo que empieza cuando se apagan las alarmas.
La red ya está aislada, los servicios vuelven poco a poco y el equipo de respuesta lleva treinta horas sin dormir. Sobre la mesa queda un fichero de doscientos kilobytes que alguien ha metido en un archivo comprimido con contraseña, y del que se sabe muy poco: que llegó como adjunto de un correo, que se ejecutó a las 03:14 y que el antivirus no dijo nada. La emergencia ha terminado. Pero no, el trabajo, en realidad, acaba de empezar! Alguien tiene que abrir ese fichero, entender qué hizo, quién lo mandó y qué se llevó, y hacerlo de manera que lo que averigüe sirva después ante un juez. De eso trata la guía CCN-STIC-834, «Protección ante código dañino en el ENS», del Centro Criptológico Nacional, y de eso trata este trabajo.
Lo que empieza cuando termina la emergencia
En el trabajo anterior de esta serie recorrimos la guía CCN-STIC-817, dedicada a la gestión de ciberincidentes: cómo se clasifica un ataque, cómo se mide su gravedad, a quién hay que notificarlo y en qué plazos, y cómo se preserva la prueba desde el primer minuto. Aquella guía dejaba al lector en un punto concreto del ciclo, el de la contención y la recuperación, con los sistemas a salvo y las evidencias recogidas. Lo que viene después tiene menos épica y bastante más ciencia. Hay una muestra, y hay que analizarla.
Ese análisis importa por tres motivos que conviene separar. El primero es operativo: hasta que no se sepa qué hacía el programa, nadie puede afirmar con fundamento que el atacante ha salido de la casa, ni saber si dejó una puerta trasera esperando. El segundo es probatorio, porque de la muestra salen las huellas que permiten sostener una acusación, vincular incidentes entre sí y, en el mejor de los casos, orientar la atribución. Y el tercero es preventivo, ya que cada muestra analizada se convierte en indicadores que alimentan las defensas de los demás. La mediana global del tiempo que un intruso permanece dentro de una organización antes de ser descubierto se situó en once días durante 2024, según el informe M-Trends de Mandiant, y sube hasta veintiséis cuando el aviso llega desde fuera. Once días dan para mucho, y reconstruir lo que ocurrió en ellos depende casi siempre de lo que el código dañino cuente de sí mismo.
Qué dice la 834, y qué conviene no pedirle
Conviene situar la guía con precisión, porque su título despista un poco. La CCN-STIC-834 tiene por objeto ayudar a los responsables de seguridad de las entidades sujetas al Esquema Nacional de Seguridad a adoptar una estrategia coherente de herramientas de protección del puesto de usuario, atendiendo a la categoría de seguridad del sistema de que se trate. Su corazón son las dos familias de productos que hoy defienden los equipos: las plataformas de protección del puesto, conocidas por sus siglas inglesas EPP (Endpoint Protection Platform), herederas directas del antivirus de toda la vida, y las herramientas de detección y respuesta, EDR (Endpoint Detection and Response), que vigilan el comportamiento del equipo y permiten intervenir sobre él. La guía, publicada en su edición pública en septiembre de 2018, analiza con detalle qué hace cada una, dónde falla y cómo elegirlas.
El eje conceptual que propone es el ciclo completo de protección, articulado en cuatro fases encadenadas: una primera de protección o prevención, una segunda de detección, una tercera de resolución y respuesta y una cuarta de adaptación, en la que lo aprendido vuelve al sistema en forma de reglas nuevas. Detrás de ese esquema circular hay una premisa que merece subrayarse, porque es la misma que sostenía la 817: ninguna barrera es impenetrable, de modo que la seguridad se juega en la capacidad de detectar, responder y aprender, tanto como en la de prevenir.
La guía no es, y conviene decirlo con claridad, un manual de ingeniería inversa. Quien busque en ella una lección paso a paso sobre cómo desensamblar un troyano se llevará una decepción. Lo que sí ofrece, y resulta valiosísimo para entender el oficio, es la anatomía del problema: por qué el código dañino se escapa de las firmas, qué técnicas emplean los fabricantes para atraparlo —análisis heurístico, emulación, ingeniería inversa y descompilación, sistemas anti-exploit y contra el código que opera sin fichero—, cómo se clasifican los ficheros desconocidos y qué debe exigirse a una herramienta antes de comprarla. A partir de ahí, el análisis concreto de una muestra concreta corresponde al perito, y se apoya en un cuerpo normativo y científico distinto que este artículo también recorre.
Del lado obligacional, la referencia está en el Anexo II del Real Decreto 311/2022, que regula el Esquema Nacional de Seguridad. Su medida op.exp.6, «Protección frente a código dañino», aplica a todas las dimensiones de seguridad y a todas las categorías de sistema. Exige disponer de mecanismos de prevención y reacción con el mantenimiento recomendado por el fabricante, instalar protección en todos los equipos —puestos de usuario, servidores y elementos perimetrales—, analizar todo fichero procedente de fuentes externas antes de trabajar con él, mantener permanentemente actualizadas las bases de datos de detección y configurar los puestos con protección en tiempo real. Sobre esa base añade refuerzos escalonados: escaneo periódico y revisión de las funciones críticas en el arranque para la categoría media, y para la categoría alta, además, lista blanca de aplicaciones autorizadas y, en el refuerzo R4, el empleo de «herramientas de seguridad orientadas a detectar, investigar y resolver actividades sospechosas en puestos de usuario y servidores (EDR)». Merece la pena retener ese detalle, porque significa que en los sistemas de categoría alta el EDR dejó de ser una recomendación comercial para convertirse en una exigencia reglamentaria, con todo lo que ello implica cuando alguien tenga que valorar después si una organización hizo lo que debía.
Por qué el antivirus llegó tarde
La pregunta que formula la víctima de un ataque, casi siempre con más resignación que enfado, es por qué el antivirus que paga religiosamente no vio nada. La respuesta está en uno de los conceptos centrales de la 834, el de la ventana de exposición o ventana de oportunidad, y tiene una lógica que se entiende bien en cuanto se dibuja.
El modelo clásico de detección depende de la firma: una huella característica que identifica a una muestra concreta y que el fabricante distribuye a todos sus clientes. Para que esa firma exista hay que recorrer antes un camino completo. Alguien debe encontrarse con la muestra y remitirla al fabricante; el laboratorio analiza su morfología y su comportamiento; la clasifica; extrae el identificador que la representa; modifica el fichero de firmas y lo despliega a la totalidad de sus clientes. Cada uno de esos pasos consume tiempo, y todo el tiempo que transcurre desde que el código empieza a circular hasta que la firma aterriza en el equipo del usuario es tiempo en que la víctima está desprotegida frente a esa amenaza precisa, por mucho que su antivirus esté al día.
El problema se agrava con la escala. El instituto AV-TEST registra más de cuatrocientos cincuenta mil programas maliciosos y aplicaciones potencialmente indeseadas nuevos cada día. Buena parte de ese volumen procede de variantes generadas automáticamente, versiones del mismo código recompiladas, cifradas o empaquetadas de forma ligeramente distinta con el único fin de que la huella cambie. Basta modificar un byte para que el resumen criptográfico del fichero sea otro, y con él la firma que lo identificaba. Perseguir muestras una a una en ese escenario es un ejercicio de agotamiento.
De ahí que la industria haya ido apilando capas por encima de la firma. El análisis heurístico busca rasgos sospechosos en la estructura del fichero sin necesidad de conocerlo. La emulación ejecuta el código en un entorno simulado dentro del propio motor, para ver qué pretende hacer antes de dejarle tocar el sistema real. Los módulos anti-exploit vigilan las maniobras típicas del abuso de una vulnerabilidad, con independencia del programa que las intente. Y el EDR completa el cuadro desplazando la vigilancia desde el fichero hacia la conducta: registra de forma continua lo que ocurre en el equipo —procesos que nacen, ficheros que se escriben, conexiones que se abren, claves de registro que se modifican— y busca patrones anómalos en esa telemetría, lo que le permite además contener el incidente bloqueando el proceso dañino, aislando el equipo de la red o dando acceso remoto al analista para trabajar sobre el sistema afectado. Este desplazamiento del qué es al qué hace resulta decisivo para el trabajo pericial, porque la telemetría del EDR se convierte, cuando existe, en la mejor reconstrucción disponible de lo que sucedió aquella madrugada.
Ninguna de estas capas es infalible, y la propia guía es honesta al respecto: cada una compra detección a cambio de falsos positivos y de consumo de recursos, dos costes que la organización acaba pagando de un modo u otro. La lista blanca de aplicaciones que exige el refuerzo R3 del ENS para la categoría alta es, seguramente, la medida más eficaz de todas las descritas, y también la más incómoda de administrar en un entorno con miles de puestos y usuarios que instalan cosas.
Las familias del código dañino
Bajo la etiqueta «malware» conviven cosas muy distintas, y el jurista que ha de calificar unos hechos agradece tener el mapa ordenado. La clasificación más útil no atiende al nombre comercial que le pone cada fabricante, sino a tres preguntas: cómo se propaga, para qué sirve y qué papel juega dentro de la operación.
Por su forma de propagarse, la distinción clásica separa el virus, que necesita adherirse a un fichero anfitrión y que alguien lo ejecute; el gusano, capaz de saltar por sí solo de una máquina a otra aprovechando una vulnerabilidad o una credencial válida; y el troyano, que se presenta como algo deseable para que la propia víctima lo instale. Esta última familia es hoy la reina indiscutible, porque el camino más corto hacia dentro de una organización sigue pasando por convencer a una persona.
Por su función, el catálogo es más variado. La puerta trasera y su versión sofisticada, la herramienta de administración remota, otorgan al atacante control del equipo como si estuviera sentado delante. El ladrón de credenciales rastrea navegadores, gestores de contraseñas y carteras de criptomoneda, y suele ser la avanzadilla de intrusiones mayores. El programa espía registra pulsaciones de teclado, capturas de pantalla o conversaciones. El criptominero se limita a robar capacidad de cálculo, un daño menor en apariencia que se traduce en facturas eléctricas y equipos agotados. El rootkit se instala en las capas profundas del sistema para hacerse invisible al propio sistema operativo. El ransomware cifra la información y exige un rescate. Y el borrador, o wiper, destruye sin pedir nada a cambio, lo que casi siempre delata una motivación distinta de la económica y aproxima el caso al terreno del sabotaje o del conflicto entre Estados.
Por su papel en la operación, conviene conocer una división que aparece en cualquier informe técnico y que confunde a quien no la espera. El cuentagotas, o dropper, es el fichero pequeño que llega primero y cuya única misión es traer al resto; el cargador, o loader, se encarga de descifrar y poner en marcha la carga útil; y esta, la carga útil propiamente dicha, es el programa que hace el daño. Un mismo incidente puede implicar tres o cuatro piezas distintas, escritas por autores distintos y alquiladas en mercados distintos, y confundir el cuentagotas con la carga útil lleva a conclusiones equivocadas sobre la gravedad de lo ocurrido y sobre quién estaba detrás.
Esta anatomía se apoya, en el plano de la clasificación oficial, en la taxonomía de la 817, donde el código dañino constituye una de las nueve clases de incidente y se despliega en subtipos que distinguen el sistema infectado, el que distribuye la infección y el que actúa como servidor de mando y control. Nombrar bien la pieza es el primer paso para encajarla en el tipo penal que corresponda.
Cómo entra y cómo se queda
Un ataque serio rara vez consiste en un solo movimiento. Se despliega por fases, y cada fase deja rastros de naturaleza distinta en lugares distintos. Conocer esa secuencia es lo que permite a un investigador saber dónde mirar, y a un abogado entender por qué su cliente tardó tres semanas en enterarse.
Todo empieza con el acceso inicial, que en la inmensa mayoría de los casos llega por una de tres vías: un correo con adjunto o enlace, un servicio expuesto a internet con una vulnerabilidad sin parchear, o unas credenciales válidas compradas a un tercero. Conseguido el punto de entrada, el atacante necesita ejecutar su código y, acto seguido, asegurarse de que sobrevive a un reinicio, lo que se conoce como persistencia y que en la práctica significa una tarea programada, un servicio nuevo o una clave del registro que devuelve el programa a la vida en cada arranque. Después viene la escalada de privilegios, para pasar de una cuenta corriente a una de administración, y la evasión de defensas, donde el intruso desactiva el antivirus, detiene el agente de seguridad o borra los registros que documentan su paso. Con permisos altos roba credenciales, explora la red, se mueve lateralmente hacia los servidores que le interesan y mantiene abierta una conversación con su servidor de mando y control. El final llega con la exfiltración de datos y el impacto, el momento en que la víctima descubre que algo pasa porque sus ficheros están cifrados o su servicio ha dejado de funcionar.
Para el análisis posterior, la utilidad de este mapa es doble. Por un lado, indica dónde buscar cada cosa: las cabeceras del correo y los registros del cortafuegos hablan de la entrada; la línea de comandos del proceso hijo, de la ejecución; una tarea programada creada a las tres de la madrugada, de la persistencia; el volumen inusual de tráfico saliente, de la exfiltración. Por otro, permite razonar sobre lo que falta. Un hueco de seis horas en un registro que se genera cada minuto es un dato en sí mismo, porque alguien tuvo que borrarlo, y esa ausencia deliberada tiene un valor indiciario que un tribunal entiende sin dificultad.
Parte I · Para el perito y el profesional del derecho
La muestra es una evidencia, y además está viva
Antes de analizar nada hay que asumir una doble naturaleza que no tiene equivalente cómodo en la prueba física. El fichero sospechoso es, al mismo tiempo, una evidencia que debe conservarse íntegra y trazada, y un artefacto peligroso capaz de infectar el equipo del propio perito si se maneja con descuido. Las dos condiciones tiran en direcciones opuestas, y todo el protocolo de trabajo consiste en satisfacerlas a la vez.
Como evidencia, la muestra sigue las reglas que ya conocemos del trabajo anterior: se calcula su resumen criptográfico —hoy SHA-256— en el momento de la adquisición, se documenta de dónde salió, quién la obtuvo y cuándo, y se trabaja siempre sobre copias, nunca sobre la pieza original. La norma ISO/IEC 27037 cubre la identificación, recogida, adquisición y preservación; la 27042 se ocupa específicamente del análisis y la interpretación, que es la fase en la que ahora estamos, y la 27041 de algo que en el análisis de código dañino resulta crítico, la garantía de idoneidad del método empleado.
Como artefacto peligroso, la muestra se guarda inerte. La práctica del oficio es sencilla y casi universal: comprimirla en un contenedor cifrado con una contraseña convenida, cambiar la extensión del fichero para que ningún doble clic accidental lo ejecute, y transportarla únicamente por canales cifrados. Nada de enviarla por correo a un compañero «para que le eche un vistazo», y desde luego nada de dejarla en un directorio compartido.
Hay un error, muy extendido y aparentemente inocente, que merece párrafo propio: subir la muestra a un servicio público de análisis. Plataformas como VirusTotal son de una utilidad enorme para consultar si un resumen criptográfico es conocido, y esa consulta por hash no revela nada. Subir el fichero completo es otra cosa. En el servicio gratuito, la muestra pasa a estar disponible de forma permanente para los fabricantes asociados y para los clientes de pago de la plataforma, que pueden descargarla. Si ese fichero es un documento ofimático con datos de la organización, un instalador corporativo con credenciales embebidas o una nota de rescate personalizada, lo que acaba de ocurrir es una segunda brecha, esta vez causada por el investigador. Y hay más: la subida es observable. Un atacante que vigila si su herramienta aparece en el servicio sabrá, en cuanto la vea, que ha sido descubierto, y reaccionará borrando su infraestructura antes de que nadie pueda documentarla. La regla prudente consiste en consultar siempre por hash, y subir el fichero solo tras una decisión consciente, valorando el riesgo de fuga de información y el de alertar al adversario, y empleando en su caso las modalidades de análisis privado.
Las primeras preguntas que se le hacen a un fichero
El análisis de una muestra progresa como un embudo, de lo barato y rápido a lo caro y lento, y en cada nivel se descarta lo que ya no hace falta mirar. El primer nivel es el triaje, y responde a preguntas elementales con herramientas que no ejecutan nada.
Se empieza por el resumen criptográfico, que permite consultar si la muestra es conocida. Se identifica después el tipo real de fichero por su estructura interna, sin fiarse de la extensión, porque un supuesto documento puede ser un ejecutable con el nombre cambiado. Se examina la cabecera del ejecutable, que en el mundo Windows revela la fecha de compilación, las secciones que lo componen y, sobre todo, la tabla de funciones que importa del sistema operativo: un programa que solicita capacidades de cifrado, de acceso a la red y de manipulación de procesos ya está declarando bastante sobre sus intenciones. Se extraen las cadenas de texto legibles, que a veces regalan direcciones de servidores, rutas de compilación con el nombre de usuario del autor o mensajes de rescate. Y se mide la entropía de cada sección, esto es, su grado de desorden estadístico: un valor muy alto delata que el contenido está cifrado o comprimido, lo que en un ejecutable normal no tiene demasiado sentido y sugiere el uso de un empaquetador para ocultar el código verdadero.
A ese nivel pertenecen también las reglas YARA, un lenguaje que permite describir patrones característicos de una familia de código dañino y buscarlos después en cualquier conjunto de ficheros. Para el perito son especialmente útiles por una razón práctica: una regla bien escrita puede aplicarse a todo el parque informático de la organización para averiguar dónde más estuvo la misma amenaza, y esa respuesta suele ser la que de verdad interesa al cliente y al juzgado.
Abrirlo sin ejecutarlo
El siguiente escalón es el análisis estático, que estudia el programa como se estudia un documento: leyéndolo. Con un desensamblador se reconstruye la lógica del código, se localizan las rutinas de cifrado, las comprobaciones que hace el programa antes de actuar y las direcciones de los servidores con los que pretende comunicarse. La ventaja del método es que ofrece la visión completa de lo que el programa puede hacer, incluidas las ramas que en una ejecución concreta nunca llegarían a activarse, como la que solo se dispara en una fecha determinada o cuando detecta que está en la red de una organización concreta.
Su desventaja es el coste y la resistencia que ofrece el adversario. La ofuscación, el empaquetado y el cifrado de cadenas están pensados precisamente para que esta lectura sea inviable en un tiempo razonable, y buena parte del trabajo de un analista consiste en deshacer esas capas antes de poder leer nada. Un programa protegido con un empaquetador comercial puede exigir días de trabajo especializado; uno escrito en un lenguaje que compila a código intermedio, en cambio, se deja leer casi como si dispusiéramos del original.
Dejarlo correr dentro de una jaula
Cuando el análisis estático se atasca, o simplemente para confirmar lo que sugiere, se pasa al análisis dinámico: ejecutar la muestra y observar lo que hace. La condición imprescindible es el aislamiento. El laboratorio es una máquina virtual desechable, en una red separada de la de producción y sin salida real a internet, con instrumentación que registra la creación de procesos, los cambios en el sistema de ficheros y en el registro, y todo el tráfico que la muestra intenta generar. Ese tráfico se atiende con servicios simulados, de modo que el programa crea estar hablando con su servidor de mando y control mientras en realidad conversa con un señuelo que lo apunta todo. Antes de empezar se toma una instantánea del sistema, y al terminar se vuelve a ella, lo que permite repetir el experimento tantas veces como haga falta desde un estado idéntico. Esa repetibilidad, dicho sea de paso, es también lo que exige la norma ISO/IEC 27042 para que un análisis merezca ser llamado así.
El adversario, claro está, conoce el procedimiento. La literatura científica ha documentado con detalle el repertorio de técnicas de evasión que el código dañino emplea para detectar que está siendo analizado y comportarse entonces como un programa inofensivo. Afianian y sus colaboradores, en una revisión publicada en ACM Computing Surveys, clasifican esas maniobras y constatan que la mayor parte del comportamiento evasivo se dedica precisamente a detectar y esquivar los entornos de análisis automatizado. Las hay burdas y sofisticadas: comprobar si existen procesos o controladores propios de la virtualización, medir si el reloj avanza de forma extraña, esperar veinte minutos antes de hacer nada porque los análisis automáticos suelen durar menos, o exigir señales de que hay una persona al otro lado, como el movimiento del ratón o la presencia de documentos recientes. La contramedida pasa por endurecer el laboratorio hasta que parezca un puesto de trabajo real y por combinar siempre los dos métodos, porque lo que el análisis dinámico no ve suele estar escrito en el código que el análisis estático sí puede leer. Or-Meir y su equipo, en una revisión igualmente publicada en ACM Computing Surveys, repasan el estado del arte de estas técnicas y la resistencia de cada una frente a la evasión, y su conclusión práctica es la que cualquier analista con oficio suscribiría: ningún método basta por sí solo.
Conviene añadir un matiz que rara vez se explica y que tiene consecuencias periciales. El análisis dinámico documenta lo que la muestra hizo en ese entorno y durante ese tiempo, y de ahí no cabe concluir sin más lo que hizo en el equipo de la víctima. Un programa que en el laboratorio no contactó con nadie pudo hacerlo perfectamente en la red real, donde encontraba el dominio, el usuario o la ruta de red que esperaba. El informe honesto describe las condiciones del experimento y se abstiene de convertir una ausencia de observación en una afirmación de inexistencia.
Cuando no hay fichero que analizar
Queda el caso incómodo, cada vez más frecuente, en el que no hay nada que llevarse al laboratorio. El código dañino sin fichero —fileless, en la terminología habitual— no escribe un ejecutable en el disco: se aloja en la memoria del equipo y se vale de programas legítimos que ya están instalados, como el intérprete de comandos del sistema, sus herramientas de administración remota o los mecanismos de automatización del propio sistema operativo. Esta forma de operar, revisada en detalle por Sudhakar y Kumar en la revista Cybersecurity, deja al antivirus tradicional sin objeto sobre el que trabajar, porque no hay fichero que escanear, y complica la investigación posterior por una razón que el jurista reconocerá al instante: la evidencia se desvanece con el apagado.
Aquí se anuda con toda claridad la enseñanza de la 817. El orden de volatilidad del RFC 3227 obliga a recoger primero lo que antes desaparece, y en estos casos la memoria RAM del equipo comprometido es, sencillamente, la única prueba que existe. Un volcado de memoria tomado antes de apagar puede conservar el código malicioso descifrado y desempaquetado, las claves de cifrado, los comandos que se estaban ejecutando y las conexiones abiertas con el servidor del atacante. La misma máquina, apagada y reiniciada con la mejor de las intenciones, no conserva nada. Conviene además saber que el volcado de memoria tiene otra virtud para el análisis: como el código empaquetado ha de descifrarse a sí mismo para poder ejecutarse, la memoria contiene con frecuencia la versión legible de un programa que en disco resultaba ilegible.
El rastro del EDR: la telemetría como fuente de prueba
Cuando el fichero no existe o ha sido borrado, y a veces incluso cuando existe, la reconstrucción de lo ocurrido descansa sobre los registros. Aquí conviene traer una segunda medida del Esquema Nacional de Seguridad que suele pasar desapercibida y que en la práctica pericial vale su peso en oro: op.exp.8, «Registro de la actividad», adscrita a la dimensión de trazabilidad.
Su exigencia básica consiste en generar un registro de auditoría que incluya, al menos, el identificador del usuario o entidad asociado al evento, la fecha y la hora, sobre qué información se realiza, de qué tipo de evento se trata y cuál fue su resultado, con éxito o con fallo, y en activar los registros de actividad en los servidores. Los refuerzos añaden lo que convierte esos registros en prueba utilizable: la revisión periódica en busca de patrones anormales, una referencia de tiempo fiable cuya modificación queda reservada a la administración y cuya sincronización debe ir protegida con mecanismos de autenticación e integridad, la definición documentada de qué eventos se auditan y cuánto tiempo se conservan antes de eliminarse, la restricción del acceso y del borrado de los registros al personal debidamente autorizado, y, en el nivel alto de trazabilidad, la recolección automática con correlación de eventos.
Cada uno de esos requisitos responde, sin nombrarla, a una objeción clásica de la defensa. La marca de tiempo protegida contesta a quien discute la cronología. El control de acceso a los registros responde a quien insinúa que alguien pudo manipularlos. La política documentada de retención explica por qué existen los registros de hace cuatro meses y no los de hace catorce, sin que esa ausencia parezca sospechosa ni interesada. Y la correlación automática es la que permite afirmar que el mismo actor tocó dos servidores distintos con veinte minutos de diferencia.
De ahí se sigue un consejo práctico para el jurista que asesora a una organización. La pregunta que conviene hacer antes de que ocurra nada no es si hay antivirus, sino cuánto tiempo se guarda la telemetría del puesto y del servidor. Una retención de siete días convierte en imposible la investigación de una intrusión que se descubre a las tres semanas, y ese plazo, en el escenario que describe el informe de Mandiant, es de lo más corriente. Los registros que no se conservaron no se pueden reclamar después a nadie, y su falta se paga en forma de conclusiones que se quedan a medias.
De la muestra al adversario
El análisis termina produciendo algo que se puede compartir y utilizar: los indicadores de compromiso, elementos observables que permiten reconocer la misma amenaza en otro sitio. Son de naturaleza muy distinta entre sí, y esa diferencia importa. El resumen criptográfico de un fichero identifica una muestra exacta y deja de valer en cuanto el atacante recompila. Una dirección de red o un nombre de dominio duran algo más, aunque se cambian con un par de clics. Los artefactos que el programa deja en el sistema —una clave de registro concreta, un nombre de servicio, un fichero en una ruta característica— resisten mejor. Y en lo más alto están las tácticas, técnicas y procedimientos, la forma de operar del grupo atacante, que responde a hábitos y a herramientas propias y no puede modificarse sin rehacer su método de trabajo.
Esa jerarquía es la que popularizó David Bianco con el nombre de pirámide del dolor, en referencia a la molestia que causa al adversario cada nivel de detección. Detectar por hash no le cuesta nada; detectar por comportamiento lo obliga a reinventarse. El catálogo MITRE ATT&CK proporciona hoy el vocabulario compartido para nombrar esas técnicas, y traducir a él los hallazgos del laboratorio convierte un informe técnico en algo comparable con lo que han visto otros. En el ámbito español, la plataforma REYES del CCN-CERT cumple la función de intercambiar esos indicadores entre organismos, del mismo modo que LUCIA canaliza la notificación de los incidentes.
Para el criminólogo, este es el punto donde el análisis de código dañino se convierte en algo muy parecido a la perfilación. Un mismo grupo reutiliza su código, sus servidores, sus horarios de trabajo y sus manías de programador, y esas constantes permiten agrupar incidentes aparentemente inconexos bajo una misma autoría probable. Los detalles menores resultan a veces los más elocuentes: el idioma del teclado con que se compiló el binario, la zona horaria en que se registraron los dominios, el patrón de actividad de lunes a viernes que delata una organización con horario de oficina, o la ruta de compilación que conserva el nombre de usuario del desarrollador.
Conviene, eso sí, mantener la cautela que impone el oficio. Los indicadores técnicos sostienen con solidez la identificación de una campaña, y son mucho más frágiles cuando se pretende con ellos señalar a una persona. La infraestructura se alquila, las herramientas se comparten y se filtran, y las pistas se colocan a veces a propósito para engañar al analista. Un grupo que quiera hacerse pasar por otro tiene medios sencillos para conseguirlo: reutilizar código público atribuido a un tercero, escribir sus mensajes en un idioma que no es el suyo o trabajar deliberadamente en un huso horario ajeno. Un informe pericial serio distingue con nitidez entre lo que la muestra demuestra, lo que meramente sugiere y lo que podría estar puesto ahí para despistar.
Que el análisis aguante en el juzgado
El eslabón final es el informe, y en él se aplican las mismas exigencias que en cualquier otra pericia. El método debe estar documentado y ser reproducible por un tercero: qué herramientas se usaron y con qué versión, sobre qué copia se trabajó, qué resumen criptográfico tenía, en qué entorno se ejecutó y durante cuánto tiempo. Las conclusiones deben separarse escrupulosamente de las observaciones, de modo que el tribunal pueda ver dónde acaba lo medido y dónde empieza la interpretación del perito. Y las limitaciones deben declararse, porque un análisis dinámico que duró cinco minutos no autoriza a afirmar que el programa no hacía nada más pasados diez.
Puestos a concretar, un informe de análisis de código dañino que aspire a sostenerse suele articularse en unas cuantas piezas fijas. Comienza por el objeto y el encargo, esto es, quién lo pide y qué pregunta se le formula al perito, porque de ahí depende el alcance de todo lo demás. Sigue con la identificación de la muestra: nombre original, tamaño, tipo de fichero, resúmenes criptográficos y momento exacto de la adquisición. Continúa con la cadena de custodia, el relato ordenado de quién tuvo la pieza, cuándo, cómo y por qué, desde su obtención hasta el laboratorio. Después describe el entorno y las herramientas, con versiones concretas, y la metodología seguida, con mención de los estándares que la respaldan. El grueso lo ocupan los hallazgos, presentados como observaciones verificables antes que como interpretaciones. De ellos se extraen los indicadores de compromiso, en una lista que el cliente pueda aplicar en su red y que otro perito pueda comprobar. Vienen luego las conclusiones, redactadas con el grado de certeza que corresponda a cada una y sin trasladar al terreno de la afirmación lo que sigue siendo una hipótesis razonable. Y se cierra con las limitaciones, que lejos de debilitar el trabajo lo refuerzan, porque un perito que dice hasta dónde llega su análisis es un perito al que resulta difícil desacreditar en la vista.
La familia de normas ISO/IEC ya citada ofrece el respaldo internacional para justificar esas decisiones, y su cita en el informe no es un adorno: acredita que el método empleado responde a un estándar reconocido y no a la ocurrencia del analista. Añádase un detalle que los tribunales aprecian y que se olvida con frecuencia: conservar la muestra y el entorno de análisis permite que la contraparte repita el experimento. Una pericia que no puede rehacerse vale poco frente a una impugnación bien planteada.
Qué se hace con la muestra cuando todo termina
Cerrado el informe queda una cuestión que casi nunca aparece en los manuales y que da bastantes disgustos: dónde acaba el fichero. La muestra sigue siendo, a la vez, una pieza de convicción y un objeto peligroso, y su custodia posterior debe estar decidida de antemano.
Lo prudente es conservarla mientras el asunto pueda tener recorrido, en un repositorio cifrado, con acceso restringido y registro de consultas, separado de la red de trabajo y con una copia de la documentación que la acompaña. Esa conservación tiene un plazo, que conviene fijar por escrito en el propio informe o en el contrato de encargo, y una forma de terminar: la destrucción documentada, con constancia de quién la ordenó y cuándo, o la entrega al juzgado si así se dispone. Las tres decisiones —conservar, destruir o entregar— son legítimas; lo que no resulta defendible es que la muestra ande por ahí en el portátil de alguien, en una carpeta compartida o en un servicio de almacenamiento en la nube contratado a título personal.
Merece una mención el caso de las muestras que contienen datos personales, más frecuente de lo que parece, porque los ladrones de credenciales suelen llevar dentro las capturas de lo robado. Ese contenido convierte el repositorio de muestras en un tratamiento de datos con todas sus consecuencias, y obliga a pensarlo desde el principio con las mismas cautelas que cualquier otro archivo sensible del despacho o del laboratorio.
Parte II · Para la empresa y el particular
Tienes un fichero sospechoso
La escena doméstica de todo esto es un correo con un adjunto raro, un instalador descargado de un sitio dudoso o un archivo que el antivirus ha puesto en cuarentena sin más explicación. Lo que conviene hacer se resume en pocas reglas.
La primera es no ejecutarlo para ver qué pasa, ni siquiera en un ordenador viejo que «total, no tiene nada dentro», porque ese ordenador está conectado a la misma red que los demás. La segunda es no reenviarlo a nadie: ni al informático de la empresa por correo, ni al grupo de la oficina para avisar. Reenviar una muestra multiplica las copias circulando y las oportunidades de que alguien haga doble clic por error. Si hay que entregarla a un profesional, lo correcto es comprimirla con contraseña y comunicarla por un canal distinto. La tercera es no borrarla, aunque el impulso sea ese: mientras el fichero exista, existe la posibilidad de saber qué ocurrió; una vez borrado, queda el relato de la víctima y poco más. La cuarta es anotar el contexto —de dónde llegó, a qué hora, quién lo abrió, qué se vio en pantalla—, porque ese contexto suele ser tan valioso como la propia muestra.
Y una regla más, específica del asunto que nos ocupa: cuidado con subirlo a un servicio público de análisis. Consultar si el fichero es conocido, mediante su huella criptográfica, no tiene ningún riesgo y está al alcance de cualquiera. Subir el fichero entero puede publicar sin querer información confidencial de la empresa y avisar al atacante de que ha sido detectado. Ante la duda, esa decisión corresponde a quien vaya a llevar la investigación.
El ransomware y la pregunta del pago
Antes o después, en cualquier incidente de cifrado alguien formula la pregunta incómoda. Conviene responderla con datos y sin dramatismo.
La postura de las autoridades es clara y constante: el INCIBE recomienda no pagar, y el motivo principal es que el pago no garantiza nada. Quien paga se queda sin dinero, sigue sin saber cómo entraron y, con frecuencia, recupera solo una parte de la información, porque las herramientas de descifrado que entregan los atacantes suelen ser tan defectuosas como cabría esperar de un producto sin servicio posventa. A eso se suma el efecto agregado: cada rescate pagado financia la siguiente campaña y confirma al grupo que su modelo funciona. Antes de plantearse cualquier otra cosa, conviene comprobar si existe una herramienta gratuita de recuperación para esa familia concreta en el portal No More Ransom, la iniciativa conjunta de Europol y la industria de seguridad que reúne descifradores publicados para decenas de variantes.
Hay además un cambio en el modelo criminal que altera por completo el cálculo. El ransomware moderno rara vez se limita a cifrar: antes de hacerlo, roba la información y amenaza con publicarla, práctica conocida como doble extorsión. La consecuencia jurídica es importante y se pasa por alto con frecuencia: aunque la organización recupere sus datos con una copia de seguridad impecable y no pague un céntimo, sigue habiendo una brecha de confidencialidad, con el deber de notificarla a la Agencia Española de Protección de Datos en el plazo de setenta y dos horas y, si el riesgo para los afectados es alto, de comunicárselo también a ellos. Pagar tampoco resuelve ese frente, porque nada asegura que el atacante borre de verdad lo que se llevó, y la promesa de un extorsionador tiene el valor que cabe suponerle.
De ahí que la decisión, si llega a plantearse, deba tomarse con asesoramiento jurídico, documentada por escrito y con conocimiento de dos cosas: que el destinatario del pago puede estar sujeto a medidas restrictivas internacionales, lo que añade un problema de cumplimiento normativo sobre el que conviene informarse antes de transferir nada, y que el rescate no cancela ninguna de las obligaciones de notificación. Mientras se discute, hay algo que sí debe hacerse en todo caso: conservar la nota de rescate, las direcciones de contacto, los identificadores de campaña y una muestra de los ficheros cifrados. Ese material es exactamente lo que permite identificar la familia, buscar un descifrador y, llegado el caso, sostener la denuncia.
Por qué el antivirus no lo vio, y qué se le puede exigir
La ventana de exposición explicada más arriba responde a la pregunta de por qué un producto correctamente instalado y actualizado puede dejar pasar una amenaza. Ningún fabricante conoce hoy lo que se ha creado esta mañana, y con cuatrocientos cincuenta mil muestras nuevas al día ninguno puede prometer lo contrario. Lo razonable es dejar de medir un antivirus por su capacidad de detectarlo todo y empezar a medirlo por lo que hace cuando algo se le escapa.
Con ese criterio, hay preguntas concretas que conviene hacer antes de contratar o renovar una herramienta de seguridad. Si dispone de capacidades de detección que no dependan de la firma, como el análisis de comportamiento o la protección frente al abuso de vulnerabilidades. Si registra la actividad del equipo de forma que después pueda reconstruirse lo ocurrido, y durante cuánto tiempo conserva ese registro, que es el dato que decide si una investigación es posible o imposible. Si permite aislar un equipo de la red desde la consola, sin tener que ir físicamente a desenchufarlo. Y qué impacto tiene todo ello en el rendimiento de las máquinas, una cuestión nada menor que la propia guía 834 trata con detenimiento, porque una herramienta que ralentiza el trabajo acaba desactivada por el usuario.
Para las administraciones públicas y sus proveedores, además, esto ha dejado de ser una elección libre. El ENS impone la protección frente a código dañino en todas las categorías, y en la categoría alta exige lista blanca de aplicaciones y herramientas de tipo EDR. Quien tenga que acreditar el cumplimiento hará bien en leer despacio la medida op.exp.6 y sus refuerzos, y en repasar de paso la op.exp.8, porque de la retención de los registros depende que un incidente pueda investigarse o haya que darlo por perdido.
Reinstalar o conservar
Queda una decisión que casi nadie plantea a tiempo y que conviene tomar con los ojos abiertos. Tras un compromiso profundo, la recomendación técnica más segura es reconstruir el equipo desde cero, porque nadie puede garantizar al cien por cien que no quede un mecanismo de persistencia agazapado. Esa reconstrucción, sin embargo, destruye la escena.
La salida sensata consiste en separar los dos objetivos en el tiempo. Primero se adquiere la evidencia: una imagen forense del disco y, si el equipo sigue encendido, un volcado de la memoria; ambas cosas con sus huellas criptográficas y su registro de custodia. Después se reconstruye el sistema con toda la agresividad que haga falta. Hacerlo en ese orden cuesta unas horas; hacerlo al revés cuesta el caso entero. Y conviene que la decisión quede documentada, con la hora y el nombre de quien la tomó, porque en un litigio posterior alguien preguntará por qué se hizo lo que se hizo.
Conviene recordar también que la reinstalación no cierra el asunto por sí sola. Si la entrada fue una credencial robada, el equipo nuevo se compromete igual de rápido que el viejo mientras esa contraseña siga siendo válida en algún sitio. La reconstrucción se acompaña siempre de la rotación de credenciales, la revisión de los accesos remotos y el parcheo de la vulnerabilidad que sirvió de puerta, y sin ese paquete completo lo único que se consigue es reiniciar el reloj del ataque.
Lo que queda cuando el fuego se apaga
La 834 se escribió para que los responsables de seguridad de la Administración eligieran bien sus herramientas, y ese propósito modesto encierra una lección que va bastante más allá. Nos recuerda que la protección frente al código dañino es un ciclo y no un producto, que la detección siempre llega con retraso respecto a la creación, y que ese retraso solo se acorta si alguien, en algún sitio, se pone a analizar la muestra y comparte lo que encuentra.
El analista que abre un fichero sospechoso en un laboratorio aislado hace un trabajo que se parece mucho al del médico forense ante una muerte sin explicar. Reconstruye una historia a partir de rastros que el autor no pretendió dejar, distingue lo que la evidencia demuestra de lo que solo insinúa, y escribe un informe que otros deberán poder revisar. La diferencia práctica está en que aquí el objeto de estudio puede morder si se maneja sin método, y en que el resultado, además de explicar lo ocurrido, sirve para que el siguiente no caiga.
Con esta entrega, la serie que venimos dedicando a las guías del Centro Criptológico Nacional completa el recorrido natural de un incidente: la 817 enseñó a clasificarlo, medirlo, notificarlo y preservar sus pruebas; la 834 explica de qué está hecho el arma y cómo se examina. Queda pendiente el paso siguiente, el de convertir todo ese conocimiento en inteligencia sobre quién está al otro lado, que es el territorio de la CCN-STIC-425 y de las herramientas del ecosistema del CCN. Volveremos sobre ello.
Bibliografía
Afianian, A., Niksefat, S., Sadeghiyan, B., & Baptiste, D. (2019). Malware dynamic analysis evasion techniques: A survey. ACM Computing Surveys, 52(6), Artículo 126. https://doi.org/10.1145/3365001
AV-TEST Institute. (2026). Malware statistics & trends report. AV-TEST GmbH. https://www.av-test.org/en/statistics/malware/
Bianco, D. (2013, 1 de marzo). The pyramid of pain [Entrada de blog]. Enterprise Detection & Response. https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
Brezinski, D., & Killalea, T. (2002). Guidelines for evidence collection and archiving (RFC 3227). Internet Engineering Task Force. https://doi.org/10.17487/RFC3227
Centro Criptológico Nacional. (2018). CCN-STIC-834. Protección ante código dañino en el ENS [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/es/series-ccn-stic/800-guia-esquema-nacional-de-seguridad/3034-ccn-stic-834-proteccion-ante-codigo-danino-en-el-ens
Centro Criptológico Nacional. (2020). CCN-STIC-817. Esquema Nacional de Seguridad. Gestión de ciberincidentes [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/es/series-ccn-stic/800-guia-esquema-nacional-de-seguridad/988-ccn-stic-817-gestion-de-ciberincidentes
Instituto Nacional de Ciberseguridad. (s. f.). No pagues ningún rescate si un ransomware ha cifrado tu información. INCIBE. https://www.incibe.es/ciudadania/blog/no-pagues-ningun-rescate-si-un-ransomware-ha-cifrado-tu-informacion
International Organization for Standardization. (2012). ISO/IEC 27037:2012. Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence. ISO.
International Organization for Standardization. (2015). ISO/IEC 27042:2015. Information technology — Security techniques — Guidelines for the analysis and interpretation of digital evidence. ISO.
Mandiant. (2025). M-Trends 2025: Data, insights and recommendations from the frontlines. Google Cloud. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025
Ministerio de Asuntos Económicos y Transformación Digital. (2022). Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. Boletín Oficial del Estado, 106. https://www.boe.es/eli/es/rd/2022/05/03/311
MITRE Corporation. (s. f.). MITRE ATT&CK: Enterprise matrix. https://attack.mitre.org/
No More Ransom. (s. f.). No More Ransom [Portal de descifradores gratuitos]. Europol, Politie y socios del sector. https://www.nomoreransom.org/
Or-Meir, O., Nissim, N., Elovici, Y., & Rokach, L. (2019). Dynamic malware analysis in the modern era: A state of the art survey. ACM Computing Surveys, 52(5), Artículo 88. https://doi.org/10.1145/3329786
Parlamento Europeo y Consejo de la Unión Europea. (2016). Reglamento (UE) 2016/679, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales (Reglamento General de Protección de Datos). Diario Oficial de la Unión Europea, L 119. https://eur-lex.europa.eu/eli/reg/2016/679/oj
Souppaya, M., & Scarfone, K. (2013). Guide to malware incident prevention and handling for desktops and laptops (NIST Special Publication 800-83 Rev. 1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-83r1
Sudhakar, & Kumar, S. (2020). An emerging threat fileless malware: A survey and research challenges. Cybersecurity, 3, Artículo 1. https://doi.org/10.1186/s42400-019-0043-x
Deja una respuesta