Técnicas de Unhooking y Refresco de ntdll en Procesos Suspendidos
El enfoque central de nuestra técnica reside en manipular el espacio de memoria de procesos suspendidos para modificar o “unhook” las APIs de ntdll que han sido interceptadas por Sophos EDR. Este proceso de unhooking es crucial para evadir la detección, ya que permite que el código malicioso ejecute operaciones sensibles sin ser monitoreado por el sistema de protección.
Para llevar a cabo esta tarea, utilizamos herramientas y librerías del ecosistema de Rust, aprovechando su rendimiento y seguridad de memoria. Iniciamos el proceso creando un programa que suspende un proceso objetivo, como notepad.exe, un vehículo inocuo y comúnmente presente en sistemas Windows. Una vez suspendido el proceso, nuestra técnica procede a realizar operaciones críticas de memoria.
Cabe mencionar que la divulgación y discusión de técnicas de evasión tienen el propósito educativo de fomentar el desarrollo de medidas de protección más eficaces. La ética profesional y la responsabilidad legal deben guiar siempre la aplicación de conocimientos en seguridad informática.
En el transcurso de nuestras investigaciones sobre evasión de sistemas de detección y respuesta ante incidentes (EDR), llevamos a cabo una verificación en nuestra máquina de pruebas que arrojó resultados reveladores. Utilizamos una herramienta especializada disponible en https://github.com/Mr-Un1k0d3r/EDRs, diseñada específicamente para identificar qué APIs están siendo monitoreadas por soluciones EDR. Este análisis nos permitió obtener una visión clara de las técnicas de monitorización implementadas por estos sistemas de seguridad, proporcionándonos una base sólida para desarrollar estrategias de evasión más efectivas.
La herramienta, desarrollada por el reconocido investigador Mr-Un1k0d3r, se ha convertido en un recurso invaluable para la comunidad de seguridad informática. Al aplicarla en nuestro entorno de pruebas, pudimos identificar con precisión las APIs que estaban bajo vigilancia del EDR. Este descubrimiento es crucial, ya que las APIs monitoreadas representan los puntos de control a través de los cuales el EDR intenta detectar y mitigar actividades sospechosas.
Creacion de procesos
Al examinar el comportamiento de los procesos en sistemas con soluciones de Detección y Respuesta a Incidentes (EDR) instaladas, se descubre un patrón notable durante el proceso de inicio. Inicialmente, las DLL del sistema, incluida Ntdll.dll, se cargan en el proceso sin modificaciones, lo que indica que las llamadas al sistema aún no han sido interceptadas por el EDR. Este estado inalterado se mantiene hasta que el proceso se reanuda, momento en el cual el EDR se activa y empieza a enganchar llamadas al sistema, redirigiendo el flujo de ejecución hacia sus propias DLLs para el monitoreo.
Este fenómeno revela un breve intervalo entre la creación del proceso y la intervención del EDR, durante el cual las llamadas al sistema en Ntdll.dll permanecen originales y sin enganchar. Aunque este lapso es muy corto y difícil de observar sin el uso de un depurador para inspeccionar paso a paso, ilustra un momento crítico antes de que el EDR ejerza control sobre el proceso. La creación de un proceso en estado suspendido muestra claramente este fenómeno, ya que en esta etapa inicial, solo se carga Ntdll.dll y ninguna DLL asociada al EDR está presente, dejando las llamadas al sistema sin modificaciones.
Hooking
es una técnica utilizada en la programación y la seguridad informática, que permite interceptar llamadas a funciones o mensajes entre componentes de software. Cuando un EDR (Endpoint Detection and Response) intercepta una API (Interfaz de Programación de Aplicaciones), está implementando un tipo de hooking conocido como “hooking de API”.
En este contexto, el hooking permite al EDR monitorear y analizar las llamadas a funciones críticas del sistema operativo realizadas por las aplicaciones. Al interceptar estas llamadas, el EDR puede examinarlas para detectar comportamientos sospechosos o maliciosos, como malware o ataques cibernéticos, antes de que la llamada se ejecute efectivamente.
Por ejemplo, si un software malicioso intenta realizar una llamada a una función del sistema para modificar archivos críticos, el EDR, mediante hooking, puede interceptar esta llamada. Esto le permite al EDR analizar la solicitud, y si se considera maliciosa, bloquearla o tomar otras medidas de mitigación, como alertar a los administradores de seguridad o recolectar más información para una investigación.
Unhooking
es el proceso de revertir el hooking, es decir, deshacer la interceptación de llamadas a funciones o mensajes entre componentes de software. En el contexto de la seguridad informática y los sistemas de detección y respuesta a incidentes (EDR), el unhooking se refiere específicamente a la acción de eliminar los hooks establecidos por malware o por el propio EDR en las APIs del sistema operativo o en otras funciones críticas.
Cuando un EDR o una herramienta de seguridad implementa un hooking para monitorear llamadas a funciones del sistema, modifica el flujo normal de ejecución para dirigir esas llamadas hacia sus propios controladores, permitiéndole inspeccionar, registrar o bloquear actividades potencialmente maliciosas. Sin embargo, en algunos casos, puede ser necesario revertir estos cambios, por ejemplo:
- Restauración de la funcionalidad original: Si un EDR o una herramienta de seguridad se desinstala o necesita actualizar sus métodos de hooking, puede ser necesario eliminar los hooks previamente establecidos para restaurar el flujo normal de ejecución de las APIs interceptadas.
- Contramedidas de malware: El malware avanzado, en un intento de evadir la detección, puede emplear técnicas de unhooking para remover los hooks establecidos por soluciones de seguridad, con el objetivo de ocultar su actividad maliciosa y operar sin ser detectado.
- Análisis forense y de seguridad: Los investigadores de seguridad pueden utilizar técnicas de unhooking para analizar el comportamiento del malware en un entorno controlado, removiendo los hooks establecidos por el malware para entender mejor sus mecanismos de evasión y operación.
El unhooking, por lo tanto, puede ser utilizado tanto por atacantes como por defensores en el contexto de la ciberseguridad. Para los defensores, es crucial entender cómo el malware emplea el unhooking como parte de sus técnicas de evasión, y desarrollar estrategias para detectar y contrarrestar estos intentos de evadir las soluciones de seguridad implementadas.
cuando se inicia el proceso suspendido de notepad se carga la lib ntdll como se logra ver en la imagen anterior.
//exploit666
//simple poc process suspended in rust
extern crate winapi;
use std::io;
use winapi::um::processthreadsapi::{CreateProcessA, PROCESS_INFORMATION, STARTUPINFOA};
use winapi::um::winbase::CREATE_SUSPENDED;
use std::ptr::null_mut;
use std::mem::zeroed;
use winapi::um::libloaderapi::GetModuleHandleA;
fn main() {
unsafe {
let mut si: STARTUPINFOA = zeroed();
let mut pi: PROCESS_INFORMATION = zeroed();
let app_name = "C:\\Windows\\System32\\notepad.exe\0";
let mut app_name_cstr = app_name.as_bytes().as_ptr() as *mut i8;
if CreateProcessA(
null_mut(),
app_name_cstr,
null_mut(),
null_mut(),
0,
CREATE_SUSPENDED,
null_mut(),
null_mut(),
&mut si,
&mut pi,
) != 0
{
println!("Process created in suspended state.");
println!("Process ID: {}", pi.dwProcessId);
println!("Thread ID: {}", pi.dwThreadId);
} else {
println!("Failed to create process.");
}
println!("Press Enter to exit...");
let mut dummy = String::new();
io::stdin().read_line(&mut dummy).unwrap();
}
}el codigo anterior es una base simple para generar un proceso suspendido en rust.
Antisandbox
Los “anti-sandbox” son técnicas utilizadas por el malware para detectar y evadir la ejecución en entornos de análisis automatizado, conocidos como “sandboxes” o cajas de arena. Estos entornos son herramientas esenciales en la seguridad informática, diseñadas para ejecutar y analizar software sospechoso en un entorno controlado y aislado, permitiendo a los investigadores observar el comportamiento del malware sin riesgo para los sistemas reales.
El objetivo principal detrás de las técnicas anti-sandbox es evitar la detección y el análisis por parte de investigadores y soluciones de seguridad, prolongando así la vida útil del malware y su capacidad para infectar sistemas sin ser detectado. Algunas de las técnicas anti-sandbox más comunes incluyen:
Verificación del Entorno: El malware puede buscar señales que indiquen que está siendo ejecutado en un sandbox, como la presencia de ciertos procesos, servicios, dispositivos virtuales o la falta de interacción del usuario. Si detecta señales de un entorno de análisis, puede detener su ejecución o alterar su comportamiento.
Retraso en la Ejecución: Algunas variantes de malware implementan retrasos en su ejecución o requieren ciertas condiciones antes de activar su carga útil. Dado que muchas sandboxes solo observan el comportamiento del malware durante un tiempo limitado, estas técnicas buscan evitar el análisis completo.
Búsqueda de Interacción del Usuario: El malware puede requerir interacción del usuario (como clics del mouse o teclado) antes de ejecutar su carga útil, aprovechando que los entornos sandbox suelen carecer de este tipo de interacciones.
Análisis de la Configuración del Sistema: El malware puede verificar características del sistema como la cantidad de CPU, memoria, o incluso archivos y programas específicos, buscando indicadores de un entorno real frente a uno virtualizado.
Estas técnicas representan un desafío constante para la comunidad de seguridad informática, obligando a los investigadores y desarrolladores de herramientas de seguridad a innovar continuamente en sus métodos de detección y análisis para mantenerse un paso adelante de los atacantes. La carrera armamentista entre las técnicas de evasión del malware y las contramedidas de seguridad es un aspecto central en la lucha contra el software malicioso.
pub fn check_mouse_click(min_clicks: u32) {
let mut count: u32 = 0;
println!("Esperando {} clics del mouse...", min_clicks);
while count < min_clicks {
unsafe {
let key_state = GetAsyncKeyState(VK_LBUTTON);
if key_state & (1 << 15) != 0 {
count += 1;
("Clic detectado: {}", count);
while GetAsyncKeyState(VK_LBUTTON) & (1 << 15) != 0 {
sleep_millis(10);
}
}
}
sleep_millis(100);
}
}Adicionalmente agregamos una validacion simple de iteraccion al codigo, para evaluar un ambiente sandbox y poder determinar si se ejecuta.
durante unos laboratorios se evidencia que fue posible realizar el bypass del sandbox evitando que emule la ejecucion del shellcode. con una simple validacion de clicks (iteraccion de usuario)
