AEV Demo | BreachLock Unified Platform | Adversarial Exposure Validation (AEV)

[Music]

Welcome to Breach's adversarial exposure

validation platform.

We're going to call it AEV for short.

What this is is a fully autonomous

pentesting/redteaming

tool for your team to be able to use to

simulate adversarial uh simulations

behavior uh and mimic what AP groups

would be able to do if they were able to

breach inside your network or from the

web.

So, our AEV solution is meant to be a

tool for your teams to be able to use to

either augment or uh hire a a virtual

redteamer or pentester for lack of a

better term. What this has the

capability of doing is autonomous

testing of infrastructure and of APIs

that are internal or public facing. So

an anticipated use case for this would

be we need to run continuous red teams

throughout the year inside our

infrastructure to assess risk to assess

the behaviors of what groups would do if

they were to breach and see what the

risk of uh CVE being exploited is.

The beginning of the journey here inside

AEV is first going to start from an

internetfacing lens. So, we need to run

an investigation against your company,

your organization to do a couple

different things. First, we want to

figure out who you are as a company, the

type of customers and clientele that you

service, but also your assets, your your

tech stack, what exists out there on the

web that APS and and threat actors may

be able to use as context for

engagements.

So, our first step here is going to be

adding a seed domain.

So let's just say the C domain is

breachlock.com.

As soon as I create this domain, a

public-f facing investigation is going

to launch with the intent of figuring

out your footprint to the web. So

subdomains, IP addresses of the servers

hosting those applications, locations,

and then also some contexts.

When that investigation has finished,

you can come in here and see the

results. So, if you've never engaged

with Breach Lock before and this is your

first time, here after a couple minutes

scan, you can see a list of uh all of

our public facing assets, what they're

doing, and then just also some context

about what it appears to be with a

screenshot of the landing pages.

Why is this information important for a

AEV tool set? Well, because this info

helps us marry it up into some thread

intelligence feeds.

So once that investigation is launched,

we're going to assign either a nominal,

a significant, or an elevated risk if

any of these groups were to target your

company.

If I click into an AP1, I can say, okay,

here's a description of what AP1 does,

who they are, who they tend to target.

They favor using these specific tools,

and they also favor these TTPs.

Based on that information about them and

you, we think that they pose a

significant risk if they were ever to

target your company because you're the

type of company they target and these

techniques may be successful against

your specific tech suite.

So, what this is going to do here is

it's going to later help uh influence

the objectives throughout both the

external and the internal engagements if

you would like to emulate the behavior

of any of these groups. Before we get

there, we need to deploy some footholds

internally so that we have a jump host

in order to reach those inside assets.

So, we're going to come into the

deployment phase here.

Now, the uh AEV deployments, these are

not agent-based. This does not need to

live on every workstation or every

endpoint. Think of this as a a physical

laptop that one of your pentesters would

have. So, creating a deployment is as

easy as naming this. I tend to name it

by location

and then choosing what type of hardware

or operating system this is going to run

on. So we do support Linux distros. We

can run on Mac, either Intel or

silicone. We can run on Windows. And

then we also do have an OVA file if you

would prefer to run on a on a

hypervisor.

Deploying this is as easy as dropping

this command in command line on that

host device. That's going to install all

the dependencies that are needed

throughout the testing engagement and

it's going to connect to our SASbased

tenant here for you to be able to

remotely manage.

Now, once those footholds are deployed

and you're able to reach the hosts that

need to be in scope for testing, we're

going to do something similar on the

inside that we did on the outside. We're

going to visualize what that surface

looks like. So, from within here, I can

choose an individual foothold.

and I'll be able to see all of my

network interfaces and all hosts that

are reachable by ping across various

subnets. So here's a list of every host

that I can ping using this foothold. And

now I know that I can put these in scope

for my internal engagements.

So the next step is going to be to

actually craft and launch those

engagements.

Up here I'm going to go into the

engagement stage. This is where you'll

also be able to ingest all of the

results. But first, we're going to

create.

So, from within here, we currently have

the ability to launch internal and

external network pentest teams. And we

can also launch uh tests against REST

based APIs, both internal and external.

For me right now, I want to launch an

internal engagement and I want it to be

somewhat red team focused.

So let's just say this is my data

center.

I'm going to choose that live foothold

that's able to reach the hosts that I

want to target.

Here I can explicitly allow hosts to be

put in scope for testing. So just

because we can reach 100 hosts doesn't

mean that you want to actively test all

of them. We will require your

intervention here to add them.

Here are those adversary profiles again.

So if throughout this engagement you

would like to mirror and mimic the

behavior and activities of these APS,

you can put them in scope. Otherwise,

we'll just do a base sweep and test any

way that we can.

From within here is how I get to dictate

how I want this story to play out. So I

had mentioned I want this to be more

like a red team. I want a very low and

slow engagement. Maybe I have Crowd

Strike or a Sentinel One, some sort of

EDR solution in play in my

infrastructure and I want to see if I'm

able to bypass those solutions. I also

want to see if I have the ability to

bypass alerts and alarms from the sock

from the blue team and remain

undetected.

On the other hand, we can also pump this

up to an extreme engagement where this

is very fast and very loud. Uh

simulating maybe somebody walking into a

branch or a brick and mortar, plugging

in a device with a reverse shell. What

are they able to do until they are

locked out of that environment?

Here we'll let you set a threshold for

the severity that you would like to

report on. So maybe you don't have an

SLA for low orformational findings and

you only care about medium and above.

I'll set that threshold for medium. Or

maybe you just want to configure a test

to run every week on a Friday and you

only want to check for critical severity

findings every week. You can set that

threshold here.

Now, within this exploitation phase

here, we're going to let you choose