Closed WingsOfDoom closed 4 years ago
Sorry for the delayed response, but hopefully the information will still help in the future.
Below is how I interpret the screenshot.
You logged into the SQL Server instance as "USFUN\pastudent56", a sysadmin.
It was possible to read the impersonation entries, because "USFUN\pastudent56" is a sysadmin. Below are the entries.
USFun\RDPUsers -> dbuser dbuser -> sa (sysadmin)
When the function is run, no escalation is executed, because "USFUN\pastudent56" is a sysadmin. This is by design, because sysadmins can impersonate anyone at any time. Here is a link to a blog that provides an overview. https://blog.netspi.com/hacking-sql-server-stored-procedures-part-2-user-impersonation/
At first glance, the impersonation entries appear to be valid. I believe that if you log into the sql server instance as a member of the usfun\rdpusers group you'll see actual privilege escalation take place when you rerun the function. However, if the usfun\rdpusers has been assigned the sysadmin role then the same scenario will play out.
I can also confirm this issue, I'm on the same box. I think the issue is due to the domain group having the ability to impersonate rather than a user.
When forcing the exploit by making the condition always true I get the following error:
Up!! Same error hahahahaha #CRTE
Up!! Same error hahahahaha #CRTE
I had the same issues as mentioned here. I fixed it, pull request can be found here #70
@nullbind hopefully you could add to. I only did it for the .ps1 file but should be the same for the others.
When there are multihops needed to privesc to sa, it appears the method is giving false positives, see screenshot for refference: