Análisis de malware
Analizando un troyano DDoS
noviembre 17, por SecRata
MD5: 67877403db7f8ce451b72924188443f8
Instalador:
En la función principal del malware, se utilizan dos subrutinas para comprobar si el malware ya está instalado en el sistema o no.
Se verifican las rutas de registro y archivos.
Si observa, verá que el archivo de instalación es syswow64, que está presente en sistemas de 64 bits, por lo que fallará en todos los sistemas operativos de 32 bits.
La verificación del registro nos da una indicación de que este archivo se instalará como un servicio con el nombre de servicio “Servicios Iptablex”.
Si ambas comprobaciones fallan al principio, se procederá a comprobar los argumentos proporcionados al binario.
El binario toma dos argumentos.
1: xxxxCliente
2: del
El argumento “xxxxClient” es necesario cuando el binario está configurado para realizar comunicaciones C2 y se realiza toda la inicialización.
El argumento “del” es necesario cuando se elimina el binario original.
En la primera ejecución, la mayoría de las comprobaciones fallarán. Después de que Binary llegue al siguiente nodo
Antes de llamar a la rutina de instalación, se realiza una llamada a “TerminateProcessWithModules”. Esta subrutina enumerará todos los procesos y sus dll cargados, si se encuentra un módulo con el mismo nombre que el binario, procederá a finalizar el proceso.
Si el ID del proceso principal es el mismo que el del proceso actual, entonces se omite el proceso de terminación. Esto se hace porque la propia instalación principal inicia el proceso como un proceso secundario. Más detalles seguirán.
En realidad, esta subrutina tiene errores. Hay una llamada a la subrutina “ConvertUnicodetoAscii” que toma un argumento de cadena de PROCESSENTRY32.szExeFile, que ya es una cadena ASCII. Debido a lo cual, nunca podrá finalizar una instancia que ya se esté ejecutando del mismo malware.
No solo procederá a crear e iniciar el servicio “Iptablex Service”, sino que también se ejecutará nuevamente con “del” en los parámetros.
El servicio comienza desde la subrutina ServiceProc. Durante la fase de inicialización se crean dos objetos de eventos globales de Windows, es decir, “GlobalhbllxxxxServer” y “GlobalhbllxxxxClient”.
Estos eventos son necesarios para que el proceso hijo sepa si la fase de inicialización ha terminado o no.
Además, procederá a iniciar otra instancia del archivo Exe desde el propio servicio con “xxxClient” como parámetro.
La nueva instancia comienza desde la siguiente subrutina.
La subrutina CheckEvents comprueba si se han configurado eventos globales. Los parámetros c2 (puerto e IP/DOMINIO) se decodifican utilizando el siguiente algoritmo simple
Si en lugar de Ipaddress está presente el dominio, el dominio se verifica usando un marcador de posición en DWORD (EncodedByteStream + 1) como 0xaaaaaaaa.
Si omitimos eso, al verificarlo se revela el dominio utilizado con un número de puerto constante 2345.
Para omitir la rutina de instalación y facilitar el análisis. Se puede utilizar el siguiente programa para mantener activos los eventos antes de comenzar la depuración.
#definir WIN32_LEAN_AND_MEAN
#incluir ventanas.h
firmado int __cdecl startEvent()
{
MANEJAR hObjeto;
MANEJAR hEvento;
hObject = CreateEventA(0, 0, 0, “GlobalhbllxxxxServer”);
si (hObjeto)
{
si (GetLastError()! = 183)
{
hEvent = CreateEventA(0, 0, 1, “GlobalhbllxxxxClient”);
si (hEvento)
devolver 1;
}
CerrarMango(hObjeto);
}
devolver 0;
}
int principal(int argc, char **argv)
{
iniciarEvento();
mientras (1)
{
Dormir(3000);
}
}
Si iniciamos el binario con los argumentos “xxxxClient”, nos saltaremos la fase de instalación y saltaremos directamente a la subrutina de comunicación c2.
Comunicación C2:
Inicialmente, el paquete de inicialización se transmite a c2c y consta de datos de texto sin formato relacionados con el sistema operativo, en su mayoría relacionados con el hardware instalado. Se establece una variable en el paquete si se encuentra un servidor Windows y un procesador AMD. Lo que demuestra que estos delincuentes están interesados en hardware potente. Este valor se establece usando una máscara xor de 4 y 2
Después de enviar un paquete de inicialización, se crea un hilo para recibir comandos del servidor. Un tiempo de espera seleccionado se establece en 30 segundos. Si no se recibe nada en 30 segundos, se envía “xy” al servidor.
Se descarta cualquier solicitud de longitud mayor o igual a 262 bytes.
Los comandos recibidos de c2 se envían al controlador donde se manejan los comandos como TCP_RAW Inundación DDOS, Actualización binaria están presentes.
¡Conviértete en un ingeniero inverso certificado!
Obtenga capacitación práctica en vivo sobre análisis de malware desde cualquier lugar y conviértase en un analista certificado de ingeniería inversa. Comienza a aprender