LetMeowIn – Analysis of a Credential Dumper | Binary Defense
By ARC Labs contributors, John Dwyer and Harold Tabellion
In April 2024, security researcher Meowmycks released a LetMeowIn which was designed to harvest credentials from the LSASS process on Microsoft Windows systems. In this blog, ARC Labs will provide an overview of how LetMeowIn works and provide some detection guidance for defenders.
Dumping credentials from LSASS is nothing new and has been a part of offensive and criminal tradecraft for many years. At its core, LetMeowIn uses MiniDumpWriteDump function from dbghelp.dll to create a memory dump of the LSASS process, but instead of writing the dump directly to disk, it employs MINIDUMP_CALLBACK_INFORMATION to manipulate the dump in memory first, enabling the tool to manipulate the dump data in memory before writing it to disk. LetMeowIn touts some additional stealth and evasion capabilities that enable it to bypass common endpoint security products such as CrowdStrike Falcon and Microsoft Defender. ARC Labs was able to confirm that LetMeowIn was able to dump LSASS while multiple security endpoint solutions were running.
Analyzing the code of LetMeowIn as well as the supplied documentation, LetMeowIn uses various methods to avoid detection by endpoint security tools such as obfuscating Windows API functions, indirect syscalls, tampering with Event Tracing for Windows, indirect LSASS handles, and anti-analysis of dump files.
Obfuscation
In the following code snippet, the library “dbghelp.dll” is split into an array of single characters and read into the variable “lldplehgbd”. The same obfuscation technique is used for “minidumpwritedeump” which is stored in a variable named dwdm. LetMeowIn leverages this same obfuscation technique in different areas for common keyword detections.
Additionally, LetMeowIn obfuscates WinAPI Functions by storing the function names by encoding the function names with Unicode Code Points and storing the values in an array. When the array is called, LetMeowIn calls a function named unASCIIme which decodes the array to WinAPI function name as a string.
For example, “ISQtN[] = { 81, 117, 101, 114, 121, 83, 121, 115, 116, 101, 109, 73, 110, 102, 111, 114, 109, 97, 116, 105, 111, 110}” will decode to “QuerySystemInformation”.
Indirect Syscalls
Indirect syscalls are a common defense evasion technique which involves designing malware to not directly invoke system calls using standard library functions or direct syscall instructions. Instead, the malware will execute system calls through an intermediary step, often involving code obfuscation or redirection. This method can involve manipulating function pointers, using inline assembly, or leveraging other forms of code indirection to invoke syscalls in a way that is not easily recognizable by standard detection mechanisms.
The following snippet is a sample of one of the indirect syscalls in LetMeowIn.
ETW Tampering
Event Tracing for Windows (ETW) is a high-performance logging mechanism provided by the Windows operating system to collect detailed system and application performance data. It is often used by endpoint security solutions to gather telemetry to aide in detection of malicious activity.
LetMeowIn has a function named Gluttony which implements a technique first documented by “acebond” which attempts to prevent ETW providers from gathering information from a process by maxing out the number of providers a single process can have. The function Gluttony leverages the EventRegister function in a loop to register providers until the maximum number is reached before any legitimate providers can be registered for LetMeowIn.
Existing LSASS Handle
As most antivirus and endpoint detection and response (EDR) solutions will detect any process attempting to open a handle to LSASS directly, LetMeowIn uses a technique introduced by SkelSec to get a copy of an existing open handle to LSASS using the NtDuplicateObject function. With an open handle to LSASS, LetMeowIn can dump the contents of LSASS to extract the credentials from the dump file.
LetMeowIn implements this technique within a function named HijackHandle which goes through the following high-level steps to hijack a process’ existing handle to the LSASS process:
- Leverages NtQuerySystemInformation with SystemHandleInformation to get a list of all open handles and their associated PIDs.
- Acquires the process ID of “lsass.exe” by searching for Event ID 4608 in the Security Event Log.
- Loop through each handle from the list obtained searching for processes which have an existing open handle to LSASS.
- For each identified handle’s PID, use OpenProcess with PROCESS_DUP_HANDLE privilege to open the process.
- Use NtDuplicateObject to duplicate the handle from the target process into the LetMeowIn.
- Use NtQueryObject on the duplicated handle to determine its type (e.g., process, thread, file).
- If the handle is a process handle, LetMeowIn will proceed with accessing LSASS and generate the dump file.
Anti-analysis for Dump Files
Before the dump file is written to disk, LetMeowIn runs a function called GenerateInvalidSignature to corrupt MDMP signature of the file. This prevents the file being analyzed by common analysis tools to confirm if the dump file contains credentials. The LetMeowIn project contains a python script which restores the proper file signature enabling the credentials to be extracted using tools such as Mimikatz.
Detection Opportunities for LetMeowIn
- Process Creation (4688/Sysmon 1):
- Often the simplest solution is the best one. Auditing process creation events for “LetMeowIn.exe”, although defenders should be aware that the process name is easily modified.
- Enable logging of process creation events (Event ID 4688). Sysmon can be configured to log these as Event ID 1, capturing critical details about newly created processes.
- Image Load (Sysmon 7) for dbghelp.dll:
- Monitor for the loading of dbghelp.dll which generates a Sysmon Event ID 7. Note that the binary could be built statically to avoid this event, so absence of this event does not rule out suspicious activity.
- Querying Event Log for 4608:
- Look for processes querying the event log for Event ID 4608, which can be used to obtain the PID of lsass.exe. This event signifies a system audit policy change and includes lsass.exe’s process ID.
- Processes with high volume calls to NtTraceControl
- LetMeowIn registers an event provider repeatedly until the maximum number of providers for a process is reached so querying for processes with 2048 providers will not yield the proper results. Instead, defenders can monitor for high volume syscalls to NtTraceControl by a single process.
- Auditing Handle Manipulation (4690, 4658, 4656 events):
- Enable auditing for handle manipulation to capture events such as:
- Event ID 4690: Handle duplicated.
- Event ID 4658: Handle closed.
- Event ID 4656: Handle opened.
- These events can be correlated to trace actions on lsass.exe. Specifically, Event ID 4690 with ProcessID=4 and SubjectUserSid=S-1-5-18 (Local System account) is notable. Correlate the SourceProcessId from this event with ProcessId and TargetProcessId from other events to build a comprehensive activity profile.
- Enable auditing for handle manipulation to capture events such as:
- Monitoring Registry Access:
- Monitor interactions with the registry key HKLMSOFTWAREMicrosoftWindows NTCurrentVersionMiniDumpAuxiliaryDlls. Set a System Access Control List (SACL) restricted to the SYSTEM account to capture access attempts.
- Enable Object Access auditing to generate events like:
- Event ID 5656: Object accessed.
- Event ID 4663: Attempted access.
- Event ID 4658: Handle closed.
- Creating a Memory Dump:
- The memory dump is typically written to C:tempdebug.dmp. Watch for file creation in this location, though the path can be easily changed in the code.
- Be aware that the dump file’s header is randomized, negating simple signature-based detection.
- Process Creation for Pause Command:
- Monitor for another process creation event (4688/Sysmon 1) with the command line C:Windowssystem32cmd.exe /c pause. This results from the system(“pause”) command, but could be removed to avoid detection.
Implementation and Monitoring Strategy
- Enable and Configure Auditing:
- Set up Windows to log process creation events (4688) and configure Sysmon for enhanced monitoring.
- Enable handle manipulation auditing to log events 4690, 4658, and 4656.
- Correlate Events:
- Use scripts or SIEM tools to correlate ProcessID, SourceProcessId, and TargetProcessId across relevant events to track activities associated with lsass.exe.
- Monitor Registry Access:
- Apply a SACL on HKLMSOFTWAREMicrosoftWindows NTCurrentVersionMiniDumpAuxiliaryDlls for SYSTEM-only access.
- Enable Object Access auditing to capture registry access events (5656, 4663, 4658).
- Detecting Memory Dumps:
- Monitor the predefined dump file location and employ heuristics or behavioral analysis to identify memory dump creation attempts.
- Hexadecimal Conversion:
- Utilize tools/scripts to convert hexadecimal PIDs to decimal for event correlation.
For more information about how Binary Defense can deliver Managed Detection and Response or Threat Hunting services that can identify LetMeowIn activity, contact us to set up a follow on conversation.
Source link
lol
By ARC Labs contributors, John Dwyer and Harold Tabellion In April 2024, security researcher Meowmycks released a LetMeowIn which was designed to harvest credentials from the LSASS process on Microsoft Windows systems. In this blog, ARC Labs will provide an overview of how LetMeowIn works and provide some detection guidance for defenders. Dumping credentials from…