All right, so let's continue with our threat hunting methodology and talk about unexpected apps on
a well known sports or a standard port.
So let's say we've determined that there is a connection persistency, right?
Connection connection per System C.
So we've got a host and it's beckoning regularly outbound.
And we've also determined from our business need analysis, need analysis.
That we don't have business justification for this behavior.
Now, one thing I do want to mention is if you don't know whether or not the destination device that
is the remote server is supposed to be in communication with this internal host.
One of the places you can go to get that verification is your local procurement department right in
your organization because procurement, what do they do?
Well, they're responsible for purchasing.
And for example, you saw we saw in entity.
It was a port, you know, and that belongs to elastic.
Let's say you don't know if your organization has elastic check with procurement and if procurement
says yes, we actually have a purchase order or elastic that occurred nine months ago and we still use
it now.
You know, there may be a business need for that traffic, so that's a quick way of checking for business
need.
Check.
Procurement.
Procure meant.
But now we're actually looking at this, which is in, I guess you can call it, an unknown app.
An unexpected app.
On a standard port standard port.
OK, now what am I talking about here?
An unknown or unexpected, unexpected and expected.
So let's say, you know, you're looking at your network connections and you're seeing you have a connection.
You see that the Chrome Remote Desktop Port is open on a server.
Now Chrome Remote Desktop?
Well, you know, we know that app is, but it's unexpected.
It's an unexpected app on a server, right?
Should it be there?
And so we see this app, you know, it's connecting outbound on the Chrome remote desktop port.
It's on a server.
It's unexpected that should increase our scoring or risk scoring by maybe 10 points.
Now let's take another approach.
Let's say you are looking at user agent strings.
A user agent string is the name of a network.
Aware application, for example, Chrome has a user agent string, Firefox has a user agent string,
they all have user age strings that kind of identify what the connecting application is and to some
degree, the operating system it's running on.
Well, let's say you jump into the ATP that log.
From Zeke.
And you see the user agent string for this particular host.
Let's look at a time period here.
The user agent string is pretty predictable most of the time.
But then at some point here for this connection, pair, you know, between this source and this destination.
The user agent string switched.
For a particular time period before flipping back.
To what it was originally.
Now that's really interesting.
How do we explain this?
We have the same computers over the same time period.
But the user agent string was changed for this particular interval before flipping back to what it was
before the switch.
This could be the malware on this box tipping its hand because the malware has to call out and it uses
a unique user agent string on that outbound connection.
Now it could mean that there's a virtual machine on this target, right?
And that virtual machine is just using a different user agent string for whatever machine is.
Is running on this this host box?
But it could mean something more nefarious than that.
So let's take a look at some of this inside of our logs.
All right.
Do we have any team sessions?
I don't tmux new will create a new session called threat.
Which directory and I am not the one I want.
So let's just exit this CD documents hunting, you know, create a new team accession goal threat.
And now I'm in the right directorate, which means every new pain is in that directory.
We'll say you analysis to do that, I just went to control a comma and I named this tab.
And that's how I was able to change it.
All right.
So we're in this user agent string analysis and do we have any files?
And here we do.
So we've got this conduct log.
Let's go ahead and cap the contact log, get contact log and we just want the user agent string.
So Zeke cut user agent.
Nothing.
That's because we're in the wrong look.
You're the agent doing should be in the HDP lobby, I believe.
Yes, there we go.
All right.
So what we can do if we cut out the user agents, we sort them.
So now they're in order.
And then, of course, we can do a unique to see only thing a user in the streets.
And then we can get a count of how many times those strings were observed inside of this data stream.
And of course, we can then sort it in reverse numerically.
And we see most of these network aware applications are the Microsoft Windows notification service.
We have the Microsoft Crypto API and then we have this right here, right?
So it's kind of hard to do this timeline analysis just in Zeek.
You know, you can you can do some of this in Rita, but you're probably going to need a tool like Splunk
or elastic.
If you're going to do true timeline analysis to determine if the user agent string has been flipping
between two targets or think about this scenario, let's say.
You have a Web browser.
And this Web browser should theoretically, when it makes a connection, it should go out or report
80 or four three three, right?
This is HGTV and this is HTTPS.
But what if instead of a Web browser?
You don't see a Web browser.
It's not a Web browser making that connection about.
It's another app.
We don't know what this app is.
But this application is making an outbound connection on Port 80 and four four three ports typically
used by browsers.
So if you see non browsers, connect it to four four three.
That's interesting.
Number two, you see non browsers, connect it to four four three and there is no less client hello.
Or, you know, the SSL handshake is missing.
That's another suspicious indicator, right?
So you might add ten points to that.
And let's say, you know, you see this outbound traffic going to port 443, but there's no corresponding
SSL dot lock.
That means Zeek, which understands over 50 apps, did not see a TLC compliant connection.
There was no TLC handshake that was typical that followed the rough seas.
So this is super weird and it should be investigated.
You might add another 10 points to that, right?
So let me just write that down.
Non browser two four four three.
Maybe you add five points for, you know, as a malicious indicator.
No client.
Hello.
Maybe we add another five points for that.
No, SSL that log.
Another five points.
So you see how we're methodically going through this to determine if something is normal or not.
Now, I just want to underscore something we're talking about unexpected or unknown apps on standard
ports.
Standard Port is four for three.
Unknown app is this thing right here?
Maybe it's no pad directly.
Maybe it's smart.
You tell that easy or PowerShell that you that's unexpected, right?
We're not talking about.
A known app on a non-standard port.
We're talking about an unknown app on a standard port.
What do I mean?
A known app when a non-standard port is kind of like running stage on which is a known app on Port two
two two two.
That's a non-standard port.
Now that might be normal, right?
Why?
Well, because maybe you want to cut down on the number of brute force attacks against SSA, so you
just change the standard port two to two to two.
You can still escalate into the box, but you need to use this non-standard port.
That's not abnormal.
What would be abnormal is if you have an unknown app.
Maybe it's putty and it's connecting outbound.
On four, four, three.
Right.
It's not a browser four, four, three.
There's no client.
Hello.
There's no SSL log.
That's that's suspicious.
That's something that we should look into.
OK.
So I hope that makes sense.
Another thing you can do is look at the G3 hash.
So G3 is really, really cool.
You should really this kind of merits a lecture all in itself.
But the jade rehash, what it is, is a fingerprint of the TLS handshake.
And so you can quickly identify rogue applications or non-compliant systems by stacking J3 hashes across
the environment.
And if you see a G3 hash that is an outlier on that graph, then that could indicate either there's
malware running or there's some non-standard application that is doing dirty work on that endpoint.
Now, I was going to show you the Google page on it, but you don't really I mean, you can Google J3.
The bottom line here and why it's really cool is even though destination types and, you know, X5 online
certificates and ports, those things can change.
The J3 fingerprint does not change.
It's static.
And so it's a great way to identify, you know, an application.
It's a name that follows that application, and it's hard to change because those applications use a
particular set of ciphers, TLR ciphers, and they're negotiated in a particular way.
And that is what the J3 hash can help you identify.
Right?
So guys, that's really all I want to get into in this lecture.
In the next one, we're going to talk about the next step and you read hunting methodology, which is
looking for unexpected protocol behavior.
Then we will look at the destination IP reputation check and we'll wrap up with an internal endpoint
investigation.
All right, guys, I will see you in the next lecture.
Thanks for sticking with me.
Thanks for doing this.
You guys are awesome.
I'm super proud of you, and let's keep marching forward.
So you guys in a little bit peace.