Monday, February 17, 2020

RID Hijacking

I read a fascinating blog post recently that described something called RID hijacking, which can be used as a method for maintaining elevated privileges on a system.  The PenTestLabs article not only outlines how to perform RID hijacking manually, but also using MetaSploit, Empire, a Powershell module, and then using the module via POSHC2.  In short, there are no shortage of ways to go about performing RID hijacking from an offensive perspective.

But how would this look from a blue team perspective?  I made a minor tweak to the output of one of the RegRipper plugins (the data was already available) so that the output appears as follows (run against a SAM hive from a Win2000 system):

Username          : Guest [501]
Full Name          :
User Comment    : Built-in account for guest access to the computer/domain
Account Type      :
Account Created : Fri Sep 27 03:32:48 2002 Z
Name                  :
Last Login Date   : Never
Pwd Reset Date   : Never
Pwd Fail Date      : Sat Aug 25 09:21:50 2012 Z
Login Count         : 0
Embedded RID    : 501
  --> Password does not expire
  --> Account Disabled
  --> Password not required
  --> Normal user account

I added the emphasis on the "Embedded RID" entry.  Again, the data itself was available in the plugin, all I did was add the line to display the RID from within the F value data (as described in the PenTestLab article).  I also added a bit of logic to compare the embedded value with the RID value from the Username field (in the brackets) and if they aren't same, print out a warning message.

I can't say that I've ever intentionally looked for this sort of thing during an investigation, as there was nothing that pointed to something like RID hijacking having occurred.  For example, there were no indications of no suspicious actions involving the Guest account, and subsequently the Guest account being used to log into the system and perform actions requiring Admin privileges. 

I have seen threat actors establish multiple means for returning to systems.  I've seen threat actors hit an RDP server, enable Sticky Keys, and then create an account, add it to the Administrators group (as well as the Remote Users group) and then add that account to the "SpecialAccounts\UserList" key path so that the icon for the account does not appear on the Welcome screen. 

Given that this capability is available, and not only via popular offensive security toolsets, I'd recommend checking for RID hijacking during investigations.  Automating the checking means that it's done every time, regardless of who runs the process.

No comments: