Welcome back, investigators!
Recently, Microsoft announced a phased plan to disable NTLM by default across Windows environments. This decision did not come out of nowhere. NTLM has long been known to suffer from structural design flaws that make it vulnerable to relay attacks, credential interception, and most notably pass-the-hash abuse. NTLM relies on static password-derived hashes that can be replayed without ever knowing the original password, which makes it attractive for hackers once a system is compromised.
With the upcoming updates rolling out through 2026, Microsoft is moving fully toward Kerberos as the primary authentication mechanism. Kerberos is significantly stronger by design, relying on time-based tickets, mutual authentication, and stronger cryptographic primitives. However, as with any complex protocol, Kerberos has its own weaknesses. Today we will explore this topic from both an offensive and defensive perspective.
Traditionally, hackers relied heavily on NTLM pass-the-hash attacks to move laterally inside a domain. Once a single domain-joined system was compromised, such as an Exchange server exploited through Proxyshell, hackers would get SYSTEM privileges. From there, extracting credentials was simple, and in many cases hackers would recover the NTLM hash of a domain administrator account. At that point, the engagement was effectively over. There was no need to crack a long or complex password because the hash itself was sufficient for authentication.
This approach only failed when accounts were placed in the Protected Users group, which prevents credential material from being cached in memory. As NTLM is phased out and protections around LSASS are tightened, the game is changing. Hackers are adapting, and defenders need to understand how. Our goal today is to walk through how hackers are pivoting to Kerberos-based techniques and, just as importantly, how defenders can disrupt lateral movement or catch attackers early in the process.
Converting NTLM Hashes to Kerberos Tickets (Over-Pass-the-Hash / Pass-the-Key)
When NTLM authentication is disabled or heavily restricted in a hardened domain, attackers often attempt to pivot toward Kerberos using NTLM-derived material. One of the classic techniques here is over-pass-the-hash, also known as pass-the-key. In this scenario, an attacker takes an NTLM hash and uses it to request a valid Kerberos Ticket Granting Ticket directly from the domain controller.
Tools such as Impacket’s getTGT.py or Rubeus are commonly used for this purpose. The NTLM hash, specifically the NT portion of it, can function as the RC4-HMAC key used in Kerberos pre-authentication. By crafting a Kerberos AS-REQ and encrypting the timestamp with this key, the attacker can sometimes convince the Key Distribution Center to issue a valid TGT. That ticket is then stored in a .ccache or .kirbi files, which can be loaded into the environment and reused for pass-the-ticket attacks against services such as CIFS, HOST, or HTTP, all without ever knowing the plaintext password.
Here is how the command looks like:
getTGT.py DOMAIN/[email protected] -hashes F6C8F436E90DE59B6B93809D36CFA80C:F6C8F436E90DE59B6B93809D36CFA80C -dc-ip
However, there is an important catch that changes the feasibility of this attack. Microsoft began shipping Kerberos RC4 hardening updates on January 13, 2026, and Enforcement mode is being phased in (updates that enable Enforcement start in April 2026, with audit removal enforcement by July 2026). Under these changes, domain controllers will assume AES-SHA1 as the default supported encryption type for accounts that do not have an explicit msDS-SupportedEncryptionTypes setting. This prevents RC4 being issued for those accounts unless RC4 is explicitly allowed on the service account. In short, over-pass-the-hash (pass-the-key) that relies on using the NT hash as an RC4 key becomes much less feasible when the KDC/account refuse RC4. Tools such as Rubeus and Impacket can request TGTs from hashes, but they succeed only when the KDC accepts the requested enctype (RC4) or when the attacker already possesses the account’s AES keys. An NTLM hash alone will not produce an AES TGT. As a result, attackers are more likely to pivot to other techniques (ticket theft from memory, silver/golden tickets, S4U abuses, etc.) or look for explicit RC4 allowances on specific accounts that were not remediated.
Auditing Kerberos encryption types through domain controller event logs, resetting passwords on high-privilege accounts to regenerate AES keys, and enforcing AES-only policies across both GPO and account attributes significantly reduces attack surface. Monitoring for unusual Ticket Granting Ticket requests, especially those using deprecated encryption types, can reveal early-stage compromise. Tools such as AdminDroid and Microsoft Defender for Identity are particularly effective at highlighting legacy authentication patterns that attackers depend on.
Memory Dump & Volatility
Dumping LSASS has become one of the most well-known credential theft techniques. For years it was trivial. An attacker could simply right-click the LSASS process in Task Manager and dump it, or use a tool like Procdump, extract credentials, and move on. Those days are largely gone.
Modern Defender and EDR solutions aggressively monitor LSASS access. Even legitimate attempts to dump the process are now flagged and blocked. Any action that targets LSASS directly is assumed to be malicious by default, and attackers are well aware of this. As a result, dumping a single process has become noisy and often ineffective unless the system is completely unmonitored.
Instead, attackers increasingly opt for full memory acquisition. By capturing the entire physical memory of a system, they avoid interacting directly with LSASS in a suspicious way. This approach is heavier and slower, as the size of the dump is roughly equal to the system’s installed RAM. Transferring the dump can take significant time, depending on network conditions. But patience is often a worthwhile tradeoff for attackers.
A memory dump can be acquired with forensic tools.
Once the memory image is acquired, tools like Volatility come into play. Newer Volatility plugins specifically target Kerberos artifacts, allowing attackers to list sessions, carve tickets from memory, and dump them in .kirbi format. These plugins often rely on Impacket under the hood and are effective when Credential Guard is not enabled.
It also relies on legitimate forensic tooling, that’s why it’s more dangerous. Products such as Belkasoft, FTK Imager, and DumpIt are trusted and allowed to perform full memory acquisition. This blurs the line between forensic investigation and credential theft, making detection more difficult.
Extraction of these tickets looks like this:
vol -p /home/kali/volatility-kerberos -s /home/kali/volatility-kerberos -f data.lime kerberos.Dump --address 0x2af64e5b930 --output /tmp
Once extracted, .kirbi files can be converted into formats compatible with Hashcat in the hope of recovering plaintext passwords, or they can be injected directly for lateral movement. Even without cracking, valid tickets often provide enough access to expand control within the domain.
From a defensive perspective, the goal is not only to prevent memory acquisition but to make any extracted artifacts useless. Enabling Windows Credential Guard is one of the most effective protections available. But keep in mind, Credential Guard doesn’t stop credential capture by keyloggers, new SSPs installed by an admin or extraction from other credential stores if those stores remain accessible.
Enforcing Protected Process Light for LSASS and enabling Defender Attack Surface Reduction rules further limits unauthorized memory access. Shortening Kerberos ticket lifetimes reduces the value of stolen tickets, and placing high-privilege accounts in the Protected Users group forces stronger encryption and eliminates delegation. When these measures are in place, attackers are often forced into far more complex and risky techniques.
PsMapExec
We have covered PsMapExec in a previous article, so we will not repeat the full walkthrough here. What matters in this context is how attackers continue to rely on PowerShell-based tooling even as detection improves. PsMapExec is a PowerShell script, and like most publicly available offensive tools, it will be flagged immediately if loaded. Skilled attackers rarely use tools straight from GitHub. Instead, they modify and obfuscate them, preserving functionality while avoiding signature-based detection. Many offensive scripts rely heavily on native Windows APIs. Because these underlying calls are legitimate, detection often depends on static signatures, keywords, or known indicators of compromise. This creates an ongoing cat-and-mouse game between attackers and defenders.
Finding a machine without active antivirus or EDR is not always easy, but it is almost always possible in large environments. Legacy systems, misconfigured servers, and overlooked infrastructure components still exist. During real-world engagements, you can sometimes find systems such as Windows Server 2003 still in active use even as late as 2025. These systems may not be valuable on their own, but they often serve as stepping stones. Once an attacker gains GUI access to unmonitored machines, their options expand significantly. PsMapExec allows attackers to extract Kerberos tickets locally or remotely, with or without credentials, depending on context.
A full guide on the use of PsMapExec was covered in a separate article. Here, our goal is to show that attackers can also extract Kerberos tickets and use them effectively for lateral movement. After loading the script, they will normally use the following options.
To acquire Kerberos tickets from the current host:
PS > PsMapExec -Method smb -Targets localhost -Module “KerbDump” -ShowOutput
To acquire Kerberos tickets from a remote host with no credentials (within the current session):
PS > PsMapExec -Method smb -Targets DC -Module “KerbDump” -ShowOutput
To acquire Kerberos tickets from a remote host with credentials:
PS > PsMapExec -Method smb -Targets DC -Username “user” -Password “password” -Module “KerbDump” -ShowOutput
Once loaded, the script parses the results, assigns variables, and makes it easy to reuse the extracted material for command execution and lateral movement.
Below is an example of command execution on the domain controller using the highest privileges, based on the Kerberos ticket that was previously extracted:
PS > PsMapExec -Target DC -Method smb -Ticket $variable -Command "whoami; hostname"
The script will store the tickets in a separate folder.
Defenders can counter this by enabling AMSI and full PowerShell script block logging, which exposes suspicious modules, encoded payloads, and in-memory execution. Restricting PowerShell through Constrained Language Mode, AppLocker, or WDAC significantly raises the bar. Most importantly, aggressively patching and segmenting legacy systems removes the footholds attackers may depend on.
Other Tools
Tools like AutoPt show how quickly attackers adapt once EDR is disabled through vulnerable drivers. It enumerates Kerberos tickets and performs Pass-the-Ticket attacks, serving as a lightweight alternative to Rubeus or Mimikatz.
It is far more common during penetration tests to find an unprotected Windows server than an unprotected user workstation. This is significantly more dangerous, as servers are typically accessed by high-value users and frequently host service accounts with elevated privileges. While placing accounts into Protected Users groups can reduce risk, many service accounts and application identities must legitimately impersonate users when accessing resources on their behalf, such as backend services connecting to databases or file servers. Protecting these accounts too aggressively can break authentication workflows, but leaving them unrestricted makes them prime targets for Kerberos abuse. Because service accounts often hold broad privileges, reducing their exposure and strictly limiting where their Kerberos tickets can be used is essential.
Summary
The move away from NTLM does not end lateral movement, but it does change its nature. As Microsoft removes weak defaults and legacy fallbacks, attackers lose the ability to rely on quick, reusable hashes and must instead understand Kerberos. Modern attacks increasingly depend on ticket behavior and configuration gaps rather than simple credential reuse.
For defenders, this shift is an opportunity. Kerberos-based abuse is harder to execute and leaves more signals behind, especially in well-instrumented environments. Strong defaults, consistent hardening, and protection of credential material will reduce an attacker’s options.
If you’d like to advance your skills in digital forensics, we recommend our Advanced Digital Forensics training. We also offer the Subscriber PRO Corporate plan. During this three-year program, we help your organization stay ahead of evolving threats by providing continuous access to high-quality educational content.
Source: HackersArise
Source Link: https://hackers-arise.com/digital-forensics-how-hackers-defeat-microsofts-2026-ntlm-patch/