Entre Bits y Valores: El Debate Ético en Torno al Cifrado de Extremo a Extremo

 ¿Qué es el cifrado extremo a extremo y por qué es importante?

A lo largo de la última década, la seguridad de la información ha ido cobrando mayor importancia y concienciación, donde uno de los aspectos de la seguridad ha sido conversar de manera privada evolucionando los sistemas arcaicos de trasmisión de información en claro por sofisticados mecanismos de cifrado extremo a extremo. 

El cifrado de extremo a extremo (E2EE – End to End Ecryption) es un mecanismo de seguridad informática que permite garantizar la confidencialidad y la integridad de los datos en una comunicación entre dos partes a través de un canal potencialmente inseguro. Consiste en cifrar los datos en el extremo origen y descifrarlos en el destino (cliente-cliente) sin que esto se haga en el servidor del proveedor de servicios, asegurando que un tercero no logre interceptar los datos en claro sin la clave de descifrado pertinente. El par de claves asimétrico [1], se genera entre el remitente y el destinatario, lo que implica que sólo estas dos partes tienen acceso a las claves necesarias para descifrar los datos. Por tanto, la pérdida del par de claves impediría el acceso a los mensajes trasmitidos. 

Un ejemplo práctico se encuentra en aplicaciones de mensajería instantánea como Signal, proyecto de código abierto haciendo uso de cifrado robusto Extended Triple Diffie-Hellman [2] o Post-Quantum Extended Diffie-Hellman [3] a prueba de ordenadores cuánticos. En ésta se garantiza la privacidad desde el punto de vista tecnológico cuyo único dato vinculado es el número de teléfono. Aunque pueda parecer una aplicación ideal desde el punto de vista de la privacidad, la principal desventaja que presenta es su uso poco extendido. Otras aplicaciones muy conocidas como WhatsApp también se basan en el mismo esquema [4], donde la privacidad de las conversaciones se mantiene intacta (siempre y cuando no hayas sido reportado por un usuario [5]). Por contra, la gran cantidad de otros datos y metadatos del usuario no cifrados y recopilados en sus servidores podría poner en peligro la privacidad [6]. 

Otra arquitectura opuesta al cifrado extremo a extremo es el cifrado de datos en tránsito, que consiste cifrar el mensaje en el extremo emisor, descifrarlo en el servidor, volver a cifrarlo en éste y descifrarlo finalmente en el extremo receptor (cliente-servidor-cliente). Al igual que el anterior, protege la información durante su transmisión, pero permite que el servidor intermediario pueda hacer uso de los mensajes transmitidos [7].

Un ejemplo de esta arquitectura es el aplicativo Telegram, donde los mensajes privados utilizan la nube para alojar y procesar los datos transmitidos. No obstante, el aplicativo también ofrece la opción de cifrar extremo a extremo la comunicación mediante los ‘mensajes secretos’ [8]. 

Como se puede observar, las tecnologías en la privacidad son muy sofisticadas, donde a pesar de la arquitectura o los cifrados empleados, existen factores no tecnológicos como las condiciones y la gestión ofrecidas por las proveedoras de servicios que pueden influir de manera indirecta en la privacidad del usuario. 

Teniendo en cuenta el auge del cifrado E2EE no sólo en el ámbito de la mensajería instantánea con funciones básicas muy comunes entre ellas, sino también en el correo electrónico, videoconferencia u otros, existe un punto de inflexión donde los usuarios con intenciones fraudulentas podrían aprovechar las ventajas de la tecnología para transmitir contenido ilegal sin ser detectado. Tanto es así, que las instituciones gubernamentales podrían implementar restricciones en el uso de los protocolos extremo a extremo [9]  al verse entorpecidos en el control masivo de contenido ilícito mediante palabras clave u otros métodos, tal y cómo ocurrió en 1993 con Phil Zimmermann [10] bajo investigación por el haber publicado PGP (Pretty Good Privacy). Una posible medida podría consistir en obligar a las empresas tecnológicas a implementar mecanismos de control o escaneos de contenido en cada extremo antes del cifrado y su emisión al receptor, dejando la característica principal del protocolo inutilizado. 

Por recapitular, independientemente del dilema moral hasta dónde se debe permitir el acceso de las autoridades a nuestra privacidad, se recomienda el uso de aplicaciones que recojan el menor número de datos posibles, a ser posible de código abierto y no controlados por una compañía gigante conocida por sus fines comerciales. Adicionalmente se recomienda proteger el extremo más débil,  el terminal, no sólo a nivel de aplicativos con posible malware incrustado, vulnerabilidades explotables o backdoors, sino también mediante la protección de una contraseña robusta o el empleo de doble factor de verificación. 

¿Qué opinas sobre prohibir el uso de cifrados de extremo a extremo? 

¿Y sobre el uso de estos protocolos?

¿Está reñida la privacidad la finalidad de la comunicación?

Referencias

[1] J. Ramió Aguirre, «Class4crypt c4c10.4 Algoritmo RSA,» [En línea]. Available: https://youtu.be/w5dWeZwfK8w?si=70Arkine_WmHy3jX

[2] Wikipedia, [En línea]. Available: https://en.wikipedia.org/wiki/Post-Quantum_Extended_Diffie-Hellman

[3] Web. [En línea]. Available: https://en.wikipedia.org/wiki/Post-Quantum_Extended_Diffie-Hellman

[4] WhatsApp, [En línea]. Available: https://faq.whatsapp.com/820124435853543/?locale=es_LA

[5] WhatsApp, [En línea]. Available: https://faq.whatsapp.com/414631957536067/?helpref=hc_fnav

[6] Xataka, «Signal vs Telegram vs WhatsApp: cuáles son las diferencias y cuál cuida más tu privacidad,» [En línea]. Available: https://www.xataka.com/basics/signal-vs-telegram-vs-whatsapp-cuales-diferencias-cual-cuida-tu-privacidad

[7] «¿Qué es el cifrado de extremo a extremo y por qué lo necesitas?,» [En línea]. Available: https://www.kaspersky.es/blog/what-is-end-to-end-encryption/23862/

[8] Telegram, [En línea]. Available: https://core.telegram.org/api/end-to-end

[9] «Leaked Government Document Shows Spain Wants to Ban End-to-End Encryption,» [En línea]. Available: https://www.wired.com/story/europe-break-encryption-leaked-document-csa-law/

[10] «The Critical Hole at the Heart of Our Cell Phone Networks,» [En línea]. Available: https://www.wired.com/2016/04/the-critical-hole-at-the-heart-of-cell-phone-infrastructure/

Arturo Fernández,  Analista de Ciberseguridad en Zerolynx.

Auditoría básica de ciberseguridad a un dominio de Microsoft

El Directorio Activo (Active Directory) es un componente crítico en la infraestructura de muchas organizaciones, utilizado para gestionar recursos y usuarios en entornos Windows. La auditoría de Directorio Activo es esencial para garantizar la seguridad de la red y la integridad de los datos. A continuación, partiendo del compromiso asumido de que un usuario de dominio ha sido vulnerado, exploraremos los principales vectores de ataque que debemos identificar:

1. Escalada de Privilegios Local

Aunque no siempre es necesario, es altamente recomendable partir de permisos de administración en la máquina atacante. De esta manera el uso de herramientas será mucho más cómodo. Para ello se pueden utilizar herramientas como PowerUp, WinPeas o SeatBelt entre otras, para identificar caminos que permitan una escalada a administrador local.

2. Políticas de Contraseñas

Una política de contraseñas débil puede ser útil para realizar ataques de tipo passwordspraying (esto debe realizarse cuidadosamente para no bloquear cuentas) o para el posterior crackeo de hashes identificados. Además, en caso de que no exista política de bloqueo tras intentos fallidos, sería posible hacer fuerza bruta contra todo el dominio sin temor a bloquear las cuentas de usuario.

3. Identificar secretos en carpetas compartidas.

Una vez se dispone de un usuario de dominio, es recomendable enumerar las carpetas compartidas a las que se tiene acceso (por ejemplo, con smbclient). En ocasiones, se pueden identificar documentos que recogen algún tipo de credencial, la cual puede ser válida o servir como punto de partida para adivinar otras contraseñas.

4. Identificación de sistemas operativos obsoletos

Se debe verificar que no se estén utilizando sistemas operativos fuera de soporte y/o desactualizados. Este tipo de equipos pueden ser muy útiles, ya que es altamente probable que tengan vulnerabilidades explotables con exploits públicos. Aunque no se traten de objetivos relevantes, acceder a ellos puede ser interesante para obtener las credenciales que tengan almacenadas. Es muy importante avisar al responsable de IT de que se va a hacer uso de exploits, por si estos pudiesen causar una caída en el servicio de la empresa.

5. Identificación de cuentas privilegiadas

Es muy interesante realizar un proceso inicial de enumeración en el que se identifiquen las cuentas objetivo que permitan comprometer la totalidad del dominio. Durante esta fase de enumeración no solo se buscan las cuentas de Domain admin, si no que también es importante identificar cuentas con permisos especiales que permitan llevar a cabo movimientos en el dominio. En puntos siguientes veremos por qué esto es importante.

6. Identificación y Abuso de cuentas con Constrained Delegation

En un punto anterior se indicaba que era necesario identificar cuentas con permisos elevados, pues este es un tipo concreto de cuenta privilegiada. Estas pueden tener delegado en ellas el poder de impersonar a cualquier usuario del dominio para una serie de servicios determinados. Gracias a esto, si se consigue comprometer una cuenta con constrained delegation, es posible suplantar a cualquier usuario para servicios de Windows como host, RPCSS, http, wsman, cifs, ldap, krbtgt o winrm.

8. Identificación y Abuso de Unconstrained Delegation

Este es otro tipo de cuenta privilegiada de alto interés. Estas cuentas están autorizadas para recibir y almacenar los TGT (Ticket Granting Ticket) de kerberos de cualquier cuenta. Es por ello, que al acceder a ellas sería posible extraer los tickets almacenados en las mismas. Por otro lado, también es posible realizar ataques de autenticación forzada sobre esta máquina, es decir, forzar a cualquier máquina del domino a autenticarse contra la máquina unconstrained comprometida. De esta manera, la nueva víctima (el controlador de dominio, por ejemplo) enviaría una copia de su TGT a la máquina unconstrained, siendo posible su interceptación.

9. Identificar y Abusar Permisos de DCSync

Seguimos con cuentas privilegiadas interesantes. En este caso es necesario identificar cuentas con permisos de DCSync, es decir, cuentas que tengan los permisos DS-Replication-Get-Changes-All y DS-Replication-Get-Changes. Si conseguimos comprometer una credencial con estos permisos, podremos realizar un ataque de DCSync, o lo que es lo mismo, simular que somos un controlador de dominio que quiere sincronizar su base de datos (ntds.dit) con la del controlador de dominio real. De esta manera se obtendrían todos los hashes del dominio, incluyendo los del Domain Admin.

10. Identificar y Abusar Resource-Based Constrained Delegation

Si como atacantes podemos identificar una cuenta con permisos de “GenericWrite” o “GenericAll” sobre “ActiveDirectoryRights”, significará que esta cuenta tiene la capacidad de otorgar permisos de constrained delegation a cualquier cuenta del dominio. Esto quiere decir que, si comprometemos esta cuenta, podremos indicar que cualquier cuenta del dominio pueda pedir TGSs (Ticket Garanting Service) para servicios de cualquier máquina del dominio, incluyendo nuestro objetivo principal: el controlador de dominio.

11. Identificar y Abusar Plantillas de Certificados Vulnerables

Este tipo de ataque se basa en utilizar herramientas como certify o certipy para identificar plantillas de certificados vulnerables en la CA (certificate authority) corporativa. Existen una serie de escenarios vulnerables posibles, que permiten a un atacante solicitar certificados en nombre de otros usuarios, por ejemplo, de un Domain Admin o de cualquier cuenta privilegiada.

12. Identificar Servicios Vulnerables

Es posible que en los directorios activos se encuentren máquinas con servicios diferentes a los propios del directorio activo desplegados (aunque no es una buena práctica), por ejemplo, Jenkins o servicios SQL. Es importante identificar estos servicios para comprobar si son vulnerables, ya que en muchas ocasiones pueden servir como punto de acceso a la máquina en la que se están ejecutando. La situación ideal para un atacante sería identificar un servicio que poder explotar, y que este estuviese siendo ejecutado con un usuario administrador local de la máquina. De esta manera, al conseguir ejecución remota de código mediante el servicio explotable, sería posible comprometer toda la máquina.

13. Kerberoasting

Kerberoasting es un ataque que se basa en la explotación de cuentas de servicio que tienen asociados Service Principal Names (SPNs). Estos SPNs son registros que asocian un servicio o aplicación específica con una cuenta de servicio en el Directorio Activo.

El objetivo de hacer kerberoasting es solicitar tickets de estas cuentas de servicio para, posteriormente, descifrarlos offline y obtener las contraseñas originales. Esto es posible ya que parte del ticket solicitado está cifrado utilizando una clave derivada de la contraseña original.

14. Extracción de Credenciales

Una vez comprometida cualquier máquina, el procedimiento a seguir es extraer de la misma cualquier contraseña almacenada. Para ello se pueden utilizar herramientas como Mimikatz. Estas credenciales pueden ser útiles para realizar movimientos laterales a través del dominio, comprometiendo máquinas en las que los usuarios que se van recolectando sean administradores locales.

Conclusión

Acabamos de ver solo algunas de las técnicas mas utilizadas durante una auditoría, pero los atacantes descubren técnicas nuevas todos los días, cada cual más innovadora. Por ello os invitamos a que investiguéis y descubráis vuestros propios caminos hacia controladores de dominio.

Ignacio Sánchez, Analista de Ciberseguridad en Zerolynx.

Riesgos asociados a la suplantación de organizaciones

El aumento del uso de Internet ha generado consecuencias en la privacidad e intimidad de las personas. Gran cantidad de información personal puede encontrarse indexada en los principales buscadores o visible en perfiles de redes sociales. Además de toda aquella información personal presente en filtraciones de datos como las sufridas a lo largo del tiempo por grandes servicios como Facebook, Twitter, LinkedIn o Badoo entre muchos otros. 

En ocasiones, desde el departamento de Ciberinteligencia necesitamos transmitir a nuestros clientes la repercusión que estos hechos pueden tener sobre sus compañías y empleados, ya que la información expuesta o filtrada es utilizada por los atacantes para suplantar la identidad de personas con capacidad de decisión o con los medios para realizar pagos. La identificación de este tipo de riesgos sirve a nuestros clientes para prevenir o mitigar posibles ataques.

Algunas de las técnicas de suplantación de identidad más utilizadas son:

• Suplantación de dominio o dominio similar (typosquatting): variación del dominio que se pretende suplantar usando caracteres muy similares, agregando o eliminando otros de modo que pase inadvertido para la víctima. Otra variante es el uso de un TLD distinto, pero con el mismo nombre de dominio. Ejemplo: elcorteingles.es o vodafone.org.

Dicha suplantación se puede evitar mediante actividades de vigilancia digital, que permiten identificar estas situaciones en el momento de creación de los dominios.

• Suplantación de páginas web: uso del diseño, logo, imagen de marca de una web lícita para crear una falsa con la que robar credenciales, información de las tarjetas de crédito o realizar fraude vendiendo artículos sin luego enviarlos. 

Este tipo de técnicas son evitables, haciendo uso de herramientas que permitan identificar el clonado de una web.

• Adquisición de cuenta: robo de cuentas de correo debido a la filtración de sus contraseñas. El uso de las contraseñas en diversos servicios (reutilización) así como el uso de la cuenta de correo corporativo fuera del ámbito laboral facilita su robo. Este robo puede conllevar estafas económicas a gran escala utilizando como medio la cuenta robada.

La exfiltración de contraseñas se puede identificar, e incluso mitigar, haciendo uso de técnicas de vigilancia de estas en diferentes sitios donde se publican este tipo de leaks.

• Suplantación de correo electrónico y SMISHING: mediante el envío de malware o falsas notificaciones en las que es necesario introducir la contraseña a la cuenta de correo electrónico se genera el robo de las credenciales de esta para posteriormente acceder y realizar la suplantación. También se puede encontrar en este tipo de suplantación el envío de SMS fraudulentos que engañan al usuario para acceder a una web suplantada y robar información bancaria.

Con el fin de evitar la suplantación del correo electrónico, es altamente recomendable implantar técnicas de verificación, así como técnicas de vigilancia. El SMISHING se puede reducir con algunas de las medidas indicadas anteriormente, aunque nada de esto es realmente efectivo sin una concienciación en materia de ciberseguridad.

• Suplantación como servicio: se ha identificado la venta de conjuntos de contraseñas, números de teléfono, cuentas de correo de recuperación asociadas e información que puede utilizarse para saltar la autentificación multifactor de cuentas concretas, asegurando al atacante el acceso a estas y su robo.

Este tipo de técnicas son muy difíciles de mitigar, aunque es posible reducir este riesgo incluyendo listas negras en nuestro sistema de navegación.

Adicionalmente, es altamente recomendable establecer políticas de seguridad que promuevan el uso adecuado del correo electrónico corporativo (exclusivamente en el ámbito laboral), políticas de seguridad adecuadas que  eviten la reutilización de contraseñas y promuevan su cambio periódico así como  crear procedimientos  para reportar correos electrónicos recibidos de dudosa fiabilidad.

Desde Zerolynx defendemos el establecimiento de medidas de seguridad para evitar estos ataques, pero consideramos que el hecho de, llevar a cabo formaciones y la concienciación de los empleados y clientes puede mejorar la prevención, así como colaborar a que el impacto de estos ataques sea mínimo. Porque, a pesar de que no es posible exigir a los empleados el conocimiento en profundidad de las técnicas mencionadas, sí lo es el ayudarles a adquirir las herramientas necesarias para identificarlos y así evitar la materialización de estas amenazas.

Noelia B., Analista de Inteligencia.

Cómo evadir AMSI haciendo uso de DLL Hijacking

¡Muy buenas a todos! Hoy venimos con una última entrega (de momento) sobre el mundo del AMSI. En esta ocasión, vamos a descubrir cómo podríamos evadir el AMSI haciendo uso de una técnica llamada DLL hijacking. 

Cuando un binario está compilado con enlaces dinámicos, el sistema operativo buscará la DLL específica para cubrir una funcionalidad en tiempo de ejecución. En muchas ocasiones, el enlace a la DLL no se define con el path completo, sino únicamente con el nombre. 

Esto da pie a que Windows, mediante su modo de búsqueda, interprete cual es la DLL que el binario pretendía cargar en ese enlace. El orden de búsqueda es el siguiente:

• El directorio donde se encuentra la aplicación que se está ejecutando

• C:\Windows\System32

• C:\Windows\System

• C:\Windows

• El directorio donde se encuentra

• Todo lo que haya en la variable de entorno %PATH%

Por lo tanto, por culpa de este funcionamiento de Windows, cualquier persona con acceso de escritura en algún lugar del disco podría evadir AMSI. ¿Por qué? Porque si podemos copiar la PowerShell para tenerla en un lugar en el que tengamos permisos de escritura, y creamos un archivo llamado amsi.dll, en el momento que se abra esa PowerShell, cargará esa DLL por tema de preferencia. 

En el siguiente ejemplo podemos ver cómo, teniendo la PowerShell en un sitio como el escritorio, podemos hacer que cargue amsi.dll de ese mismo sitio.

El único requisito para utilizar esta técnica es tener una DLL (creada en C/C++) que tenga las funciones definidas de la misma manera que la DLL real. Es decir, no es necesario que la funcionalidad sea la misma, pero de cara a la PowerShell, la llamada a la función se tiene que dar de la misma forma: con el mismo nombre y los mismos argumentos.

PowerShell de 64 bits se puede encontrar en el siguiente directorio:

• C:\Windows\System32\WindowsPowerShell\v1.0

Mientras que PowerShell de 32 bits se puede encontrar en el siguiente directorio:

• C:\Windows\SysWOW64\WindowsPowerShell\v1.0

Una forma sencilla de realizar esta tarea es mediante el parcheo de la DLL original. En otras palabras, podríamos tomar amsi.dll y cambiar las instrucciones pertinentes para que se pierda la funcionalidad original, y no devuelva nunca que hay malware.

Anteriormente en el post Funciones AMSI  explicamos para qué servía cada función de AMSI.

Sabemos que AmsiScanBuffer devuelve un HRESULT, que es un código que representa si la función se ha ejecutado de forma exitosa o no. Si cambiamos AmsiScanBuffer para que siempre devuelva 0x80070057, AMSI dejará de funcionar y lo habremos evadido.

La siguiente imagen es una parte de la función AmsiScanBuffer. 

El primer if hace una serie de validaciones básicas y si las cumple, significa que los argumentos se han proporcionado de forma inválida y no se podrá realizar el escaneo, por lo que setea uVar2 a 0x80070057. 

Pero ¿Qué pasaría si dentro del else también se setea uVar2 a 0x80070057? La respuesta es que AMSI dejaría de funcionar correctamente, porque, a pesar de que AMSI se comunique con Windows Defender para enviar el buffer, si la función devuelve INVALIDARG, el comando se ejecutará de forma normal.

En ensamblador, para devolver un valor en un return, debemos cargar el contenido en un registro de retorno, por lo tanto, para devolver INVALIDARG, podríamos añadir lo siguiente:

• MOV        EAX,0x80070057

Si utilizas ghidra, seleccionando en la parte del decompile, la parte que nos interesa, podemos ver dónde se encuentra su ensamblador correspondiente. Para parchear esta función y que siempre devuelva INVALIDARG, podemos cambiar el último call.

Por lo tanto, la función quedaría como la siguiente:

Por último, quedaría exportar la DLL como PE y ya estaría.

Y con esto nos despedimos de AMSI por el momento. Si os habéis quedado con ganas de más, ¡escribidnos!

Justo Martín, Security Analyst at Zerolynx.

Ligolo-ng, pivoting avanzado de la mano de Go

Muy buenas, durante esta entrega hablaremos de una herramienta que facilita mucho la temática de los túneles. ¡No os perdáis en él! .

Ligolo-ng es una herramienta simple, ligera y rápida que permite a los pentester establecer túneles desde una conexión TCP/TLS inversa utilizando una interfaz virtual “tun” (sin necesidad de SOCKS). A diferencia de Chisel u otras herramientas, con Ligolo-ng no necesitamos hacer uso de SOCKS, si no que mediante interfaces virtuales levantaremos un túnel (al más puro estilo VPN).

Gracias a esto, podremos correr herramientas como Nmap sin tener que usar proxychains, por lo que las tareas de pivoting se vuelven más sencillas y rápidas, ya que una de las ventajas de Ligolo-ng es una significativa mejora en el rendimiento de las conexiones frente al uso de SOCKS. Tendremos conexiones más rápidas y estables. 

A continuación, os detallamos cómo usar esta herramienta correctamente:

Get-ready

Agent – Máquina víctima

Proxy – Máquina atacante

En primer lugar, descargaremos en nuestro directorio de trabajo los binarios que vamos a necesitar. Os dejamos el repositorio oficial de Ligolo-ng:  .

 
Tenemos la posibilidad de descargar el código fuente o el binario ya compilado, por comodidad en este caso, descargaremos tanto el binario del agente como el del proxy en función de los sistemas operativos que vayamos a emplear (en nuestro caso Linux):

En el caso de optar por descargar el código fuente (GO), usaremos los siguientes comandos para compilarlo:

Linux:

Windows: 

Configurar Ligolo-ng:

Ligolo-ng se basa en una interfaz virtual a través de la cual se establecerá un túnel entre la máquina víctima y la atacante, es por ello por lo que será necesario levantar primeramente la interfaz “tun” sobre la que se apoya Ligolo-ng:

Consultamos las opciones que nos ofrece el proxy:

En donde se nos presenta las distintas opciones de certificados TLS que disponemos:

• Autocert: El proxy automáticamente solicitará un certificado usando Lets encrypt. Esta opción requiere accesibilidad al puerto 80. 

• Certfile / -keyfile: Si queremos usar nuestros propios certificados.

• Selfcert: Generara automáticamente un certificado autofirmado. Esta opción es la menos recomendada en términos de seguridad, pero si estamos trabajando en un laboratorio aislado o en un entorno de pruebas, es una opción válida.

• Tun <nombre interfaz>: En el caso de haber escogido otro nombre para la interfaz.

• Laddr <IP:port>:  La interfaz de escucha por defecto 0.0.0.0:11601, para definir otra interfaz lo indicaremos mediante este comando.

Lanzamos el proxy con la configuración por defecto, valiéndonos de certificados autofirmados para el cifrado de la conexión

En la máquina atacante:

En la máquina víctima:

Ya tendríamos la sesión creada:

Ahora seleccionamos en el proxy (maquina atacante) la sesión que acabamos de crear:

Siempre tendremos que indicar sobre que sesión queremos trabajar. Una vez levantada la sesión podemos llevar a cabo diferentes acciones:

Desde el propio proxy podremos consultar las interfaces de red que hay levantadas en el agente (víctima) mediante el comando ifconfig:

Para poder llegar a esta nueva red (192.168.1.0/24) tendremos que indicar a nuestra máquina atacante que redirija el tráfico con destino 192.168.1.0/24 a través del túnel Ligolo que acabamos de crear. Para ello añadimos la siguiente ruta estática a la tabla de routing de la máquina atacante: 

Y por último iniciamos el túnel: 

Os muestro en el siguiente diagrama lo realizado hasta aquí:

Y ahora pasamos a comprobar que llegamos a la nueva subred (192.168.1.0/24) a través de la interfaz eth1 de la víctima:

Enlace puente

Los agentes permiten escuchar en puertos prestablecidos, de tal forma que todo el tráfico entrante hacia esos puertos sea redirigido directamente a la máquina atacante. 

Desde el proxy (atacante) y sobre la misma sesión que teníamos establecida, levantamos un listener en el agente (víctima): 

Cualquier tráfico entrante en la máquina víctima con destino el puerto 1234, será redirigido a la máquina atacante al puerto 4321. Esto es muy útil cuando tenemos que ejecutar un reverse payload hacia la máquina atacante o descargar ficheros en la víctima desde un servidor HTTP alojado en la máquina atacante. 

Avanzamos quedando así, un ejemplo de una reverse shell seria este:

Podemos gestionar cada uno de los listener levantados mediante listener_list y listener_stop/start.

Pivotando entre varias máquinas

Si queremos pivotar entre varias máquinas, podemos crear tantas sesiones como queramos apoyándonos de los listener, de tal forma que en cada máquina haya un listener escuchado en un puerto establecido que nos redirija a la máquina anterior de salto y así sucesivamente, hasta llegar al puerto 11601 (por defecto) de la máquina atacante en donde proxy-ligolo está escuchando peticiones de nuevos agentes (víctimas).

Ejemplo: desde la red 192.168.1.0/24 (donde se encuentra la máquina de salto) levantamos el agente (víctima 2) hacia el listener de la máquina intermedia (víctima 1) que nos redirigirá directamente al proxy-ligolo (atacante).

1. Configuramos el listener en la máquina de salto (192.168.1.147) desde la máquina atacante:

2. En la nueva máquina víctima lanzamos el agente (víctima 2) hacia el listener de la máquina de salto intermedia (192.168.1.147:11601):

3. La conexión será redirigida al proxy-ligolo. Se establece una nueva sesión que permitirá a acceder a nuevas subredes:

Concluyendo con esta práctica hemos realizado este ejercicio:

¡Hasta aquí hemos llegado! ¡Esperamos que haya sido de interés y utilidad para todos!

¡¡¡A volar, perdón, a pivotar!!!! 

Alejandro Auñón, Offensive Security Senior Analyst at Zerolynx.

Técnicas de ofuscación para AMSI

Muy buenas a todos. En este post vamos a hablar de como los antivirus (AV) detectan scripts maliciosos en tiempo de ejecución y las medidas para ofuscar los scripts en Powershell y que la ejecución de este no sea bloqueada por el AV.

Como ya se ha visto en artículos anteriores , AMSI es una API que conecta el AV con Powershell para identificar si un script puede ser o no malicioso en tiempo de ejecución y en caso de serlo, bloquearlo. Pero la pregunta que hay que hacerse es la siguiente: ¿Cómo los antivirus detectan si el script es malicioso? La respuesta a esta pregunta son las firmas de los AV.

Firmas de antivirus en Powershell 

Las clásicas firmas de virus son una secuencia continua de bytes comunes en cierta muestra de malware, es decir, si esa secuencia continua de bytes está incluida en un archivo, ese archivo es malware.

Siguiendo este concepto, las firmas de antivirus en PowerShell son patrones únicos que representan cadenas características en los scripts escritos en este lenguaje. Cuando un script es escrito en la consola de Powershell, al ejecutarlo, AMSI envía el script al antivirus y este detecta si la firma de alguna de las cadenas incluidas en el script puede ser susceptible de ser maliciosa o si toda la cadena lo es y si estos casos se cumplen, la ejecución del script es bloqueada por el antivirus.

Como ejemplo a esto, si intentásemos usar mimikatz en Powershell, como la cadena de mimikatz es bien conocida por ser un script que podría ser malicioso en manos equivocadas, si se intenta invocar, aunque el archivo no esté en el path, antes de saltar el error de que el script no se encuentra, saltará el error de que el script contiene uno o más elementos malintencionados y que ha sido bloqueado por el antivirus.

Lo mismo ocurre si escribimos la cadena amsiInitFailed que es usada en algunos bypass de AMSI, el antivirus lo va a detectar y bloquear porque hay una firma en el antivirus de esta cadena en concreto:

Esto, por tanto, supone un impedimento a la hora de ejecutar scripts maliciosos en primera instancia, por eso lo que se suele hacer es ofuscar las cadenas del script de manera que estas no tengan firma en el antivirus y por tanto lo hace indetectable al AV.

Técnicas de ofuscación en Powershell

Para evadir la detección del AV, se utilizan técnicas de ofuscación para modificar el código fuente de un script de manera que sea más difícil de detectar y analizar. Este conjunto de técnicas son la siguientes:

Codificación y decodificación en Base64: 

Esta técnica consiste en codificar el contenido del script en Base64 y decodificarlo en tiempo de ejecución, es decir, se codifica en Base64 la cadena que hace de trigger para el AV y se decodifica en dentro del script. 

Como ya hemos visto, la cadena amsiInitFailed es detectada por el AV, pero si la pasamos a base64 la cadena pasa a ser YW1zaUluaXRGYWlsZWQ= y al volver a convertirla en ASCII, ya no la detecta, y se imprimirá por terminal.

Concatenación y escape de caracteres

El operador para concatenar en Powershell, como en otros muchos lenguajes, es el carácter +. Una manera de ofuscar el código de un script es dividiendo las cadenas que lo incluyen y que tienen una firma en el AV, de manera que a la hora de escribir el script y concatenarlas en tiempo de ejecución, el antivirus no detecta la ejecución que sí detectaría sin esta concatenación porque la firma de la cadena dividida no está incluida en el mismo.

Otra manera de ofuscar es incluyendo en las cadenas el carácter de escape que en Powershell es el carácter `. Este tipo de carácter se suele incluir dentro de una cadena de caracteres.

Reordenación de cadenas con formateo

Powershell también incluye el formateo de cadenas mediante el comando -f. Con esto podemos escribir una cadena que normalmente detectaría el AV por tener una firma y reordenarla en tiempo de ejecución.

Reflejo de métodos .NET

En internet existen numerosos scripts que hacen bypass a AMSI. Uno de los más famosos es el de Matt Graeber que usa el método de reflejo.

El reflejo de métodos .NET (reflection en inglés), consiste en inspeccionar, invocar y acceder a datos de tipos .NET que incluyen tanto parámetros públicos como privados. Por defecto, PowerShell proporciona acceso a las propiedades y métodos de acceso público, pero utilizando las API de reflexión, puede acceder a los parámetros privados.

El método es el siguiente:

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Sin embargo, ya es tan usado que hay que aplicar alguna de las técnicas descritas arriba y la siguiente técnica que se va a explicar para que el antivirus no lo detecte.

División de scripts en distintas líneas

Existen muchos scripts de una sola línea (one-liner en inglés) que usan métodos como reflection junto con concatenación de cadenas, etc. Aunque, el uso de estos scripts está tan extendido que ya hay firmas para este tipo de scripts. 

No obstante, una manera simple de evitar que AMSI se queje, es dividiendo el código en distintas líneas o si es un código de una misma línea como el de Matt Graeber, dividiéndolo en distintas variables. De esta manera, aunque a primera vista pueda parecer absurdo, como ya hemos explicado cómo funcionan las firmas de los antivirus en Powershell y AMSI, tiene sentido que sea posible esta manera de ofuscar el script.

Veámoslo en un ejemplo.

En la imagen podemos ver que el primero es el script original y al segundo se le ha aplicado concatenación de cadenas de caracteres para intentar evitar al AV. Sin embargo, es tan usado que algo así no es válido.

Pero si dividimos este script en distintas líneas, el tema cambia como os voy a demostrar en la siguiente imagen:

Como se puede ver, al dividirlo en distintas variables más el uso de la concatenación de cadenas de caracteres es posible evitar que AMSI detecte este script y se efectúa correctamente el bypass.

Hay que aclarar que normalmente estas técnicas se usan a la vez en un mismo script ya que todas las explicadas en este post son más eficaces si se realizan en conjunto que por separado.

Esto es todo por ahora. En los siguientes artículos de AMSI se verán distintas técnicas de cómo realizar estas evasiones (cuyos scripts evidentemente estarán ofuscados con alguna de las técnicas aquí mencionadas).

¡Hasta el próximo post!

 Justo Martín, Security Analyst at Zerolynx.