Help! Someone Stole my RID: Exploring RID Hijacking TTPs

This technique is a method of establishing local persistence by covertly modifying an account to grant administrative privileges without adding it to the local administrators group. We will explore how to execute this attack, as well as what it looks like in Sysmon and Windows Event Logs.

Introduction

Local persistence is a strategy commonly employed by both red teamers and threat actors to maintain access to a compromised system across reboots. This tactic ensures they can use the compromised system as a flexible jump box, facilitating movement from a level 1 compromise to a more deeply entrenched level 2 position.

Before we start with the Proof-of-Concept, let us understand what is SID and RID and how it plays in Windows systems.

Understanding Relative Identifier (RID) and Security Identifier (SID)

In Windows, a Relative Identifier (RID) is part of a Security Identifier (SID), which uniquely distinguishes each user and group within a domain. An administrator account will have RID value of “500” and for normal users the RID will start from value “1000”.

A Security Identifier (SID) is a unique string of characters assigned by Windows to each user, group, or other security principal. Each SID, which is created when the account or group is established, is used to control access to resources and track activities for security purposes.

For further readings refer to Microsoft's official page for documentation.

Here’s an example of a normal user’s SID and RID:

The primary purpose of implementing RID in Windows is to efficiently manage user and group identification, ensuring that each entity is distinctly recognized across the network. This is especially important in large organizations with numerous users and groups, where managing permissions and access controls accurately and securely is critical.

Now, let us talk about how this technique works.

RID Hijacking: Manipulating Account Privileges

Before we begin with the Proof-of-Concept of this technique let us understand first what the red teamer or threat actor must acquire and do to perform this attack.

Here are some steps needed to perform this attack:

Level 1 Foothold - Attacker must have fully compromised a level 1 machine or initial compromised machine on the network that will act as jump box to the other machines in the network.

SYSTEM privilege - This attack requires SYSTEM level privilege to make changes to the SAM registry hive.

Malware - Beacon or a malware to control the compromised system from a remote host.

You will see how these steps plays through this type of attack as we progress with the discussion.

How does RID Hijacking Work?

This method involves a type of local persistence in which an attacker modifies the Security Descriptor (SD) of the SAM hive entry for a user. The relevant SAM Registry Key located at:

‘HKLM\SAM\SAM\Domains\Account\Users’

This section of the SAM registry stores critical values that, when altered, can deceive the system into granting a normal user Administrator privileges. This contains the Relative Identifier (RID) for each user in hexadecimal format. For example, an admin with a RID of ‘500’ appears as ‘01F4’.

The 'F' value is particularly significant as it encompasses the RID, timestamps, and other user-related data. One key point is that the RID is located at the 0x30 position, as shown in the diagram below. This is reversed due to little endian formatting.

So if the attacker has already compromised the machine and obtain SYSTEM level privilege, they can easily modify the data and put the Administrator’s (01F4) RID to the user they want to have elevated privilege without adding it to the local administrator’s group. Nice trick right?

Now that we have already an idea of how this technique work, let’s get our hands dirty to find out.

Case Study: RID Hijacking Proof-of-Concept Attack and Detection

To make this topic easier to follow, we’ll break it down to following stages:

• Account Creation via ‘net user’
• Account Enumeration via ‘wmic’
• Registry Query via 'reg query'
• Registry Add via 'reg add'

Now, let’s start!

RID Hijacking: Account Creation

To understand how this technique work I created a normal user account named ‘support01’ which mimics a technical support account to avoid suspicion.

Note: I used RAT-like setup to perform this attack meaning I have a C2 or a Remote Server listening and executing commands to the compromised machine.

As you can see I have successfully created an account from my remote C2 server.

Now, to detect this user creation stage we’ll resort to investigate both Windows Event Logs (WEL) and Sysmon logs.

In WEL, it generates the following logs:

• 4656 - A handle to an object was accessed(In this case, SAM).
• 4690 - An attempt was made to duplicate a handle to an object.
• 4658 - The handle to an object was closed.
• 4663 - An attempt was made to access an object.

In Sysmon, the following logs have been generated:

• 1 (Process Create) - This entry contains the user account creation commands I executed from the remote server included the user which in our case the SYSTEM.

As we can see, Windows Event Logs helps us identify log patterns with regards to SAM registry access and Sysmon logs to find out what command was executed on the machine and which user executed this command.

RID Hijacking: REG QUERY

Now, that I have created the account our next step is to query the values of SAM registry.

I use the C2 to communicate with the compromised machine and execute the query command. This is what it looks like:

The ‘03EB’ is the ‘support01’ user that I recently created which if translated to hexadecimal the value will be ‘1003’.

To detect REG QUERY, let’s check what logs this action generated.

In WEL, it generates the following registry related event logs:

• 4690 - An attempt was made to duplicate a handle to an object.
• 4658 - The handle to an object was closed.
• 4656 - A handle to an object was accessed.
• 4663 - An attempt was made to access an object.

And when you look closely at the event ID 4656 it will tell you what process were responsible and what type of action it performed.

Surprisingly, Windows Event Logs does tell you something about the action.

However, In Sysmon logs it generates only one event ID:

• 1 (Process Create)

Still, Sysmon provides a brief and well defined explanation of the action specially with the value in the command line.

RID Hijacking: Data Patching in Action

In the previous discussion, we already performed user creation and registry query.

In this stage, we will replace the 0x30 bytes of the normal user(support01, 0x03EB) with administrator’s RID(0x01F4). Still, we will be executing the attack from our remote C2 server.

To give you a look how this execution looked like in a C2 server, here’s a snippet of the command that was executed. We have successfully patched the 0x30 bytes of ‘F’ with the administrator’s RID.

In the compromised box, we can see the actual patched data by inspecting the normal user’s SAM '.

Checking if it inherits administrator’s RID, we run a simple “whoami /user” command.

As you can see, it now have the RID of 500(Administrator) and added to the local administrator group too.

Let’s take a look at how Windows Event Logs detect this.

In WEL, the action generates the same registry logs patterns:

• 4690 - An attempt was made to duplicate a handle to an object.
• 4658 - The handle to an object was closed.
• 4656 - A handle to an object was accessed.
• 4663 - An attempt was made to access an object.

But the note the difference between the QUERY and ADD’s Access Request Information part.

In REG QUERY, it contains ‘Query key values' and 'Enumerate Sub keys’.

In REG ADD, it contains the following:

However, in Sysmon it only generated a single process ID 1.

The cool thing about this log is the command line value that help us detect the data patching.

Detection: ELK and Splunk Queries

Knowing the attack is half the battle won and the other half is “how” to detect this in our environment. In this part, we will list the possible ELK and Splunk queries that an analyst can run to detect this type of attack. Again, we will be arranging it according to the attack stage performed above.

Please do note that the filter used in the following example will vary depending on the maturity of your organization's threat hunting capabilities, as it differs from and makes use of a data dictionary that indicates all fields within your SIEM.

What are Data Dictionaries? Data dictionaries create a uniform way to categorize and label data, efficiently for conducting threat hunting activities. It links data sources to the analytics used in your organization. By implementing a standard data dictionary, the team can gain increased visibility for detecting adversaries in the environment, irrespective of their originating OS. These dictionaries contain detailed information on various security events, represented by event logs, with the aim of establishing standardized terminology for data from different sources.

Account Creation: SAM Access

ELK:

event_id: "4656" AND process_name: "C:\\Windows\\System32\\lsass.exe" AND (accesses: "ReadPasswordParameters" OR accesses: "CreateUser" OR accesses: "LookupIDs")

Splunk:

index=* EventCode=4656 Process_Name="C:\\Windows\\System32\\lsass.exe" (Accesses="ReadPasswordParameters" OR Accesses="CreateUser" OR Accesses="LookupIDs") | table _time, host, user, Process_Name, Accesses

REG QUERY

ELK:

event_id: "4656" AND object_name: "REGISTRY\\MACHINE\\SAM\\SAM\\Domains\\Account\\Users" AND process_name: "C:\\Windows\\System32\\reg.exe"

Splunk:

index=* EventCode=4656 Object_Name="REGISTRY\\MACHINE\\SAM\\SAM\\Domains\\Account\\Users" Process_Name="C:\\Windows\\System32\\reg.exe" | table _time, host, user, Object_Name, Accesses, Process_Name

REG Add: Data Patching

ELK:

event_id: "4656" AND object_name: "REGISTRY\\MACHINE\\SAM\\SAM\\Domains\\Account\\Users" AND process_name: "C:\\Windows\\System32\\reg.exe"

Splunk:

index=* EventCode=4656 Object_Name="REGISTRY\\MACHINE\\SAM\\SAM\\Domains\\Account\\Users" Process_Name="C:\\Windows\\System32\\reg.exe" | table _time, host, user, Object_Name, Accesses, Process_Name

Detection: Sigma Rules

Sigma rules are a powerful tool for threat detection and response. These rules offer a standardized way to define search patterns for various security events, making it easier to detect and respond to threats across different SIEM (Security Information and Event Management) systems. By utilizing Sigma rules, organizations can improve their detection capabilities, identify suspicious activities such as RID hijacking, and enforce consistent security monitoring practices.

We have created Sigma rules for the steps needed to perform RID hijacking. To keep this blog concise, we will only include the data patching part. If you are interested in Sigma rules related to account creation and registry queries, you can find the resources at:

GitHub - SecurityBlueTeam/sigma-rules: A collection of SBT Sigma Rules

Here’s an example of a sigma rule detecting RID Hijacking specifically the data patching part.

title: Detect Data Patching in RID Hijacking
id: 56789012-5678-9012-5678-901256789012
description: Detects attempts to patch data in the registry for RID values indicating potential RID hijacking.
status: experimental
author: SBT RENMARC
date: 2024/06/11
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1
        Image: "C:\\Windows\\System32\\reg.exe"
        CommandLine|contains|all:
            - "HKLM\\SAM\\SAM\\Domains\\Account\\Users\\*"
            - " /v F"
            - " /t REG_BINARY"
    condition: selection
fields:
    - EventID
    - Image
    - CommandLine
falsepositives:
    - Administrative scripts
level: high
tags:
    - attack.persistence
    - attack.t1078.002

Implications and Defensive Measures for RID Hijacking

RID hijacking poses significant security risks by allowing attackers to escalate privileges and maintain persistent access to a system. This technique compromises system integrity, as unauthorized users can gain administrative control and will remain undetected if proper queries or alerting are not in place.

To detect and prevent RID hijacking, implement best practices such as regular auditing of account privileges and monitoring event logs for unusual activity. Use tools like Sysmon for advanced logging and employ Group Policy settings to enforce strict access controls. Strategies for system hardening include disabling unnecessary services, applying the principle of least privilege, and regularly updating security patches to reduce vulnerabilities.

If you found this topic interesting and you don’t have any exposure to Malware Analysis, Reverse Engineering, Digital Forensics and Incident Response, why not take a look at our online gamified blue team training platform.

Discover Blue Team Training for the Different Stages of your Career

Security Blue Team is a leading online defensive cybersecurity training provider with over 100,000 students worldwide, and training security teams across governments, military units, law enforcement agencies, managed security providers, and many more industries. From our junior blue team certification, right through to our Certified Security Operations Manager cert, we have something for everyone.