 This is post‑metasploitation using Metasploit for making post‑exploitation faster, better, stronger. My name is Egypt. I like Comic Sans. I don't care who knows it. I'm not the country of Egypt. I get solicited on IRC at an e‑mail on a regular basis asking me if I speak Arabic. No, I don't. I have nothing to do with the country. And I've never used my beard to overthrow government. But I'm working on it. I work on a cool project called Metasploit. I assume most of you have heard of it. It's an open‑source tool for all kinds of stuff. It's not just exploitation. It's reconnaissance. It's tying together all the things you need to do on a pen test. It's capturing all the data, storing everything. You are a good man, sir. Everything is better now. Metasploit was created in 2003. It was originally written in Perl. H.D. Moore wrote it as a game. And that's sort of a theme in Metasploit. Several features were originally created as a joke and later fleshed out to be awesome. D.B. Autopone was originally a joke because some reporters said, well, you can't just click a button and own everything. And, well, yeah, now you can. The ability to inject a payload into an existing E.X.E. was the same thing. Some reporters said, well, you can't just throw a payload into ‑‑ it's not a virus. You can't just put it ‑‑ well, yeah, it is. But the big thing about Metasploit is that it's a framework. It's not just a thing to run exploits. It's a thing for writing exploits. It's a thing for using exploits. And it's a thing for everything in the middle and more on top. It's a clearing house for compromised machines. It's where you store all your data. It all goes into the database. You can take it out of there and put it into cool reports. And once you've compromised things, you can pivot around on the other things. And that's a lot of what we're going to be focused on talking today. So why are you here? I hope you're here because you like shells and you want more of them and you want them to be better shells. You know, it's cool having one shell. It's nice seeing that hash prompt pound up. But one shell is often uninteresting and it's nice to have all the shells. And hopefully using Metasploit and some of the awesome techniques that are available to you through Metasploit, you'll know your shells better than the incident response team knows you. And having one shell on a workstation with low privileges, you know, it's fun for a while but it's not all that interesting. It's much better to have a root shell in the data center. Having data center is fun at five o'clock on a Friday but it's even better if you can sit there for a week with nobody noticing. So that's what Metasploit is for. That's what this talk is about. I assume you've heard of Metasploit at least. I'm going to be talking about some of the internals and writing code so please don't be afraid of the ruby. I assume you've gotten a shell because this is not about exploitation. This is about what happens after. And I assume that that shell is not your goal. If your goal is just to get a shell, then your scoping sucks and you should talk to your boss. So why do we use Metasploit for all of this? The first thing is that it's already great at getting shells. There are almost a thousand exploits, dozens of auxiliary modules, over 100 post-exploitation modules with all their own cool techniques. Just one of the best tools available for getting shells and once you've got those shells, then we get to do the cool stuff. The second coolest thing about Metasploit is that it's all open source. It's up on GitHub so you can just go download it. It's a BSD license notably not like GPL which is really a virus. And you can take it and do whatever you want with it. Since it's BSD licensed, it's really easy to fork it, write your own stuff for it. You don't have to share it with anybody. You can keep it all for yourself, give it away to your friends, whatever you want to do, all because of open source. And as a corollary to that, there's a huge community. We've got almost 200,000 people who update regularly. And all of them know something. There are a lot of noobs in the world and everybody started someplace but the people who use Metasploit typically know something you don't. So if we can tie all of those people together and take your cool techniques and their cool techniques and get everybody using all of the cool techniques in one place, we tie them all into a single framework and give everybody access to the coolest shit out there. All because of open source. Ruby is faster to write than see. So that's another advantage of Metasploit. If you do need to get really down and dirty and you have to write some C for something, that's available too. We have integration with a project called Metasm which is an assembler and compiler. It can compile C for x86 or x8664. And it can assemble a whole bunch of different assembly languages for all kinds of different architectures. And because of that, if you really need to get down and dirty and you need to have a very specific payload or some really tight code for fixing up a stack or something along those lines, all of that is still available and you can get into the really nitty gritty stuff if you need to. But when you don't need that power, when you just need to, when you don't need that low level access, you just need to write some code really fast, Ruby can save you tons and tons of time. So first I want to talk a little bit about the design goals, why we write post modules will come up later, but for now I want to talk about what post modules should be. And to start with they should be minimal. They should do one thing, they should do it very well. It's a common thing to see people tie lots of different functionality into a single post module. And that's cool in some respects, but a lot of the automation can be done much more easily through resource files. And so you have a module for stealing passwords, a module for stealing this kind of file, a module for stealing this kind of file, this kind of data. If you have those separated out, it's much easier to categorize them and understand what each thing does individually. And then you can tie them all together with other kinds of automation. So it's better to have modules that do one thing than it is to have a single module that does all kinds of shit that's not necessarily related. Modules should be readable. Like everything else, there's some cool metadata available in the module structure. And we'll see a little bit of code in a second explaining that. But if everything has a consistent structure, which we strive for in the framework, then it's a lot easier to write new stuff. It's a lot easier to understand what a single module does. And if we have consistent output, then you'll always have an understanding of what this module is doing as it moves along. And possibly most important, modules should be reliable. Just like exploits, it's really important for a module not to crash shit. If you have a kernel bug and there's a possibility of panicking the box, beer saves the panic. If you panic the box, you lose your shell. And then that's no fun. So you should detect everything you can that might affect your exploit or your module's functionality. So, for example, path names change between Windows versions. You know, you've got six wow and all that sort of stuff. And if you don't detect those variables and your module just doesn't work, that's kind of a bummer. But if you're doing kernel exploitation and you blue screen the bitch, now what? You've lost your shell, you've lost your access, you've tipped off somebody on the other side. So now the guy sitting at that console is going to go, whoa, what just happened? And maybe call incident response and then not only have you lost your shell, all the other shells are harder to get and harder to maintain. So crashing things is very, very bad. And we try really hard to make sure that that doesn't happen. Again, as a part of reliability, cleaning up is one of the most important things that modules can do. You should always drive to leave your system in the original state you found it in for multiple reasons. If you leave stuff on the box, you could potentially end up causing antivirus to flag it later, things like that. I had a pen test in which for whatever reason my PS exec wasn't cleaning up on something like 10 percent of the size I owned. And at about midnight, the customer called me up at the hotel and said, some shit is hitting the fan, I need you to get down here right now and make sure this is you and not somebody else owning the entire organization. So yeah, cleaning up is really important. Getting those phone calls is a bummer. So when you're developing modules, they're very much like auxiliary modules in that usually they're not an exploit. They don't have a payload. They do something. They record it. And then you can look at that data later in the database. In terms of the code, they have some similar structure and similar method names. All ox modules and post modules have a run method that's analogous to the exploit method in exploit modules. This isn't entirely the case because there are also local exploit modules now and we'll talk more about those later which are sort of a hybrid between regular exploits and post modules that allows you to do some really cool things in sort of blurring the line between a local exploit and a remote exploit. Post modules have actions just like auxiliary modules and a lot of people don't know that actions even exist but they're a way to have your module do different things based on what you need at the moment. So an example is installing something and deleting it are sort of disparate actions but they're related so they should be in the same module. So having a different action can let you separate those out in the code. And like pretty much all other modules, they can include mix-ins from other module types. So if you have a post module you can include exploit mix-ins and gain access to all the protocols that Rex supplies. You can include auxiliary modules and gain advantages of being able to report to the database easily. You get all those wrappers for free. You get potentially server code so you can set up other kinds of like an HTTP server. All of that stuff is available through the exploit and the auxiliary mix-ins. You also get the post mix-ins and there's an expanding API that's being updated pretty constantly now. I'm putting a lot of effort into making the post API as generic as possible and make it work everywhere in a single unified API. So you just say write file and it puts binary where you tell it to. And that is a very handy thing, you know, so you can disregard the kind of session it is and what kind of box it's on. You have the same API it works everywhere. You can write files to a Windows box or a Solaris box or a Linux box and it all works exactly the same way. So having that kind of separation in abstraction can really save you a lot of time. And lastly, like auxiliary modules, post modules should generally report something. If you're not saving the data then what's the point of gathering it in the first place? It's really important to keep that all together so that you can look back at your engagement and say, okay, yes, I owned this box but what did I get from it? And we'll talk more about the ideas of what to steal as we go on. But saving that data is just as important as stealing it in the first place. Hey, it might even be a little bit readable. Awesome. This is a very simple module just as an example to give you an idea of what the structure looks like. If you're at all familiar with any of Metasploits exploit or auxiliary modules, the structure is very similar. So you have a block of metadata in the constructor in the initialize method that gives you the author some information about the exploit or in this case the post module. And that will be a free form text block that you can use to describe what the thing does and where it gets its data, that sort of thing. And it's really important for the description to include all of the relevant information about this module. If you're using the module and it just says does some stuff, then now you have to go look at the code to actually find out what stuff means. So we try to be really diligent in getting the descriptions to match up what the thing actually does. So like I said at the top, there's the chunk of metadata. Usually your mixing includes will also go at the top. And that, like I said, can come from the exploit, the auxiliary, the post, name spaces. And then we've got registered options and those are the things that show up when you type show options or set. And that's where our host and those familiar options will go. Most of the options that you're familiar with come from Mixins. So you don't need to do anything here for those like our host, our port. Those all come from Mixins. But if you need something specific to your module, like for example, in this case we've got a command that we're trying to run. So we register a string option that will be that command that runs on the target. So this is just a really simplistic module to demonstrate the structure of how they fit together. But I hope you'll go and take a look at some of the other post modules that are available. There's a bunch of them, there are over 150 of them. They all do something cool. And whether that something cool applies to your particular situation may not be the case, but it is worth looking at them just to find out what cool techniques are out there and maybe give you some ideas for other cool techniques that you'd like to try. So like I said, the post API is meant to be an abstraction to give all of the things that you want to do on every shell, a simple way to write that code. So writing files, running shell commands, listing users, dumping passwords, changing directory, that sort of stuff. The simple things that every module will want to or a lot of modules will want to do, all of that should be in a library that everything has access to and is really simple. And sort of the look and feel of the API is meant to be like a domain specific language where it feels sort of like a shell. You just type in CD directory name and that's where it goes. And so it is meant to give you a very simplistic and understandable and readable API while maintaining all the power of Metropeter and the available underlying shell. So yay, secret sauce. I like to break post-exploitation down into these three P's and as the footnote says there, I totally stole this from Mubix. I get all my best ideas by stealing them from people. So presence describes where you are, who you are, what is this box, is it important for achieving your goal? Like I said, if your goal is just the shell, then your scoping sucks. So presence is all about what does this box do, who does it talk to, that sort of thing. Persistence is maintaining access to that box. If the victim reboots the box and that completely hoses you for the rest of your engagement, then you need persistence. So you need to ask yourself that question, when you get on a new machine, is this the only way I have to get back in? And if that's the case, then persistence is very, very important. Pivoting is where we're going to spend most of our time for the rest of the talk. Basically the idea of you have access to this machine and this machine has access to other machines or not necessarily other machines, but other data, other users, other places you want to be. And we'll get into more of that as we go along. So in presence, there's basically two subsections. We have the users and the machine. The machine itself can often be interesting, but the users are really important as well. The user is not just, is this guy an admin? Is it, it's more than that. It's, is this guy in finance? Is this guy in HR? Is this guy a developer? All of those things are important and the particular user you have access to can often be much more important than the machine you have access to. Of course, you know, if this guy is a domain admin, then you can just waltz around the rest of the network and all the rest of the security controls don't matter. But, you know, you don't always have domain admin. Sometimes you have it in the first 30 seconds of the engagement, but not always. And so if you end up on, like a developer's machine, you need to understand what that user does, what he has access to. So the user can sometimes be way more important than the machine. But the machine can be useful, too. Does the machine have, is the machine running a database? That's where the keys to the kingdom usually live. All your credit cards are in a database somewhere. All of your user information, all of your financials are in a database somewhere. So if you see those processes, then that's where you need to focus. And an issue with presence is getting an unfamiliar shell that you've never played on before. You end up on, you know, this is an AIX box. I've never looked at AIX. What do I do? Well, with the Metasploit Post API, again, we've got that abstraction. So you don't have to know what commands are available that will allow you to write a binary file onto that box, because we've already done that work for you. There's one API for writing a file and it just works. And we go through several different possibilities for commands that can write a file, printf, echo in some cases, although echo tends to be really unreliable. And a lot of places don't implement the dash n or the dash e. For echo, which you might be familiar with in bash, that's actually a bash built in version. Bash and Zish implement that, but basically nobody else does. And user bin echo almost never does dash e, which means the escaping of hex characters. So if you want to write out a file with binary in it that you can't normally just echo, if you don't have the dash e in the echo command, echo won't let you do that. So you need to find other ways to do that. We try xxd, we try printf, we try several others, purl, awk. So because of that abstraction, you can write files, you can do the things that you normally want to do on any of the systems that we've tested on, and hopefully more, because we try to do it in a generic way. So this is one way that Metasploit helps you out with presence. This module here is the enum logged on users, and it gives you the SID and the profile path of all of the users that are currently in the credential cache. So because of the way Windows caches credentials, you can just look around for anybody who not only is logged in right now, but who has logged in recently, and from that you can steal cached hashes, but sometimes it's more important just to know that that person has been there. And all of that is part of presence. So from the perspective of the machine, like I mentioned, the running processes can often tell you a ton about the box. If this guy is running some sort of antivirus or file integrity monitoring like tripwire, then you know you're going to have to be careful when you upload files. If that's not there, then maybe you don't have to be so careful. But it's something that you have to know. SSH agent and pageant are both very cool processes to see in the list, because it often means that you can steal that person's keys. If you upload Plink, and there was a cool blog post about this, I can't remember where I saw it, but it was a couple of weeks ago, where if you upload Plink, it will automatically use any keys that are stored in pageant. So if the user you're logged in as has run pageant and unlocked their keys, now you can use them just like if you were on that, just like if you were that user. Which means now you can log into any of their stuff. And similarly SSH agent on Unix like systems does the same thing. There's also the SSH master socket, which is a super cool way to own all the things. And I haven't really figured out why you would want it legitimately, except to have your shit owned. But it's there. Editors are something that a lot of people don't think about. If you see like Eclipse in the process list, then that's a really good flag that this is a developer. And if you're on a developer box, that's almost always interesting because they usually have access to stuff that nobody else has access to. They have like backup data. They have test data. I ended up on a test system, and this tipped me off. There was a guy running notepad plus plus I think it was. So I started looking around a little bit more and it turns out there was a local MS SQL database that wasn't listening on the outside interface but it was listening locally. And it was a developer who had taken production data and was using that as his test system. So it was, you know, I didn't have to own a database server which was pretty highly protected. I just ended up on this one box and there was like 200,000 credit cards. Awesome. And what does this box talk to? Normally you want to find out can this guy talk to another system? Something that I'm interested in. Because again, your goal is usually data. It's not a box. It's data. It's where the data lives. So you need to find out what this guy talks to. What other users are available on the system. And Metasploit does that with the TCP net stat module which does exactly what it sounds like. It's net stat. And it gives you a list of the things that it's all connected to. A list of the servers that are listening. And this simple little module gives you a lot of information. So it saves you the effort of having to drop to a shell. This uses Railgun, which if you're interested in Railgun and the Windows API, I highly recommend you stick around for Dave's talk after this one. He's going to talk about owning all the things through Railgun which is a Windows API bridge for Metasploit. Persistence is the next big thing. Passwords are very, very important for persistence. If you log in legitimately as a normal user, then that looks just like a normal log in that everybody expects to find. And just a quick show of hands. How many of you audit successful log ins? Not failed ones, successful. A smattering of hands. Not very many. So if I log into 4,000 machines with the same username and password, that should probably be logged somewhere. People don't look at it. And it's how you get around. It's how you get around in a network using passwords, creating a new user that just lets you log in everywhere can really be the keys to the kingdom, just one user. There's also back doors which I think of separately as, separately from passwords. Not like a back door SSH, but like including something in the startup menu or startup folder. Things like that are a back door in my mind versus a password that lets you log in even if it's a back door password. And then lastly, reintroducing vulnerabilities. And this is something that Val Smith talked about in his black hat talk from a couple of years ago. And lots of other people have mentioned, Mubix has talked about it a lot. I think it's really, really interesting. But it's something you should be very careful about if you're on a pen test and you like remove a patch or reintroduce some other kind of vulnerability. You're potentially making another hole in your customer's network that could be really detrimental. So with a grain of salt, be very careful on a customer's network. But if it's not necessarily a customer and you're not into that hole not going to jail thing, it's a viable option. Metasploit has some sort of temporary persistence in the reverse HTTP and reverse HTTPS payload stages. They currently work for Windows native and Java interpreters. And it gives you a short term persistence in that it doesn't survive a reboot. But it will continuously pull out trying to make a connection out to you. So as long as that process is alive, you will have a shell even if your listener goes away. So if you have to shut down your line node for whatever, you lose your MSF console for some reason. If you bring it back up and set up the handler the same way, it will eventually call back to you again and you'll get that shell back. So it's really super handy on spotty networks where you've got high latency, low throughput. If the network for whatever reason, you know, you end up with a reset, you just get another shell in a minute. So that simple ability to have it call back to you continuously means that it's some form of persistence that can save you a lot of headache if for whatever reason the network causes you to lose your shell. But of course it's temporary. So if the box reboots you lose your shell, if you really have to hang around for more than the life of this current boot, then you need something more. And for that we've got auto runs. And auto runs.exe is a really cool tool by SysInternals, which is now part of Microsoft. And it's something for administrators to look into all of the places where things run automatically. And if you're an administrator, it's super useful to find out the stuff that's running. But if you're an attacker, it's also useful as a list of places to push it. So auto runs is super useful. And we have a persistence module for Windows that has several techniques for dumping binaries into the right place, modifying the registry is necessary to make them run. You can also use things like the task scheduler to have it run things later. Cron and LaunchDi is sort of the Unix equivalent, LaunchDi is the Mac thingy. And we previously didn't have much for Unix like operating systems. Our persistence was pretty much based on passwords for a long time. But I mentioned in the Metasploit channel that damn, we don't have any cool persistence stuff for Unix. And then like an hour later, Alex Malato gave me a pull request. So that will probably be it next week. That guy is a badass by the way. And he is responsible for a lot of the cool stuff that you see in SMB these days. He did a whole lot of work on making SMB signing work in the Metasploit protocol implementation. So now when you want to connect up to a 2K8 server over SMB, he's the guy that is responsible for making that work. So if you run into him, buy him a beer. You can also enable RDP or root SSH login or whatever to give you another place to use passwords. And passwords, as we mentioned before, are one of the best ways for maintaining persistence. Now the really fun stuff, pivoting. Going from this box to something more interesting. Not necessarily on another system, but potentially just on the local system pivoting to a new role. Going from a user to a root or a user to another user. And that's part of privilege escalation. But then there's also trust relationships. So this box is allowed to connect up to this MySQL server, for example. Those kinds of relationships are very important. And the way Metasploit does pivoting, there's a few different mechanisms for it. The first is the route and the port forward commands, which allow you to set up a way for Metasploit to send all of its packets through a compromised machine. And that's a very simple way for running new exploits against something else. Or port forward is one of my favorite tools when looking at like a corporate internet. You own a box. And on the inside, through phishing or whatever, you find out that hey, this box is an internet that has potentially interesting stuff on it. So we set up a port forward that goes from your local attacker box, goes through the compromised machine and comes out on the other side. And then you can just fire up a browser and talk directly to that thing using Firefox or whatever. So you get to use all your normal tools for web auditing. You can use Burp or whatever. And all of that stuff just goes right through the compromised machine. The SOX module, the auxiliary module sets up a SOX server on the local machine and gives you the same sort of idea. But since it's a proxy, you can just set that as your browser's proxy and then use it on all of the internal HTTP servers. So with those two simple techniques, you can run exploits against everything on the other side. You can scan them with auxiliary modules. You can browse their internet with your own web auditing tools. And it gives you some of the real powerful parts of Metasploit inside the compromised machine's network as if you're sitting on that same network. The last bullet here is the COM argument to the Rex socket library. And Rex sockets are Metasploit's implementation that allows you to use the route and the port forward and all of those things. And it's the underlying library that allows all that stuff to happen. It also gives you SSL for free. It gives you proxies and a few other options. But the way that's all implemented is with a COM object. And Meturpreer sessions are all COM objects. So you can just pass a Meturpreer session into a socket creation. And then from that point, that socket will be connected through the compromised machine. And there's not a whole lot of use of this yet. It's a relatively little known feature. But it's very, very cool. And I think it will be super important for post modules in the future. I think it's one of the best things about Metasploit is being able to create new sockets on the other side. And the COM object gives you a quick way to do that. So for example, you can set up a post module that scans something on the other side using the session as the pivot point. And that way you don't have to set up an explicit route in the console. The post module will just do everything for you. So look for a lot of that stuff in the future. And if you're interested in writing something like that, please talk to me. I would love to get more of that stuff in. And also part of pivoting is post exploitation, exploitation, privilege escalation for when you get on a system that you would really not like to lose. It's often important to have route or local admin. If you're on a user session, if you got them to click an exe, then when they log off you lose your shell. So you need to get out of their window session into something that's going to run for a long time at the very least. Or potentially if you can gain system, then you can just migrate into some other process and not have to worry about getting kicked off when they log out. It's, of course, when you're talking about kernel exploitation, there's always the possibility that you're going to panic your machine or hit the wrong button. But because of the difference between local exploits and remote exploits, you have to be careful with the, you have to be careful about not kernel panicking the box, of course, but also if you're dropping an executable, there's an element of it being local because you're dropping an executable. But it's also really remote. So anyway. Just like network exploitation, it's not always an exploit. Sometimes it's really just passwords such as sudo, things like that. Suit executables, I sort of think of like a trust relationship. The same idea that logging into a server from here to there works. You're using this executable that runs as root. So it's kind of a trust relationship. And there's all sorts of things that count as misconfiguration in the same line. So first demo. This is Nmap in its man page has this quote Nmap should never be installed with special privileges e.g. suit root for security reasons. And some friends of mine mentioned that that happens more often than you think. You find boxes with Nmap installed suit root. So I looked into what security reasons actually means. And it turns out there used to be a command called or an option called dash dash interactive. You just pipe shell commands to it and you win. So they took that out a while back at about the same time that they added NSC scripts. So now you can just write an NSC script that pipes out to shell commands and you win. So here, if I can find my mouse, maybe. Okay, so first thing here is we're just going to show all the options. Very quickly drop into the session show that we're user 1,000. We're not root. We set that session. We run the exploit. It drops out a file. Drops out an executable. Runs the executable. And now we're root. Very simple. Easy to clean up. Just drops a couple of files. Woot. Sox entry page. This is one of my favorite kernel exploits of all time because it covers everything. It goes from 244 and 260 to the most recent kernel versions at the time that it was dropped in August 2009. So it covers 8 years of every version of the kernel that shipped. So this gets you root everywhere. Now this one is a little more complicated. So we're not just dropping an executable and a thing that runs that executable. Instead, we're, and you can see here I'm not root yet, we're actually compiling C on the fly and assembling it with custom shell code and dumping a payload into that so that now, as you can see here, we get a new session and it takes a minute because we're still cleaning up. And this I think is very, very awesome because we're compiling C and assembling shell code in Ruby so it works anywhere that Ruby does. Very cool. This is the part I was talking about where local exploits sort of blur the line between local and remote because you're using something about the session and you're still pivoting into a new role as a new user. But we use post mix-ins to be able to do all the post stuff and exploit mix-ins to create executables and that sort of thing. We can compile C for those two architectures and assemble for all of those and a whole bunch more. So now I want to talk more about Windows and we talked about trust relationships but this is sort of the same idea. Windows has some cool little tricks because of the way their authentication works over the network. So first I want to talk about a recap of SMB relay. This is an old school technique that was talked about for the first time at least since 1999. But a victim talks to some attacker machine and it doesn't matter how, why it's talking to that machine just some, for some reason it's calling out to this box. It attempts NTLM authentication. So the attacker just sends that same packet straight over to a target and he wants to own that target. The target sends back an 8-byte challenge. We send that same challenge to the victim. The victim calculates a response for that challenge, sends it to us, we pass it on. Now we're logged into the target as whatever the victim user was. This is a well-known attack. It's been around for a long time. There are some mitigations that break it but it's been around forever and it will probably be around for a lot longer. Basically mandatory signing is the only way to shut it down completely. But if you do that then you break all of your old clients. So nobody does that. If you only have newer Windows systems then you can turn on mandatory signing and break this for the most part. But very few people actually do that. So now this is an awesome new technique, well relatively new technique of dropping an LNK file. It turns out that LNK files are sort of like a sim link in the UNIX world but they can have an icon and that icon can be a UNC path like most things, most paths in Windows can be a UNC path. So we drop an LNK file on some file server that we have access to with an icon that points back to our server. So now some victim opens up that share. The share has this icon. The icon is a link to our thing so it tries NTLM authentication to our box. And so once we do that then we can own all the things. Very cool technique. Another thing that Windows does is automatic authentication with your token. So in the GUI when you open up a file share it uses your current token to authenticate using the same technique. So if your user has local admin on another box you can also create services on that box. And turns out those services can also point to a UNC path. So this is the API call that does that. LP machine name can be a UNC path. And then LP binary path name, or excuse me, machine name can be like any server that you want to create a service on. LP binary path name can be a UNC path so it points back to your box. So now automatic authentication. So we can see here that we're a domain user right there. And this user is a domain admin. We have his token. So now go go video. Our host here is 10111 is our domain controller. So now get UID where system on this guy. He's the domain controller. And you can see that's the new address. So the cool thing that happened here is we didn't have to know a username or excuse me we didn't have to know a password. There's no hash here. There's no password. All we did was have a box with the token. So now that the domain controller called back to us and gave us a shell. Very, very awesome. It turns out you can do this on everything. If you have local admin, if you have any user, any domain user that is a local admin on all machines then you can get a shell on all of them. So Metasploit is awesome sauce. Yay. And if it doesn't already do something that you need it's relatively easy to add your own stuff. The module structure is simple. The amount of Ruby necessary to learn how to write new modules is minuscule. If you've written any other scripting language you can learn the Ruby necessary to write a module in an afternoon. So if you're interested in more post exploitation awesome sauce stick around for Dave Maloney's talk. He's coming up next. And this is how you can contact me. Interestingly these images are what happens when you Google awesome sauce. And also these. I have no idea what a kitty going dead ass has anything to do with awesome sauce. I thought it was funny. So there you go. Thank you.