Time
4 hours 20 minutes
Difficulty
Intermediate
CEU/CPE
5

Video Description

As a professional web app pentester, you must conduct yourself and your activities in an organized and professional manner. This is extremely important since your activities are virtually indistinguishable from a real attacker. The name of the game is to protect yourself! Key components of pentesting best practices are: - Gain written permission about what, how, and when things will be tested. - Create documentation that records the tests such as output from wireshark and tcpdump along with logs about what you did. - Build reports about what was discovered and how to fix vulnerabilities. - Establish a good working relationship with other departments to stave off any potential misunderstandings during testing.

Video Transcription

00:04
welcome to Cyber Very I am Raymond Evans and I will be your subject matter expert for Cyber Aires without penetration testing course.
00:11
In this video, we will be discussing pen tester best practices, what will be covered,
00:18
Gaining permission documentation, boating reports, one to test and working with other departments. This video is handy because many of the things in this video
00:29
can help keep you out of a lot of trouble and help you keep yourself covered in case somebody tries to throw blame at you for something that you didn't necessarily. D'oh. So the first and
00:40
most critical part
00:42
of pen testing or the preparation for pen testing is gaining permission.
00:47
Reading permission should always be established prior to performing tests.
00:50
You should never use the word of mouth or
00:54
a vague email or some sort of memo that was sent to you. You should always have an agreement has been written out and signed
01:03
by heads of departments and individuals who are allowed to approve this kind of thing.
01:11
If you have a low level boss who says, Hey, go do this and you know that that individual is not allowed to give that kind of
01:22
permission to you.
01:25
You should probably
01:26
talked to somebody higher than him. And make sure that that's exactly what needs to be done
01:34
right to cover yourself. This written permission will also act as an agreement
01:40
which will house things like different boundaries and what exactly needs to be done or wants to be done for this test. So in this agreement, you will need to have a list of what tests will be done,
01:53
how long each of these tests will be performed for. So this helps establish sort of time frames.
02:00
Ah, that
02:01
you will be performing the tests today.
02:06
So
02:07
that company who you work for or who your company is sending you out to perform the pen test for will know that that traffic that's going across the wire at that time will most likely be yours.
02:21
Along with these times, you will also need what your targets will be. So specific Websites are different machines that you have
02:31
set as the targets that you will be testing. This ups the people who you're working for identify that
02:39
they're not necessarily under an attack. But that's that. That is your traffic that is going across the wire there, not only to agreements need to be made with your customer, but they should also be established with any third party. Organizations that provide additional service is so I S s A S r p A S o
02:59
infrastructure service or platforms, as service is
03:02
as things like
03:05
cloud systems or cloud service is,
03:08
um
03:09
if you're going to be performing tests on a website that's hosted on the cloud, you will need to let that person who host that website on the cloud
03:21
I know that this will be happening. You know, you need to put them in the agreement as well and have them sign off,
03:28
because if you
03:30
have an individual who has a website and they give you permission
03:35
two
03:36
performing where that pen test on it. But the people who are hosting it on there
03:44
when their cloud
03:45
don't give you permission than the people who are hosting on the cloud,
03:50
um
03:51
can come after you and can call the cops on you and can look at this as an attack. Documentation should be maintained in order to protect yourself as soon as you get on the network. Anything that goes wrong
04:04
Well, most likely be blamed on you
04:08
by individuals who don't understand what you're doing.
04:12
They just know that you are there and you're performing a penetration test. And
04:17
even if they their system doesn't touch yours, it has nothing to do with yours. Um,
04:24
if you are pen testing a payment submission page on a website
04:30
and a computer goes down and h r.
04:33
The individuals in HR who don't know better are going to automatically assume that you tried to hack their computer down there
04:42
on blame will be thrown at you. So keeping a proper documentation will give you the ability to identify what you did
04:49
to damage the network or to protect yourself from accusations. This documentation should be automatic and manual. For the automatic
05:00
documentation, you have to have something like wire shark or TCP dump running.
05:04
This type of documentation allows for accountability of what happened over the network. So with wire shark or TCP dump running, you are able to accurately
05:15
show exactly what came out of your machine over the network. So if somebody and HR says, hey,
05:25
they attacked our computer
05:28
at
05:30
whatever time
05:31
you are able to go and look your wire shark or TCP dump at that exact time.
05:39
Ensure them? No, this is the I. P address I used
05:44
for the test, or this is the Web page I was performing the test against,
05:47
and you're able to protect yourself. Or if you did take down the computer accidentally, you are able to see
05:57
how you accidentally took it down. What exactly took what exactly caused that machine to fail and then manual documentation. This documentation should include a list of all commands that were used, what time they were used in what system they were used on.
06:13
So a small excel sheet or something like that with a couple of columns for things like commands, times, websites
06:23
and,
06:24
most likely as well, something that would be handed at into that is a notes section. So if something interesting happens when you type in a command, you could just
06:32
jot down that little note in that section.
06:35
But these are very, very important documents. These are very, very important ways of maintaining proper documentation to keep
06:46
yourself covered. When you build a report, a report should be comprehensive and easy for customers understand
06:53
their key elements that each report should include
06:56
a type of vulnerability that was found
06:59
where exactly that vulnerability was found,
07:02
how it affects the customer. So you should probably put in a little detailed item. Here is something like
07:10
such as
07:12
this cross site scripting can be used to enumerate cookies. Um,
07:18
and if it's ah banking company and you're able to successfully
07:24
get cookies from from a test they've performed,
07:28
then you can also show
07:30
proof that this this could be used to harvest cookies and steal individuals, money and things like that after you have how it affects the customers. You should also put a suggested fixing because
07:43
it's
07:44
good that you find vulnerabilities, but you should be knowledgeable
07:47
or semi knowledgeable as to how to fix it. So if you find something like a sequel injection, you know that they have to
07:58
have proper validation for user input.
08:01
Two.
08:03
Parse out certain key characters
08:07
that caused that
08:09
vulnerability

Up Next

Web Application Penetration Testing

In this course, SME, Raymond Evans, takes you on a wild and fascinating journey into the cyber security discipline of web application pentesting. This is a very hands-on course that will require you to set up your own pentesting environment.

Instructed By

Instructor Profile Image
Raymond Evans
Instructor