 I'm Luke Jennings, and I'm a security consultant from the UK, and this talks basically about abusing Windows access tokens. It's nothing completely new. It's an issue that's been known about for some time, but I think it's something that hasn't really been taken seriously before, and I'm just kind of showing that it is a very serious issue, and I've kind of ridden the tool to demonstrate that, because I'm a penetration tester, so from my perspective it's very useful, and it's been useful on client tests. So the issue is that really vendors have been improving the security of their software for many years now, and post exploitation has become a lot more important because of that. Microsoft are probably one of the best examples of that, because they've gone from a position where they were notoriously poor in their security prospect, but since the Trustworthy Computer Initiative, they've got much, much better, and now it's a case of where the number of systems you're going to be able to compromise on a test is going to be much fewer, so you really need to make the most of what you have if you're trying to prove something. So post exploitation has been addressed, to some extent, with other things. Metabloit is a great example of that, particularly for Windows with the interpreter payload. I don't know if many of you use that very often, but that's excellent, and there's passive X payloads as well, and they're very useful on tests, particularly when proxy servers are being used for web access externally. But from a penetration tester's perspective, not much has been done with Windows access tokens. Now, they're kind of integral to how single sign-on works in an active directory environment. If you think you log on to a desktop and you then decide to access a remote file server on the same domain, you're not requested for your username and password again. The connection just goes through, and that's because the tokens that were involved, they cash your credentials, so in the Kerberos sense it'd be a ticket granting ticket when it's NTLM authentication, it'd be the NTLM hash years, and they enabled the authentication to just go transparently through. The other issue is that on penetration tests, I found it very difficult to convince clients of the importance of keeping their administrator's desktops and other systems just as secure as their servers. Classically, you might talk about installing keyloggers and how that could be used to compromise other servers, but Windows access tokens are another way of doing it, and it's more powerful in some respects, which I'll be showing you later. So, just to give a quick overview of them, they're not particularly well understood, I've found. I mean, their counterpart on Unix systems is obviously user IDs, and it's kind of integral to how you learn Unix. Whenever you run an LS command, you'll see the user IDs that files are owned by, you'll see the current permissions that are set, but Windows is kind of hidden from you unless you go looking into it, you don't see it normally, and they're inherently more complex as well, so it just leads to people not having some misconceptions about them sometimes. But processes essentially have a primary token associated with them, and that determines their privileges. So, whenever a process tries to perform some sort of task, the operating system consults the token to see if that's allowed. But Windows has been a multi-threaded operating system, it also allows other tokens to be used, and threads can then temporarily impersonate those tokens, and a good example of that is in a client server application, perhaps an FTP server. If a client connects through Windows authentication, the FTP server process will be running as a service account, but then Windows authentication that creates a new token, and then the thread that's serving their request can temporarily impersonate that, and then everything that it does from then on will be under the context of their privileges. And tokens essentially have four different security levels. We're only really going to be concerned here with impersonation and delegation, because they're the interesting ones, and basically a delegation level token is one that stores credentials, so it can be used to access external systems. An impersonation token is only valid on the local system, it doesn't have the necessary credentials to access a remote system. And basically, normally an interactive log-ins, if you log in at the console, if you're desktop or by terminal services or something, that will result in delegation tokens being created, and then that's why when you access a remote file server, for example you don't need to enter username and password again. But non-interactive log-ons, going back to the client server example, they normally only result in impersonation level tokens. But under some circumstances that's not the case, and you'll get delegation tokens, if you've trusted a computer for delegation, say, EFS is an excellent example, because if you want a remote EFS server, the server needs the password to actually decrypt the file, so in order to do that, it needs the delegation tokens to be present. How do you go about abusing? Basically, if you compromise a system, there are going to be some tokens present. Depending on who's logged on to the system, what's going on, dictates what ones are going to be there and what the privileges are, what you might be able to do with them. So as a consequence of that, they can lead to privilege escalation of some sort. There's two primary types, and one I've kind of called domain privilege escalation. That's the idea of compromising one server, finding a delegation token present and using it to access another server. A good example of that is if you're trying to get into a database server and that's very well protected, but then you find an administrator's desktop is insecure and then you take his token and you can then use it to access the database server. That would be a good example of that. Local privilege escalation is less common, but under some circumstances it can be performed. So if you're not running the system, a good example of this is with SQL Server. I know Dave Litchfield put a paper on databasesecurity.com some time ago. A brief paper just dictating this, the theory of this. The idea is if SQL Server has been configured to run as a low privilege service account and you compromise it, then if an administrator actually connects to that server via winners authentication using enterprise manager or query analyzer or something, that will create a new token that will be within the SQL Server process space so then you can actually use that token and impersonate it and start executing commands as administrator and escalate your privileges locally. So if we have a tool to demonstrate these issues from a penetration testers perspective, the first thing we'd want it to do is to be able to enumerate tokens that are present and show us what's there. After that you'd want to perform common post-exploitation tasks. Now, a common example, you might want to execute processes, create a new command.exe run as a different user, for example, with a token that you've found. You might want to force remote connections, the idea being that if you can force a kind of entity-alem authentication, you can set up a sniffer and use the challenge response hashes that you've captured to try and crack them and then you might have the underlying passwords as a result. You might want to perform some sort of user management trying to add users to other hosts or to groups. So I've basically ridden the tool, which I call the Incognito. I've just called it that because it allows you to assume someone else's identity rather than go for something generic like a token dump. But the functionality that's present at the moment, and it is an ongoing project for me, it's something that I will add to you, but currently it has the ability to list tokens that are present on the system and you can do that by username or you can do it by group, for example, if you're looking for a token that's belongs to a particular group and there's maybe 100 users that's a member of that group, rather than look out for 100 different users, you can just look for that group. It can force remote connections, so you can try and snarf the challenge response hashes. You can create new processes with a token of your choice. You can perform common user management tasks. Additionally, you can use it remotely if any of you have used PWD, I'm sure you have if you use the remote option for it. It's a similar concept, it communicates via named pipes and installs a service, which it then cleans up after it's executed. So how does it go about enumerating tokens? Well, basically you can use the underlying, the low level API calls that Windows presents and it uses NT query system information. Now that's something that many other security tools have used before. This uses it to enumerate all the handles on the system and then it combines that with another low level API called NT query object and by doing that it can actually determine which handles point to tokens and which points to something else. So it filters out process handles and file handles, socket handles, etc. and just leaves you with a short list of the token handles. And then you can use other API calls to actually get information about those tokens, find out what the privilege levels are, find out what the usernames and groups associated with them are and whatever information, other information you'd like to get. So that's just a, I'll be showing you a demo later, but this is just a screenshot here. I executed this on my laptop some time ago, just kind of demonstrating the basic issue. You can see that it's listed some delegation tokens being available. If you notice the Luke J user there, that was just because I was logged in at the console and some of the other ones that are available are just kind of, they're always there as another standard service accounts that Windows has and you see local service, network service, system, etc. Because the processes can also be created using it. Now, if you create a process on Windows normally, you'd use the create process API call, but the trouble with that is even if the thread is executing whilst impersonating a different token that's not the same as the primary process token, it will still create the child process using the primary process token. So for the purpose of this tool, you need to create processes user API call. That actually allows you to specify another token and as such you can manipulate them in that sense. And doing so, as I mentioned before, you might want to create yourself a new command.exe process, so you've got a command prompt running as another user, but it's not limited to that. Maybe you want to create an active directory process to manage users and run that as a different token you've found on the system. Again, that's just a quick screenshot just showing how I've got a command.exe up. I'll show you all this properly later, though. It can also, as I said before, if you use the WNet ad connection API call, you can actually force connections now. If you do that to a server that's not in the same domain like if you make it connect to your own server that's not part of a domain, then it won't use Kerberus authentication. It will use, it's downgraded to use an NTLM authentication. And consequently, if you run, say, the Metastroy SMB sniffer module or something called use Cane enable, you get access to the hashes. And ideally, you might get it to downgrade it to use Landman and then use a static challenge and you could use rainbow tables to crack it much quicker. Finally, user management. It's just an idea of adding users to the host. All the kind of net commands are available. Obviously, it has API calls as well. And so using them is possible to add users or modify group memberships on remote hosts, not just the one you've actually compromised, but you just take the token on the system you've compromised and then use it to try and add a user to another host, such as the main controller or a database server or whatever your final target is. So I'll just get on to showing you a demo of it now. I've basically got a setup here where I have a Windows 2003 Enterprise Edition Service Pack 1 box running as a domain controller and then I have a Windows 2000 Service Pack 4 box running as a domain member. So for the purposes of this, I'm actually going to assume that we've compromised the Windows 2000 box and we'd like to see what we can do from there with the tokens that are present on the system. So I'll kind of assume that we have the local administrator password for the box, for example. Can you just bear with me while I just set this up quickly? Okay, that's good. I hope you can all see that. Is there anyone having major difficulty seeing that? Okay, I'll try and make it a bit bigger. Is that better? Sorry? If you like. Yeah, we'll see. I've run this on the Windows 2000 box and you can see that at the moment the only delegation token that's available beside the system is a low-proof SQL. That's actually part of a SQL server account which I'll be coming to later. But I haven't logged in as a user yet, so I'm going to log in to the server now as the domain administrator. If I run this again, you can see that as a delegation token that's available, it's the company administrator that's actually the domain administrator token. I could do the same to list by group and you should see that the main admins will be listed. Okay, so you've got domain admins, enterprise admins, so forth. So that means that I should be able to actually access remote servers with it. For example, I've created a new process, a command.exe process. Right, so that should be running as the domain administrator now. So just to prove it, I connect to the actual domain controller itself. Okay, so you see I've got access to the main controller as a result of that. But additionally, I'll exit that, should be able to actually perform some user management tasks like add a new domain administrator automatically. What's happened? Sorry, but at least we seem to be having quite a bit of bad luck today. Okay, so there we can see we've added a new user to the domain controller. Now if I just add it to the domain admins group, now if I show you the actual domain controller itself, you're not getting a signal. I think we're going to have to give up on this demo. Okay, sorry about all this. Okay, you can see that we've added a new domain administrator there that's been successfully added as a result just compromising that token. I think given the amount of time that's gone, I'm going to skip the next part of the demo and just move on with the talk to get to the more important things. This hasn't moved on either. Ah, okay. Okay, it might be thinking at this stage, okay, this is maybe serious, but if I'm not logged on at the moment, my account's safe. It's only when I'm logged on that it's an issue. But when I was testing all this, I found that that's not always true. You'd expect that when you log off, all the tokens should be cleaned up completely and they wouldn't be present anymore. But I found that on unpatched systems, and I know the exact hotfix that did this, but I couldn't find any information about it, so I presume it was something silently patched. Maybe that was unintentional, and it was just a consequence of some other change that I don't know. But tokens, once you've logged off, they're still reported, but as impersonation tokens, they're not reported as being delegation tokens, but if you actually try to use them, it appears that they can still be used to access remote systems. If you use that, then you can basically take a system that someone's logged into some time ago, logged off, and if the server hasn't been rebooted yet, the token is still there, and you can still actually use it. I've given an example on the slide there of if you logged into some insecure box a month ago, that's maybe not strictly true, because if it's in a curved environment, the ticket granting ticket will eventually time out. But you still might be able to force a connection to a remote server and snarf ntlm hashes, but you might not be able to use the other features of the token if it's been in excess of the time out. So, I'm going to skip the demo of that again to move on, but just hopefully trust me that that's true. The other issue is that whilst developing this, I thought being a plan and metasport project used it a lot myself before. It's been very useful on penetration tests. I thought the meterpreter itself is very useful and people have already put functionality into it, such as the kind of functionality of PWDump has been embedded as another module, the hash dump, so you can use that from within a meterpreter session. However, if you could put incognito's functionality within a meterpreter session, then you'd be in a very powerful situation because the meterpreter just runs as a thread, so you could actually get the meterpreter thread to then impersonate a token that you'd like to use, and as a consequence all the existing functionality of the meterpreter would then be run in as that, so you'd get all this extra functionality if you will for free, in a sense, just by impersonating another token. So it would be a powerful combination of the two tools. I wrote an extension for that now. If you check the CD's, the code for incognito is on the CD, but the metasploit code isn't, but I hope to at some point send that to the metasploit developers and get it integrated, so just keep checking the SVN repository. But the other point with that is that if there's probably more aimed at a system administrator that wants to just run a big test of the network, but the metasploit has gone a lock down the route of automated exploitation in recent times, and because you can actually configure the metasploit through Ruby scripts and get them to automatically run as in as a metasploit instance is created, technically you could configure metasploits, sweep a network, compromise every box it can, and then load up the incognito module within the metasploit session and try some of the brute force type approaches like I showed you before, of adding users to hosts and just perhaps say try and compromise every system possible and try and create yourself a new domain administrator and if you found that there was a domain ad being logged on to any of those hosts, then after you've run that you'll find that there's a new domain administrator with a password of your choosing ready on the network. So obviously that would be a good case for a system administrator to be able to justify some more budget for security. And I'm not sure if I'm going to be able to demo this as a result of some of the issues we've been having unfortunately, but you just have to try it out for yourself once the code comes out. Now, one of the other issues I thought about with this is that what I've done is very useful if you compromise a system you just want to try and see what you can do with it that's in addition to what you might normally be able to do, but often a penetration test is very focused. It might be that it's a very large environment, but a company is just interested in, for that penetration test they want to know of the security of their database servers, for example, the running SQL server. Now, you might try and attack them and find that they're really well protected. They've taken lots of measures, they've got a fully patched, strong passwords they're using host-based intrusion prevention systems whatever you like, and you might fail with your standard penetration attempts, but then you might think, maybe I can find some tokens somewhere else, but it's not really going to be very feasible to just start hunting the network and compromising any system you can in the hope that you'll find some sort of token somewhere that's going to allow you access. That's just not going to happen normally. So what would be really great is if you could actually sweep a network trying to look for systems that might have those tokens first and give yourself a little short list of extra systems to compromise and then if you're successful you'll have found a token on another system and then be able to get access to them that way. So it'd be a precision strike if you will. Going back to the example of a database server with looking for a database administrator's desktop, you'd want to be sweeping the network trying to find out what desktop he's logged into so I kind of looked into that and found that there's a fairly simple way to go about that. It's not perfect but it's a lot better than just the brute force approach and I kind of wrote another supplementary tool to go along with the Incognito and it actually makes use of an API call called Network Station Username and it's designed to a new rate that we're currently logged on users but as I mentioned it's not perfect the problem is it will still list users that have logged off until the reboot happens then they'll be there so if it's a system that's not rebooted very often you might have a lot of users reported of which many of the tokens might not be available. The plus side is that what I spoke about before on Unpatch systems with the tokens still hanging around you might be able to find those systems so it depends how you look at it there may be some false positives but there's uses with that as well. Now in order to use that API call you only need a standard domain user account so on a pen test it's kind of reasonable to assume that if you're doing an internal pen test you're going to maybe compromise at least one user account through a weak password or whatever or even it might be feasible to suggest that you're given a domain user account to start the test with because if you're testing from the perspective of internal employee they're probably going to have an account already so it's quite likely you're going to be able to use this functionality so I'll just quickly demo this now ok so what I've used there the account is called user that's just a domain user account standard low privilege domain user account here and I've rebooted the Windows 2000 server since the last demo so there's no one logged on to it and the only thing that's come up is the SQL server account that's running there but if I log on now there's a domain that I've been for example you'll find that now you can actually see that the domain has been logged on there now I've only looked at one host here but you can just give it a file with a list of IPs or system names and let it sweep a network and then just grep through looking for any accounts you're interested in and in that sense you might find some other systems and you've got a short list of things to attack and consequently you know you might be quite efficiently be able to locate that system penetrate it if it's of a weaker level of security and then use the token to access whatever sensitive system you're really interested in ok so just a basic methodology for using that if you want to kind of conduct targeted penetration testing then you just need to decide on your targets again the good example is critical database servers conduct your conventional penetration testing but if that fails you want to make sure you've done your enumeration well and ideally located what users can access it so perhaps you've got null sessions and enumerated the fact that three different user accounts that you've found out from the wiki are actually the database administrators for that and then you think ok that are the accounts I'm looking for and then just use find token as it just showed you and very sorry I just realised that I didn't show the slides never mind yes so you do use those tokens try and penetrate them if you can then you've just got yourself access to those database servers ok so finally a word on defence I mean this is a kind of feature of the operating system so it's not something you just patch but there is kind of standard advice you could follow that if you take it into account the security policies you really minimise the risk that this poses and the first obvious use is limiting the use of privileged accounts particularly using run as is a good example so you know that's fairly standard security advice but I mean I found most people a lot of clients have dealt with that they never use it but if you do then it's very useful because it's just minimising that window attacker has to find the correct token and additionally I found that even on the unpatched systems when you've logged in once you've logged out the token still remains even on those systems if you use run as once you close the process that's still cleaned up properly so that's an additional bonus for any unpatched systems out there there's also an active directory option called account is sensitive and cannot be delegated unfortunately that doesn't work for interactive logons but it does work for non interactive logons where delegations being used are highly privileged accounts you just want to make sure that you don't fall victim to a delegation level attack when it's a non-interactive logon like an EFS server then if you check that it minimises the risk obviously you lose the ability to access remote EFS servers or use any other form of delegated authentication if you do that but it's a small price to pay if it's going to protect you but the biggest piece of advice is to just not rely on only securing what you consider your real sensitive servers there are many other ways to get into systems and in particular you've got to think about your administrator's desktops you can't just have them on a kind of roll out that's unattended where there's no real patch management plan involved like there might be with your servers you've got to really think about everything sometimes people you've found before local administrator parcels might be set the same you might be aware of that and as such haven't set those the same and think that means you're secure but obviously the ability to take tokens and use them means that you can still access other servers so you've got to think about that but another thing is to really change your way of thinking about it's easy to think about security in the sense of either account based security or system based security with accounts you think this is a sensitive account and as such I'm going to protect it well by using a strong password or this is a sensitive system so I'm going to protect it well by patching it well and having it configuring other policies and hardening it but really you need to think of them in combination because a resource is only as secure as the weakest system that any account has access to it is currently logged into and using and the more systems you log into and the weaker ones the more you expand your risk in that sense you've got to think about that and so really you need to have policies governing what security requirements the system has to be able to meet if you're going to use a particular account to log into it and then additionally you just want to try and separate your privileges again that's fairly standard security advice use separate administrative accounts for different things where possible particularly development and test systems if you do that hopefully if a weaker system is penetrated they might take the token but it might not get them access to it won't get them access to the things they really want so that's really all that can be done so yeah as I said there's no real patch but follow the right kind of advice and you can minimise your risk but if you don't take it into account at all you could be exposed a lot more greatly than you imagine okay so that pretty much concludes the presentation I'm sorry about all the technical difficulties we had I particularly wish I could have demonstrated the Metasploit action for you but I just had to wait for the code that's it, thanks very much