Just prior to this,
we started talking about host detection capabilities of the osquery
and Sigma and different rules in use for seams,
analyzing logs, and file activity, and now we're going to look at it
from another perspective on the network indicators.
And we got into it a little bit prior to this because we
almost had to because once we, first of all,
when we looked at what the service was doing, we saw that
there was an interesting port being used.
It was connecting out to the internet.
Yeah,
I think it' was 449 or 447, so I was kind of curious for
a TCP traffic out to the internet, right?
And then secondly, under the config, when we unencrypted the
config, we identified additional ports and IPs and things
that we should be looking for.
So we know that those are command and control servers that are looking out.
Yeah, yeah, those, you know,
each plugin has its own configuration file, and when you decode them,
at least we found about a dozen or so different IP addresses and ports that
would be connecting over. So we obviously could use those on a network to
look to see if anybody was connecting to those.
That would be a great indicator looking looking at those ports to see if
anybody's connecting to those ports for the unusual ones.
Obviously,
for something like 80 or 443 you're going have a ton of traffic to that,
but the rest of them would be a little bit unusual.
Yeah, absolutely.
And when we talk about doing detection, especially,
well,
really any type of detection, but talking about network detection, we can
block those things, that's cool, and we can put detection on very
specific domains, but then people are using DGAs,
right?
And so that's like cat and mouse game. And you can put detection on specific
IPs they're going out to, but those change as well. Right,
right..
And the configs can change.
I usually try to look for more kind of behavioral or maybe you call
metadata about the network traffic that is going to be more consistent
regardless of changing IP or a port or that kind of stuff. Right.
Especially now that know a lot of traffic is encrypted using SSL or TLS,
you can't just pure into the traffic.
You've got to look for other indicators related to the SSL certificates or
something like that in order to hopefully find some indicators.
Yeah, absolutely.
And if you could decrypt it, or even if you can't,
there's still signatures, so we can use Snort or we can use Suricata, and we
can alert on odd ports that we find, right? But first,
we have to find the ports, so I think there's usually a ton of
information to worry about with that. You gave me a pcap that was from
that last VM where we detonated everything after it started downloading
the main executable that was inside speedLan.
So the speedLan executable was communicating out and downloading those
modules, and so hopefully there's some of that data in there.
And you gave that to me to or did some analysis in Bro, or Zeek now, right?
Right.
Well, it's Zeek now, but if you install it,
you still have to install Bro, so. And all the commands are Bro.
There's like a guide on zeek.org to tell you how to make aliases
to call Zeek. And I'm like that's extra work.
I'm not going to do it.
Oh, yeah, just continue on with the way it is.
Yeah, right.
So you're not familiar with Bro, it's used heavily in a couple different
courses, Security Event Triage: Signature and Session Analysis,
as well as from the same path there's a network behavioral
analysis course that uses Bro and malloc and a lot of this
kind of session analysis stuff.