0

Recently I discovered that passing the creds of local admin and domain admin to a remote windows 7 machine yields the same result: I gain access to that machine as NT Authority\System. The only way I found to get the domain admin rights back on remote machine is through token impersonation. Surely there is an easier way to identify as domain admin after passing the creds? I used metasploit's psexec module and connected through Admin$ share. I also provided domain name and domain admin creds, yet after running "getuid" in meterpreter I was still identified as local nt authority\system.

2 Answers 2

1

The reason this is happening to you is because of the way psexec works. Psexec uses your credentials to create a service on the remote machine using dcerpc's service control manager. Services by default will use the system principal as their process token. Now to the matter at hand - how do I get back my administrator rights, assuming you don't have a hash, tgt or password - you can't. Why?

Credentials are by design not passed on the wire, only a challenge response hash (ntlm) of a tgs is passed between hosts, meaning that even if the host accepts your credentials you won't be able to use them from that host to other hosts. If you only require local access with the admin user you can use wmi as your remote execution method.(but even that is a network logon which doesn't allow forwarding credentials to other hosts)

0

I don't believe one is "identified" by NT AUTHORITY\SYSTEM. NT AUTHORITY and SYSTEM are not accounts or groups. User accounts contribute their SID as the primary SID to the access token but the access token can contain other SIDs, most utilities/tools reflect the principle SID in outputs and such but when a permission is required windows will look for any SID that has the required permission associated to that token.

The SID only defines a set of permissions, it doesn't need to define users or groups. NT AUTHORITY\SYSTEM can be added to accounts to become the principle SID for those accounts, and will show up in task manager as SYSTEM for tasks that have it as their principle SID. but a user this is not.

1
  • I disagree. You can in fact really, really be identified as such. Try to run psexec /s cmd and then whoami /all -> user is set to system (SID S-1-5-18) and the former/actual user is completely unlisted in the output. Not even as a secondary SID or something. (You can also check with procexp.exe in the Security tab of that process.) (Just tried on Win10Pro.) Commented Nov 4, 2017 at 8:48

You must log in to answer this question.