I guess there's no goon introducing us, so we'll have to do everything ourselves.
All right, so I'm Dennis. A lot of you guys know me. Yay for Houston.
A lot of you know me from my previous talk. I talked about access control systems,
so this is going to be my second time speaking. I work for Lars Consulting.
I'm an adversarial engineer, my best, my most favorite title yet.
I am also, since I'm from Houston, I'm a founder of Houston Locksport, or Lock Picking Club,
and Houston Air and Hackers Anonymous, just a bunch of us hanging out, drinking beers,
and doing micro-talks in Houston. So, ooh, what have we got here?
Libations for your talk.
Oh, thank you so much. Round of applause for Kyle.
All right, and so I'm Tim. I'm a red team manager for Lars,
which means I don't know what to call Dennis' employee.
But more of a team lead, consultant, that sort of thing.
This is my 10th year as a DEF CON goon, so I'm eligible for retirement now, which is always fun.
Yeah, woo. I'm also a former CCDC team coach for a group of college students through CCDC.
I don't know if y'all are familiar with that program. I see you guys in the back.
Awesome. And I'm also a former CTF participant for DEF CON. I did that two years in a row.
I also ran the wireless contest for a couple of years, so I've kind of been around.
I've done a little bit of everything. This is also my second DEF CON talk.
So, what we're going to talk about is Sticky Keys.
If I say Sticky Keys, does everybody in here know what we're talking about?
That's how you get into your computer. Exactly right.
So, if you Google for how to reset Windows passwords, like eight of the top ten links
on Google are pages that tell you reboot off your rescue CD, go in, copy cmd.exe over sethc.exe,
reboot, at the login prompt, press shift five times, use Net User, change your password,
close the window, login, and you're done.
There's only one.
one or two of those sites, it actually says, clean up after yourself when you're done. So there's a lot of
boxes out there that still have CMD replaced, or CMD replacing
set HC, and these boxes are just kind of ripe for the picking. So it was
used as a persistence mechanism, like there's a kernel ownage blog on it. There's several different places
that tell you how to do this. And with this though, so there's no event
logs that are generated whenever you actually execute this backdoor. So there's no trace that
you press shift five times and you get a command prompt because it's pre-authentication.
So there's two ways that you can go about backdooring
a Windows box with this method. One of them is the binary replacement, actually replacing any of the
pre-authentication accessibility tools with CMD, or you can set
the image file execution option registry debugger key
to be CMDDXE. And so whenever you access any of the
accessibility tools from within Windows, you get a command prompt running as system
pre-authentication. So here's a list of the accessibility tools that are available
for pre-authentication. You've got the binary on the left,
the description of what the tool actually does in the middle, and on the right, you've got how you actually
access that. And so that's going to come in important later whenever we actually start talking about the tool.
But Microsoft does have some limitations on what
binaries you can replace any of the accessibility tools with.
So the first limitation is you have to have elevated access on the box. You're going to have to
have administrator system to begin with. So we're not actually exploiting the box and we're not
actually placing a backdoor. We're just taking advantage of a backdoor that
somebody else has already put on the box.
The binary must be digitally signed. This is Microsoft's restriction for that. The binary must
exist in system 32 and it must be on the Windows protected file list. And so if you've ever
ran system file checker and it goes back and says, hey look, these binaries have been replaced or there's something
wrong with them and it fixes them, that's the Windows protected file list. And you can get a list of those
from Microsoft's website. So you can't just use any old
binary. You have to use something that meets those criteria and CMDDXE meets all
three of those criteria. And so we were working with an incident
response team in our organization and they had uncovered via the file system side
of things several boxes that had this persistence mechanism put
in place. And so it was more than likely a systems administrator, could have been a rogue
admin, could have been some APT group that was in the environment. Don't know how they actually got there
but we wanted something to where we could scan for this from the network side.
So we started, well let me back up a little bit.
The problem with looking for binaries that have been replaced on the disk is you don't actually
catch the image file execution option unless you're sweeping the registry as well. You're going to miss any
unmanaged boxes. So boxes that the group doesn't have administrative access on. You're
going to miss any boxes that don't have administrative privileges. And so
we had a need for a network based scanner. We started looking into writing our
own using Java RDP or looking at Python and had a bunch of problems
and just a hate for Java that we couldn't get over.
So we ran across Zach Grace's proof of concept script, Sticky Key
Hunter. Sticky Key Hunter was a
great starting point for us. It gave us a
decent framework for how we wanted to kind of implement our script. But his
script was similar to the Peeping Tom program. If any of you are pen testers and you've seen Peeping Tom, it
scrapes a bunch of websites and will take screenshots of them and then give you
a page that you can just scroll through looking at them. And so if you're talking about a large organization
with anywhere from 20 to 100,000 endpoints, that's
a lot of screenshots just to scroll through looking for a command prompt. So we wanted a
way to automate some of
that for us.
And so Zach's script also
in the to-dos had automatic command
prompt detection and then multi-threading to make his script
faster. It took about 25 to 30 seconds per
host and we did some optimizations on that.
Alright, so we started
with the Sticky Key Hunter script that we
you know, Tim talked about.
And we went into it just
we wanted to help improve it and help
kind of complete the to-do items.
And what ended up happening is
I spent way too much time
on it just
seeing things that I wanted to do differently.
And so we ended up more than double
the lines of code of what
it originally was. And we implemented
a lot of performance improvements.
Some error handling to help with
you know, if hosts go down or whatever.
Lots of detailed logging to help
with reporting. And as well as
it's now parallelized so it'll
scan more than one host at a time.
And that dramatically improves the time it takes
to scan a list, a range of hosts
or IPs. And it also automatically
alerts on command prompts
on hosts it thinks it actually found a command prompt
on. And so you don't have to scroll
through thousands and thousands of
screenshots. And of course it's in Bash
so it's tailored toward Linux.
We programmed this on Kali Linux.
All the tools you'll need is
available for Kali.
That's our script. So let me demo this for you.
I'm going to start
by demoing what Tim
talked about. What's the
Sticky Keys vulnerability is.
So I'm going to remote desktop into
a computer and just show you
what happens. You're going to see a Windows login
prompt and we're not going to put in any
credentials. We're just going to be presented with that login
prompt. And this
computer
is vulnerable to the Sticky Key
backdoor. So all we do is press shift
five times. I'm going to do this.
There you go. And then now
you see we have a command prompt. And because this is
spawning from winlogon.exe
you can see who am I. We are
system. The highest level access
you can get on that computer. And so that's
just a method of persistence. A backdoor
that lots of people do.
And so our script, let's go back to
the PowerPoint here. Our script automates
searching for that. Automates actually
scanning for that vulnerability.
You'll see here, let's press play
carefully. Does that work?
Okay. So it's going. So you'll see it's named
banana.sh. When we recorded this
I had no idea what to name it. So Tim and I
settled on banana. But now it's
Sticky Key Slayer.
But you can see I told it to do eight
seconds at a time. It's doing a host of like 20 something
hosts. A list of 20 something hosts. And it's
going through each one. It's establishing a connection
to it. It's taking screenshot.
Hitting shift five times as well as other keyboard
shortcuts. Taking another screenshot and then comparing
the amount of black pixels that are on
the screen. And it'll alert. Okay. I found
a lot of black pixels. It's within this range
of this percentage and this percentage.
I think you have a command prompt. Once it's done
you can see the logging there. I hope the text is
not too small.
You can look through the screenshots and you
see the screenshots of all the hosts that don't have
a command prompt. And in that discovered folder
that I'm going to click on in a second, you'll see
all the hosts that actually have a command prompt.
And you can see them in there. There's
one of them. So
to reiterate, there's Sticky
Key Slayer. That's the real name.
Specify-JH for the number of jobs.
Demo host is just a list of
targets line by line.
And then you get the screenshots for
all the computers. And in the discovered
folder, there's the ones that actually have
command prompt. And there it is. And those are
computers we have full system level remote
code execution on without any work.
Using someone else's back door.
So free money.
So tool usage.
I mean that's the tool. That's the gist
of it. It's like 360 lines of code.
But that's all it does.
StickyKey
Excuse me. Tool usage
StickyKeySlayer.sh
So there's a few
parameters that you can choose. You can do
dash v for verbose. It does output
some information to you. But you can make it more
verbose if you want to. Maybe something's wrong.
Or you just want more information.
You can specify the number of jobs.
It defaults one job at a time.
But you can give it as much as you want.
As much as your CPU can handle.
Don't try 1,000 because it will crash.
But I've had success on a
Kali VM running on a MacBook Pro
about 24. And that'll scan
about 22,000 hosts in about
3 hours. So that's pretty good.
Timeout. You guys are familiar
with the concept of timeout. It'll
try a certain job for a certain amount of time
before it just errors out. You can
specify that timeout. It defaults to 30 seconds.
And then target list. You can either give it
a single target, an IP or a host
or a FQDN. Or you can give it
a list of hosts.
And that's the money right there.
You can give it a list of 20,000 hosts.
Let it run. Go home. Come back.
And get hundreds of
20,000 screenshots
when you come back.
So some limitations to the tool.
It does tie up the computer you're using.
As you can see, it was popping up
a bunch of remote desktop windows.
So it's kind of hard to use it.
It's hard to use a computer when you're
using the script. So have a VM
dedicated just to that for that time.
And
as well as
when Tim and I were doing
some scans on some other IP addresses
with their permission
wink
we found that
the majority of them
the majority of the backdoors were cmd.exe
however there were a few that were
something else like task manager or MMC
or something, you know, custom.
And our script of course doesn't detect
those because it's looking for a certain amount of
black pixels.
So maybe in the future
Tim and I are kind of working on how we're going to engineer that.
Engineer like detecting
any anomalous
behavior, not just cmd.
Statistics.
Alright, so
based on Dennis and I's assessments and then based on
some assessments from some other friends and other things
we've probably scanned about half a million boxes.
We've turned these over to some large organizations for internal
scanning and there's a pretty decent success rate internally
for some of the environments that we were in.
But we decided to turn around and
look at a large business class ISP.
I went to Shodan, did a search for
business ISP and then
port 3389 got a list of boxes
that were exposing RDP to the internet
and there were about 100,000
or so roughly in that list.
We had 570 system
shells by the time the scan was done.
It took about 6 or 8 hours to scan
that large of an IP space.
So that was one out of the real
statistic was like one out of every 173 boxes.
One out of every 175 makes a great
round number for it. But that was far more
boxes than we thought were actually going to be
vulnerable to a back door that's been around
for years. I mean our first
step into this was this is going to be stupid
nobody's ever going to do this.
And it turns out this is happening all
over the place. So by looking at the domain
names on the login screen, there's educational
institutions, there's law offices, manufacturing
facilities, hospitals,
pretty much any vertical that you can think of
have free system shells
on their boxes. So
if you step into an assessment or an environment
if you're doing an external test and they have RDP enabled
hey take a shot it may work. If you're
internal that's even better because you may find
one or two servers but those one or two servers
you've got a system shell on that you can now run
Mimikatz or go from there with absolutely
no logging.
By the way
that's 570 plus
shells we got like
with no work required. How was that
not worth a round of applause?
Wow.
Alright so now we got to talk about
what matters most right? The recommendations
the remediation, the prevention detection.
So we have a lot of, we've worked a lot
on the remediation side of this
so we came up with a few
techniques, a few
just ways to help mitigate
this. So if you do find
one of these, one of your boxes
in your environment are vulnerable to this back door
there are a few things you can do. You can delete
the executable. If there's
if CMD was replaced as sethc.exe
or any one of those other
accessibility tools you can just simply
delete them. They're not totally
necessary to make a computer function
and your computer
will eventually in an update or
when it does an integrity check it'll
it'll replace those files back to where it'd be.
If you don't want to delete them you can
force an integrity check. You can use
sfc.exe which is system file
checker that's built into Windows and what that'll
do is that'll scan
all the Windows protected files
in which all of these are Windows protected files
and it'll check are these the files
that they're supposed to be. If not
it'll replace them back to what they're supposed to be.
So you can run sfc, scan now
you can specify to do your
entire drive or specific files.
If this was done
through the registry method using the debugger
to make it run you can simply
delete that registry key. That key
does not need to be there. Delete the
whole key for sethc.exe or utilman
or whatever. And one thing
I like to
inform people is that I really
feel that they should treat this as an indicator
of compromise. If
you guys find this backdoor in your environment
it's going to be one of two things. It's going to be
someone subverted processes
and put this
backdoor in for whatever reason. Maybe
it's just a simple reason
they wanted to get in in case something goes wrong or maybe
they wanted to get in when they get fired.
So there's that
and then there's also if it's not
that reason it's an indicator of
compromise. Maybe there's a
an intrusion in your network previously.
Some malware or
APT as they call it or some threat actor.
Oh great, someone laughed at APT.
I laugh too every time.
Someone did this.
This is a known method
of persistence. I mean this is my top method.
When I go to CCDC I played against that guy
over there.
I mean we wrecked them with just
cmd.exe backdoor
because they took a snapshot of their
VMs before
after we already implemented
backdoor. So we were able to get in every time.
So treat this
as an indicator of compromise because it's serious.
It doesn't just happen.
Now going into the prevention detection
phase. Okay the simple protection. Simple
way to protect against this is restrict local
admin of course. You need to be local admin
to replace these files. So restricting
that is important.
It helps resolve a lot
of issues including this.
Full disk encryption. That will help prevent
if someone were to steal a laptop and get
access to contents that hard drive
and replace the files that way.
Full disk encryption will help protect against that.
My favorite
method of
it doesn't really protect against it.
It protects against exploitation of it is
network level authentication for remote desktop.
Network level authentication
when that's enabled
it requires valid credentials
before a console is
ever presented to the user.
So our script wouldn't work unless we had
valid credentials. So enabling
NLA across your
entire environment is
a valid protection against exploitation
of this. Against remote
exploitation. Endpoint monitoring
we've seen a lot of success with endpoint monitoring.
You can monitor a few things.
One of them being monitor when the file is
replaced. If the file is something where it's not
supposed to be alert on that.
You can also alert on if CMD
ever spawns from the
Winlogon process as a child of the
Winlogon process. That's not normal.
In my experience it's
usually not normal. So you can flag on that
as well. And then NetFlow analysis.
Simply look at are there hosts
is there one host or a few hosts in the
environment that are just spraying RDP
port 3389 everywhere. If so
maybe you should look into that.
So, oh by the way
Tim made this for me. It's great.
This is
what do you call it?
Conquest. The ears of your enemies.
The ears of my enemy. The rumor
has it these are all the shift keys
that we've broken over time from
exploiting them. So we just took them off and
made them into a necklace.
So I'm going to wear it.
So a little treat for you guys.
The code has been released
as of an hour ago. So it's on my
GitHub. Sticky key slayer.
What are you laughing at?
Sticky key slayer.
It's up there.
I put a lot of
documentation. Hopefully it's easy to
read and easy to use. I recommend
if you guys work for a big company or a small company
download it. Look at the code
so you know I'm not doing anything malicious.
Don't just download any code and run it.
But you can
if you want. I don't care.
Run this in your environment
and just see. You'll be surprised
how many you'll see out there.
There hasn't been any environment yet
that we've scanned and haven't
at least found one. So
try it. Look into it and see what you can get.
So yeah. My code's on GitHub.
I encourage you guys to contribute to it
or at least report any issues you see.
I always like to make my stuff work for
everyone. So report issues, send us feedback,
whatever you want. Slides are also online.
Demo video's online if you care about it.
That's pretty much it.
Questions?
We've also got a weaponized version in the works
that you can just say execute this
code as soon as you find a command prompt.
So you just set it and forget it and watch the
shells rain in. So that's a
good thing. I call it rainingshells.sh.
Question?
Question over there.
Can you go up to the microphone?
Oh. We'll repeat the question.
Yeah, yell.
.
Okay. Yeah, that's a good idea.
Okay, we'll do that. Okay, questions go up here.
So we have three minutes for questions.
Can you use a loud mouth in the back?
Yeah, I'm sure you have questions.
Okay, go ahead.
Is it on?
.
.
Okay, just tell me. I'll repeat it.
All right, so if you use black pixels
to determine if you got a command prompt,
what did you do to
account for the different operating
systems? For example, Windows XP has
a pure black background and
other operating systems might use
dark backgrounds.
It's the difference between the, whenever we make
an initial RDP connection, we take a screenshot
and whenever we make a, actually send all
the accessibility options, we take a
second screenshot and it's the difference between
the two. It's not just looking for black pixels, it's
looking for the different, the difference between them.
So if you look at like Dell has their default Windows
install has the front end of the Dell bezel on it that's
got a lot of black in it. Whenever you actually pop a
sticky key shell on it, it, it, it, there's more black on
the screen than there was before and so we're just
looking for the difference. It's very simple, it's
rudimentary. There's been some work out there in like
OpenCV trying to do screen shot detections and other
stuff for it. We looked into using OCR-ing the screen,
but we found a lot of boxes in non-OCR.
It's non-native English and I don't know how to do OCR
recognition in English in non-English character sets, so.
Um, the about half a million IP addresses that we've scanned
with it from us and then other people's engagements,
uh, it's great. It's like 99.96% um, effective in detecting
the screen shot every time. There were a couple of false
positives, but those false positives were due to broken
consoles to where like the top two-thirds of the screen
was the actual console, the bottom third of the screen
would just be black. Thank you. Woo-hoo!
Thank you.
Uh, yeah, I mean, so to, to, to parallelize this, we do use, uh,
GNU Parallel. Did I say that right? GNU Parallel. We use the
tool GNU Parallel and that just allows, uh, the script to spawn
itself in multiple processes and just run really, really fast.
So it's really cool looking at that tool. Question?
I think it was first. Question?
Um, do you have a list of all of the other ones that work?
Yeah, let me go back to that.
Because you said there were other ones. But you only
talked about this one.
We talked about ZHC.
There you go.
Ha-ha. Thank you.
Okay, so yeah, so...
So, just to reiterate, this is a...
So, shift five times is only one of the, uh, one, two, three,
four, five, six, seven, seven executables that'll work with
this. Uh, window key U will open Utilman, uh, on-screen
keyboard, uh, there's, uh, there's no keyboard shortcut
for that, but there's an option for that.
Um, and so they're saying we're done. We have one more
minute. Question?
One more minute.
Yeah, sure. So if you can programmatically scan and
detect these things and you can programmatically send keys,
you could also in theory programmatically add an option
to remove the back door.
Yes.
Or add dash dash evil and add your own implant and
then remove that back door.
So my goal as a troll was if you just downloaded our
code and ran it and said, hey, go ahead and just do this,
is to run SFC slash scan now as the actual, um, weaponized
code, and then drop us something in the log file to say,
hey, um, this box had this back door enabled on it,
but sorry, you just cleaned it, thanks.
Really?
Thank you guys so much. Questions will be out there,
and we'll slowly move to the bar.
Thank you guys so much for coming.