All right, so in the last lecture, we dug into known vulnerabilities, right, using components with
no bones.
Now I want to talk about detections.
Right.
How can you respond to something you can't see?
You can't write mean you need to have sufficient logging, not just in the local logs or whatever the
asset is that you're monitoring, but also there's something to be aggregated into a central location
so that you can correlate events and infer relationships between different events and then respond.
Right.
You can prioritize risk and you can respond appropriately.
And so this is actually the last part of the last top 10.
You know, insufficient logging and monitoring is the bedrock of nearly every major incident.
Right.
I mean, this is a big deal.
You know, if you can't detect an attacker probing your network, well, I mean, how can you expect
to not be compromised or even to respond to the compromise when it happens?
So, you know, it's really important that you make sure that lots of not only stored locally, but
also, like I said, sent to a SIM like Splunk.
And because we have our cyber range set up, we can do that.
Right.
We can run tests with a map.
We can scan our Web app with berp.
Right.
You can see here, I'm scanning it right now and and then we can see, you know, how the app responds.
So, for example, if I just fire up, here's our web, right?
Let's just fire up in that.
I should see if we can scan it with an aggressive scan and maybe we'll fire up, go bust or something
like that, too.
We're just looking to make sure that we can get that log data inside the app.
So Zero in map will do a very agreeable scan, will assume that the Web application is already active
and go ahead and minimize the app behind it.
Then we'll run an aggressive scan, we'll do a full report, scan zero two six five five three five
output will be, let's call it like Justyn that.
Me the reason why it's blocked and where we want to scan ten one hundred zero ninety one that is due
shop.
And we also want to do a version of numeration and run some people in my scripts against it so we can
say redefault default scripts tac lowercase s capital C and diversion enumeration as well.
So this should be really noisy.
We can press spacebar and update as the scan runs.
You can also open a new tab.
And run, go buster against it.
Looking at you like Sirocco buster, we'll just find a very noisy scan and you can see here I'm just
basically using a previous check that I've done.
So with the increased number of threats
to like 20 or something like that.
Hello, it's good to me.
Right, so we should be generating a lot of noise right now.
And if you look at my source IP, you can see on zero that 160 for one one six eight zero dot one sixty
four.
So we can flip over to Randy Moralez, get into Splunk.
Let's do a search over the last day for this.
See what happens.
We've got.
All right, so that finished and you can actually see we've got a lot of events that are being blocked
by our open since firewall, right?
It's being filtered.
So that's good.
Action was blocked, right?
This guy is definitely blocked in the direction, is inbound.
That's good.
Let's look at some of these other source types and Surakarta.
Let's look at the job source type.
So this is really interesting.
We can see that this is clearly an attack, right?
Because we have the same source, IP 119 116 zero 160 for.
Hitting the same target, but it's hitting different endpoints, for example, index asp up text, comment,
feedback podcast.
Right.
It's just doing force browsing.
And you can see these are strings are changing every time.
And the reason why that's happening, because we told to do that.
Right, controls IDUs tab.
You can see random agent is selected.
And we have our word list that we saw in Zwack.
So in this case, we actually don't have insufficient logging in monitoring.
We're not vulnerable here because of the way we set up our lab.
But, you know, a lot of times there are still gaps.
You know, a lot of times post requests aren't logged with the same verbosity as get requests.
And so an attacker might or switch the method from get to post in order to evade some logging and detections
and that sort of thing.
So it's always important to make sure that your logs are appropriate, that the appropriate levels are
in place, and that you have, you know, maximum visibility into all of the Internet's connected inputs.
Right.
So that's it for this.
We're going to wrap up this entire section.
Oos, penetration testing, and I hope it's been very helpful to you.
Now we're going to move on to the next piece, which I think you guys are absolutely going to.
All right.
I'll see you guys in the next lecture by.