Join GitHub today
Add post module RID Hijacking on Windows #9595
This module will create an entry on the target by modifying some properties of an existing account. It will change the account attributes by setting a Relative Identifier (RID), which should be owned by one existing account on the destination machine.
Taking advantage of some Windows Local Users Management integrity issues, this module will allow to authenticate with one known account credentials (like GUEST account), and access with the privileges of another existing account (like ADMINISTRATOR account), even if the spoofed account is disabled.
By using a
For more information see csl.com.co.
This module has been tested against:
This module was not tested against, but may work on:
Assigning Administrator privileges to Guest built-in account.
Results after login in as the Guest account.
Assigning Administrator privileges to local custom account.
Results after login in as the testuser account.
Assigning custom privileges to Guest built-in account and setting new password to Guest.
Assigning custom privileges to local custom account and setting new password to custom account.
@r4wd3r, I meant adding a md doc to the branch for documentation purposes: https://github.com/rapid7/metasploit-framework/wiki/Writing-Module-Documentation
In a quick test, the module says that it successfully changed the RID of the guest account, but that's not reflected in the output of hashdump or wmi :
@bwatters-r7 Have you tried to login as GUEST in your machine after running the module?
About your test, I've found this behavior is pretty normal after the module execution, because
This module doesn't change the RID of an user in all the registry keys which it is located, but only in one which causes the integrity issue being exploitable. It means it'll not change the RID from one to another in all the system data (in your case, from 501 to 500), that's why this attack is stealthy ;)
I've done your test and I got the same results as you, but still being capable of login as GUEST with Administrator privileges.
After login as GUEST on the victim host, executed
Thanks for your comment, please try to login to the victim host and let me know if it works.
Sorry about that; I was out most of last week wandering in the woods. Back this week.
My test process:
Second Session (with guest account)
Hi again @bwatters-r7, I hope you enjoyed your well-earned vacation!
Glad to hear you could run the module successfully with the Guest account as Administrator. I've checked your last code review (for which I thank you), and will try to apply all the rubocop recommended style changes.
As I've said at the review, the code you mention only runs if an
To execute the snippet you mention, you can try, for example:
Set the useful privileges of the Guest account (?) to the custom msfuser local account
Set the msfuser (RID: 1000) privileges to the Guest account without using the
You could even try custom1:custom2, but I think with these tests you'll get that piece of code executed.
Thanks again, and let me know if something else is needed.
@bwatters-r7 As I should have thought, you were totally right about the missing
I've adjusted every rubocop recommendation, and got 0 offenses. However, you can do the tests I've mentioned in my previous comment if necessary.
@r4wd3r No worries; I am significantly more comfortable in C or Python than I am in Ruby, so most of the rubocop stuff you got dinged for is the same thing I got/get dinged for, too. Rubocop is a great teacher for accepted Ruby syntax if something else is your first language.
Apr 3, 2018
added a commit
this pull request
Apr 3, 2018
The post/windows/manage/rid_hijack module has been added to the framework. It quietly changes the relative identifier (RID) of an existing account to grant system privileges. You can then authenticate with known credentials for another account and use the privileges of the elevated account, even if the spoofed account is disabled.