Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state
Use the normal client for the observed service
# Use the normal client for the observed service
ssh -o PreferredAuthentications=password -p PORT USER@TARGET
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares
evil-winrm -i TARGET -u USER -p 'PASSWORD'
xfreerdp /v:TARGET /u:'DOMAIN\USER' /p:'PASSWORD' /cert:ignore
# Local Windows account
nxc smb TARGET --local-auth -u USER -p 'PASSWORD' --shares
# Variant — known user, targeted password dictionary
hydra -l USER -P WORDLIST -s PORT -t 4 -f ssh://TARGET
hydra -l USER -P WORDLIST -t 1 -f rdp://TARGET
# Variant — one password across an authorized user list
hydra -L USERS -p 'PASSWORD' -s PORT -t 1 rdp://TARGET
nxc smb TARGET -d DOMAIN -u USERS -p 'PASSWORD' --continue-on-success
# Capture a correct request and stable failure marker with Burp
hydra -l USER -P WORDLIST TARGET http-post-form \
'/LOGIN_PATH:username=^USER^&password=^PASS^:F=STABLE_FAILURE_TEXT'
Decisive output: the destination service accepts the intended identity. Share, session or action access is a separate authorization result.
Use only on an assigned target after checking lockout and rate controls. Confirm every reported success with the normal client.
Dynamic CSRF tokens, cookies, redirects, throttling and uniform responses require manual handling or a different approach. A weak failure marker creates false positives.
RunasCs — test a known password from an existing Windows shell
Use a reviewed, compatible build on the current Windows host with a known plaintext password. This creates a new local process/logon context; it is not remote execution and does not turn an NT hash into a password.
REM RunasCs — test a known password from an existing Windows shell
REM Domain account: verify the new process token
RunasCs.exe USER PASSWORD "cmd /c whoami /all" -d DOMAIN
REM Local account: omit the domain switch for the current host's account
RunasCs.exe USER PASSWORD "cmd /c whoami /all"
REM Network-only credentials: local identity stays unchanged
RunasCs.exe USER PASSWORD "cmd /c dir \\TARGET\SHARE" -d DOMAIN -l 9
Read: in the first two forms, whoami identifies the created process; inspect its groups/integrity before claiming escalation. With logon type 9, local whoami is not a credential test: use the remote operation's result. Logon failure → check account scope, password and permitted logon type. An accepted logon with access denied → inspect authorization on that resource.
RunasCs — test a known password from an existing Windows shell
Read: in the first two forms, whoami identifies the created process; inspect its groups/integrity before claiming escalation. With logon type 9, local whoami is not a credential test: use the remote operation's result. Logon failure → check account scope, password and permitted logon type. An accepted logon with access denied → inspect authorization on that resource.
# RunasCs — test a known password from an existing Windows shell
accepted identity -> groups/roles -> reachable services -> shares/files
-> authenticated application behavior -> accessible hosts/routes
-> new credentials/tickets/sessions -> privilege and movement handoffs
RunasCs — test a known password from an existing Windows shell
Verify destination host, accepted identity and actual read/write/execute rights. New hosts/listeners return to discovery; recovered material returns here; operating-system execution enters session handling; domain identities enter AD mapping.
REM RunasCs — test a known password from an existing Windows shell
net accounts /domain
RunasCs — test a known password from an existing Windows shell
# RunasCs — test a known password from an existing Windows shell
Get-DomainPolicyData | Select-Object -ExpandProperty SystemAccess
Password validation belongs to the existing credential procedure. Do not spray by default. If explicitly required, account for lockout threshold, duration, observation window and prior failures; use one justified candidate, stop on lockout/rate-limit evidence and preserve successful identities separately.
Verify → Record exact identity, service and tested read/write/session effect; classify authentication and authorization separately.
If it fails → Account disabled, expired password, wrong domain and denied logon require different responses. Avoid repeating a known-valid password against a denied action. More detail ↓
Explanation & examples
Validate known passwords and context-specific reuse
- USE WHEN
- A password tied to a plausible user and service
- STARTING ACCESS
- A credential artifact with a recorded source and possible account context
- RESULT
- A verified authentication result followed by tested service-specific authorization
Recognize the clue
Use the account label from the producing source and the observed service inventory to choose one compatible, correctly qualified validation.
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'
SMB TARGET [+] DOMAIN\USER: accepted
Administrative execution: not yet demonstratedMeans: Accepted authentication proves one service/account pairing; it does not establish shares, administration, RDP or WinRM.
Confirm: Qualify local/domain/application identity explicitly, test a compatible reachable service and record the accepted identity. Then test the specific share/logon/execution right; successful authentication is not administrative authorization.
- After validation
- The intended service operation succeeds under the recorded identity: use that access and re-enumerate.
- Ruled out in this context
- The secret is valid only for the application and not the proposed OS account: reject that reuse pairing.
- Still inconclusive
- A generic logon failure may hide account/domain/state mismatch; classify it before repeating attempts.
Troubleshooting: Account disabled, expired password, wrong domain and denied logon require different responses. Avoid repeating a known-valid password against a denied action.
Additional prerequisite checks
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'
ssh -p PORT USER@TARGET
Use the normal client for the observed service:
Local Windows account:
Decisive output: the destination service accepts the intended identity. Share, session or action access is a separate authorization result.
Variant — known user, targeted password dictionary
Use only on an assigned target after checking lockout and rate controls. Confirm every reported success with the normal client.
Variant — one password across an authorized user list
One attempt per account can still trigger lockout or monitoring. Establish scope, threshold/window and observation period first.
Variant — HTTP POST form
Capture a correct request and stable failure marker with Burp:
Dynamic CSRF tokens, cookies, redirects, throttling and uniform responses require manual handling or a different approach. A weak failure marker creates false positives.
RunasCs — test a known password from an existing Windows shell
Use a reviewed, compatible build on the current Windows host with a known plaintext password. This creates a new local process/logon context; it is not remote execution and does not turn an NT hash into a password.
Read: in the first two forms, whoami identifies the created process; inspect its groups/integrity before claiming escalation. With logon type 9, local whoami is not a credential test: use the remote operation's result. Logon failure → check account scope, password and permitted logon type. An accepted logon with access denied → inspect authorization on that resource.
RunasCs upstream. Native runas remains an alternative when an interactive password prompt is usable. Neither tool guarantees an elevated token.
Verify destination host, accepted identity and actual read/write/execute rights. New hosts/listeners return to discovery; recovered material returns here; operating-system execution enters session handling; domain identities enter AD mapping.
Password validation belongs to the existing credential procedure. Do not spray by default. If explicitly required, account for lockout threshold, duration, observation window and prior failures; use one justified candidate, stop on lockout/rate-limit evidence and preserve successful identities separately.
Why it works
One password may belong to several independently managed identities. Authentication success is useful only when associated with a precise service and allowed action.
Worked example · hypothetical
Observation: a configuration contains a username/password. Test: validate the source application first, then an evidence-backed OS/domain reuse. Illustrative output: SMB authenticates but no administrative access exists. Interpretation: enumerate readable shares rather than assume execution.
New identity, privilege, host or route? Re-enumerate → All topic tasks →