IRON GIANT: When The Vault Becomes The Victim

IRON GIANT: When The Vault Becomes The Victim

Speakers: Erik Egsgard, Principal Security Developer, Field Effect

Conference: OffensiveCon

YouTube: https://www.youtube.com/watch?v=2ytQDhLSDMg

Overview

In the realm of Windows security, the Local Security Authority Subsystem Service, or LSASS, stands as a formidable guardian, often dubbed the "Iron Giant" for its critical role in managing authentication, credential storage, and policy enforcement. For years, the prevailing assumption within the security community has been that LSASS, holding the keys to the kingdom, is exceptionally well-hardened, its interfaces meticulously audited and largely impervious to novel attacks. Erik Egsgard, a Principal Security Developer at Field Effect, challenged this deeply ingrained belief in his OffensiveCon talk, "IRON GIANT: When The Vault Becomes The Victim," revealing a surprisingly vast and underexplored attack surface.

Egsgard's research meticulously mapped out multiple distinct vulnerabilities across a mix of legacy and modern interfaces, demonstrating that even the most critical components of Windows security are not immune to sophisticated bug hunting. His findings span remote and local RPC services, Security Support Providers (SSPs), and client protocols where outbound connections can be induced. The presentation offered a compelling counter-narrative to the notion of LSASS's unassailability, exposing critical denial-of-service and heap corruption vulnerabilities that underscore the need for continuous scrutiny of even the most fundamental operating system components.

Background

▶ Watch: Challenging the assumption of LSASS being hardened (0:00)

LSASS is the bedrock of Windows security, responsible for fundamental operations such as user authentication, password policy enforcement, and the secure storage of sensitive credentials. Given its pivotal role, LSASS is a frequent target for attackers seeking to extract credentials, most famously through tools like Mimikatz that dump its memory. However, Egsgard points out that while memory dumping techniques are widely discussed, the actual interfaces—the "doors to the vault"—through which external processes interact with LSASS have been largely considered hardened and bug-free. This perception has led to a blind spot in vulnerability research, focusing on post-exploitation memory access rather than pre-exploitation interface flaws.

Egsgard's research aimed to bridge this gap by systematically exploring LSASS's diverse interaction boundaries. He delineated three primary attack surfaces: local inter-process communication via ALPC (Advanced Local Procedure Call) and local RPC to services like the SSPI server; remote interaction through various remote RPC endpoints; and scenarios where LSASS itself acts as a client, initiating outbound network connections to external servers. This comprehensive approach allowed for the discovery of vulnerabilities that had previously gone unnoticed, challenging the long-held assumption of LSASS's robust security. It's important to note that Egsgard explicitly scoped his research to non-isolated LSASS processes, intentionally excluding environments protected by Credential Guard or hypervisor isolation, which employ additional layers of defense.

Key Findings

▶ Watch: Overview of LSASS attack surface boundaries (local, network, client) (2:00)

Egsgard's research unveiled a series of significant vulnerabilities within LSASS, demonstrating that its interfaces are far from bug-free. These findings highlight both remote and local attack vectors, leading to denial-of-service or memory corruption:

• Remote Denial of Service (DoS) via LDAP Client Referral Recursion: By leveraging an unauthenticated Netlogon RPC method, attackers can force domain controllers to initiate outbound LDAP queries. A malicious server can then respond with self-referential referrals, causing LSASS to spawn thousands of recursive threads, leading to CPU exhaustion and eventual process crash.
• Remote Denial of Service (DoS) via LDAP Client Memory Amplification: Building on the referral mechanism, Egsgard discovered an inefficient array growth routine in the LDAP client. Combined with the ability to force a TCP fallback for referrals, a 64MB malicious response containing millions of empty strings could trigger hundreds of thousands of reallocations and gigabytes of data copying, resulting in the LSASS process hanging for hours or crashing.
• Remote Unprivileged Denial of Service via LSA RPC Access Check Bypass: An incomplete access check in the LsaSetSecurityObject RPC endpoint on domain controllers allows any unprivileged domain account to bypass permission verification. By setting specific security descriptor flags (like the label flag), an attacker can modify the Mandatory Integrity Label (MIL) of critical policy objects, effectively locking out legitimate system processes and causing a domain-wide denial of service.
• Local Heap Corruption via Negotiate Extensions SSP (TOCTOU): A Time-of-Check Time-of-Use (TOCTOU) vulnerability was identified in the Negotiate Extensions SSP related to how authentication data is copied and validated. A race condition allows a malicious local client to manipulate structure lengths, leading to an integer overflow during allocation and a massive buffer overflow within the LSASS process.
• Local Heap Corruption via CredSSP (Integer Overflow): Within the CredSSP (Credential Security Support Provider), specifically when handling smart card logons (submit type 13), an integer overflow vulnerability was found. An attacker-controlled CSPDataLength value can cause a tiny buffer to be allocated, followed by a memory copy operation using the original, massive length, resulting in nearly 4GB of heap corruption within LSASS.

These findings collectively underscore that LSASS's extensive attack surface, encompassing various RPC services and client-side logic, remains a fertile ground for discovering critical vulnerabilities, contrary to common assumptions.

Technical Deep Dive

▶ Watch: Forcing LSASS to make outbound LDAP queries (3:15)

Egsgard's talk provided a granular look into the mechanisms behind each vulnerability, showcasing the intricate details that allowed these critical flaws to manifest.

The journey began with client-side vulnerabilities, stemming from the observation in the "LDAP Nightmare" blog post by SafeBreach. This research highlighted that hitting an unauthenticated Netlogon RPC interface endpoint, specifically GetDcName, could force Windows domain controllers to make outbound LDAP queries to an attacker-controlled server. Egsgard capitalized on this, noting that client-side network code is historically less hardened than server code.

The first bug, LDAP Client Referral Recursion, exploited the CLDAP (Connectionless LDAP) protocol, typically used for fast, stateless domain controller discovery over UDP port 389. When a legitimate LDAP server cannot fulfill a query, it can return a referral, directing the client to another server. Egsgard's malicious server would respond with a referral pointing back to itself. This triggered a recursive chain: LSASS would make a local RPC call to GetDcName to resolve the new server, spawning a new thread for an LDAP query. Each subsequent response containing a self-referral would repeat this process. Crucially, each thread would block until the next completed, and response messages were kept in memory. With no checks for already processed or duplicate referrals, a single initial packet quickly led to over 6,000 threads spinning up inside LSASS. This massive thread creation exhausted CPU resources, denying service to the entire domain, and if left unchecked, would eventually crash LSASS completely. To maximize impact, Egsgard padded response packets with 512 bytes, staying within UDP size limits.

The second client-side issue, LDAP Client Memory Amplification, was discovered by examining how LSASS processes arrays of values from LDAP responses. The routine for growing destination arrays was inefficient: it doubled the array size until 256 entries, then added a fixed 0x100 (256) entries at a time. This becomes problematic for large arrays, as it necessitates continuous reallocations, copies, and frees. Furthermore, an empty string, which is only two bytes when ASN.1 encoded, required 24 bytes of memory storage in the client due to alignment requirements. While UDP payload limits initially constrained the impact, Egsgard found that when processing referrals, the client code would fall back to TCP. This allowed for larger responses. By sending a 64MB response composed of 32 million empty strings, a relatively powerful server could be made to hang for four solid hours. This single packet processing involved over 300,000 reallocations and copies, with the final data size copied around three-quarters of a gigabyte. Multiple concurrent requests could make the server totally unresponsive, leading to an LSASS crash.

Moving to remote RPC interfaces, Egsgard focused on those exposed only on domain controllers, anticipating less scrutiny. He uncovered a critical flaw in the LSA RPC interface, used to manage security policies. While most sensitive endpoints require authentication, the LsaSetSecurityObject function, which sets security descriptors on policy objects, presented an opportunity. This function typically takes an object handle, a flags field, and the security descriptor payload. LSASS usually performs an access check by converting the flags field into a DesiredAccess value, which is then compared against the user's permissions. The vulnerability lay in an incomplete conversion: the logic only checked for GroupOwner, DACL, or SACL flags, completely ignoring others like Backup or Label flags. If a request was sent with only these unverified flags set, the DesiredAccess value would evaluate to zero. A zero DesiredAccess value causes the internal access check function to succeed, allowing the call to proceed to the kernel's RtlSetSecurityObject. Crucially, because no impersonation was performed, the kernel validated the request against the SYSTEM account, permitting the modification.

The impact of this LSA RPC flaw centered on the System Access Control List (SACL), specifically the Mandatory Integrity Label (MIL). The MIL defines an object's inherent trust level (Low, Medium, High, System), and Windows enforces a strict hierarchy: a process with a lower integrity level cannot access an object with a higher one, regardless of standard DACL permissions. By exploiting the access check bypass, an unprivileged attacker could overwrite the MIL on core domain policy objects, elevating them to System or higher. This effectively locked out all processes running at lower integrity levels, including those of domain administrators, leading to a complete denial of service for critical domain functionalities. While the Backup flag could have allowed full control, it required the ClientToken field to be filled, which only happened if the Owner flag was set, and the Owner flag was properly checked. This fortunate oversight prevented a full domain compromise, but a remote, unprivileged DoS against a domain controller is still a significant win.

Finally, Egsgard investigated local RPC interfaces, specifically the Security Support Provider Interface (SSPI), which acts as a common interface for SSPs like NTLM, Kerberos, and TLS. He focused on SSPs used by Remote Desktop connections: Negotiate Extensions SSP and CredSSP.

The Negotiate Extensions SSP expands on the older Negotiate SSP, handling modern authentication methods. When creating a credentials handle, this SSP must copy authentication data from the user-mode client process into LSASS's memory using CopyFromClientBuffer. This manual copying opened the door to a Time-of-Check Time-of-Use (TOCTOU) vulnerability. The authentication header was copied and validated, but then copied again in the CaptureSuppliedCreds function, with re-validation. A subtle bug existed where an overflow check used 64-bit math, allowing even very large size values to pass. However, when this size was later passed to 32-bit allocation routines, it would truncate to 32 bits, triggering an integer overflow. This created a narrow window where a malicious client could rapidly flip the structure length between valid and invalid values, causing the initial validation to pass but the subsequent allocation to overflow, leading to a massive buffer overflow and memory corruption inside LSASS.

The CredSSP vulnerability also involved an integer overflow leading to heap corruption. CredSSP provides Network Level Authentication (NLA) for RDP, forcing authentication before the full RDP protocol stack is accessed. Egsgard focused on submit type 13, used for smart card logons, which involves the KrbCertificateLogon structure. The CreateKrbCertLogonBuffer function calculated an initial allocation size based on string lengths and an attacker-controlled CSPDataLength. If a very large CSPDataLength (near the 32-bit maximum) was provided, it would trigger an integer overflow, wrapping the allocation size back to a tiny number. While TSAllocate would create this tiny buffer, the subsequent memory copies would still use the original, massive CSPDataLength. Both the CredSSP and Negotiate Extensions SSP bugs resulted in nearly 4GB of overwritten data on the heap. Egsgard noted that without a way to stop these large memory copies, he assumed these were not practically exploitable for code execution, but expressed openness to being proven wrong.

Demo / Proof of Concept

▶ Watch: Unchecked recursive LDAP referral processing vulnerability discovery (6:00)

While initially not planning a live demonstration, Erik Egsgard was "sucked back in" during preparation and performed additional research, culminating in a live demo during his talk. He showcased a proof of concept, dubbed "Iron Giant V2," running on a fully patched Windows system (with the latest patches from the week prior to the conference). The demonstration successfully triggered an LSASS crash, resulting in the system displaying the critical "Your PC will automatically restart in 1 minute" message. Although a technical hiccup prevented the audience from seeing the pop-up directly on the main screen, Egsgard confirmed the crash, validating the immediate and severe impact of his findings. This live demonstration underscored the real-world applicability and potency of the discovered vulnerabilities, even against up-to-date systems.

Defensive Implications

▶ Watch: LSASS thread exhaustion demonstrated with 6,000+ threads (8:00)

The revelations from "IRON GIANT: When The Vault Becomes The Victim" carry significant defensive implications, challenging the long-standing complacency surrounding LSASS security. Defenders must re-evaluate their assumptions and adopt a more proactive stance:

• Prioritize Patching: The discovery of critical vulnerabilities in core Windows components, even on fully patched systems, highlights the ongoing necessity of timely and comprehensive patching. These bugs underscore that new attack vectors are continually being found.
• Network Segmentation and Least Privilege: Limiting network access to domain controllers is paramount. While some vulnerabilities identified by Egsgard could be triggered by authenticated users, strict network segmentation, firewall rules, and adherence to the principle of least privilege for all user accounts can reduce the attack surface for remote RPC and client-side attacks.
• Monitor Outbound Connections: Organizations should monitor domain controllers for unusual outbound LDAP queries (especially over UDP port 389) or unexpected connections to external, untrusted servers. Abnormal network activity from LSASS could indicate an attempted referral-based attack.
• Resource Monitoring: Keep a close eye on CPU utilization, thread count, and memory consumption for the LSASS process on domain controllers. Sudden spikes or sustained high usage could signal a denial-of-service attack leveraging thread exhaustion or memory amplification.
• Awareness of Integrity Levels: Understand the role of Mandatory Integrity Labels (MILs) in Windows security. While not a common attack vector, the ability to manipulate MILs for denial of service demonstrates how subtle access check bypasses can subvert fundamental security mechanisms. Defenders should ensure auditing is in place for changes to security descriptors on critical policy objects.
• Consider Credential Guard/HVCI: Although Egsgard's research deliberately excluded environments with Credential Guard and hypervisor isolation, these technologies offer significant protection by isolating LSASS and its sensitive data. For organizations seeking enhanced protection against credential theft and certain LSASS attacks, deploying these features where feasible is a strong recommendation.
• Input Validation and Secure Coding Practices: For developers, Egsgard's findings serve as a stark reminder of the importance of robust input validation, careful handling of memory allocations (especially across different bit-widths), and rigorous testing for race conditions in critical security components.

Key Takeaways

• The Windows Local Security Authority Subsystem Service (LSASS) possesses a vast and surprisingly underexplored attack surface, challenging the prevailing assumption of its impenetrable hardening.
• Client-side code within LSASS, particularly its LDAP client, is a fertile ground for critical vulnerabilities, including recursive referral-based thread exhaustion and memory amplification attacks leading to remote denial of service.
• Incomplete access checks in remote RPC interfaces (like LSA RPC) can be exploited by unprivileged domain accounts to bypass security descriptor modifications, enabling denial of service by manipulating Mandatory Integrity Labels on core policy objects.
• Local RPC interfaces, specifically Security Support Providers (SSPs) like Negotiate Extensions and CredSSP, are susceptible to classic memory corruption bugs such as Time-of-Check Time-of-Use (TOCTOU) race conditions and integer overflows during memory allocation.
• Even fully patched Windows systems are vulnerable to novel LSASS attacks, underscoring the continuous need for advanced security research and proactive defense strategies.
• Denial of service against LSASS on a domain controller can cripple an entire domain's authentication infrastructure, representing a critical impact on organizational operations.

About the Speaker(s)

Erik Egsgard is a Principal Security Developer at Field Effect, a cybersecurity company. His primary focus at Field Effect is working on their Endpoint Detection and Response (EDR) product, particularly for Windows systems. Beyond his full-time development responsibilities, Erik has a passion for bug hunting, occasionally delving into vulnerability research on the side, a pursuit that led to the compelling discoveries presented in this talk.