9.4 Credential Theft, Mimikatz, Sysmon, and Auditd

Credential theft as an endpoint objective

Once an adversary has a process on an endpoint (section 9.3), stealing credentials multiplies the intrusion. A single finance workstation becomes the help-desk password, the service account, or the domain administrator hash. SAL1 training content calls out credential theft with a focus on Mimikatz, then closes the module on attack impact and on detection logging with Sysmon and auditd. This independent study section teaches what that activity looks like to defenders. It does not document Mimikatz modules, command syntax, or laboratory dump procedures.

On Windows, LSASS (lsass.exe) is the process that implements much of local authentication policy and holds secrets in memory for actively logged-on users. Backup software, some security products, and Microsoft's own tooling may access LSASS under a known, signed parent. A random binary, a script host, or rundll32.exe launched from an Office child is not that baseline. The impact of a successful dump is reuse of those credentials on other hosts: new 4624 Type 3 or Type 10 events as the stolen identity, often from the original workstation's IP or from a newly persisted service.

Linux credential theft looks different: reading /etc/shadow (usually needs root), dumping process memory of authentication helpers, harvesting SSH keys from ~/.ssh/, or scraping tokens from user agent files. Auditd is how those file and exec events become evidence.

What Mimikatz-class activity looks like to defenders

Mimikatz is a well-known credential-dumping tool frequently discussed in SOC training. You may see the string in a file name, a command line, a hash match, or a threat-intel hit. You may also see behaviorally equivalent activity with a renamed binary. Do not wait for the trademarked name.

Defender-visible signals (no usage instructions):

• Sysmon Event ID 10 (ProcessAccess) with TargetImage ending in lsass.exe and a source image that is not in the allow-list (unknown EXE, powershell.exe, rundll32.exe, cmd.exe, unsigned code in user-writable paths).
• GrantedAccess masks that include memory-read rights atypical for that parent. You do not need to memorize every mask; you need a detection engineering note that "Office → script → LSASS access" is never backup software.
• Security Event 4688 (process creation) with command lines that name credential-dumping tools, that invoke LSASS-related libraries through rundll32, or that disable logging immediately before the access. Treat the command line as an IOC to hash and contain, not as a lab exercise.
• Follow-on 4624 as a second user on the same host, or 4648 logon with explicit credentials toward a file server, while the human is still in Word.

Worked, sanitized 4688 plus Sysmon 10 (strings generalized on purpose):

4688 Time=2026-09-18T10:04:12Z Parent=C:\Program Files\Microsoft Office\WINWORD.EXE
     NewProcess=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
     CommandLine=[encoded or remote-download flags redacted — preserve the original in the case file]

4688 Time=2026-09-18T10:04:19Z Parent=powershell.exe
     NewProcess=C:\Windows\System32\rundll32.exe

Sysmon 10 Time=2026-09-18T10:04:20Z SourceImage=rundll32.exe TargetImage=C:\Windows\System32\lsass.exe

Case note language that stays honest: "Process access to LSASS from rundll32 with WINWORD as the grandparent matches credential-theft tradecraft associated with tools such as Mimikatz; isolate host, reset credentials for users logged on at 10:04, and hunt the same parent-child pattern." That sentence does not teach anyone how to dump LSASS.

Sysmon for Windows detection logging

Sysmon (System Monitor) is a Windows system service and device driver that logs high-value endpoint events to the Windows Event Log (typically Microsoft-Windows-Sysmon/Operational). It does not replace antivirus. It does not contain a host by itself. It gives analysts structured telemetry that default Security auditing often lacks.

Event IDs you will actually query during credential-theft and endpoint-attack investigations:

• Event ID 1 — Process creation, with parent image, hashes, and command line when configured. Complements 4688, which also records process creation when Advanced Audit Policy includes it, but Sysmon's default field set is richer for hunting.
• Event ID 3 — Network connect (who talked to whom after the dump).
• Event ID 10 — Process access (the LSASS story).
• Event ID 11 — File create (dump files landing on disk, if the actor wrote one).
• Event ID 13 — Registry value set (Run keys from section 9.3).

Sysmon is only as good as its configuration and its forwarding. A workstation that never shipped Event ID 10 cannot alert on LSASS access. A configuration that excludes rundll32.exe to reduce noise also excludes a common living-off-the-land parent. SOC detection engineering should exclude known signed security products that access LSASS, not the entire System32 directory.

4688 remains important on hosts without Sysmon: it still shows winword.exe → powershell.exe if command-line auditing is on. Without command-line auditing, 4688 may show only the image name, which is weaker but still enough to start a timeline.

Auditd for Linux detection logging

auditd is the user-space component of the Linux Audit system. It records security-relevant events according to rules: system calls, file watches, and login streams. SAL1 training content names it alongside Sysmon because Windows and Linux endpoints both need activity logging for detection.

Analyst-useful record types:

• USER_AUTH / USER_LOGIN / USER_START — complements sshd Accepted lines with PAM context.
• SYSCALL + EXECVE — the Linux equivalent of process creation with arguments (when execve auditing is enabled). This is how you see a web worker spawn a shell (section 9.2) or a user session start a credential-stealing script.
• File watches (-w) on authorized_keys, sudoers, cron directories, and /etc/shadow — persistence and credential-file access.
• SYSCALL around ptrace or memory-related calls on authentication processes — Linux cousins of LSASS process access, without treating this as a recipe.

Worked, sanitized auditd exec:

type=EXECVE time=2026-09-18T10:16:44Z uid=0 pid=9201 a0=python3 a1=[script under /tmp redacted]
type=SYSCALL success=yes comm=python3 exe=/usr/bin/python3 key=sensitive-exec

Pair that with an sshd Accepted for the same user two minutes earlier. Initial access plus a root python interpreter touching sensitive paths is credential or data theft until proven otherwise.

Worked process tree: Office to LSASS access

Put the chapter together. A user opens a document. WINWORD.EXE starts. Word starts powershell.exe (macro, template, or add-in — the analyst records the parent, and does not need to reproduce the macro). PowerShell starts rundll32.exe. Rundll32 opens lsass.exe (Sysmon 10). Within minutes, 4624 Type 3 appears toward a file server as another user who never typed a password on that workstation.

winword.exe
  --> powershell.exe
        --> rundll32.exe
              --> process access: lsass.exe
                    --> later 4624 as stolen identity on FILE-01

Impact: every account that had a session on the workstation is in scope for reset; Kerberos tickets and cached material may already have been copied; persistence from 9.3 may already be in place so that killing PowerShell is not recovery. Detection depends on Sysmon 10 (or equivalent EDR process-access telemetry) plus 4688/Sysmon 1 for the tree plus identity logs for reuse. If those logs were never enabled, the case starts at ransomware, not at 10:04.

Traps: lsass.exe accessing other processes is not the same as other processes accessing lsass.exe. Security product parents should be allow-listed by hash and path, not by "it said antivirus in the name." Encoded PowerShell command lines are still 4688 evidence; decoding them belongs in the case file, not in a public blog as a reusable exploit. Mimikatz is one named tool in a behavior class; renamed clones must still match the tree.

Activity logging is the difference between a contained credential-theft incident and a domain-wide reconstruction. Sysmon and auditd are not optional decorations on a lab VM. They are how SAL1-style analysts prove initial access, persistence, privilege escalation, and credential theft with timestamps instead of guesses.