- I've been able to find
indicators of compromise, strange traffic, threat
hunting-style things, while troubleshooting other problems. Things that we weren't even looking for. - There's no way that's legit. Why would on earth would you send internal information like
that to some random server? - So what protections do we have in place for our outgoing web traffic? (exciting music playing) - Hi Everyone, David Bombal. Back with Chris. Chris, welcome. - Great to be back David.
Hope you're doing okay? - I'm well and I'm really
excited about this. We were talking offline, this is something that you've
been doing a lot of work on and really enjoying is that right? - Absolutely, threat hunting,
it's an interesting topic. It's a big world of
traffic to look through. A lot of different
types of attack patterns and things that we can find. So I've been eating it up and I'm excited to share
some of what I've found. - You have been studying this stuff, but then at the same time you've been like using some
of the stuff you've learned on real world engagements. Give us some of the stories 'cause were telling me offline some of the cool stuff that you found. - So for years, people
have been coming to me with problems on their network. - Something slow.
- [David] Yeah. - There's an application that
doesn't connect properly. - Says you could have network
connectivity problems. - It's the network stuff. So they'll grab traffic, they'll send it to me, "Hey
Chris, I just need help." And one of the reasons why I
specialized in TCP analysis is 'cause that's what I
was troubleshooting, right? If something was slow, a
handshake looked weird. So those are things that
I constantly was doing from a consultant perspective,
actually fixing things, so it wasn't difficult to
bring that into the course or develop courses around that topic. But over the last few years, that's definitely been changing. Now I'm getting approached
more by SOC teams or someone within the
networking side of the house is responsible for digging
deeper into a problem that comes more from a security angle. So a few years ago, and we've chatted about
this on the channel, I started going for some
cybersecurity certifications 'cause I at least wanted
to have a good basis on cybersecurity in general, right? Just to get my hands around, "Typically what does a SOC member know?" Or even from a pentester perspective, "What types of attacks
are they gonna generate?" All the while doing that,
I had Wireshark running. So I was able to get an idea of what an attack starts
to look like on the wire, which is my -- I'm a packet head, that's my visibility into the world. Not to say there's not
a thousand other tools that can help with this, 100%. We're actually gonna look at that today. But from a packet perspective, I find I don't really get it
until I see it on the wire. And then I can, first of
all, I won't forget it, but I also can now adapt
that to other tools. So what started to happen is since I've been developing
more content around this, threat hunting, malware analysis and such, you're gonna see in my Wireshark, now I have a lot more buttons
there, preset filters. I've found that even when I'm doing
troubleshooting for a company, it's not the network style
stuff, something slow, I've been able to find
indicators of compromise, strange traffic, threat
hunting style things while troubleshooting other problems, things that we weren't even looking for. A few weeks ago I was doing
an analysis for a company. They were having a slow problem. They were having external
traffic from their users go through this proxy that came into this big web environment. At certain points of the day, things just were dragging and dragging, but then it would seem to resolve. What we were able to find is that when we did our capture, we just captured on
each side of the proxy, and the users coming in
and then the application, and I found this big burst of
traffic that was happening. And it started to happen regularly, like every 10 minutes or so. And I asked him, "So
like should this proxy be talking to literally directly
to one of your databases?" And the answer was "No." And we found that there was a bunch of
SQL traffic coming back and then that traffic on the other side was being sent to somewhere in a country it shouldn't have been sent to. I'll refrain from mentioning anyone. So those types of things, I start to start to see more often because now just having more
of an awareness of threats and how these types of attacks work, now my Wireshark profiles are
more configured to find them and help me spot them to begin with. But just as an analyst now, I'm more tuned to think in those terms. And that's where a Threat
Hunting with Wireshark course was really hatched. - Just some updates,
you teaching at DEFCON, at the time it was
recording, it's next week. And you just taught this content
around this at SharkFest, is that right? - [Chris] Yeah, I did. So we just had SharkFest, which is the Wireshark users
and developers conference. It happened in Kansas
City a few weeks ago. And I was invited to teach this Threat Hunting with Wireshark course as a pre-conference course. We had lots of attendees to it. We had people that wanted
to dig into these problems on the wire; we had a lot of fun. After that I was able
to repeat that training to a couple other organizations and now at DEFCON is going to
be in two different formats. There's gonna be a four hour workshop and then a full two day course that is gonna be happening through DEFCON. I'm basically gonna be taking
some pieces of that course, as well as some of the
TCP Deep Dive content and sharing that again at DEFCON. - That's amazing. I mean, you're gonna be sharing some of that now, but I've kind of twisted
your arm to create a course. So hopefully at some point, you're gonna have a course on this topic, which we'll link below, is that right? - David, you're a persuasive guy, so I think we're gonna put
that together for everybody. - That's great. So Chris,
without further ado, let's see some packets 'cause
you and I talk too much. So let's jump into the
packets and you know, show us what you've got. - You bet, absolutely. All right, so first of
all, before we get started, let's go ahead and set the stage. Number one, I'm wearing
the wrong color hat. So let's just fix that. (fingers snapping, digital chiming) Okay, that's better now
I'm wearing a blue hat. This is typically a blue
team thing, SOC analyst. So we're looking for attacks. But let's get a definition
of, "What's threat hunting?" Let's go ahead and take
a look at a definition. I like this one, it was taken
from the CompTIA website and it says "Threat hunters
are IT professionals who proactively find cybersecurity threats and mitigate them." Gonna pause on a few of these words here. First, a threat hunter. Are they just seasoned
veterans within the SOC team? What do you think, David? - Well, I don't know, it can vary. I mean I always hate that people think you have to have years
and years of experience because even if you're new,
you might catch something. - Completely agreed. And here this definition
says IT professionals. You could be a network technician, you could be on your first
job just on the help desk and you could find something and you're a threat hunter, all right? So we're talking to everybody right now. We're not talking about
seasoned pentesters that have been in this
industry for tech decades or SOC analysts that
already have their tool set that's just like, you
know, Swiss army knife and all those kinds of things,
although they can benefit. Let's just get a clear definition here. This first of all is all
IT, and also proactive. Proactive means we
don't wait for an alert, if we're threat hunting. We're not sitting around and hoping that we see some alert come up on an IDS/IPS system
or some other tool has, "Brr, brr, brr, brr,
you've been breached." Well then we go into
incident response, recovery. Threat hunting is when we don't yet even have
an alert; it's proactive. Now, why is this important?
And what is abnormal? I'm gonna show you some stuff when we get into the weeds of Wireshark here in just a moment. But why threat hunting with
Wireshark specifically? Why is this a good tool
to add to that tool set? Well, first of all, our systems are being attacked everybody. We're under attack, we're at cyber war. If we don't think so, then we have a false
sense of security, right? We are under attack. We've
gotta have that mindset. Second, our IDS/IPS systems are good. Yes, someone's watching the front door. That is true. Well, in most environments. Or if we don't have someone
watching the front door, we should at least get
an open source Suricata, get some SNORT going,
a Zeek IDS, pick one. And we need to be able to
watch dog our front door. However, it's good, but it's not perfect. These systems are largely built on previously defined signatures
from previous attacks. Attacks are changing every day, new threat actors, new attack vectors. So we need to keep on the watch. Also our IDS/IPS can't be
everywhere all the time. I just said it. A lot of times they're
watching the front door, but when it comes to a thief
breaking into my house, there's a whole lot of other ways they could get in than my front door. There's other places within our network we need to keep an eye on. Now this was a quote
actually from SharkFest that I thought I would just mention here. "You can hide processes or logs, but you can't hide packets." So an attacker, if they
gain access to a system, they can go and wipe the processes, they can clean logs, they
can cover their tracks, and that's gonna be one of their goals. They want to try to make it look like, "Hey, they were never there." The nice thing about doing
this at the packet level, which IDS/IPS systems are
gonna fundamentally use to find this stuff, packets, while they can be manipulated or there's things that we can do to falsify that data, that's true. However, ultimately that
attack has to gain access some kind of way, and it's
gonna happen over packets. So that's why, again, the Wireshark tool set and
the tools that it compliments are such an important skill
set for everybody to learn. Now I mentioned, okay,
Wireshark has friends. There's lots of ways to do this. Here's just a few of them, everybody. There's a lot of tools
that can compliment. I'm gonna show you Brim,
that's a third one over, today. I'm also gonna show you
a little bit of Tshark. You've seen on my channel a
little bit about Ettercap. I'm gonna be continuing talking
about these different tools. But one thing I don't want
everybody to think is, "I've gotta be an expert on
every single one of these tools in order to be a threat hunter," 'cause that's just not true. Today what we're gonna
do is learn how malware, there's a particular malware infection we're gonna take a look at, we're gonna see how it looks in Wireshark. Look at some of the IOCs. Then we're gonna pivot
over to one of these tools and see how it can compliment
what that tool finds as well. - Chris, what's IOCs? - I'm sorry, thank you. Thanks for asking that question. IOCs, Indicator of Compromise. So that means that I see
something in the traffic that indicates that
we've been compromised. There's either been a breach or where you have some malware
or some unexpected traffic. It's the weird stuff,
something that looks weird. Thank you for asking that question. Again, why should we care? Just one last little
statistic for everybody, not to scare you. Are people lurking or are
attackers in my network? Well, let's take a look at
this study from April 2022, just a few months ago.
This is from Mandiant. They published a report
called M-Trends 2022 and check this out, what they found. They did a study of the breaches that they were aware of from 2021. So for all of those breaches
that happened in that year, that they were able to study. It said in 2021, the median dwell time, so from the time that an attacker gets in until they are discovered, is now 21 days. - It's crazy. - Feelings? How do we like that? They're in, they're dwelling. They're living off the
land, they're pivoting. They're discovering, they're going through different steps of the
MITRE ATT&CK framework, which is basically a definition of a life cycle of an attack. And 21 days is a long time. How would you like someone camping out in your house for 21 days, David? - (chuckling) It's not
good. It's not good. - That's a lot of time. So this is why we need
to be threat hunters. This is why we need to attack
this and be proactive about it because our job, not just as
threat hunters, SOC analysts, cybersecurity professionals, IT, anyone, hell the help desk, is to
reduce or eliminate dwell time. Get that 21 days down to
as little as possible. We find them before
they have that much time to discover our secrets, lock us out, put in some type of ransomware, whatever their objective is. We want to reduce that amount of time. So one way that this
happens is through malware. This is one method. So let's go ahead and talk about, let's go ahead and get to the packets, 'cause it's already been too
long since we've been talking and not been in packets, am I right? - Chris Greer, not doing packets within the first two
minutes is like scary. - I know, I know. No, just to tell everybody,
when I do my live courses, like I just did at
SharkFest or I do at DEFCON, I actually put up a slide
and that slide says, "If I don't have you in
a PCAP within 15 minutes, then I'm not doing my job"
and I gotta walk out the room. (David chuckling) - But you're pushing it in this video. We're very close. - Hands on. Well, I mean, this is how I learned this stuff, David. - [David] Exactly.
- I nerd out. Like I just have so much fun with it. It's not a chore. I really enjoy it. So I welcome anyone to reach out, ask questions, comment below, if you feel the same or if you have any other
questions about packet analysis. - You'll give us the PCAP, sorry, and we can put it below, yeah? - Oh, 100%. So we're
gonna be giving everybody this packet capture and it's
called malware analysis, like sec-malwareanalysis. That's my little naming convention. I'd like to show you
where this PCAP came from. So there is a site called
malware-traffic-analysis.net. So this is actually a
gentleman named Brad Duncan. And he's been using this site or populating this blog for
a very long amount of time. The reason why this is a great
place to go for sample PCAPs is 'cause he has so many
different examples of infections. Not all infections are the same. Not all malware acts the same. Here we can go, we can get a sample and he even can help step us through some of the indicators of compromise through these exercises. People can come here and
you can go "Click here" for these exercises. The one that I'm gonna demonstrate to you can actually be found down here. This is the "Traffic analysis
exercise - Catbomber" from May 28th, 2020. A little bit older, but it's
still something that we see. We still see some of these indicators, even in more modern infections, okay? So just wanna let everybody
know about that site and thanks to Brad for
always letting us use this. One of the reasons why I like
to use those samples as well is because these infections are let loose in a demo environment and he has some really
well placed captures to collect the behavior of the malware. It's quite a bit harder when
we're on a real environment and we have gigs and gigs and
gigs of competing traffic, a lot of which could be normal also in conjunction with
our malware traffic. So let's go ahead and back up, learn how to drive in the parking lot. And then we'll go out into the highway and learn how to find this
in a real environment. - Yep, that's great. - So first of all, so let
me just do at a high level. I see a bunch of packets, hey,
I get dizzy too, all right? Where do my eyes go? Well, I'm down here at
the bottom of the screen and I'm down here, I've
got 13,000 packets. Okay, so kind of muscle memory, some of the things that I do just to show people some of my workflow, I just go top to bottom
just to take a walk through. I know some of my coloring
rules have been triggered. You see like this bright orange here. I got this one, this "Client Hello." Of course my handshakes. I like my green handshakes everybody, gotta have green handshakes. Those connections, those new connections, jump out to me. Maybe another thing that I'm gonna try, I'm gonna go to "Statistics"
-> "Conversations." Everybody that's seen our
content together, David, should know to come here. And here we can take a high level look at the different
conversations that are had within this PCAP. All right, so what do my eyes do? Well, first this is sorted by
source or destination address, whichever was the case here. It sorts this first column by address. So I see here, I can see,
I have 28.8 and 28.229, to abbreviate those IPs. So they're involved, then I
have all these other ones. Well, if I come over here to "IPv4," I'm gonna sort this
"Relative Start" column. The reason is this gives me
a pattern of conversation. The first conversation we
see in the PCAP is here. The final conversation
was down here, all right? So then I can get an idea, "Okay, .229 is talking to this 5.1 device and then, oh, it's also talking to 28.8." So I know that these
guys have a relationship. Okay, so moving forward, all right. Also TCP, I'm just gonna come here to "Relative Start" as well. What's my eye doing? I'm just gazing down "Port B" right here. 443, 80, 445, hmm, 135, Windowsy stuff, 389 LDAP. Hmm, 447; that's an interesting port. Might wanna check that out. Come down here, 8082, okay. Could be webish stuff. We'll see, we'll find out. All right, so I got some secure web. I got some open web. I got some other Windowsy
kind of things, all right? That's all stored now.
Cool, let's come back out. Okay, so now we're at the entry point. So one other thing that I
do before I go much farther, and this is something
else we've demonstrated here in your channel, David, if I come up to
"Statistics" -> "Endpoints", and if I go to "IPv4," this is where I can just take a glance at the GeoIP information, right? So I'm talking to Germany,
talking to Indonesia, United States, Ashburn, Cambodia. - So that could be an indication
that there's a problem, 'cause you might not want to talk to those kind of countries, is that right? - Yeah, it depends on my customers, right? Where they coming in from, how are my applications architected? Do I have a CDN that should be taking care
of Cambodian and Indonesia? If that's true, why they
coming in straight to me? And what conversations
are we having, right? Same thing with US and Europe. It's not that any one country we pick on or that any one country by
itself would be an indicator. It's just that, "Is that normal for me?" And, "Is this something that I usually see any given Monday kind of thing?" Just taking a peek at
that, let me close. Okay. - So you're just trying
to get a big picture of what's going on, is that right? - 100%. Trying to get a lay of the land. I don't open up a PCAP and go straight to the TCP window size. I have no basis to yet, right? And you know, that's just too
deep in the weeds, too fast. We're already in the weeds. So let's make this a little
bit easier on ourselves. - Is it like trying to get
like a 10,000 foot view of like what's going on and now you can jump into the details? - Absolutely. That's what I'm here to do. So, okay, I've got my
bit of a lay of the land. Now, there's a few different things that I like to look for that
we call them low hanging fruit. Not all malware is advanced
malware that's all encrypted over the QUIC protocol and
is just absolutely impossible to make sense of on the wire. Yeah, there's some pretty sophisticated, advanced attacks, totally. But there's also some low hanging fruit that we can watch for, okay? So one of those that I like to look for, just go straight to web, HTTP. All right, let's just see, do we have possibly a malware author, whoever put this together
and architected it, maybe they got a little lazy and they didn't want to go
through the whole TLS process for every single web call. Maybe we could find some indicators there. So if you're following along with me, you just go up, "http"
in the display filter. We come down here, we've
got 26 hits for that filter. Now we can start to look
through a few of these. So let's go ahead and
go to this first GET. - You're looking for HTTP because most traffic today
should be encrypted, right? - Yeah, so I noticed in
the conversation list that we had some port 80, so that means it's standard web, right? So I'm gonna take a look at that first, low hanging fruit kind of
stuff, just what's using that. And another reason why I'm
looking at that these days is because so much of my normal traffic, like you and I talking now, you and I going to davidbombal.com, going to packetpioneer.com,
going to wireshark.org. If we're hitting sites out there, most of that today is encrypted, right? So we just shouldn't
have a whole lot of HTTP, standard port 80 left
going out to the internet. There's some, but there's
not gonna be a whole lot because so much of our web
activity is encrypted right now. So that's why this is low hanging fruit. And again, there's nothing
wrong with this GET and this response yet. It's just that this
was a quick way to say, "Okay, what are my GETs
and response strings?" I noticed that I've got
a couple files here. GET /images/imgpaper.png, GET /images/cursor.png. I'm gonna come back to
those in just a minute. Before I do though, literally,
let's go to that first GET. We're gonna right click, we're gonna go to
"Follow" -> "TCP Stream." Now usually I don't first go to "Follow." I'm gonna go to "Conversation
Filter" -> "TCP." But in this case, I wanna see what is
within that GET string. So I'm gonna go "Follow" -> "TCP Stream." And let's take a closer look. First of all, right away, this doesn't look very healthy
to me for a few reasons. First of all is my user region. I shouldn't say not healthy, I should just say my little radar in the back of my mind, David
is just going, do, do, do do. There's just a little yellow
alert going on right now. I'm sending a GET and I'm using basically a kernel level user agent. It's just doing a direct curl call. It's almost like doing
it from the command line. That's something that's
kind of interesting. If this is coming off of someone who, let's just say that their machine, that this is the IP that they're using. What is this, 28.229? I might wanna look up,
"Okay, who is that user?" And if it's just Dave the
secretary in the front, you know he's sitting in
the front of the office, so Dave's machine is
the one generating this. That's where I'll come back here and I'll go, "So why is Dave running like
a kernel level curl call? What, what are they doing?" This could be some API that
they're running possibly. However, that's just gonna
cause my little radar to go up. Next, how about this? I go out to the server,
returns back at 200 OK. But the server's name is "Cowboy." (David laughing) - That looks legit. - Might, yeah. Okay, right, because -- - But curl, yeah? So just for
everyone who doesn't know, curl is like a command line URL tool. It's not something that normal
users would ever use, right? - Yeah, or the actual API will, a lot of the browsers are, like the APIs, are actually going to use curl, but so into the kernel that we just don't see
this user agent, right? So curl's a very, very, very common thing. However, usually your user
agent is gonna be much longer. It's gonna say, okay, Mozilla 5.0, and it's gonna say -- My user agent is me
basically introducing myself to the server and establishing
some of the parameters of the engagement. So you can send me these languages. I accept this kind of coding. And "Hey, here I am." So in fact, we've all seen
some of the statistics that different websites track. This amount of traffic is
coming from mobile devices, or iPads, or Windows 10, Windows 11. Well, the way they figure
that out is by the user agent, it's the client introducing
themself to the server. So, okay. We're doing like
a kernel level introduction, no frills, no gimmicks, nothing. This is usually pretty unusual to see in normal, healthy traffic. Not to say it never happens, but it just is going to raise my eyebrow. Next, "Cowboy" comes back with a 200 OK. Date, also all they return
back is an IP address; that's the content, all right? So that looks kind of interesting. That's just gonna be a note to self. So I'm actually gonna take
and just take this address. I'm just gonna do a little
quick little copy on it, and now I'm gonna say "Close." Now with this infection, we basically reach out to a server, we knock on its door and it
returns back an IP address. And we can see that
address again here down in our hexadecimal view. All right, so I'm gonna take that and you know what I'm gonna
do? I'm just gonna first see, "Do we ever actually go
talk to that address?" "Ip.addr," 'cause I'm like, "What if it's sending me an instruction to then go talk to
another machine, right?" Like, "Hey buddy, go talk
to my buddy over here." Okay, so I never actually
see that address being used. That means that I don't
go and knock on the door of yet another server out there. But I'm still not in the clear. So let me just back up again. I'm gonna go clear out my filter. I'm gonna go ahead and go
back up here, "http" again. So now let's take a
look at this next POST. Now it's interesting here. I have this station. First of all, it reached
out to this device up here. Then this next one was a POST. So now with HTTP, I
can either GET traffic, "Hey David, give me this." Or I can say, "Hey David, here is data." It can go in either direction. And the method of HTTP
call that I use GET, POST, there's a few other ones, HEAD, INFO. I can come here and I say, "Okay, I'm POSTing, sending
data out to this machine." I'm just gonna peek over here. Let's take a look at the IP address. Gonna go down to GeoIP. Ooh,
now we're talking to Indonesia. We're sending data to Indonesia. Now that could be again, I
gotta think of my context. Do I have a legit system running that should be talking to another country? That's something that
we'd have to look at. Gonna come to "Follow" -> "TCP Stream." Okay, so here, let's take
a look at this again. Now you notice our user agent's a little longer this time. This is actually a more
normal looking user agent and I can actually take
this user agent, copy it, and there's a few sites
out there on the internet that I can search for, just to see what type of system this is. Mozilla 4.0, it's gonna
be a little bit older. The host, usually when
I'm talking to a server, in many cases, I'm using a hostname, wireshark.org, davidbombal.com, whatever. This time I'm using an IP, right? So I'm not doing a domain lookup. I'm just going straight to an IP. But let's see the data that I am sending to here again, "Cowboy." Hmm, now I'm posting to "Cowboy." Let's check out our content disposition. So let me just read these fields to you and see if this sounds comfortable, David. What would you think if I
started sending data out that was "formdata",
"billinfo" and "cardinfo?" Anything suspect there? - Yeah, straight away. I mean, who's just gonna send that kind of information
to some random server in perhaps a foreign country? - Very good. So would you say that this, even if we aren't yet malware experts or we're not hackers and all the above, even if we're not at a certain comfort level
yet with cybersecurity, should this kind of thing
raise our little antenna? - Oh yeah, yeah. - Yeah for sure. Now there's a very cool little thing, a feature in Wireshark. This was just one POST, but if you remember from
before I saw several POSTs. There's a cool feature in Wireshark called "Stream" down here,
it's easy to overlook. You see here in the lower right? Right now I'm on "Stream 8." So a "Stream" is basically just a single TCP conversation. And here, what I'm doing in this view is I'm extracting any clear
text out of that conversation and presenting it in ASCII. All right, I could also
change that if I want to, if there's any other language, however, let's just keep with ASCII. I'm gonna come down here to "Stream" and I'm going to go to the next one. So I don't have to close, reset a filter, come back to "Follow" -> "TCP Stream." I can just jump to the next
one using the "Stream" number. So Wireshark kicks me to the next one. Let's take a look at this,
still talking to Indonesia. Hmm, now I'm exporting,
exfiltrating, I'll use that word, mail.catbomber.net, port 995. Here's a username. Oh,
and here's a password. Suspect or no? - No, it looks dodgy. I mean, why would the
password be clear text? And it's, I mean, a name like "catbomber" is like straightaway doesn't look good. - Yeah, I'd agree in
this case or, oh yeah. And we're identifying
Outlook passwords, wonderful. - Yeah, Outlook passwords,
that's sounds a bit dodgy, yep? It's trying to email
passwords or something, right? - I am exfiltrating over web a username and password of email. - Oh, I see. Yeah, so that's
really dodgy. Yep, yep. - Yeah. So I'm telling, "Hey, here's my username
password over email." - So basically the
"Cowboy" server, whatever, has now just learned an
email address and password. - Absolutely, yep. And we're not done yet. How about open VPN passwords and configs? - [David] (chuckling) Yeah. - In this packet, we
don't see any of that, but again, it's trying. It's trying to kick this stuff out. How about this open SSH private keys? - Yeah, I'm glad that
you highlighted that. So in other words, it's a
whole bunch of HTTP POSTs. In other words, it's
basically sending data to a server on the internet and it's sending email
information, VPN information. And what I'm seeing now is like a whole bunch of process information. - Yes, and while you were talking, I just fast forwarded just a little bit. There are some encrypted
conversations, 100%. But if we come back to "Stream 21," everyone go ahead and
drop "Stream 21" in here. Or you can filter for that in Wireshark, come back to "Follow" -> "TCP Stream." And this is where we can see
our user agent "Winhttp 1/0." Again, it's just not a common one that I'm typically gonna see for most web traffic that's
being done over browsers. Also the host that I'm talking to, talking to this 203 box, we can go and check out who that is. See, my IP is changed. I was talking to Indonesia
now I've switched here. Now I'm POSTing somewhere else. This time, I'm sending a process list of the system that I'm
actually on right now. So how about this? What would you think if I had a user that was sending to some
unknown server out there, all of their system processes, their internal system
information, including their name, their DNS suffix, their
ethernet adapter information? Here's our IP. Here's our default
gateway, DHCP server, DNS. Come down here, "net config," even the type of software that this is. We see it's an older operating system. This is why we shouldn't leave this kind of stuff lurking
around, side point. "Net view." I mean, look at all of this
that's being sent out, right? Local machine data, username. - There's no ways that's legit. Why on earth would you send
internal information like that to some random server? - Exactly. And why would this, and let's think about this
from a practical standpoint, if we're blue teamers, well, how come this would still happen? Well, are we looking for it? This is web, it's being
initiated from the inside. So what protections do we have in place for our outgoing web traffic? Most firewalls are gonna
let it blast right through. So are we inspecting this? Okay, all that we get
back from that server, by the way, here's some
usernames, you know, no big deal. - I was just gonna say,
"Username: Administrator," "Username: Guest," all that
information's being sent. Sorry, and you were gonna
say something, sorry? - You took it right outta my mouth. "Is that something I should expect?" - No, for sure not. - Yeah, and also too, "Catbomber-DC." So my domain controller. I'm gonna talk about
that in just a minute. So first, this is just a station that's just doing all this stuff. If I come down here, check out here again, here's our server, "Cowboy." So we can see that we
have a distributed system that's accepting this data. It's not just one isolated
actor working alone on one machine. Or they could be working alone
and have several machines that are set up to receive this traffic. However, it's not always
going to just a single IP, a single server. That server named "Cowboy"
though is the thread that's tying this together. So what have we learned? Let me back up. I'm just gonna say "Close." While I'm here, I'm also gonna peak at, if I say "Destination." Let me just take a quick little peak at the GeoIP information. And there we go, Cambodia. So I've talked to Germany,
I've talked to Cambodia, I've talked to Indonesia, a few other places around
the world, which is, again, that could be normal traffic. However, this doesn't look very normal, the conversations that I'm having out. Also remember, you saw
this catch my eye before, this 8082 port number. - [David] Yeah, yeah. - And again, it's just not 443, 80, the standard ports that I'm seeing run by. It's just enough different
that it caught my attention. So maybe what I'll do, let me do this. Let me see, do I see
any other 8082 traffic? I'm going to just go "tcp.port==8082." So I definitely see it
here, but if I scroll down, uh oh, remember our domain controller? So we had "Catbomber-DC?" If I come down here I
have two conversations. One is coming from 229,
but I also have 28.8. Let me see what's up down here. Let me do, there we go,
"Follow" -> "TCP Stream." I went blind for a minute and
sure enough, check this out. So this is a POST from "Catbomber-DC." And if I come down here, that same process list, system info. Oh great, our domain
controller's been infected too. It's exfilling that same stuff out to that site out there, to "Cowboy." This malware has compromised
more than one station. I got 229. I got .8. I'm seeing those indicators
come from both places. Okay, how we doing? Just checking in. - Yeah, I was just thinking of a question, which we can come back
to later if necessary, "Is how do you find the
needle in the haystack?" And I think what you did, which is great, and you can fill in more detail, Chris, is that you went high
level, like 10,000 foot, and then you noticed HTTP and you just started looking at HTTP amongst all the other traffic. And that's kind of like
how you spotted this stuff. How do you it in like the real world where you've got gigs and gigs of data. That's always the question, isn't it? - Well actually I'm gonna
show you some of the things that I can do on the
terminal, on the command line. And that greatly improves the speed that we can do this with. And it also has some
other interesting features that make this a little faster for us. - [David] Right. - You asked another
interesting question though I want to talk about. So how do you know what to look for? And basically, I mean, since I haven't yet had
an attacker come up to me and just send me an email of the details of all of his attacks,
right? (both chuckling) If I'm playing another
team in the Super Bowl, he's not gonna send me his playlist and his offensive plan, you know, so I can defend against it. It's what we do is we start
looking, we're threat hunters. When we set out as threat hunters, we're first of all, we're proactive. We don't wait for an alert. We also don't always know
what we're looking for because we don't have an alert. So some of these skills
you can learn at home. Start capturing on your machine and look at the HTTP calls
that your system sends. There's several different things
that might jump out to you and say, "Hey, you know, that
just looks strange," okay? And the more you see your
normal baseline traffic, the faster and better you're gonna be able to
identify the abnormal. But that's why I say one of the reasons why I like teaching this way, especially with HTTP,
is because it is open. It is clear text. We didn't
have to decrypt anything. We didn't have to have
a special one-off case where we're able to capture
the keys from a TLS proxy or from locally on this client. We're able to see this
going across the wire. So that way we can learn how this works, so that if something becomes encrypted, we still have some
indicators we can look for. I'm about to pivot to that. - [David] Great. - Because in here, let me just remove this and
jump back through to the top. So when I jump back up to the top, here I can see that I
actually come out the gate with an encrypted conversation. My packet number one is 443, all right? So it's coming from 28.229. Now this is a packet number one. So this could be that
a client was phished. They were sent an email, a link, something that they executed. This is the kind of thing
that can go on under the hood once that link is clicked or whatever script comes
down from that initial server and then it starts to
actually do its badness. So that's another reason why I like these PCAPs from
malware-traffic-analysis is it starts very clean. So here's our SYN, SYN-ACK, ACK. We do our three-way handshake. The first thing I'm gonna look for, again, muscle memory, click
here. Let's go to GeoIP. I'm talking to Germany. Okay, just taking a look through. What have we got, our country code, our Autonomous System numbers. We're going out knocking
on that door, comes back. Okay, handshake finishes, and then I have this "Client Hello." Now I'm going to just take a look. I'm gonna show you when we
go "Follow" -> "TCP Stream" on this, it's encrypted, right? We don't have a whole lot to go on here from a clear text perspective. This doesn't mean that we're
completely in trouble though, because there's something super cool called the JA3 Client Fingerprint. Everybody click packet four, 'cause I know you're
following along, right? Why stand by and watch people have fun when you can dig into the
packets too? So, alright. The "Client Hello" is the first
packet of a TLS handshake. It happens after the TCP connection. The client now is reaching out and basically establishing the parameters of an encrypted conversation. So there's some interesting
things that are here that could raise our eyebrow, right? First, it's actually normal-ish
to see version TLS 1.0 here in the initial part of the handshake, but it's not really common
to see it down here. So TLS 1.0, first of all,
we're on TLS 1.3 now. An overwhelming amount
of traffic out there is now TLS 1.2 or 1.3. If I'm running old TLS, So either SSL 3.0, TLS 1.0 or 1.1, those could be just an indicator that this is either super
old, it needs to be patched, or I'm dealing with a
lazy malware situation, where they didn't go to
this extent of TLS 1.3 to fully do perfect forward secrecy and do all the modern stuff that we do. It was just good enough to keep this out of the
view of most IDSs, okay? So old, interesting. Now that actually forms
this version field, begins to form the basis of
something that we call JA3. JA3 is a fingerprint
of this "Client Hello." So what else does it look for? Version, cipher suites. So cipher suites, this is the different
encryption algorithms that I want to use
within this conversation. So I offer the ones that I know
or I can use, to my server. The server comes back and
picks the one they want to use. And then we can complete that handshake. But these are all the ones
that the client has capable. Just right off the bat,
RSA catches my attention. That's kind of an old, dead standard now, shouldn't see it in the
modern world anymore. Unless it's with an older system, we've kind of moved on from RSA. But that's also gonna form a fingerprint. Okay, so those 12 suites, version TLS 1.0. Also if I take a look at
some supported groups, a few other little indicators, and I come up with this
full string number. Now here's the gory details,
I'll do it very quickly. 769 is actually the decimal equivalent of the hexadecimal value up here. So 0301, if you flip it
to decimal, it's 769. For all these cipher suites, I just take all of these values over here and flip 'em to decimals. And I get all this long stringing numbers. The great thing about JA3 is you don't have to
memorize all those numbers. It basically goes through a hash and then the hash value
that's outputted is here. This is the JA3 hash, the JA3 signature, for this "Client Hello." What does that do? - That's in every hello or
every message, is that right? - This is a feature,
that's a great question, this is a feature of Wireshark;
Wireshark's doing this. And JA3, it's not unique to Wireshark. There's other tools
that are able to do it. But basically it pulls out these values and we're able to get a hash value that we can then look up
against a known database. So this is what we're gonna do. Right click, I'm gonna
go to "Copy" -> "Value." Now there's a site that I like
to tinker with, ja3er.com. Let's have everybody go there. All right, so if you
drop it into ja3er.com, I went ahead and copied that hash, if you come back here to search JA3 hash, this is where we can paste this in, search for JA3 hash. And this looks up against a known list of hash values for "Client Hello's." So there's tons of them out there, right? Because there's all
kinds of different ways that we approach servers. It depends on our browser,
our browser version, our operating system, the type of software that's actually generating
the TLS connection. And what this is telling
us is that this signature looks like a trickbot infection. So malspam-infection-traffic,
hmm. Malware test. So this site has already seen this before. It's already been registered as a malware trickbot infection, which is, it's something that it's seen before. So that's where I can come back here, and even in an encrypted conversation, I can still use the destination IP. So where are we talking to? And I can also take a look
at the "Client Hello," and get that JA3 string to get a vibe, "Is this possibly malware?" And that's just another
indicator I can use to do some threat hunting. - That's great 'cause you
didn't have to decrypt anything. Just by taking that signature
you were able to discover that it's malware. - Absolutely, yeah. Now we could make the case, "Well, all an attacker has to do is just use a normal
looking 'Client Hello.'" That happens, but we're talking
about low hanging fruit. We're talking about,
we gotta do something. We gotta keep scanning. Not all malware is going to be perfectly, perfectly hidden in encrypted conversations
with just perfect user agents and perfect "Client Hello's" that will just whizz by the IDS/IPS. Absolutely. Those exist, 100%. But there's things like this that we can do while we're threat hunting that should raise our antenna. - And I mean, I like the
example that you shared offline where you were doing
this in the real world. And I mean, you've shared
a little bit about it in this video, but you you've been doing
this in the real world where you're looking at slow traffic and then suddenly you
encounter stuff like this. So it's not like this is theoretical. This is real world stuff
that you're encountering. - Yes, in fact, just a teaser to a previous video that you and I did together on Nmap scans and what those look like. Well, if I come up here to the SYN, if I come down here to the
TCP Hello, the window size? If I take and pop this guy upstairs, boop. If I say take that
window size value, 8192, if I come to 1024, how
do I know it's 1024? Go watch the video. But Nmap likes to use that as an initial TCP window size value. So what I did, I just hit "Save." And now I've got it over
here as a signature. And what I'll do from time to time, if I'm just looking at normal traffic, I'll look at this window size value. I literally David, was just
working with a customer that I just happened to
throw this on the PCAP. And we found internal scans
happening behind the IDS, right? So a device that should not
have been running an Nmap scan was scanning the network. It wasn't like a blast of data, but it was just real slow, checking different ports coming over here, checking over there. So I told them, "You need to go find
out what this device is and why it's scanning your network. And if that's something
that should be happening." So the case could be made that,
"Okay, I stumbled on this." But if you think there are other ways that I could do a more persistent
scan against network data, I can take a huge block of network data and just look through it for
all window sizes of 1024. So I'm gonna show you how
to do that in just a moment. So as you can see, there's a lot that we
could cover in this PCAP. In fact, I'm sure that
there's a whole lot more that the viewers will be able
to find, a ton of detail. I think every time I
look at this trace file, I find something new. But before we finish, I
wanna make sure to show you one last thing about this PCAP. So let's have everybody to do this. Let's go ahead and
investigate those two files that the client retrieved
from the HTTP server. You remember those PNG files?
Let's take a look at 'em. We're gonna go up to "File." We're gonna come down to
"Export Objects" -> "HTTP." Now I just want to caution everybody, remember you're playing with live malware. There are malicious files in here that if we locally execute
them, we can become infected. So what I wanna make sure
everybody does not do, do not under any circumstances, come down here and say, "Save all" and extract these png files
and locally execute them. Leave them alone. You're fine looking at them
here in the packet format, but we wanna make sure we don't extract them
and execute them, okay? But let's just take a look at those names, imgpaper.png, cursor.png, okay? So let's go ahead and say "Close." When I clicked on one of those files, it jumped me there in the packets. So I'm gonna take a look at one of those. I'm just gonna right click this and just do first "Conversation Filter." And I just want to go "TCP." Now, if I take a look up on top here, so here the client is reaching out and it's saying, "Hey, SYN, SYN-ACK, ACK," there's my handshake. It's getting cursor.png. That was one of the
files it was requesting. Let's just see where this
IP address is located while we're here. Okay, this is actually in
the US at Nodes Direct. Okay, interesting. Now,
if I come down here, I'm getting cursor.png
as the name of the file. But if we take a look at the response, check out this first packet of response. And we can come over here. In fact, let's go ahead
and just right click, "Follow" -> "TCP Stream." Okay, so here we are on the stream data. Now here, we can see we do that request. And again, we're doing it to
a host IP, not to a host name. But down here when we request it, here we can see MZ is the
initial part of that file header. Now MZ, those are the initials
of one of the gentlemen that had a hand in creating DOS basically. So MZ is at the start of every executable or binary file that we see in that actual header information. Over here, we can actually see as well, this program cannot be run in DOS mode. So that tells us that this
is not actually a png file, 'cause that would be an image. We're actually retrieving
an executable file that's being hidden behind
that cursor.png filename. So another indicator here of this malware and what it's trying to do and that it's up to no good, if we're downloading hidden executables. Okay, so Brim is one, if
you're a threat hunter, you should have in your toolbox. And what it does is it
basically takes PCAP data, like we just saw, and it
generates Zeek logs off of it. And then it allows us
to search those logs. So all I did was I
opened up this same PCAP that we've been working with and I popped it open in Brim. Open source, go download it, it's got a bunch of
different operating systems it can work on. So go ahead and pick your flavor. And what I'm gonna do is I'm
just gonna come over here and just for this PCAP -- - It's free software, right? Yeah? - [Chris] Yep. Open source,
totally open source. So I'm gonna come over here and I'm just gonna zoom,
zoom, zoom, zoom, zoom into this little bar
over there on the side and it's coming in. So basically what this shows
me is over time for this PCAP, what conversations were
held, where, and with whom. Now something that I like about Brim is I can come down here and
just say, "Whoa, alert." Hmm, that doesn't look right. So why don't I just take
alert if I want, right? - Picked it up straight
away, yeah? Yeah, go on. - I mean anybody's eyes
could catch that I hope. Let me right click it and
say "Filter as value." Let's take a look at some of
the alerts that it figured out. Check out 8082, check
out some of those ports. In fact, if I back up, let
me just come over here. So my alert, "MALWARE
Trickbot Checkin Response." That took five seconds from a PCAP. - And you can filter
for alerts, can't you? Just like any alerts
and then it'll show you what it thinks is badgered, right? - Oh yeah, absolutely. We can either filter for that value, or another thing I can do is
come over here to the side and I can say, okay, coming down here, I can even use Suricata alerts, right? So, "Hey, you got potentially bad traffic, malware command and control,
network trojan was detected." I can take this and then I can pivot and go back into that actual alert. And then I can even pivot further and go back into the packets.
You see my little fin up here? So I'm not gonna go too far on Brim, but I can select that conversation. This gives me more of
my fire alarm level view if I have a very large data set. And it allows me to pick out these things that my eyes should go to. I approach this backwards from the way a lot of
people might approach it. They might go to Brim first
and do that high level. I wanted you to start on
the wire just so you can see the actual anatomy of attack and how this progresses, and
down to the packet level, showing the kind of
data that was sent out. So now I absolutely
compliment what Wireshark sees with a tool like this. - I think it's important
what you do, Chris, because if you understand
the low level stuff, it's gonna help you catch stuff that these tools might not catch. It's good to have an understanding and then use the automated tools. But if you just use automated
tools, you're kind of blind. - Yeah, absolutely. I mean, I could have a self-driving car and it could get me from A to B, but what if something happens? (chuckling) You know, I still need
to know how to drive. Or the other thing about
our IDS/IPS systems, they're watching only on certain links. Like take the example of the client I was talking to you about, where we found some scan traffic. They had an IDS/IPS, but
it wasn't picking it up because those packets never
crossed that connection that was being analyzed. The C2 traffic, the attacker, I think, was coming in over probably
an encrypted C2 conversation probably on port 443. So it just looked like any old web traffic and it was being let in. - Chris, you said that
you'd show us how to do this like in real world, like large data sets. Have you got an example of that or am I jumping the gun again? - Not at all. No, that's a
natural next question like, "Okay, this is an isolated
PCAP from a known infection, how do you actually find this stuff?" And let me go ahead and show you from the PCAP we already have. So, first of all, one way that
I like to do some scanning or just again, high level stuff, kind of like what you're seeing, we did it packet by packet
in the user interface. But an important tool I'd
like everybody to start to get used to is a command
line tool called Tshark. And that's Terminal Shark. If you have Wireshark installed, it wants to install
Terminal Shark as well. So if you just type in "tshark." So I'm actually starting to
capture traffic right now. So Tshark, let me make sure
you understand as well though, Tshark is a part of my path
variable here on my system. So if I just do print and I say path -- Okay, so I actually added "/Applications/Wireshark.app/Contents/MacOS"
to my
system. You can do the same. If you're on a Windows system, you can go ahead and go
to your path variable, which is in your environment variables, and you can add its
"Program Files/Wireshark." That's where all of those
command line tools are installed. And then you'll be able to
run those command line tools from anywhere in your system. And I'll go ahead and
demonstrate a little bit of this for you. So lemme go ahead and
just see, first of all, what I have here in this folder. I have my malwareanalysis.pcap. I also saw reverseshell,
in case we had time for it, might have to do that another time. But anyway so, what I can do is I can say, "Hey, Tshark, go ahead and read in my first malwareanalysis.pcap, read that. And then from here, I can decide, "Do I want to take a
look at conversations?" Just go ahead and pull
out all the conversations. "Do I wanna look at user agents?" "Do I want to filter on
specific signatures?" So let me do this,
we've already seen this. So I'm gonna use the "-t fields." Okay, this is where I tell T shark, I want to take the field that
I'm going to indicate for you and either print it
here on the command line or copy it to a text file. And the field that I'm gonna
be interested in is, "-e," that's how I indicate what
field I'm talking about. So I first say, go look at
a field. Look at this field. The field I'm gonna say
is "http.user_agent." So where I get that from,
'cause you might be thinking, "How do I remember that?" Well, remember when we
were back in the packets, you actually have a cheat sheet here. I'm gonna go to my GET,
I'm going to collapse TCP, open up HTTP, you see "User-Agent: curl?" Remember, we saw that first? - [David] Yeah. - Look down here to the
low left, http.user_agent. All I'm telling Tshark
is to take this field, pull it out and put it on my command line. Let's see what happens. So first, if I just hit this, it's actually gonna run
through the entire PCAP and you kind of saw a
couple of them blip by. But I don't want to
just have those blip by, I wanna actually isolate them. So what I can do is I can say "-y," which is a filter, http.user_agent, okay? So what that does is it says filter only for the packets that have a user agent. So what I did is I focused
now only on packets that actually have a user agent. Okay, so I can see I've got a few of 'em. I got this Mozilla 4.0, WinHTTP, curl. You notice that I have a
few copies, a few doubles? So what I can do here is I can just say, okay, let me up arrow again. Actually, you know, I'm gonna
go ahead and use "sort." And what that'll do is it'll sort it, but it'll also, if I say "unique," what that'll do is it'll only show me the unique user agents. So now I can take and run
this against a huge PCAP and it can pull out the user agents that are unique within that PCAP. And I'm gonna tell you, these ones start to jump out to you because all these other ones
just start to look like this, you start to see, okay. I can even run this against
a user agent checker just to see what type of
user agent it came from. But this is one way that I
can parse larger data sets. I could also do the same with DNS names. I can say, forget all of this packet, let me just export all of the DNS names that I'm scanning for, or
that are a part of that PCAP. Also another one that I could do, and this is this one's gonna
be real world everybody, so let's go ahead and modify this. In fact, you know what, let me just clear. All right, let's do a real world one that you could do right now
on your network back home or in your enterprise environment. Let's do "tshark," read. Okay. Let's read in the same
malware example, okay? And I'm gonna say, I only wanna see, I'm gonna say, so "-y", which is a filter, and I'm gonna say, "tcp.port==443." So I'm looking for secure web, and I'm going to say,
"-T," out fields again. And I'm gonna say, "-e,"
but this time I want the -- Let's go back into Wireshark.
Let's go ahead and remove. I'm gonna show you where
I actually get this from; it's not just coming
from the top of my head. I want the version, tls.handshake.version. Go ahead and pull that out, "tls.," and -- Did I spell that right,
"tls.handshake.version?" Okay, let's pull that out. I'm just gonna do a sort on
that. Let's do unique as well. All right. So in this
PCAP, there's only one. But this tells me if I come
back here, you see TLS 1., so 0301 means TLS 1.0. So I should be seeing 304 or 303. So thankfully they just
count up 301 is TLS 1.0, 302 is 1.1, 303, 3.2, or 1.2
and then 1.3, respectively. So if I ever see those, ooh! I don't wanna see some old
TLS "Client Hello" versions. So this is where I could start
to, if I had large data sets, if I had gig files, which
I could show you as well, maybe on another video
or if we have time now, how to capture and stream that to basically capture,
capture, capture, save; capture, capture, capture, save. And just have a whole
section of a hard drive full of capture data from that day. What I can do is I can take
this value, or this command, and then I can script it to run against all of
those different files and it can rip out all of
the low hanging fruit there. - Yeah. So Chris, can
you give us an example of like a large amount of data, because the problem with
a lot of the training, and that's what I love about
talking with you is, you know, people have these like
cookie cutter type PCAPs. Have you got an example with
like a crazy amount of data, like gigs of data that we
can just filter through? - Sure, 100%. Let me
go ahead and show you. So here on my screen, I
actually have some sample data. Now, of course, I can't
really ever use client data, to protect everybody. - [David] Yeah. - But this is a larger data set. If you take a look at, basically I call this ring buffer, and you can see over here the size, this is gig gig gig gig gig, basically. So we got 11 gigs of data
here or close, right? So I don't wanna pop open
one, go to the user interface, take a look at old versions of TLS and take a look at user agent strings and such things like that
on a file by file basis. Instead what I'd like to do
is be able to script that. So what I'm able to do, I actually created a script and I'll first show you how it works and then I'll show you how I made it. And again, this is all part
of the threat hunting course, so hopefully you guys will
check it out when we drop it. But basically I'm just
gonna do "./threathunt." And this is a script
that's gonna start running. Now, let me show you what this does. So first thing it does is it
first goes into each file. And the first thing it's going
to do is create a DNS folder. It's going to go into each
file and it's going to rip out just the DNS data from that folder. Now I could be more specific. If I wanted to look for a certain domain, if I'm just suspect of
a certain type of call, then I can be very specific
to that thing that I comb for. All right, so it's gonna rip all that out. And then it's going to
create a separate PCAP for everything it found
within each larger data set. After this, what it's gonna do
is merge everything together. And then it's just gonna
leave me with one PCAP that I call all DNS. And so now that part of
the script, what it does, is it pulls out all the
DNS, rips it out for me, and now I can just look
through that DNS traffic. If I wanted to be, again, if I wanna be more
specific, I could do that. Another aspect of the script is, we're gonna see this happen
since it's running live, let's give it just a minute to run. Okay, so this one just finished. So I got all DNS now,
so okay, that's done. And it went ahead and erased
all the other previous PCAPs. It did that with a tool called Mergecap. Next I go for strange ports. So I built a filter within
the script that it will say, "Okay, ignore port 443, port
80, some just normal ports, maybe port 8,000," even though things can
hide in those ports. However, I'm looking for the
one offs, the weird ones. So go ahead and pull out all the non-normal web traffic ports and just show me any of those. And so now it's going through
and ripping all of those out and making separate PCAPs for me. Okay, it's gonna do the same thing for strange country codes. It's gonna do the same thing
for old versions of TLS. And so the way this happens, I'm gonna go ahead and stop the script. All right, so if I come in here, I'm just gonna open
this with a text editor. All right, so this is just
one example, everybody. So basically what I'm
telling it, and again, I'm not huge on scripting. This is something that I modify and just depending on
the environment I'm in, this is where I say, "Okay, make a directory DNS,
go ahead and pull out DNS, go ahead and save that to
a new DNS file," right? So I say, okay, "for f in rings." So ring is where that actual location is. For all the files in that folder, do "tshark," throw this filter at it, go ahead and write that to
another file with that name. And then you're done. Once you're done doing all of
those files in that folder, now I want you to go
and merge them together. Now let's Mergecap, write "alldns," and your source is gonna be
everything in that folder. After that, remove it. So I just did this for DNS,
strange ports, TLS versions, Nmap scans, remember I told you before? Show me everything with a SYN, that's one, an ACK that's zero and
a window size of 1024. If I start to see a bunch of hits here, I'm starting to see Nmap-like signatures. And also countries that I'm
not typically talking to. So using this kind of
script, David, this is where, let me go back to my ring buffer, so this is where I can take
a large, large data set, and I can create different filters or different types of signatures that I'm gonna be
interested in threat hunting and throw it at a much larger
data set, boil that down, and I can start to look more
specifically at those packets. I'm always gonna do that though, in conjunction with a tool like Brim. Also, I can run Suricata
logs against this, take a look at some of
the deeper Suricata logs and just be able to take a large data set and just look at it from
more of a fire alarm level. - Chris, I mean, this is fantastic, but we don't have enough time
to go through all of this. This is where you're gonna
add this to the course, is that right? - This is already built in.
It's already part of course. - Great. - [Chris] So, so what I do is -- - This is what you're teaching at DEFCON and other places, right? - Yes. I'm gonna be
teaching this at DEFCON. This also part of my Threat
Hunting with Wireshark course. Keep in mind that we built
this over several exercises. So, I mean, this is a lot
to take in right away. And again, you might be thinking, "Okay, what do I look for?" Well, in the course, we go and we look at
command and control traffic. We look at exfil traffic. We look at lateral movement indicators. In the course, what I do is
I take MITRE ATT&CK framework or the Cyber Kill Chain
by Lockheed Martin, and what those do is
they give us a picture of how an attack works
from start to finish. How does an attacker first get in? So in the course, once
we get to this point, we've already learned the
life cycle of an attack, and that's part of what
threat threat hunting is, we have to know our adversary. In order to be able to find an attacker, it's good to think like one. So we go through and we take a look at, "How does an attacker initially get in? What are some of the signatures of that?" Or, "How does it actually happen?" Then, "How do they move
laterally and find other systems? How do they discover a network?" Not just Nmap, but other tools. And, "What does that look
like on the packet level?" The reason why we do it is
because you now understand better of how that attack life
cycle actually happens. And you have a better understanding of how to find it on the wire. So using frameworks like MITRE
ATT&CK and Cyber Kill Chain, we at least get an understanding, "Okay, they first get in. Then they overcome a machine and then they try to move laterally. They try to get to the crown jewels, then get that important data out." So those are things that, again,
they can overwrite syslogs, they can wipe processes,
but they can't wipe packets. That's why Wireshark and these tools that we've talked about
today know as threat hunters, which isn't just the SOC team people. This is help desk. This
is network technicians. This is network engineers. Anybody that's interested in cybersecurity that wants to pivot over, you have access to those packets. So now it's just capturing them and then learning to find the
strange ones that pop out. - Chris, this is amazing. I'm really glad that you've
decided to teach this. And thanks for, you know,
teaching this at DEFCON, but also creating a course
that people can access, which I'll, again, link below. Really appreciate you
putting all this work in; I know it's been a journey for you. - Hey, I have fun. This is
great. I have a great time. But I wanna thank everybody
that is watching the video. And I just want to encourage you that, hey, I feel overwhelmed too. Sometimes I open up a PCAP and I initially might not
know what to look for. And I don't always get
to the exact right place just within a few clicks. Sometimes it takes some time. So be patient with yourself, stick to those fundamentals,
learn them well, and you will start to see
some strange looking traffic. find it and understand it with Wireshark. - Brilliant, Chris. Thanks so much. - You bet. (exciting music playing)
