optiv/freezeFreeze es un kit de herramientas de payloads para evadir EDRs mediante procesos suspendidos, syscalls directas y métodos de ejecución alternativos.
Para ver la última versión de Freeze o enviar un problema, consulte https://github.com/Tylous/Freeze.
Si desea obtener más información sobre las técnicas utilizadas en este marco, eche un vistazo a SourceZero Blog
Freeze es una herramienta de creación de payloads utilizada para eludir los controles de seguridad EDR y ejecutar shellcode de manera sigilosa. Freeze 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 forma que evite otros controles de monitoreo de endpoints.
Cuando se crea un proceso, Ntdll.dll es la primera DLL que se carga. Esto ocurre antes de que se cargue cualquier DLL de 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 aún no hay nada hookeado. 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 puede ver que no se cargan DLL de 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, 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 garantizar que todos los objetos mapeados en memoria, la pila, el montón y el propio programa ejecutable 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 la misma por cada 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 se asocia comúnmente 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 existen usos operativos legítimos para esta función y resultaría en muchos falsos positivos.
Podemos llevar esto 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 incorporada 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 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 es predeterminado en todos los cargadores.
Dado que solo se restaura Ntdll.dll, todas las llamadas posteriores para ejecutar shellcode deben residir en Ntdll.dll. Usando Go (nota: puedes hacer esto en otros lenguajes, pero en Go es bastante fácil de implementar) podemos definir y llamar a las syscalls NT necesarias para asignar, escribir y proteger el shellcode, omitiendo efectivamente las llamadas estándar ubicadas en kernel32d.dll y Kernelbase.dll, ya que estas pueden aún estar hookeadas.
Freeze fue desarrollado en Golang.
Para instalar Freeze, ejecute los siguientes comandos, o use el binario compilado:
go build Freeze.go
___________
\_ _____/______ ____ ____ ________ ____
| __) \_ __ \_/ __ \_/ __ \\___ // __ \
| \ | | \/\ ___/\ ___/ / /\ ___/
\___ / |__| \___ >\___ >_____ \\___ >
\/ \/ \/ \/ \/
(@Tyl0us)
Pronto aprenderán que la venganza es un plato... mejor servido FRÍO...
Uso de ./Freeze:
-I string
Ruta al shellcode raw de 64 bits.
-O string
Nombre del archivo de salida (ej. loader.exe o loader.dll). Dependiendo de la extensión de archivo definida, se determinará si Freeze crea un dll o un exe.
-console
Solo para payloads binarios: genera información detallada de la consola cuando se ejecuta el payload. Esto desactivará la función de ventana oculta.
-encrypt
Encripta el shellcode usando cifrado AES 256
-export string
Solo para cargadores DLL: especifique una función Export específica para que tenga el cargador.
-process string
El nombre del proceso a crear. Este proceso debe existir en C:\Windows\System32\. Ejemplo 'notepad.exe' (por defecto "notepad.exe")
-sandbox
Habilita la evasión de sandbox verificando:
¿El endpoint está unido a un dominio?
¿Tiene el endpoint más de 2 CPUs?
¿Tiene el endpoint más de 4 GB de RAM?
-sha256
Proporciona el valor SHA256 de los cargadores (Esto es útil para el seguimiento)
Freeze puede generar un archivo .exe o .dll. Para especificar esto, asegúrese de que la opción de línea de comandos -O termine con .exe para binarios o .dll para dlls. Actualmente no se admiten otros tipos de archivos. En el caso de archivos DLL, Freeze también puede agregar funcionalidad de exportación adicional. Para ello, use el -export con el nombre de la función de exportación específica.
Freeze utiliza una técnica para primero crear el proceso y luego moverlo al fondo. Esto hace dos cosas: primero, ayuda a mantener el proceso oculto, y segundo, evita ser detectado por cualquier producto EDR. Crear un proceso directamente en segundo plano puede ser muy sospechoso y un indicador de maliciosidad. Freeze 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. Freeze utiliza estas API en lugar de usar el tradicional -ldflags -H=windowsgui, ya que esto está altamente firmado y clasificado en la mayoría de los productos de seguridad como un Indicador de Compromiso.
Si se selecciona la opción de línea de comandos -console, Freeze no ocultará el proceso en segundo plano. En su lugar, Freeze agregará varios mensajes de depuración que muestran lo que está haciendo el cargador.
Agradecimiento especial a aahmad097 por desarrollar AlternativeShellcodeExec
Agradecimiento especial a mvdan por desarrollar Garble