VB2020 – Advanced Pasta Threat: Mapping Malware Use of Open Source Offensive Security Tools

Paul Litvak

The term Offensive Security Tool, also known as OST, is a controversial subject within the InfoSec community. It often sparks fierce debate with both sides of the argument weighing in on how the uncontrolled publication of offensive security capabilities should be treated.

On one side of the argument, typically held by more defense-oriented people, the free publication of OSTs is detrimental because it arms adversaries with free offensive capabilities and misses opportunities to exact development costs from threat actors.

The other side of the debate believes it’s important for OST projects to be released publically as they can help promote security by educating defenders, supplying penetration testers with up-to-date tools, and help bring new talent into the industry, one that is already suffering from a shortage of trained professionals.

While this debate has been ongoing for years now, very few evidence actually exists to support either viewpoint. One thing that is for certain, is more and more threat actors are outsourcing their offensive capabilities into open-source OST projects:

pasted image 0 6

In a research study conducted by yours truly, I sought to add more data to the conversation, aiming to make it a more productive discussion.

First, I created a central map to track threat actor adoption of open source Offensive Security Tools. I populated it with new, previously unknown connections identified through code reuse, with an emphasis on open source Offensive Security Libraries that are typically embedded into larger tools and aren’t previously mentioned by vendor reports. I invite you to add new connections via our corresponding GitHub repository.

pasted image 0 5

I found numerous new connections by building a tool (now available on GitHub!) that compiles dozens of OST libraries into all possible code patterns and searches for those patterns in Intezer’s Genome Database to detect code reuse prevalent among specific threat actors:

pasted image 0 2

Putting discussions of ethical considerations of OSTs to the side, I focused my research on how we can use the trend of increasing OST adoption to create code-based YARA signatures to target malware adopting Open Source OST libraries:

pasted image 0 3

This part is also covered partially in a previous Intezer article.

Last but not least, this research will be covered in depth during my pre-recorded Virus Bulletin talk, which is available on demand from September 30. Registration is free and I invite you to join the discussion. The full research report which will be made available via Intezer’s website following the conclusion of the conference.

Paul Litvak

Paul is a malware analyst and reverse engineer at Intezer. He previously served as a developer in the Israel Defense Force (IDF) Intelligence Corps for three years.

In this article

Share this article
Recommended Blogs
blog cover for when to use generic AI for your SOC
7MIN READ

Generalist AI for your SOC: When and where to use it

Many security leader are asking the same question right now. We already pay for Microsoft Copilot, ChatGPT Enterprise, or Claude. Why buy anything else? Here's what you need to know.
ASL@Nasdaq blog post cover
5MIN READ

AI SOC Live at Nasdaq: Real conversation about modern security operations

The SOC is broken. Not because of a lack of talent or effort, but because human capacity does not scale. At AI SOC Live NASDAQ, we are bringing together the security leaders who are doing something about it.
blog cover for AI SOC: When to buy and when to DIY
5MIN READ

AI SOC: When to buy and when to DIY

The question worth asking isn't "build or buy?" It's a more precise one. Which parts of this problem are worth your engineers' time, and which parts aren't?