Estoy emocionado de presentarles Pescan.io.
Encontrarás Promo Codes en las notificaciones de 4n4lDetector. 😈

Descúbrelo ahora

sábado, 28 de noviembre de 2015

Antivirus K.O. Ordinal Numbers vs API Names

Como mola poner un título en inglés, y luego redactar el artículo en español. Sobre todo en estos tiempos en los que se puso tanto de moda el vender humo, ya hasta el que usa la palabra “postureo”, me incita a pensar que se junta con gente muy cool… ¡No lo soporto! ¡Dudo hasta de entrecomillar esas mierdas! ¡Puta invasión Hipster!

Hoy quería hablaros sobre un sapo que me he comprado, bueno, ya me pongo serio.

Existen varios métodos para evitar el tener que declarar un API en la Import Table de un binario, y sin embargo llegar a utilizarla. Métodos como Call API By Name, Call API By Hash, embeber una Shellcode suelen ser los más habituales. En el caso que expongo, el API se encuentra declarada, pero no con el nombre de la misma.

La idea que se me había ocurrido, trata de probar a llamar a las funciones que exportan las librerías, utilizando los números ordinales que las referencian, en lugar de a sus nombres. Este método por cuestiones de compatibilidad suele ser desaconsejado, ya que es posible que dependiendo del sistema operativo donde el binario se ejecute, pueda llegar a no funcionar. Esto existe sencillamente porque se encuentran multitud de funciones sin nombre, y esta sería la única forma de poder llamarlas. No obstante, podemos utilizar mi anterior método DAF para embeber las librerías que necesitemos en el sistema a modo Dropper, antes de ejecutar el malware en cuestión.

Para la prueba de concepto quería empezar con algo sencillo, aunque posiblemente muy detectado. Con lo que se me ocurrió generar el “stage 1”, la primera etapa de conexión del payload de Metasploit “reverse_tcp”.

Para la ejecución de la ShellCode, he compilado un binario desarrollado… ¿cómo no? en Visual Basic 6, para no perder la costumbre, mediante el uso de CallWindowProcA.

La herramienta Pestudio, abrirá el camino para identificar de forma rápida el número ordinal que utiliza en mi sistema la función CallWindowProcA de la librería user32.dll. La siguiente imagen muestra las APIs que esta librería exporta.

El número ordinal 1531 nos dará acceso a invocarla, con lo que realizaré los cambios en el código anteriormente utilizado para llamarla.

Tras comprobar ambos binarios, se muestra como se realiza la llamada en este caso. Algo físicamente más complejo de detectar que mi anterior publicación del Método Mmove, en el que se migraban los nombres de las funciones, a otros huecos.
Sencillamente declaramos la función con el número ordinal que hace referencia a la API en decimal.

Comprobando con Metasploit, si este último binario realmente funciona.

Ahora solo queda enviar las muestras a un Scanner Online.

¡Esto funciona muñeca! Como es lógico, algún antivirus debía de detectar la muestra, más que nada porque se encuentra la ristra de opcodes que forman el payload embebido sin ningún tipo de codificación o cifrado. Para evitar estas detecciones, lo más seguro es que bastase con darle uso a una herramienta como Abronsius Code Ofuscator, que utilicé anteriormente en la creación de 4n4lCrypter.

No podía dejar escapar esta oportunidad, para añadir una detección que saldrá en la próxima versión de 4n4lDetector, sobre este tipo de binarios compilados en Visual Basic x, que utilicen la invocación de las APIs mediante sus números ordinales.

¡Hasta aquí todo chahi piruleta! Pero realmente lo divertido, sería modificar un binario ya detectado del cual no tenemos acceso a sus fuentes, para llevar a cabo un limpiado de detecciones como venía haciendo tiempo atrás.

Así que como Visual Basic 6, internamente es un poco tedioso a la hora de hacer las llamadas a las APIs, ya que las carga de forma dinámica a través de otra función llamada DllFunctionCall. Me he pasado “temporalmente” a un lenguaje, el cual deja de lado las marranadas en su Import Table, Assembler.

Algo muy sencillo, un Downloader que utilizará tres APIs. La muy quemada URLDownloadToFile, ShellExecute y ExitProcess. ¡El trío de las blacklist!
Para el POC, he subido una calculadora de Windows a Google Drive.

Es salir de Visual Basic, y asombra lo maravilloso que es compilar binarios de 2KB… jajajaa

He vuelto a utilizar Pestudio para leer los ordinales de estas nuevas funciones, las cuales proceden de librerías diferentes.


La primera prueba la haré con URLDownloadToFile, así que vuelta a un editor PE. Ya saben que yo soy de utilizar LordPE, así que abriremos el binario con este, nos dirigiremos a su tabla de importaciones y le daremos a editar.


Eliminaremos los bytes del Hint y el nombre de la API, y agregaremos en ThunkValue el ordinal en hexadecimal, sumado a (0x80000000), con el cual se representa este tipo de dato.


Tras comprobar que este nuevo ejecutable funciona sin problemas, se realiza el envío de ambas muestras.

Jajajaa… a mí personalmente me hace gracia. No pude evitar ponerme algo de música, unas 10 horas de Vaina Loca, una hora por antivirus saltado con tal de evadirme.

Ya que estaba con el ritmo en las venas, decidí quitarme de encima también las declaraciones de ShellExecute y ExitProcess. Así que hice lo propio con LordPE. Una nota importante, tras revisar el binario modificado con este software, me di cuenta de que no realizaba el borrado completo del nombre de la función, sino que tan solo ponía a byte nulo el primero del nombre, evitando su lectura. No obstante, es sencillo terminar de dejarlo limpio con un editor hexadecimal.

Tras comprobar que el binario sigue cumpliendo con su función. Lo envío de vuelta al Scanner Online.


Dr. Web se baja del carro. Realmente los dos que quedan, es posible que utilicen alguna rutina de detección basada en la URL, con lo que seguro es bastante sencillo evitarles ofuscando la cadena.

Saludos 4n4les! ;)

domingo, 14 de junio de 2015

4n4lDetector v1.1

¡Joder qué tiempo de mierda hace ahí afuera! Ha llegado ese momento incómodo en el que todo el mundo, se vuelve en tu contra. Si te metes en la cama y te arropas, pasas calor. Si asomas un pie por el extremo de la sábana, corres el riesgo de perder el meñique por congelación. Si se te ocurre salir en pantalón largo, hasta los gayumbos se fusionan con los cachetes de tu pompis, y esto junto a la transpiración de tus pelotas se convierten en enemigo público número uno. ¡Porqué te la empieza a sudar todo! Y si por el contrario decides pasarte a los pantalones cortos... date por jodido porque algo malo tiene que pasarte, tú hazme caso…  ¡Qué esto es un sin vivir!

La verdad es que no me apetece escribir el post pffffffff jajajaa… preferiría estar tirado al solecito en mi terraza chupando del polo flash, pero como alternativas después de un fin de semana tan movidito solo me quedaba publicar algo o entrar en putalocura, y no sé qué estará ocurriendo, pero últimamente no la actualizan con buen contenido, pues eso… que estoy perdiendo el interés.

Así que me he dicho… voy a regalarles a los chavales y especialmente a las chavalas, la nueva versión de mi software 4n4lDetector. Bromas a un lado, le he dedicado bastantes horas para que sea aún más potente que la anterior versión, y si os digo que estoy muy contento con los resultados que esta herramienta me está dando, no os engaño. Además no tengo que venderos nada, porque todo conmigo siempre es gratis.

¿Qué cosas nuevas trae esta versión de 4n4lDetector?

Si recuerdan mi anterior entrada en la que desarrollé un Crypter para hacer malware indetectable. Este utilizaba un stub llamado enelpc.exe, que tras utilizarlo con 4n4lCrypter, el archivo resultante Crypt.exe transportaría finalmente el malware cifrado. Este sería el resultado al arrastrar ambos ejecutables a la herramienta.

He incluido como ven una rutina de detección de Droppers, que funcionará sobre aplicaciones de tipo Binder, Joiner y Crypters que se basan en stubs.

Siguiendo con los Crypters, una de las publicaciones de indetectables.net realizada por el usuario MaggicianCOr, se trataba de otro modificado por él mismo. Decidí descárgalo y usarlo para echarle un vistazo al binario cifrado, sirviendo de buen ejemplo para mostrar el resto de información que nos brinda 4n4lDetector.

Esta nueva versión estudia la posible abundancia de caracteres extraños, normalmente generados de forma aleatoria por el malware, para incluir un añadido de polimorfismo a las descripciones de los binarios generados. La siguiente imagen muestra una detección de polimorfismo, seguida de la cantidad de código Dropper, y la anomalía tras el Entry Point de encontrar un salto condicional JPO, el cual delata la modificación del ejecutable compilado en Visual Basic 6.

Si recuerdan la entrada en la que cifrábamos un malware a mano, se incluyeron unos algoritmos de rotación, sumas, restas e instrucciones XOR tras el Entry Point del troyano Poison Ivy. Algo que también llamará la atención de 4n4lDetector ya que estudia los primeros 25 Bytes del punto de partida de todas las aplicaciones.

Algo que no podía faltar en el módulo de ejecución, sería la posibilidad de cargar librerías. Con lo que esta nueva versión cuenta con un nuevo ejecutable añadido de apenas 2,7 KB, para poder estudiar sus Memory Dumps.

Los algoritmos encargados de la búsqueda de nombres ejecutables también han sido mejorados, con lo que ahora tendremos en este apartado una información más amplia y mejor obtenida.

Algún usuario me pidió que se guardasen en un LOG las extracciones, así que preparé una función por consola para la herramienta, en la que si se le pasa como parámetro sin comillas de ningún tipo, el nombre del ejecutable a analizar, esta genera un TXT en la raíz de 4n4lDetector con el nombre de la aplicación analizada.

Algo que creo recordar nunca había nombrado en el blog, son los métodos Call API By Name o Call API By Hash. Estos métodos son utilizados para invocar a las API sin declararlas como tal. Mediante algoritmos se calcula el hash como nombre con el que hacer referencia a un API o se suelen llamar a las funciones cargando directamente las librerías con LoadLibrary y copiando de su memoria las instrucciones. El malware puede utilizar estas técnicas para esconder del análisis estático, cuales son las funciones que realmente utilizará, con lo que me pareció una buena idea incorporar la detección de estos métodos. La siguiente imagen muestra un simple Downloader, camuflando el API UrlDownloadToFile.

Qué raro se me hace desarrollar métodos de evasión antivirus y malware como hobby y a su vez combatirlos también como hobby jajaja


Saludos 4n4les! ;)