📆 Join Us Every Wednesday at 9:00PM ET (see our latest events on LinkedIn)
Table of Contents
Introduction And Setup
So, you were just asked by someone if you can do a pentest for their company. Nice one hacker-kiddo!
Pre-engagement and post-engagement planning are arguably just as important, if not more important, than the hard skills-based component of penetration testing. Much is written, discussed, analyzed, planned, and built around all of the actual “hacking” parts of penetration testing, but relatively little is discussed about the scoping, communications, project planning, and expectation setting part of penetration testing. It’s especially crucial for very large and complex environments, systems, applications, and companies that could take over a hundred hours of penetration testing effort to complete. Neglecting to properly complete pre-engagement activities has the potential to open the penetration tester and their team to a number of problems, including scope creep, taking systems offline, having unsatisfied customers, legal troubles, and unprofitable projects. The scope of a project specifically defines what is to be tested. How each aspect of the test will be conducted will be covered in the Rules of Engagement section.
#1 Know Who You Are Talking To
- Who is asking for this penetration test? Speak at the level and in terms of your point of contact. Use jargon you believe they would know and avoid jargon they will not know.
- Examples: Is it a person with technology experience? Is it a business decision maker?
What is the personality type of the point of contact you are interfacing with? Speak to the speed, detail, and comfort level of your point of contact.
- What are they looking to get out of this penetration test? Most people have an objective and agenda; make sure your pentesting report aligns with it.
- Is it for real insight? For regulatory compliance? Because a customer asked? Are they trying to allocate more to technology or cyber budgets? (Be aware that enterprises are filled with tons of compliance theater and politics - know what your point of contact wants, what their boss wants, and what the company wants)
- What do they mean when they want “a pentest”? Avoid speaking “past” one another because you are not speaking with the same fundamental meaning.
- It’s very common for people not to be speaking the same jargon or lingo.
- Many people in general, do not understand the difference between a vulnerability scan or a pentest.
- Pentest is a very generic term, and there are tons of things that fit under the category or are closely related to it; things like wifi pentesting, physical pentesting, social engineering, phishing testing, network pentesting, web app pentesting, API pentesting, cloud pentesting, white box & gray box pentesting, red teaming, etc.
- Ask your point of contact to briefly explain what they want, then make sure you briefly explain what you would be doing and what your pentesting process involves.
- Explain what techniques, guidelines and processes you are going to follow. For example, NIST800-115 Technical Guide to Information Security Testing and Assessment, Penetration Testing Execution Standard (PTES), OWASP Web Security Testing Guide, etc.
#2 Know The Scope Of Your Pentest
How Much Time Is This Going To Take? How Much Should You Get Paid?
One key component of scoping an engagement is outlining how the testers should spend their time. As an example, a customer requests that one hundred IP addresses be tested for the price of $100,000. This means that the customer is offering $1,000 per IP address tested. However, this cost structure only remains effective at that volume. A common trap some testers fall into is maintaining linear costs throughout the testing process. If the customer had only asked for one business-critical application to be tested at the same pricing structure ($1,000), while the tester would still be only attacking a single IP, the volume of work would have increased dramatically. It is important to vary costs based on work done. Otherwise, a firm can easily find themselves undercharging for its services.
Despite having a solid pricing structure, the process is not all black and white. It is not uncommon for a client to be completely unaware of exactly what it is they need tested. It is also possible the client will not know how to communicate effectively what they’re expecting from the test. It is important in the Pre-Engagement phase that the tester is able to serve as a guide through what may be uncharted territory for a customer. The pentester must understand the difference between a test which focuses on a single application with severe intensity and a test where the client provides a wide range of IP addresses to test and the goal is to simply find a way in.
Anything that is not explicitly covered within the scope of the engagement should be handled very carefully. The first reason for this is scope creep. As the scope expands, resources are consumed, cutting into the profits for the tester and may even create confusion and anger on the part of the customer. There is another issue that many testers do not think of when taking on additional work on an ad-hoc basis: legal ramifications. Many ad-hoc requests are not properly documented, so it can be difficult to determine who said what in the event of a dispute or legal action. Further, the contract is a legal document specifying the work that is to be done. It should be tightly tied to the permission to test memo.
Any requests outside of the original scope should be documented in the form of a statement of work that clearly identifies the work to be done.
Try to balance asking questions that are going to provide you the insight you need to scope the pentest but not so many where you are interrogating someone for a simple small network pentest; it annoys people.
The issue is that many companies and managers have little to no idea how to identify it or how to react to it when it happens.
There are a couple of things to remember when battling scope creep. First, if a customer is pleased with the work done on a particular engagement, it is very common for them to request additional work. Take this as a compliment, and do not hesitate to ask for additional funding to compensate for the extra time spent. If a customer refuses to pay for the extra work, it is almost never worth staying on to do that work. People need to put food on the table to eat; no one works for free.
A key component of defeating scope creep is explicitly stating start and end dates. This allows the project to have a definite end.
Good Scoping Questions To Ask:
Network Pentesting
- Is the penetration test required for a specific compliance requirement?
- When does the customer want the active portions (scanning, enumeration, exploitation, etc...) of the penetration test conducted?
- During business hours?
- After business hours?
- On the weekends?
- How many total IP addresses are being tested?
- How many internal IP addresses, if applicable?
- How many external IP addresses, if applicable?
- How are you able to perform any internal pentesting?
- VPN Access? Deployed Computer? Virtual Machine?
- Are there any devices in place that may impact the results of a penetration test such as a firewall, intrusion detection/prevention system, web application firewall, or load balancer?
- Where are these systems located geographically? Are they in a cloud provider?
- Are all of the systems in scope owned by your company are there some systems owned by a hosting provider or IT MSP?
- In the case that a system is penetrated, how should the testing team proceed?
- Perform a local vulnerability assessment on the compromised machine?
- Attempt to gain the highest privileges (root on Unix machines, SYSTEM or Administrator on Windows machines) on the compromised machine?
- Perform no, minimal, dictionary, or exhaustive password attacks against local password hashes obtained (for example, /etc/shadow on Unix machines)?
Web Application Pentesting
- How many web applications are being assessed?
- How many user accounts and privilege levels are being assessed?
- How many static pages are being assessed? (approximate)
- How many dynamic pages are being assessed? (approximate)
- Will any source code, postman collections, swagger file, WSDL, SDK be provided?
- What is the function of the web app(s)?
- What type of data does the web app(s) process? PII? PHI? PAN? etc.
- Who are the primary users of the web app(s)?
- Are you looking to have a production or non-production environment pentested?
- Will there be any kind of documentation?
- If yes, what kind of documentation?
- Will static analysis be performed on this application?
- Does the client want fuzzing performed against this application?
- Does the client want role-based testing performed against this application?
- Does the client want credentialed scans of web applications performed?
Social Engineering
- Is social engineering completely blind and requires OSINT and recon?
- What is the expected communications process with the customer during the social engineering engagement?
- Upon gaining access to a user account or system, should lateral movement be performed?
- Does the client have a list of email addresses they would like a Social Engineering attack to be performed against?
- Does the client have a list of phone numbers they would like a Social Engineering attack to be performed against?
- Is Social Engineering for the purpose of gaining unauthorized physical access approved? If so:
- How many people will be targeted?
- It should be noted that as part of different levels of testing, the questions for Business Unit Managers, Systems Administrators, and Help Desk Personnel may not be required. However, in the case these questions are necessary, some sample questions can be found below.
Related to this subject is this GoVanguard Security private page:
#3 Have A Good Rules of Engagement (ROE) In Place
Rules of Engagement (RoE) is a document that deals with the manner in which the penetration test is to be conducted. Before you ever start pentesting anything, be sure to have a signed ROE by someone who has the legal authority to do so for their company.
More specifically, this document states the scope and contains a signature that acknowledges awareness of the activities of the pentesters. Further, it should clearly state that testing can lead to system instability, and all due care will be given by the tester to not crash systems in the process. However, because testing can lead to instability, the customer shall not hold the pentester liable for any system instability or crashes. It is critical that testing does not begin until this document is signed by the customer.
A Robust ROE Should Include At Least:
- Scope of Systems to Pentest
- Pentesting Timeline
- Pentesting Timeframes/Window
- IPs/MACs Which Pentesting Will Be Conducted From
- Standards and Guidelines The Pentest (NIST 800-115, PTEST, OWASP Web Security Testing Guide, etc.)
- Communication Channels & Status Update Frequency
- Contact Details of Points of Contact on Each Side
- How Sensitive Data Should Be Handled
- Disclaimers on Point-in-Time Assessment, Comprehensiveness, and Ramifications for System Outages
- Commitment to Customer Confidentiality, Integrity, and Availability
- Any Customer Specific Limitations
#4 Know How To Manage Customer Expectations & Communications
Evidence Handling
When handling evidence of a test and the different stages of the report it is incredibly important to take extreme care with the data. Always use encryption and sanitize your test machine between pentests. Never hand out USB sticks with pentest reports out at security conferences. Avoid re-using a report from another customer engagement as a template! It's very unprofessional to leave references to another organization in your document.
Report Details and Content
Be sure to set expectations in advance of what your pentesting report will cover and how all the data will be laid out. Things like the scope of systems, testing methods, observed security findings, exploited security findings, lists of affected systems, remediation recommendations, references, etc. Be ready to provide a spreadsheet of the security findings and a letter of attestation too.
Regular Status Meetings & Email Updates
Throughout the testing process, it is critical to have regular meetings with the customer informing them of the overall progress of the pentest. These meetings should be held daily and should be as short as possible. Meetings should be kept to three concepts: plans, progress and problems.
Plans are generally discussed so that testing is not conducted during a major unscheduled change or an outage. Progress is simply an update to the customer on what has been completed so far. Problems should also be discussed in this meeting, but in the interest of brevity, conversations concerning solutions should almost always be taken offline.
Time of the Day to Test
Certain customers require all testing to be done outside of business hours. This can mean late nights for most pentesters. The time of day requirements should be well established with the customer before testing begins. Be sure to over-communicate rather than under-communicate when you start/stop pentesting.
Dealing with Shunning
There are times where shunning is perfectly acceptable and there are times where it may not fit the spirit of the test. For example, if your test is to be a full black-box test where you are testing not only the technology, but the capabilities of the target organization’s security team, shunning would be perfectly fine. However, when you are testing a large number of systems in coordination with the target organization's security team it may not be in the best interests of the test to shun your attacks.
Capabilities and Technology in Place
Good penetration tests do not simply check for un-patched systems. They also test the capabilities of the target organization. To that end, below is a list of things that you can benchmark while testing.
- Ability to detect and respond to information gathering
- Ability to detect and respond to footprinting
- Ability to detect and respond to scanning and vuln analysis
- Ability to detect and respond to infiltration (attacks)
- Ability to detect and respond to data aggregation
- Ability to detect and respond to data ex-filtration
- When tracking this information, be sure to collect time information. For example, if a scan is detected, you should be notified and note what level of scan you were performing at the time.