Hi, everybody.
In this particular video, we're going to go over a pretty high level on what a Red Team is.
So like I said in the previous video, we are going to go the whole red team blueprint is based around the red team.
So we will go to all of this in more detail.
But this is just a quick high overview.
So a red team in a nutshell is we identify and exploit issues in an organizations environment.
So we don't do the run a scan, fire up, vulnerability scan, find out, OK, this particular service is vulnerable to this and then just report it.
So what we do is we actually go out and exploit the actual issue to see whether or not it's real, how it affects our organization.
Inside of this, we also will check on new exploits that come out against the organization to see if they are valid.
Do they fit in our organization?
We simulate external internal threats.
So this could be disgruntled employee, hacker from a different country.
So we try to simulate both sides of the of defense here.
There's a lot of internal threats, just as there are external threats.
Each have their own negatives and positives as far as like what can be done.
We also provide cyber awareness training so this can be phishing training, password cracking, training or use a weak passwords or reuse of passwords.
In a general sense, this may or may not be under a different team depending on the organization, however, and in some cases where phishing is the is owned by the red team as it is in my particular case, we handle the awareness training around, you know, what you can can do how to identify things.
So it's more of a full feedback loop, which is important of a slap on the wrist, knowing what you did wrong, how to fix it, etc.
We'll go into that a little bit later on.
But when I go over some phishing in detail, so we also test the organizations response to active threats.
So whether when we're doing an engagement of some kind, we could be throwing off alerts that the blue team would be getting.
So seeing how they handle it, because in some cases we want to test something without the blue team knowing that it's being tested.
So because of this, we checked their actions.
How they how well did they how well do they do in terms of how long did it take for them to actually identify that we were there and we were doing something malicious.
So a good a good red team needs to understand the defensive side as well as the offensive.
The problem with that is there's a lot of people that come up and they just learn on the offensive side.
Now, that'll get you far.
However, to be well rounded, you need to be able to understand that, yes, you could exploit this particular issue.
But how do you fix that particular issue when it's not just telling somebody to patch something?
Something's out of date?
Well, maybe there's a regular expression that failed, which allowed you to inject commands, for example.
How do you deal with that and provide them detail on how they can fix the problem?
Where was the RegEx lax?
Where was it weak?
How to tighten it up a little bit?
It's important to be well rounded in terms of offensive and defensive, because without knowing what the defenses could be in place, if you're attacking from a unknown perspective, as in you're not you're not letting them know you're going to set off so many alarms, just something as simple as throwing a port scan and default settings is enough to trip off most intrusion detection systems and alerting software that they'll know immediately that you're there.
So there's a lot of stuff that you'd have to know ahead of time on the defensive side.
So why are we needed?
There's a lot of reasons why red teams need it. In most cases, where SME or a subject matter expert on attacks, attack scenarios, data infiltration, exfiltration as well.
Any type of attack that an organization could could happen, could happen to an organization.
We need to be able to be there to interject and figure out whether it's a real threat or not, realistically testing scope of an attacker's effectiveness in situations.
So just because there's an issue of somebody has a type of injection attack on their web app, if there's no sanitization on it, that's that's a problem in and of itself.
But if you allow that through and then the let's say the development team doesn't think it's a big issue because you have to be authenticated.
Well, getting authenticated access to a Web app, there's a there's a lot of ways to do that.
So relying on something being behind authentication is not necessarily good, a good spot.
And just because they have access to that and we exploit it, were we able to gain it?
Execution on the machine from that machine were we able to infiltrate the rest of the network.
So not just taking it from a finding but to a full scope of what you're trying to do?
We also provide risk analysis on attacks and vulnerabilities that can hinder the company and the organization.
So we're able to take certain types of attacks, more specifically vulnerabilities as well, provide a risk matrix for them to be able to them as an e-staff and the executives and managers and the organization as a whole to be able to tell them that this is the this is the risk that you're taking when you allow this type of configuration or this type of service to be unpatched.
So and that's a very big thing to have.
So, are is the red team required?
Yes and no.
So in a larger organization?
Most definitely, yes.
There's there's way too much moving parts, way too many moving parts, way too many developers over top of each other.
There's there's way too much that can go on that could go wrong in an organization.
So we definitely need it in a larger organization.
Now, a smaller organization that's maybe 100 people, 50 people, maybe even 150, 200 people.
In a general sense, a lot of people in those companies wear multiple hats, so to speak.
So one guy could be the software developer, network administrator and security guy that kind of does everything.
I've been in those roles before where at smaller companies you kind of wear 10, 15 different job roles all at once.
So, in this particular case, it might not be needed because you might be able to get the one one guy or girl that can can perform those actions, not necessarily on the scale of a full team, but enough of the scale to get away with the task needed at that point in time.
So the team structure, this is a more of a generic structure for a red team in general, and the size of the team can vary depending on the size of the organization.
So, as I said, you know, you might have one person on the red team, quote, unquote, red team.
If you're at like 100 or 150 people at a company with 2000, 3000, 10000, 20000 people, you're going to see something similar to this where there is a manager.
I didn't added onto this particular slide, but there's normally a director.
Once you start getting into the 5, 6, 10000 employee companies, there's normally a director, a red team director, a manager.
There may be a senior manager in there as well and possibly even a VP.
So from an organizational standpoint, you normally have a manager, you have one manager, 1 to 2 leads, possibly 3.
Depending on the situation, majority of your task force is going to be mid level, which is level 2 to about 3 or 4.
Once you start getting 4 or 5, you start creeping into the lead.
The entry level is normally up for debate.
So most red teamers are not entry level per se.
They may be entry level to red team, but they should not be entry level in general.
So as an example, you wouldn't grab somebody who is fresh out of school and never touched IT before in their lives to bring them on to an enterprise level red team.
Now, it does happen with internships, which is also included in this entry level.
However, most people there entry level and red team have been system administrators.
They've done IT support desk.
They've done some other sort of task of IT before they happen to make it to the red team.
So this is a quick overview of what the team kind of looks like, why we're here, what we do, a lot of this.
I'll go into more detail through the rest of the blueprint.