3. Phases of a Web Application Pentest

Step 1: SOW & MSA Signed

SOW = Statement of Work MSA = Master Service Agreement

SOW is a longer version of a quote basically the paper that lays out payment terms, the scope that we are allowed to touch, details about what accounts/infrastructure we will be able to touch upon and basically a description of the service we need to work with, a general overview of the situation.

MSA lays out some of the rules of vendor - client relationship, for example who is liable if something occurs? We also have something called negligence or gross negligence, talks about liability in certain situations because we are doing pentesting against production, service systems, development systems potentially and it just depends.

There are some limitations to which as bug bounty hunters we need to pay attention for example we might take down a system during a pentest or a bug bounty discovery we have:

CASE A:

We take down a system by mistake trying to poke at it and maybe it was running an old software or application on a server that shutdown or went down which can sometimes really happen by mistake. Let's say we were careful with what we were doing but something went wrong and we can say:

"Hey, I was testing for this and accidentally I took this down because it might have affected your old version of x software"

CASE B:

We pentest a system or a service but acting grossly negligent by trying any kind of exploits or payloads at it without paying attention, that can lead to partial service or total service disruption, and it usually happens when we use "random bullshit go" exploits without actually planning and thinking of consequences or without knowing what the hell they do.

"Hey, I took this down because I didn't know what I was doing" :(( qq

We also layout things as NDAs and non-compete agreements basically saying we don't snipe employees from each other and definitely setting up the location or if we need to go to court we go to an arbitrator first instead of going directly to court

Step 2: ROE - Rules of Engagement

In the rules of engagement we will lay out what we can and cannot do during an engagement. That includes what we can attack, can't attack, what times we're going to be testing, what dates we are going to be testing.

Me and Demo Corp

Part 1: Establishing some ground rules for the attacks so we can provide best benefit to Demo Corp regarding the interaction and to prevent law enforcement involvement. They are responsible to document responses for our intrusion attempts and we have to communicate in a timely manner to discuss if we're too loud and they're catching upon it or if we need to be quieter at times.

Part 2 - CPOC:

Client point of contact is responsible for the coordination with the pentesting team. They will be able to verify and differentiate the pentest suspicious activities with our team to know if it's not coincidental with real-world hacking attempts. They will be able to reschedule activities if necessary and will make ALL his contact methods known to us.

Part 3 - IPOC: Same as CPOC but on our end.

Part 4: Rules of Engagement

• Test Dates - When is it happening?

• Status Updates - How often and how we will report updates?

• Web application PenTest - The in-scope and out-of-scope rules

Part 5: Test Boundaries

What is the out-of-scope things we do not touch.

Part 5: Stop Point

Explaining how and when we will stop testing.

Part 6: Keeping Access

Lay out we may maintain access throughout testing as an admin account. Like if we get access to something and they want us to keep testing someone in their company discovers it we will be able to maintain access to the cPanel to not go through the whole shenanigans again.

*** This needs to be undone when we are done with the testing.

Part 6: Announcement:

We do not disclose the attacks etc.

Part 7: Project Closure

It will be closed on x date or after debrief happened.

Part 8: Postmortem

The penetration team will offer full disclosure and reporting to explain the attacks and vulnerabilities found out at Demo Corp

Part 9: Out of Scope:

• DoS

• Social Engineering / Phising etc.

Disclaimer:

• Not responsible for the system outages experienced before or during the assesment ![[Pasted image 20231009003300.png]]

NOTE: IT DOESN'T PROTECT US FROM GROSS NEGLIGENCE!!!

We send an e-mail when we test to let them know from which IP address we will perform the attacks.

===============NEVER BEGIN TESTING UNLESS YOU SIGNED THE ROE! NOW WE CAN BEGIN TESTING===========

Step 3: Verify the Scope

We verify once more that the scope they provided us is theirs and not somebody else's, ips, domains etc.

Step 4: Pentest Occurs

You do the pentesting that usually takes around a week depending on how much work needs to be digested and how many people are involved.

Step 5: Report Written and Delivered

We write the report well documented with everything we found, things they did well or not so well.

Step 6: Debrief

Sometimes clients ask for a debrief meeting that should usually take around 30 mins - 1 hour. They might argue over the criticality of some issues and of course they will try to balance it in their favor in some instances, however we as pentesters have the final decision in how the report is delivered and even though they can argue over some stuff we choose what we write as they hired us for that. They can also go the complete opposite direction and ask to be way more critical to push for some specific changes management wouldn't normally agree with.

Step 7: Retesting ( IF NECESSARY )

When problems are fixed we retest sometimes what is repaired to see if the issues have actually been fixed. The report might be redone or have a second version explaining the changes and if those actually fixed or didn't the initial issues.