Damon, I don't know, you've spoken at Source Boston, you've spoken at DevCon.
Didn't you give a one-on-one in DevCon two years ago?
I think that's how I first was introduced to you.
Well, okay, without much ado, I'm just going to go to the next slide.
My pleasure to introduce to you Damon Small.
Thank you, Ming.
All right.
So, as you can see, I did not go through my normal pre-presentation routine that I normally go through,
but that's fine.
This will make this much more interesting, I think.
So, yeah, my name is Damon Small.
Some folks know me as Chef.
Thanks for coming out to see me.
And the title of my slide is Layer 8 and Why People are the Most Important Security Tool.
And I'm realizing, as usual, I'm a little short for that podium,
so I'll wander around.
Sorry in advance to the cameraman.
So, first of all, I want to say special thanks to, well, the Wall of Sheep,
who sponsors the Packet Hacking Village.
It's been a privilege of mine to be a volunteer staffer for the last three years.
I love DevCon, and I love this venue.
It's a lot of fun.
A lot of work, but a lot of fun.
Of course, my employer, who is helping me be out here,
so shout out to my boss and the rest of the NCC folks that I work with,
and my wife and editor.
My wife and editor.
My wife gets to go through all these slide decks that I do,
and she takes out the mistakes and makes them suck a little bit less.
So, thanks, hon, for reading through it.
Last but not least, you.
Every time I get accepted to present somewhere, after the excitement wears off,
you then wonder, it's like, oh, God, is anyone going to show up?
Especially, you know, it's in the afternoon.
It's been a long day.
So, people have shown up, so thank you very much to all of you.
Thank you for sitting through this, and I mentioned that my employer was helping me be out here,
which I'm very, very grateful for.
So, you'll have to sit through a short commercial.
I work for the NCC group.
We're a large global cybersecurity company, 35 offices.
That number in the lower right is incorrect.
We released our annual financials a couple weeks ago,
and we actually did 244 million pounds in revenue last year.
So, it was a good year.
We have a lot of services.
We do a lot of work.
We do a lot of things.
We've got 2,000 geeks globally, and a lot of offices.
And enough about them.
Let's talk about me.
My name is Damon.
Like I said, tech director for NCC group in North America.
I've been in IT since 1995, and I started focusing on InfoSec in 2001.
The dot-com bubble had burst around 2000,
so that was a good time to kind of change my career a little bit,
and I think I got lucky and thought,
back then, that, well, security is probably going to be a problem for a while,
so that's a good area to go into, and I think I was right.
Louisiana native, go Tigers.
Any LSU fans here?
Oh, really?
Right on.
Okay, cool.
That was unexpected.
I studied music at LSU.
I was in Tiger Band and all that.
I went to grad school in 2005.
I spent most of my career in Blue Team,
and I've worked in the healthcare, DOD, aerospace, and oil and gas industries,
as far as I know.
There's a nice picture of me, which reminds me of a joke.
How do you know when someone is a DEFCON speaker?
They'll tell you.
There you go.
shout out to my buddy Dennis who's spoken on the big stage three times
alright so let's get into it how did this slide deck
come to be so I'll tell you a little story about that I'm a bit of a digital
pack rat and I ran across a white paper that I had written about a decade
ago I believe it was and I found this old white paper and I thought
well this is going to be comical because this is old material and it's probably not aged very
well and it's not going to make any sense and I read the white paper and I was shocked to discover
that it was actually still quite relevant
particularly in the context of the wall of sheep because if you've been over across
the hall and you've seen what we do with packet detective and capture
the packet and some of the training we do we're very much about
you know basic skills that are important for everybody
in infosec regardless of what your role is and especially since our capture
the packet contest is you know it's a CTF basically but you're
finding telemetry on a network
as it's flying across so as we get into this I think you'll see why I thought hey
the wall of sheep is the perfect venue for this
so yeah the techniques are simple and old but remain very useful I like telling
stories so I thought this was an interesting narrative and
WannaCry had just happened when I started putting this slide deck together and a lot of the
techniques I'll talk about from the incident from a decade ago are still quite relevant
so quick
poll of the audience how many folks in here on some regular basis will use tools like
TCP dump or win dump to examine network traffic okay a few hands
what about something like some of the PS tools stuff like
PS exact or things like that yeah some other hands I mean so those are tools that have been around for a while right
they're not new but we'll see how I think I think they'll be interesting
as we get into this so to start off I mean if you work in any kind of IT department you know you've got you
know people time and money are limited and you face a myriad of decisions every day to try and
figure out what tools what technical controls are you going to use you've got to make purchasing
decisions to try and figure out you know which are the right widgets for your environment and
you have to remain fiscally responsible though right so you can't you know you can't buy everything
But I wonder sometimes if in business, if we spend too much time worrying about which widget to get
and we don't spend enough time looking at the human beings that we have in our IT teams and our InfoSec teams.
So to start off, the first case study I'll go through, the name of the white paper was actually called Finding the Needle.
And so to set it up, it was December 2004, and a primary firewall of a health care provider failed.
And it failed over to the backup firewall.
And, of course, the networking team was keenly interested in trying to figure out why the failure had occurred.
And they noticed a large volume of traffic on port 135.
And there was also a periodic burst of Internet-bound traffic on various ephemeral ports.
So there was a lot of traffic on the perimeter.
On multiple.
On 135 and lots of other high TCP port traffic.
So they were, you know, trying to figure out, okay, based on that information, what is going on?
Of course, you know, a lot of folks immediately suspected something malicious, some malicious software.
But we had several technological limitations to deal with.
Namely, some of the, and I heard the previous speaker was talking about spoofed IP addresses and things.
So it's kind of funny that that came up.
But some of the source IP addresses were spoofed.
So, obviously, they weren't valid packets.
So we couldn't figure out, you know, from where they were coming.
This health care provider also had a lot of third-party supported systems that they themselves didn't have access to.
So they were, you know, tenants on their network.
But they didn't have control over them.
At the time, this shop had something like 8,000 workstations.
But, you know, health care environments are very difficult to manage.
And, you know, antivirus wasn't necessary.
It wasn't necessarily fully functional on all of those machines.
And, again, many of those were third-party supported.
Some of this should sound familiar to my two buddies down there.
Yeah, it doesn't?
Okay.
So, and lastly, the networking team at the time.
And, again, this was, what year did I say this was?
This was a long time ago.
They had protocol analyzers.
But they didn't, the protocol analyzers were really good at giving you trends over time.
But they weren't really good at giving you visibility into real-time traffic.
On the network.
So they were having a hard time sorting out what was going on.
So due to these limitations, they couldn't really troubleshoot any further than just saying,
yep, something had gone horribly wrong.
So they, in that last bullet point there, they begrudgingly engaged the InfoSec team.
And I say begrudgingly.
At the time, network teams weren't really keen.
To let anybody else look at their infrastructure or work on it.
And the InfoSec team, you know, back a decade or more ago, was viewed as the guys that managed, you know, access and identity.
It was really it.
And we had told them, it was like, look, we've got some pretty cool tools.
We could help you out.
But, you know, they're like, no, no, no, you're not a network person.
You can't get on there.
So after they figured out they were kind of stuck, they engaged us and said, okay, will you help us out?
And we were happy to.
So what we needed to know was this.
From where the traffic came to where it was going, what was causing it and how to get rid of it.
Those are very basic questions, right?
I mean, that shouldn't be a huge problem.
But we couldn't answer those four questions.
So I'm going to step through how the creativity of the human beings involved in this using very basic tools and techniques were able to answer those questions where the network team was unable to.
So the first thing.
We had some detective methods.
We had commercial antivirus, of course, on the network.
But I've already mentioned that it wasn't fully functional on some workstations.
So we couldn't depend on it for 100% visibility into our entire environment.
We had an IPS and it was giving us some information.
I'll touch on that a little more.
But interestingly, the most useful thing we had was wind dump, which, of course, is the Windows load of TCP dump that we use on Unix.
All the time in Linux.
So all we did was we got access to a span port near the perimeter so we knew we would see all the traffic.
And we just simply ran wind dump looking for destination port 135.
That was it.
So simple.
But it was a capability that we didn't have in other parts of the organization.
So from that, we were able to figure out which hosts were generating all that traffic.
And we were able to navigate around port 135, which as it turns out was the malicious software trying to propagate to other hosts.
So now that we started gathering a list of who the bad guys were, who the bad hosts were, we were able to target individual machines that were infected and try and clean the mess up.
We found various self-propagating worms that took advantage of the RBCD COM buffer overflow.
And there was also an LSAS buffer overflow at the time.
So there were like two different platforms.
self-propagating softwares, exploiting two different
vulnerabilities on our network. Now I'll pause just to say that
that is a bad day. You know, one piece of malicious software is
no good and two is twice as no good. Looked like Blaster and
Sasser and patches existed but recall that, you know, this was
2004. It's hard to get patches installed on a large environment
today. It was, you know, even harder back then. And in 2004,
we were still going through the narrative of trying to decide,
oh, you know, we patch every quarter, you know, whether we
need to or not. That's enough, right? And even now we still
struggle with trying to figure out, you know, well, I mean, it's
got to be monthly, right? Because that's when patch
Tuesday is. So, yeah, so we weren't, the point is we were
not patched at all. So just, I'm sure most of us, if not all
of us in here, are familiar with patching. But, you know,
we're familiar with botnet worms. But just to give a little
context before I move forward here, I'll say that, you know, a
lot of times they'll do command and control through, in these
cases, these specific examples, they were using internet relay
chat. I think there was a period of time where the only people
that ever used internet relay chat was malicious software. So
the worm logs into an IRC channel and receives instructions
from the bad guy. And then the bad guy can use these zombie
computers for other bad things, right?
I mean, I'm pretty sure we're all familiar with this. But
interestingly, the traffic from the worm propagating and also
logging into the IRC channel caused so much traffic that it
crippled our network. So we had some information. We knew where
the bad traffic was coming from. But we still needed to gather
more data. So, like I said, we had problems with antivirus not
giving us complete data. It really wasn't helping us. You
know, we enabled the IRC log-in event rules on the IPS. You may
be wondering why weren't they enabled in the first place. And
you know, who knows? Tuning devices is hard. And by turning
on the IRC log-in event rules on the IPS, we found three
different IRC channels that the malicious softwares were using.
Of course, I've obfuscated the IP addresses, but, you know,
there they are, the three different ones that existed. But
because we were blocking the IRC log-in events, we actually
created another problem for ourselves, which was the IPS
existed on the external interface of the firewall such
that the firewall had translated the addresses to a routable IP
address before the IPS saw it. So at the point at which the IPS
blocked the traffic, all I saw was the NAT address. And to
figure out what the RFC 1918 address was, we had to go through
the firewall logs and look at the NAT tables, and that was a
huge pain. Very time-consuming. We had to go through the firewall logs and look at the NAT tables, and that was a huge pain. Very time-consuming. So, you know,
consuming. And it was then that we realized that note to self
you should probably put the IPS on the internal interface of the
firewall or otherwise positioned such that you can see the 1918
addresses before they're translated. Again it was 2004.
IPSs were new and exciting back then so we were still sorting a
lot of things out. So what did we do? Wind dump to the rescue
again. So we already knew what those three IRC channels were so
it was trivial to as you see there to set up a string that
would look for any traffic going to any three of those hosts. And
we quickly so we started seeing all kinds of traffic and it was
like great so we're seeing more traffic but if you've ever done
wind dump you know stuff flies by and yes you can write it to
disk and grep it and those sorts of things. But we still
weren't having very much luck on quickly figuring out where the
infected hosts were. So here's another tool. Anybody use snort
or something similar? I'm sure you do. Yep. So it's really easy
you can see the syntax there. I mean it's so easy I could write
that. And all we did is say that look we set up a variable
that included the three IP addresses of the botnets we are
interested in. And we told snort to just alert us any time it saw
traffic going to there. And it was a lot easier to generate a
list of infected hosts. So we set up a variable that included the
infected host using this technique rather than going
through a bunch of you know wind dump logs. So interestingly as
we were going through the logs of the alerts we would capture
packets. Again shout out to wall of sheep. And we started
seeing all sorts of interesting things. Which is the militia
software actually logging in to the IRC channel. And getting
ready to receive commands from the back end of the network. And
we can see the data. We can see the data that we have. And we
can see the data that we have. So I'm not going to walk through
this. But this is one of those artifacts that during an incident
response or during an investigation you will stumble
across data like this and I don't know. I thought it was
kind of cool. And that was one of those moments when I was
reading it you know more than ten years after I had written it.
I was like huh. That's interesting. We can also see
yeah so the militia software continues to get logged in. And
there are on the second line there are 4,253 invisible users.
So I mean I reckon that means that's how many other devices
had logged in. So I mean by today's standards that's not a
large bot net. But it was still you know pretty interesting to
see that. And here towards the end of the conversation it
appears that the bad guy sent a command to our host to begin
scanning. That 10.32 network was part of our network. And it
was scanning looking for port 445 being open presumably to
find other hosts that were potentially vulnerable. In this
case I believe that would have been the LSAS buffer overflow.
So we actually saw as we were looking at this traffic you know
the actual evidence of the malicious activity going on. And
of course for you know a bad guy you know a malicious user to be
successful at what he's doing he's got to you know find other
hosts and exploit them. So we see the scan starting here. And
then we see where the software actually found other malicious
hosts. And there they are. So that was useful because you know
while the exploit was still taking place we already knew who
those hosts were. And then we see the bad guy continuing on to
take over. It looked like this might have been a SYN flood
against port 6667 and other ports. So maybe this is somebody
that you know the malicious actor was interested in taking
down or something. But you know and meanwhile you know our
firewall is falling over. And now you know we got computers on
our network launching SYN floods against other people. So that
sucked. But so we figured out a bunch of things using very very
simple tools. We figured out a lot of things. We figured out a
lot of information that other you know as I said other parts of
our organization were not able to figure out. So now that we
knew all this stuff now it's time to kind of clean up the
mess. And try and get rid of it. So again antivirus was
largely nonfunctional. We had third party devices. Oh and it
being a hospital system we had biomedical devices. Now if we
had more time this is where I'd go on my rant about FDA 510
cases. I'd go on my rant about FDA 510 cases. I'd go on my rant
about FDA 510 cases. I'd go on my rant about FDA 510 cases. I's
more aboutress on healthcare and why biomedical device
manufacturers don't want to patch their device because
they think the federal Gotan' birth don't want them to do it.
And it's not true. But suffice to say they were devices that
had SOLIDWORKS. S central communication that
had Windows based computers in them. Um Actually I will tell
half of this story. So while this was happening, you know I
have the microphone and changed my mind. Um so we had a it was
U H F or V H F radios on the radio and we are seeing the
traffic coming from some device and we knew what Ethernet port
it was on so therefore the engineers were able to tell us
what room it was in. So I get on the radio and it's like hey
someone in hospital blah blah blah go to room 67 and turn off
the computer that's in there because it's making a lot of
noise and breaking things. And the guy radios back and said
okay I'm in this room and there's no computer here. I was
like dude that's not possible. I'm looking at the traffic. I
know the Ethernet port is in that room. There's got to be a
computer in there turn it off. And he's like look. And I said
where are you? Physically where are you? He's like well I'm in
radiology and I'm telling you there's no bloody computer in
here. I'm like alright fine. So I told the engineer alright
turn off that Ethernet port. I don't know what that device is
but turn it off. We'd been talking to the hospital
administration the whole time during this thing so they knew
that stuff was going on. So we disabled the port, took the
machine offline and within about 90 seconds my computer
my phone rings and it's the director of the ED at the
hospital. And he says hi our only x-ray machine just went
offline so I'm putting the entire hospital on drive-by.
Drive-by meaning they can't accept new patients because they
don't have an x-ray machine. So if an ambulance was on the way
to that hospital they get to turn around and go somewhere else
because they can't admit new patients. And so the director
continued and said what did you just do? And I'm like well I
mean nothing. I turned off a network port but you know it was
a Windows box and you said it was an x-ray machine. That can't
be an x-ray machine. And he said no no actually it runs
Windows XP. Huh. So I get back on the radio and I ask the
desktop guys like so you said there was a big box in there
apparently it's an x-ray machine. Does it have a
screen on it or something? And he goes over there and poke poke
poke huh it runs Windows XP. I'm like oh god we just turned off
the only x-ray machine in this entire hospital. So then the
trick was you know do you turn it back on so you could admit
patients because I you know I'm a computer geek. I'm not in the
business of making life and death decisions right. That's why
I went into computer science and not medicine. So we turned the
machine back on and I told him I was going to turn it back on.
I was like look man if I see it start propagating outside the
organization we'll have no choice but to turn it off. So you
know your call if you want to put somebody in there. So
anyway that that was like you know early in my career and one
of the worst moments I had because you think as you know in
computer you know if you're in IT or infosec or whatever you
know I'm dealing with you know packets and computers and you
know if a computer doesn't isn't doing what I want it to do you
just turn the damn thing off. You don't have to worry about it
and then you know so I turned the damn thing off and now I got
you know people in the ambulance and you know people in the
ambulance is getting rerouted and so I chose to leave health
care of course and got into consulting instead. So alright I
told that story. Thanks for sitting through that. So now that
we knew who the infected hosts were talking to and we knew who
the infected hosts were now we needed to try and figure out you
know what actual software is doing this and how do we get rid
of it. So if you look at some of these logs from Snort
the blue bits of course that's an IP address so we knew which
hosts were infected and then it also told us which port was
being used on the red bits there. So we had a port so we
have a little more information now so now it's time to find the
offending process. Anyone ever use F port? It's a great tool
there's other tools that will give you the same information
this is one of many ways to find this information out. But we had
access to the network. So we had access to the network and we
had access to the remote machines. Again disclaimer this
was 2004. Everybody had local admin on every machine because
why not. So it was easy to run F port and figure out so I knew
that what was that number 1303. So if you look at all the
processes look process 1420 sure enough was using port 1303. And
look at that the executable associated with it is W32 USB2
.exe. Not to be confused with the actual windows process W32
USB.exe. So of course they gave it a file name that would make it
easy to overlook and not know what you're seeing. So now we
knew what piece of software was doing all this. Great. So how do
we stop it? Well thankfully malicious software back then was
much much less sophisticated than it is today. So we could use
another tool called PS kill. Probably one of the most popular
ways to process kill. You give it a UNC path to an IP address.
You give it the name of the process. Again W32 USB2 and it
kills it. It's a lot harder to do now. A lot of malicious
software it will protect itself and reinstall itself and you
can't necessarily just stop the process and delete it. But again
the point is these were very simple techniques we were using
to overcome technical deficiencies that we had. So
we went through this and to be fair this is very much a manual
process. In a sufficiently large organization this would not
likely scale very well. You could script it I imagine and
still be useful. But as we went through this process we found
several. So I had mentioned that there were two vulnerabilities
that were being exploited. All told there was one, two, three,
four different infected files with a variety of different
malicious softwares. As you see there's spy bot, woot bot,
randex spy bot, rbot and the list goes on. I think the
message here is there was a lot of these types of softwares being
used around that time. And I'm not sure that we ever figured
out who patient zero was. How that stuff got inside our
network. But the point is it was a variety of things that were
eating us up not just one thing. So the lesson here knowing
which screw to turn. So there's a story. I have no idea if it's
true or not. But it's very interesting and I like to
believe it's true. Where a machinist was hired to fix an
electric generator that wasn't working. And this was you know
way back in the 20th century somewhere. And so the machinist
walked in, looked at the device, turned a screw and then
the generator started working again and he submitted his
invoice for $10,000. So that's a lot of work. And so the
client was like I mean $10,000 you turned a screw. You know you
got to itemize that invoice and tell me what are you charging me
for because that seems like an awful lot of money. So he said
fine. I charged you $1 for turning the screw and I charged
you $9,999 for knowing which screw to turn. So as I've walked
through what we did, hopefully none of you are sitting there
thinking wow that was really impressive that they knew how to
use very, very basic software. So I'm going to give you a
little bit of an overview of the security tools that everybody
in this room probably knows how to use. But we were in an incident
response situation where our other response techniques had
failed and we felt like that we just happened to know which
screw to turn. And the huge win in our case was not that
anything we did was necessarily amazing but it was very
effective and it overcame several challenges. Understanding the nature
and the context of the incident based on the collective experience
of all of us involved is what resulted in the malware
eventually being eradicated. And as I mentioned in the beginning
of this, if you go over to packet detective or capture the
packet, a lot of these techniques are very, very similar
to what you're still doing today. And so it's I think even
though they're not the exciting, you know, kind of layer
seven sorts of things that are becoming ever more popular,
they're still very, very relevant. So one more case study that goes
over some very similar things involved web dev vulnerabilities
existed. It was back in 2003. I think it was on the weekend. I
got a call from one of my buddies that had a new server he
had deployed in the DMZ. And I answered the phone and he was
like, hey, man, do you want to see a dead body? Recall we worked
for a hospital system so I wasn't sure if that was a euphemism or
something. So I didn't know where it was. I was like, what do
you mean? And he's like, yeah, I got a server in the DMZ and
there's a problem with it. I noticed that the C drive was
filled up. I'm like, okay, what filled it up? Well, I don't
know. So, yeah. Then it became interesting. He looked at the C
drive of his machine that he had deployed. It was probably very
difficult to see, but none of that stuff had anything to do
with making sick people healthy. So we immediately thought, okay,
well, what does the network profile of this box look like? So
we scanned it and there was three, we pretty much knew what
everything, oh, look, FTP was on there. Again, 2003, don't be a
hater. So we knew what everything was except those bits
in red. We weren't sure what the ports, 1978, 2003 and 3460. So
those were the ones we knew just a quick in map and we
knew, okay, those are the things we need to look at first
to figure out what's going on. So F port, again, saved us. We ran
F port on it and figured out that port 2003 was being used by
a process called WIMNGNT, not to be confused with the
legitimate Windows process called WIMN, oh, now I can't
remember. It's spelled different. Trust me. Oh, there it
is. Right there. Yeah. I should have done that. I should have
read my own slides. WIMNGNT, not NT. Okay. So, all right, that
didn't, we knew that was sketchy. We didn't know what it was. So
what did we do? Well, of course, we telnet it over to
port 2003 to see what it was. And apparently the bad guy
wasn't done configuring his server, but we had, you know, it
responded with a banner and it had, it was, you know, once it
was set up, it would have had server statistics and, you know,
this was a rogue FTP server. So, you know, it was, you know,
this was a FTP site that was on our server in the hospital. So
that was kind of neat. And I'm glad, thank goodness I'm a
digital pack rat and I saved all of this information. Here I
am, you know, 15 years later talking about it. We continued
to look around the server to see what was interesting there. We
found a file called rb.bat and apparently that was the install
script that was used. And you can see it installs some things,
starts some services up.
And so, yeah, I'm not going to talk through the technical
details of it. It was just interesting that we found
artifacts left over by the bad guy. And so this is probably a
well-known technique probably for most folks in here. But the
hacker was kind enough to patch our system once he or she was
done. So you can see here that the script stops the vulnerable
service, modifies the registry such that that service was no
longer vulnerable to the web dev buffer. So, you can see here,
over flow, imported some information and then restarted
the service at some point. And I think we all know why they do
that. But, again, back in 2004, that was a bit non-intuitive.
You know, why did the bad person take the trouble to patch
our server after he attacked it? Well, of course, the answer is
because the bad guy didn't want anybody else to also compromise
that server and gain access to the server's resources. So, at
least we knew that machine would only
get owned once, I guess, with, you know. But, of course, any
malicious software can only continue to exist if it finds
other victims. So as we continued to look through the
logs and whatnot that had been left behind, it began looking
for new victims. So you can see it was looking for other hosts
that had web dev enabled. I obfuscated those because those
were not RFC 1918 IP addresses. They were routable IP addresses,
which meant, you know, it was a little bit of a challenge to
make sure that the hospital that I worked for was attacking
other people out on the open Internet, which means that, you
know, you're going to start getting, you know, angry phone
calls from ISPs and whatnot wondering what you're doing.
Excuse me. Lastly, that hacker was nice enough to leave behind
his calling card. I started Googling some of the key words
on there, and they started redirecting to a lot of TLDs
that I have no interest in communicating with, so.
If anyone would like to research that further and let me
know who these people are or who they were, but like I said, you
know, it was a lot of, yeah, a lot of domains I didn't want to
visit. So that, again, none of those techniques were
mind-blowing or complex or anything, but it was just very
simple techniques that a couple guys on the weekend, we went
through and figured some interesting things out. But
there is another side of the coin.
So I've talked about how people can be the most useful security
tool, but sometimes we're the problem as well. And this is a
much shorter part of this slide deck, so don't panic. We're
getting close to the end. Thank you for still being here. It
was on a red team exercise, and we had a very complex nine-step
attack chain. And I'll show you a picture of the attack chain
just to make the point that, ooh, this was really hard. But
during that nine-step attack chain, we got very, very lucky
because the reason the attack chain worked was because of human
error on the part of the client. For example, we gained access to a
workstation on which the administrator left credentials
in a spreadsheet on his desktop. And this was last year. This was
2016 when this happened. Okay. Don't leave your creds in a
spreadsheet. This was in 2016. Don't leave your creds in a
encrypted. Unencrypted. I didn't put this in the slide deck,
but also, do not name the spreadsheet credentials.CSV. You
you don't have to be a very clever red teamer to figure out
that that's a file I'm going to open. And then we went through
the attack chain. Once we had domain admin, during the read
out, we asked the client, look, we were in domain admin for like
three days before anyone said anything. You should probably
monitor the DA group. And they said, we do. All right. So we
asked, why didn't you notice that we had created an account
for ourselves in the group? And they said, well, because the
monitoring system that checked DA had failed. So you need a
monitoring system for the monitoring system. And that
sounds funny and everything, but it's true. I mean, if you've
got one box that does a critical thing. So that was human error
as well. They had a bad design. And whomever was responsible
for that system hadn't checked it, apparently, because it
wasn't doing its job. So this, I mean, this is a very good
example. This has been sanitized. But, I mean, this
looks amazing. But, again, I'm making the point that if it
weren't for a couple of key failures by people, then we
would not have been successful. So that's the cynical point of
view, is that people, a lot of times, you know, there are
processes. There are technical controls. There are things in
place that will stop bad things from happening. But we're not
perfect. And we, you know, sometimes we make mistakes. And
this is what happens. So to start to wrap it up, I'm going
to give you a couple of examples. And I just copied and
pasted this directly from the white paper I mentioned that I
wrote. So we had several technological challenges. We
used commercial and freely obtainable tools. And we
overcame the obstacles in a resourceful and cost-efficient
manner. So the point is, problems can be solved
creatively. I really do speak English, I promise. Using
limited resources. And so we have to regularly evaluate the
commercial products to use inside our organizations. But
properly trained personnel can be more valuable to an
organization than any hardware or software device. So what can
we do as information security professionals? Now this is where
the conversation usually begins. And you may or may not agree with
me. And if you don't agree with me, that's awesome. Because then
you can tell me your opinion and maybe I can learn something to
change. But I think we should spend on people first and
technology second. If you build a team around a set of
technologies that you deploy, then when those technologies
change, you may be left with the wrong team for your
organization. So I advocate for building the team first and
making sure they're enabled to adapt as the technology changes
because it's the people that are more important, I think. When
you're ready to spend on technology, make sure you consider the
skills of the people you already have. You might make a decision to
deploy a certain technology based on your support model. Or maybe
you know if you're going to deploy a certain technology, then you
will have to include training to get your people the appropriate
skills to support it. And that's, you know, identify those gaps.
Understand what's going to, it's not just buying the widget. With
all due respect to any sales folks that might be here, just
because someone says, oh, yeah, this product's easy to support
and doesn't require any training, that's rarely true, right? And
work outside your organizational silos. I think this is less of a
problem these days, but I mentioned in the beginning slides that
our networking team was reluctant to engage the InfoSec team
because, you know, we were in a different silo. I think that's
less of a problem these days, but, you know, just be aware of
the capabilities that exist in your organization outside of the
one in which you work. So, that's my story. I'm sticking to
it. Many thanks. Oh, right. So, I know putting up a QR code in
front of an InfoSec crowd is probably a wildly unpopular idea.
You can trust me. There's nothing malicious in there. So,
go ahead and scan it. Everybody scan it right now. So, anyway,
that's me. That's my e-mail address on Twitter. I'm Damon
Small. Comments or questions before we wrap up?
I guess this is where Ming gets up and says comments or
questions. So, any comments and questions, please. Thank you,
Ming. Nothing. All right. So, I'll be around. I will be over
there with the wall of sheep most of the time. I'm happy to
talk about this more. If anyone has any comments or questions
later on you want to ask me or catch me, please do. Thank you
for sitting through this. Enjoy the rest of DEF CON 25. Cheers.
Thank you.