👉 Overview
👀 What ?
Windows COM Hijacking is a post-exploitation technique used by attackers to execute malicious code, often to maintain persistence in a system. Component Object Model (COM) is a Microsoft technology that allows interprocess communication and dynamic object creation in a large range of programming languages. The COM infrastructure relies on a set of registry keys to map COM objects to DLLs. By manipulating these keys, an attacker can redirect the COM objects to execute their malicious code.
🧐 Why ?
Understanding Windows COM Hijacking is crucial as it is a powerful technique that can be used to maintain persistence within a system. The manipulation of COM objects provides a stealthy way for attackers to execute their malicious code as it can easily bypass security measures like anti-virus software. Hence, it is an important topic for security researchers and practitioners.
⛏️ How ?
COM Hijacking is achieved by identifying a COM object that is instantiated during the boot process, but whose corresponding DLL does not exist. The attacker then places their malicious DLL with the same name in the expected path. When the system boots, the COM object is redirected to execute the malicious DLL. To counter this, one should regularly monitor and audit the registry keys associated with COM objects.
⏳ When ?
COM Hijacking has been in use since the introduction of the Component Object Model technology by Microsoft, which was in the mid-1990s. However, its use as a post-exploitation technique in cyber attacks has been more common in recent years.
⚙️ Technical Explanations
A COM object is essentially a unique identifier that is used to instantiate a specific instance of a class. The mapping of COM objects to their associated DLLs is done through the Windows Registry. When a COM object is instantiated, the system looks up the object's Class Identifier (CLSID) in the registry to find the path of the corresponding DLL. By replacing the path of a legitimate DLL with a path to a malicious DLL in the registry, an attacker can trick the system into executing their malicious code. This is possible if the legitimate DLL is missing or if the system has inadequate security measures to prevent such changes to the registry. Once the malicious code is executed, it can provide the attacker with persistence, as the COM object is likely to be instantiated each time the system boots.
For instance, let's consider a scenario where an attacker wants to execute a malicious DLL named "malicious.dll" using COM Hijacking. The attacker has identified a COM object that is instantiated during the boot process but its corresponding DLL, let's call it "missing.dll", does not exist.
- Firstly, the attacker needs to locate the registry key associated with the "missing.dll". This key would contain a Class Identifier (CLSID), which is a unique identifier for the COM object.
# Use the 'reg query' command to search for the CLSID of the missing DLL
C:\\> reg query HKCR\\CLSID /s /f "missing.dll"
- Once the attacker has the CLSID, they can navigate to the registry key and see the path where the system expects to find "missing.dll".
# Navigate to the registry key
C:\\> regedit HKEY_CLASSES_ROOT\\CLSID\\{CLSID}
- At this point, the attacker can replace the legitimate path with the path to their "malicious.dll".
# Replace the path
C:\\> reg add HKEY_CLASSES_ROOT\\CLSID\\{CLSID}\\InprocServer32 /v "C:\\path\\to\\malicious.dll"
- Now, when the system boots and tries to instantiate the COM object, it will execute "malicious.dll" instead of "missing.dll".
This example is purely hypothetical and is intended for educational purposes only. It highlights the importance of monitoring and securing the registry keys associated with COM objects.