Professionals who have experience responding to real-life cyber incidents, including those in which they have observed attackers already operating confidently inside their environments, know that adversaries don’t usually rely on custom malware or novel exploits to conduct their attacks. Instead, they exercise discipline by maintaining command and control while moving laterally across the environment with escalating privileges.
These attackers often use legitimate penetration testing (pen testing) tools – notably frameworks like Cobalt Strike or Metasploit – against the very organizations those tools were intended to protect. This experience tells us that penetration testing tools are not inherently defensive. In fact, they become force multipliers for attackers in environments where the appropriate protections are not in place.
To be clear, we should not blame red team tools because they can become weapons in the hands of malicious actors. The fault lies with many organizations that deploy those tools into architectures that were not designed to contain them. Pen testing tools should not be used in production environments with standard identity practices, broad administrative privileges, unrestricted outbound access and limited behavioral monitoring. In these scenarios, the architecture has determined the outcome.
A Switch to “Adversary First” Thinking
Most pen testing programs focus on whether within an environment something can be exploited. But they rarely focus on the structural resilience of the environment itself. For that reason, organizations should adopt an “adversary-first” different approach to pen testing. With this approach, they should address a series of questions before any tool is deployed. These include:
- What paths would a real attacker take following initial access?
- When making architectural decisions, what might inadvertently enable lateral movement across the environment?
- In what areas does trust extend farther than necessary?
By consistently looking at their environment through this lens, organizations can identify structural weaknesses that traditional testing overlooks – including issues related to identity, segmentation and control plane access. This practice routinely exposes critical risks that prior assessments missed.
The issue isn’t the quality of the tools but that organizations allow pen testing to outrun architectural design. Pen testing tools – ranging from new AI-driven systems to broadly deployed ones like Cobalt Strike – work because of their ability to emulate real attackers. They operate in memory, use legitimate APIs and blend into enterprise traffic.
Those positive attributes are the same ones that make them dangerous when compromised or misused. For that reason, we increasingly see adversaries exploiting cracked or repurposed red team frameworks, mask malicious activity as authorized testing, and use trusted tools as attack infrastructure. In these cases, traditional defenses struggle because they were not designed to distinguish malicious intent from authorized execution inside a permissive architecture.
Deliberate Use in Production Environments
Pen testing tools provide important security benefits but must be applied purposefully in organizations’ environments. They should be considered high-risk capabilities and not routine utilities. That means enterprises should take the following steps to protect them
- Isolate their testing infrastructure from production control planes
- Enforce least-privilege principles limiting users’ access to only assets necessary to their jobs at the architectural level, not just as a matter of policy
- Don’t just look for malware signatures. Monitor activity for behavioral misuse as well
- Design environments that can remain defensible even if a trusted tool is abused
Architectural risk analysis matters more than test coverage. While penetration testing remains essential, it cannot serve as the lead focus to counter today’s threat landscape.
When architecture serves as the lead, enterprises are positioned with strong identity boundaries and enforced trust. In these environments, tools like Cobalt Strike become what they were intended to be: instruments for security and not weapons for compromise.
The organizations that get this right don’t ban helpful tools. They build environments that don’t collapse when tools fail.
Join our LinkedIn group Information Security Community!
