In this demonstration,
we're going to cover the process of preparing
for a penetration test on your own services
that are hosted in AWS,
which is an essential pre-engagement activity
for a pentest.
Before diving into the actual testing,
it's important to follow AWS guidelines.
So, we need to make sure that we obtain
the necessary permissions and understand the scope
and limitations to avoid any issues during your test.
Now, first, it's important to know here,
as mentioned in this first paragraph,
that AWS allows certain penetration testing
on certain services without any prior approval.
So services like AWS EC2, Amazon RDS,
and AWS Lambda are examples where you can conduct tests
freely as long as your activities
are within the approved scope.
All right, so we can see a few here.
Then we'll also see the prohibited services.
And again, you will notice this
on a lot of different penetration tests.
Denial-of-service attacks are typically
just prohibited across the board.
Most of the times, companies want to make sure
that they keep their systems up and running,
and there's been a lot of history
when a denial-of-service attack happens
where it's hard to recover the systems.
Okay, so then we also see here
there's other simulated events
that we might have to request
specific type of permissions for.
And you see here we have different forms for each event.
So for example, we have the red, blue,
purple team testing,
network stress testing,
iPerf testing.
So iPerf is a tool
for network performance measurement and tuning.
Then we have the DDoS simulation testing policy.
So you just need to request certain type of permissions
for the most part,
if it's not in the permitted list initially.
They do have simulated phishing, malware testing.
And again, this is the request authorization
for other simulated forms in general.
So pretty much everything
that wasn't on this initial list here,
it's going to be under this other simulated form events.
So we're going to click this
and just kind of go over the form briefly.
Okay, we have the simulated event submission form.
This is just an example of what the form will look like.
Now, of course, if you're going to do an Azure
or GCP, they're going to look a lot different,
but AWS is the most common cloud provider.
So this form probably be something
that you will encounter more often than not.
All right, so simply we have all the basic information,
right, you see we have the customer information,
so your AWS email correspondence.
Then we have the account ID of source,
so the AWS account ID initiated in test.
And then we have the IP addresses
of the non-AWS sources involved in the test,
separated by commas, of course.
And then we have a list of the AWS regions
where this testing takes place.
All right, so then we have the details of the destination
to which the event is being simulated.
So here in this first field,
we have the account ID of destination.
So again, AWS account ID of the target.
So one key distinction here
is that we're focused on the IP address of the client
that we're targeting, not our own.
Then we just have the AWS sources
that are involved in the testing.
You have non-AWS destination IP addresses.
So what that means is any non-AWS IP address
that are targeted, separated by commas.
So, if they're not part of the AWS system,
we need to indicate that here.
Then same as earlier, any AWS regions
where the destination sources are located.
So, next, let's look
at the testing security information section.
So first, we have pretty much
this monitoring and escalation form.
Well, we just need to make sure we need to confirm
if we either have a way to monitor the activities
and methods to stop it immediately if anything arises.
This goes along with the general pentest theory
of having an escalation path
for any of these type of issues.
And then we have the simulated event information.
So see we have stress test,
phishing, malware analysis, et cetera.
And we'll make sure we have at least
two emergency contact details.
And then just the generic comments
and questions field that we see
on most forms in general.
So, in summary,
in this demonstration, we just discussed
the essential steps for preparing for a penetration test
on your services that are hosted in AWS.
We touched bases on some
of the automatically-permitted services
like Amazon EC2, RDS, and Lambda.
Then we also focused on some of the ones
that required additional permission
'cause they were not included on the list.
And then we just covered the form
and just some of the fields
that we'll have to think about
when we're engaging in the penetration test.
So, that concludes the demonstration
and I'll see you in the next one.