ALPChecker: Detecting Spoofing/Blinding Attacks

ALPChecker: Detecting Spoofing/Blinding Attacks

Speakers: Anastasiia Kropova (MEPhI); Igor Korkin (Independent)

Conference: HITB Phuket

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

Overview

This talk, presented by Anastasiia Kropova and Igor Korkin at HITB Phuket, delves into a critical and under-addressed attack surface within the Windows operating system: the Asynchronous Local Procedure Call (ALPC) mechanism. ALPC is the foundational interprocess communication (IPC) system in Windows, enabling diverse applications, including core system components and security tools, to interact. The speakers demonstrate novel spoofing and blinding attacks that exploit the integrity vulnerabilities of kernel-mode ALPC port structures.

The core premise of the research is that while ALPC is ubiquitous and essential for system functionality, its kernel-mode structures are not routinely checked for integrity by existing Windows security solutions. This gap allows attackers, particularly those leveraging kernel drivers, to subtly manipulate ALPC connections. Such manipulation can lead to clients communicating with unintended servers, servers failing to receive legitimate messages, or even the establishment of illegal, persistent connections designed to evade detection. The work culminates in the introduction of ALPChecker, a new security tool designed to detect these sophisticated, kernel-level ALPC attacks, highlighting a significant blind spot in current Windows defenses.

Background

▶ Watch: Introduction: ALPC security and its importance (0:00)

Every application running on a Windows system operates as a process. While processes maintain a degree of isolation, they constantly require interaction for a myriad of functions, such as utilizing Dynamic Linked Libraries (DLLs), authenticating users, performing operations on behalf of users, handling input, managing threads, and interacting with the Component Object Model (COM) and Distributed COM (DCOM). The fundamental internal mechanism facilitating this crucial interprocess communication in Windows is the Asynchronous Local Procedure Call (ALPC).

ALPC serves as the backbone for transmitting messages between client and server processes, forming connections that are even present in the simplest Windows applications. Its critical role extends to various Windows security tools, including antivirus (AV) software and Endpoint Detection and Response (EDR) systems, which rely on ALPC to monitor system activity and enforce security policies. Consequently, ALPC becomes an attractive target for malicious actors. Hackers aiming to conceal ransomware attacks or other illicit activities from security systems often seek to disable or modify ALPC connections, thereby disrupting the very mechanisms designed to detect them.

The speakers conducted a comprehensive security study of ALPC to identify vulnerabilities and propose advanced improvements for protection systems. Their research specifically focused on the most complex attack vector: Windows kernel drivers. At the heart of ALPC interactions are ALPC ports, which are categorized into three primary types:

• Client Communication Port: The port used by a client process to initiate and maintain communication with a server.
• Server Communication Port: A named port maintained by the server for each active client, facilitating unique communication channels.
• Server Connection Port: A named port specified in the initial request to connect to a server. Multiple clients can connect to a single server via one or more connection ports, but client and server communication ports remain unique for each interaction.

These ALPC ports are represented in the operating system's kernel memory as ALPC_PORT structures. Each ALPC_PORT structure contains a wealth of information about the associated interaction, including a list of ports (PortListEntry), pointers to the other end of the communication (OtherEnd), various message queues (MainQueue, PendingQueue, WaitQueue, CancelledQueue, LargeMessageQueue), and the OwnerProcess. Of particular interest for this study is the CommunicationInfo field, which points to an ALPC_COMMUNICATION_INFO structure. This nested structure holds critical connection details, such as the addresses of the ConnectionPort, ClientCommunicationPort, ServerCommunicationPort, a pointer to the ConnectionDescriptorTableHandleTable, and the ConnectionCloserMessage.

The fundamental vulnerability identified is that the integrity of these kernel-mode ALPC_PORT and ALPC_COMMUNICATION_INFO structures and their connections is not routinely checked by any existing Windows security tools. This critical oversight means that direct modification of these structures, achievable only from kernel mode, can lead to the disabling of legitimate ALPC connections or the establishment of illegal, unauthorized connections.

Attacks leveraging kernel drivers are increasingly common. The speakers highlighted three popular techniques:

1. Bring Your Own Vulnerable Driver (BYOVD): Users or malware download and exploit legitimate, but vulnerable, drivers.
2. Malware Drivers Signed with Leaked/Revoked Certificates: Criminals acquire drivers signed with compromised or revoked certificates, bypassing driver signature enforcement.
3. Firmware-level Malware Implants: A more advanced threat, where malware resides in the firmware, granting deep system access.

The prevalence of such threats was underscored by citing industry reports: Ponin and Corin (2022) presented over 50 examples of attacks using these techniques, Rapid7 (2022) detailed 30 malware examples using BYOVD, and Trend Micro (2023) confirmed the growing actuality of kernel-level threats. While the concept of ALPC vulnerability was previously touched upon by the Binary Team in 2022 at LabSec and EO Party conferences, where they demonstrated attacks on WMI by disabling ALPC connections, this talk introduces novel attack types focused on direct manipulation of ALPC port structures themselves, leading to distinct spoofing and blinding scenarios.

Key Findings

▶ Watch: The fundamental ALPC kernel mode vulnerability (5:30)

The primary contribution of this research is the identification and demonstration of three novel types of spoofing and blinding attacks targeting the Windows ALPC mechanism. These attacks exploit a critical security gap: the absence of integrity checks on kernel-mode ALPC_PORT and ALPC_COMMUNICATION_INFO structures by existing Windows security tools.

The key findings are:

• Novel Attack Vectors: The speakers unveiled three distinct methods for manipulating ALPC connections at the kernel level: client port modification, server port modification, and a more complex client port modification combined with server termination. These methods allow attackers to redirect client communications, render servers unresponsive to legitimate clients, and establish covert, persistent connections.
• Kernel-Mode Vulnerability: All demonstrated attacks hinge on the ability to directly modify kernel-mode ALPC_PORT structures. This highlights that deep kernel access, typically achieved via malicious drivers, is the enabler for these sophisticated attacks. The ALPC_COMMUNICATION_INFO field within the ALPC_PORT structure was identified as the crucial target for manipulation.
• Evasion of Current Defenses: A significant finding is that current Windows security instruments lack the capability to detect or prevent these specific types of ALPC attacks. This creates a critical blind spot for security experts, allowing malicious activity to proceed undetected by standard AV and EDR solutions.
• Development of ALPChecker: To address this detection gap, the researchers developed ALPChecker, a new security tool. ALPChecker is designed to inspect the integrity of ALPC connections and port structures from kernel mode, effectively identifying all three types of demonstrated attacks. Its ability to detect inconsistencies in ALPC connections (e.g., a client connecting to a server that doesn't acknowledge the connection) proves its efficacy.
• Real-World Implications: The research underscores that by manipulating ALPC, attackers can achieve significant objectives, such as concealing ransomware by blinding security tools or establishing command-and-control channels that bypass traditional network and process monitoring. The ability to terminate blinded servers to hide attack traces further complicates detection.

In essence, the talk exposes a fundamental weakness in Windows IPC security, providing concrete examples of how it can be exploited and offering a foundational solution for detection.

Technical Deep Dive

▶ Watch: Demonstrating ALPC spoofing and blinding attacks (8:00)

The technical core of the presented research revolves around the intricate structure of Windows ALPC and the precise methods used to subvert it. ALPC operates on a client-server model, where messages are asynchronously transmitted between processes. The integrity of this communication relies heavily on the correct configuration and state of ALPC ports, which are defined by specific kernel-mode data structures.

As previously mentioned, ALPC_PORT structures reside in kernel memory and contain comprehensive information about an ALPC interaction. Key fields include:

• PortListEntry: A list entry for managing ports.
• OtherEnd: A pointer to the ALPC_PORT structure at the other end of the communication channel.
• Message Queues: Several queues (MainQueue, PendingQueue, WaitQueue, CancelledQueue, LargeMessageQueue) for managing message flow.
• OwnerProcess: A pointer to the process that owns the port.
• CommunicationInfo: A pointer to an ALPC_COMMUNICATION_INFO structure, which is the primary target for the attacks.

The ALPC_COMMUNICATION_INFO structure contains critical connection metadata:

• ConnectionPort: A pointer to the ALPC_PORT structure representing the connection port.
• ClientCommunicationPort: A pointer to the client's communication port.
• ServerCommunicationPort: A pointer to the server's communication port.
• ConnectionDescriptorTableHandleTable: A handle table for connection descriptors.
• ConnectionCloserMessage: Information related to connection termination.

The presented attacks leverage direct, unauthorized modification of these kernel-mode ALPC_PORT and ALPC_COMMUNICATION_INFO structures. Such modifications require kernel-level access, typically achieved through a malicious kernel driver. The speakers demonstrated three distinct attack scenarios using a test bench with Client 1 (C1) and Server 1 (S1) interacting via ALPC, and Client 2 (C2) and Server 2 (S2) also interacting via ALPC.

Attack #1: Client Port Modification (Spoofing/Blinding)

This attack targets the client-side ALPC_PORT structure to redirect its communication.

1. Target: The ALPC_PORT structure associated with Client C2's communication port.
2. Action: The attacker modifies the ConnectionPort value within the ALPC_COMMUNICATION_INFO structure of Client C2's communication port.
3. Manipulation: The ConnectionPort value is changed to the memory address of Server S1's connection port.
4. Result: Client C2, originally intended to communicate with Server S2, is now spoofed into connecting and sending messages to Server S1. Consequently, Server S2, C2's legitimate server, becomes blinded and no longer receives any messages from C2. This effectively hijacks C2's communication stream.

Attack #2: Server Port Modification (Spoofing/Blinding)

This attack targets a server's communication port to misdirect or blind it.

1. Target: The ALPC_PORT structure associated with Server S1's communication port.
2. Action: The attacker modifies the ConnectionPort value within the ALPC_COMMUNICATION_INFO field of Server S1's communication port.
3. Manipulation: The ConnectionPort value is changed to the memory address of Server S2's connection port.
4. Result: The specific example given in the talk was "legitimate connections between client C2 and server S1 are established and server S2 is Blended and does not receive any messages." This implies that by modifying S1's communication port to point to S2's connection port, S1 is either spoofed into facilitating a connection it shouldn't, or its own expected incoming connections are misdirected, ultimately resulting in S2 being blinded. The key takeaway is the ability to manipulate a server's internal connection pointers to achieve redirection or denial of service for other legitimate parties.

Attack #3: Client Port Modification and Server Termination (Complex Spoofing)

This is a more sophisticated, multi-stage attack designed to establish an illegal connection while actively trying to hide its traces.

1. Stage 1 (Client Spoofing): Similar to Attack #1, Client C2's communication port is modified to connect to Server S1. This establishes an initial illegal connection between C2 and S1.
2. Stage 2 (Cover-up): The now blinded Server S2 (C2's original legitimate server) is terminated. The rationale is that any logs indicating incorrect ALPC connections would only appear in the blinded server's logs. By terminating S2, the attacker attempts to remove evidence of the attack.
3. Stage 3 (Temporary Disruption): The illegal connection between C2 and S1 is temporarily broken. The ServerCommunicationPort field within Client C1's communication port structure (not C2's, potentially a typo in the transcript or a step to further obfuscate) is filled with zeros. This step might serve to temporarily clear state or create an opportunity for re-establishment without immediate detection.
4. Stage 4 (Re-establishment): The ServerCommunicationPort value within the ALPC_COMMUNICATION_INFO structure of Client C2's communication port is replaced with the address of Server S1's server communication port.
5. Result: The illegal connection between C2 and S1 is re-established and remains active, despite the termination of the original legitimate server (S2) and intermediate steps to obscure the activity. This demonstrates the persistence and stealth capabilities of such kernel-level manipulations.

These attacks highlight a profound vulnerability: by directly manipulating the kernel's representation of ALPC connections, attackers can completely subvert the intended communication pathways, establish covert channels, and blind security mechanisms, all while operating below the radar of conventional security tools.

Demo / Proof of Concept

▶ Watch: Live demo: ALPChecker before the attack (14:00)

The speakers provided a live demonstration of ALPChecker's capabilities in detecting these sophisticated ALPC attacks. The test bench for the demonstration consisted of a Windows 10 virtual machine connected to WinDbg, which was used to simulate a malicious embedded kernel driver. Within this environment, two pairs of applications were set up: Client 1 (C1) interacting with Server 1 (S1) via ALPC, and Client 2 (C2) interacting with Server 2 (S2) via ALPC.

ALPChecker Architecture and Operation:

ALPChecker itself is written in Python and leverages the subprocess module to interact with the LiveKd application. Crucially, ALPChecker does not use ALPC in its own operations, preventing a circular dependency or potential self-compromise. LiveKd, in turn, uses its own dedicated driver to collect low-level system kernel-mode information, allowing ALPChecker to inspect the integrity of ALPC connections directly from the kernel.

The detection logic of ALPChecker operates in a systematic manner:

1. Information Collection: ALPChecker first collects all available information about ALPC connections and ports across the entire system. This data is then categorized and distributed into distinct lists for client and server connections.
2. Integrity Check: For each connection identified in these lists, ALPChecker performs a cross-referencing check. It verifies if a corresponding ALPC port exists in the other list. For example, if a client's communication port points to a specific server's connection port, ALPChecker checks if that server's communication port acknowledges and is correctly linked back to the client's port.
3. Anomaly Detection: If ALPChecker finds a connection where no such symmetrical or expected corresponding ALPC port exists in the paired list, it flags that connection as suspicious.
4. Alert Generation: Upon detecting suspicious connections, ALPChecker generates a security message, alerting the user to a potential ALPC attack.

Demonstration Walkthrough:

1. Baseline Check: Initially, ALPChecker was executed on the clean Windows 10 VM. The output correctly showed "no problems detected message," confirming the system's normal state.
2. Kernel-Level Inspection (WinDbg): The speakers then switched to WinDbg to simulate the attacker's perspective. They used the !dml_proc command to list all running processes, confirming the presence of the two ALPC servers and two ALPC clients. Subsequently, the !alpc instruction was used to inspect the ALPC ports associated with each process. For servers, two connections were visible, one being with its client. For clients, two connections were also visible, one being with its server.
3. Attack Execution (Client Port Modification): The demonstration proceeded to execute Attack #1. Using WinDbg's memory modification capabilities, the ALPC_PORT structure of Client 2's communication port was targeted. Specifically, the ConnectionPort value within the CommunicationInfo field of Client 2's communication port was copied from Client 1's communication port and pasted into Client 2's.
4. Observing Attack Effects: After modifying the kernel structure, the virtual machine was run again. The application behavior visibly changed: Client 1 continued to send messages to its legitimate Server 1. However, Client 2, now compromised, also began sending messages to Server 1. Crucially, Server 2, Client 2's original legitimate server, received nothing, demonstrating the blinding effect.
5. ALPChecker Detection: Finally, ALPChecker was executed once more. This time, it generated an "Alert message about attack on ALPC server." Below this message, a list of suspicious connections was displayed, including the specific incorrect client connection that had been manipulated. The tool successfully identified the kernel-mode attack on ALPC.

The demo vividly illustrated ALPChecker's ability to detect these stealthy, kernel-level ALPC manipulations, proving its efficacy as a much-needed security instrument for Windows systems.

Defensive Implications

▶ Watch: Live demo: ALPChecker successfully detects the attack (17:00)

The research presented on ALPC spoofing and blinding attacks uncovers a significant blind spot in current Windows security postures, necessitating a re-evaluation of defensive strategies. The core implication is that existing Windows security tools, including many advanced EDR and AV solutions, are currently incapable of detecting or preventing these kernel-mode ALPC structure manipulations. This leaves a critical vulnerability that sophisticated attackers, particularly those with kernel-level access, can exploit to bypass defenses and hide their activities.

Defenders must consider the following implications and adopt proactive measures:

1. Prioritize Kernel Integrity Monitoring: The most direct implication is the need for enhanced monitoring of kernel-mode data structures. Tools like ALPChecker represent a proof-of-concept for this capability, and security vendors should integrate similar deep kernel integrity checks into their products. This extends beyond simple file integrity monitoring to real-time verification of critical OS data structures like ALPC_PORT and ALPC_COMMUNICATION_INFO.

1. Strengthen Kernel Driver Security: Since all demonstrated attacks require kernel-level access, often facilitated by malicious or vulnerable drivers, a robust kernel driver security strategy is paramount:

• Strict Driver Signing Policies: Enforce strong driver signing requirements and actively block drivers signed with revoked, leaked, or suspicious certificates.
• BYOVD Mitigation: Implement mechanisms to detect and block known vulnerable drivers (Bring Your Own Vulnerable Driver). Solutions like Microsoft's HVCI (Hypervisor-Enforced Code Integrity) and driver blocklists can help.
• Driver Audit and Monitoring: Continuously monitor for the loading of new or unusual drivers, especially those from unknown vendors or with low reputation scores. Unexpected driver activity should trigger high-priority alerts.

1. Advanced EDR/XDR Evolution: Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) systems need to evolve to incorporate deeper kernel visibility. This means moving beyond user-mode process monitoring to:

• IPC Monitoring: Develop specific heuristics and behavioral analytics to detect anomalous ALPC connection patterns, such as a client communicating with an unexpected server, or a server failing to receive messages it should.
• Memory Integrity Protection: Leverage hardware-assisted memory integrity features (e.g., HVCI on Windows) to protect critical kernel data structures from unauthorized modification. While not a silver bullet, it adds a significant layer of defense.

1. Anomaly Detection in ALPC Behavior:

• Connection Mismatches: Actively look for inconsistencies where a client reports an ALPC connection to a server, but the server's internal ALPC structures do not reflect that incoming connection, or vice-versa. This is precisely what ALPChecker identifies.
• Unexpected Process Termination: Monitor for the termination of processes (especially servers) that coincide with suspicious client redirection or communication loss, as demonstrated in Attack #3 as a cover-up tactic.

1. Threat Intelligence and Research: Security teams should stay abreast of new research into Windows kernel vulnerabilities and IPC mechanisms. Understanding the attack surface at this fundamental level is crucial for anticipating and defending against emerging threats.

In conclusion, the talk serves as a stark reminder that attackers will always seek the lowest possible layer to evade detection. For Windows defenders, this means extending their gaze from the application and network layers deep into the kernel, specifically focusing on the integrity of vital IPC mechanisms like ALPC. The absence of such checks today represents a significant risk that must be addressed with advanced kernel-level monitoring and protection strategies.

Key Takeaways

• ALPC is a Critical, Undermonitored Attack Surface: Windows' Asynchronous Local Procedure Call (ALPC) mechanism is fundamental for interprocess communication and is heavily relied upon by security tools, yet its kernel-mode structures are not robustly monitored for integrity.
• Kernel-Mode Manipulation Enables Stealthy Attacks: Attackers with kernel access (e.g., via malicious drivers) can directly modify ALPC_PORT and ALPC_COMMUNICATION_INFO structures to execute sophisticated spoofing and blinding attacks.
• Existing Security Tools Are Blind: Current Windows security solutions (AV, EDR) lack the capability to detect these specific kernel-level ALPC manipulations, creating a significant detection gap.
• Attacks Facilitate Evasion and Covert Operations: These ALPC attacks can redirect client communications to unintended servers, blind legitimate servers, and establish persistent, illegal connections, potentially enabling ransomware to evade detection or establish covert command-and-control channels.
• ALPChecker Demonstrates a Viable Detection Solution: The developed tool, ALPChecker, proves that detecting these attacks is possible by verifying the integrity and consistency of ALPC connections at the kernel level.
• Defenders Must Enhance Kernel-Level Security: A robust defense requires strengthening kernel driver security, implementing advanced kernel integrity monitoring, and evolving EDR/XDR solutions to include deep visibility into core OS IPC mechanisms like ALPC.

About the Speaker(s)

Anastasiia Kropova is a student from the National Research Nuclear University (MEPhI). Her work on investigating attacks on the ALPC mechanism formed the basis of her Bachelor's thesis, conducted under the supervision of Igor Korkin.

Igor Korkin is an independent researcher with over 15 years of experience in Windows security. His expertise lies in exploring and discovering new attacks on the Windows kernel and developing methods to prevent them. He served as the supervisor for Anastasiia Kropova's research on ALPC vulnerabilities.