How I learned to stop worrying and love ‘grey hat’ tools

A comprehensive security solution needs a sense of subtlety: not all machine code lends itself to be classified easily as malicious. As with most things in life, there’s a grey area in malware detection that includes hacking tools, poorly designed or easily exploitable applications, or borderline adware that provides little benefit to the unfortunate user of the machine running it.

Many applications that fall into this grey area don’t directly cause harm to a system or user, but the mere presence of these files on a computer can weaken the overall security posture, which can facilitate other attacks. Some tools open additional communication sockets, provide unintended backdoors, or make it easier for someone with malicious intent to download and execute modules from untrusted sources, or introduce new exploitable software bugs.

Many anti-virus solutions warn users when they detect files that fall into this grey area. Sometimes, your security software may allow you to suppress the detection if an admin determines the associated risk acceptable.

In this post we are looking at a more specific subset of tools within this grey area.

What are grey hat tools?

Grey hat tools are software kits often used by penetration testers and red teams to generate attacks with benign payloads, for the purposes of testing computer and network security.

The majority of grey hat tools attempt to obfuscate a given executable, shellcode, or scripting language payload for the purposes of evading detection by anti-virus software.

Other grey hat tools may provide library code containing common exploitation methods, keylogging, anti-debugging techniques, or code to detect the presence of a sandbox, virtual environment, or instruction emulation.

Some tools simply help with facilitating communication to a command and control server, by providing a framework for client-server communication with a given attack target.

Most of these kits are freely available, and published on community source control repositories like GitHub and SourceForge. Other kits are commercially available for a price and marketed to professional pentesters with the same intended use of conducting security audits. These types of tools often include disclaimers about how the code should only be used for testing computer or network security, by someone authorized to perform that task by the owner of the computer or network, and that the authors takes no responsibility for any potential unlawful uses of their creation.

These tools are adopted by criminals as well

Of course, there’s no way to prevent criminal users, with nefarious intentions, from using these kits to produce or enable malware. While a lot of mediocre malware may use these grey hat tools unmodified, “out of the box,” the more creative malware authors will often further modify a given grey hat tool in attempt to further expand its capabilities or make it more difficult for security software to detect.

These types of users generally have little respect for the various license agreements, intellectual property laws, or the aforementioned requests from the author not to use their software for illegal purposes. Your license agreement ends here.

We aim to stop these payloads as well as we do with malware

It’s pretty important that computer security solutions protect systems from the attacks these tools facilitate, because they get used in a lot of attacks. It’s also increasingly important for security products not only to identify the specific attacks employed by the original tool kit, but also to develop more comprehensive detection that can generically identify the methods or techniques used in the attack chain. That way, an analyst can build a way to detect the variations of the methods that inevitably follow, once criminals begin using a given grey hat tool.

Core grey hat tools

In our efforts to track the usage of grey hat tools, we found that the majority of grey hat tools employ one of the very few core tools to generate the initial shellcode, payload, or component that would then be further processed by a secondary tool. This creates a dependency chain in which tool A is a prerequisite for tool B.

Some grey hat tools install an entire suite of other grey hat tools for the purpose of chaining various methods together or layering different types of code obfuscation. These common prerequisite components we call core tools.

The following chart shows the three most popular core tools we followed in 2019 and the percentage of core tool detections in customer environments containing signature elements of having been generated with or inspired by that tool.

Metasploit

Of the core tools, various components that originated as part of the Metasploit framework are, by far, the most common tool in the grey hat toolbox, used in 73% of the incidents in which we detected and interdicted the use of any kind of grey hat tool during an infection. Perhaps it would be better to characterize them as Metasploit-inspired tools, as the numbers for core tools also include samples that contain a core tool payload, or connect to a core tool C2 server. Not all the things we identified as part of the Metasploit Framework are ‘vanilla’ Metasploit – some just contain Metasplot components.

Some of the reasons for its popularity are:

• It is freely available, and pre-installed, in Kali Linux distributions.
• It contains SDK like component (MSFVenom) that can be called by other tools to facilitate the generation of customized shellcode.
• It contains a modular Meterpeter component that can be packaged into other tools, and allow attackers to use Metaspoit itself as a C2 server.

Cobalt Strike

Cobalt Strike is the third most popular core tool with many of similar features to Metasploit. We see Cobalt’s components used in real-world malware as well, but because it is not open source and sold only to the pen-testing community directly, it may be more difficult for grey hat tool publishers to employ its components in derivative works.

We do see Cobalt’s components used in the real-world attacks. Some examples of this include the MegaCortex ransomware which contains a beacon which is used to connect back to a Cobalt Strike server with a reverse shell.

These types of reverse shell connections to the victim machine are common with many Grey hat tools. Attackers use the tool’s ability to remotely access a system in situations where the target resides behind NAT gateways and firewalls (which, to be fair, is most of them).

This connection can also be established using only a small block of shellcode (often less than 100 bytes in size).

The Snatch ransomware is another real-world example of malware using a grey hat tool component in a malicious attack.  Like MegaCortex, Snatch also uses Cobalt Strike to facilitate a reverse shell connection to the target system. Once the reverse shell connection has connected back to a Cobalt Strike listener the attacker can use Cobalt Strike to remotely control the infected system.

PowerShell Empire

We consider PowerShell Empire a core tool due to it being the source of many malicious PowerShell scripting techniques used in other grey hat tools.

PowerShell Empire is not necessarily used in the same way as many of the other tools. The attack framework contains a large collection of template methods that are copied and used in other tools. Although PowerShell Empire may not have initial been the initial origin for all the script sources that it contains, we still consider it a core tool due to its popularity in the communities.

Secondary stage and less popular grey hat tools

Many grey hat tools use payloads or listeners from the core tools above. The following chart includes detections for secondary stage grey hat tools as well.

Secondary stage tools often incorporate shellcode or other components generated by one of the core tools, but will add other layers of obfuscation or functionality.

It is important to note that, in some cases, attackers use more than one tool. This can cause some inaccuracies in our tracking, as we only associate the sample with the kit features that were used in the last layer of processing in the build chain.

The following charts show both the core tools and secondary stage tool detections we have seen in all of 2019

It is often difficult to determine what percentage of the detections are internal security audits as opposed to a malicious attack in these numbers.  When we look at the detections over time, we see audits being conducted in close time proximity, with the same tool(s) and in the same network or customer environment.

Often, significant spikes in detections can be indicative of penetration testers conducting audits. But that can vary between toolkits. Some are more popular in the malware authoring community, while others are more popular with red teams

Moving forward

Understanding the usage of grey hat tool in both the penetration testing communities and the adaptations of these tools as used in malware helps us better understand trends in the threat landscape.

It also helps us better predict what new methods and payloads that are likely to be popular in the future.

Moving into 2020 we expect the use of powershell evasion techniques to remain popular as well as using WMI and other unconventional methods of achieving persistence. We also expect to see new and improved methods for encoding shellcode payloads as well as attempts to evade in-memory detection of the various C2 call-back agents.

Acknowledgments

The author would like to thank fellow researchers Andrew O’Donnell and Gabor Szappanos for their contributions to this research.