From Offence to Defence: Using Offensive Security to Boost Incident Response
Source: NSB Cyber
When attacks leave little forensic evidence, it can be difficult to see how an attacker achieved their objectives. In these cases, organisations often face the difficult question: “How do I close out my security gaps and ensure that all possible attack paths that allowed the incident to occur have been remediated?”.
In such situations, an auxiliary service often complementary to core DFIR capabilities during an incident, is having an offensive security testing capability (i.e. penetration testing). An experienced pentesting team lives and breathes the same tactics, techniques, and procedures a threat actor would use. This includes simulating a threat actor targeting your organisation and network to determine possible entry points, identifying potential gaps in your security processes, confirming remediation efforts and ultimately providing assurance that the incident has been fully contained and remediated.
In this article, we will briefly explore several common reasons for engaging in pentesting during an incident, along with the types of pentests most beneficial in these contexts. We’ve also included a helpful guide ‘Pentesting in Incident Response: When and How to Use It’ with step-by-step insights and recommendations.
Common Reason 1: Lack of evidence resulting in an incomplete forensic picture
In a perfect world, every organisation would have full visibility into every single action taken by a threat actor in their environment, enabling immediate containment and response. Identity, cloud, network, endpoint, and application logging would all be enabled, and streamed to a SIEM monitored 24x7, with redundancy in place to prevent tampering. EDR deployments would capture additional telemetry across devices with tamper protection enabled, allowing for continuous monitoring.
Unfortunately, the reality for many organisations (particularly small and medium-sized enterprises) is that logging is often limited and not tamper-proof, allowing threat actors to erase their tracks. Further complications arise when well-meaning teams accidentally destroy evidence (e.g., prematurely rebuilding a server and erasing the original disk).
How can pentesting help here?
Suppose you suspect the initial access came from a recent critical vulnerability in your Product X VPN. A scoped pentest against this vulnerability can help prove or disprove the theory.
Or imagine a threat actor compromised user X’s account, but hours later the domain administrator Y’s account was also compromised. A pentest team could assess your Active Directory environment to determine if an attack path existed between user X and admin Y, then help you close it, preventing the same escalation if another account (say user Z) was compromised.
Common Reason 2: Technical validation of containment efforts
Sometimes organisations need to validate that remediations have been implemented correctly, especially when remediation isn’t as simple as applying a patch, or when mitigating controls on a 0-day vulnerability with no vendor fix available. Or perhaps the stakes are simply too high, and you want a “trust but verify” assurance (something we at NSB Cyber strongly advocate).
In such cases, a scoped penetration test can quickly confirm whether a vulnerability has been successfully remediated. By assessing the vulnerability, applying the right methodology, and attempting exploitation (with permission), independent testers can provide assurance that fixes are effective. This independence is especially valuable when communicating with partners or regulators who may question whether containment actions were sufficient.
The last thing an organisation wants, is to discover after the fact that they remain vulnerable to the issue that caused the incident in the first place.
Common Reason 3: The entire organisational estate is at risk
In some cases, threat actors exfiltrate sensitive IT documentation, cybersecurity playbooks, or even platform source code. This creates one of the most challenging response scenarios, as attackers now have insight into internal gaps and vulnerabilities, forcing you to treat your entire surface as potentially exposed. From a penetration testing perspective, the priority is validating the security of your most valuable and exposed assets first. Typically, this starts with external-facing systems (e.g., web applications, VPNs, and perimeter appliances) before moving deeper into internal systems where attackers could inflict the most damage.
Common Penetration Testing Scopes in Incident Response
Each cyber incident is unique, and so are the penetration testing requirements. A value-adding pentest should be scoped to the systems and networks that were impacted, exploited, or exposed.
Some common examples include:
External Network Penetration Test: A short, time-boxed assessment of the external network perimeter, often useful when a vulnerability (e.g., VPN, RDP gateway) has been exploited.
Active Directory (AD) Vulnerability Assessment: A targeted penetration test to uncover misconfigurations and attack paths within an Active Directory environment. Particularly valuable for understanding how attackers may have abused privilege escalation.
Web Application Penetration Test: A focused assessment of in-scope applications for common vulnerabilities. Often applied to CMS platforms (e.g., WordPress, Magento, Drupal) or outdated/unpatched web servers.
Scenario-Driven Test: Tailored to a specific concern raising during an incident. For example: “An internal system was scanned and targeted by a threat actor for two days during the incident, but we don’t know the extent to which it was potentially exploited”.
Final words
A strong penetration testing capability can augment DFIR and CTI efforts, providing a more holistic response to cyber incidents. As the saying goes: the best defence is good offence!
Ready to be supported by an experienced cybersecurity team? Let’s start the conversation - book a meeting with us today.