Funny story -- I have a number of virtual machines setup for various types of exploitation such as the machine I used below for this RID Hijacking post.  When I'm done with the exploitation, I will revert them back to their previous state to keep things clean and in order to have a fresh slate for my next "project".

After finishing up this post, I reverted the machine to a point further back than I thought and I was unable to login to the machine with the known password.  Quickly thinking, i was confident the box was vulnerable to MS17-010 but I was incorrect.  :\

This particular machine is hosted on a Xenserver hypervisor which allows you to detach the disk and reattach it elsewhere -- which is what I did.  Upon accessing the drive from another virtual machine, I changed the utilman.exe executable with a meterpreter executable.  I then reattached it to the original host.  If you're not familiar with this hack:  

"Utilman.exe is a built in Windows application that is designed to allow the user to configure Accessibility options such as the Magnifier, High Contrast Theme, Narrator and On Screen Keyboard before they log onto the system."

More importantly, it's accessible prior to login and it launches on behalf of NT AUTHORITY\SYSTEM.  Or in my case, my meterpreter executable launched on behalf of NT AUTHORITY\SYSTEM.  Obviously this wouldn't have worked had the drive been encrypted which is another reason to encrypt your hard drives!  

Anyway, moving along to the real topic...

RID Hijacking is essentially an account impersonation that can allow for persistence if undiscovered.  If this is new to you -- RID is Relative Identifier and SID is Security Identifier.  When we look at the local user accounts on this system, we see the SID which starts with "S-1-5-21" and it ends with the RID.  In the case of the Guest account, we see the account's RID is "501".  Below the Guest account, we see my account which has the same SID but the RID is "1001".  

How we get on the machine isn't all that relevant, it's that we are on the machine and we want to setup persistence. 

I catch my shell:

I background the session and I move over to the post exploitation module:

My target is the Guest account and I'm going to change the Guest account RID to the RID of my account which has administrative privileges.  I'm also enabling the Guest account and I'm setting a password.  

We execute and we are successful! 

Let's take a look at our Guest account once again:

As far as we can tell, it looks exactly the same as it did previously.

Now that we've taken over the account, we could use psexec or any other methods for accessing this system.  For this exercise, I'm jgoing for RDP because I think it shows us something interesting.  When we login with the Guest account:

We are presented with:

A bit of confusion on the part of the system but not surprising because we are Guest with Vince's RID. 

When we execute whoami /all :

We see that we're using the Guest user account but now that we are logged in, we also see actual RID we're using for the first time.  Perhaps there's another reference buried in the registry but aside from that possibility, the above is the only way I noticed the difference.  

Not an ideal solution but:






From what I've read, it seems like the Guest account is one that people like to reference when using this technique.  If we were pinging off of changes to the Guest account, the biggest hint would be a change from Disabled to Enabled. 

The script above detects the opposite but we can change $false to $true in order to look for the reverse.  Basically, this will look at the Guest account, if the Enabled state is matched, it will launch calc.exe.  In the real world, we could send off an email notification.  In a previous post, I have an example for assigning the query to a variable and when matched, it sends off an email.  It would be fairly simple to cobble these two together.