optiv/freeze.rsFreeze.rs es un kit de herramientas de payloads para evadir EDRs mediante procesos suspendidos y syscalls directas escritas en RUST.
Para ver la última versión de Freeze.rs o enviar un problema, consulta https://github.com/Tylous/Freeze.rs.
Si quieres aprender más sobre las técnicas utilizadas en este framework, echa un vistazo al Blog de SourceZero y a la herramienta original.
Freeze.rs es una herramienta de creación de payloads utilizada para evadir los controles de seguridad de EDR y ejecutar shellcode de manera sigilosa. Freeze.rs utiliza múltiples técnicas no solo para eliminar los hooks de EDR en el espacio de usuario, sino también para ejecutar shellcode de manera que evite otros controles de monitoreo de endpoints.
Cuando se crea un proceso, Ntdll.dll es la primera DLL que se carga; esto sucede antes de que se carguen las DLL del EDR. Esto significa que hay un pequeño retraso antes de que un EDR pueda cargarse y comenzar a hookear y modificar el ensamblado de las DLL del sistema. Al observar las syscalls de Windows en Ntdll.dll, podemos ver que todavía no se ha hookeado nada. Si creamos un proceso en estado suspendido (uno que está congelado en el tiempo), podemos ver que no se cargan otras DLL, excepto Ntdll.dll. También se puede ver que no se cargan DLL del EDR, lo que significa que las syscalls ubicadas en Ntdll.dll no están modificadas.
Para usar este proceso suspendido limpio para eliminar los hooks del cargador de Freeze.rs, necesitamos una forma de encontrar y leer programáticamente la memoria del proceso suspendido limpio. Aquí es donde entra en juego la aleatorización del diseño del espacio de direcciones (ASLR). ASLR es un mecanismo de seguridad para prevenir vulnerabilidades basadas en corrupción de la memoria de pila. ASLR aleatoriza el espacio de direcciones dentro de un proceso, para asegurar que todos los objetos mapeados en memoria, la pila, el heap y el programa ejecutable en sí, sean únicos. Ahora, aquí es donde se pone interesante porque mientras ASLR funciona, no funciona para código independiente de la posición, como las DLL. Lo que sucede con las DLL (específicamente las DLL del sistema conocidas) es que el espacio de direcciones se aleatoriza una vez al arrancar. Esto significa que no necesitamos enumerar la información de un proceso remoto para encontrar la dirección base de su ntdll.dll porque es la misma en todos los procesos, incluido el que controlamos. Dado que la dirección de cada DLL es el mismo lugar por arranque, podemos obtener esta información de nuestro propio proceso y nunca tener que enumerar el proceso suspendido para encontrar la dirección.
Con esta información, podemos usar la API ReadProcessMemory para leer la memoria de un proceso. Esta llamada API comúnmente se asocia con la lectura de LSASS como parte de cualquier ataque basado en credenciales; sin embargo, por sí sola no es inherentemente maliciosa, especialmente si solo estamos leyendo una sección arbitraria de memoria. La única vez que ReadProcessMemory será marcada como parte de algo sospechoso es si estás leyendo algo que no deberías (como el contenido de LSASS). Los productos EDR nunca deberían marcar el hecho de que se llamó a ReadProcessMemory, ya que hay usos operativos legítimos para esta función y resultaría en muchos falsos positivos.
Podemos ir un paso más allá leyendo solo una sección de Ntdll.dll donde se almacenan todas las syscalls: su sección .text, en lugar de leer toda la DLL.
Combinando estos elementos, podemos obtener programáticamente una copia de la sección .text de Ntdll.dll para sobrescribir nuestra sección .text hookeada existente antes de ejecutar el shellcode.
ETW utiliza syscalls integradas para generar esta telemetría. Dado que ETW también es una característica nativa integrada en Windows, los productos de seguridad no necesitan "hookear" las syscalls de ETW para acceder a la información. Como resultado, para prevenir ETW, Freeze.rs parchea numerosas syscalls de ETW, vaciando los registros y devolviendo el flujo de ejecución a la siguiente instrucción. El parcheo de ETW ahora está activado por defecto en todos los cargadores.
Dado que solo se restaura Ntdll.dll, todas las llamadas posteriores para ejecutar shellcode deben residir en Ntdll.dll. Usando la crate NTAPI de Rust (nota: puedes hacer esto en otros lenguajes, pero en Rust es bastante fácil de implementar) podemos definir y llamar a las syscalls NT necesarias para asignar, escribir y proteger el shellcode, saltándonos efectivamente las llamadas estándar que se encuentran en Kernel32.dll y Kernelbase.dll, ya que estas pueden seguir estando hookeadas.
Con la crate NTAPI de Rust, puedes ver que todas estas llamadas no aparecen bajo ntdll.dll, sin embargo todavía existen dentro del proceso.
Como resultado:
Esto comenzó como un proyecto divertido para aprender Rust y se ha convertido en su propio framework.
Freeze.rs fue desarrollado en Rust.
Si Rust y Rustup no están instalados, por favor instálalos. Si lo compilas desde OSX o Linux, asegúrate de tener el target "x86_64-pc-windows-gnu" añadido. Para ello, ejecuta el siguiente comando:
rustup target add x86_64-pc-windows-gnu
Una vez hecho esto, puedes compilar Freeze.rs, ejecutar los siguientes comandos o usar el binario compilado:
cargo build --release
A partir de ahí, la versión compilada se encontrará en target/release (nota: si no pones --release, el archivo estará en target/debug/ )
___________
\_ _____/______ ____ ____ ________ ____ _______ ______
| __) \_ __ \_/ __ \_/ __ \\___ // __ \ \_ __ \/ ___/
| \ | | \/\ ___/\ ___/ / /\ ___/ | | \/\___ \
\___ / |__| \___ >\___ >_____ \\___ > /\ |__| /____ >
\/ \/ \/ \/ \/ \/ \/
(@Tyl0us)
Soon they will learn that revenge is a dish... best served COLD & Rusty...
USAGE:
Freeze-rs [FLAGS] [OPTIONS]
FLAGS:
-c, --console Solo para payloads binarios - Genera información detallada en consola cuando se ejecuta el payload.
Esto desactivará la función de ventana oculta
-h, --help Muestra información de ayuda
-n, --noetw Desactiva el parcheo de ETW que evita que se generen eventos de ETW.
-s, --sandbox Habilita la evasión de sandbox verificando:
¿El endpoint está unido a un dominio?
¿El endpoint tiene más de 2 CPUs?
¿El endpoint tiene más de 4 GB de RAM?
-V, --version Muestra información de la versión
OPTIONS:
-E, --Encrypt <ENCRYPT> Cifra el shellcode usando cifrado AES 256, ELZMA o RC4
-I, --Input <INPUT> Ruta al shellcode sin procesar de 64 bits.
-O, --Output <OUTPUT> Nombre del archivo de salida (ej. loader.exe o loader.dll). Dependiendo de la extensión de
archivo definida, se determinará si Freeze genera un dll o exe.
-p, --process <PROCESS> El nombre del proceso a lanzar. Este proceso debe existir en C:\Windows\System32\. Ejemplo
'notepad.exe'
-e, --export <export> Define un nombre de función de exportación personalizado para cualquier DLL.
Freeze.rs puede generar un archivo .exe o .dll. Para especificarlo, asegúrate de que la opción de línea de comandos -O termine con .exe para binarios o .dll para dlls. No se admiten otros tipos de archivos actualmente. En el caso de archivos DLL, Freeze.rs también puede agregar funcionalidad de exportación adicional. Para ello, usa -export con el nombre de la función de exportación específica.
Cifrar el shellcode es una técnica importante utilizada para protegerlo de ser detectado y analizado por EDRs y otros productos de seguridad. Freeze.rs incluye múltiples métodos para cifrar shellcode, estos incluyen AES, ELZMA y RC4.
AES (Advanced Encryption Standard) es un algoritmo de cifrado simétrico que se utiliza ampliamente para cifrar datos. Freeze.rs utiliza un tamaño de bit AES-256 para cifrar el shellcode. La ventaja de usar AES para cifrar shellcode es que proporciona un cifrado fuerte y es ampliamente soportado por las bibliotecas criptográficas. Sin embargo, el uso de un tamaño de bloque fijo puede hacerlo vulnerable a ciertos ataques, como el ataque de relleno por oráculo.
ELZMA es un algoritmo de compresión y cifrado que se utiliza a menudo en malware para ofuscar el código. Para cifrar shellcode usando ELZMA, el shellcode primero se comprime usando el algoritmo ELZMA. Luego, los datos comprimidos se cifran usando una clave aleatoria. Los datos cifrados y la clave se incrustan en el código de exploit. La ventaja de usar ELZMA para cifrar shellcode es que proporciona tanto compresión como cifrado en un solo algoritmo. Esto puede ayudar a reducir el tamaño del código de exploit y hacerlo más difícil de detectar.
RC4 es un algoritmo de cifrado simétrico que se utiliza a menudo en malware para cifrar shellcode. Es un cifrado de flujo que puede usar claves de longitud variable y es conocido por su simplicidad y velocidad.
Freeze.rs utiliza una técnica para primero crear el proceso y luego moverlo a segundo plano. Esto hace dos cosas: primero ayuda a mantener el proceso oculto, y segundo, evita ser detectado por cualquier producto EDR. Lanzar un proceso de inmediato en segundo plano puede ser muy sospechoso y un indicador de maliciosidad. Freeze.rs hace esto llamando a las funciones de Windows 'GetConsoleWindow' y 'ShowWindow' después de que se crea el proceso y se cargan los hooks del EDR, y luego cambia los atributos de la ventana a oculta.
Si se selecciona la opción de línea de comandos -console, Freeze.rs no ocultará el proceso en segundo plano. En su lugar, Freeze.rs agregará varios mensajes de depuración que muestran lo que está haciendo el cargador.