Detecting MITRE ATT&CK Technique: Part 2 – T1003.001 (LSASS Memory)

Today I wanted to write a quick blog post on how you can detect, with free and open source tools, attackers using rundll32.dll and the comsvcs.dll to dump the memory from LSASS.

You can find out how my environment is setup in part1 of this series: https://marcusedmondson.com/2020/07/29/detecting-mitre-attck-technique-t1218-010-regsvr32/

So now let’s cover how MITRE ATT&CK describes how LSASS can be accessed to dump credentials.

ATT&CK Description:

Adversaries may attempt to access credential material stored in the process memory of the Local Security Authority Subsystem Service (LSASS). After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. These credential materials can be harvested by an administrative user or SYSTEM and used to conduct [Lateral Movement](https://attack.mitre.org/tactics/TA0008) using [Use Alternate Authentication Material](https://attack.mitre.org/techniques/T1550).

As well as in-memory techniques, the LSASS process memory can be dumped from the target host and analyzed on a local system.

For example, on the target host use procdump:

procdump -ma lsass.exe lsass_dump

Locally, mimikatz can be run using:

sekurlsa::Minidump lsassdump.dmp

sekurlsa::logonPasswords

Also built-in windows tools can be utilized to dump LSASS using:

C:\Windows\System32\rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).id $env:TEMP\lsass-comsvcs.dmp full 

Windows Security Support Provider (SSP) DLLs are loaded into LSSAS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user’s Domain password or smart card PINs. The SSP configuration is stored in two Registry keys: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages and HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages. An adversary may modify these Registry keys to add new SSPs, which will be loaded the next time the system boots, or when the AddSecurityPackage Windows API function is called.(Citation: Graeber 2014)

The following SSPs can be used to access credentials:

Msv: Interactive logons, batch logons, and service logons are done through the MSV authentication package.

Wdigest: The Digest Authentication protocol is designed for use with Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) exchanges.(Citation: TechNet Blogs Credential Protection)

Kerberos: Preferred for mutual client-server domain authentication in Windows 2000 and later.

CredSSP: Provides SSO and Network Level Authentication for Remote Desktop Services.(Citation: TechNet Blogs Credential Protection)

Now to what my environment was able to pick up for this attack. 

Today’s attack utilized T1003.001 – LSASS Memory: Atomic Test #3 – Dump LSASS.exe Memory using comsvcs.dll. The command I used was: C:\Windows\System32\rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).id $env:TEMP\lsass-comsvcs.dmp full

So the way I had my environment setup the event ID’s that fired for this attack were:

1. Sysmon Event ID 1 – Process Create
2. Sysmon Event ID 11 – File Created
3. Windows\PowerShell\Operational Event ID 4104 – PowerShell ScriptBlock Logging

Here are my Kibana queries:

1. winlog.event_id:* AND winlog.event_data.CommandLine:”~rundll32″ AND winlog.event_data.ParentImage:”~powershell.exe”
2. winlog.event_id:* AND winlog.event_data.ProcessGuid:”{F52EECD8-B0EC-5F21-8001-000000000800}”
3. (winlog.event_id:4104 OR winlog.event_id:4103) AND “lsass-comsvcs.dmp”

The first query is looking for all event ID’s where PowerShell is calling anything similar to rundll32 in the command line. The ~ operator is the way you can perform a fuzzy search using kibana. This gave me Sysmon Event ID 1 to look at.

Query number 2 is looking through all event ID’s, where the ProcessGuid matches what I found in my first query. Sysmon creates the ProcessGuid field to allow correlation of events. For example, if a process makes a network connection and also created a file they would all have the same ProcessGuid. This gave me Sysmon Event ID 11 to look at. This is powerful when looking for suspicious events on your machines. 

Query number 3 is looking through all my 4103 module logs and 4104 script block logs looking for the file I found in my second query. This gave me Windows\PowerShell\Operational Event ID 4104 – PowerShell ScriptBlock Logging to look at.

So in conclusion, free and open source tools for the win. Until next time…

Happy Hunting,

Marcus

References:

1. https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md#atomic-test-2—dump-lsassexe-memory-using-procdump
2. https://attack.mitre.org/techniques/T1003/001/