Everybody welcome to the next video.
So in the last video we talked about goals and scoping ID.
Now what we also need to understand when we go ahead and scope this is we need to understand the stability
considerations that are going to be put in play for whatever you happen to be testing.
So why do we need to look at stability.
This is because we need to know if a service network or any other device in between is in a fragile
state.
So if a firewall is running too high or a switch is running too high or at capacity this can cause a
lot of problems and uplink port just as simple as running a port scan through an uplink that is running
a little too hot could bring down the entire network segment.
The last thing you want to do is bring down a production host or a network specifically if if there's
an issue already known and you make that issue worse.
Now the owners of these services networks or any type of hosts might already know what the stability
issues are.
And in most cases they will know what it is.
So it's a good idea to get in contact with these individuals that own the services or the hosts or networks
that you want to run your test against to identify what potential issues might be in play.
Now you're not going to able to get them all and be able to grab every issue known demand for that particular
host that network at that point in time.
But you can get a decent idea of the type of tests you want to run.
We'll have some sort of impact on the stability of the service or host.
Now you can also use some common networking knowledge and host knowledge to know if you start running
some stupid things and memory on a fragile like a Java service as an example is pretty fragile when
it comes to messing with its memory because they normally run pretty hot on memory in the first place.
So if you bulk up the memory too too much with a buffer overflow or maybe there's some other issue that
we didn't know about.
Maybe it's a zero day that you didn't actually understand what the issue was you were testing things
out you saw an opening and you decided to play around with it something like that on a Java service
that's memory hot can cause the entire service to drop.
Now that can be a very big issue if that service is running prod traffic at the moment.
So we also need to understand what stability is and where we're going to be looking at it now again
we should be looking out for sensitive services exploits with memory corruption specifically.
So anything with buffer overflow or stack overflow or any of those we need to make sure we understand
what the restrictions are and in most red teams you're going to find a list of well tested exploits
that they already have pre compiled ready to go.
So we know that there they exit cleanly.
They don't mess up.
They don't jack up the process.
They return the stack and everything back to normal.
So while test it exploits is normally the start of a mature red team.
However starting out red teams won't have this right away.
So keep that in mind.
But red teams that have been in the business for a little while tend to have their own protested exploit.
So make sure you look for those and you use those first before you go ahead and start pulling stuff
off the web.
And that goes for any type of exploit not just compiled or memory issued ones.
Now attacks on attacker traffic on network devices such as Port gains like I said with uplinks you can
take down network segments in some cases port scans can cause too much traffic for the switches and
they won't process their own traffic that they're supposed to be doing which slows down the network
which slows down connections which might drop clients from being able to reach your service.
You don't want to have to deal with that.
So make sure you keep reports against light unless you know the band within the network can handle it
which is a good question for the network operation team or the I.T. team or the network team to be able
to give you better insight on what segment you're about.
You're about to hit and whether or not segment is split across 10 different data centers.
So unstable exploits as I said the way it exits the threads the way it returns the process stack back
to normal others exploits that are built to recover and then there's ones that just crashes and crashes
you need to be able to understand which which exploits are what and this is where the come where it
comes into where you test the exploits in a development environment and not in prod first so you understand
what's actually happening.
Now another thing you want to look out for is systems or hosts or services that don't have any high
availability set up on them.
So you might have two hosts that are running a web service and this web service might not have any other
backup on it.
So if you bring down one you've essentially cut the entire load of the production network for that host
in half hour for that service and half you do not want to do that.
You want to make sure that you have all your ducks in a row and you understand the predicament on certain
machines which again reaches out to stakeholders which are going to go over in the next video the next
biggest part that I want to stress here is this goes for internal red teams.
This goes for consultants any any type of when you're in it in an attacker standpoint you need your
paper trail.
You need to keep track of the emails communications documents approvals of any of these considerations
and the scope the goals restrictions.
I want you to make sure you have everything down written down.
Everything is being communicated it's been approved.
You approve it with your manager.
You double check with your manager.
You want a CYF.
You want to cover your ass.
You do not want to have some some host fall off the face of the earth because you ran some weird exploit
you downloaded which caused it to be some reverse shell back to somebody in a different country.
Now customer data is exposed.
You don't want to do that essentially what happens when something like that does happen as you get something
called an RG which is a resumé generating event and I shouldn't have to explain what that is.
However you'll be looking for a new job.
If you if you decide to pull that so make sure that you are very specific.
This is a sensitive field.
Red teaming is a sensitive field whether you're internal or external.
More specifically when you're external as am I as a consultant you want to make sure everything's been
approved.
Everything has been double checked.
Your manager approves it.
Their manager approves it the client approves it.
In this case the service owners or another company everybody's got to approve everything that's about
to happen.
Because that is your get out of jail free card.
The last thing you want is to be doing some physical engagement let's say and you don't have a document
that says you have to prove right to try to break into this particular building.
You're doing a physical pen test and then you end up getting arrested.
So you want to make sure that you have everything in a row.
Same goes for when you're doing a remote exercise as well.
So keep this in mind.
I know this is getting more on the serious side of things.
However when you're doing anything from an attacker standpoint you have to make sure everything is correct
documented and the proof.