New research: we discover how to avoid SmartScreen via COM Hijacking and with no privileges

COM Hijacking technique has a simple theoretical basis, similar to the DLL Hijacking one: What does it happen when an application searches for a non-existent COM object on the computer where it is being executed? Or when such object exists but it cannot be found on the registry key where it was searched? An attacker may create it by means of altered information. For instance, a path leading the victim to a DLL created by the attacker instead of to the searched one. We can benefit from the by-default order used by the program to search for this object: this is how we have managed to avoid SmartScreen on Windows. COM (Component Object Model) is a binary-interface standard for software components allowing communication between processes as well as dynamic creation of objects, regardless of the language used to program them. COM provides a stable ABI (Application Binary Interface) that does not change with compilers’ different versions. This is appealing for C++ developers when the code must be shared with clients using different compilers’ versions. COM objects are commonly compiled as a DLL, but the way they are used is particular. COM objects must be unequivocally identifiable at execution time, so the GUID identification method is used. Each COM object is registered under its corresponding GUID, together with one or more keys that provide information on the object itself, such as the real path of its specific DLL. Usually, COM objects are registered under the following registry paths: HKLMSOFTWAREClassesCLSID or HKLUSOFTWAREClassesCLSID. There, under the corresponding GUID key, InprocServer, InprocServer32, InprocHandler e InprocHandler32 registry keys are commonly used to provide the object DLL with the paths. If the COM object is under the root HKEY_LOCAL_MACHINE (HLKM), this means that it is available for all users on the computer and has been created thanks to system admin permissions; while those under the root HKEY_CURRENT_USER (HCKU) are valid for the user currently authenticated and not necessarily created by an admin. The system’s search order is quite interesting. A typical scenario is going firstly to user’s branch and then to the computer’s branch where it is executed. Let’s think of an application that when boosting needs to use the functions of the COM object located on the following registry key: HKEY_LOCAL_MACHINESOFTWAREClassesCLSID{CB4445AC-D88E-4846-A5F3-05DD7F220288}InprocServer32 However, before examining there, the application search for it in the following path: HKEY_CURRENT_USERSOFTWAREClassesCLSID{CB4445AC-D88E-4846-A5F3-05DD7F220288}InprocServer32 In case this last key did not exist, we would be facing an application vulnerable to COM hijacking. Performing the technique only involves creating the following structure on the registry: HKEY_CURRENT_USERSOFTWAREClassesCLSID {CB4445AC-D88E-4846-A5F3-05DD7F220288} InprocServer32 (Default) = C:DLLsMaliciosasmiDLL.dll The COM Hijacking technique to achieve persistence brings several advantages against the remaining traditional techniques to boot the system. The best way is to have a native COM object, called every time the system is boosted. The main problem here is that native COM objects are usually located on HKCR (classes root) instead of on the user’s own registry, so a user on its own should not be able to access it. The truth is that HKCR is a virtual view of that we see both on HKCU and HKLM. This means that if you wish to write a key on HKCRCLSID{A47979D2-C419-11D9-A5B4-001185AD2B89} You would be able to do it by creating it on HKCUSoftwareClassesCLSID{A47979D2-C419-11D9-A5B4-001185AD2B89} Consequently, to perform the hijack over the native COM object on Windows, the key may be created as shown in the following image, where you can observe how it is immediately spread.

Since we work over HKEY_CURRENT_USER (HKCU), no admin permissions are needed to perform the attack. Once the registry key created, the code within the entered DLL will be executed each time the vulnerable application finds the kidnapped COM object and loads the malicious DLL. To elevate privileges through a technique such as COM Hijacking, we must take advantage of a vulnerable application executed with elevated privileges and high-integrity level process. Event Viewer and Task Scheduler applications call an elevated and high-integrity level process known as mmc.exe. It is used by several Windows applications for administration. Functionalities mentioned search for COM objects on the following path: HKCUSoftwareClassesCLSID{0A29FF9E-7F9C-4437-8B11-F424491E3931}InprocServer32 What would it happen if a COM hijack were performed over such object? As you can see, the following line achieves a hijack: powershell.exe -Command {$Path="HKCU:SoftwareClassesCLSID{0A29FF9E-7F9C-4437-8B11-F424491E3931}InprocServer32";$Name="(Default)";$Value="C:MisDLLsepp1.dll";New-Item -Path $Path -Force;New-ItemProperty -Path $Path -Name $Name -Value $Value} Once the vulnerable process called, this will find the COM object (that in principle has not been allocated) and will execute the malicious DLL: in this case a meterpreter shell located on "C:MisDLLsepp1.dll" As the vulnerable process is elevated and has high-integrity level, the provided shell will have SYSTEM privileges without problems. A similar technique has been used to avoid UAC. Some time ago we discovered how attackers were able to avoid SmartScreen by taking advantage of DLL Hijacking techniques. This approach manages similar effects, but in a different manner. Every time a program is executed on Windows, SmartScreen is executed in order to protect us. No matter what program it is, every execution goes over SmartScreen, that queries on the cloud if the program might result in a risk for the system.. Nevertheless, SmartScreen is vulnerable to COM Hijacking. Every time a binary is executed, SmartScreen is executed as well; in turn, every time SmartScreen is executed several COM objects are unsuccessfully searched within the registry. Among them: HKCUSoftwareClassesCLSID{A463FCB9-6B1C-4E0D-A80B-A2CA7999E25D}InprocServer32. By using a simple DLL, a hijack can be performed over this object by executing the following command on the PowerShell console: Following the execution of the previous script, any program executed by the user will execute SmartScreen, and in turn such process will load and execute the malicious DLL, so returning a meterpreter shell. For the proof of concept, we simply used a DLL that displayed a “Hello world!”, letting die the process that is supposed to protect us. It may be used for bypassing and persistence too.