Hola amigos de Taringa! Decidí hacer un curso practico sobre hacking ético, orientado a la parte de pentesting o test de penetración...
Lo dividiré en varias partes, no se muy bien cuantas serán, así que vamos a empezar.
Parte 1:
Importancia del Fingerprinting
La explotación de alguna vulnerabilidad suele ser el objetivo principal de todo atacante. Poder ejecutar código en el sistema comprometido para llevar a cabo las acciones oportunas determina sin duda alguna el éxito de una intrusión. Casos como los del Hydraq (más conocido como Aurora) donde atacantes utilizando un 0 Day para Internet Explorer tuvieron por objetivo docenas de organizaciones, entre ellas Adobe Systems, Juniper Networks, Yahoo, Google, etc. O casos más recientes como Stuxnet, Duqu o la intrusión en RSA mediante phishing con un fichero .xls malicioso han puesto de moda el concepto Advanced Persistent Threat (A.P.T.). Este término, comúnmente usado para referirse a ciberataques que implican cierto nivel de sofisticación, y cuyo objetivo principal es el espionaje y robo de información, ha empezado a generar cierto temor en prácticamente cualquier organización. Dichos ataques presentan un denominador común: el atacante contiene información más que detallada y precisa de los sistemas objetivo. Para desempeñar una intrusión de tal envergadura el atacante debe dedicar tiempo a investigar sobre las redes, sistemas, correos, empleados, software, etc. utilizando diversas herramientas y técnicas (entre las que se incluye la ingeniería social) para más adelante personificar el ataque.
Exploits / Antivirus
Conocer la versión del sistema operativo y del software instalado es una de las partes cruciales que cubre el fingerprinting. Esto se debe a que, en la mayoría de los ataques, se emplean exploits que necesitan ser ajustados previamente con datos concretos que dependen de la versión exacta del propio software o del sistema operativo. Ejemplo de ello son los exploits que se aprovechan de un desbordamiento de búfer y que requieren, en muchos casos, de determinados valores (direcciones de instrucciones) únicos de cada S.O. En estos casos, el objetivo del exploit es sobrescribir valores en el stack hasta alcanzar determinados posiciones de memoria como el return address o la tabla de excepciones SEH. Estas variables son reemplazadas por instrucciones (jmp reg, call reg, pop pop ret, push reg ret, etc.) que permiten saltar al payload dentro de la pila y que proceden en ciertos casos de librerías del S.O. y cuyas direcciones varían de una versión a otra o de un Service Pack a otro.
Se deduce, por tanto, que un atacante que conozca las versiones exactas tanto del S.O. así como la del software vulnerable, podrá construir un exploit capaz de ejecutar código en la máquina objetivo. En cambio, un exploit incorrectamente «ajustado» seguramente produciría la caída o bloqueo de la aplicación vulnerable, frustrando así las intenciones del atacante.
Es por este motivo por el que muchos de los exploits disponibles en el Framework Metasploit ofrecen la posibilidad de especificar el target (opción show target) antes de lanzarlos. La siguiente figura muestra la sección de código encargado de seleccionar la versión exacta del S.O. y donde se muestra el valor de la instrucción ret en cada uno de ellos.
Figura 1: Show Targets
De la misma forma, si se observan muchos de los exploits disponibles en www.exploit-db.com, éstos necesitan ser «ajustados» antes de ser lanzados por el motivo comentado anteriormente. El siguiente ejemplo es un extracto de un exploit remoto contra el servidor KnFTP.
En el código se aprecia que se hace uso de la instrucción jmp esp para sobrescribir la dirección de retorno en la función en la que se produce el desbordamiento de búfer. La dirección de dicha instrucción para un Windows XP SP3 (inglés) es 7C874413 (representada en little endian) y reside en kernel32.dll. Cuando se ejecute el exploit, la dirección de retorno de la función sobrescrita apuntará a 7C874413, que «saltará» a ESP (debido al jmp esp) donde empezará a ejecutarse el código del egghunter encargado de buscar y ejecutar el payload en memoria.
Figura 2: Exploit KnFTP
Si se quisiera lanzar ese exploit por ejemplo contra una máquina Windows SP3 en español, se necesitaría comprobar si existe tal instrucción en dicha dirección. En caso de no ser así se necesitaría buscar otra dirección válida (sin null bytes, bad caracteres, etc.) bien en otra librería del S.O. o bien utilizando el propio ejecutable o alguna de sus dlls para hacerlo más estable, teniendo en cuenta ciertas contramedidas como safeseh, stack cookies, etc. Como se ve en la siguiente captura (imagen A), la dirección 7C874413 en un Win SP3 (español) no contiene un JMP ESP, por tanto, si se lanzara este exploit sin modificarlo seguramente tiraría el servidor FTP abajo. Para construir el exploit de forma efectiva necesitamos buscar una dirección válida con «algo» que nos permita saltar a ESP, por ejemplo un CALL ESP, como se muestra en la imagen B.
Figura 3: Bad JMP ESP
Figura 4: Call ESP
En otros casos, el atacante puede tener más suerte y contar con un exploit universal que afecte a un sistema operativo independientemente de su versión o incluso que el propio exploit pueda hacer un brute-force de tales direcciones sin producir una caída de la aplicación, por ejemplo, en casos en los que un servicio genera procesos hijos para atender diversas peticiones (ej. servidores web, smb, etc.).
Figura 5: PHP 6.0 Dev str_transliterate() Buffer overflow - NX + ASLR Bypass
De la misma forma que conocer el S.O. ayudará enormemente en la elaboración de exploits, saber de antemano el antivirus que una organización utiliza facilitará y ahorrará también mucho esfuerzo al atacante. Este dato puede aumentar aún más las posibilidades de intrusión si lo que se pretende es «troyanizar» la máquina de la víctima. Modificar un binario con el objetivo de eludir firmas que puedan ser detectadas por el AV será mucho más fácil si se conoce el producto en cuestión. La gran mayoría de AV disponen de firmas para payloads ampliamente conocidos como Meterpreter, bind/reverse shell, etc. así como troyanos y malware de diversa índole. Utilizando encoders, packers, o incluso manualmente es posible eludir dichas firmas para hacerlos prácticamente indetectables por la gran mayoría de fabricantes antivirus basados en firmas.
En el siguiente ejemplo se utilizará msfvenom para generar una staged reverse_shell (windows/shell/reverse_tcp). La ventaja de un staged payload es que el ejecutable únicamente contendrá el código necesario para conectar con el equipo del atacante desde donde se enviará el resto del payload. De esta forma, el proceso nunca guardará en disco el payload recibido, el cual es susceptible de contener las firmas que alertarían al AV sobre una posible reverse shell. En el ejemplo también se ha utilizado como encoder shikata_ga_nai con un total de 12 iteraciones para dificultar aún más la detección por parte de los los AV. El paper “Exploit writing tutorial part 9: Introduction to Win32 shellcoding” de Corelan es una de las mejores referencias para comprender cómo trabajan los encoders y como ayudan enormemente no solo a tratar con bad characters a la hora de desarrollar exploits, sino también a la hora de ofuscar código para evadir sistemas AV. En la salida generada por VirusTotal.com puede apreciarse como de un total de 42 AV, ninguno ha identificado como dañino el ejecutable reverse.exe.
Figura 6: Staged Reverse Shell
Otra alternativa a http://www.virustotal.com/ para testear los ejecutables sin miedo a que se puedan generar nuevas firmas para los diversas marcas AV (o si lo que se pretende es esconder información confidencial o utilizarlo en otros proyectos) es http://vscan.novirusthanks.org/ especificando la opción “Do not distribute the sample”.
Existen numerosos métodos y técnicas para evadir AV por ejemplo, mediante la herramienta ShellCodeExec, desarrollada por Bernardo Damele, es posible inyectar una alphanumeric-encoded shellcode en el espacio de direcciones de un proceso haciéndolo de igual forma prácticamnte indetectable. Otro ejemplo que muestra cómo crear un backdoor multiplataforma en python (reverse Shell) en apenas 13 líneas y eludiendo los 43 AV lo proporciona David Kennedy (autor de SET):
Muchas organizaciones sin ser conscientes de esto, reenvían correos donde puede verse el tipo de software AV que emplean o directamente son víctimas de ingeniería social y donde, sin mucho esfuerzo, ellos mismos delatan el tipo de antivirus utilizado. En libros como «El arte del engaño» de Kevin Mitnick o «Social Engineering: The Art of Human Hacking», de Christopher Hadnagy, se describen hechos reales y casos de estudio donde se refleja la eficiencia de la ingeniería social y donde se pone de manifiesto que en muchos casos la labia y la psicología son más eficientes que la propia tecnología para conseguir información.
Figura 7: “NOD32 Antivirus ha comprobado este mensaje”
Queda claro por tanto, que cualquier dato que proporcione información acerca de los sistemas que se planea comprometer serán puntos a favor para el atacante y esto es precisamente lo que cubre la fase de Information Gahering. Bien de forma pasiva o activa, esta fase comprende un conjunto de técnicas que permiten obtener información sobre el entorno de la víctima. Por ejemplo, una de estas partes denominada Fingerprinting se encargará de localizar el mayor número de máquinas/redes y dispositivos así como servicios y versiones de los S.O.
A modo de ejemplo práctico, y para poner de manifiesto la importancia de estas técnicas, a continuación se propondrán 3 casos de intrusión, los cuales cubrirán varios objetivos. Por una parte, mostrar la facilidad con la que hoy en día es posible planificar un ataque sin necesidad de ser un experto. Y, por otra, concienciar a administradores y responsables de seguridad de la importancia que tienen las políticas de seguridad orientadas a controlar de forma exhaustiva la información de una organización.
Caso 1: Spear phishing attack
Como ejemplo análogo al descrito en la introducción, a continuación se mostrará como un ciberdelincuente puede planear un ataque para infiltrarse en una organización. Tras dedicar gran cantidad de tiempo, con herramientas como Nmap, Nessus, Nikto, etc. con el objetivo de buscar información sobre el dominio, equipos, puertos abiertos, topología de red, firewalls/IDS, servicios corriendo, etc., sin encontrar una puerta de entrada o un vector de ataque, el atacante, como último recurso, decide llevar a cabo un Spear-Phishing Attack. La idea de este ataque es enviar un documento malicioso a la víctima y utilizar un poco de ingeniería social para que lo abra.
El primer paso que lleva a cabo es conseguir la mayor cantidad posible de información sobre empleados de la organización, esto es, correos electrónicos, nombres de usuario, perfiles, etc. Para ello utiliza las herramientas theHarvester, la Foca y Maltego. TheHarvester permite obtener listas de nombres y emails indexados por motores de búsqueda como Google, Bind o Linkedin además de proporcionar DNS Enumeration, Reverse lookups, etc.
En su última versión, además, incorpora la base de datos de SHODAN permitiendo obtener banners y puertos de diferentes fuentes públicas.
Tras investigar un rato, el ciberdelicuente encuentra gran cantidad de emails públicos así como metainformación en documentos ofimáticos publicados en el propio dominio de la organización. Comparando la salida de dichas herramientas empieza a correlacionar información observando, por ejemplo, que usuarios con perfiles públicos en servicios como Linkedin son autores de algunos de los documentos publicados. La herramienta Foca permite extraer metadatos de gran variedad de documentos ofimáticos localizados por medio de motores de búsqueda, como Google o Bind. Mucha de esta metainformación, ignorada por la propia compañía en muchas ocasiones, puede proporcionar información valiosa para un atacante: IPs privadas, emails, nombres de usuario, software utilizado, etc.
En la salida, el usuario Antonio Galindo con correo [email protected], dispone de varios papers técnicos sobre Switching/Routing con metadatos interesantes.
Figura 8: Metadatos con Foca, Username
Por un lado, todos sus documentos revelan que dispone de la versión Microsoft Office XP y que la máquina es un Windows XP. Además, observando las horas en las que crea y modifica dichos ficheros junto al tipo de impresora empleada, hace pensar que se trata del equipo de trabajo de dicho usuario.
Teniendo en cuenta dicha versión de Office el atacante se decanta por utilizar el exploit ms10_087_rtf_pfragments_bof.rb. Dicho exploit (CVE-2010-3333) aprovecha una vulnerabilidad en ficheros Microsoft Word RTF que afecta a una amplia gama de productos Office. La vulnerabilidad permite un desbordamiento de búfer basado en pila en el parámetro ‘pFragments’ cuando se parsea un fichero RTF. Para generar el exploit utiliza Metasploit:
Figura 9: Metadatos con Foca, Operating System
Teniendo en cuenta la escasa preocupación de la víctima por mantener su software actualizado, el atacante decide emplear un segundo exploit de respaldo que afecta a Adobe Flash Player. La vulnerabilidad explotada es CVE-2011-0609, la misma utilizada para comprometer los sistemas de RSA mediante un fichero .xls con un swf embebido. Dicha vulnerabilidad se aprovecha de una validación incorrecta de bytecode por parte de la ActionScript Virtual Machine (AVM) permitiendo ejecutar código por medio de heap spraying. La vulnerabilidad afecta a Adobe Flash Player 10.2.152.33 e inferiores versiones para Windows, Macintosh, Linux y Solaris. El exploit disponible en Metasploit es válido para IE6, IE7 y Firefox 3.6 así que si hay un poco de suerte y la víctima dispone de alguna de estas versiones conseguirá shell.
Por tanto, el atacante dispone de un fichero RTF malicioso y un servidor http falso corriendo en el puerto 80 esperando alguna petición. Además, tiene un handler en el puerto 443 esperando una shell en el caso de que algunas de las vulnerabilidades sea explotada. El siguiente paso es enviarle un email incitándole a que, o bien abra dicho fichero o bien visite la URL. Aquí es donde entra en juego la ingeniería social. Tras leer alguno de los post en los que la víctima participa, observa que técnicos de varias empresas discuten sobre ventajas e inconvenientes de ciertos protocolos de routing en determinados escenarios.
Figura 10: Configuración OSPF (Foro Networking)
Con toda esta información decide crear un correo suplantando la dirección de alguno de estos usuarios. Esto aumentaría las posibilidades de que la víctima abra un correo procedente de los mismos. Previamente comprueba si algunos de los dominios pertenecientes a dichos usuarios contienen registros SPF (Sender ID):
Figura 11: Registros SPF
Aunque no disponer de registros SPF no garantiza que el mail no sea filtrado por el MTA de dicha organización, sí habrá más garantías de que alcance el objetivo. Finalmente, envía un correo con un asunto y descripción que enganche. Por un lado, se envía como adjunto el RTF malicioso y, por otro, la URL maliciosa en la propia descripción del correo:
Figura 12: SendEmail
El usuario, tras abrir el correo pulsa en el enlace abriéndose el navegador y ejecutándose el exploit. El atacante recibe un mail de confirmación y una sesión de Meterpreter teniendo acceso total al sistema comprometido.
Desde ahí podrá escanear y «saltar» a otras máquinas y redes mediante técnicas como pivoting (5.1.1), consiguiendo así comprometer la organización al completo. En la imagen, tras obtener shell en el equipo de la víctima, consigue elevar privilegios mediante la extensión getsystem. Dicha extensión utiliza diversas técnicas y exploits (ej. kitrap0d) para intentar elevar privilegios en el sistema.
Figura 13: Meterpreter Session (AutoRunScript migrate_mail)
Incluso si el administrador del dominio se ha logueado recientemente en dicha máquina es posible «tomar prestado» el token generado por Kerberos y asumir su rol mediante token impersonation comprometiendo así el dominio al completo. Con la extensión incognito es posible lisar los tokens disponible en el sistema (list_tokens) para ver si se dispone del token del administrador del dominio. En el caso de contar con múltiples sesiones, puede utilizarse el script (post/windows/gather/enum_domain_tokens) de Jcran (http://www.pentestify.org) con el cual automatizar la búsqueda de dicho token.
Caso 2: Social engineering toolkit
Dada la importancia que tiene la ingeniería social en el mundo de la seguridad y en un intento de fusionar dicha habilidad con herramientas de pentesting se creó SET (Social Engineering Toolkit).
Desarrollada por David Kennedy (ReL1K), SET comprende una suite de herramientas desarrollada en Python que trata de poner en práctica numerosos vectores de ataque a tavés de la ingeniería social. En sus primeras versiones, SET presentó diversos ataques por medio de phishing, file-format bugs y certificados autofirmados en Java. Actualmente dispone de una gran variedad de vectores de ataques adicionales. Entre los más destacables se encuentra el vector de ataque Wireless Attack Vector que hace uso de airbase-ng para crear un Fake AP y redirigir tráfico, o el payload RATTE (Remote Administration Tool Tommy Edition) desarrollado por Thomas Werth y que permite tunelizar instrucciones mediante HTTP aprovechándose de las configuraciones locales del navegador, el payload Interactive Shell o el reciente e ingenioso Teensy USB HID Attack.
En el ejemplo anterior, el usuario necesitaba tener una versión de Office o Flash Player vulnerable para que se consiguiera ejecutar alguno de los exploits. Veamos cómo podemos hacer algo parecido desde este framework. En el ejemplo se utilizará el vector de ataque conocido como Multi-Attack Web Method utilizando para ello un sitio web falso que utilizará diversas técnicas para comprometer de alguna forma el equipo de la víctima.
Como se verá a continuación la ventaja principal de SET es la facilidad y rapidez con la que se puede preparar un vector de ataque. Apenas pulsando un par de teclas es suficiente para quedar a la espera de una shell.
El Multi-Attack Web Method te permite especificar sucesivos métodos de ataque hasta que alguno de ellos tenga éxito. En las imágenes se detalla el proceso de configuración del mismo. Una vez configurado como Site Clone la URL de login de uno de los portales de Inteco (https://conan.cert.inteco.es/login.php) especificamos el número de ataques que queremos utilizar. En este caso, hemos elegido la opción Tactical Nuke que habilita todos los tipos de ataques automáticamente.
Al final de la configuración, SET preparará un servicio web en su puerto 80 encargado de clonar y ofrecer la web fraudulenta además de un handler en el puerto 443 a la espera de una sesión de Meterpreter. Dicha URL se la enviaremos a la víctima y tras abrirla, el usuario se enfrentará a diversos métodos de ataque.
En un principio tanto el Applet de Java malicioso como el exploit que se aprovecha del XSS en el centro de ayuda y soporte de Microsoft (MS10-042) no tienen éxito por lo que, como último recurso, se lleva a cabo un Credential Harvester. Este método de ataque no tiene por objetivo explotar ninguna vulnerabilidad del navegador ni del S.O.; únicamente consigue las credenciales del usuario al que posteriormente redirige al sitio web legítimo para enmascarar el engaño.
En la salida, SET nos muestra las credenciales del usuario bmerino con password ConanElBarbaro24_#
Figura 14: Site Cloner
Figura 15: Tactical Nuke / Interactive Shell
Figura 16: Credential Harvester
Caso 3: Web server exploitation
En este caso, en lugar de utiliza la ingeniería social se intentará explotar un sitio web por medio de alguna vulnerabilidad conocida utilizando para ello diversas herramientas. El atacante utiliza Nikto, Watobo, Whatweb y WPScan para auditar un sitio web hasta que finalmente encuentra un posible punto de entrada. El servidor web contiene Joomla y parece ser que uno de sus componentes es candidato a ser vulnerable a un LFI (Local File Inclusión).
Figura 17: WhatWeb
Aunque se desconoce la versión exacta de dicho componente, según se puede leer en exploit-db, la versión afectada es la 2.X y los fabricantes no han proporcionado ningún tipo de parche o actualización por el momento por lo que es muy probable que el sitio sea vulnerable al mismo. Primero, se comprobará que realmente existe dicho componente con el siguiente dork:
Figura 18: Google Dork LFI
El siguiente paso será comprobar si existe el LFI en dicho componente. Para ello, se utilizará Fimap, herramienta en Python especializada en LFI/RFI sobre aplicaciones web que hacen mal uso de funciones como fopen(), include(), require(), require_once(), etc.
Fimap puede ahorrar gran cantidad de tiempo probando multitud de ficheros con los cuales hacer el LFI/RFI. Además, permite definir el payload a ejecutar si alguna de estas vulnerabilidades es explotada (por ej. una reverse shell).
Fimap permite también hacer de crawler dentro de un sitio web y generar un reporte con las vulnerabilidades encontradas una vez finalice las pruebas con cada una de las páginas y variables que encuentre en el sitio web.
Figura 19: Fimap Output
Según muestra la salida, parece ser que efectivamente el servidor web hace uso de una versión vulnerable de dicho componente.
Figura 20: LFI /etc/passwd
Además, permite acceder a /proc/self/environ por lo que ya hay una posible vía de entrada para ejecutar código PHP. Existen numerosos métodos para ejecutar código PHP en una situación LFI por medio de ficheros de configuración y logs.
Figura 21: /proc/self/environ
De hecho, uno de los motivos por lo que Fimap ahorra mucho tiempo es porque durante sus tests, prueba gran cantidad de ficheros locales susceptibles de ser utilizados. En este caso, suele emplearse el campo USER_AGENT del navegador para inyectar código PHP en el servidor web. El atacante decide entonces subir una shell que previamente creará con Weevely. Mediante Weevely podemos crear una shell codificada en base64 (útil para eludir determinados AV) que permite enviar y recibir parámetros por medio del campo HTTP REREFER, haciéndolo también bastante silencioso frente a ciertos NIDS. Además, dicha comunicación requiere de una contraseña que autentique al cliente de la conexión. Para generar la shell ejecutamos lo siguiente:
Figura 22: Backdoor con Weevely
Tras copiar la shell en /var/www, estará lista para su descarga por medio del USER_AGENT. Una vez lanzada la petición y visualizando de nuevo /proc/self/environ, se ejecutará la función system() descargando la shell en el servidor web.
Figura 23: Inyección de código por medio del User Agent (Tamper Data)
Para comunicarnos con la shell únicamente especificaremos su ruta y el password para autenticarnos. Si capturamos tráfico cuando enviamos órdenes con Weevely podemos ver como se utiliza el campo REFERER:
Figura 24: Shell por medio de Weevely
Vistos estos ejemplos, podemos extraer las siguientes conclusiones:
1. La efectividad de un ataque es totalmente proporcional a la cantidad de información que se tenga sobre el sistema objetivo.
2. El descuido por parte de responsables de seguridad sobre la publicación de determinada información puede ser utilizada de forma ofensiva para ingeniar un ataque. Lo mismo ocurre con configuraciones de servicios y sistemas que ofrecen información precisa sobre las versiones de software que están en funcionamiento (banners, mensajes de error, etc.)
3. No es necesario ser un experto para desplegar muchos de los ataques que hoy en día sufren organizaciones y empresas. La existencia de herramientas de pentesting utilizadas para llevar a cabo auditorías son también utilizadas por ciberdelicuentes para comprometer sistemas. La facilidad de uso de muchas de estas herramientas da lugar a que se incrementen los intentos de intrusión por personas que apenas tienen conocimientos básicos en seguridad.
4. No incluir la ingeniería social dentro de la gestión del riesgo puede tener implicaciones desastrosas para una organización. Esto se agrava aún más si se carece de contramedidas que permitan contener ataques de esta envergadura.
La auditoría preliminar sobre la reciente intrusión en los sistemas de la autoridad certificadora DigiNotar puso de manifiesto cómo el descuido de políticas de seguridad básicas dio lugar a una intrusión de tal dimensión. Falta de antivirus, contraseñas débiles, servidores CA dentro de un mismo dominio, software desactualizado, carencia de sistemas de validación de credenciales (login), etc. presentan el caldo de cultivo perfecto para un A.P.T (Advance Persistent Threat).
Como dato de interés, la serie de informes DBIR (Data Breach Investigations Report) de Verizon refleja un total de 1700 brechas de seguridad y más de 900 millones de registros comprometidos, dejando más que claro que las intrusiones y el robo de datos sigue siendo un problema crítico para las organizaciones.
Además, según el último “Security Intelligence Report” de Microsoft, los ataques por ingeniería social (como por ejemplo falsos antivirus o phishing) representan el 45% de los vectores de ataque actuales, mientras que, exploits 0 Day representan menos del 1% de los de los mismos.
NOTA: La etapa de Information Gathering es sin lugar a duda la más extensa de todo el proceso de intrusión. Esta fase implica la recopilación de información de numerosas fuentes, empleando para ello multitud de herramientas de pentesting. Para facilitar la organización de todos los datos que se vayan recopilando a lo largo de la investigación se han creado diversas herramientas como Basket, Leo, Dradis, etc. cuya misión es la de trabajar a modo de repositorio de información. En la imagen se muestra Dradis, un framework Open-Source que implementa un servidor de plugins con los cuales importar y parsear el contenido generado por herramientas externas como Nmap, Nessus, etc. Dradis viene pre-instalado en Backtrack 5 (/pentest/misc/dradis) y resulta realmente útil para ir anotando todo tipo de información sobre el sistema auditado.
Figura 25: Captura de Dradis (Bed Output)
Bueno amigos, hasta acá llega la primer parte del post. Mas adelante haré la parte 2 en la que voy a hablar de External footprinting.
Espero que les sirva y les allá gustado. Saludos.
Lo dividiré en varias partes, no se muy bien cuantas serán, así que vamos a empezar.
Parte 1:
Importancia del Fingerprinting
La explotación de alguna vulnerabilidad suele ser el objetivo principal de todo atacante. Poder ejecutar código en el sistema comprometido para llevar a cabo las acciones oportunas determina sin duda alguna el éxito de una intrusión. Casos como los del Hydraq (más conocido como Aurora) donde atacantes utilizando un 0 Day para Internet Explorer tuvieron por objetivo docenas de organizaciones, entre ellas Adobe Systems, Juniper Networks, Yahoo, Google, etc. O casos más recientes como Stuxnet, Duqu o la intrusión en RSA mediante phishing con un fichero .xls malicioso han puesto de moda el concepto Advanced Persistent Threat (A.P.T.). Este término, comúnmente usado para referirse a ciberataques que implican cierto nivel de sofisticación, y cuyo objetivo principal es el espionaje y robo de información, ha empezado a generar cierto temor en prácticamente cualquier organización. Dichos ataques presentan un denominador común: el atacante contiene información más que detallada y precisa de los sistemas objetivo. Para desempeñar una intrusión de tal envergadura el atacante debe dedicar tiempo a investigar sobre las redes, sistemas, correos, empleados, software, etc. utilizando diversas herramientas y técnicas (entre las que se incluye la ingeniería social) para más adelante personificar el ataque.
Exploits / Antivirus
Conocer la versión del sistema operativo y del software instalado es una de las partes cruciales que cubre el fingerprinting. Esto se debe a que, en la mayoría de los ataques, se emplean exploits que necesitan ser ajustados previamente con datos concretos que dependen de la versión exacta del propio software o del sistema operativo. Ejemplo de ello son los exploits que se aprovechan de un desbordamiento de búfer y que requieren, en muchos casos, de determinados valores (direcciones de instrucciones) únicos de cada S.O. En estos casos, el objetivo del exploit es sobrescribir valores en el stack hasta alcanzar determinados posiciones de memoria como el return address o la tabla de excepciones SEH. Estas variables son reemplazadas por instrucciones (jmp reg, call reg, pop pop ret, push reg ret, etc.) que permiten saltar al payload dentro de la pila y que proceden en ciertos casos de librerías del S.O. y cuyas direcciones varían de una versión a otra o de un Service Pack a otro.
Se deduce, por tanto, que un atacante que conozca las versiones exactas tanto del S.O. así como la del software vulnerable, podrá construir un exploit capaz de ejecutar código en la máquina objetivo. En cambio, un exploit incorrectamente «ajustado» seguramente produciría la caída o bloqueo de la aplicación vulnerable, frustrando así las intenciones del atacante.
Es por este motivo por el que muchos de los exploits disponibles en el Framework Metasploit ofrecen la posibilidad de especificar el target (opción show target) antes de lanzarlos. La siguiente figura muestra la sección de código encargado de seleccionar la versión exacta del S.O. y donde se muestra el valor de la instrucción ret en cada uno de ellos.
Figura 1: Show Targets
De la misma forma, si se observan muchos de los exploits disponibles en www.exploit-db.com, éstos necesitan ser «ajustados» antes de ser lanzados por el motivo comentado anteriormente. El siguiente ejemplo es un extracto de un exploit remoto contra el servidor KnFTP.
En el código se aprecia que se hace uso de la instrucción jmp esp para sobrescribir la dirección de retorno en la función en la que se produce el desbordamiento de búfer. La dirección de dicha instrucción para un Windows XP SP3 (inglés) es 7C874413 (representada en little endian) y reside en kernel32.dll. Cuando se ejecute el exploit, la dirección de retorno de la función sobrescrita apuntará a 7C874413, que «saltará» a ESP (debido al jmp esp) donde empezará a ejecutarse el código del egghunter encargado de buscar y ejecutar el payload en memoria.
Figura 2: Exploit KnFTP
Si se quisiera lanzar ese exploit por ejemplo contra una máquina Windows SP3 en español, se necesitaría comprobar si existe tal instrucción en dicha dirección. En caso de no ser así se necesitaría buscar otra dirección válida (sin null bytes, bad caracteres, etc.) bien en otra librería del S.O. o bien utilizando el propio ejecutable o alguna de sus dlls para hacerlo más estable, teniendo en cuenta ciertas contramedidas como safeseh, stack cookies, etc. Como se ve en la siguiente captura (imagen A), la dirección 7C874413 en un Win SP3 (español) no contiene un JMP ESP, por tanto, si se lanzara este exploit sin modificarlo seguramente tiraría el servidor FTP abajo. Para construir el exploit de forma efectiva necesitamos buscar una dirección válida con «algo» que nos permita saltar a ESP, por ejemplo un CALL ESP, como se muestra en la imagen B.
Figura 3: Bad JMP ESP
Figura 4: Call ESP
En otros casos, el atacante puede tener más suerte y contar con un exploit universal que afecte a un sistema operativo independientemente de su versión o incluso que el propio exploit pueda hacer un brute-force de tales direcciones sin producir una caída de la aplicación, por ejemplo, en casos en los que un servicio genera procesos hijos para atender diversas peticiones (ej. servidores web, smb, etc.).
Figura 5: PHP 6.0 Dev str_transliterate() Buffer overflow - NX + ASLR Bypass
De la misma forma que conocer el S.O. ayudará enormemente en la elaboración de exploits, saber de antemano el antivirus que una organización utiliza facilitará y ahorrará también mucho esfuerzo al atacante. Este dato puede aumentar aún más las posibilidades de intrusión si lo que se pretende es «troyanizar» la máquina de la víctima. Modificar un binario con el objetivo de eludir firmas que puedan ser detectadas por el AV será mucho más fácil si se conoce el producto en cuestión. La gran mayoría de AV disponen de firmas para payloads ampliamente conocidos como Meterpreter, bind/reverse shell, etc. así como troyanos y malware de diversa índole. Utilizando encoders, packers, o incluso manualmente es posible eludir dichas firmas para hacerlos prácticamente indetectables por la gran mayoría de fabricantes antivirus basados en firmas.
En el siguiente ejemplo se utilizará msfvenom para generar una staged reverse_shell (windows/shell/reverse_tcp). La ventaja de un staged payload es que el ejecutable únicamente contendrá el código necesario para conectar con el equipo del atacante desde donde se enviará el resto del payload. De esta forma, el proceso nunca guardará en disco el payload recibido, el cual es susceptible de contener las firmas que alertarían al AV sobre una posible reverse shell. En el ejemplo también se ha utilizado como encoder shikata_ga_nai con un total de 12 iteraciones para dificultar aún más la detección por parte de los los AV. El paper “Exploit writing tutorial part 9: Introduction to Win32 shellcoding” de Corelan es una de las mejores referencias para comprender cómo trabajan los encoders y como ayudan enormemente no solo a tratar con bad characters a la hora de desarrollar exploits, sino también a la hora de ofuscar código para evadir sistemas AV. En la salida generada por VirusTotal.com puede apreciarse como de un total de 42 AV, ninguno ha identificado como dañino el ejecutable reverse.exe.
Figura 6: Staged Reverse Shell
Otra alternativa a http://www.virustotal.com/ para testear los ejecutables sin miedo a que se puedan generar nuevas firmas para los diversas marcas AV (o si lo que se pretende es esconder información confidencial o utilizarlo en otros proyectos) es http://vscan.novirusthanks.org/ especificando la opción “Do not distribute the sample”.
Existen numerosos métodos y técnicas para evadir AV por ejemplo, mediante la herramienta ShellCodeExec, desarrollada por Bernardo Damele, es posible inyectar una alphanumeric-encoded shellcode en el espacio de direcciones de un proceso haciéndolo de igual forma prácticamnte indetectable. Otro ejemplo que muestra cómo crear un backdoor multiplataforma en python (reverse Shell) en apenas 13 líneas y eludiendo los 43 AV lo proporciona David Kennedy (autor de SET):
Muchas organizaciones sin ser conscientes de esto, reenvían correos donde puede verse el tipo de software AV que emplean o directamente son víctimas de ingeniería social y donde, sin mucho esfuerzo, ellos mismos delatan el tipo de antivirus utilizado. En libros como «El arte del engaño» de Kevin Mitnick o «Social Engineering: The Art of Human Hacking», de Christopher Hadnagy, se describen hechos reales y casos de estudio donde se refleja la eficiencia de la ingeniería social y donde se pone de manifiesto que en muchos casos la labia y la psicología son más eficientes que la propia tecnología para conseguir información.
Figura 7: “NOD32 Antivirus ha comprobado este mensaje”
Queda claro por tanto, que cualquier dato que proporcione información acerca de los sistemas que se planea comprometer serán puntos a favor para el atacante y esto es precisamente lo que cubre la fase de Information Gahering. Bien de forma pasiva o activa, esta fase comprende un conjunto de técnicas que permiten obtener información sobre el entorno de la víctima. Por ejemplo, una de estas partes denominada Fingerprinting se encargará de localizar el mayor número de máquinas/redes y dispositivos así como servicios y versiones de los S.O.
A modo de ejemplo práctico, y para poner de manifiesto la importancia de estas técnicas, a continuación se propondrán 3 casos de intrusión, los cuales cubrirán varios objetivos. Por una parte, mostrar la facilidad con la que hoy en día es posible planificar un ataque sin necesidad de ser un experto. Y, por otra, concienciar a administradores y responsables de seguridad de la importancia que tienen las políticas de seguridad orientadas a controlar de forma exhaustiva la información de una organización.
Caso 1: Spear phishing attack
Como ejemplo análogo al descrito en la introducción, a continuación se mostrará como un ciberdelincuente puede planear un ataque para infiltrarse en una organización. Tras dedicar gran cantidad de tiempo, con herramientas como Nmap, Nessus, Nikto, etc. con el objetivo de buscar información sobre el dominio, equipos, puertos abiertos, topología de red, firewalls/IDS, servicios corriendo, etc., sin encontrar una puerta de entrada o un vector de ataque, el atacante, como último recurso, decide llevar a cabo un Spear-Phishing Attack. La idea de este ataque es enviar un documento malicioso a la víctima y utilizar un poco de ingeniería social para que lo abra.
El primer paso que lleva a cabo es conseguir la mayor cantidad posible de información sobre empleados de la organización, esto es, correos electrónicos, nombres de usuario, perfiles, etc. Para ello utiliza las herramientas theHarvester, la Foca y Maltego. TheHarvester permite obtener listas de nombres y emails indexados por motores de búsqueda como Google, Bind o Linkedin además de proporcionar DNS Enumeration, Reverse lookups, etc.
En su última versión, además, incorpora la base de datos de SHODAN permitiendo obtener banners y puertos de diferentes fuentes públicas.
Tras investigar un rato, el ciberdelicuente encuentra gran cantidad de emails públicos así como metainformación en documentos ofimáticos publicados en el propio dominio de la organización. Comparando la salida de dichas herramientas empieza a correlacionar información observando, por ejemplo, que usuarios con perfiles públicos en servicios como Linkedin son autores de algunos de los documentos publicados. La herramienta Foca permite extraer metadatos de gran variedad de documentos ofimáticos localizados por medio de motores de búsqueda, como Google o Bind. Mucha de esta metainformación, ignorada por la propia compañía en muchas ocasiones, puede proporcionar información valiosa para un atacante: IPs privadas, emails, nombres de usuario, software utilizado, etc.
En la salida, el usuario Antonio Galindo con correo [email protected], dispone de varios papers técnicos sobre Switching/Routing con metadatos interesantes.
Figura 8: Metadatos con Foca, Username
Por un lado, todos sus documentos revelan que dispone de la versión Microsoft Office XP y que la máquina es un Windows XP. Además, observando las horas en las que crea y modifica dichos ficheros junto al tipo de impresora empleada, hace pensar que se trata del equipo de trabajo de dicho usuario.
Teniendo en cuenta dicha versión de Office el atacante se decanta por utilizar el exploit ms10_087_rtf_pfragments_bof.rb. Dicho exploit (CVE-2010-3333) aprovecha una vulnerabilidad en ficheros Microsoft Word RTF que afecta a una amplia gama de productos Office. La vulnerabilidad permite un desbordamiento de búfer basado en pila en el parámetro ‘pFragments’ cuando se parsea un fichero RTF. Para generar el exploit utiliza Metasploit:
Figura 9: Metadatos con Foca, Operating System
Teniendo en cuenta la escasa preocupación de la víctima por mantener su software actualizado, el atacante decide emplear un segundo exploit de respaldo que afecta a Adobe Flash Player. La vulnerabilidad explotada es CVE-2011-0609, la misma utilizada para comprometer los sistemas de RSA mediante un fichero .xls con un swf embebido. Dicha vulnerabilidad se aprovecha de una validación incorrecta de bytecode por parte de la ActionScript Virtual Machine (AVM) permitiendo ejecutar código por medio de heap spraying. La vulnerabilidad afecta a Adobe Flash Player 10.2.152.33 e inferiores versiones para Windows, Macintosh, Linux y Solaris. El exploit disponible en Metasploit es válido para IE6, IE7 y Firefox 3.6 así que si hay un poco de suerte y la víctima dispone de alguna de estas versiones conseguirá shell.
Por tanto, el atacante dispone de un fichero RTF malicioso y un servidor http falso corriendo en el puerto 80 esperando alguna petición. Además, tiene un handler en el puerto 443 esperando una shell en el caso de que algunas de las vulnerabilidades sea explotada. El siguiente paso es enviarle un email incitándole a que, o bien abra dicho fichero o bien visite la URL. Aquí es donde entra en juego la ingeniería social. Tras leer alguno de los post en los que la víctima participa, observa que técnicos de varias empresas discuten sobre ventajas e inconvenientes de ciertos protocolos de routing en determinados escenarios.
Figura 10: Configuración OSPF (Foro Networking)
Con toda esta información decide crear un correo suplantando la dirección de alguno de estos usuarios. Esto aumentaría las posibilidades de que la víctima abra un correo procedente de los mismos. Previamente comprueba si algunos de los dominios pertenecientes a dichos usuarios contienen registros SPF (Sender ID):
Figura 11: Registros SPF
Aunque no disponer de registros SPF no garantiza que el mail no sea filtrado por el MTA de dicha organización, sí habrá más garantías de que alcance el objetivo. Finalmente, envía un correo con un asunto y descripción que enganche. Por un lado, se envía como adjunto el RTF malicioso y, por otro, la URL maliciosa en la propia descripción del correo:
Figura 12: SendEmail
El usuario, tras abrir el correo pulsa en el enlace abriéndose el navegador y ejecutándose el exploit. El atacante recibe un mail de confirmación y una sesión de Meterpreter teniendo acceso total al sistema comprometido.
Desde ahí podrá escanear y «saltar» a otras máquinas y redes mediante técnicas como pivoting (5.1.1), consiguiendo así comprometer la organización al completo. En la imagen, tras obtener shell en el equipo de la víctima, consigue elevar privilegios mediante la extensión getsystem. Dicha extensión utiliza diversas técnicas y exploits (ej. kitrap0d) para intentar elevar privilegios en el sistema.
Figura 13: Meterpreter Session (AutoRunScript migrate_mail)
Incluso si el administrador del dominio se ha logueado recientemente en dicha máquina es posible «tomar prestado» el token generado por Kerberos y asumir su rol mediante token impersonation comprometiendo así el dominio al completo. Con la extensión incognito es posible lisar los tokens disponible en el sistema (list_tokens) para ver si se dispone del token del administrador del dominio. En el caso de contar con múltiples sesiones, puede utilizarse el script (post/windows/gather/enum_domain_tokens) de Jcran (http://www.pentestify.org) con el cual automatizar la búsqueda de dicho token.
Caso 2: Social engineering toolkit
Dada la importancia que tiene la ingeniería social en el mundo de la seguridad y en un intento de fusionar dicha habilidad con herramientas de pentesting se creó SET (Social Engineering Toolkit).
Desarrollada por David Kennedy (ReL1K), SET comprende una suite de herramientas desarrollada en Python que trata de poner en práctica numerosos vectores de ataque a tavés de la ingeniería social. En sus primeras versiones, SET presentó diversos ataques por medio de phishing, file-format bugs y certificados autofirmados en Java. Actualmente dispone de una gran variedad de vectores de ataques adicionales. Entre los más destacables se encuentra el vector de ataque Wireless Attack Vector que hace uso de airbase-ng para crear un Fake AP y redirigir tráfico, o el payload RATTE (Remote Administration Tool Tommy Edition) desarrollado por Thomas Werth y que permite tunelizar instrucciones mediante HTTP aprovechándose de las configuraciones locales del navegador, el payload Interactive Shell o el reciente e ingenioso Teensy USB HID Attack.
En el ejemplo anterior, el usuario necesitaba tener una versión de Office o Flash Player vulnerable para que se consiguiera ejecutar alguno de los exploits. Veamos cómo podemos hacer algo parecido desde este framework. En el ejemplo se utilizará el vector de ataque conocido como Multi-Attack Web Method utilizando para ello un sitio web falso que utilizará diversas técnicas para comprometer de alguna forma el equipo de la víctima.
Como se verá a continuación la ventaja principal de SET es la facilidad y rapidez con la que se puede preparar un vector de ataque. Apenas pulsando un par de teclas es suficiente para quedar a la espera de una shell.
El Multi-Attack Web Method te permite especificar sucesivos métodos de ataque hasta que alguno de ellos tenga éxito. En las imágenes se detalla el proceso de configuración del mismo. Una vez configurado como Site Clone la URL de login de uno de los portales de Inteco (https://conan.cert.inteco.es/login.php) especificamos el número de ataques que queremos utilizar. En este caso, hemos elegido la opción Tactical Nuke que habilita todos los tipos de ataques automáticamente.
Al final de la configuración, SET preparará un servicio web en su puerto 80 encargado de clonar y ofrecer la web fraudulenta además de un handler en el puerto 443 a la espera de una sesión de Meterpreter. Dicha URL se la enviaremos a la víctima y tras abrirla, el usuario se enfrentará a diversos métodos de ataque.
En un principio tanto el Applet de Java malicioso como el exploit que se aprovecha del XSS en el centro de ayuda y soporte de Microsoft (MS10-042) no tienen éxito por lo que, como último recurso, se lleva a cabo un Credential Harvester. Este método de ataque no tiene por objetivo explotar ninguna vulnerabilidad del navegador ni del S.O.; únicamente consigue las credenciales del usuario al que posteriormente redirige al sitio web legítimo para enmascarar el engaño.
En la salida, SET nos muestra las credenciales del usuario bmerino con password ConanElBarbaro24_#
Figura 14: Site Cloner
Figura 15: Tactical Nuke / Interactive Shell
Figura 16: Credential Harvester
Caso 3: Web server exploitation
En este caso, en lugar de utiliza la ingeniería social se intentará explotar un sitio web por medio de alguna vulnerabilidad conocida utilizando para ello diversas herramientas. El atacante utiliza Nikto, Watobo, Whatweb y WPScan para auditar un sitio web hasta que finalmente encuentra un posible punto de entrada. El servidor web contiene Joomla y parece ser que uno de sus componentes es candidato a ser vulnerable a un LFI (Local File Inclusión).
Figura 17: WhatWeb
Aunque se desconoce la versión exacta de dicho componente, según se puede leer en exploit-db, la versión afectada es la 2.X y los fabricantes no han proporcionado ningún tipo de parche o actualización por el momento por lo que es muy probable que el sitio sea vulnerable al mismo. Primero, se comprobará que realmente existe dicho componente con el siguiente dork:
Figura 18: Google Dork LFI
El siguiente paso será comprobar si existe el LFI en dicho componente. Para ello, se utilizará Fimap, herramienta en Python especializada en LFI/RFI sobre aplicaciones web que hacen mal uso de funciones como fopen(), include(), require(), require_once(), etc.
Fimap puede ahorrar gran cantidad de tiempo probando multitud de ficheros con los cuales hacer el LFI/RFI. Además, permite definir el payload a ejecutar si alguna de estas vulnerabilidades es explotada (por ej. una reverse shell).
Fimap permite también hacer de crawler dentro de un sitio web y generar un reporte con las vulnerabilidades encontradas una vez finalice las pruebas con cada una de las páginas y variables que encuentre en el sitio web.
Figura 19: Fimap Output
Según muestra la salida, parece ser que efectivamente el servidor web hace uso de una versión vulnerable de dicho componente.
Figura 20: LFI /etc/passwd
Además, permite acceder a /proc/self/environ por lo que ya hay una posible vía de entrada para ejecutar código PHP. Existen numerosos métodos para ejecutar código PHP en una situación LFI por medio de ficheros de configuración y logs.
Figura 21: /proc/self/environ
De hecho, uno de los motivos por lo que Fimap ahorra mucho tiempo es porque durante sus tests, prueba gran cantidad de ficheros locales susceptibles de ser utilizados. En este caso, suele emplearse el campo USER_AGENT del navegador para inyectar código PHP en el servidor web. El atacante decide entonces subir una shell que previamente creará con Weevely. Mediante Weevely podemos crear una shell codificada en base64 (útil para eludir determinados AV) que permite enviar y recibir parámetros por medio del campo HTTP REREFER, haciéndolo también bastante silencioso frente a ciertos NIDS. Además, dicha comunicación requiere de una contraseña que autentique al cliente de la conexión. Para generar la shell ejecutamos lo siguiente:
Figura 22: Backdoor con Weevely
Tras copiar la shell en /var/www, estará lista para su descarga por medio del USER_AGENT. Una vez lanzada la petición y visualizando de nuevo /proc/self/environ, se ejecutará la función system() descargando la shell en el servidor web.
Figura 23: Inyección de código por medio del User Agent (Tamper Data)
Para comunicarnos con la shell únicamente especificaremos su ruta y el password para autenticarnos. Si capturamos tráfico cuando enviamos órdenes con Weevely podemos ver como se utiliza el campo REFERER:
Figura 24: Shell por medio de Weevely
Vistos estos ejemplos, podemos extraer las siguientes conclusiones:
1. La efectividad de un ataque es totalmente proporcional a la cantidad de información que se tenga sobre el sistema objetivo.
2. El descuido por parte de responsables de seguridad sobre la publicación de determinada información puede ser utilizada de forma ofensiva para ingeniar un ataque. Lo mismo ocurre con configuraciones de servicios y sistemas que ofrecen información precisa sobre las versiones de software que están en funcionamiento (banners, mensajes de error, etc.)
3. No es necesario ser un experto para desplegar muchos de los ataques que hoy en día sufren organizaciones y empresas. La existencia de herramientas de pentesting utilizadas para llevar a cabo auditorías son también utilizadas por ciberdelicuentes para comprometer sistemas. La facilidad de uso de muchas de estas herramientas da lugar a que se incrementen los intentos de intrusión por personas que apenas tienen conocimientos básicos en seguridad.
4. No incluir la ingeniería social dentro de la gestión del riesgo puede tener implicaciones desastrosas para una organización. Esto se agrava aún más si se carece de contramedidas que permitan contener ataques de esta envergadura.
La auditoría preliminar sobre la reciente intrusión en los sistemas de la autoridad certificadora DigiNotar puso de manifiesto cómo el descuido de políticas de seguridad básicas dio lugar a una intrusión de tal dimensión. Falta de antivirus, contraseñas débiles, servidores CA dentro de un mismo dominio, software desactualizado, carencia de sistemas de validación de credenciales (login), etc. presentan el caldo de cultivo perfecto para un A.P.T (Advance Persistent Threat).
Como dato de interés, la serie de informes DBIR (Data Breach Investigations Report) de Verizon refleja un total de 1700 brechas de seguridad y más de 900 millones de registros comprometidos, dejando más que claro que las intrusiones y el robo de datos sigue siendo un problema crítico para las organizaciones.
Además, según el último “Security Intelligence Report” de Microsoft, los ataques por ingeniería social (como por ejemplo falsos antivirus o phishing) representan el 45% de los vectores de ataque actuales, mientras que, exploits 0 Day representan menos del 1% de los de los mismos.
NOTA: La etapa de Information Gathering es sin lugar a duda la más extensa de todo el proceso de intrusión. Esta fase implica la recopilación de información de numerosas fuentes, empleando para ello multitud de herramientas de pentesting. Para facilitar la organización de todos los datos que se vayan recopilando a lo largo de la investigación se han creado diversas herramientas como Basket, Leo, Dradis, etc. cuya misión es la de trabajar a modo de repositorio de información. En la imagen se muestra Dradis, un framework Open-Source que implementa un servidor de plugins con los cuales importar y parsear el contenido generado por herramientas externas como Nmap, Nessus, etc. Dradis viene pre-instalado en Backtrack 5 (/pentest/misc/dradis) y resulta realmente útil para ir anotando todo tipo de información sobre el sistema auditado.
Figura 25: Captura de Dradis (Bed Output)
Bueno amigos, hasta acá llega la primer parte del post. Mas adelante haré la parte 2 en la que voy a hablar de External footprinting.
Espero que les sirva y les allá gustado. Saludos.