synawk

CLOP: Cuando menos es más (?) - Análisis de Malware 0x2

Uno de los malware más significativos que surgió en el año 2023 fue CL0P, un ransomware que aprovechaba diversos exploits, incluyendo el de MOVEit, para infectar los sistemas. El presente análisis se centra en el código empleado en el desarrollo del ransomware, con el objetivo de comprender su estructura y funcionamiento.

El objetivo de esta publicación es revisar de forma técnica lo que pudo haber sido el desarrollo del ransomware CL0P. Como lo menciona el título “menos es más”; esta publicación busca justamente desarrollar este concepto en el ámbito del desarrollo de malware. Muchos piensan que la elaboración de un malware, en este caso, un ransomware, implica un desarrollo de alta complejidad. Sin embargo, nada más alejado de la realidad. El desarrollo de un malware que tenga la capacidad de exfiltrar datos o encriptarlos es bastante sencillo y, de hecho, la estructura en la mayoría de los casos es la misma. Lo que quizá pueda cambiar son los vectores de infección, así como la forma en la que se distribuye; por todo lo demás, en la mayoría de los casos, es lo mismo. Echemos un vistazo.

El ransomware inicia sin mas, cabe mencionar que la ejecucion de este ransomware proviene de probablemente un loader o un malware que ha realizado la persistencia previa. Al iniciar se puede notar en la imagen que realiza una iteracion con un valor de 666000. Como las funciones dentro tienen argumentos invalidos, van a generar error y seran omitidas; sin embargo es una opcion interesante para generar un tiempo muerto por incertidumbre. Es decir que depende la ejecucion tomara mas o menos tiempo del necesario y los EDR/AV no podran avanzar de forma satisfactoria la emulación. Esta primera parte me parecio interesante, ya que no tiene mucho sentido la forma en la que ha sido desarrollado el malware, evidenciando que sus desarrolladores no cuentan con mucha experiencia; esto se podra ver a detalle mas adelante. Continuando con el analisis se puede ver lo siguiente:

procesos CL0P

Como puede observarse en la imagen anterior, el malware ejecuta una función en ciertos archivos que aparentan ser ejecutables, aunque posiblemente posean nombres ligeramente diferentes (por ejemplo, exel.exe, orale.exe, etc.). En la siguiente imagen, se aclara con mayor detalle la acción que realiza el malware: detiene todos estos procesos, lo cual sugiere que está asegurándose de que no haya otra instancia del mismo ransomware en ejecución. Una estrategia bastante común para evitar algún conflicto entre procesos.

detener proceso CL0P

El ransomware es bastante simple y no ofrece mucho más allá de lo que ya se ha mencionado. Al igual que cualquier otro malware de este tipo, contiene una clave pública que se utiliza para cifrar los archivos del equipo afectado. Cabe destacar que solo puede desencriptarse con la correspondiente clave privada.

clop public key

Posteriormente, el ransomware realiza algunas operaciones adicionales, como por ejemplo extraer el README a través de los resources para luego operarlo con una operación XOR y extraer su contenido. Omitiré estos detalles ya que hay mucha información disponible al respecto y no tienen un impacto significativo. Aquí es donde quería llegar: después de todo lo explicado, el ransomware llega a la función principal encargada de llevar a cabo el proceso de búsqueda de archivos y encriptación.

Antes de entrar en la función, proporcionaré un contexto sobre lo común en el procedimiento de un ransomware. Este tipo de malware tiene como objetivo encriptar la mayor cantidad de datos en el menor tiempo posible, evadiendo todos los controles. Por esta razón, es crucial utilizar un algoritmo que recorra todos los archivos posibles de manera eficiente. Para lograr esto, existen dos opciones: DFS o BFS; ambos casos ofrecen una solución para la búsqueda y encriptación.

El problema radica en decidir qué algoritmo es mejor para realizar el encriptado. Otro problema común al desarrollar un ransomware es determinar la ruta de inicio. Se deben evitar rutas como Windows, Program Files, etc. Para todos estos desafíos, los cibercriminales ya han encontrado soluciones, como se ha observado en muchos de los ransomwares que circulan hoy en día y continúan infectando equipos.

Si decides usar un DFS, puede suceder que, si la primera carpeta tiene 30 subcarpetas adicionales, el ransomware probablemente tarde algunos minutos en salir. Y peor aún, si las subcarpetas contienen muchos archivos de gran tamaño, es posible que tarde hasta horas en salir de esas carpetas. Por lo tanto, es más común utilizar BFS. A diferencia del algoritmo DFS, BFS encripta conforme va ingresando. Es decir, si inicia en la ruta A, encripta todo lo que haya en A y luego continúa en A1, pero no va más adentro. Después, pasa a B1 y en ese nivel encripta todo. Esto es una solución aplicada, por ejemplo, por el ransomware Conti, lo que asegura un tiempo menor al momento de encriptar los archivos.

Dicho esto, resulta interesante encontrarse con ransomwares que ni siquiera se molestan en desarrollar código lo suficientemente complejo para intentar evadir controles de seguridad o ser eficientes. Simplemente, con un poco de conocimiento en código, es posible lograr mucho. El ransomware no se complica en absoluto; en una primera fase, encripta todo lo que se encuentra dentro de una carpeta de inicio dada. Para lograrlo, crea un hilo por cada archivo, permitiendo que la operación de encriptación se realice en paralelo, en caso de que tome más tiempo en ejecutarse.

clop encriptacion

Una vez que finaliza, vuelve a realizar la operación, pero esta vez para todos los archivos que encuentre. En todos los casos, se está utilizando DFS, como expliqué líneas arriba acerca de cómo funciona y por qué no es la mejor opción. Finalmente, se crea un hilo para encriptar el archivo, aunque no hace mucha diferencia teniendo en cuenta que utiliza WaitForSingleObject, que es bloqueante. Esto resulta en la creación y destrucción de cientos de hilos, lo cual a menudo puede ser un indicador de malware.

Conclusiones

Más que un análisis de malware, era una serie de comentarios sobre la percepción errónea de que la creación de malware es una tarea compleja que requiere conocimientos extraordinarios, cuando malwares como este demuestran todo lo contrario. Hoy en día, el acceso a información de este tipo se encuentra en cualquier lugar y no es necesario comprender el funcionamiento interno de los sistemas operativos o incluso de la memoria. Por todo esto, se deben desarrollar nuevas y mejores técnicas para detectar no solo firmas o comportamientos casi predefinidos; los sistemas de seguridad deberían ser capaces de prever estos comportamientos y evitar que actúen de la forma en que lo hacen.