Pre-engagement Penetration Testing Considerations

Pre-engagement Penetration Testing Considerations

Introduction And Setup

So, you were just asked by someone if you can do a pentest for their company. Nice one hacker-kiddo!

BUT!!! Penetration testing is not just the “fun” hacking part. You need to do a good job if you want to keep earning penetration testing projects. You can accomplish that by having a plan and following logical processes consistently.

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.

Think about your point of contact and the company you will be dealing with! Do they seem unprepared? Do they seem really demanding? Are they the type to ask you to jump through tons of hoops that are not necessary? Is the company so large and complex it is going to take weeks or months to get access to the environment to conduct a pentest? Be sure to figure these items into how much time is going to be dedicated to that pentest and customer.

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.

Scope creep is one of the most efficient ways to put a penetration testing firm out of business.

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:

Some folks may want an NDA in place before providing any detailed answers. Try asking for their NDA before your scoping call so it can be reviewed\signed in advance.

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)?
Some service providers require advance notice and/or separate permission prior to testing their systems. For example, Amazon used to have a pentest request form that would have to be completed, and the request must be approved before starting any pentesting. If this is required, it should be documented with the ROE.

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?
Be sure to ask for a demo of the web app to see how it works and the intended functionality. Be sure to know if you are testing against production or non-production systems. Production stuff requires more careful pentesting processes and will take longer.

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
Check your laws! Some activities common in penetration tests may violate local laws. For this reason, it is advised to check the legality of common pentest tasks in the location where the work is to be performed. For example, any VOIP calls captured in the course of the penetration test may be considered wiretapping in some areas. Also, no ROE signed by a company permits you to pentest or social engineer another company on their behalf.

#4 Know How To Manage Customer Expectations & Communications

Think about what you are pentesting! Are you testing production systems? Avoid low-quality exploits that can reboot a system. Avoid load testing. Avoid “hail-mary” attacks that generate tons of noise. Avoid automated injection attacks and fuzzing on production systems that will get filled with tons of garbage data that will mess up business intelligence and require clean-up. Think about what is downstream of any web apps, mobile apps or API endpoints; for example, if you are brute-forcing a login page that is connected to Auth0 then you are going to piss off Auth0. Likewise with if you find a vulnerability that allows you to perform SMS spamming, don’t piss off Twillio. IF YOU ARE UNCERTAIN, THEN ASK!

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.

Be sure to inform customers ASAP when you discover an exploit with high-severity security findings. Surprises in reports make for very annoyed people.

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.
Include customer due diligence in the report too; you are not writing a hit piece. Let them know where they are doing well. Request from customers during the pentest for any evidence of them discovering you throughout the pentest.