Los autores de malware siempre inventan formas ingeniosas de evitar la detección. Para el malware escrito en código administrado, como PowerShell o malware de .NET, los autores lo codifican para dificultar aún más identificar su intención maliciosa.
Pero si llevamos esto un paso más allá, los atacantes a veces “codifican” el malware para un endpoint o usuario en particular. Esto significa que el malware solo puede ejecutarse en el endpoint objetivo, porque está vinculado al nombre del endpoint, la dirección IP o incluso el usuario con sesión iniciada.
Veamos un ejemplo.
En este blog analizamos un comando de PowerShell con un payload codificado según el entorno. En otras palabras, el payload (normalmente) solo se ejecutará en el endpoint particular para el que fue codificado, lo que hace que el análisis automatizado sea mucho más difícil.
El hallazgo
Identificamos un endpoint con múltiples puntos de apoyo maliciosos. Uno de ellos era un comando de PowerShell configurado para ejecutarse como servicio:
El comando usa la variable de entorno COMSPEC, que por defecto apunta a cmd.exe. El comando primero inicia una instancia de cmd.exe, que inicia otro cmd.exe, que finalmente inicia PowerShell.exe ejecutando un comando especificado mediante la opción -C (la versión abreviada de la opción -Command).
El propio comando de PowerShell consiste en una larga cadena hexadecimal concatenada con una llamada a Convert.FromBase64String() y una cadena en base64 como argumento. Al decodificar la cadena en base64 se revela lo que parece ser un decodificador al que la cadena hexadecimal (789cbd588f73…) se le canaliza (pipe):
El mensaje 'Bad key' en la última línea del decodificador llama la atención; parece haber un caso en el que el decodificador puede fallar. Mirando más de cerca, vemos que el COMPUTERNAME, USERNAME, DOMAINNAME y la dirección IP (líneas 11–13) se combinan para crear una clave — $kl— necesaria para decodificar el payload (la cadena hexadecimal del comando):
A los autores de malware y a los atacantes les gusta usar PowerShell porque es omnipresente. Además, la naturaleza del código de PowerShell dificulta identificarlo como malicioso, en especial si el comando está codificado. Para inspeccionarlo, hay que decodificarlo u observarlo mientras se ejecuta. En este caso, el payload estaba codificado para el endpoint, así que no se puede ejecutar en cualquier lugar.
Pudimos codificar la clave manualmente usando los detalles que conocíamos del endpoint (línea 2) e imprimir el payload decodificado (línea 17) en lugar de ejecutarlo:
El payload decodificado es un stager que se usa para descargar y ejecutar Meterpreter directamente desde la memoria.
Curiosamente, el payload incluye varios mensajes de error que no esperarías encontrar en malware. Por ejemplo, “algo está bloqueando el acceso al método 'Connect', probablemente un firewall o software antivirus.” Con el uso de meterpreter y los mensajes de error tan expresivos, al principio pensamos que esto provenía de una prueba de penetración, pero el cliente dijo que no había contratado a ninguna empresa de pen-testing. 🤨
• • •
Esperamos que hayas disfrutado este vistazo a los tipos de tácticas turbias que pasan por los escritorios de nuestros analistas de amenazas. Si de algo sirve, esto muestra hasta dónde llegan los atacantes para maximizar su payload y minimizar sus probabilidades de ser detectados.
¿Quieres profundizar en más análisis de amenazas? Lee algunos de nuestros otros blogs:
