Introduction

Dear Professionals, welcome back to “The Road to CRTP Blog” series! In our previous post, we explored Lateral Movement – PowerShell Remoting., let’s shift our attention to Lateral Movement – Mimikatz.

Let’s continue this exciting journey towards CRTP success!

Mimikatz

Once we gain administrative access to remote machines, the next critical step is often credential extraction. And no discussion about credential extraction is complete without mentioning the legendary tool: Mimikatz.

Mimikatz can be used to dump credentials, tickets, and many more interesting attacks!

The Two Eras of Windows and Active Directory Security

Mimikatz’s release in 2012 marked a turning point in the world of Windows and Active Directory (AD) security. There are essentially two eras of security in this domain:

1. Before Mimikatz: Credential theft and advanced attacks like Credential Dumping, Golden Tickets, and Kerberos Constrained Delegation (CDC) injection were largely theoretical. These techniques were known within research circles but remained inaccessible to most attackers.
2. After Mimikatz: Mimikatz brought these attacks to the masses, turning theoretical exploits into practical and widely used techniques. This forced Microsoft to step up its security game, leading to significant advancements in Windows and AD security mechanisms.

Why Mimikatz Stands Out

Mimikatz is not just a tool; it’s a revolution. It made complex attacks easy to execute, enabling penetration testers, red teamers, and attackers alike to exploit critical vulnerabilities in Windows environments.

Its impact is so profound that it exists in multiple forms:

• Executable Version: The standard tool used for credential extraction.
• PowerShell Port: Known as Invoke-Mimikatz, this version allows seamless integration with PowerShell environments, making it even more versatile for use in penetration testing labs and real-world scenarios.

The Legacy of Mimikatz

Mimikatz didn’t just expose vulnerabilities — it reshaped how the industry views Windows security. It highlighted critical gaps and forced Microsoft to address them, leading to innovations like Credential Guard, Protected Users Group, and improvements in Kerberos ticket handling.

Advanced Credential Extraction Techniques

Credential extraction is a critical step in post-exploitation, and tools like Mimikatz have revolutionized the process. Over time, various tools and methods have emerged, each offering unique approaches to extracting credentials, especially from the LSASS (Local Security Authority Subsystem Service) process.

Mimikatz and Its Variants

Mimikatz remains the go-to tool for credential dumping. However, there are several variants and adaptations that cater to different environments and bypass detection mechanisms. Here are some key methods and tools for credential extraction:

1. Dump Credentials on a Local Machine Using Mimikatz

The original Mimikatz tool can directly dump credentials with commands such as:

Invoke-Mimikatz -Command '"sekurlsa::ekeys"'

2. SafetyKatz

A C#-based variant of Mimikatz, SafetyKatz, introduces additional stealth by creating a minidump of LSASS and using a PE Loader to execute Mimikatz functionalities.

SafetyKatz.exe "sekurlsa::ekeys"

3. SharpKatz

Another C# implementation of Mimikatz functionalities, SharpKatz offers similar capabilities in a lightweight format.

SharpKatz.exe --Command ekeys

4. Dumpert

Developed by Outflank, Dumpert uses direct system calls and API unhooking to dump LSASS memory while avoiding detection by security tools.

rundll32.exe C:\Dumpert\Outflank-Dumpert.dll,Dump

5. PyPyKatz

A Python-based implementation of Mimikatz, pypykatz is particularly useful for scriptable environments and cross-platform attacks.

pypykatz.exe live lsa

6. comsvcs.dll

A native Windows DLL, comsvcs.dll, can be used to generate an LSASS dump. This method often bypasses basic security controls.

tasklist /FI "IMAGENAME eq lsass.exe"
rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump <lsass process ID> C:\Users\Public\lsass.dmp full

7. From a Linux Attacking Machine

Using tools like impacket and physmem2profit, attackers can remotely expose an entire system’s RAM and extract credentials. Notably, physmem2profit is known for evading even advanced security solutions like Microsoft Defender for Endpoint (MDE).

8. Minidump with Mini.Net

The mini.net tool employs a custom implementation of the WriteDump API, providing a stealthy way to dump LSASS memory without triggering MDE detections.

Each of these tools and techniques demonstrates the evolving landscape of credential extraction. While Mimikatz remains the cornerstone, its variants and alternative methods like Dumpert, PyPyKatz, and SafetyKatz highlight the creativity and adaptability required to bypass modern security defenses.

Understanding LSASS

Credential extraction from the LSASS process (Local Security Authority Subsystem Service) has long been a critical focus for attackers and penetration testers. However, evolving security measures, such as Endpoint Detection and Response (EDR) solutions, have made interacting with LSASS increasingly risky and detectable.

What is LSASS?

Think of LSASS as the credential broker on every Windows machine. It is responsible for managing authentication, including processing user logins, validating access tokens, and handling single sign-on. Any authentication activity on a Windows machine will leave traces in the LSASS process, making it a goldmine for credentials.

LSASS holds sensitive information such as:

• Usernames and passwords
• Kerberos tickets
• NTLM hashes

However, due to its critical role, EDR solutions heavily monitor LSASS, making direct interaction with it risky unless absolutely necessary.

Why Avoid LSASS (If Possible)?

While LSASS is a valuable target, it’s no longer the first choice due to:

1. High Risk of Detection: EDRs are finely tuned to detect suspicious interactions with LSASS.
2. Alternative Locations for Credentials: Credentials are also stored in other, less monitored locations, making them safer targets for extraction.

Where Else Can You Find Credentials?

1.DPAPI (Data Protection API):

• Browser cookies, saved passwords, and encrypted data in the Windows environment are often protected by DPAPI.
• This has led to the phrase: “The browser is the new LSASS.”
• DPAPI is far less monitored by EDRs, making it an excellent target for credential extraction.

2. Credential Vault:

• Stored credentials for both local and domain accounts can be extracted from the Windows Credential Vault.

3. LSA Registry and SAM Hive:

• The LSA registry key and the SAM Hive (Security Account Manager) contain sensitive authentication data, such as password hashes.
• These are implemented in tools like Mimikatz, which can extract the data with minimal detection risk.

Are Credentials Still Available in LSASS?

There is often speculation that Microsoft has removed credentials from LSASS to improve security. However, this is unlikely because:

1. System Architecture Dependency: Windows authentication relies on SSPs (Security Support Providers) that interact with LSASS for credential validation.
2. Practical Necessity: LSASS must store credentials in memory because they are actively used during authentication processes.

Unless Microsoft fundamentally changes how Windows authentication works, LSASS will continue to store credentials in memory, making it an inevitable target for extraction.

In controlled environments, such as penetration testing labs, LSASS is frequently used for credential extraction due to the practicality of learning and simulating real-world attacks. Therefore, despite the risks in production environments, we will continue to use LSASS repeatedly for educational purposes in the LAN setting.

Replaying Credentials in Active Directory

Once you’ve obtained credentials through various means, the next step is to replay them to achieve lateral movement or escalate privileges in an Active Directory (AD) environment. However, the method you choose to replay these credentials matters greatly, especially from an operational security (OpSec) standpoint.

Why Use AES Keys Over NTLM Hashes (RC4)?

When replaying credentials in a domain, it’s highly recommended to use AES keys rather than RC4 (NTLM hashes). Here’s why:

1. Detection by Security Tools

• Tools like Microsoft Defender for Identity (MDI) are designed to detect anomalies in authentication behavior.
• MDI observes domain traffic for 30 days during a learning phase, where it establishes what “normal” looks like in your environment.
• Normally, Kerberos tickets (TGTs and TGS) use AES encryption by default (since Windows Server 2008).

If you replay a Kerberos ticket with RC4 (NTLM hash), MDI will flag it as an encryption downgrade, since this behavior deviates from the observed normal traffic.

2. Anomaly Detection and Reporting

When an RC4-encrypted Kerberos ticket appears in the network:

• It’s seen as an anomaly, as RC4 is no longer the default encryption mechanism.
• MDI (or similar tools) will raise alerts and potentially disrupt your operation by reporting the unusual activity.

3. OpSec Benefits of AES

• AES is far more OpSec-friendly because it blends with normal domain activity.
• Since it’s the default encryption protocol for Kerberos authentication in Windows environments, using AES makes your activities harder to detect.
• Unless you absolutely cannot acquire the AES keys, avoid using RC4 (NTLM hashes).

How AES Became the Default

Since Windows Server 2008, Kerberos tickets in Active Directory environments use AES encryption by default. Unless explicitly configured to allow RC4 for backward compatibility, AES is the go-to method for encryption across:

• Ticket-Granting Ticket (TGT)
• Ticket-Granting Service (TGS)

This change ensured stronger security for AD authentication processes, aligning with modern encryption standards.

Credential Replay Attacks Techniques

When it comes to credential replay attacks in Active Directory environments, two common techniques are Pass-the-Hash (PtH) and Over Pass-the-Hash (OPtH). Both methods aim to leverage credentials for lateral movement and privilege escalation, but they operate differently in terms of scope and implementation.

Pass-the-Hash (PtH)

What Is It?

• Pass-the-Hash is a technique used to authenticate with NTLM hashes without knowing the plaintext password.
• It is primarily used for local accounts or accounts where NTLM authentication is accepted.
• For non-Domain joined machines

How It Works:

1. Obtain the NTLM hash of the target account (often from tools like Mimikatz).
2. Use the NTLM hash to authenticate to other systems without cracking the password.
3. Typically applied to local administrator accounts.

Use Case:

• Target: Local accounts or systems using NTLM authentication.
• Example: A local administrator hash is replayed to access another system within the network.

Over Pass-the-Hash (OPtH)

What Is It?

• Over Pass-the-Hash is an advanced version of PtH where Kerberos authentication is leveraged instead of NTLM.
• It uses AES keys (or optionally NTLM hashes) to request a Kerberos Ticket Granting Ticket (TGT) from the Domain Controller.
• For Domain joined machines

How It Works:

1. Extract AES keys (or NTLM hashes) for a domain account using tools like Mimikatz.
2. Use the extracted credentials to request a TGT from the Domain Controller.
3. With the TGT, access services across the domain via Kerberos.

Use Case:

• Target: Domain accounts in an Active Directory environment.
• Example: Using extracted AES keys to generate a Kerberos TGT ticket for accessing domain resources.

Why Over Pass-the-Hash is Superior

1.OpSec-Friendly:

• AES keys blend with legitimate traffic, making it less likely to trigger anomaly-based detection tools like CrowdStrike Identity Protection or Microsoft Defender for Identity.
• NTLM hashes, by contrast, can trigger alerts as they are often seen as legacy or anomalous.

2. Wider Access:

• Over Pass-the-Hash allows access to domain resources via Kerberos, offering greater flexibility compared to NTLM’s limited scope.

3. Avoiding Detection:

• Modern tools like CrowdStrike Identity Protection and Microsoft Defender for Identity heavily monitor for NTLM activity or encryption downgrades. Using AES keys avoids creating anomalies in authentication patterns.

Executing Over Pass-the-Hash

Over Pass the hash (OPTH) generate tokens from hashes or keys. Needs elevation (Run as administrator)

Using Mimikatz:

Invoke-Mimikatz -Command '"sekurlsa::pth /user:Administrator /domain:north.sevenkingdoms.local /aes256:<aes256key> /run:powershell.exe"'

Using SafetyKatz:

SafetyKatz.exe "sekurlsa::pth /user:administrator /domain:north.sevenkingdoms.local /aes256:<aes256keys> /run:cmd.exe" "exit"

Key Details:

• Tools: Both commands start a new process (PowerShell or cmd) using the specified credentials.
• Logon Type: The process runs with Logon Type 9, also known as RunAs /netonly.

What Happens in a Logon Type 9 Process?

Logon Type 9: Interactive Logon for Network Resources

• Local Resource Access:
  If you run a command like whoami within the new process, it will still show the current user (e.g., a local user like “student”). This is because Logon Type 9 does not replace the local session’s credentials.
• Remote Resource Access:
  When accessing remote resources (e.g., file shares, remote servers), the new credentials (e.g., Administrator with AES256 key) are used. This allows the process to interact with domain resources as the impersonated user.

Key Difference from Logon Type 3:

• Logon Type 3 (Network Logon) is typically used for direct network access (e.g., remote desktop, SMB connections). It does not create an interactive session on the local machine.
• Logon Type 9, on the other hand, creates a local process that appears as the original user but uses new credentials for network-only interactions.

Using Rubeus for Over Pass-the-Hash

The Rubeus tool can be used for Over Pass-the-Hash (OPtH) to replay credentials.

1. Without Spawning a New Process

Rubeus.exe asktgt /user:administrator /rc4:<ntlmhash> /ptt

Details:

• Replaces Kerberos tickets in the current session.
• No elevation required (does not need “Run as Administrator”).

2. Spawning a New Process

Rubeus.exe asktgt /user:administrator /aes256:<aes256keys> /opsec /createnetonly:C:\Windows\System32\cmd.exe /show /ptt

Details:

• Starts a new process (cmd.exe) with Kerberos authentication.
• Requires elevation (must run from a high-integrity process).

.

create a process with a logon type of 9 in order to request Kerberos tickets as the test user:

rubeus.exe asktgt /user:student98 /password:'redacted' /domain:dollarcorp.moneycorp.local /dc:dcorp-dc.dollarcorp.moneycorp.local /createnetonly:c:\windows\system32\windowspowershell\v1.0\powershell.exe /show

.

.

---

DCSync Technique

DCSync is a stealthy and powerful technique used to extract credentials from a domain controller by leveraging Active Directory’s replication process. Here’s a concise breakdown:

How DCSync Works

• Replication Service:
  Active Directory uses replication to synchronize data across domain controllers.
• DCSync Leverages Replication:
  Instead of executing commands or injecting code on the Domain Controller (DC), the attacker simulates a legitimate replication request.
• Result:
  If the attacker has sufficient privileges, the DC responds with the requested credentials.

Execution Example

1. Using Mimikatz:

Invoke-Mimikatz -Command '"lsadump::dcsync /user:us\krbtgt"'

2. Using SafetyKatz:

SafetyKatz.exe "lsadump::dcsync /user:us\krbtgt" "exit"

Requirements

• Permissions:
  By default, only Domain Admins and Domain Controllers have the necessary permissions to replicate credentials.
• Target Credentials:
  Typically used to extract hashes for sensitive accounts like krbtgt (used to forge Golden Tickets).

Key Features of DCSync

• Silent by Design:
  Does not require code execution on the Domain Controller.
• Privilege Dependency:
  Requires an account with replication rights.
• High Alert Risk:
  Tools like Microsoft Defender for Identity (MDI) generate high-severity alerts for DCSync activities.

DCSync is a technique to “ask nicely” for credentials from the DC without running commands or code on the DC itself. It requires appropriate privileges but is detected by advanced monitoring tools. Proper opsec is critical when using DCSync.

Thank you for taking the time to read my blog. Wishing you a joyful learning experience ahead!

.

here is the introduction