One of the most reliable data sources is monitoring for cross process injection operations. Stacking and investigating which processes are injecting into LSASS can be a challenge. Depending on your enterprise software stack, you may need to tune your logic to rule out legitimate applications like antivirus (AV) solutions and password policy enforcement software. These applications have legitimate reasons to access and scan LSASS to enforce security controls.
The following data sources are readily available to audit and detect suspicious LSASS process access:
Another great telemetry source that should be monitored closely is the creation of
dmp files. After dumping the memory space of LSASS, adversaries typically perform offline password attacks by leveraging a multitude of security tools and techniques. Certain memory dumping tools like Dumpert and SafetyKatz create predictable memory dumps by default in certain file paths that you can detect with high fidelity. As always though, the name and location of these files can be modified. Start with the default filenames and dive deeper into the behavior by detonating these tools in a controlled environment. On top of creating rules for specific tools, take a holistic look at what processes typically write
dmp files and narrow down your logic from there.
Network connections and child process data may also be reliable indicators of malicious code injected into LSASS. It’s rare for LSASS to execute child processes such as
powershell.exe, which may spawn because of malicious code injection. On top of child processes, LSASS establishes many internal network connections over ports 135, 445, and 88 to handle authentication with internal network services.
The days of detecting Mimikatz via traditional methods like AV, common command-line arguments, and binary metadata are far behind us. Instead, start at a high level and gather what normal LSASS activity looks like before writing detection logic around abnormal behavior.
Rather than detecting on specific tools, we recommend establishing what “normal” LSASS memory access looks like within your environment. In doing so, you can tune out normal usage and detect on any previously unknown tools or techniques an adversary might use. To investigate this, start broad and narrow down your detection logic.
Suspicious injection into LSASS
A detection analytic that has the potential to exhibit a high signal-to-noise ratio is to look for instances of
rundll32.exe that obtain a handle to LSASS. Under normal circumstances (assuming minor tuning), this behavior is rarely observed. We have detected post-exploitation frameworks such as Cobalt Strike and PowerShell Empire with such logic during numerous incident response engagements and red team simulations. Examples of data sources that raise handle access events are Sysmon Process Access events and Event ID 4656 in the security Event Log in Windows 10.
Detection should not be limited to these three processes. As you’re formulating a hypothesis about what constitutes normal and abnormal LSASS memory injection, take into consideration any patterns you may observe. Ask yourself:
- Are false positives being generated by processes located in certain process paths?
- Are there some common characteristics of these processes we can identify and exclude?
- Which processes are typically being targeted by threats in the wild?
As is discussed in the analysis section above, adversaries can create a MiniDump file containing credentials by using Rundll32 to execute the
MiniDumpW function in
comsvcs.dll and feeding it the LSASS process ID. To detect this behavior, you can monitor for the execution of a process that seems to be
rundll32.exe along with a command line containing the term
Weeding out false positives
LSASS establishes a lot of cross process memory injection stemming from itself. We identify far fewer false positives from processes injecting into LSASS. Some password-protection products will scan LSASS to evaluate user passwords. If approved by your help desk or IT support, these applications should be added to an allowlist as part of a continuous tuning process.
We don’t expect any raw data source to return a high false positive rate in itself. Detection logic should always be routinely maintained with constant tuning to prevent alert overload. Your analytics should act as a living, breathing code repository with frequent, on-the-fly adjustments to navigate your evolving environment.