 Hey, how's it going? Yeah. So this is a meta post exploitation. I just got a question. This is still a hacking con, right? So you guys mind if we just talk about some hacking techniques for a change? A little bit of demonstration right on. All right, so I'm Val Smith, a founder of Fensit Computing, work on the Metasploit project. Basically break into computers, reverse things, play with malware. I'm sort of the new face here. I'm Colin Ames. I work for Offensive Computing and do pentesting malware analysis. You know, the usual bit. Nothing terribly exciting. All right, so we just wanted to warn you guys we discovered this really crazy DNS, you know, can destroy the internet, kind of freaked us out. So we wanted to share it with you and make sure you're aware. We're going to show you in this next slide here exactly what it is. So watch out. Also, since every other talk we've ever given is pretty much just pages of assembly, we thought we'd have a requisite page for you so you wouldn't feel like you missed anything. All right, now that's over. All right, so basically this is a follow-up to the talk H.D. Moore and I gave last year. I don't know if any of you saw that one. It's a collection of strange, weird, old, unusual ways of breaking into computers. Well, this year we wanted to do the same thing, but it's about what you do after you break into the computers. Okay, so how do we define post-exploitation? Well, we see it as what are the steps you take after you've broken in, whether your goals are to move on to other computers or escalate your privileges or what have you. A lot of the traditional sort of things people do nowadays are root kits, things like that. We're going to talk about some different stuff. And there's several subject matters under post-exploitation that we've broken it down into, like password management, feature modification, persistence, stealth, things like these. We're going to sort of go over each of these topics and demonstrate a few techniques under each one that we find kind of interesting. All right, so getting root is just the beginning. A lot of people focus on, well, I broke into the computer, I got root, I'm done. We really feel that that's not where it's at. You want to look at where can I go? What data can I access? What things can I get into from there? What habit can I wreak? Basically, how do you scale to attacking thousands of hosts? If you're keeping track of one computer at a time, it's kind of hard. And you see botnet authors are very successful at this. We're sort of ignoring the botnet technology for this particular talk. All right, so the first subject we're going to talk about is password management. And what this means to us is on large pen test or attacks, if you're breaking into lots of computers, you want to be able to keep track of what passwords go with what computer, what hosts, what access these passwords give you. So, you know, you want to be able to test passwords that you've captured and cracked on multiple different systems and see if they're using shared passwords. This is really common in large networks. You want to build your word list files, these are your dictionaries that you're using to crack. And so, you know, this is pretty easy when you're breaking into one, two, or three computers. But when you're doing 10,000, 30,000, it gets to be really big and difficult to organize. And, you know, Val's very fond of trying to do all of this in, you know, notepad or wordpad, textpad. And it just doesn't scale to this point. So really, you know, our goals here are we want to be able to acquire it and store it in some meaningful manner and organize it and track it. I mean, so this is useful both in attacking and gathering, you know, further intelligence on what targets you might want to hit, as well as clean up later. And so, basically, we just want to expand this out and show you the pieces of it. So basically, like I said, there's many stages. The first ones are, of course, acquiring hashes or, you know, cash credentials or so forth on a host, listing tokens, what's available there, several tools that we can do that, some choices here. Then you have to prioritize, make some decisions, decide what you want to do with it. And then take your choices that you want and crack them or rainbow tables or however you want to approach these passwords. We don't want to talk about cracking here. People do it. It's not hard. I mean, there are some idio-sequancies to it that we just can't get into right now. And then really, it's, you know, we want to track that so you can look back at what you've done, where you're going, as well as reuse it. So, again, here's some more existing tools. You know, you have Lofcrack, Canine Able, and these, you know, core impact that will allow you to view a session, view some tool types, hash types, decide how you want to crack them, if you're going to use a rainbow tables or just a John type approach, and then basically, you know, how we want to track them. And this is just, we're trying to show you sort of a snapshot of what tools are out there and what limited features they already give you. So, and here's a nice little screenshot just to kind of give you an idea. You know, you have Lofcrack and Canine Able. I mean, there's some good information here, but all in all, not terribly useful to you when we're talking about tens of thousands of boxes. Is this mic work? I'll write it on. Sorry, our voice is a little rough. We've been in Vegas for about a week, so bear with us. And as we, you know, the poor man's KVM as we just, you know, unplug and re-plug in. So here's a basic demo of MetaPast as some kind of split that we, or a MetaSplit module that we've created. So basically here we are scanning a network to show you some clients. We're basically going to start from like 20 to about, you know, 55. And some basic options that hopefully we'll zoom in on and you can see a little better. Ah, there we go. So, you know, we generally, you can specify a dictionary list. You can have where you want to place these files. In this example we're using FGDump, which is not, it's terribly detectable by AV, but this is to demonstrate as we run out of time to finish the code. As we get later, we're going to integrate this further in and use Meturpeder as opposed to a lot of these methods for actually acquiring the hashes and fully utilize the MetaSplit framework for it. But you can plug in your dumper of choice to this right now. Yes, it'll do what it wants. And it's also, you know, we want to acquire the password hashes as well as tokens on each host. And as we kind of go through here, kick in a few more options, we're going to specify the range of hosts that we want to go through. Type faster. And, you know, some general things, you know, 10 seconds for a timeout. That's just way too long. I'm way too impatient for that. So let's knock it down a bit. And then we're going to go into a user. This is a user that we have already acquired and hacked. And so that's important here. Like we have the password in our dictionary list. So we have a specific number of passwords we've already acquired for this network. And so like we're saying, this is post exploitation. We have one host. We have one password at least. And we know at least one user here. It's local Val Smith was a local administrator. As we kick it off, um, you'll also see. So we'll have output. The black screens are actually dumping. And if you look over on the right screen, you can actually see. Well, not really. But, you know, so here's some output. We have some tokens that are going through showing that we're dumping some passwords tokens. And up in the right hand corner, you can actually see the hosts broken out by IP ranges. And then you have a dot PW dump as well as just a normal file. And these are each hosts. It's been executed and exploited and gathered into further intelligence so we can dig deeper. And so then we're going to go ahead and dump our acquired information into loft crack here. And we've prepended the last octet onto each because well, as you'll see, there's quite a few administrators going through here. So it's, you know, here's to aid in your continuation, where you've cracked what you're going to do. And, you know, some fun passwords up there. You know, kind of amusing. So what this thing is doing is basically you start off with one account that you've hacked on the system. You feed it to this and it's going to go out across the network, whatever ranges you specify, and try this password on every system and then use whatever access it has to gather intelligence, like other passwords, accounts, tokens. So it's really automating that process of reusing your password and connecting to thousands of systems. Oh my God, it worked. All right, so now we're going to get into a topic, stealth versus persistence. Back in the old days when people talked about the concept of root kits, this is basically a set of software that you would use to maintain root on a system. You know, you would upload your files and then you use them so you could come back. Nowadays, everyone when they talk about root kits, it's pretty much all about hiding your activities rather than maintaining access. You know, if you see any of Joanna's talks, it's like, how do I hide my files and my network access and things like this? These two concepts in our minds still go hand in hand, but we sort of split them out because we sort of, we see them as really different aspects of post-exploitation. Okay, so what is persistence to us? Well, to us it's maintaining access. Just being able to re-access the target that you've broken into. And why would you want to do this? Well, targets can get patched. A lot of exploits can be one-shot only, meaning once you use your exploit and break in, the system's unstable and you can't break in again using the same exploit. Often you need to return to the host you've broken into multiple times afterwards because either you don't know how useful the target is or you've learned something further on breaking into the network that tells you, oh, I need to go back and get this information or this data. The goals of persistence in post-exploitation are really access to the target as often as you want. This is sort of a huge area of study. There's lots of people working on tools for this. Also keep in mind sometimes persistence doesn't matter. You know, sometimes speed is more important than persistence. All right, so we've broken down sort of the stages of persistence, which start off as the initial access. This is when you exploit the box, either with, you know, a standalone exploit or stolen password and you break in. At that point you've got to make a decision. Well, what do I use to get persistence? What do I use to get back in? Am I going to upload a back door? Am I going to upload a root kit? These types of things. It's really OS dependent, target dependent. It depends on how well you know your target. Then you're going to set up your persistent mechanism, whatever it is, and then you're going to come back to the target on successive occasions and get what you need. I'm a big advocate of cleanup. I've seen like a lot of pen testers leave 100 different tools on target. This gets you caught. It makes forensics really easy, things like this. So leave no trace. There's all kinds of existing tools to help you maintain persistence. I'm not really going to talk too much about these. They're all pretty cool and everybody uses them, but they're conventional. The existence of one of these things on your system tells the target that they've been hacked. So we have a couple of different perspectives on persistence. If you can always re-exploit the target, then why worry about it? This is unlikely to be the case, but occasionally it is. What we really prefer to do is inject, add, or modify new vulnerabilities into a target. It's really hard to determine maliciousness when the system just has a bug and they're not aware of it. If they discover the bug, it's not like discovering a root kit. It's like, oh crap, I've been hacked. If you discover vulnerable pieces of software, have I been hacked? Or what's the deal? It's very difficult if you watch any other talks any other year. It's very difficult to find bugs, people are writing fuzzers, people are doing all these crazy things to look for bugs. Now imagine someone is purposely putting bugs in the code. That would be very difficult to detect and even more difficult to understand is this on purpose or is this just accidents of coding. We also like leveraging existing persistent admin access. There's lots of things out there, especially in the enterprise, that people use legitimately to have access to the hosts they're going after. Things like Nagios, which is a big monitoring software. On some attacks I've done, we'll actually add our own Nagios checks, which go out and give us root on all the systems or access to all the systems that it's checking. Configuration management systems like CF Engine and SMS are really good to attack because they basically have access to every system in the network and they're pushing things out. So if you break into those and just use what's there, use what the target has left for you to use. Here's some examples and we're going to show some demos of some of these concepts. So imagine you're going after a machine and lots of admins use BNC to remote administer their machines. So you break into the computer somehow and you want persistent access but you don't want to put in a trojan because they're likely to find it. Well, replace the existing BNC with a vulnerable version. It's got an exploit like authentication bypass. Make sure that you copy the password so that the target doesn't realize that his software has been modified. His BNC is going to work normally. When he logs in to do his thing, it's still going to be there but you're also going to have an exploit that you know will work every time and you haven't added any root kits or backdoors. Another really sneaky thing we like to do is to add vulnerable code to applications. It works really well on web apps because they're not compiled so the code is sitting there for you to modify. Do things like take out user input validation. A lot of these web applications have forms that people fill in. We'll go in there and take out the security checks so that you can exploit them later. It's unlikely that the coder is going to notice that and say, wow, someone modified my code. They just maybe won't even notice it ever. The focus here is on vague intent. Never be solely malicious. Never have your actions only have one outcome. Reintroduce patchbooks. Here's a more concrete sort of real world example of this. We're going to show a demo so I might not talk too much on this slide but basically adding an extra field into a form with a little bit of extra code that processes it that does not look malicious but the code has a vulnerability. Let me switch up just a little bit more. When you're adding vulnerable code to a web app, you can add things that will execute your commands just like as if they had coded it in securely themselves. Who needs to add a shell bound to a port which is going to be noisy and be detectable in some tool? It's unlikely to ever detect these kind of things, especially in big apps that have thousands of lines of code. One good thing is they can never be sure of the maliciousness of these bugs. They're not going to be able to say definitively, well, we've been hacked because this bug is in our code. That doesn't make much sense. All right, so basically what we've done is contrived sort of a really simple web app to show you the concept here. All this web app does is take what you type in and echo it but extrapolate this idea out to any type of large web application. All right, so we're just typing in our stuff to make sure it works. This one in particular uses a GET request so you can see the different parameters in the URL. So we've hacked the web server. We have access to the web server. So we want persistent access so that we can come back. The admin is likely to discover that there's a bug in whatever we use to exploit it and patch it. So what we're doing is we're going into this web application that they have. We're looking at their code and we're going to add just a few lines of code that introduce a vulnerability that we can use to get back in later. All right, so in this particular piece of code they have a function called check page. This is just a very simple pearl example. So what they do is they look to see if something's being passed from the form to the parameter page lock and then they do something with it. So we're just going to add another check for another form field and we'll call it lang which looks fairly innocuous like language check. So if we detect that any data has been passed to this form field we're going to process this data by doing open file name with whatever the data is. So the vulnerability here is that pearl, if it receives a pipe to the open function we'll execute that as a shell command. And so all we've done is introduce a vulnerability into this web app. We didn't put in a backdoor listener, just a bug. That looks fairly innocent and if you're reading this code you're not going to see, oh evil hacker backdoor here. Well, you might now that we've told you about it but. Okay, so we're going to add a hidden field. Now what this means is that your regular users using this web page aren't going to notice any change in the functionality. They're not going to see any difference to their form. It's going to work exactly the same. So we reload it, we test it, works exactly the same. However, when I get requests there's now a new parameter called lang. So all we do is we go in here and you could craft this with curl or with some script or a lot of different ways. You can do it in a post and there you go. We just add a command to the lang parameter and it executes shell commands right through the web. So we now have a persistent access backdoor inside of their own source code that looks like innocent source code. So extrapolate this out to PHP, whatever web application software you want to use and you'll have a backdoor. If you use post instead of gets nothing will show up in the logs and we'll get into some more complex concepts on this in just a sec. So I mean, that's a good sign. We're trying to make you think outside the box, but bin password showing up in your web logs is probably pretty malicious, right? So we want to hide intent again. We want to try it. So the next step is how do we hide this? Well, if name is this with this value of input, go ahead and just change the password to something we know or do whatever. And if we want to make it even further we can obfuscate it with URL encoding and other things but you don't network traffic and sniffers and snort and these sort of things. We'll pick up similar, we'll pick up simple intent, we'll pick up simple strings and strings identify very specifically intent in this case. And if we really want to take it to the next step, like keep stealth involved with our persistence, we want to encode it differently. We want to provide some logic at the back end. Like do we want to use a validation field as an input key to our Caesar cipher or a ROT13 rotational cipher and then gain a command out of that. And if the command is valid go ahead and run it. So this is all done on the actual server side and that way you can hide your intent across the network and bridge those gaps. And these are very simple things that kind of take it to the next level. Let me just go back real quick. I just want to give another side example. Imagine that you embed a code inside the web form where if a particular name, first name, last name, age, date of birth, a particular sequence of information looks completely innocuous as entered, that means run this shell command. So that's going to be very, very hard to detect. So, I mean, now that we've talked a little bit about persistence and continuing, you know, covert accessing of targets, I mean there are other ways of doing this as well. You know, there's general like support accounts that are automatically added and yes, you can crack these in rainbow tables and you can re-enable them. You can change names. You can make a guest look something else. Now, again, if you're adding guests to the admin group, that might be a little visible. But these are simplistic things that you can do to maintain persistence at a very legitimate level, which makes it harder at the end for people to kind of keep track of what's going on. And, you know, we have some examples of at later, so we don't want to really get into that because Val loves at very much. So, yeah, a lot of what we're going to be talking about is, you know, some of it's kind of old stuff, but the old stuff really, really works very well. I mean, ask any professional pentester. They're going to be using 10-year-old net bios bugs. Okay, so now that we've done persistence, we're going to sort of merge into persistence's sister Stealth. And what we think Stealth is all about, what's about hiding our activity from a whole series of things which might detect you. Intrusion detection, antivirus, you know, sysadmins reading their logs, users even. I mean, often, I've been on a pentest where I've done something weird and the user said, oh, my box windows started opening and they called the security guys and then I got caught. So, really, it's about hiding yourself from anything that might detect you. And why do you care if you hide? Well, if you get caught, you get stopped. So, you know, the longer you can go undetected, it's sort of like you're always going to get hacked. You're probably always going to get detected while you're hacking as well. You know, it's both sides have this problem. But the longer you can operate, the more you can do. Also, admins won't fix problems that they don't know exist. So, if you're being really noisy, you're running much exploits and, you know, busting shells all over the place, the admins might see this and say, well, I got to start patching, or they might not. All right. Also, I feel very strongly about this. When you're doing a pentest, you should be testing really the organization's capabilities to detect and defend against what you're doing. A lot of people, their pentest is, well, we got into this many boxes with this many exploits, and they're done. But really, you have to assume that you're going to get broken into, which is a large organization you have to rely on detection and what do you do? How do you stop it? How do you protect? So, you know, we don't feel like we've done a good job unless we've exercised those aspects of your organization and security as well. So, some of the goals we see for stealth is to keep the system operable, and this is a big deal. You know, a lot of these really high-end root kits you see people talking about make the system unstable, cause lots of blue screens, cause task manager to crash. So, if the system gets really unstable, unusable, someone's going to come and rebuild it or fix it, and then you're going to be screwed. So, you want to be able to operate without fear of detection, and you want to be robust. A lot of these stealth root kit tools are very difficult to run, and you have to, like, there's a lot of work involved. You just have to be able to go in, run a command, and then do what you want to do and not have to keep babing the tools. Above all, don't look malicious. You know, the mere presence of hacker tools on a target indicates that they've been hacked. So, if you're only using what's there, you know, what's normal to be on a system, you're not uploading tons and tons of stuff from PacketStorm or one of these sites, you know, they're going to take a less of a look at you. All right, so there's lots of tools for evading detection. RootKits is the big one everyone talks about, and interpreter is a Metasploit module for, basically, it's one of the payloads you can run, and it's an amazing tool for evading detection. It's pretty good, you should take a look at it. There's encryption, like Shikata Genai and some of the other encoders for exploits, which help with IDS evasion and log cleaners and all the standard stuff. And then with your binaries, is you're uploading your tools. I mean, one of the tools we're going to show later, is that you can evade and delete it. And so, if you see any of our other offensive computing talks, all we ever talked about before was sort of anti-analysis techniques. So you can use some of those ideas. So, you know, our perspective on stealth is, don't be different, don't be an anomaly, don't be something strange on a system, hide in plain sight, make all of your tools and all your behavior ambiguous. Well, is that an admin tool? Is it, could it be used maliciously? Make it really hard to figure out what's going on. Another thing that stealth people forget is the whole concept of, well, you know, the guys I'm worried about over here, so I'm going to throw a rock over there. You know, make one target look really noisy, make a server freak out while you hack quietly on this other server here. And we focus a lot on trying to know our target's environment. If you see our tactical exploitation talk from last year, a lot of it is about this, really knowing what they have so that you can profile your attacks. For example, if they're using encryption on all their networks, maybe you should encrypt what you're doing. But if they're not, maybe you shouldn't because, you know, an admin might see encryption going across the network and say, well, that's weird. We don't use that here. So change your strategy up. Don't always follow the same steps. You know, and don't always focus on exploits. Usually on big pentests, you use one exploit and the rest of the time you're doing all this post-exploitation stuff to break in. It's very hard to write a regular expression for intent. So if you're doing normal behavior that users do with malicious intent, no automated system is going to detect that. It's very difficult. Also, focus on some crazy techniques that don't leave any footprint on the network. Lots of big organizations are moving towards full packet capture and network logging and IDS's that store, you know, what's been happening forever. So use things that aren't ever seen by these systems at all, like IR reports. You know, you walk into them like this full of laptops. A lot of these laptops have IR ports. They'll automatically connect to each other, set up a network and share folders. You can just start throwing your Trojans on everybody's machine over IR and then later when you hack them, your code is already there. And so a forensics analysis or a network forensics is never going to see anything going across the network sending tools because it never went on a network. It went over IR, Bluetooth, or any of these other strange types of protocols. Look at IPv6 and old protocols nobody uses anymore. You know, a lot of people have their IPv4 interface firewalled off, but their IPv6 is sitting there wide open. So, you know, think about really weird strategies that are outside the norm. I mean, and so, you know, continuing on this idea of strange ideas outside of the norm, in Windows, basically, you have secureable objects. This could be a file. This could be a registry key. This could be a policy, basically. And so logging is completely based upon all of these things. So if there's no logs, there's nothing to look at. Well, okay, but what about, you know, logging is a good thing. If I just turn off all your logs, you might probably notice that something's a little strange. So wait, wait a minute. We can do the exact same thing. We can cause almost a denial of service, in a sense, where we can put audit on success of opening, you know, H-key local machine run. That doesn't get called ever in a normal day. I mean, if you're generating thousands and thousands of legitimate accesses, the logs will fill up with plenty of noise, and then you could either choose to allow them to log your actual malicious actions or not log. But, you know, an admin will take a great deal of time hunting down all of these individual little pieces. And if you're not doing it programmatically, it's pretty much impossible. Because I can enumerate through an entire file system that gets opened daily and create it so on successful opening of any of these objects. Go ahead and log something to the security log for me. That turns into a real headache really quickly, and can be very useful. Yeah, you might even get the admin for you without doing it. I'm glad I got my AV guy with me. I try. I try. So, I mean, we're going to give just a general example of some logging stuff, effecting auditing, effecting local policies. So, as we see here, we actually have multiple views. And you might notice we're using a lot of old tools. That's because the old stuff still works. PSX still rocks if they don't block it. So, here, this is for the audience. This is the view on the system. We have some logs in the screen. We have some auditing on success failure. Normal things that you would actually expect on the system. And so, we're going to go in again. We have an account on this box, so obviously we can authenticate it. And we're going to query and make sure that the firewall is actually on. And it is. Let's go ahead and stop it. And we also want to stop some antivirus if it hit there. Take that Symantec. Some antivirus will be much harder to stop, but Symantec is pretty easy. So, we're going to go ahead and make an actual director for our tools. And we'll share that out, because we're nice guys. We like to use net biosharing. It's a terribly useful tool. And we mount it on our attacking machine. And copy everything over. Now, we have some good things. We have two tools here, basically audit policy and clear logs. We'll programmatically alter your auditing as well as many other things. But clear log is the next one. So, we've set all of the auditing to nothing. And we've gone ahead and cleared the logs. Of course, you can turn auditing back. Now you can do your evil and then come back and turn the logs back on and make everything normal. And then there's just a blip in time, which is probably harder to detect. We'll go ahead and refresh all these wonderful tools here. So, we can see the nice gooey view of it. No firewalls. No logs in the actual log over there. And no auditing. And we haven't been sending knobs across the network. We haven't been sending, you know, 255 A's across the network. You know, yeah, we're doing sort of weird old, you know, traditional stuff. But people are so focused nowadays on exploits and, you know, all the new things coming out that a lot of this old stuff is either hard to tell that it's malicious or it'll be easily missed. A lot of what we all do is we'll actually do what we just demonstrated where we clear out the logs and all this and then put everything back. Like we'll make a backup of what the security policies are. We'll turn the firewall back on. We'll turn the AV back on. So we'll get into a box, turn everything off, do our evil, put it back to the way it was, and it's going to be hard for them to realize that we're over there. All right, so now we're going to talk about user identity theft. And I don't mean social security numbers. So often it's not always about root. It's about what access can you get. You know, a lot of networks will actually set up root to not be able to access users' home directories so that there's for privacy concerns, whatever. So when you're doing post-exploitation activities, you want to be able to look like whoever you want, whenever you want. Use the credentials and access that someone else has. You know, the goals here change your identity, it will. Whether it's domain credentials, user ID, existing sessions, impersonating system accounts, whatever. And this is all in order to make your activities look like normal user behavior. You know, if they see a count hacked going across the network doing lots of weird stuff, it's pretty obvious. But if they see, you know, Joe DBA accessing the database, that's what he does every day. So, you know, the stages of this are first you want to target the users. So while you're going through, you know, gather intelligence about who has access to what data, you know, if you see Joe DBA, it's likely he's going to be the database guy. You want to change your identity by hijacking credentials, which we're going to show how to do. Access is the end goal, not root. So, there's actually some pretty cool tools to do this. There's a tool and we're going to show some stuff with it called Incognito. It's actually been built in a metasploit now. It's very, very useful as you hijack tokens. The FU root kit from Rokit.com is very cool and you can actually extend it to do some interesting things. And then some more traditional things, process injection, things like this. So, you know, in this wonderful world of identity theft we still have secureable objects and we still have a bunch of crap in. I used to say this, but I'm tired and I just don't want to say it anymore. But, you know, what we basically want is a privilege. Privilege is controlled by SIDs and tokens on Windows systems. And since we're very Windows-centric here for this talk, it's what we're going to stick with. And what do we want? We want access. And basically, you know, we're going to show how we'll use Incognito to swipe leftover tokens that are on a box to then elevate privileges to something that's a little more useful for us in targeting. All right. So, basically, we're going to demo here. A little bit might be slightly tedious because it's stuff you probably know. But we really wanted to show the entire mindset and step-by-step process of starting with one host that we've hacked. How do we take over an entire domain? So, we're going to actually take over a domain admin and do what we want. All right. So, we're doing our traditional enumeration stuff, looking for hosts to go after. And we're just sort of using sort of innocuous-looking things rather than Nessus or whatever. So, we're looking for, like, the servers and the clients. And here we sort of contrived an example. So, we're looking at it. We're going to run some random metasploit exploit that we know will work on this system. This demo is about what happens after you break in. All right. So, we exploit the box. We're using Maturperter as our payload because we really, really like Maturperter. You should also like Maturperter. Maturperter has a file browser built into it that lets you transfer files over its communications channel. So, we're just going to transfer some random password-dumping tool. And again, some of this you know, but it's the step-by-step concepts of starting from the beginning and getting to running the domain. We're going to use a tool called SAM Juicer, which is part of metasploit research. Vinny Lu wrote it. It's pretty decent. All right. So, using Maturperter, we've set up a shell. And I know you can't read that, but it's actually not that important. All we're doing is dumping passwords. So, we have local access to one machine on the network. We've captured their hashes. And we're going to crack them. And one of those, obviously, you're going to get the passwords eventually. You're going to use Rainbow Crack or BruteForce or whatever, and you'll get the account. But the more important thing here is what account to go after. How do we know which account to target? Should we crack all 10 passwords we just dumped? Well, that might be a waste of processing resources. So, we're going to run a couple of commands and we'll zoom in here in a sec so you can actually see what we're doing. We're running Net Local Group Administrators because we want to target who's in the admin group. There's an account called localVal Smith, which is in the admin group. What this tells us is, okay, who cares about all the other accounts? Let's just crack that one. And then we're enumerating the domain admins. Well, there's one called adminVal Smith. So, that tells us who we want to go after next. You know, we're building our attack plan as we go along. All right, so we really like the loft crack still. I know it's old, but it's still cool. So, we've cracked it, whatever. Now we're going to move on to the next stage. Incognito has a standalone mode, which, you know, we really want to show a lot of the manual hands-on techniques. And it has a sort of a long command line. But the first thing we're going to do is we want to enumerate tokens. And if you notice before, Metapast does this for you now. So, you know, we have the automated way and the manual way. So, with Incognito, you pass at the username and password that you cracked that's a local account on the box. And it tells you that there's a token present for the domain admin that we want to target. So, now we're going to go ahead and write a new command that says, give us a shell using the account that we've hacked that's local and hijacked the domain admin credentials off of the box. Believe it or not, when you log out, your credentials don't go away. They don't really go away until you reboot. I'm not sure what the design theory is behind that, but... All right, so now we've got a shell. And I'm running it on my tool. And basically, we're domain admin. And that's really all it took. There's a lot of theory behind the way that Incognito works. I recommend reading Luke Jennings' paper on it. It's pretty awesome. But just to prove that we have domain admin, we're now adding a hacked account to the domain. I don't recommend doing this in practice because it's really obvious, but this just shows that our access is working. So, we've added a username and password to the domain and we're going to go check the domain admins group on the target that we hacked to verify that it all worked. And there it is. We've added our hacked account to the domain admins group. So, we've basically taken over domain using only local access to one machine. And we're automating a lot of these types of attacks inside of Metasploit, and we'll be releasing the modules for them. So, look for that. Okay. All right, next subject matter, feature modification. This is the idea of changing existing features on a system to benefit our post-exploitation activities. Whether a little bit of it's kind of related to stealth, all these subjects intertwine and they're all really part of each other. But, you know, maybe you want to enable and secure things, or you want to re-enable things they've turned off. And, again, you know, obviously I like secureable objects a little too much. It's probably a bad thing. But, again, I mean, this is what controls all of these things. This is how you disable things on Windows. This is how we want to leverage this to re-enable them. And basically, you know, these are what we have to do to do it. And then it plays many roles. And so we've showed multiple variants of it, like how you use it here, how you use it there, and when it's important. We really like movies, so we're going to be showing a few of them here. But, yeah, basically, you know, we're going to show a fun demo here in a second about re-enabling GUI access remotely from a command line and why you would even care about doing this. But, you know, you've got to be careful with this because sometimes turning stuff that they've intentionally turned off is a bad idea because it gets you caught. All right, so we've just provided a slide. I'm not going to read the whole thing. But this slide helps you enable VNC, like install it and turn it on remotely. If you've got an exploit, you can use the Metasploit module for injecting VNC. But a lot of times you're broken up with a password. So, you know, you've got a password, you can get a shell through PSXAC or some other way. So how do you install it fairly legitimately over a command line? Well, this is how you do it. You make a registry file that looks like this. There's tools out there to encode your password in the format that it needs. You install this using these commands. And we'll show a little quick demo. Now, the reason you would do this is a lot of times the system you're going after is running an application that doesn't have a command line component to it. And often you don't even care if you get root. You want access to the application. We'll show you why at the end of this demo here. All right, so, you know, we've hacked this machine. We have a command shell on it. We're going to establish authentication to it using this password that we've cracked or whatever. So we're going to gain a shell. You can use lots of different things. We're using PSXAC because it's easy. And we're going to add a directory under Program Files. Now, a lot of people will look in Windows System 2 for malware, System 3.2, but, you know, sticking stuff in Program Files works pretty good too. We're going to share this out to ourselves so we can copy files to it. And I advise turning the shares off after you're done using them. All right, so we're going to connect to the 19.94 NetBio stuff. All right, so we copy our tools over there. We're going to go in there. Everything looks good. So we're going to add the registry settings using RegEdit. We're going to install the service for VNC. And then I believe we're going to start the service. Remember, we have to wait for it to install. So, yeah, it takes a little time. And for some reason, installing VNC this way, starting the service always fails the first try. I don't know if it's a timing issue or what, but the second try always works. So keep that in mind. All right, so now we're going to connect to our target. Metasploit actually provides a VNC viewer for you if you want to use that. So we're going to connect. So we started off with a command line, which is pretty good for most things. And a lot of hackers focus on command lines. But what if what you want isn't on the command line, like, say, telecommunications and power and phone monitoring and configuring systems. These are unlikely to be accessible via command line, but lots of systems use VNC for remote administration. And so, you know, you've just enabled yourself further access that you didn't have. All right, so, you know, on a sort of similar topic, we just added VNC, but, okay, well, VNC isn't something they had there natively. So are they going to detect it? Well, possibly. If you look at the corporate port scan, they're going to see this weird port open. Okay, well, what about a remote desktop? That's something that is fairly legitimate, is already on your system, just often disabled. And why do you want this? Well, maybe the system you're going after is running the security cameras for the company, and you want to see what's going on on these cameras. Or who knows what else, evil. All right, so enabling a remote desktop is actually much more difficult than enabling VNC. You have to do a lot of work with GPOs. So we've created this policy file, which we'll provide in the slides, which will enable remote desktop for your terminal services, basically. Change the account to whatever real account you have access to. All right, so then there's another file you need to create with some registry settings that turns on terminal services, and then a set of commands that you run. We really love movies. And the stuff in the slides is really for you later. We're going to basically go through the exact same thing again here in the movie, and just sort of reiterate it. We're just showing that we tried to connect with a remote desktop, failed, and we're going to go ahead and hop in here. This is our shell that's on the actual remote box, and we're going to move into the security database where the actual local policy database is stored. And create a copy of it, because remember, we like cleaning up. We're all about cleaning up. So we want to share this out and copy it. And then we've pushed a registry file which allows us to toggle things on because there are some settings that are controlled in the registry. Some are controlled in local policy database. So we have two of those, an INI that will allow us to push to the database and a reg file that will change it. We've made sure that we've turned terminal services on via SC, and we've now... seven minutes. And then we've pushed the registry file, and then we're going to apply... first copy and then apply changes to the actual new database and push through it. And we're forcing an update. You have to use GP update to do these things because local policy updates are not transparent, and so you have to generally force a lot of this stuff, and we restart and re-verify everything. And then we'll go ahead and log in with remote desktop. And ha-zah! We have some Oracle access, which is not something you can get on the command line. It'll waste in many cases All right, we've got about five minutes left, so... what I want to talk about really briefly is abusing the scheduler. And basically, a lot of these techniques were automating. We're putting into Metasploit using modules. And abusing the scheduler is a lot of people will turn off admin dollars so you can't get a shell using PS exec. They'll turn off service control managers so you can't turn services on and off. What we like to do in that case is use at. At is just a scheduling command. You can say, at that system, at this time, run this command. So we've written some tools to automate it that we're porting to Metasploit, and we're just going to go ahead and go right in the demo since we're almost out of time here. All right, so, you know, currently this is just a sort of a wrapper-prol script. We have a bunch of parameters, so all the different evil stuff we want to do, whether it's turning on shares, adding accounts, disabling services, whatever, we put in here. These are protocols we're using TFTP for simplicity. That often is detected on networks, so be careful. We have a little config file, so basically we're going to run our command against a list of IP addresses. And I've actually used this with great success on a really large pen test where everything is disabled on the network except for at, but we have the admin password so we can control it. So basically what this is going to do is it's going to connect to the target, it's going to figure out what time it is at the target, and then it's going to say, okay, in one minute from whatever time it currently is, run all these different commands. So you can see basically it's populating up, it's adding shares, it's adding accounts, putting people in the administrators group, turning off antivirus, and it's going to do this automated and fairly quickly over a large number of hosts. So yeah, we're just about out of time. We're going to go ahead and go to the question and answer room in a minute here. But yeah, basically just automating things using scheduler is pretty cool. All right, so we want to thank all the people from Offensive Computing and Unformed and Metasploit and our different friends, Danny Quest and KerbClepto. Also really seriously check out Luke Jennings. Here's a couple of related talks that you might want to consider checking out. Escape and Spoonum released a talk called Beyond EIP, which is on the exploit side, the code side of post-exploitation activity and Luke Jennings talk. All right, thank you very much. Thank you.