What Makes a Good Offensive Security Tool?

Just a few real world tools that we use in our lab. #nofilter

At its core, offensive security doesn't really have anything to do with tools. Offensive security is the practice of making systems, processes, and people act in ways that may not be intended - often against the best interests of an organization, user, or data owner. There are often high-tech and low-tech ways to achieve your goals as a red-team operator. Likewise, successful blue-team engineers don't defend against tools - they understand root causes of failure and where their control gaps are so they can build more resilient systems. The value of either side of security is in the results.

That said, tooling can affect the trajectory of a given engagement and increase capabilities. Widely available tooling can tip the scales in favor of either attackers or defenders. Quality offensive tooling can provide access to new attack surface area or increase the pace of testing so that more of the system can be explored within a constrained timeline.

Keep in mind we are talking about tooling here, not intention. Our constrained timeline may be driven by a regulatory deadline or product release target. A real threat actor's timeline may be driven by a race against the target's incident response team trying to contain the breach. The same tool can be used for good and evil, which has been true since the stone age.

The simple hammer can build or destroy. The hands control the hammer, not the other way around.

So what makes an offensive tool "good" for folks who are looking to make systems stronger? Firstly, the tool that does the job. Security engineers are not a trusting bunch; we don't like speculation, we like seeing hard evidence. We don't have to like the command line syntax or the look of the UI as long as we get new shells or a local copy of the target web app's database.

While a lot of professional pentesting leverages automation, many vulnerabilities can be exploited with manual tools and utilities.

The second key attribute to consider is whether the tool tells the story. Exploitation can take many forms, from extremely low level to extremely high level. The tool needs to speak to the person who is in charge of fixing the problem. Overly verbose tools can be hard to follow at best. At worst, they raise false positives that distract from the real issues. Likewise, tools that offer no context at all may be effective for malicious use - why create artifacts that help build the case against you? - but fall short of the understanding we need to build better systems. A "good" tool gives plain-language descriptions of what it is doing and how it is doing it while also generating and saving raw data that can be used to re-create the behavior from scratch with a completely different toolchain.

The tool output eventually goes into the penetration test report whether as raw data or in a screenshot. It's important that the output can effectively communicate what happened during the test and why it matters.

The last attribute we'll consider in today's post is trustworthiness (see "not a trusting bunch" above). Not every tool has to be open source, but there are huge advantages to open source tooling when it's available. To the degree that a tool can be inspected, it should be. Whether we are looking directly at source code (ideal) or profiling the behavior of a new tool in a closed lab environment, offensive security shops vet their kit since there are plenty of bad actors who would love to slip a backdoor into a PoC and piggyback off of our legitimate work for their own nefarious purposes.

Transparency provides story telling by allowing an engineer to follow the code flow, and it also provides trustworthiness by being auditable for risky behaviors.

Tools are exciting for offensive security engineers. When operated correctly, tools allow us to be efficient, effective, and safe. As a bonus, they are fun to build and sometimes fun to use. But most of all, the best tools help us be part of the solution instead of a thorn in the dev-team's side.

We have a whole host of tools that we are ready to use to help your dev team manage real-world risks. Contact sales@logichazard.com to learn more about our offensive security offerings!