Hold – Verify – Execute: Rise of malicious POCs targeting security researchers

Overview

While investigating CVE-2024-5932, a code injection vulnerability in the GiveWP WordPress plugin, our team encountered a malicious Proof of Concept (POC) targeting cybersecurity professionals.  This has become a growing threat to cybersecurity professionals from threat actors to achieve their motives, such as crypto mining, data exfiltration, and backdoor installation. We have dissected an instance we encountered and felt it important to share to help bring awareness to this problem.  While security researchers are often very well equipped to handle and detect this situation, it is easy to become overconfident, leading to compromise.

Security researchers often need to verify publicly available POCs to accomplish their various tasks, and GitHub is a hotspot for such POCs. POCs on GitHub are widely considered reliable due to their ease of accessibility and the website’s reputation. Should defenders execute a script without thoroughly vetting it? The subsequent sections will elaborate on why it is critical for researchers to be extra vigilant while leveraging such scripts. For the specific example used in this blog SonicWall has created a signature to ensure the protection of our customers IPS: 4496 XMRig Crypto Mining Activity.  It’s important to recognize the larger threat is not one specific example but the technique being used to target security researchers.

Analysis of a real-world sample

Initially, there was only a single instance of POC for CVE-2024-5932 by EQSTLab, which is a legitimate one. However, after a few hours, a couple of similar instances popped up, which looked like replicas of the original repository at first glance. The links of those repositories (taken down at the moment) are as follows.

http[s]://github[.]com/niktoproject/CVE-2024-5932 (malicious repo)

http[s]://github[.]com/sqlmap-projects/CVE-2024-5932 (malicious repo)

A screenshot of one of the instances can be seen in Figure 1.

Figure 1 Screengrab of the malicious poc repository

Although such instances are not unusual, we decided to dig into them out of curiosity. It unveiled the addition of a discreet malicious code in the script, as seen in Figure 2.

Figure 2 Evil code from poc script

This malicious code is executed when the script is run for the first time by the victim and performs the following tasks.

1. Clones the specified malicious script from the repository (http[s]://github[.]com/niktoproject/c/blob/main/c[.]sh – malicious), which contains crypto mining code.
2. Makes the script executable and runs it
3. Deletes the script.

The cloned malicious script that uses XMRig miner to mine Monero can be seen in Figure 3.

Figure 3 Crypto mining code

The above code performs the following tasks.

1. Downloads the miner and save the executable file into a hidden directory and a hidden file at /home/<user_name>/.xconfig/.x path.
2. Collects information of the machine resources, such as RAM and CPU, to use as a unique identifier.
3. Creates a cronjob to make sure the mining process persists across reboots.
4. Cleans temporary files to evade suspicion.
5. Execute the miner.

Indicators of compromise (IOCs)

If someone has (accidentally) executed the malicious script, it can be identified using the indicators below.

1.Look for the process named “.x”, which consumes the maximum resources, as seen in Figure 4.

Figure 4 Crypto mining process

2.Check the cronjob list to see if the malicious cronjob is created.

3.Observe the outgoing network connections going on the specified port in the script, as seen in Figure 5.

Figure 5 Network connection originated by mining process

Steps to remove the miner

The below steps can be followed to remove the miner.

1. Kill the process “.x” shown in Figure 4.
2. Delete the miner executable from /home/<user_name>/.xconfig/.x
3. Remove the cronjob.

Best practices

Following are some established practices that can aid researchers in improving their security posture.

1. Always use isolated VMs and networks to do research or work.
2. Execute but verify! Run scripts only after vetting them thoroughly.
3. Never use the host machine to test anything.
4. Check the “Issues” section of the suspected repository. Some good souls may likely have warned the users.

Flagging on social media

Some researchers also flagged this issue on the social media platform “X,” as seen in the links below.

https://x.com/win3zz/status/1828704644987511107

https://x.com/nav1n0x/status/1828715567785636112

Conclusion

Although researchers will undoubtedly need to use public POCs, their execution ought to be done with utmost caution to avoid dire consequences and severe attacks such as ransomware, data exfiltration, spoofing, and botnets.

MITRE ATT&CK Mapping

Figure 6 MITRE ATT&CK mapping