Credential access and lateral movement: stopping the spread

by psyrun / 2026-10-06 / Credentials and lateral movement

Credential access has 44 rules and lateral movement 10, but the group matters more than its size: credential access has the highest share of high-severity rules (10 of 44), and the tactic is tagged on nearly 50 rules overall. Stolen credentials are how an intrusion turns from one machine into a network.

1. Memory theft: LSASS

Credential-access hunt: Credential collection through reads of lsass.exe memory      medium
Credential-access hunt: Potential LSASS memory dump behavior                            HIGH
Credential-access hunt: LSASS memory capture saved as a file                      medium
memory dumping through comsvcs.dll                      HIGH
Defense-evasion hunt: Procdump launched from an uncommon folder            medium
Credential-access hunt: Unusual debug file created in a temporary folder behavior   HIGH
Credential-access hunt: Mimikatz flags detected in launch parameters (two rules)             HIGH
command-line arguments matching Mimikatz execution      HIGH
PowerShell running with known Mimikatz arguments        medium

LSASS holds credentials for logged-on users. Rules cover the process that touches it, the tools used (the comsvcs minidump call needs no extra binary), and the artefact left behind (a dump file in a temp folder). A rule on the dump file catches renamed tooling that evades name-based rules.

2. Older and custom credential tools

fgdump                                 medium
gsecdump                               medium
pwdumpx                                medium
wce (Windows Credential Editor)        medium
LaZagne                                HIGH
Cain and Abel installed low
NTLM credential capture with RpcPing   medium

These are old, but still used because they are small and reliable. Having a rule per tool is cheap and makes alerts self-explanatory.

3. Credential stores on disk

  • Registry hives that hold password hashes being dumped (low, two rules).
  • The domain database: ntdsutil accessing ntds.dit (high, two rules). This is one of the most serious events on a domain controller.
  • Volume shadow copies used to read locked files: creation with vssadmin, and WMI access to the shadow-copy interface. Attackers copy the database out of a snapshot because it is locked on the live system.
  • Browsers: an unsigned process reading Chromium credential files (two rules), a non-Google process reading sensitive Chrome files, and a non-Mozilla process reading Firefox password files (two rules).
  • Windows credential manager: a living-off-the-land binary reading a credential-manager file (two rules), and a command-line access to the credential vault (medium).
  • Cleartext hunting: harvesting passwords with find and grep (informational, plus a Unix grep rule in post 6).
  • Other: Credential-access hunt: Nagios inventory (low), and shell and SSH key discovery (Unix, post 6).

4. Kerberos and authentication abuse

setspn.exe execution (service principal enumeration for Kerberoasting)   informational
a Kerberos service-ticket request inside a PowerShell command            HIGH
Execution hunt: Rubeus tool process launch                                                    HIGH
Kerberos ticket forging using Impacket                                   medium
Kerberos brute force using Kerbrute
password brute-force tool execution
hash cracking with Hashcat                                               medium
Credential-access hunt: configuration changes of NTLM restrictions in the Registry
modification of password-filter DLL registry keys

The last two rules matter because they look for attackers making authentication weaker or inserting a password-filter DLL that captures plain-text passwords at the next password change. They fire rarely and are worth keeping at high priority.

5. Lateral movement

PsExec attempts to run a command on a remote host
an executable copied to a remote host through an admin share
Remote-movement hunt: WMI-driven remote process execution behavior                                         low
remote RDP session enumeration with query.exe and qwinsta.exe (two rules)
Remote-movement hunt: AMSI scanning evasion behavior (filed under lateral movement)                                 medium
Remote-movement hunt: scp-mediated remote file copy behavior, a remote command from a Linux host, and SSH authorized_keys changes   (post 6)

Related rules in the execution and persistence groups complete the picture: the psexesvc service running a remote command, the PsExec EULA registry key, plain-text credentials on a PsExec command line, and remote wmiexec.

6. A realistic chain

script host launches a downloader
 -> credentials taken from LSASS memory (HIGH)
 -> service tickets requested in PowerShell (HIGH)
 -> PsExec to another server
 -> domain database copied from a shadow copy (HIGH)
 -> shadow copies deleted (HIGH) and ransomware starts

If only the high-severity rules are enabled, the chain can still be caught three times.

7. Practical advice

  1. Treat LSASS access as a tier-one alert and harden the process with the operating system's own protections so a successful dump is harder.
  2. Ntds.dit access outside a backup window deserves an immediate response.
  3. Log Kerberos service-ticket requests on domain controllers; the endpoint rule covers PowerShell, but the controller sees every client.
  4. Disable NTLM where you can, and alert on any change to the restrictions.
  5. Limit local administrator reuse, because lateral movement rules only slow someone who still has valid shared credentials.
  6. Tune by signer: some backup and monitoring tools legitimately open LSASS or read shadow copies.

Deep dive A: protecting and investigating LSASS

LSASS keeps credential material in memory so Windows can do single sign-on. Dumping it means copying that memory somewhere an attacker can read it. Three layers of defence work together.

run LSASS as a protected process, so only trusted code can open it
use virtualisation-based credential isolation (Credential Guard) where supported
turn off the legacy mechanism that keeps reversible passwords in memory (WDigest)
reduce cached logons and use short-lived admin sessions

And the rules provide the detection layer: a non-system process opening LSASS, a dump file appearing in a temporary folder, or a built-in library being asked to write a minidump of LSASS (the comsvcs rule). If one fires, assume every account that logged on to that machine since boot is exposed, and rotate those credentials in order of privilege.

Deep dive B: Kerberoasting in plain language

Any domain user may request a service ticket for an account that has a service principal name. The ticket is encrypted with that account's password hash, so an attacker can take it away and guess passwords offline, with no failed logons and no alerts on the domain controller.

1  list accounts with service principal names     (setspn, or an LDAP query)
2  request service tickets for them               (a PowerShell call or Rubeus)
3  export the tickets and crack them offline      (Hashcat)
4  log on as the service account, often a privileged one

Rules in the library watch steps 1, 2 and 3. Defences: use long random passwords or managed service accounts for service principals, prefer AES over RC4 tickets, and alert on ticket requests that use the weaker RC4 type. A single user requesting tickets for many different services in a short time is a strong signal.

Deep dive C: the domain database

The file that stores every account's password hash (ntds.dit) is locked while a domain controller runs, so attackers use workarounds: a shadow copy, the directory-services utility's snapshot features, or a replication request that impersonates another domain controller (a DCSync). The first two leave host events (the ntdsutil and vssadmin rules); the third leaves directory-service events on the controller. Treat any such access outside a known backup window as a domain compromise and start incident response immediately.

Deep dive D: how PsExec-style movement looks on both ends

connects to the admin share                | a new file appears in the admin share folder
copies a small service executable          | a service is installed remotely
starts the service through the service     | the service runs the command and opens a named pipe
manager over the network                   | then the service is removed

That sequence explains why the library has rules for the PsExec registry flag on the source, the service binary executing a command on the target, and an executable copied through an admin share. Tools such as wmiexec do the same job over WMI and leave different traces (output written to a hidden share file). For both, the best defence is removing the ability: block the admin shares between workstations, firewall remote service management, and use a local-administrator password manager so one stolen password does not open every machine.

Deep dive E: remote desktop and its rules

Enumerating remote sessions with query and qwinsta tells an attacker where privileged users are logged on, so they know whose credentials are worth stealing. Alert on those commands from non-administrative workstations, require network-level authentication for remote desktop, limit who may use it, and watch for the remote-logon events that show a new source address.

Hardening checklist

local administrator password manager (unique password per machine)
tiered administration: domain admins never log on to workstations
Protected Users group for privileged accounts
restrict or disable NTLM; log and review the exceptions
long random passwords for every account with a service principal name
credential isolation and protected-process mode for LSASS
alerts on LSASS access, ntds access and group-membership changes