Hello,
I am in the first course of the Host & Network Penetration Testing, the System/Host Based Attacks, in the Windows Privilege Escalation section, Access Token Impersonation video. There is one specific thing I don’t understand:
→ Minute 14:40, after successfully impersonating the ATTACKDEFENSE\Administrator token, we attempt to get/retrieve/see the privileges that we have by typing “getprivs”, but we are returned with an “access denied” message. Why? Why don’t we have privileges to run “getprivs” since we technically are the Administrator user? Why don’t we have privileges to run “getprivs” but we do to migrate to Process Explorer? In the same video, we couldn’t migrate to Process Explorer under the NT AUTHORITY\LOCAL SERVICE account, which is why we go ahead and impersonate the ATTACKDEFENSE\Administrator account.
@AlexisA I am really looking forward for the Privilege Escalation course, which, as far as I know, it is still under development and you will most likely cover these topics there.
Thank you very much in advance.
Hi there, from my notes, If we try getprivs at that point we still get “Operation failed: Access is denied” Because if you double-check sysinfo output you will see that
- our meterpreter session is still
x86 (32-bit)
- while the target system is
x64-bit
Oncne you migrate to x64 explorer.exe process:
ps -S explorer.exe
migrate {process_id}
If you check again the updated results for:
getprivs you will see you have all privileges now ( Edit: I mean, no more access denied)
and if you check sysinfo you can see that both, the meterpreter session and the target system have matching architecture x64
I hope that helps
Thanks for your reply.
I actually performed some testing in the attached lab and did some research with Google and I think I understand it more now. I still might be wrong about it though. Here’s the breakdown:
We run the rejetto exploit with a 32-bit meterpreter session. It’s fine cuz we end up migrating. Right after obtaining the meterpreter session, we run “getuid” and we see we are currently logged in as NT AUTHORITY\LOCAL SERVICE. This particular account has its respective privileges that we can retrieve with “getprivs”. Now, we are not able to migrate to the explorer.exe process because it requires elevated privileges, but not because we have an x86 payload - that does not make any difference here. If we had the privileges to do it, the migration process would take care of providing us back with an x64 payload or it would spit an error saying we cannot run the command since the payloads don’t match or something like that I would assume (it’s actually the migration process itself that requests it and it gets sent back to us; take a look at this) → [metasploit - How does 32 bit Meterpreter migrate into 64 bit process? - Information Security Stack Exchange] - I actually redid the lab but creating an x64 payload to double check this and I still couldn’t migrate. Therefore, it’s gotta be only the non-elevated privilege. If we type “ps”, we can see a list with all the process with some of them having ATTACKDEFENSE\Administrator privileges and others having NT AUTHORITY\LOCAL SERVICE.
Now, after loading the incognito module and impersonating the token, if we type again “getuid” we can see we are now ATTACKDEFENSE\Administrator. Typing then again “ps”, we don’t see anymore the NT AUTHORITY\LOCAL SERVICE privilege next to the processes that hey had it before.
*** My honest impression here *** is that due to this impersonation, we kind of still are NT AUTHORITY\LOCAL SERVICE but with an ATTACKDEFENSE\Administrator access token. It is because of this impersonation, *** I think ***, that running the command “getprivs” does not retrieve anything until we migrate to another process. It’s like we are “somewhere in between both accounts without actually being one of them” if that makes sense… Once we migrate to any other process, the command returns the privileges of the account we are in (in this case, ATTACKDEFENSE\Administrator). I did the following last experiment to confirm it: after migrating to the explorer process and obtaining an x64 payload, I migrated back to another service that is being run with NT AUTHORITY\LOCAL SERVICE and with an x64 payload too (for whatever reason, typing “getuid” after performing this migration kind of “downgrades” the privileges to NT AUTHORITY\LOCAL SERVICE instead of keeping them as ATTACKDEFENSE\Administrator but anyway…) – Also, note here that we cannot migrate back to the service that we were in the first time right after obtaining the meterpreter session, due to the rejetto exploit module deleting the payload after obtaining the meterpreter session (I think this is the reason!) - If we attempt to migrate back to that process, it will tell us it doesn’t exist! – As I was saying, after migrating back to this other service, I performed the impersonation again to elevate my privileges and I already had the x64 payload but I still got an “Access Denied” when I run the “getprivs” command. Again, most probably due to what I explained above.
I hope this makes sense. If not, I hope to learn it properly at some point.