>> This is Brady and I guess he's going to talk to you about how I guess Windows likes to
have fun with itself. All right. ? >> [Applause]. ? >> All right, I guess you guys are a little
too excited to watch Windows play with itself. We'll be covering some really interesting
stuff today. First off, I guess a little bit about myself. I started out in the Government
space doing a lot of cool stuff there. Like most of you, I'm passionate about security, been
doing it ever since I was old enough to get into trouble for it. If any of you have heard of
the POS Project, I started that project and currently I'm a founder and principle security
consultant at Simon Briggs Security. So throughout this you will see a lot of the techniques
and tools that we have developed in conducting penetration tests. So before we enter the danger
zone for you Archer fans out there, I wanted to give you a little bit of background as to
what motivated this talk. Ok. So back when I was in the Government space, I remember
talking to some friends in the private sector and they were telling me about some of the
difficulties they had and the differences between what a penetration test was and what an
actual attack was, or what they were actually trying to defend against, right? So, you know,
fast forward, that was about three or four years ago, fast forward from that point a couple
years and that ended up being one of the motivating factors to starting Simon Briggs Security,
was to shorten that gap and to combine what an actual attack is with what a penetration test
should model after. So that's typically, you know, that's typically the methoDLLogy that
we use when conducting penetration tests. So there's still very few covert
persistance tools on the market. Right? A lot of us use Metasploit and I'm a big fan of
Meatsploit. I'm definatley not going to badmouth it because I think it's an awesome project.
But I think it is important to reduce the reliance that we have on Metasploit. And there's other
great projects that do this as well, right. Such as Veil, Veil does it. Cobalt Strike is
another great project that does it as well. So anything that we can do to, you know, customize
and model assesments and penetration tests after what organizations are actually
defending against, I think is a good thing. So throughout my talk, you will see some of the
techniques and the tools that are being released will hopefully help you in doing
that. We have a lot to cover. We're going to first talk a little bit about DLL injection,
a new technique for that. A new, actually a few new techniques for persistence, stealthy
persistence in a Windows environment. We're going to release throwback and I'll give
you some demonstrations with that along with lots of other demos along the way. So I'm
really hoping the demo Gods will be kind to me tonight. So first off, for DLL injection -- ? >>
[Laughter]. ? >> For DLL injection, you know, for those of us who have had to deal with
the Windows API, that's often what it feels like, right? It's kind of a black box. It's
definitely a black box. Three out of the four APIs there are undocumented, right? So a lot of
the options that we have and we that have to deal with, we have to reverse engineer and look at
Microsoft DLLs and try to figure out what Microsoft was thinking when they did things. The only
documented one is create thread, but Microsoft is, you know, implemented quite a few
restrictions around that with integrity level for processes and things like that. I have
never been able to get NE create thread to work very well. My favorite is RTL create user
thread which works really well most of the time. And then you know, at the bottom you have
like NTQAPC thread which can blue screen certain OSs, I think particularly Windows server
2008. And then for the really elite stuff you can do like Code Caving which is also known as
the Nebet Shuttle technique but it is extremely difficult to do on 64 bit windows. So wouldn't
it be nice to have another option, you know, besides one that is documented and three
that have very little support by Microsoft? So the new one that I found, it's called add monitor
and it's actually a port monitor, it's used to install a port monitor for a printer.
There are some advantages and disadvantages of it, but it's still an awesome technique. It
takes three parameters and it injects into it spool SV, you don't have the flexibility of
choosing which process to inject into like you do with some of the other APIs. But on the
positive side it doesn't require masion architecture, you know typically when you want to
inject a 64 DLL you have to be coming from a 64 bit process, otherwise there's a little
trickery involved. So it's super easy to use and in a minute I'll show you the source code and
we'll go through a demo, but it takes literally three parameters. The last one there
is the most important one, which is a monitor info 2 structure. And, again, in a second you'll
see what's contained within that. The biggest disadvantage in my mind is the DLL has to be
on disk and it requires administrative privileges. So with that, let's check out the
DLL injection demo. This one I recorded just because we have a lot of other cool stuff to
cover, so --. Okay, so I can't see very well from here, hopefully you can see better
than me, but you can see that the first, that the command line argument that we're passing is
the name of the DLL we want to inject, right? The part I just highlighted was the monitor info
2 structure which again has 3 parameters. One is generic name, the second one is just the
architecture of the system and then, again, the third one is the DLL name that we are
specifying to the command argument. You need the SE low driver privilege, which is, you
know, you can easily obtain with admin privileges and the last one you know, you just call the
function or the add monitor API with the necessary parameters. So I guess to prove it's being
injected in spool SVI, I wrote it up. Process explorer, there in the background, highlighting
spool SV, so when we actually carry out the demo, you'll see that the DLL gets loaded into
spool SV. In this case, the DLL just a test DLL that I wrote. It will do a hash dump on the local
system and then it will dump it to debug view. So it's a pretty basic demo. But as soon as we
run it, I'm going to drop back into Process Explorer here so you see the DLL, you should see
a gree line up here showing that the DLL got loaded under spool SV. There's the green line so
the DLL is running under spool SV right now, it just got loaded. And now if we check out
the debug view that DLL should have dumped out the local -- done a local hash dump. And you
can see it ran from the spool SV process. So obviously in this case I choose a, you know, the
DLL to do a hash dump. In your case, you know, it can basically do whatever you want it to do,
whatever you design the DLL to do. So that's the DLL injection technique. From there -- okay,
so from there, I want to talk a little about persistence. So first of all, there's lots of
persistence mechanisms in Windows, but which one do you guys typically use? Who uses a
service, first of all? Come on you liars, raise your hand. You all know that you use the
service, right? If you have system privs, that's what you typically use, right, is a
service. That what the ATP report by Manual, isn't that what it said? Like 75% of all
attacks create installer service, according to my good friend Bryce [laughter]. We do
have other options, right. There's run keys, there's SEH tabs, but wouldn't it be nice if
we had another option, especially something as simple as dropping a DLL tab disk and
creating and creating a registry key and have that be loaded on boot through a system level
process. DLL is super stealthy and it, we can design the DLL to do whatever we want. So like I
said, there's lots of techniques. The technique that I used to find this, I'm going to
talk about three, you know, I don't think that the techniques that I use to find these are
new. You know, definitely not, I just used process monitor and in this case, you know, you can see
that on the left, I have process monitor, monitor specifically DM ware tools. And then, you know,
I just went through all the processes, had it monitor that process specifically for DLLs
that were loaded and then start, well first of all, stop and restarted services one by one to
see which DLLs got loaded. You can see then kind of in the middle it says, name not found.
Well it tried loading the NTDSAPI.DLL [indiscernible] from the WBEN directory before it
tried loading it from system 32, so there's a DLL hijacking vulnerability there. So if we
drop a DLL into the WBEN folder named NTDSAPI ours will be loaded as that service on boot.
So it's kind of a cool technique. And that actually is one of the techniques that is
I'm disclosing right now. It's kind of a funny story that goes along with this though. The
second technique that I had listed, actually I found those probably like three years ago,
back when it was ESXI 4.0, 4.1, and I just kind of sat around and didn't do much with them and
finally my DEF CON talk comes around and of course being a good hacker I wait until the
last minute to actually start testing my stuff and I realize that in EXSI 5.5 they're
actually both patched. So I'm pulling a Stewie running around not knowing what the heck to do
because both of them get patched. But fortunately I spent a couple hours and found another
one which is the NTDSAPI.DLL. So literally all you have to do is drop that DLL into the WBEN
folder within system 32 and it will get loaded at boot time by VEM ware tools service. So
obviously the down side is VEM toos has to be installed. So it's more useful on servers or
in a virtual environment. However, we're going to go from good, better, to best. And right
now we're moving on to the best category, okay? The best is this one. And this is to create
persistence in Windows. All you need to do is create a new key at the registry key I specified
and then a value within that key named driver and the value of the driver is just the DLL you
want to get loaded. You drop the DLL into Windows systems 32 and at boot Windows will load that
DLL within the spool SV or the print spooler service. The upside is you can create as many
as you want. You want multiple DLL persistence, you create multiple keys each of them with
the value of driver, each of them specifying the DLL at boot, you know, as many persistence or
DLLs you want to run will be executed by the print spooler. So I think it's time for some
demos. That's enough of me talking. Let's move on to some fun stuff. Oh, wow! That is
really big! I was waiting for that. Okay, all right, I think that's close enough, right?
Hopefully everything fits. I tried to resize the font and everything, so - I cannot even
see that. Is that administrator? Okay. I can see why most people don't extend the desktop. Okay.
So we're going to -- first off, we'll do the first persistence which is the NTDSAPI.DLL. So
that's in demo 2. And - okay, so all we have to do for this one, there's no registry
modifications required. We just have to copy that test DLL to see Windows system 32 WBEN and
then we'll name it NTDSAPI. Did I type that right? Anybody see? NTDSAPI.DLL okay? All right, so
one file is copied. So that's it. There's no registry modifications necessary. What
this DLL does is, it just, it's similar to the first DLL it shows what process loaded it and
then dumps some information out to the debug view. So we're going to reboot. Actually, I'll
just type it because it's a little easier. So what I'm going to do is log in as fast as
possible because, again, it's being loaded in the system so it doesn't wait for me to log in to
execute the back door or the DLL. It's going to execute as soon as the service gets
started. I'm going to log in quick, start up the debug view, and we should see that DLL being
executed. Okay, it should say something about what process or what data it's running from and
where the DLL is located at. Is that what you are seeing, for those of you that can see it?
Ok, so that's the first one, it again requires the VM ware tools are installed. There are some
requirement there, but if it is installed, you have a super stealthy persistence technique
in Windows. So now we'll demo the second one. ? >> Yay! [Applause]. ? >> The second one,
like I said, I think the second one is pretty awesome. It's super stealthy and the best part
about them is when you can find logical vulnerabilities within Windows because those are a lot
harder to patch. So what we have here is we have the - there should just be an error message.
I code named it error message. So if we run that, it just take the DLL, like I said it must be
in system 32, so we'll go ahead and copy test DLL to see Windows system 32 and we'll call it
ErrorMess.DLL. I think I typed that right. So now if we just run Errormess and then just
specify the DLL that is in system 32 and then test app that I wrote just asks if you want to
load it now? And we're just going to say no because we're going to reboot the box anyway.
Then we shut down. This is basically the same test DLL and when we reboot, we should have
two persistence mechanisms on this box now. So the first persistence should be running
out of the VM tools D. The second persistence that we just installed should be running out
spool SV.DXE both of which are system processes. So there's one and it looks like there's the
other. So they are both running as they should. One should be running from VM tools and the
other should be running from spool SV. ? >> [Applause]. ? >> So -- ? >> [Applause]. ? >> So
right there we have two, you know, pretty stealthy persistence techniques. A lot
stealthier anyway than installing a service, right, because a service creats all
kinds of logs. It's kind of a dirty persistence technique, in my opinion, but it does work.
Now let's talk a little bit more about Windows APIs. I guess as a super quick prep course to
throwback, we're going to distinguish between win HTTP and 1 Inet. Those are the two main
libraries within Windows that Windows provides you when you want to write a back door. So
win http is intended primarily for services. Win Inet is for user space. So win Inet will
automatically pull user settings, it will automatically do like the NTLM authentication.
Has anybody ever had problems getting out of a network that does NTLM authentication using
an meterpreter? ? >> Yeah ? >> [Laughter]. ? >> Anybody else? Okay, well, the reason why is
because there's a certain flag that you have to set, it's called the Internet flag keep
connection. And that flag will automatically tell win Inet to do NTLM authentication at the
proxy. So something as complex as NTLM authentication, it can easily be enabled just by
setting a flag within win Inet. ? >> [Indiscernible]. ? >> Oh, great! ? >> [Laughter]. ? >>
[Applause]. ? >> I don't - I actually, I don't drink, but I came prepared with Mountain Dew,
so. ? >> [Off mic] ? >> Oh, okay. ? >> [Laughter]. ? >> You just stand there and look
pretty. We've got it. ? >> That's it? That's all I get? ? >> That's all you get. ? >>
Oh, sorry, I'm not used to drinking. ? >> [Laughter]. ? >> We're not there yet. ? >> On a
special edition of shot the new, we have a new, in addition to our new speaker,
congratulations. ? >> [Applause]. ? >> We also have a new attendee, Nikita. Everybody
say hello to Nikita. It is very tough to get accepted at DEF CON. Congratulations. How about
some love for our new speaker? ? >> [Applause]. ? >> You're done, I've got this. ? >> Okay.
? >> [Laughter]. ? >> I would have done this very differently. ? >> [Laughter]. ? >> In fact
--. ? >> [Off mic]. ? >> There we go. All right.? >> All right, wait a second, listen this is
all crap. I would have done it differently. You just take it. ? >> [Laughter]. ? >> I can't
even be on stage with this anymore. ? >> [Laughter]. ? >> Who took my alcohol? ? >> I have
it. ? >> Okay. ? >> [Laughter]. ? >> Okay. Thanks, guys. That was fun! ? >> [Laughter].
[Applause] ? >> Okay, so we'll finish talking about the two different HTTPAPIs within
Windows. As I was saying, the win Inet one is super easy to use. Doing something as complex
is as MT modification is as simple as adding the correct flag within the API column. It's
important to understand the distinction because for throwback, we actually used win
HTTP. You know, based on when doing a penetration test, what's the first thing you want to do?
You get access to a user's work station and from there you want to escalate privileges and run
from a service. So in order to do that, that's why we decided to go the win http route because
it's tailored more for services. So the back door itself is written in C++. The control
panel and the LP portion are written in PHP with MILSQ back. It was designed for stealth.
Like I said, we're trying to converge the penetration test with what an actual attack looks
like, so we want to build tools that support that methoDLLogy. So it has persistence built in,
both as a DLL and as an EXE. Here is a kind of a brief overview of how it works. An
attacker, you know, sends a spear fishing email, or you know, however you use your
imagination to gain access and infect a user's work station with the throwback executable or
the throwback DLL and gets going execution on their box. Throwback then starts leaking
out of their proxy firewall out to their throwback LP, which again is a PHP interface and it
has a control panel that we can then send command and control and we can send commands back to
the throwback door. You'll notice that there's 2 throwback LPs in this scenario, so you can
have it round robin and randomly select one of how ever many LPs you want to configure throwback
to call back to. If you want to set it up to ten, then it will randomly select one of the ten
to call back to however often you tell it to call back. So here are some other features of
throwback. A robust proxy detection. So remember I said that we used win HTTP. So win
HTTP doesn't have the robust user proxy settings that win Inet has. So what we ended up
doing to get around this was, because it does run from a service, you can impersonate
users a lot easier. So what did was we decided was to mount each user's NT user dot dat file, if
it's not able to get out initially, it tries mounting the registry file, looks in their
user settings for proxy settings within Internet Explorer and grabs those proxy settings and
uses those to try to get out. And it does that for all users that have logged into the box
for their proxy settings. Like I said, you can also set it up to use distributed LPs. So instead
of calling back to the same LP every hour or 15 minutes, you can set it up to call 5 or 10
LPs and it decreases the traffic to each domain. It also uses the MSGRPC interface to generate MSF
payloads which we will be demoing in a minute as well. It uses RC4 for encrypted
communications. So you can configure this HTTP or HTTPS. Either way the actual payload
data is encryped using RC4. It also implements reflective DLL injection. We will be demoing
that as well. Reflective DLL injection, you know, from a malware writing perspective is
the coolest thing ever. It just allows you to run other DLLs from memory. So we will be
demoing that as well. Lastly, the string encryption. So if someone does grab the binary and
starts using reverse engineering on it, all of the strings within throwback, before you put, for
example, any of the domains you want to call back to, you have to run it with a, you have to
enter them into a python script that spits out an integer array that you then copy into the C
file so the strings are not stored in clear text within the binary. So a lot of you might
look at this and say what's the difference between this and the meterpreter? I don't think
anybody would say meterpreter, and I again, I really like meterpreter, but it really
doesn't have the best offset, right. So, when you type in meterpreter script it just
randomly generates and executable on target. It randomly generates a service
whereas this is designed more for stealth and it's not an interactive tool either.
meterpreter is for interactive access, interactive shell on a target you have access to. So
with that, it doesn't have as much functionality as meterpreter either. It's just
more of a bare bones, back door that can provide stealthy persistence access within a
network. ? >> [Applause]. ? >> We'll be seeing a demo of it. This is the interface, so
remember I talked about how there's a control panel written in NPHP? This is how you control
all of the different boxes that are calling back. You can see in this case there are four calling
back. The first three are set back to call back every minute. The last one is set to call back
every ten minutes. That's changeable. When a target call back you can say, hey, now I
want you to call back every four hours. If you are not going to be being interactive operations
for a while, you can change that and modify it. So that's the interface. Again we'll be doing
a demo, right now actually, on how to do it. And hopefully I don't feel like doing this to
somebody at the end of it. Okay, so what I wanted to do is just kind of run through, you know,
when doing an assessment the general flow of an assessment, right? So here we have a cally
VM and I'm going to pull this up here. Hopefully that's big enough so you can kind of see
it. I know I can't see it on that little monitor. But we're going to be using the exploit.
It's an old IE 10 exploit, but we have customized it for this particular version of IE 10
we'll be using. And we creatively call it two girls, one sploit. ? >> [Laughter].
? >> You know, the rest of the params are pretty basic. Set it on port 80. It's an IE 10
exploit. The payload is a custom DLL inject payload. And I think this payload is one of the most
underrated payloads in Metasploit. It allows you to use a custom DLL as a payload within
Metasploit. So instead of relying on meterpreter and potentially getting flattened by
AV, you can use a custom DLL inject payload and inject whatever DLL, custom DLL you
want. So I suppose I probably should have started that up, but that's just within that resource
file. So I'm going to start up the resource file there. So that's going to start up the
exploit. Okay? I have a lot of things going on here. So this is interface. It is available on
gethubnow. So we'll log in. You can see there's one box calling back. It's just a test box. You
can see the last call back was yesterday when I was testing some stuff. So what we're going
to do, like I said, is come into here. The exploit, yep it started by now. So now, you know
obviously, it doesn't matter how you deliver the payload, that's not what this is about. This is
about, you know, using a custom - using throwback as a custom payload within metasploit. So -
and I think that's that. Just slash into HPEXP so that should - so what that's going to do is
exploit the browser, obviously. It's going to inject the custom DLL into memory. And so now if
we pull this up, we should very shortly see a new box pop up because our DLL was just
injected. ? >> [Applause]. ? >> So from here we have another target, we can install
persistence on it. At this point we're just a DLL running in memory because of the way that
we delivered throwback. If you were to deliver it through macro attack as an executable, then it
would automatically install itself, you know, as persistence. So you can do all
sorts of stuff. You can run - create a process list, which I think is this second one. Nope,
that's not it. Oh, that's actually change call back time, I believe, right? Change call
back time. So that one, actually that one is create task list, I think. I don't know what it is,
but whatever it is, we'll run it. ? >> [Laughter]. ? >> So you can see we just queued it up,
there's now a task waiting for throwback to execute. When it turns pink like that, that means
it is currently executing it. So we can come in her and you can see it's picked up the task and
then it should return the output from that task. Yep, it was a task list. ? >> [Applause]. ? >>
So when we have access to a box, what do we want? Do we want like, you know, do we want this
- I mean, we want shells, right? Isn't that what every wants? We always want a shell. So one
thing we decided to add, you can see it's calling back every minute. So what we're going to
do is, there's a functionality called met creator and what this does is this will generate a
metasploit payload, an meterpreter payload and we're going to create a raw one. And
let's do, I don't know what that is. I think that's the reverse HTTPEX86. ? >> [Off mic]. ? >>
HTTPS. Sure, that works. Okay. And then we're going to go back to our cally box. Let's see what
IP this is. And we'll go ahead and kill this because we don't need that any more. What's the
IP? It's like 20.110? ? >> [Off mic]. ? >> All right. Okay, so we'll come back - oh, not that.
This. So we want the call back to be 22.168.20.1. I think I did that wrong. Is that right? And
port 443. Okay, so now we're going to create the payload and what it's going to do is, it's
going to use the MSG RPC interface within metasploit to create the shell code to execute
this payload in an HTML file. It's going to create a shell code and it's going to look semi
normal. And then what we'll do is we'll queue up throwback to call back to this HTML file and
grab the shell code and it will inject it in the memory so meterpreter will never touch
this, it will be running from memory. So once we click "create payload" here and it creates
this handy little output folder, so we can just copy that to create our handler. So now we'll
come back into here. So one thing that's important to notice is you will notice I changed the
exit function to thread instead of process. That's important because when we inject the shell
code into another process and we come out of our meterpreter shell, we don't want it to kill
the process, we just want it to kill the thread that we created within that process. So we have
our handler listening there. The payload is being generated to that HTML file. So now let's go
ahead and queue up the task. That one. It should say, download and implement shell
code. And then the argument in this case is the process ID or the pin we want to inject into.
In this case, we're just going to cheat and I'm going to just look in the process list and
type one in. We already ran a task list, so, you know, we could just look at the task
list, but it's hard for me to see, so -. Okay, so no notepad ++ so we'll inject in notepad
++. So it's 1460. And then you have to select the target and then submit it. And we should
only have to wait, at most, a minute for it to execute it. All right, it looks like it executed
it. So if we go back now to our cally box, we have an meterpreter shell in memory.
? >> [Applause]. ? >> Okay. So that went well. ? >> [Laughter]. ? >> Okay, so going forward like
I said, throwback has been published on gethub. You will see the link in the next slide.
We have used it literally for the last four or five years. So at this point, you know, I feel
it's pretty stable and mature, but, you know, we obviously want to make it a community based
project. We're open to feedback. We're open to other people's ideas on improving it. And we
also like to create modules because it implements the reflective DLL injection. It
would be super easy to add a key logger module, cats module, hashtag module, things like
that. So in the end, the final shameless plug is if you're interested in this type of
writing custom malware, custom back doors, we are actually having or holding a course that
focuses especially on this, on throw backing and creating your own malware in Black Hat Europe
and Black Hat East Coast later this year. I'm also involved with flex grove IO if you're
interested in any spear phishing or things like that. Custom spear phishing attacks, that's
another super awesome project. You should check it out, if nothing else. The counts are
free. Thank you for attending the talk today. I appreciate your time and have fun at DEF
CON. >> [Applause]