LSASS.DMP... Attacker or Admin?

When analysing a system for evidence of attacker activity, the presence of a file named LSASS.DMP should pique your interest as an investigator, as it can be an indication of credential theft and possible privilege escalation. However, if there is no other evidence of compromise on the system, or the creation timestamp of LSASS.DMP is outside of your intrusion timeline, you may be left questioning whether the dump relates to this breach, a historical breach, a red team or no breach at all.

In this blog I will share an analysis technique which recently helped me ascertain with high confidence that an LSASS.DMP file was generated by an administrator and was not related to the intrusion we were investigating.

What is LSASS.DMP?

The Local Security Authority Subsystem Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing the security policy on the system, such as verifying users during users logons and password changes. 

LSASS.DMP is a dump file of the LSASS process. Attackers can dump LSASS to a dump file using  tools such as ProcDump (https://docs.microsoft.com/en-us/sysinternals/downloads/procdump). The attacker can then extract passwords and password hashes from the process dump offline using Mimikatz.

Whilst an attacker can run Mimikatz directly on a system, collecting a LSASS process dump may be a preferable technique as ProcDump is not considered malware by most antivirus tools, so is less likely to generate a security alert.

Admin or Attacker ?

When an administrator is generating a process dump, it is often at the request of a vendor or application team. The purpose of these dumps are to capture an error or unwanted behavior for troubleshooting. The vendor may request that ProcDump is executed with specific arguments, in order to increase the likelihood of capturing the unwanted behavior. For example, I have seen the following procdump arguments used by an administrator to generate a process dump of LSASS when the process utilised more than 85% CPU for more than 5 seconds.

procdump -c 85 -s 5 -n 3 lsass

Thankfully, ProcDump does us a favour as investigators and includes a comment in the process dump detailing the non-standard arguments used to generate the dump. These comments can be read by opening the dump file in WinDbg. Once loaded, the Command Window will display the comment as follows:

Loading Dump File [C:\Users\barna\AppData\Local\Temp\lsass.DMP]

Comment: '

*** procdump -c 85 -s 5 -n 3 lsass

*** Process exceeded 85% CPU (system scale) for 5 seconds. Value: 99%. 

Hottest Thread: 6868 (0x1ad4).'

User Mini Dump File: Only registers, stack and portions of memory are available.

Not only is it highly unlikely that an attacker would execute procdump with these arguments, the resulting process dump does not contain complete application data. In my testing, this resulted in errors when attempting to extract credentials using Mimikatz.

When an attacker is generating a process dump of lsass, they want to acquire all of the process application data. This is where the credentials are stored, and this is the default type of dump generated by procdump with no additional arguments.

When you open this kind of process dump in WinDbg,  the Command Window will display the following message:

Loading Dump File [C:\Users\barna\AppData\Local\Temp\lsass.DMP]
User Mini Dump File with Full Memory: Only application data is available

During testing I was able to successfully extract credentials from this type of process dump using Mimikatz, as expected. It is important to note that unlike the first dump we examined, which is highly likely to be related to administrative activity, an LSASS dump with full application data and no comment could be related to either administrator or attacker activity. Further analysis of the system would be required to provide context as to why the dump was generated.

Conclusion

WinDbg enables an investigator to easily analyse the comments embedded in LSASS process dumps, as well as whether the process dump contains 'full' or 'portions' of application data. This information can help to provide context to why the process dump was generated. In some scenarios, this information may be sufficient to conclude with a high level of confidence that the dump was not related to attacker activity.