Common Windows Attack Techniques
This is where processes, tokens, the registry, and logging from the last five chapters stop being separate topics and start being the pieces of a real attack chain. An attacker with local admin on one workstation does not stop there. They dump credentials, reuse them elsewhere, move laterally to reach a more valuable host, and plant persistence before a defender ever notices the first alert. This chapter walks through the techniques that connect those steps: credential dumping from LSASS, pass-the-hash, the mechanics behind PsExec, WMI, and WinRM, and why persistence is usually one of the first things an attacker does rather than one of the last. By the end, you should be able to read a short sequence of Windows events and recognize it as a chain, not a set of isolated alerts.
Credential Dumping from LSASS
Why LSASS Holds Value
The Local Security Authority Subsystem Service, lsass.exe, is the process Windows uses to enforce local security policy and handle interactive and network authentication. Part of that job requires it to hold credential material in memory for as long as a user's session is active.
When you log on interactively, unlock your machine, connect to a network share, or authenticate to an RDP session, Windows caches enough of that credential, an NT hash, a Kerberos ticket, sometimes a reversibly encrypted or plaintext secret depending on configuration, so you are not prompted to re-enter your password every time a process needs to prove who you are. This is a usability feature, single sign-on, not a bug, and it is also the reason LSASS memory is one of the most consistently valuable targets on any Windows host.
How the Access Happens
Reading that memory requires a handle to the lsass.exe process with sufficient access rights, and Windows does not hand that out casually. This is where Chapter 4's discussion of SeDebugPrivilege becomes directly relevant.
- Enable the privilege. A process needs SeDebugPrivilege enabled in its token, combined in practice with local administrator or SYSTEM context, before it can attempt to open LSASS with the access mask that permits reading its memory.
- Open a handle to lsass.exe. Tools built for credential access, Mimikatz being the best known example, use that privilege to open the process directly.
- Extract the credential material. The tool either dumps the process memory to a file for offline parsing, or walks the relevant memory structures live to pull credentials out directly.
- Optionally blend in. Some approaches avoid dropping a suspicious binary entirely by calling a legitimate Windows component, such as the MiniDump export inside comsvcs.dll, to produce the dump, making the action look like a routine diagnostic operation.
The Yield
What makes this technique so consistently valuable is the yield relative to the effort. A single successful dump on one compromised host can return credentials for every account that has authenticated to that machine since boot, not just the currently logged-on user.
On a workstation that is one or two accounts. On a jump box, a Remote Desktop server, or any host where administrators regularly connect to perform routine work, a dump can return domain admin credentials, service account credentials, and help desk credentials in one pass. That single event on one low-value box is frequently the pivot point that turns a contained incident into a domain-wide one.
Mitigations
Modern Windows includes mitigations that raise the cost of this technique without eliminating it. Credential Guard isolates a subset of secrets in a virtualization-based security container that ordinary LSASS memory access cannot reach. LSA Protection, when enabled, marks lsass.exe as a protected process so that only signed, trusted callers can open it with the access rights credential dumping requires.
Neither is universally deployed, and both can be bypassed or downgraded under the right conditions, which is why detecting the attempt still matters even in a hardened environment.
Pass-the-Hash
Chapter 3 covered how NTLM authentication works: a client proves it knows a password by using the NT hash of that password to compute a response to a challenge issued by the server, without ever transmitting the plaintext password itself. The hash is what does the cryptographic work in that handshake. That single fact is what makes pass-the-hash possible.
If the NT hash is functionally equivalent to the password for the purposes of the protocol, then an attacker who obtains the hash, typically pulled from LSASS memory the way the previous section describes, can plug it directly into the same handshake and authenticate successfully. They never see the plaintext password, never crack it, and do not need to.
A Substitution, Not a Bypass
The mechanics only swap out one input in an otherwise normal handshake. From the server's point of view, a correctly computed response to its challenge is proof of authentication. It has no way to tell whether that response was derived from a freshly typed password or a hash lifted from another machine hours earlier.
| Step | Legitimate Logon | Pass-the-Hash |
|---|---|---|
| Source of the NT hash | Computed locally from the password the user just typed | Obtained by other means, typically dumped from LSASS on a different host |
| Response computation | Client computes the challenge response from that freshly derived hash | Attacker's machine skips straight to the response computation using the stolen hash |
| What the server sees | A correctly computed response | The same correctly computed response, indistinguishable to the server |
Where It Reaches
The technique's reach is bounded by where NTLM is accepted and by what that authenticated identity is authorized to do. Any service that will accept NTLM as an authentication mechanism, SMB administrative shares, WMI, RPC-based management interfaces, is a viable target as long as the account behind the stolen hash has meaningful rights on the destination host.
This is why credential dumping and pass-the-hash are so often chained together in the same incident. Dump a hash on one machine, replay it against a second machine where that account has local admin, and the attacker has code execution somewhere new without ever needing the plaintext.
Mitigating Exposure
Kerberos-preferred environments reduce but do not eliminate exposure to this technique. Where NTLM fallback is still permitted, and it frequently is for compatibility reasons, pass-the-hash remains viable.
A closely related technique, pass-the-ticket, applies the same substitution idea to Kerberos tickets instead of NTLM hashes and is worth knowing exists even though the underlying protocol mechanics differ. The defensive takeaway is the same either way: restricting NTLM where it is not needed, and limiting how widely privileged accounts are permitted to authenticate, reduces how far a single stolen credential can travel.
Lateral Movement: PsExec, WMI, and WinRM
Once an attacker holds usable credentials for an account with rights on another host, whether recovered by cracking, replayed via pass-the-hash, or simply reused because it was weak, they need a mechanism to actually execute code on that host. Three built-in Windows facilities cover the overwhelming majority of real-world lateral movement, and each one leaves a distinct fingerprint that a defender can learn to recognize.
PsExec: Service Creation over ADMIN$
PsExec, and tools that replicate its approach, work by writing an executable or a service binary to the target's ADMIN$ administrative share, then using the Service Control Manager API to remotely create and start a temporary Windows service that runs that binary, typically as SYSTEM. Output is relayed back over a named pipe.
The service is usually deleted immediately after use, but the act of creating and starting it is logged before that cleanup happens, and the file transfer over ADMIN$ leaves its own trace.
WMI: Process Creation Without a File Drop
WMI-based lateral movement takes a different path. It uses DCOM or WMI's own RPC-based protocol, communicating over TCP 135 plus a dynamically negotiated high port, to invoke the Win32_Process class's Create method on the remote host.
This spawns a process directly through the WMI provider host without writing a new service or dropping an executable through a file share first, which is exactly why it is popular with attackers trying to minimize artifacts. The trade-off is that WmiPrvSE.exe becomes the parent of whatever process gets created, and that parent-child relationship is unusual enough in most environments to be a strong detection signal on its own.
WinRM: An Interactive PowerShell Session
WinRM, PowerShell remoting, runs over the WS-Management protocol on TCP 5985 for HTTP or 5986 for HTTPS. A successful connection spawns wsmprovhost.exe on the target and gives the attacker an interactive PowerShell session rather than a single fire-and-forget command, which makes it attractive for anything beyond a one-shot execution.
Because it is a full PowerShell session, everything Chapter 6 covered about script block logging and the PowerShell Operational log applies directly here: commands run over a WinRM session are visible in that telemetry if logging is configured to capture them.
| Method | Underlying Mechanism | Port / Protocol | Key Artifact |
|---|---|---|---|
| PsExec | Temporary service via Service Control Manager | SMB (445), named pipe | Event ID 7045, ADMIN$ file write |
| WMI | Win32_Process.Create over DCOM/RPC | TCP 135 + dynamic high port | WmiPrvSE.exe as parent process |
| WinRM | PowerShell remoting over WS-Management | TCP 5985 / 5986 | wsmprovhost.exe parent, PS Operational log |
Persistence from the Attacker's Perspective
Chapter 5 walked through registry-based persistence, Run keys, scheduled tasks, and malicious services, mostly as mechanisms in isolation: what each one is, where it lives, how it survives a reboot. Seen from the attacker's side of an active intrusion, those mechanisms are not a checklist item to get to eventually.
They are usually one of the first things established once code execution on a target is achieved, often before any lateral movement or objective-focused activity begins.
Why Persistence Comes Early
The reasoning is practical. An attacker cannot predict when their initial foothold will disappear, and any of the following can end an access that took real effort to obtain in the first place, whether through a phishing lure, an exploited vulnerability, or purchased initial access from a broker:
- A routine reboot. The user restarts the machine for a normal patch cycle.
- A help desk reimage. A support ticket triggers a full rebuild of the endpoint.
- An EDR detection. The initial payload gets flagged and quarantined hours after execution.
None of these events are under the attacker's control. Persistence is the insurance policy against all of that uncertainty, converting a single fragile foothold into a durable one that survives the ordinary churn of a managed endpoint.
The Access Broker Gap
This is especially visible in access broker and ransomware precursor activity, where the group establishing initial access is frequently not the group that will eventually deploy the final payload. There can be a gap of days or weeks between the two.
That entire gap depends on persistence mechanisms quietly surviving reboots, patches, and routine administrative activity without drawing attention. A Run key pointing to an innocuous-looking binary, a scheduled task disguised as a system maintenance job, or a service installed under a name that resembles a legitimate one, any of these can bridge that gap.
What This Means for a Defender
The practical implication is that persistence should be treated as an early-stage indicator, not a late-stage one. Finding a suspicious autorun entry or an unfamiliar service is not evidence that an intrusion is winding down.
It is frequently evidence that it just began, and that credential access, lateral movement, and further objectives are still ahead rather than behind.
Living Off the Land on Windows
- LOLBin ("living off the land binary"): a legitimate, Microsoft-signed executable that ships as part of Windows or a common Windows component, and that has some documented, legitimate function an attacker can repurpose for a malicious task.
- Application allowlisting: solutions like AppLocker or WDAC that block unknown binaries from running, but generally permit LOLBins by default to avoid breaking legitimate administrative workflows.
What Counts as a LOLBin
Tools like certutil, mshta, rundll32, and regsvr32 all fall into this category. None of them were designed as attack tools.
All of them can, under the right circumstances, be used to download a file, execute a script, or load code, which is the reason they show up so often in real intrusions.
Why They Evade Detection
The appeal to an attacker is straightforward. A signed Microsoft binary that is already present on essentially every Windows install does not trigger the same suspicion that a custom, unsigned executable does.
Application allowlisting solutions generally permit these tools by default, and antivirus signature detection has nothing unusual to flag when the binary in question is a stock component of the operating system. The malicious part is not the file. It is the arguments passed to it and the context in which it runs.
Where to Go Deeper
This chapter only touches the concept at a high level, because the depth of coverage it deserves lives elsewhere on this platform. H3AD-LEARN's dedicated LOLBAS module catalogs specific binaries, the techniques associated with each one, and how to build detections around their abuse patterns rather than their static identity.
If you want the full inventory beyond the handful of examples named here, that module is the place to go next.
Detection Mindset for Attack Chains
Every technique in this chapter looks unremarkable on its own if you only have one piece of telemetry to look at. A process accessing lsass.exe could be legitimate diagnostic tooling. A WinRM connection could be routine remote administration. A new scheduled task could be a normal deployment artifact.
The techniques described here become detectable not because any single event is definitively malicious, but because Chapter 1's process tree thinking and Chapter 6's logging coverage let a defender line up several weak signals in a short window of time and recognize the shape of a chain.
A Concrete Chain
- LSASS access. Sysmon Event ID 10 shows an unusual process, one with no ordinary reason to touch LSASS, opening a handle to lsass.exe with a GrantedAccess mask consistent with memory reading. On its own, worth a look, not necessarily an incident.
- Outbound WinRM connection. Within a short window afterward, the same host shows an outbound connection on port 5985 to a host it has never talked to before.
- Process spawn on the second host. A wsmprovhost.exe process appears on that second host with a parent chain that traces back to a legitimate-looking but recently modified service account.
Individually, each event might survive a first-pass triage. Correlated, in sequence, on a tight timeline, they describe credential access followed by lateral movement using the credential just obtained, which is exactly the chain this chapter has been building toward.
Why This Ties Everything Together
This is the practical payoff of everything the last six chapters covered. Process trees tell you what spawned what. Tokens and privileges tell you whether an action was even possible for the account performing it.
The registry and service-based persistence mechanisms tell you what an attacker is trying to make permanent. Event logging and Sysmon are what make all of the above visible and correlatable in the first place. None of these are separate skills in a real investigation; they are the same skill, applied to different layers of the same host.
Key Takeaways
- LSASS caches credential material in memory to support single sign-on. Dumping it requires SeDebugPrivilege and admin-or-higher context, and one successful dump can return credentials for every account that has authenticated to that host since boot.
- Pass-the-hash works because NTLM authentication only ever requires the NT hash, not the plaintext password, allowing a stolen hash to be replayed directly into the same challenge-response handshake.
- PsExec, WMI, and WinRM each provide legitimate remote execution and each leaves a distinct artifact: a temporary service, a WmiPrvSE.exe parent process, or a wsmprovhost.exe session respectively.
- Persistence is typically established early in an intrusion, not late, because attackers cannot predict when their initial foothold will be lost to a reboot, patch, or detection.
- LOLBins are abused precisely because they are signed, trusted, and already present, letting malicious activity blend into normal administrative noise. The LOLBAS module covers the full catalog.
- Real detection comes from correlating weak signals across process, credential access, and network telemetry in a tight time window, not from any single alert in isolation.
Knowledge Check
Click an answer to reveal the explanation.
A Sysmon Event ID 10 shows a non-standard process, with SeDebugPrivilege enabled in its token, opening a handle to lsass.exe with a GrantedAccess mask that includes PROCESS_VM_READ. What is most likely occurring?
An incident responder finds that an attacker authenticated to a file server as a domain admin account from a workstation where that account had never interactively logged on, and no plaintext password for the account was ever recovered from the attacker's tooling. Which technique best explains this?
A SOC analyst sees Event ID 7045 (new service installed) on a target host, with the service binary written to the ADMIN$ share, immediately followed by a brief service execution and its removal. This artifact pattern is most consistent with: