Detecting Remote Credentials Dumping via comsvcs.dll

Remote credential dumping via comsvcsc. Showcasing Lsassy 3.0.0 tool for stealthier approches detection.

Introduction:

I previously wrote a three parts blog about Detection Engineering Dimensions in a SOC Universe where I used Remote Credentials Dumping via comsvcs.dll as a use case to practically demonstrate the implementation of the Analytic Ascendency Model on detection analytics development in order to improve detection resilience.

Gartner's Analytic Ascendency Model is a data and analytics maturity model that was introduced in 2012. The initial purpose of this model is to help organizations determine their data and analytics maturity level. The model identifies four types of analytics:

• Descriptive Analytics : What happened ?

  • What telemetry was generated ?

  • What are the changes observed on the targeted host ?

• Diagnostic Analytics : Why it happened ?

  • What enabled the attacker to perform such an attack ?

• Predictive Analytics : What could change ?

  • What the attacker can change to evade this detection ?

• Prescriptive Analytics : What should be done ?

  • What can we do to stop it ?

Lab environment:

• Winlogbeat Agent and Sysmon for endpoint telemetry

• Zeek for network telemetry.

• Elastic Stack for centralized logging and correlations

• Tool : Lsassy 3.0.0 by @HackAndDo

  • Supported dumping methods :

    • comsvcs

    • comsvcs_stealth

    • dllinject

    • procdump

    • procdump_embedded

    • dumpert

    • dumpertdll

    • ppldump

    • ppldump_embedded

  • Supported execution methods :

    • Remote Service Creation (smb.py)

    • Remote Service Modification (smb_stealth.py)

    • Remote Scheduled Task Creation (task.py)

    • Remote Command Execution via WMI (wmi.py)

    • Remote Command Execution via MMC (mmc.py)

  • Key Features:

    • Dumping at scale by targeting multiple hosts at once.

    • On-Host parsing capability without the need to download the dump and parse it offline.

    • Stealthy implementations to evade detections.

    • Highly customizable and modular to add custom dumping techniques.

Descriptive Analytic : What happened ?

In this demo we used comsvcs.dll dumping technique with SMB execution method. Later, we will demonstrate a stealthier approach with the same tool. However, upon our first demo, here are our first observations :

• A service was created with a random name

• The service was configured with a one-liner service file name to find and dump LSASS process memory using a LOLBin technique based onCOMSVCS.DLL.

• The service is configured to start on demand when the StartService function is called

Descriptive Analytic:

Event ID 4697 / 7045 :

Service installed

• Service File Name : *comsvcs.dll*

Event ID 1:

Process created

• Process Name : cmd.exe

• Process Parent Name : services.exe

• Process Command Line arguments : MiniDump, full, rundll32.exe, *comsvcs.dll

Logic is valid. However, detection resilience is very low

Diagnostic Analytic : Why it happened

The WHY here is not about an attacker's intent but about what enabled the attacker to do this. Here are some key points to consider.

• The service control manager (SCM) is an RPC server that enables service configuration and control of service programs. It was leveraged by the SMB.py exec module of lsassy to remotely create a service on the targeted machine.

• SCM supports remote procedure calls over both Transmission Control Protocol (RPC/TCP) and named pipes (RPC/NP).

• The server interface is identified by UUID 367ABB81-9844-35F1-AD32-98F038001003 and uses RPC endpoint "\PIPE\svcctl". According to Microsoft documentation, the server MUST use RPC over SMB, ncacn_np or RPC over TCP, or ncacn_ip_tcp as the RPC protocol sequence to the RPC implementation. [See references bellow]

Lsassy smb.py code snippet

• After binding to the server interface the tool uses OpenSCManagerW function that establishes a connection to the service control manager on the specified computer and opens the specified service control manager database.

SC_HANDLE OpenSCManagerW(
// The name of the target computer
LPCWSTR lpMachineName,   

// The name of the service control manager database. This parameter should be set to SERVICES_ACTIVE_DATABASE. Fixed to registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services at system boot.
LPCWSTR lpDatabaseName,

// The desired access to the service control manager.
DWORD dwDesiredAccess

);

• Then it creates a service using CreateServiceW function

SC_HANDLE CreateServiceW(
  SC_HANDLE hSCManager,
  LPCWSTR   lpServiceName,
  LPCWSTR   lpDisplayName,
  DWORD     dwDesiredAccess,
  DWORD     dwServiceType,
  DWORD     dwStartType,
  DWORD     dwErrorControl,
  LPCWSTR   lpBinaryPathName,
  LPCWSTR   lpLoadOrderGroup,
  LPDWORD   lpdwTagId,
  LPCWSTR   lpDependencies,
  LPCWSTR   lpServiceStartName,
  LPCWSTR   lpPassword
);

Lsassy smb.py SCMR code snippet

• comsvcs.dll exports a function called MiniDump which can be used by rundll32 to dump process memory.

• comsvcs.dll accepts three parameters but the first two are ignored and the third one contains three parts which are the target process ID, the dump file location and the option full.

• The MiniDump function requires a target process ID. Process discovery technique is expected. In this case tasklist.exe is used to get LSASS process ID.

• The MiniDump function call can also be achieved by function reference number #24.

• The execution of this method requires rundll32.exe to request a handle to LSASS. An EID 10 will be generated with comsvcs.dll in Call Trace field.

After going through diagnostic analysis more telemetry seems to be relevant to this attack technique. Bellow an updated list of observed events :

Diagnostic Analytic:

Event ID 5145 :

A network share object was checked to see whether client can be granted desired access

• Relative Target Name : svcctl

• Share Name : \*\IPC$

Zeek :

DCE-RPC log file

• DCE-RPC Operation: CreateService*

• DCERPC Endpoint: svcctl

Event ID 12 :

Registry object create and delete

• Process Name : services.exe

• Target Object : HKLM\System\CurrentControlSet\Services\*

Event ID 13:

Registry value set

• Process Name : services.exe

• Image Path: HKLM\System\CurrentControlSet\Services\*\ImagePath

• Details: *comsvcs.dll*

Event ID 7045 / 4697 :

Service installed

• Service File Name : *comsvcs.dll*

Event ID 1 :

Process created

• Process Name: tasklist.exe

• Process Command Line Arguments : tasklist, /fi, Imagename eq lsass

Event ID 1 :

Process created

• Process Name : rundll32.exe

• Process Command Line Arguments : (MiniDump OR #24) AND full AND *comsvcs.dll

Event ID 10 :

Process Access

• Source Image : *rundll32.exe

• Target Image : *lsass.exe

• Call Trace : *comsvcs.dll*

Event ID 4656 :

A handle to an object was requested

• Process Name : *rundll32.exe

• Object Name : *lsass.exe

Predictive Analytic : What could change ?

In predictive analysis we reach the phase where we will be working on analytic resilience. So the next step is to know what the attacker can change in order to evade generating this telemetry. Bellow, I am stating a few but not all possible changes that can be done by the tool LSASSY since my goal is not to detect the tool but to understand the underlying capabilities:

1. The attacker in this use case can change the execution method by not creating a new service and only modifying an already existing one, this will automatically evade detections based on EIDs 7045 and 4697.

2. The attacker can also copy and rename the DLL comsvcs.dll to evade hardcoded string-based command-line detections.

3. The attacker can also adopt the execution of obfuscated and encoded command lines through cmd.exe or powershell.exe.

Prescriptive Analytic : What should be done ?

Now that we know some potential mutational properties that the attacker might change we will refine the diagnostic analytic telemetry in order to use ones that will hold up and build a resilient detection analytic.

• Modifying an existing service will result in using QueryServiceConfig to query the configuration of targeted service the attacker wants to change followed by ChangeServiceConfig function to apply that change instead of CreateService. For detection opportunities we can rely on EID 5145 but Zeek's DCE-RPC event log has high Event Decisiveness and Traceability since it provides the exact endpoint operation and not just the accessed RPC endpoint svcctl.

• Event traceability analysis of EID 7045 and 4697 against EID 12 and 13 would eliminate the usage of service creation Windows events logs. The modification or creation of a service configuration would results directly in the SCM database registry ImagePath modification under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\[RANDOM]\ImagePath. So we can rely on EID 13 for this matter.

ImagePath modification upon the creation or modification of a service

• In order to copy the comsvcs.dll file and rename it the attacker needs to reach it first. So an EID 5145 will be generated in this case with comsvcs.dll in Relative Target Name field. This event is highly decisive since it is pretty rare to observe such behavior therefore it can be a detection analytic on its own.

Event ID 5145 remote access to comsvcs.dll

• The attacker can also rely on obfuscation techniques or encoding their command lines. The success of catching malicious obfuscated command can be achieved through your SIEM/EDR abilities in parsing command arguments, case-sensitivity search and recording de-obfuscated commands. In this particular technique I will be relying on process access telemetry as an alternative since it is a less risky and much decisive artifact than command-line execution.

• Again, we can use two events, Sysmon's EID 10 and Windows event log EID 4656. An event traceability evaluation would go with EID 10 in this case because of its additional Call Trace field richness and the source process GUID that can be used for correlation purposes (In my case Elastic Security uses this field to create process trees visualizations). rundll32.exe accessing lsass.exe alone is a rare behavior. However, you can increase the precision of your analytic by looking for comsvcs.dll in Call Trace or any another dll from a location other than C:\Windows\System32\in case it was renamed.

rundll32.exe accessing lsass.exe

Prescriptive Analytic :

Event ID 5145 :

A network share object was checked to see whether client can be granted desired access

• Relative Target Name : Windows\System32\comsvcs.dll

• Share Name : \\*\C$

Zeek :

DCE-RPC log file

• DCE-RPC Operation: CreateService* ORChangeServiceConfig*

• DCERPC Endpoint: svcctl

Event ID 5145 :

A network share object was checked to see whether client can be granted desired access

• Relative Target Name : svcctl

• Share Name : \*\IPC$

Event ID 13:

Registry value set

• Process Name : services.exe

• Image Path: HKLM\System\CurrentControlSet\Services\*\ImagePath

Event ID 10 :

Process Access

• Source Image : *rundll32.exe

• Target Image : *lsass.exe

Bellow is a correlation example of different logic building blocks after adopting Gartner's Analytics Ascendency Model to our detection engineering for a resilient detection output. Remember to increase the reliability of your detection, an event visibility evaluation is important. Also to increase the efficiency of your SOC detection capabilities, operationalizing your detection analytics relies on continuous tuning and actionable metrics measurement.

Several other execution methods like Scheduled tasks and WMI or MMC can be used with this technique but for brevity I won't be including these options. However similar approach can be used for this matter.