Everybody Welcome to Part Five of the routine assessments many module.
In this particular video we're going to be talking about constant assessments.
So what are our constant assessments.
They are assessments that are done daily or weekly that don't tend to fit into the monthly quarterly
or yearly schedule.
So automation plays a very key part in that.
So what.
Automation is the is the task of writing some sort of scripting code or programming language such as
Python to perform tasks that are mundane.
They're consistent tends to get it off your plate.
So performing automation here or building automation around these particular tasks tend to make things
go a little faster on your day to day basis.
So stuff like this normally contains like password cracking can be automated.
The vulnerability scanning can be done daily ticketing the feedback loop everything can be done automatically.
Building custom tools lets say you saw a particular Web service that had an issue in your environment
and they fixed it.
However has a tendency to pop back up again maybe using a custom tool to search for that on a consistent
basis is a good way to go.
So there is there's quite a few others depending on what your team is doing how how you are performing
things whether you even are supposed to be writing custom tooling.
Normally it's encouraged to write tooling yourself.
However some places have teams dedicated to tooling you put in the request you get the tool so it entirely
depends on the team.
But these are some common things that you're going to see.
So for parser cracking again automating this task is crucial.
It takes a lot of time it takes a lot of GPO usage depending on the type of cracking you're going in
again.
We have a module specifically dedicated to password cracking that we'll get into this a little bit more
detail.
However utilizing different types of techniques will take more time so.
And that's a big part of automating it so you never have to worry about going back changing things grabbing
new password hashes everything's already done automatically.
So you want to keep track of the passwords in this particular case.
So you're going want to keep track of passwords that people have used some new found and create something
called a master list.
So with this list YOLO you will be able to quickly grab all the hashes from your organization run them
do the master list and just see if common passwords are previously cracked after it had been found at
all.
So this essentially allows a user never to use the same password twice since they began working there.
Sometimes that's good sometimes it's bad but in most cases it only has a positive outcome depending
on the password length and complexity requirements that your I.T. organization has.
Again the feed back loop is important.
You need to make sure that when you're automation runs through you crack a password you notify the user
so they can change it you notify the manager to make sure that they're aware that they got caught in
some sort of cracking scheme.
So the good thing is it's not to get anybody into trouble but it's to make sure people are aware that
they're using crap passwords.
So the managers need to be aware that their employees depending on who it is might be at a more sensitive
employee where they have more access to things than they probably should.
So that also is the feedback loop is very large when it comes to this.
So it can get pretty complex pretty quickly.
So it's again we'll have a whole module dedicated to this.
But just keep kind of keep that in the back of your mind.
So vulnerability scanners This is scanners such as NASA's quality.
There's there's a large variety of them on this particular case we're just going to be looking at this
for my example which is a vulnerability scanner and network vulnerability scanner built by tenable.
So who handles scanners in a general sense.
It's normally the security engineering or the architecture team that kind of handles that.
Now the red team does not tend to run vulnerability scanners on a consistent basis.
However on smaller teams you may.
So keep that in mind it's always good to be familiar with them what they find automating it.
Again this is a very big thing when it comes to scanners.
They're complex they produce a lot of data and it's not something you want to shift through when you
have let's say one hundred two hundred thousand eyepiece on a network that can be gigs and gigs and
gigs of data in raw text that you're going to have to shift.
It's not something you want to do on your own.
So can these be used in Red Team engagements.
Yes.
And normally they are depending on what you're doing.
So if an engagement has a pretty open scope you're not really restricted by much.
You may want to throw a scanner at a particular host that you're looking at.
It can.
It has a tenable case NASA's probe which you can get a free license for educational purposes.
Can identify things that you wouldn't be able to identify quickly.
So knowing that something's out of date and it's vulnerable to this CTE or this exploit.
So in most cases it'll give you a link directly to it which has some sort of PMC or proof of concept
code that you can use in some cases there's even better split modules that are publicly available for
these which will we'll have a whole course I'm going to support but it's an exploitation framework made
to allow things to be a little bit easier.
So it's very crucial to run these and we'll have a little bit more talk in depth on vulnerability scanners
in future modules.
However just keep in mind that when you're looking at these they normally come into high low medium
and informational depending on the scanner.
However one thing I want to stress quickly is that never discount the informational especially during
the reconnaissance phase because you never know what little bit of information you're going to need
that could be the difference between you popping the machine and not custom tools so custom tools can
be a large variety of things.
It could be something as simple as is this port open.
Is this service running.
What port does a service run.
What how is it responding to this particular request.
So a customer who can be anything.
So who builds these.
Everybody builds a blue team red team security engineering architecture application security developers
everybody builds tools.
So most of the time you are going to build them during an engagement or when you've seen something.
So you want to let's say you saw a particular web service you found an issue with it.
You need to take a tool that scans an entire range on a network to find out what hosts are still running
that service so you can identify the full scope of what the issue is.
So building a tool like that would be a good start.
Who runs them again depends.
Some places have a corporate security team that will handle running consistent tools on a daily basis.
In some cases it's the red team.
Again you would want to automate this.
So running the automation of the tools giving it in a having a tool kick back a useful output that you
can then in turn create a ticket for.
So this is where the feedback loop comes into play and you'll notice I'm consistently bringing back
feedback loop.
It's very important.
It runs into almost every aspect of what you're going to do if there's not a feedback loop.
Something's wrong.
You want to make sure that there's always a way to have consistent improvements no matter what you're
doing.
So we've only got one more video left.
And then you guys you guys should be good again.
This is the going to be the last module that we're going to have a lot of text.
So bear with me here.
Starting a next module it'll all be hands on.
Ninety nine percent of it.