COM Classes and CLSIDs

explain this : COM classes are registered with the Operating System and
mapped to a GUID, which represents a Class Identifier
(CLSID).
CLSIDs are located in the registry, under the following
locations:
• HKLM\Software\Classes\CLSID
• HKCU\Software\Classes\CLSID

COM (Component Object Model) is a platform-independent, distributed, object-oriented system for

creating binary software components that can interact. Here's a breakdown of the explanation
provided:

1. COM Classes and Registration:

COM classes are essentially the blueprint of COM objects, which define their properties and
methods.
These classes need to be registered with the Operating System to be usable by
applications. Registration involves informing the OS about the class's existence and how to
instantiate it.
2. GUID and CLSID:
Each COM class is associated with a GUID (Globally Unique Identifier). A specific type of
GUID for COM classes is called a CLSID (Class Identifier).
The CLSID is a unique identifier that allows the operating system to distinguish between
different COM classes. It's used to instantiate the correct class when requested by an
application.
3. Registry Locations:
The Windows Registry is a database that stores configuration settings and options on
Windows operating systems.
CLSIDs are stored in the registry to keep track of registered COM classes. The locations in
the registry where CLSIDs are stored are:
`HKLM\Software\Classes\CLSID` (HKEY_LOCAL_MACHINE): This registry hive stores
information applicable to all users on the machine.
`HKCU\Software\Classes\CLSID` (HKEY_CURRENT_USER): This hive stores information
specific to the currently logged-in user.

In summary, when a COM class is registered, its CLSID is placed in one of these registry locations. This
allows the operating system to find and instantiate the correct COM class when an application
requests it by its CLSID.

In the previously mentioned registry locations, the keys that we are interested in within each COM
object, are:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 1/23
 • LocalServer32 – defines path to executable on disk
• InprocServer32 – defines path to DLL on disk

In the Windows Registry, the keys `LocalServer32` and `InprocServer32` within each COM object's
CLSID entry are crucial for defining how and where the COM object is implemented. Here’s a detailed
explanation:

1. LocalServer32:
The `LocalServer32` key specifies the path to the executable file (.exe) that implements the
COM object.
This is used for out-of-process COM servers, where the COM object runs in its own process
space, separate from the client application.
When an application requests an instance of this COM object, the operating system will
launch the executable specified in `LocalServer32`.
Example Path:

objectivec

HKLM\Software\Classes\CLSID\{Your-CLSID}\LocalServer32

2. InprocServer32:
The `InprocServer32` key specifies the path to the dynamic link library (.dll) that implements
the COM object.
This is used for in-process COM servers, where the COM object runs within the same
process space as the client application, offering potentially better performance because of
the reduced overhead of cross-process communication.
When an application requests an instance of this COM object, the operating system will
load the DLL specified in `InprocServer32` into the application's process space.
Example Path:

objectivec

HKLM\Software\Classes\CLSID\{Your-CLSID}\InprocServer32

Example Registry Entries:

Suppose you have a COM object with a CLSID of `{12345678-1234-1234-1234-1234567890AB}`.
For an out-of-process server:

swift

[HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{12345678-1234-1234-1234-
1234567890AB}\LocalServer32]
@="C:\\Path\\To\\YourExecutable.exe"

For an in-process server:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 2/23
 swift

[HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{12345678-1234-1234-1234-
1234567890AB}\InprocServer32]
@="C:\\Path\\To\\YourDLL.dll"

In summary, the `LocalServer32` and `InprocServer32` registry keys are used by the operating system
to locate and load the COM object’s implementation, whether it's an executable for out-of-process
servers or a DLL for in-process servers.

As opposed to HKLM, in HKCU there should be either zero

or very few entries.
While non-privileged users are unable to modify the registry
values and the binary files they execute (presumably due to
ACL folder restrictions), they can add user specific CLSID
values which resemble the ones in HKLM.

You're correct. The registry hive `HKCU\Software\Classes\CLSID` (HKEY_CURRENT_USER) is typically less

populated compared to `HKLM\Software\Classes\CLSID` (HKEY_LOCAL_MACHINE), as it stores user-
specific settings and configurations for COM objects. Here’s a deeper dive into the differences and
implications:

1. Non-privileged Users and Registry Modifications:

Non-privileged (standard) users do not have the necessary permissions to modify most of
the entries under `HKLM`, which is a system-wide registry hive. This includes COM class
registrations in `HKLM\Software\Classes\CLSID`.
However, non-privileged users do have write access to their own user-specific registry hive,
`HKCU` (HKEY_CURRENT_USER).
2. User-specific CLSID Entries in HKCU:
Users can add or modify COM class registrations in `HKCU\Software\Classes\CLSID` without
needing administrative privileges.
This means that they can register their own COM objects or override the registration of
existing COM objects for their user context only.
These entries are specific to the user's profile and do not affect other users on the same
machine.
3. Security Implications:
While non-privileged users can’t modify the system-wide `HKLM\Software\Classes\CLSID`
entries, they can create user-specific entries in `HKCU` that resemble those in `HKLM`.
This can be a potential security concern if a malicious user registers a COM object in `HKCU`
to hijack the behavior of legitimate applications running under their user context.
Applications that rely on COM objects will first check `HKCU\Software\Classes\CLSID` before
falling back to `HKLM\Software\Classes\CLSID`.

Example Scenario:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 3/23
 A non-privileged user might add an entry in `HKCU\Software\Classes\CLSID` to register their own COM
object, perhaps to replace a legitimate COM object for certain operations within their user session.
Example Entry in HKCU:

swift

[HKEY_CURRENT_USER\Software\Classes\CLSID\{12345678-1234-1234-1234-
1234567890AB}\InprocServer32]
@="C:\\Path\\To\\UserSpecificDLL.dll"

In this example, if an application running under this user's context tries to instantiate the COM object
with CLSID `{12345678-1234-1234-1234-1234567890AB}`, it will load `UserSpecificDLL.dll` instead of the
system-wide COM object registered in `HKLM`.
Mitigations:

Organizations should enforce strict ACLs (Access Control Lists) and use security policies to limit
the potential for misuse.
Monitoring and auditing registry changes in `HKCU\Software\Classes\CLSID` can help detect and
prevent unauthorized COM object registrations.

In summary, while `HKLM\Software\Classes\CLSID` contains system-wide COM object registrations, non-

privileged users can create user-specific COM object registrations in `HKCU\Software\Classes\CLSID`,
which can have both legitimate uses and potential security implications.

explain this : The problem: CLSID values in HKCU take precedence over
CLSID values in HKLM (Hijacking!).
In other words, imagine there is a scheduled task which
executes a COM object with CLSID 1 in HKLM. If a user
registers a CLSID also with value 1 in HKCU, which
executes a malicious binary, the scheduled task will run the
one in HKCU.

The issue described involves a potential security vulnerability where CLSID values in the `HKCU`
(HKEY_CURRENT_USER) registry hive can take precedence over those in the `HKLM`
(HKEY_LOCAL_MACHINE) registry hive. This situation can be exploited for hijacking by non-privileged
users. Here’s a detailed explanation:

The Problem: CLSID Precedence and Hijacking

1. CLSID Registration:
CLSIDs (Class Identifiers) are registered in the Windows Registry under
`HKLM\Software\Classes\CLSID` for system-wide availability and under
`HKCU\Software\Classes\CLSID` for user-specific availability.
When a COM object is requested, the system first looks for its CLSID in `HKCU`. If it doesn’t
find it there, it then checks `HKLM`.
2. Precedence:
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 4/23
 CLSID values in `HKCU` take precedence over those in `HKLM`. This means that if the same
CLSID exists in both hives, the system will use the one from `HKCU`.
3. Hijacking Scenario:
Imagine there is a scheduled task configured to execute a COM object identified by CLSID
`1` that is registered in `HKLM`. This task expects to run a legitimate system-wide COM
object.
If a non-privileged user registers the same CLSID (`1`) in their `HKCU` hive, pointing to a
malicious binary, the system will execute the malicious binary instead of the legitimate one
when the scheduled task runs.
Example Steps of Exploitation:
Legitimate Registration:

swift

[HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{1}\LocalServer32]
@="C:\\Path\\To\\LegitimateExecutable.exe"

User Hijacks CLSID:

swift

[HKEY_CURRENT_USER\Software\Classes\CLSID\{1}\LocalServer32]
@="C:\\Path\\To\\MaliciousExecutable.exe"

When the scheduled task runs and requests the COM object with CLSID `1`, the system
checks `HKCU` first, finds the malicious entry, and executes `MaliciousExecutable.exe`.

Implications

Security Risk: This behavior can be exploited by non-privileged users to escalate privileges,
execute arbitrary code, or disrupt system operations by hijacking legitimate COM object
requests.
Persistence: Malware can use this technique to achieve persistence, ensuring that even if the
system-wide (HKLM) COM object is intended for a legitimate purpose, the malicious version will
run for the specific user.

Mitigation Strategies

1. Registry Permissions: Tighten permissions to prevent non-privileged users from adding or

modifying entries in `HKCU\Software\Classes\CLSID`.
2. Monitoring: Regularly monitor and audit `HKCU\Software\Classes\CLSID` entries to detect
unauthorized registrations.
3. Security Policies: Implement security policies that restrict the ability of users to register COM
objects in their user-specific hives.
4. Application Design: Design applications and scheduled tasks to specifically check `HKLM` for
critical COM objects, if possible, to avoid user-specific hijacking.

Conclusion

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 5/23
 The precedence of `HKCU` over `HKLM` for CLSID values can be exploited by non-privileged users to
hijack the execution of scheduled tasks or other system operations that rely on COM objects. Proper
security measures and monitoring are necessary to mitigate this risk.

explain : From a privileged user perspective, there can be multiple

abuse scenarios, from modifying LocalServer32/
InprocServer32 to execute a malicious file, to replacing the
file in the original location on disk.

From the perspective of a privileged user (one with administrative rights), there are several potential
abuse scenarios involving the modification of COM object registrations in the registry. These scenarios
include altering the paths defined in `LocalServer32` or `InprocServer32` to execute malicious files, or
replacing the legitimate files at their original locations on disk. Here’s a detailed explanation of these
scenarios:

Abuse Scenarios for Privileged Users

1. Modifying `LocalServer32`/`InprocServer32` to Execute Malicious Files:

`LocalServer32` and `InprocServer32` are registry keys that specify the paths to the
executable (for out-of-process COM servers) or DLL (for in-process COM servers) that
implement a COM class.
A privileged user can modify these registry keys to point to a malicious file instead of the
legitimate one. This means that any application or system component that tries to
instantiate the COM object will execute the malicious file.
Example:
Original Registry Entry:

swift

[HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{12345678-1234-1234-1234-
1234567890AB}\LocalServer32]
@="C:\\Path\\To\\LegitimateExecutable.exe"

Modified by Privileged User:

swift

[HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{12345678-1234-1234-1234-
1234567890AB}\LocalServer32]
@="C:\\Path\\To\\MaliciousExecutable.exe"

Now, when the COM object with CLSID `{12345678-1234-1234-1234-1234567890AB}` is

instantiated, the system will run `MaliciousExecutable.exe`.
2. Replacing the File in the Original Location on Disk:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 6/23
 Instead of or in addition to modifying registry entries, a privileged user can replace the
legitimate executable or DLL file at its original location on disk with a malicious one. This
approach can be particularly stealthy because the registry entries remain unchanged.
Example:
Original File Path:

mathematica

C:\Path\To\LegitimateExecutable.exe

The privileged user replaces `LegitimateExecutable.exe` with a malicious file named

`LegitimateExecutable.exe` at the same location.
Any system or application process that relies on this COM object will now execute the
malicious file, assuming it to be legitimate.

Implications

1. Elevated Privileges: By modifying the registry or replacing files, a privileged user can execute
code with elevated privileges, potentially gaining full control over the system.
2. Persistence: These changes can ensure that malicious code is executed persistently, even after
reboots or user logins.
3. Stealth: Replacing files on disk or making subtle registry modifications can be less noticeable
compared to other methods of executing malicious code.

Mitigation Strategies

1. Access Control: Implement strict access controls to limit who can modify critical registry keys
and executable files.
2. Monitoring and Auditing: Regularly monitor and audit changes to `LocalServer32`,
`InprocServer32`, and critical system files to detect unauthorized modifications.
3. Integrity Checks: Use file integrity monitoring (FIM) tools to ensure that important executables
and DLLs have not been tampered with.
4. Security Policies: Enforce security policies that restrict the ability to modify COM registrations
and critical system files, even for privileged users.

Conclusion

Privileged users have the potential to exploit COM object registrations by modifying `LocalServer32`
or `InprocServer32` registry keys to point to malicious files or by replacing legitimate files at their
original disk locations. These actions can lead to the execution of malicious code with elevated
privileges, persistence, and stealth, posing significant security risks. Implementing robust access
controls, monitoring, and security policies are essential to mitigate these risks.

explain this in deep: As hunters, our focus is therefore any registry additions or
modifications of CLSIDs on the keys LocalServer32 or
InprocServer32.
If baselines are not available to compare with, we could
also hunt by looking for presence of objects within

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 7/23
 HKEY_CURRENT_USER\Software\Classes\CLSID\ as their
presence alone is anomalous behavior.

Understanding the Context

In the context of cybersecurity, "hunters" refers to security analysts or threat hunters who actively
search for indicators of compromise (IoCs) or malicious activity within an organization's systems and
networks. Their goal is to detect and mitigate threats before they can cause significant harm.

Focus on CLSID Registry Modifications

Key Areas of Interest:

LocalServer32 and InprocServer32:

These registry keys define the paths to executables and DLLs that implement COM objects.
Modifications to these keys can redirect legitimate operations to execute malicious files.

Why Focus on CLSID Modifications:

Attack Vector: Malicious actors may modify these keys to hijack legitimate processes and
execute malicious code.
Persistence: Changes to these keys can ensure that malicious code runs persistently, especially
during system startup or when specific COM objects are invoked.

Hunting Strategy

1. Monitoring for Registry Additions or Modifications:

Track changes to `LocalServer32` and `InprocServer32` within both `HKLM` and `HKCU`.
Focus on detecting any new entries or modifications to existing entries. This could indicate
an attempt to hijack COM objects.
2. Baseline Comparisons:
Baselines: These are reference points that represent the normal, expected state of the
system’s registry. They can help identify deviations or anomalies.
If baselines are available, compare the current state of the registry against the baseline to
detect unauthorized changes.
3. Hunting Without Baselines:
HKCU\Software\Classes\CLSID: This location is user-specific and should generally have
fewer entries compared to the system-wide `HKLM` location.
The presence of CLSID entries in `HKCU` can be considered anomalous, especially if there is
no legitimate reason for user-specific COM registrations.
Any unexpected or new CLSID entries in `HKCU` should be investigated as potential
indicators of compromise.

Detailed Steps for Hunters

1. Identify Target Registry Keys:

Monitor the following registry paths:
`HKLM\Software\Classes\CLSID\{CLSID}\LocalServer32`

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 8/23
 `HKLM\Software\Classes\CLSID\{CLSID}\InprocServer32`
`HKCU\Software\Classes\CLSID\{CLSID}\LocalServer32`
`HKCU\Software\Classes\CLSID\{CLSID}\InprocServer32`
2. Set Up Alerts for Modifications:
Use tools and scripts to set up real-time alerts for any additions or modifications to these
registry keys.
Windows Event Logs and Sysmon can be configured to log registry changes, which can then
be monitored by a Security Information and Event Management (SIEM) system.
3. Analyze Suspicious Entries:
For each detected modification or addition, analyze the following:
Timestamp: When was the entry created or modified?
User: Which user account made the change?
File Path: Does the file path point to a legitimate executable/DLL or a suspicious one?
4. Investigate Anomalies in HKCU:
Since `HKCU\Software\Classes\CLSID` should have few entries, any new or unexpected
CLSIDs should be scrutinized.
Check if the executables or DLLs pointed to by `LocalServer32` or `InprocServer32` are
legitimate and expected within the user’s context.
5. Correlate Findings:
Correlate registry changes with other logs and alerts (e.g., file integrity monitoring, process
execution logs) to build a comprehensive picture of potential malicious activity.
Look for patterns such as repeated modifications by the same user or targeting the same
COM objects.

Conclusion

As threat hunters, focusing on registry modifications related to `LocalServer32` and `InprocServer32`

for CLSIDs is crucial because these keys can be exploited to execute malicious code. By monitoring for
additions or changes to these keys, especially in `HKCU`, hunters can detect and investigate potential
threats. When baselines are not available, the presence of unexpected CLSID entries in `HKCU` can
serve as an anomaly worth investigating, helping to identify and mitigate security risks.

how to Set Up Alerts for its Modifications? give examples of queries

To set up alerts for modifications to the `LocalServer32` and `InprocServer32` registry keys, you can
use various tools and techniques. Below are some examples using different platforms:

Using Windows Event Logs and Sysmon

Sysmon (System Monitor) is a tool from Microsoft that logs system activity to the Windows Event
Log. You can configure Sysmon to log registry events, including changes to specific keys.

1. Install and Configure Sysmon

1. Download and install Sysmon from the Microsoft Sysinternals website.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 9/23
 2. Create a Sysmon configuration file to log registry events. Below is an example configuration
file that monitors modifications to `LocalServer32` and `InprocServer32`.

xml

<Sysmon schemaversion="4.12">
<!-- Capture registry key and value changes -->
<EventFiltering>
<RegistryEvent onmatch="include">
<TargetObject condition="contains">LocalServer32</TargetObject>
<TargetObject condition="contains">InprocServer32</TargetObject>
</RegistryEvent>
</EventFiltering>
</Sysmon>

3. Install Sysmon with the configuration file:

sh

sysmon -accepteula -i sysmon-config.xml

2. Monitor and Alert Using Windows Event Viewer

Sysmon logs can be viewed in the Windows Event Viewer under Applications and Services Logs
> Microsoft > Windows > Sysmon.
Set up alerts using Windows Event Viewer by creating a custom view:

1. Open Event Viewer.

2. Go to Actions > Create Custom View.
3. Select By log and choose `Microsoft-Windows-Sysmon/Operational`.
4. Set the Event IDs to filter for registry events (Event ID 13 is used for RegistryEvent in Sysmon).
5. Save the custom view and set up an alert to notify you when these events occur.

Using SIEM Solutions

If you are using a Security Information and Event Management (SIEM) system like Splunk, Elastic Stack
(ELK), or Microsoft Sentinel, you can create queries and alerts for registry modifications.

Splunk Example

1. Collect Windows Event Logs and Sysmon logs in Splunk.

2. Create a search query to detect modifications to `LocalServer32` and `InprocServer32`.

spl

index=main source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventID=13

TargetObject="*LocalServer32*" OR TargetObject="*InprocServer32*"

3. Create an alert based on this search:

Save the search as an alert.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 10/23
 Configure the alert conditions (e.g., trigger alert when the number of matching events exceeds a
threshold).
Set up email notifications or other alert actions.

Elastic Stack (ELK) Example

1. Collect Sysmon logs using Beats or another log shipper.

2. Create a search query in Kibana to detect modifications:

kql

event.code: "13" and registry.path: "*LocalServer32*" or registry.path: "*InprocServer32*"

3. Create an alert in Kibana:

Go to Alerts and Actions.

Create a new alert and use the above query as the condition.
Set the alert frequency and actions (e.g., email, webhook).

Using PowerShell

For environments without advanced tools, you can use a PowerShell script to monitor and alert on
registry changes.

1. PowerShell Script Example:

powershell

$path = "HKLM:\Software\Classes\CLSID"
$filter = "LocalServer32","InprocServer32"

Register-WmiEvent -Query "SELECT * FROM RegistryValueChangeEvent WHERE

Hive='HKEY_LOCAL_MACHINE' AND KeyPath='Software\\Classes\\CLSID'" -SourceIdentifier
"CLSIDWatcher" -Action {
$event = $Event.SourceEventArgs.NewEvent
$registryKey = "HKLM:\Software\Classes\CLSID\" + $event.KeyPath
$changedValue = Get-ItemProperty -Path $registryKey | Select-Object -Property $filter
Write-Output "Registry change detected: $changedValue"
# Add code here to send email or log the change
}

# Keep the script running

while ($true) { Start-Sleep -Seconds 10 }

2. Run the Script:

Run the PowerShell script on a system with administrative privileges.

Modify the script to include notification mechanisms (e.g., send an email or write to a log file).

Conclusion

Setting up alerts for modifications to `LocalServer32` and `InprocServer32` registry keys can be
achieved using tools like Sysmon with Windows Event Viewer, SIEM solutions like Splunk or ELK, or

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 11/23
 even custom PowerShell scripts. Each method involves monitoring for specific registry changes and
configuring alerts to notify you of potential malicious activity.

Examples of detection of hijacking a COM object

Detecting the hijacking of a COM object involves monitoring for suspicious changes to registry keys
and paths associated with COM object registrations. Here are examples using different tools and
methodologies to detect such hijacking attempts:

1. Using Sysmon and Windows Event Viewer

Sysmon can be configured to monitor for registry changes, particularly for keys related to COM
objects (`LocalServer32` and `InprocServer32`).

Sysmon Configuration

First, set up Sysmon with a configuration file that monitors registry events:

xml

<Sysmon schemaversion="4.12">
<EventFiltering>
<!-- Capture registry key and value changes -->
<RegistryEvent onmatch="include">
<TargetObject condition="contains">LocalServer32</TargetObject>
<TargetObject condition="contains">InprocServer32</TargetObject>
</RegistryEvent>
</EventFiltering>
</Sysmon>

Monitoring and Alerting

1. Install Sysmon with the configuration file:

sh

sysmon -accepteula -i sysmon-config.xml

2. Set Up Alerts in Event Viewer:

Open Event Viewer.
Create a custom view:
Go to Actions > Create Custom View.
Select By log and choose `Microsoft-Windows-Sysmon/Operational`.
Set the Event IDs to `13` (which corresponds to `RegistryEvent` in Sysmon).
Save the view.
Set up a task to send an email or trigger an alert when such events are logged.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 12/23
 2. Using Splunk

Splunk can be used to search and create alerts for suspicious registry changes.

Search Query

1. Collect Sysmon logs into Splunk.

2. Create a search query to detect modifications to `LocalServer32` and `InprocServer32`:

spl

index=main source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventID=13

TargetObject="*LocalServer32*" OR TargetObject="*InprocServer32*"

3. Save this search as an alert:

Configure the alert to trigger when the number of matching events exceeds a threshold.
Set up email notifications or other alert actions.

3. Using Elastic Stack (ELK)

Elastic Stack can also be configured to detect and alert on registry changes.

Kibana Query

1. Collect Sysmon logs using Beats.

2. Create a query in Kibana to detect suspicious registry changes:

kql

event.code: "13" and registry.path: "*LocalServer32*" or registry.path: "*InprocServer32*"

3. Create an alert in Kibana:

Go to Alerts and Actions.
Create a new alert using the above query as the condition.
Configure the alert to notify you via email, webhook, or other actions.

4. Using PowerShell

A PowerShell script can monitor for registry changes and detect hijacking attempts.

PowerShell Script Example

powershell

$path = "HKLM:\Software\Classes\CLSID"
$filter = "LocalServer32","InprocServer32"

# Register WMI Event for registry changes

Register-WmiEvent -Query "SELECT * FROM RegistryValueChangeEvent WHERE
Hive='HKEY_LOCAL_MACHINE' AND KeyPath='Software\\Classes\\CLSID'" -SourceIdentifier
"CLSIDWatcher" -Action {
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 13/23
 $event = $Event.SourceEventArgs.NewEvent
$registryKey = "HKLM:\Software\Classes\CLSID\" + $event.KeyPath
$changedValue = Get-ItemProperty -Path $registryKey | Select-Object -Property $filter
Write-Output "Registry change detected: $changedValue"
# Add code here to send email or log the change
}

# Keep the script running

while ($true) { Start-Sleep -Seconds 10 }

Run this PowerShell script with administrative privileges.

Modify the script to include a notification mechanism, such as sending an email or logging the
change.

5. Manual Detection

Regular audits can help detect hijacking attempts.

Steps for Manual Auditing

1. Baseline Registry Entries: Create a baseline of known good `LocalServer32` and

`InprocServer32` entries.
2. Periodic Audits: Regularly compare the current registry entries against the baseline to detect
unauthorized changes.
3. Investigate Anomalies: Any discrepancies should be investigated to determine if they are
legitimate changes or potential hijacking attempts.

Example Scenario of Detection

Suppose you have the following legitimate registry entry for a COM object:

sh

[HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{12345678-1234-1234-1234-
1234567890AB}\LocalServer32]
@="C:\\Path\\To\\LegitimateExecutable.exe"

If a Sysmon event or a SIEM alert shows a modification like this:

sh

[HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{12345678-1234-1234-1234-
1234567890AB}\LocalServer32]
@="C:\\Path\\To\\MaliciousExecutable.exe"

Investigate and Respond:

1. Check the Timestamp: Determine when the change occurred.

2. Identify the User: Find out which user account made the change.
3. Analyze the Executable: Investigate the path to see if it points to a legitimate or malicious file.
4. Mitigate the Threat: If the change is malicious, revert it, and take steps to remove the threat
and prevent future occurrences.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 14/23
 By setting up these monitoring and alerting mechanisms, you can detect and respond to COM object
hijacking attempts effectively.

explain this in deep: Some interesting research discovered that rundll32.exe can
also be used to start COM objects.

Using `rundll32.exe` to start COM objects is a technique that has been explored in various research
studies and threat actor methodologies. `rundll32.exe` is a legitimate Windows utility that can
execute functions exported from DLLs. It can also be leveraged to invoke COM objects, which can be
an interesting avenue for both legitimate and malicious purposes. Here’s a deeper look into this
concept:

Rundll32.exe Overview

Purpose: `rundll32.exe` is designed to load and run 32-bit dynamic-link libraries (DLLs) and call
their exported functions. It is commonly used by various Windows components and software
applications.
Location: Typically located in `C:\Windows\System32`.

Using Rundll32.exe to Start COM Objects

How Rundll32.exe Can Be Used with COM Objects

COM objects can be instantiated and their methods invoked via `rundll32.exe`. This is achieved by
using a specific function call pattern that `rundll32.exe` can interpret. Here’s how it works:

1. Creating a DLL that Exports a Function:

The DLL must export a function that can instantiate a COM object and call its methods. For
example:

cpp

// Example DLL code

#include <windows.h>
#include <objbase.h>
#include <iostream>

// Prototype of the function to be called by rundll32.exe

extern "C" __declspec(dllexport) void CALLBACK RunCOMObject(HWND hwnd, HINSTANCE
hinst, LPSTR lpszCmdLine, int nCmdShow) {
// Initialize COM library
CoInitialize(NULL);

// CLSID of the COM object

CLSID clsid;
CLSIDFromString(L"{YOUR-CLSID-HERE}", &clsid);

// IID of the interface you want to use

IID iid;
IIDFromString(L"{YOUR-IID-HERE}", &iid);

// Create the COM object

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 15/23
 IUnknown *pUnknown = NULL;
HRESULT hr = CoCreateInstance(clsid, NULL, CLSCTX_INPROC_SERVER, iid,
(void**)&pUnknown);

if (SUCCEEDED(hr)) {
// Do something with the COM object
// ...

// Release the COM object

pUnknown->Release();
}

// Uninitialize COM library

CoUninitialize();
}

2. Using Rundll32.exe to Load the DLL and Execute the Exported Function:
Once the DLL is prepared and placed in a known location, you can use `rundll32.exe` to
execute the exported function:

sh

rundll32.exe path\to\your.dll,RunCOMObject

Example Scenario

Consider the following steps to demonstrate how `rundll32.exe` can start a COM object:

1. Creating the DLL:

Compile the above example code into a DLL, ensuring it exports a function that can
initialize a COM object.
2. Executing the DLL with Rundll32.exe:
Use `rundll32.exe` to load the DLL and execute the exported function:

sh

rundll32.exe C:\Path\To\YourDLL.dll,RunCOMObject

In this example, `RunCOMObject` is the function within the DLL that instantiates the COM object and
invokes its methods.

Potential for Abuse

While `rundll32.exe` is a legitimate utility, it can be abused by attackers for several reasons:

1. Evasion:
Using `rundll32.exe` to execute malicious code can help evade detection because it is a
trusted Windows binary.
Attackers can use it to load malicious DLLs that instantiate harmful COM objects.
2. Persistence:
Attackers can register COM objects that get instantiated by `rundll32.exe` on system
startup or during specific system events.
3. Execution of Malicious Code:
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 16/23
 Malicious DLLs can be loaded to perform a wide range of harmful activities, such as data
exfiltration, system modification, or further payload execution.

Detection and Mitigation

1. Monitoring and Logging:

Monitor usage of `rundll32.exe`, especially when it is used to load non-standard DLLs.
Enable logging for process creation and DLL loading events.
2. Behavioral Analysis:
Analyze the behavior of processes spawned by `rundll32.exe` to detect anomalies.
Use security tools that can inspect the command lines and parameters passed to
`rundll32.exe`.
3. YARA Rules:
Create YARA rules to detect suspicious patterns related to the misuse of `rundll32.exe`.
4. Endpoint Protection:
Utilize advanced endpoint protection tools that can identify and block malicious use of
system utilities like `rundll32.exe`.

Conclusion

The use of `rundll32.exe` to start COM objects is a technique that leverages legitimate system
functionality for potentially malicious purposes. Understanding this technique is crucial for both
defending against and detecting its misuse. By monitoring, analyzing, and implementing robust
security measures, it is possible to mitigate the risks associated with this method.

give real examples/queries of Detection and Mitigation for rundll32.exe

To detect and mitigate the misuse of `rundll32.exe` for executing COM objects or malicious DLLs,
security analysts can leverage a combination of event logging, SIEM solutions, and endpoint detection
and response (EDR) tools. Here are real examples and queries using popular tools:

1. Sysmon Configuration

Sysmon can be configured to log detailed events about process creations, including `rundll32.exe`
executions.

Sysmon Configuration File Example

Create a Sysmon configuration file (`sysmon-config.xml`) to capture events related to `rundll32.exe`:

xml

<Sysmon schemaversion="4.12">
<EventFiltering>
<!-- Log process creation events -->
<ProcessCreate onmatch="include">
<Image condition="contains">rundll32.exe</Image>

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 17/23
 </ProcessCreate>

<!-- Log DLL loading events -->

<ImageLoad onmatch="include">
<ImageLoaded condition="contains">rundll32.exe</ImageLoaded>
</ImageLoad>
</EventFiltering>
</Sysmon>

Install Sysmon with this configuration:

sh

sysmon -accepteula -i sysmon-config.xml

2. Detecting with SIEM Solutions

Splunk Query

In Splunk, you can create a search query to detect `rundll32.exe` executions with suspicious
command lines:

spl

index=main sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1

Image="*\\rundll32.exe"
| eval cmdline=lower(CommandLine)
| search cmdline="*comobject*" OR cmdline="*loadlibrary*" OR cmdline="*.dll"
| table _time, ComputerName, User, Image, CommandLine, ParentImage

Save this search as an alert:

Configure the alert to trigger when the number of matching events exceeds a threshold.
Set up email notifications or other alert actions.

Elastic Stack (ELK) Query

In Kibana, create a query to detect `rundll32.exe` executions:

kql

event.category: "process" and process.name: "rundll32.exe" and

(process.command_line: "*comobject*" or process.command_line: "*loadlibrary*" or
process.command_line: "*.dll")

Create an alert in Kibana:

Go to Alerts and Actions.

Create a new alert using the above query as the condition.
Configure the alert to notify you via email, webhook, or other actions.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 18/23
 3. Detecting with Windows Event Viewer

Custom Event Viewer Filter

Create a custom filter in Event Viewer to detect `rundll32.exe` executions:

1. Open Event Viewer.

2. Create Custom View:
Actions > Create Custom View.
Select By Source and choose `Microsoft-Windows-Sysmon/Operational`.
Add Event ID 1 (Process Create).
Include the keyword `rundll32.exe` in the command line.
3. Save the custom view.
4. Set up a task to trigger an alert or email notification when these events are logged.

4. PowerShell Script for Real-time Monitoring

A PowerShell script can monitor for `rundll32.exe` executions:

powershell

# Define the WMI query for process creation events

$query = "SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA
'Win32_Process' AND TargetInstance.Name = 'rundll32.exe'"

# Register the WMI event

Register-WmiEvent -Query $query -SourceIdentifier "Rundll32Monitor" -Action {
$process = $Event.SourceEventArgs.NewEvent.TargetInstance
$cmdline = $process.CommandLine
if ($cmdline -match "comobject|loadlibrary|\.dll") {
Write-Output "Suspicious rundll32.exe execution detected: $cmdline"
# Add code here to send email or log the change
}
}

# Keep the script running

while ($true) { Start-Sleep -Seconds 10 }

5. Mitigation Strategies

Endpoint Protection Policies

1. Application Control:
Implement application control policies to restrict the execution of `rundll32.exe` to known,
trusted DLLs only.
2. Behavioral Analysis:
Use EDR tools that can analyze the behavior of `rundll32.exe` and detect anomalies.
Configure rules in EDR tools to flag or block `rundll32.exe` executions with suspicious
command lines.

Group Policy and Software Restriction Policies

1. Software Restriction Policies:

Create software restriction policies to limit where `rundll32.exe` can execute from.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 19/23
 text

Software Restriction Policies > Additional Rules > New Path Rule
Path: *\rundll32.exe
Security Level: Disallowed

2. Group Policy:
Use Group Policy to restrict `rundll32.exe` usage to prevent unauthorized DLL loading.

Conclusion

By configuring Sysmon, leveraging SIEM solutions like Splunk and ELK, using PowerShell scripts, and
implementing endpoint protection policies, you can effectively detect and mitigate the misuse of
`rundll32.exe` for executing COM objects or malicious DLLs. Regular monitoring, alerting, and
enforcing strict application control policies are crucial steps in securing your environment against
such threats.

Create YARA rules to detect suspicious patterns related to the misuse of rundll32.exe

Creating YARA rules to detect suspicious patterns related to the misuse of `rundll32.exe` involves
looking for specific command-line arguments or behaviors that indicate malicious activity. Below are
some example YARA rules that can help identify potentially malicious use of `rundll32.exe`.

Example 1: Detecting Suspicious Command-Line Arguments

This YARA rule detects the use of `rundll32.exe` with suspicious command-line arguments such as
those often used to load a DLL or execute a COM object.

yara

rule SuspiciousRundll32CommandLine
{
meta:
description = "Detects suspicious rundll32.exe command-line arguments"
author = "Your Name"
date = "2024-07-23"
reference = "https://example.com"

strings:
$suspicious1 = /rundll32\.exe.*
(,RunDLL|,DllRegisterServer|,DllInstall|,DllUnregisterServer|,EntryPoint)/ nocase
$suspicious2 = /rundll32\.exe.*(javascript:|vbscript:|file:|data:)/ nocase
$suspicious3 = /rundll32\.exe.*(\.dll,|\.ocx,)/ nocase

condition:
any of ($suspicious1, $suspicious2, $suspicious3)
}

Example 2: Detecting Rundll32.exe Loading Uncommon DLLs

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 20/23
 This rule detects when `rundll32.exe` loads DLLs from uncommon locations or with uncommon
names, which could be indicative of malicious activity.

yara

rule UncommonRundll32DllLoading
{
meta:
description = "Detects rundll32.exe loading uncommon DLLs"
author = "Your Name"
date = "2024-07-23"
reference = "https://example.com"

strings:
$dll_path1 = /rundll32\.exe.*C:\\Users\\.*\\AppData\\Local\\Temp\\.*\.dll/ nocase
$dll_path2 = /rundll32\.exe.*C:\\Windows\\Temp\\.*\.dll/ nocase
$dll_path3 = /rundll32\.exe.*C:\\ProgramData\\.*\.dll/ nocase

condition:
any of ($dll_path1, $dll_path2, $dll_path3)
}

Example 3: Detecting Rundll32.exe Loading Suspicious COM Objects

This rule targets the loading of specific COM objects known to be commonly abused by malware
through `rundll32.exe`.

yara

rule SuspiciousCOMObjectLoading

Detecting Rundll32.exe Loading Suspicious COM Objects

To detect `rundll32.exe` loading suspicious COM objects, we need to identify patterns in the
command-line arguments that are associated with malicious activity. Below is an example YARA rule
that focuses on detecting the loading of suspicious COM objects by `rundll32.exe`.

Example YARA Rule: Detecting Suspicious COM Object Loading

This rule looks for the presence of specific patterns in the command-line arguments of `rundll32.exe`
that are indicative of malicious use of COM objects.

yara

rule SuspiciousRundll32COMObjectLoading
{
meta:
description = "Detects rundll32.exe loading suspicious COM objects"
author = "Your Name"
date = "2024-07-23"

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 21/23
 reference = "https://example.com"

strings:
// Detecting common patterns used in rundll32.exe to load COM objects
$com_load1 = /rundll32\.exe.*CoCreateInstance/i
$com_load2 = /rundll32\.exe.*DllGetClassObject/i
$com_load3 = /rundll32\.exe.*Ole32\.dll/i
$com_load4 = /rundll32\.exe.*ProgIDFromCLSID/i
$com_load5 = /rundll32\.exe.*CLSIDFromProgID/i
$com_load6 = /rundll32\.exe.*CLSIDFromString/i

// Suspicious GUIDs associated with COM objects commonly abused

$guid1 = /{D63B10C5-BB46-4990-A94F-E40B9D520160}/ nocase
$guid2 = /{0006F03A-0000-0000-C000-000000000046}/ nocase
$guid3 = /{0002DF01-0000-0000-C000-000000000046}/ nocase
$guid4 = /{F414C260-6AC0-11CF-B6D1-00AA00BBBB58}/ nocase
$guid5 = /{F414C261-6AC0-11CF-B6D1-00AA00BBBB58}/ nocase

condition:
any of ($com_load1, $com_load2, $com_load3, $com_load4, $com_load5, $com_load6) or
any of ($guid1, $guid2, $guid3, $guid4, $guid5)
}

Explanation

Meta Section: Contains metadata about the rule, such as description, author, date, and
reference.
Strings Section: Defines the strings and regular expressions to match suspicious command-line
patterns and GUIDs associated with malicious COM objects.
`$com_load1` to `$com_load6`: These are regular expressions to match common methods
and libraries used to load COM objects with `rundll32.exe`.
`$guid1` to `$guid5`: These are GUIDs associated with COM objects that are known to be
abused by malware.
Condition Section: Specifies the conditions under which the rule will trigger. The rule triggers if
any of the defined strings or GUIDs are found in the command-line arguments.

Usage

1. Integration with EDR: This YARA rule can be integrated with endpoint detection and response
(EDR) solutions to monitor process creation events and analyze command-line arguments.
2. Log Analysis: Apply this YARA rule to logs collected from Sysmon, Windows Event Viewer, or
other logging mechanisms to detect suspicious `rundll32.exe` executions.

Example Usage with a YARA Scanner

To use this rule with a YARA scanner, save the rule to a file, e.g., `rundll32_com_object_loading.yara`,
and run the scanner against the target logs or process memory.

sh

yara -r rundll32_com_object_loading.yara /path/to/logs/

By implementing such YARA rules, security analysts can enhance their ability to detect and respond to
the misuse of `rundll32.exe` for loading malicious COM objects, thereby strengthening their overall
security posture.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 22/23
 ‫ يمكن أن تصدر عن‬ChatGPT ‫ لذلك يجب التحقق من المعلومات المهمة‬.‫بعض األخطاء‬.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 23/23