Windows Authentication, Relay, and Lateral Movement

BLUF

The most important distinction is the material being abused:

• Pass-the-hash (PtH) reuses an NT hash as proof of knowledge of a password.
• NTLM relay forwards a live NTLM challenge-response exchange; it does not recover or reuse the NT hash.
• Pass-the-ticket (PtT) reuses an existing Kerberos ticket.
• Token impersonation reuses or duplicates a Windows access token on a host.
• DPAPI abuse targets secrets protected for a user, machine, or domain recovery context.

These techniques have different prerequisites, targets, telemetry, and mitigations. A captured NetNTLMv2 response is not an NT hash and cannot be treated as a generic PtH credential.

1. Identity-material map

flowchart LR
    P[Password] --> H[NT hash]
    H --> N[NTLM challenge-response]
    P --> K[Kerberos long-term key]
    K --> TGT[Ticket-granting ticket]
    TGT --> ST[Service ticket]

    H --> PTH[Pass-the-hash]
    N --> RELAY[NTLM relay]
    TGT --> PTT[Pass-the-ticket]
    ST --> PTT

    LOGON[Successful Windows logon] --> TOKEN[Access token]
    TOKEN --> IMP[Token impersonation]

    USER[User or machine context] --> DPAPI[DPAPI master-key chain]
    DPAPI --> SECRET[Protected application secret]

    style PTH fill:#5b2333,color:#fff
    style RELAY fill:#5b2333,color:#fff
    style PTT fill:#5b2333,color:#fff
    style IMP fill:#5b2333,color:#fff

Artifact taxonomy

2. NTLM authentication

NTLM is a Windows challenge-response authentication package. In a domain workflow, the client proves access to password-derived credential material without sending the plaintext password. The server and domain controller validate the exchange. Applications normally use Negotiate, which selects Kerberos when possible and falls back to NTLM when Kerberos cannot be used.

Common reasons for NTLM fallback include connecting by IP address, missing or incorrect service principal names, workgroup/local-account use, legacy applications, and incompatible name or trust conditions. Do not assume every Negotiate logon used Kerberos; record the negotiated package.

NT hash versus NetNTLM

Use precise language:

• NT hash / NTOWF: password-derived credential material stored or validated by Windows authentication components.
• NTLMv2 response / NetNTLMv2: the output of a particular challenge-response exchange.

Offline guessing of a captured response attempts to recover the password. PtH uses an NT hash directly. Relay forwards a live exchange. Those are three different operations.

3. Pass-the-hash

PtH is alternate-authentication-material abuse: an actor authenticates to an NTLM-capable service using an NT hash instead of the plaintext password. It succeeds only where the protocol, client implementation, account type, target policy, and authorization allow it.

Key boundaries:

• Possessing a hash does not create authorization the account does not already have.
• Local administrator password reuse turns one local hash into a lateral-movement path; Windows LAPS reduces this risk.
• Credential Guard reduces exposure of some reusable secrets but does not protect the SAM or AD database itself.
• NTLM restriction, protocol signing, privileged-access tiers, unique local credentials, and limiting administrative logon paths reduce PtH exposure.

RDP PtH and Restricted Admin

RDP normally uses CredSSP/NLA and credential delegation. Restricted Admin mode changes the trust model: reusable credentials are not sent to or stored on the remote host, the connecting identity must be an administrator on the target, and outbound access from the session generally uses the remote host's identity rather than the user's identity.

This defensive feature historically also enabled RDP authentication with equivalent NTLM material. Therefore:

• Restricted Admin reduces credential exposure on a possibly compromised target.
• It is not the same as Remote Credential Guard.
• It does not make a previously stolen NT hash harmless.
• Current client policy may prefer or enforce Remote Credential Guard and ignore an explicit /restrictedadmin choice.

Microsoft's client exposes mstsc /restrictedadmin. FreeRDP exposes /pth:<password-hash> and /restricted-admin options, but success is version-, build-, platform-, NLA/CredSSP-, and server-policy-dependent. Document the exact FreeRDP version and test only with a synthetic lab account; do not publish a hash-bearing command transcript.

4. NTLM relay

Relay is a live authentication-forwarding problem, not hash reuse.

sequenceDiagram
    participant C as Client
    participant R as Unintended endpoint / relay
    participant S as Target service
    participant D as Domain controller

    C->>R: Attempts NTLM authentication
    R->>S: Forwards negotiate message
    S-->>R: Target challenge
    R-->>C: Forwards target challenge
    C->>R: Challenge response
    R->>S: Forwards response
    S->>D: Validate identity and response
    D-->>S: Authentication result
    alt Signing, channel binding, service binding, or policy blocks relay
        S-->>R: Reject
    else Relayed identity is accepted and authorized
        S-->>R: Authenticated session with that identity's rights
    end

Required conditions

A useful relay threat model asks whether all of these are true:

1. A client can be induced or misdirected into authenticating to an unintended endpoint.
2. The client negotiates NTLM rather than Kerberos.
3. A target service accepts the forwarded exchange.
4. Signing, channel binding, service binding, MIC requirements, and Extended Protection do not reject it.
5. The relayed identity has meaningful authorization on the target.
6. Network paths and protocol details are compatible.

“NTLM is enabled” is therefore not enough to prove relayability.

Responder's role

Responder is a rogue name-resolution and authentication-service framework commonly used in labs to demonstrate LLMNR, NBT-NS, mDNS, DNS, WPAD, and authentication exposure. It may observe challenge-response material, but it does not dump the NT hash from the endpoint.

Defensive validation should focus on whether:

• untrusted hosts can answer local name-resolution requests;
• clients fall back to multicast/broadcast name resolution;
• WPAD or proxy discovery can be influenced;
• endpoint and network telemetry identify the unexpected responder;
• controls prevent the resulting authentication from being useful.

Prefer fixing name resolution, disabling unnecessary LLMNR/NBT-NS, constraining WPAD, reducing NTLM, and enforcing service protections rather than merely detecting a particular tool name.

MSSQL through ntlmrelayx

Current Impacket releases include MSSQL relay support in ntlmrelayx; this is a Windows Authentication path over SQL Server's TDS stack, not replay of a SQL login password. A successful authentication still has only the database permissions of the relayed Windows identity.

Do not equate authentication with operating-system command execution. Database roles, server permissions, disabled features, service-account context, and endpoint controls determine impact.

SQL Server's primary relay defense is Extended Protection, using service binding and TLS channel binding. Effective enforcement requires compatible client drivers, TLS, a correct SPN, Windows Authentication, and SQL Server Extended Protection configured—preferably Required after compatibility testing. As of this review, SQL Server does not enable Extended Protection by default.

5. Kerberos and pass-the-ticket

Kerberos uses a Key Distribution Center (KDC):

sequenceDiagram
    participant U as User or computer
    participant AS as KDC Authentication Service
    participant TGS as KDC Ticket-Granting Service
    participant S as Application service

    U->>AS: AS-REQ with identity and pre-authentication
    AS-->>U: AS-REP with TGT and session key
    U->>TGS: TGS-REQ with TGT and target SPN
    TGS-->>U: TGS-REP with service ticket
    U->>S: AP-REQ with service ticket
    S-->>U: Service access; mutual authentication when used

Pass-the-ticket means presenting an existing TGT or service ticket without knowing the account password. A TGT can request service tickets while valid and permitted; a service ticket is normally limited to its service principal. Ticket flags, PAC contents, encryption type, lifetime, realm, logon session, and service name all matter.

klist, .kirbi, and ccache

• Windows klist displays and manages tickets in Windows logon-session caches.
• MIT Kerberos and many Unix tools use credential caches, often called ccache.
• KRB-CRED files are commonly called .kirbi in security tooling.
• Impacket's ticketConverter.py converts between KRB-CRED/.kirbi and ccache formats.

klist2ccache is not standard Windows terminology and is not a canonical current Impacket command. If a course or script uses that name, record its repository and version. Conversion changes representation; it does not grant new authorization or extend the ticket lifetime.

Detection should correlate ticket events with the source host, logon session, account, SPN, service destination, encryption type, timing, lifetime, and expected administrative path. Avoid single-event “PtT signatures.”

6. DPAPI

The Data Protection API lets applications protect data under a user or machine context. Applications may add optional entropy, and domains maintain highly sensitive DPAPI backup keys so domain users can recover protected data after certain password-reset scenarios.

Important distinctions:

• A DPAPI blob is not automatically portable between users or machines.
• The user's password-derived material may participate in protecting DPAPI master keys, but the full recovery chain and context matter.
• Machine-scope protection changes who can decrypt on that computer.
• Domain DPAPI backup keys are extremely sensitive; Microsoft states that compromise can expose DPAPI data for domain users and does not provide a supported rotation mechanism.
• Browser, RDP, Wi-Fi, application, and vault secrets may add their own protection layers on top of DPAPI.

Protect profile directories, LSASS, domain controllers, backup repositories, and the identities allowed to perform recovery. Treat a DPAPI domain backup-key compromise as a domain-compromise incident requiring expert response; assess forest impact separately when trusts or shared administration expand the blast radius.

7. wbadmin, SAM/SYSTEM, and backup exposure

wbadmin is a legitimate Windows backup utility. The security issue is not the binary's presence; it is whether a principal can create, read, mount, export, or restore security-sensitive backups.

System-state or critical-volume backups can contain registry data and, on domain controllers, Active Directory data. The SAM hive contains local-account credential data whose protection depends partly on material associated with the SYSTEM hive. Backups can therefore bypass controls that protect live files.

For a clean defensive validation:

1. Review Backup Operators, backup-service identities, scheduled tasks, and repository ACLs.
2. Confirm backups are encrypted, access-logged, isolated from ordinary administrators, and protected against deletion.
3. Test restore authorization with synthetic data; do not extract real credential material.
4. Alert on unexpected wbadmin/VSS activity, new backup destinations, hive access, volume mounting, and access from non-backup hosts.
5. Treat copied SAM/SYSTEM, NTDS, DPAPI backup keys, and unprotected system-state media as credential-bearing incident artifacts.

“Clean” or “discreet” collection is not a legitimate design objective. The useful objective is controlled, attributable validation with minimal data handling.

8. Windows access tokens and T1134.001

After logon, Windows uses access tokens to represent a process or thread's security context. Tokens carry identity, groups, privileges, integrity information, restrictions, and other authorization data.

MITRE ATT&CK T1134.001, Token Impersonation/Theft, covers duplicating or impersonating an existing token. It is distinct from:

• PtH, which abuses password-derived NTLM material;
• PtT, which reuses Kerberos tickets;
• T1134.002, which uses a token to create a process; and
• T1134.003, which creates and impersonates a new token from supplied credentials.

Detection is behavioral: correlate unusual privilege changes, cross-user process access, sensitive-handle access, and token APIs such as DuplicateTokenEx, ImpersonateLoggedOnUser, and SetThreadToken with process ancestry, integrity level, and logon-session context.

9. Living off the land and interactive access

“Living off the land” (LOTL) describes using built-in or trusted utilities. It is not itself an authentication method and does not make activity invisible. Native tools often produce strong process, script, service, authentication, and network telemetry.

mstsc /shadow

RDP shadowing views or controls an existing session; it is not a separate logon technique or a software vulnerability. Microsoft documents /shadow:<sessionID>, /control, and /noConsentPrompt, but successful use depends on session-control permissions and policy. No-consent shadowing is a high-risk administrative configuration.

Defensive rules:

• require user consent except for narrowly approved support cases;
• restrict session-control rights;
• notify users and record the operator, source, target, session ID, and ticket number;
• investigate shadowing from unexpected hosts or outside support windows.

“RDP over WinRM/SMB”

RDP, WinRM, and SMB are separate service surfaces. One may be used to configure or reach another, but authentication and authorization do not magically transfer between them. Document the chain explicitly:

flowchart LR
    O[Operator workstation] -->|WinRM management| J[Managed host]
    O -->|SMB or RPC administration| J
    O -->|RDP interactive session| J
    J -->|Approved gateway or proxy path| T[Internal target]

    P1[Identity authorized?] -. check .-> J
    P2[Protocol protected?] -. check .-> J
    P3[Route approved and logged?] -. check .-> T

Do not collapse this into “RDP over SMB.” Record each transport, listener, authentication package, delegated credential behavior, firewall change, and audit source.

10. DLL side-loading and hijacking

These are related execution-flow abuses, not authentication techniques:

• DLL search-order hijacking places an unintended DLL in a location searched before the legitimate library.
• DLL side-loading pairs a legitimate executable with an unintended DLL that it will load.
• Phantom DLL hijacking supplies a DLL that an application references but that is normally absent.
• DLL substitution replaces an existing library.

The security boundary is writable location plus privileged or trusted loading behavior. A signed executable does not make every DLL it loads trustworthy.

Defenses include fully qualified library paths, safe loading APIs, Safe DLL Search Mode, removing write access from program directories, application control that covers DLLs, and monitoring unexpected image loads from user-writable or nonstandard paths. Map this family to MITRE ATT&CK T1574.001.

11. Proxying and pivoting

A proxy or tunnel forwards traffic through an intermediary. It is not NTLM relay. Proxying changes network reachability and attribution; the inner protocol still performs its own authentication and authorization.

Document:

• operator, ingress, intermediary, egress, and final destination;
• SOCKS, HTTP CONNECT, port-forward, gateway, or application-proxy type;
• DNS-resolution location and leak risk;
• which protocols tolerate the proxy;
• identity used at each hop;
• encryption, logging, lifetime, and teardown owner.

For authorized labs, bind listeners to loopback where possible, allow-list destinations, set an expiry, and preserve connection logs. Avoid broad subnet routing when a single host/port proves the control gap.

12. Control and detection map

flowchart TD
    A[Unexpected authentication or remote access] --> B{What material or path?}
    B -->|NT hash| C[PtH hypothesis]
    B -->|Live NTLM exchange| D[Relay hypothesis]
    B -->|Kerberos ticket| E[PtT hypothesis]
    B -->|Local access token| F[Token impersonation hypothesis]
    B -->|Remote route| G[Proxy or service-use hypothesis]
    B -->|Unexpected DLL load| H[Execution-flow hijack hypothesis]

    C --> I[Check account reuse, LAPS, NTLM policy, source host]
    D --> J[Check signing, CBT, EPA, name resolution, target authorization]
    E --> K[Check TGT/TGS timing, SPN, realm, lifetime, logon session]
    F --> L[Check token APIs, privileges, process and handle lineage]
    G --> M[Check route, listener, management allow-list, DNS and flow logs]
    H --> N[Check path writability, signature context, loader telemetry]

    I --> Z[Correlate endpoint, DC, network, RDP, WinRM, SMB, and SQL evidence]
    J --> Z
    K --> Z
    L --> Z
    M --> Z
    N --> Z

Priority hardening

1. Inventory NTLM use and fix Kerberos/SPN/name-resolution failures before restricting it.
2. Require SMB signing; assess current Windows defaults and legacy exceptions explicitly.
3. Enforce LDAP signing and channel binding.
4. Enable SQL Server TLS and Extended Protection after client compatibility testing.
5. Deploy Windows LAPS and eliminate shared local-administrator passwords.
6. Use privileged-access workstations and constrain where administrative identities may log on.
7. Use Credential Guard, Restricted Admin, or Remote Credential Guard according to the administrative scenario.
8. Protect backup operators, system-state media, DPAPI backup keys, and backup repositories as credential-bearing assets.
9. Restrict RDP shadowing and require consent by default.
10. Apply DLL-safe-loading guidance and DLL-aware application control.
11. Allow only documented management and proxy paths; expire temporary routes.

13. Safe validation worksheet

Sources

Microsoft

• Microsoft NTLM
• NTLM v2 Authentication — MS-NLMP
• Microsoft Kerberos
• Kerberos Network Authentication Service — MS-KILE
• klist
• Remote Credential Guard and Restricted Admin comparison
• mstsc
• shadow
• SMB security hardening
• SMB signing overview
• LDAP signing and channel binding
• Extended Protection for SQL Server
• DPAPI backup keys on Active Directory domain controllers
• Dynamic-link library security

Framework and tool owners

• MITRE ATT&CK T1134.001 — Token Impersonation/Theft
• MITRE ATT&CK T1550.002 — Pass the Hash
• MITRE ATT&CK T1550.003 — Pass the Ticket
• MITRE ATT&CK T1574.001 — DLL
• MITRE ATT&CK T1090 — Proxy
• Impacket ntlmrelayx
• Impacket ticketConverter.py
• FreeRDP client options
• Responder

Review record

• Primary-source check: 2026-09-09.
• Independent agentctl challenge pass: 2026-09-09; used for contradiction discovery and source discovery, not as evidence.
• Mermaid semantic review: 5 diagrams checked against surrounding prose.