GitHub proofs of concept (PoCs) for known vulnerabilities could themselves contain malware as often as 10% of the time, security researchers have found.
Researchers at the Leiden Institute of Advanced Computer Science have alerted security professionals about risks associated with GitHub and other platforms like pastebin that host public PoCs of exploits for known vulnerabilities.
While such PoCs are usually meant for educational purposes only, researchers found that 4,893 repositories out of 47,300 examined “have symptoms of malicious content,” which represents a bit more than 10% of all PoCs analyzed.
These “proofs” advertised exploits for vulnerabilities that have been publicly disclosed between 2017 and 2021.
See the Top Vulnerability Management Tools
Signs of Malicious PoCs
To determine whether the repository is malicious or not, researchers used specific criteria:
- they checked whether the PoC’s publisher IP is in popular blocklists such VT or AbuseIPDB
- they checked whether the hash of the provided binary and exec got flagged by Virus Total
- they analyzed obfuscated code (hexadecimal, base64).
They discovered info-stealers disguised as legitimate PoCs, obfuscated Python script in PowerShell commands, and inactive malicious components that could be activated by the author.
Some repositories seem to contain RATs (Remote Access Trojans) such as Houdini, or unexpected requests to command and control (C&C) servers (e.g., Cobalt Strike).
Also read: Cybersecurity Agencies Release Guidance for PowerShell Security
Hijacking Legitimate Tools
Cybercriminals diverting legitimate tools to fool unwise testers is nothing new, and I’ve found that out in my own work.
I created a repository some time ago that demonstrates how easy it is to fool beginners in cybersecurity. The code does not contain any malicious code like external requests, but it would have been easy to add, especially in Python.
Black hat hackers sometimes use GitHub and similar services to host malware, as it allows them to evade most detection tools. It’s a known tactic that is hard to offset, as many teams use the same platforms for legitimate purposes.
However, running code blindly without knowing what it does is the very definition of a script kiddie. The problem is that security professionals can be tempted to act recklessly in an effort to speed up their operations.
How to Avoid Malicious PoCs
The obvious but still valuable recommendation is to check any code before running it on your machine, especially when it’s for an exploit kit or ransomware.
If the code is too obfuscated, it’s a warning sign. Of course, obfuscation is often mandatory when building exploit code, but testers should take the time to deobfuscate it and understand what it does exactly.
Leverage powerful platforms such as Virus Total and other databases to check your samples and executables.
In addition to this, testers should absolutely get an isolated environment. It’s way easier these days to build a lab, for example using a virtual machine and a dedicated operating system like Kali Linux.
Most security experts recommend using separate environments for sensitive activities and daily tasks.
Of course, your machine will likely use the same network for external calls, so ensure you don’t use your real IP (e.g., by using a VPN) and you don’t share too many permissions and folders between the virtual machine and your default system.
Having a dedicated machine for sensitive operations might seem a bit expensive, but it makes sense from a security perspective.
Last but not least, if you cannot determine whether the PoC can be trusted, then ask for help or read notes by other professionals in the community. Binary analysis requires deep knowledge and the appropriate tools.
See the Best Vulnerability Scanners
