OS Credential Dumping- LSASS Memory vs Windows Logs

0

Credential dumping is the process of obtaining account login and password information, normally in the form of a hash or a clear text password, from the operating system and software. Credentials can then be used to perform Lateral Movement and access restricted information.

In most organizations, we have the rule to detect it with lsass memory. But still, we are missing more peculiar rules which may evade AV/EDR. Those are the techniques listed below:

Technique 1:via MiniDumpWriteDump (Generic + ComSVCs.dll Lolbas):

  • MiniDumpWriteDump process writes user-mode minidump information to the specified file.
  • There are multiple ways to write a simple lsass process dumper using MiniDumpWriteDump API.
  • It’s possible to use MiniDumpWriteDump API call to dump lsass process memory.
  • Lsass process dumps created with MiniDumpWriteDump can be loaded to mimikatz offline, where credential materials could be extracted.
  • Mostly AV/EDR will flag it for reading lsass process memory.

Find more info at: sighthillstonecircle.net

Detection Techniques:

Detection 1:

Sysmon Process Access EID 10 – TargetImage is Lsass AND Call Trace contains dbghelp.dll or dbgcore.dll

Description:

  • Sysmon Event ID 10: The process accessed event reports when a process opens another process, an operation that’s often followed by information queries or reading and writing the address space of the target process. This enables detection of hacking tools that read the memory contents of processes like Local Security Authority (Lsass.exe) in order to steal credentials.
  • Malicious code uses a native windows API call MiniDumpWriteDump to make a memory dump of a given process.
  • If you are on the blue team and trying to write detections for these activities, you may consider looking for processes loading in dbghelp.dll module and calling MiniDumpWriteDump function.
  • dbghelp.dll: This analyzes debug information in a file / in a running process.
  • dbgcore.dll: Windows Core Debugging Helpers
  • Call Trace includes the DLL and the relative virtual address of the functions in the call stack right before the open process call

Logic explanation:

Need to have a detection rule if the .dllfiles : dbghelp.dll or dbgcore.dll tries to call the process lsass along with the sysmon ID 10.

Detection 2:

Sysmon Process Creation – EID 1 – Process Original Filename is Rundll32 and CommandLine contains comsvcs.dll and Minidump

Splunk Rule:

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where `process_rundll32` Processes.process=*comsvcs.dll* Processes.process=*MiniDump* by Processes.userProcesses.process_nameProcesses.original_file_nameProcesses.processProcesses.dest | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)` | `dump_lsass_via_comsvcs_dll_filter`

Description:

  • Event ID 1: Process creation: — The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier. The hash is a full hash of the file with the algorithms in the HashType field.
  • comsvcs.dll: — The comsvcs.dll is an executable file on your computer’s hard drive. This file contains machine code. If you start the software COM+ Services on your PC, the commands contained in comsvcs.dll will be executed on your PC. For this purpose, the file is loaded into the main memory (RAM) and runs there as a COM+ Services process (also called a task).

Logic explanation:

Need to have a detection rule with a process name as “Rundll32” and CommandLine contains comsvcs.dll and Minidump along with the Sysmon Event ID 1.

Detection 3:

Sysmon ImageLoad EID 7 – DLL Original File name is COMSVCS.DLL and DLL Name is != comsvcs.dll and Process Name is runDLL32

Description:

  • Event ID 7: Image loaded — The image loaded event logs when a module is loaded in a specific process. This event is disabled by default and needs to be configured with the –l option. It indicates the process in which the module is loaded, hashes and signature information. The signature is created asynchronously for performance reasons and indicates if the file was removed after loading. This event should be configured carefully, as monitoring all image load events will generate a large number of events.

Logic explanation:

Need to have a detection rule with parent process name as “COMSVCS.DLL” and loading process should be “runDLL32” with a condition of loading process NOT EQUAL TO “COMSVCS.DLL” along with the Sysmon Event ID 7.

Detection 4:

Sysmon ImageLoad EID 7 – Lsass.exe loading dbghelp.dll/dbgcore.dll

Description:

Previously we have explained about Sysmon Event ID 7, dbghelp.dll, and dbgcore.dll.

Logic explanation:

Need to implement a detection rule with the process “Lsass.exe” having the DLL files:dbghelp.dll/dbgcore.dll in the command line.

Detection 5:

Few FPs limited to WerFault.exe/WerFaultSecure.exe with Callstack contains wer.dll

Description:

  • Werfault.exe is the Windows Error Reporting process of Windows 10. This tool is used by many applications to report errors. For example, if something on your computer crashes, Werfault.exe makes it possible to forward the crash report to Microsoft.
  • WerFaultSecure.exe is a file most often belongs to the product Microsoft® Windows® Operating System. and was most often developed by the company Microsoft Corporation. These files most often have descriptions of Windows Fault Reporting. 
  • wer.dll – Windows Error Reporting DLL

Logic explanation:

Need to keep track of the process WerFault.exe/WerFaultSecure.exe along with the DLL file “wer.dll”


Technique 2:via MirroDump (Rogue LSA Plugin that leaks Lsass handle to a malicious process, bypassing NtOpenProcess requirement)

  • We can detect Lsass memory duping using this tool (MirrorDump) that works by loading a DLL into Lsass via AddSecurityPackage (adds an LSA Plugin), this DLL main role is to obtain a handle to Lsass via DuplicateHandle bypassing NtOpenProcess monitoring. This handle will be used by the MirroDump hosting process to uses MiniDumpWriteDump (hooked to write output in memory stream and then zip it).
  • This will generate a behavior where lsass.exe (after loading a DLL Lsa Plugin) is accessing MirrorDump.exe (with GrantedAccess value equal to 0x40 PROCESS_DUP_HANDLE) required to duplicate a handle using DuplicateHandle. followed by creation of zip file (containing memory dump) by the same taregetImage / process.executable.
  • This can be translated to the following EQL that detects a similar Sysmon Process Access event, adding ImageLoad or File creation to the EQL as a sequence is possible but may require a noisy Sysmon configuration (ie logging all ImageLoads by Lsass.exe or Logging all file creations by any process), thus the most realistic config is to add GrantedAccess equal to 0x40 by SourceImage equal to lsass.exe to your sysmon process access configuration.

Detection Techniques:

Sysmon Process Access EID 10- SourceImage is Lsass.exe and GrantedAccess is 0x40 (PROCESS_DUP_HANDLE) and TargetImage is any and Optional CallTrace contains UNKNOWN

Splunk Rule:

process where winlog.event_id == “10” and

  /* DuplicateHandle – GrantedAccess 0x40 PROCESS_DUP_HANDLE */

winlog.event_data.GrantedAccess : “0x40” and process.name : “lsass.exe” and

 /* call coming from unknown module function within lsass memory space */

winlog.event_data.CallTrace : “?:\\Windows\\*UNKNOWN*”

Sentinel Rule:

event.category:process and event.code:”10″ and process.name :”lsass.exe” and winlog.event_data.GrantedAccess :”0x40″ and

winlog.event_data.CallTrace :*UNKNOWN*

Description:

  • When one process opens another, sysmon will log this with an event ID of 10. The access with higher permissions allows for also reading the content of memory, patching memory, process hollowing, creations of threads and other tasks that are abused by attackers. This technique has been used for access to credentials, keys and data that are in the process memory.
  • PROCESS_DUP_HANDLE (0x0040) — Required to duplicate a handle using DuplicateHandle.
  • Sysmon generates this event using ObRegisterCallbacks leveraging its driver. The main filtering fields recommended are:
    • SourceImage: File path of the source process that created a thread in another process
    • TargetImage – File path of the executable being accessed by another process.
    • GrantedAccess – The access flags (bitmask) associated with the process rights requested for the target process
    • CallTrace: Stack trace of where open process is called. Included is the DLL and the relative virtual address of the functions in the call stack right before the open process call

Logic explanation:

Need to implement a rule if the source image is “Lsass.exe” and GrantedAccess is “0x40 (PROCESS_DUP_HANDLE)” and CallTrace contains “UNKNOWN” for any TargetImage along with then Sysmon event ID 10.


Technique 2:via PssCaptureSnapShot:

  • PssCaptureSnapshot is another Windows API that lets us dump lsass process using MiniDumpWriteDump that may help us sneak past some AVs/EDRs for now.
  • The benefit of using PssCaptureSnapshot is that when MiniDumpWriteDump is called from your malware, it will not be reading lsass process memory directly and instead will do so from the process’s snapshot.
  • We can use dumper code that uses the PssCaptureSnapshot to obtain a snapshot of the lsass process. The handle that is returned by the PssCaptureSnapshot is then used in the MiniDumpWriteDump call instead of the lsass process handle.

Detection Techniques:

Detection 1:

Sysmon Process Access EID 10- two successive process accesses are performed by the same process and targeting two different instances of LSASS (2 unique pid)

Description:

Sysmon Event ID – 10 has been already updated previously.

Logic explanation:

Identifies suspicious access to an LSASS handle via PssCaptureSnapShot where two successive process accesses are performed by the same process and target two different instances of LSASS. This may indicate an attempt to evade detection and dump LSASS memory for credential access.

Detection 2:

Audit Security EID 4688- Isass.exe process creation with parent process set to Isass.exe (Lsass clone from which the memory dump is taken)

Description:

Security Event ID –  4688 : This event generates every time a new process starts.

Logic explanation:

Create a rule logic with the Event ID – 4699 where the process & parent process is lsass.exe


Technique 3:via PPLDump (bypass Lsass PPL from usermode):

Detection:

Look for rogue WinTcb Protected processes (e.g. services.exe, csrss.exe, smss.exe with unusual parent process and accessing Lsass.exe) (Correlation of sysmon Process Creation with Process Access)

Description:

  • Windows 8.1 introduced the concept of Protected Process Light (PPL), which enables specially-signed programs to run in such a way that they are immune from tampering and termination, even by administrative users. The goal is to keep malware from running amok — tampering with critical system processes and terminating anti-malware applications.
  • At a high level, the exploit is a cache poisoning attack where an attacker can add a DLL to the KnownDlls cache — a trusted list of Windows DLLs. KnownDlls is only writable by WinTcb processes, which is the highest form of PPL… but a bug in the implementation of the DefineDosDevice API allows attackers to trick CSRSS, a WinTcb process, into creating a cache entry on their behalf.
  • KnownDlls is trusted by the Windows loader, so no additional security checks are performed as KnownDlls are loaded, even inside PPL processes. After poisoning the cache, the attacker launches a protected process which ends up loading their DLL and executing its payload.
  • Because this exploit enables attackers to inject a DLL of their choosing into a PPL process, they can perform any action with WinTcb privileges.
  • The first public exploit POC that we’re aware of is the recently-releasedPPLDump, a tool that can dump any PPL process, such as LSASS in RunAsPPL mode.
  • With the exploit code public, we expect that offensive tools will quickly capitalize on it, running payloads as WinTcb PPL. This will enable them to:
    • Dump enterprise credentials, even when LSASS is hardened to run as PPL.
    • Terminate or silently disable PPL processes such as security products.
    • Run entire implants as WinTcb PPL processes. These implants cannot be inspected or terminated by user-mode security products. Microsoft restricts security products to AntiMalware PPL, which is less-privileged than WinTcb.
    • Inject code into existing PPL processes. Imagine running Cobalt Strike’s beacon payload inside of Windows Defender.

Logic explanation:

Create a rule based on WinTcb Protected processes like services.exe, csrss.exe, smss.exe with unusual parent process and accessing Lsass.exe.


Technique 4:via Direct Syscall (bypass NtOpenProcess hooking if any):

Detection:Look for sysmon Process Access targeting Lsass and Call Trace contains only UNKNOWN

Description:

  • We have the NtOpenProcess hook. While using MiniDumpWriteDump for lsass attack, even though we use a stolen handle on LSASS, the internals of MiniDumpWriteDump will open an additional handle to the LSASS process. This of course will trigger event ID 10 in SysMon.
  • Internally, MiniDumpWriteDump eventually triggers a call to RtlQueryProcessDebugInformation which is where the source of the additional handle comes from.
  • So in our hook function we simulate a call to NtOpenProcess by duplicating the stolen handle that we already have for lsass. This will mean no real NtOpenProcess is called and no event ID 10 is generated from SysMon where MirrorDump is the source process and lsass is the target process.

Logic explanation:

Create a rule based on Sysmon ID 10 (Process Access) where the TargetImage is Lsass and the call trace contains the result as “UNKNOWN”.


Technique 5: Generic via Reading Lsass Process Memory:

Detection 1:Get Super noisy if not scoped:

  • Permission includes VM READ+ UNKNOWN in CALLTRACE (unbacked module) + Short Call Trace
  • Unusual Source Process (i.e.Lolbin such as RunDLL32, PowerShell, Regsvr32, MSBuild.exe etc.) + VM READ
  • 4703 (SeDebugPrivilege Enabled followed by Sysmon Process Access to Lsass) with VM_READ permission

Detection2:False Positive Champs:

  • Msiexec.exe /v, procexp, procmon, ProcessHacker, WmiPrvse.exe, any from program files + signed and parent is services.exe
  • Rund1132 is a good signal, one rare common FP is rundll32 with cmdline “zzzzInvokeManagedCustomActionOutOfProc” and parent msiexec.exe

Conclusion:

With the existing techniques, blue teams can spot attacks that dump OS credentials, and the most advanced techniques can evade antivirus software. Attackers are obtaining the credential dump using new open technologies. To set these rules with LSASS and Windows events, additional effort is needed.

Previous articleWEBBFUSCATOR Campaign New TTPS – Detection & Response
Next articleThe latest Windows zero-day vulnerability allows JavaScript files to skip security warnings

LEAVE A REPLY

Please enter your comment!
Please enter your name here