How Attackers Leverage Pentesting Tools in the Wild
Pentesting tools have been used in malware attacks by adversaries who take advantage of publicly available tools. In this two-part blog series we will be discussing in depth the use of pentesting tools in malware. In this first post, we will go over the changing security landscape, controversies, challenges, and detection approach.
What are pentesting tools?
Penetration testing, commonly known as pentesting, provides an organization a detailed view of its security posture by simulating attacks that are conducted by real world adversaries. It realistically highlights the weaknesses that could lead to security incidents and demonstrates actual risks to the organization. The tools that are used to exploit these loopholes and vulnerabilities are known as pentesting tools.
These tools are written by security researchers, pentesters and other professionals to automate the process, increase the testing efficiency and discover the loopholes that might be hard to find through manual testing. For example, it’s hard to imagine probing a network or a machine without a port scanning tool, yet security professionals need to check for open ports in the organization.
The double-edged sword
Oftentimes you will see an argument whether these tools should be published online and if yes, should there be mechanisms released by the authors to detect and fingerprint these tools. Penetration testers want to collaborate with open source communities to find vulnerabilities and defend the corporate environment but at the same time their tools can be used by some of the most notable threat actors.
Pentesting tools provide a platform for the defender to test the capability of their environment. Instead of learning a new attack technique, the public release of these tools allows defenders to take advantage and prepare the response before an attacker uses this for a malicious purpose. On the other hand, providing ready-made tools lowers the bar for less-skilled attackers and increases the attack surface; for example, one of the popular pentesting tools Cobalt Strike was released in 2012 but has become one of the most common second stage payloads for the malware (Reference 1). Although released for security professionals to emulate targeted attacks, it is now commonly used by some of the most famous advanced persistent threats (APTs) across the globe.
There is no obvious winner in the argument above, but one thing that’s clear is that there is little to no effort and costs required in this process. As a result, the adversaries lean toward using the open source tools as it gives them a good head start in their threat campaign.
White hat tools going darker
In recent years, we have seen an exponential rise in the use of penetration testing tools by individual attackers, nation-state actors, and some of the major APT groups. Of late, in addition to the legitimate use of these tools for internal pentesting, they are being utilized in active malware and threat campaigns all over the world.
We have seen several malware families and vulnerabilities released recently using a modified version of a publicly available tool and in some cases simply the tool itself. You may have heard of these names in the news or probably dealt with them in recent threat hunting sessions. If you have never heard of these tools, malware or vulnerabilities, you can read about them in this blog series.
Some of the more recent and prominent pentesting tools used by malware include:
- Darkside Ransomware – BloodHound/SharpHound, Mimikatz, Powerview, PSexec (Windows Utility – modified version usage)
- Hafnium Exchange Server Vulnerability – Nishang, Powercat, Procdump, Covenant
- Trickbot – PowerShell Empire, Metasploit, Cobalt Strike, Mimikatz, Lazagne, Bloodhound, AdFind
- Emotet – Second/Third stage malware delivery via Ryuk Ransomware – Mimikatz
- Solaris Zero-Day Attack– Mimikatz, Powersploit, Responder, Procdump, Crackmapexec, Poshc2
- Lockbit Ransomware – Crackmapexec
The above list is not exhaustive but the one thing common among all the attacks is the heavy usage of open source pentesting tools.
The current state of detection
Now we are clear on the usage of these tools, we want to reflect on the current state of detection. There is a way to detect these malware campaigns by detecting the IoCs and commands. For instance if you see a process name as Mimikatz or the same hash as Mimikatz, trigger the Mimikatz rule. Though it can provide a certain degree of protection but whether it is a good or bad detection, we will leave this for you to decide. It is important for an organization to see and be alerted for any behavior from a tool like Mimikatz. The goal is to catch the behavior of Mimikatz and not the only command or a similar process name that was seen in this particular campaign. This ensures that the analyst is equipped to make their choice in doing the triage and starting the incident response process on it.
The reason for this approach is that you might detect Mimikatz in your environment for that particular incident but attackers are getting smarter and modifying these open source pentesting (Reference 2) tools according to their needs to evade detection. A better strategy is to detect the core behavior of these tools rather than the tools themselves for better coverage.
A hybrid approach
A static rule approach provides good true-positive results, but may be blind to small variations in the attack method. A pure anomaly detection method can pick up on suspicious behavior, but without context those triggers can be dismissed as benign or simply ignored. A hybrid approach leverages anomaly detection capabilities and injects them with expert knowledge to increase fidelity and be able to detect these attacks using broader strokes. With a hybrid behavior-based approach, we always ask these set of questions:
- What is this tool used for?
- Is this accessing a file/folder that it isn’t supposed to?
- Is this creating a new service or a new registry for persistence?
- Do you see an abnormal amount of network traffic pattern for the user or the asset?
- Have I seen this tool first/abnormal time for a user or an asset?
All these questions help stitch the attack pattern for these tools and map out behavior for the user or entity. With the need for regular upgrades, these behavior-based detection patterns also require a review at regular intervals as adversaries are getting smarter and stealthier. We will talk about some of the pentesting tool modifications we have seen recently in our next blog.
The ease of access to these penetration testing tools makes the job more challenging for the analysts but at the same time helps them understand the attack surface better and be more prepared. Many organizations develop their own in-house red team tools but it is important for them to monitor the usage of these tools continuously as they could be leveraged and exploited by the adversaries. Red team engagements provide a great opportunity for a company to find the weakness in their infrastructure and it is equally important for a blue team to detect these red team exercises and tools to keep pace with their counterparts.
In part two of this series, we will dive deep into the detection of some of the common penetration testing tools and how to hunt and map the attack timeline.