While there are many articles directed at assessors and consultants on “what not to do” during a penetration assessment, I haven’t seen many blogs directed towards what things clients should avoid when preparing for a penetration assessment. I wanted to address this topic, and share from experience, pitfalls that can often hinder the progress and quality of a penetration assessment.
What is a "Penetration Assessment"?
Penetration assessments are a way to identify an organization’s risks by simulating common threats. These assessments can target a wide range of scenarios; such as, external service attacks, insider threats, social engineering and physical intrusion. Once these vulnerabilities have been identified and exploited, that information is then compiled into a report and passed on to the client for remediation. Because these assessments generally happen within a smaller timeframe, and within a specific assessment window, we consider the results to be more of a "point in time" assessment. Due to configuration changes with time, we recommend having a penetration assessment conducted on a regular basis.
Now, here’s how to NOT prepare for an assessment.
A Vulnerability Scan is Not a Penetration Assessment
Companies can often confuse a vulnerability scan for a penetration assessment. It is important that they understand the difference here. If the assessor is only running automated scanning software, and not attempting exploitation, that is only a vulnerability scan. Vulnerability scanners are good for quickly finding "low hanging fruit" against basic configurations and systems in an environment. However, they lack the human component, and therefore cannot do things such as daisy-chain vulnerabilities together to escalate to something more critical. They are restricted to a certain set of pre-programed rules, and are unable to go outside of that.
Poor or Inaccurate Scoping
Poor scoping can result in many vital targets being excluded. This could potentially lead to compromise. Here is a quick list of the most common scoping gaps that I’ve encountered:
- Limiting what can be assessed
- Asking the assessor to only focus on one type of system, such as Windows-based systems only, and ignoring all other system types that are still connected to the same network.
- Removing the Domain Controller from the scope limits testing of things such as domain resources and checking that domain’s security policies.
- Including items that they don't own, or not getting permission from 3rd party system owner
- It is important to always have permission for a penetration assessment against the system/network from the 3rd party who owns the systems. Otherwise, this could be a breach of contract with that vendor, or could have other legal ramifications.
- Leaving out entire sub-networks or departments
- It is important to include as much as possible within the scope. This will help to give a more robust view of the network’s security posture.
- Only putting hosts in scope to meet a minimum regulatory requirement, such as PCI.
- This completely bypasses assessing any sort of lateral movement across a network, through systems that might not even be related to the intended target. A common scoping gap involves forgetting to include trusted domains within the assessment scope.
Limiting What the Assessor Can Do
At times, clients will provide a healthy scope, but then add limitations that can smother the efforts of the assessor. Below are some examples that will prevent an assessment from exploiting vulnerabilities to their fullest potential, to show how that issue can affect the client and their assets
- No permission to make any changes to the hosts
- This means, “Do not write anything to disk.” This rule excludes exploiting any type of remote-code-execution (RCE), registry changes, etc., and can limit chances to escalate privileges, or to pivot into other systems or networks.
- Not enough time to thoroughly complete the assessment
- Rushing the assessor to try and prevent a deep-dive during an assessment is not a good way to expect a thorough job. There have been times when clients have done this on purpose to try and prevent assessors from finding and exploiting vulnerabilities.
- For social engineering assessments
- Excluding employees, and departments. This prevents us from going after whatever targets they specify, which often includes C-level employees, network admins, or whatever else they want to exclude. This can be limiting and is unrealistic compared to real word attacks.
- Excluding use of guise as employees or vendors is also another restriction that we’ve encountered. This basically left us to cold-calls, which is restricting, and again, unrealistic.
- No use of the company’s logo or mention of company name during phishing and vishing campaigns is an extremely limiting rule. Although there are still other useful tactics to bypass this, it isn’t something that an attacker is going to avoid. It’s usually one of the most used tactics to attempt to gain trust.
- Notifying employees and departments of the social engineering assessment in order to increase the client’s chances of "success" is certainly a way to take out any sort of “real world” component. This is where clients might notify their employees or security guards, or might even seek out the assessor themselves while they are on-site to stop the engagement by "catching" them quickly. Doing this can provide very little understanding of the state of security awareness of their employees or the success of their internal security awareness training.
The sample of common mistakes that I’ve provided can cause problems on both sides of the table, but can ultimately end up affecting the client in a negative way. Allowing these to occur also prevents the ability to provide a realistic view of a company’s security posture. This could also lead to a future compromise, or even avoiding detection of a previous compromise — which can of course lead to a whole other set of issues for them. If you are interested in a more accurate view of your state of security, and wish to be better prepared against real world attacks, preventing any of these issues is certainly a step in the right direction!