Troyano minador

#92 Bitwarden + Authy. Todo el mundo piensa que con un par de claves va bien hasta que le pasan estas cosas.

Yo uso KeePass, es un gestor de contraseñas. Así puedes usar diferentes passwords para cada cosa y no perderlos.

Pregunta random así de gratis:

Es posible que teniendo ese script funcionando en un PC haya dejado pasar un cryptolocker sin que un "supuesto anitivirus de confianza" lo detecte?

#98 Entonces fue casualidad. Tuve un problemilla con un Cryptolocker hace unos meses y sólo tengo sospechas de 1 PC de la red por donde podía haber entrado. Recuerdo ver ese archivo .vbe en un zip en dicho PC, aunque el cryptolocker sólo atacó en el servidor, a saber por dónde entró...

El código vba no está "encriptado" sino ofuscado, ese tipo de ofuscación con base64 es muy común en scripts de servidores dedicados y páginas webs. Dicho esto, es un buen curro teniendo en cuenta que lo haces por amor al arte.

#101 gracias! El código inicial del vbe está encriptado, no es base64, te dejo una foto y verás que por los carácteres usados jamás podría tratarse d eun base64

Hay que deshacer la encriptación del vbe usando la documentación que puse, por suerte es algo conocido y no cuesta absolutamente nada hacerlo, siempre y cuando sepas identificar lo que tienes. Luego sí que encuentras 3 ficheros codificados en base64, y eso por suerte es muchísimo más fácil dejarlo en texto normal.

Finalmente están los ficheros shell.txt y pe.bin, que no logro desencriptar. Pondría la mano en el fuego que están en RC4, yo con esos algoritmos me bajo del tren ya que sin la clave solo te queda fuerza bruta y paso. xd

#102 Debería ser esto, no?

No controlo mucho sobre el minado de criptomonedas, pero eso de stratum que comentas aparece ahí. Ya me dices.

Joder que a gustito leyendo este thread con el desayuno.
Las 2 preguntas que tenia en mente, ya las han hecho.

Pero se me ocurren un par mas:

1) ¿Como coño inyecta en systeminfo.exe algo? ¿Como inyectas sin problemas a un legacy?

2) Al tratar con rand-paths, en algun lado debe dejar constancia de la carpeta que ha creado para poder trabajar con ellos en los startups, no? O la parte rand es simplemente para el deploying y ya posteriormente tira de path construible (nombrePC + whatever)? Lo digo porque quizás seria interesante buscar en el registro, la entrada con el nombre de la carpeta. Para acabar de hacer limpio del todo.

#103 Y luego pensaba, en todos los casos, para poder ejecutarse todo, debe ser capaz de poder desencriptarse por si solo. Luego las claves deben estar contenidas en el propio script como tal.
Para la desofuscación del vbs, lo dicho. Pero el contenido interno, las claves deben estar contenidas en algún sitio. Para los hard-codedm un decode de base64 y obtienes texto. Pero para los shell.txt y el pe.bin, o se ejecutan en un remote-service en algun servidor, en el que para algún tipo de payload mandado es capaz de recuperar la clave y entonces desencripta, o de nuevo nos encontramos con encriptación propietaria y no RC4.

edit: viendo el tema, juraría que la clave está precisamente en el test.au3. Le has podido clavar el diente?

#111 El mundo de la inyección de codigo en procesos remotos es una pasada. Se utiliza esta técnica para evadir análisis, detección de antivirus, firewall-bypass, anti-heurística, elevación de privilegios y un montón de cualidades más.

Hay muchísimos métodos de inyección, te dejo un artículo MUY completo aquí: https://www.endgame.com/blog/technical-blog/ten-process-injection-techniques-technical-survey-common-and-trending-process Parece algo complejo pero por desgracia es un método muy común en el mundo del malware y cheats-multiplayer.

El tema del rand es otra técnica más para dificultar la detección y la creación de firmas para hacer una vacuna. Está mal implementado en este bicho, ya que no guarda semilla alguna y eso a la larga es contraproducente cuando el usuario ejecuta varias veces el virus por error. En el momento que has diseccionado el código del malware te evitas tener que hacer búsquedas a lo loco para ver si te has dejado algo, pero nunca está de más hacerlo, claro.

Está claro que todo lo encriptado/ofuscado debe deshacerse en algún punto para ser ejecutado. El vbe se desofusca solito por el runtime de WSH, dentro hay base64 para hacer el deploy del autoit.exe. El enigma empieza justo ahí... el exe del autoit ejecuta un fichero test.au3 que está cifrado de alguna manera, y por algún motivo, el exe es capaz de leer ese fichero, interpretarlo y ejecutar el script.

A partir de ahí, sería el propio script de autoIt quien tiene en su interior la key usada en el RC4 para leer los ficheros shell.txt y pe.bin. La zona roja está entonces en el momento que el autoit.exe abre, interpreta y ejecuta el test.au3

Se me ocurre debugar con IDA el autoit.exe a ver si cazo algo, pero si lo hago sería por los loles, no creo que llegue a sacar nada en claro. Buscando un poco creo que han podido usar esta tool para codificar el test.au3: https://www.pelock.com/products/autoit-obfuscator pero, de nuevo, no estoy seguro.

#113 Mmmm... mas bien viendo que hablan de que el source se encuentra empaquetado entero con el binario, quizas de podria "desempaquetar el exe" del Autoit entero y recuperarlo a pelo? No entiendo como venden la recuperación del source en la propia web de obfuscator y luego hablan de usar IDA para trabajar a nivel "asembler". Tiene que ser mas fácil.
Supongo que, cuando compilas un script, generas un EXE que debe ser en si mismo el reflejo del propio codigo au3 encriptado. Es decir, el EXE, contiene el propio interprete que es a su vez el traductor estricto de la versión encriptada del fichero distribuible, que permite por lo tanto, acceder a pelo a la versión oculta pero entera del codigo y así hacer el contraste y su posterior ejecución. La clave seria arrancarlo del EXE.

si no ha hecho nada todavia xd, le queda decompilar el au3, luego desofuscar el au3, etc xD
aqui te dejo un par de decompiladores
http://files.planet-dl.org/Cw2k/MyAutToExe/index.html
http://domoticx.com/autoit3-decompiler-exe2aut/