{
	"id": "6986bc94-02e8-4685-a8b3-3fa6cae98109",
	"created_at": "2026-05-05T02:45:30.794841Z",
	"updated_at": "2026-05-05T02:46:36.72459Z",
	"deleted_at": null,
	"sha1_hash": "cfa1b91e1d42cd6d86d703f1f4ccf1e27b00340d",
	"title": "Storm clouds on the horizon: Resurgence of TeamTNT? | Group-IB Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2104553,
	"plain_text": "Storm clouds on the horizon: Resurgence of TeamTNT? | Group-IB Blog\r\nArchived: 2026-05-05 02:03:17 UTC\r\nIntroduction\r\nIn the past few decades, we have witnessed significant advancements in the IT landscape. Automation,\r\ncompliance, security, and development have all experienced a resurgence due to the advent of new solutions that\r\nhave simplified and improved the daily operations of sysadmins, and for companies that run their businesses\r\nonline.\r\nThe most prominent cloud services— such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud,\r\nAlibaba Cloud—offer an exceptional opportunity for businesses to create and deploy new public services almost\r\ninstantly with a few clicks.\r\nWithin this landscape, Docker and Kubernetes introduced a new paradigm of microservice architecture, enabling\r\nthe creation and implementation of complex solutions through smaller, modular components. This approach\r\navoids the pitfalls of large applications, and provides developers an environment where they could deploy and\r\nmaintain their code quickly, safely, and efficiently.\r\nHowever, as is often the case, even the best ideas come with unintended drawbacks.. As any security expert\r\nknows, the principle of 100% security is just a chimaera, it is just something that can be imagined but never\r\nachieved because an attacker will always find a way to open a breach, or find a bug or an exploitable vulnerability\r\nto use to access a particular asset.\r\nThe cloud has become the new frontier of compromise for threat actors to gain covert access to their victims’\r\npublic resources, allowing them to amplify their impact and reach.\r\nTo preface our research, we have to look back to 2019, when a new threat actor initiated a covert, long-term\r\ncampaign targeting vulnerable public instances of Redis, Kubernetes and Docker. This then-unknown adversary\r\ndeployed homebrewed malware using a comprehensive toolkit of shell scripts and malicious binaries, aimed at\r\nstealing credentials, to installing backdoors, to mining cryptocurrencies, and hunting for new victims.\r\nOver the years this threat actor evolved and improved its capabilities, developing new tools and targeting an\r\nincreasing number of victims while operating in the shadows. But in 2022, the adversary abruptly vanished,\r\nabandoning their social media profiles and websites.\r\nWe are talking about the infamous threat actor, TeamTNT.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 1 of 15\n\nFigure 1. [Left] A screenshot of TeamTNT’s GitHub profile, and [Right] A screenshot of TeamTNT’’s X (formerly\r\nTwitter) account.\r\nBased on the investigations conducted by our Digital Forensics and Incident Response (DFIR) analysts we\r\nidentified various traces of matching tactics, techniques, and procedures (TTPs) used by TeamTNT in campaigns\r\nperpetrated in 2023, and campaigns still ongoing in 2024, which we will elaborate in this blog.\r\nNo, we’re not referring to the well-known group of mappers who created and shared various free level maps for\r\nDoom. Instead, we’re discussing a threat actor known for its initial malicious campaign, which likely originated in\r\nGermany. The only connection to the mappers is their shared name; aside from that, there is no relation between\r\nthe two groups.\r\nKey discoveries in the blog\r\nTeamTNT’s ongoing campaigns target VPS cloud infrastructures on CentOS, beginning with SSH brute\r\nforce attacks and malicious script uploads.\r\nThe malicious script disables security features, deletes logs, and modifies system files while searching for\r\nexisting miners.\r\nIt kills cryptocurrency mining processes, removes Docker containers, and updates DNS settings to\r\nGoogle’s servers.\r\nThe script installs the Diamorphine rootkit for stealth and root privileges, and uses custom tools to\r\nmaintain persistence and control.\r\nIt locks down the system by modifying file attributes, creating a backdoor user with root access, and\r\nerasing command history to hide its activities.\r\nWho may find this article interesting:\r\nCybersecurity analysts and corporate security teams\r\nMalware analysts\r\nThreat Intelligence specialists\r\nCyber investigators\r\nComputer Emergency Response Teams\r\nLaw enforcement investigators\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 2 of 15\n\nCyber Police Forces\r\nEmergence of a New Campaign\r\nGroup-IB’s DFIR team identified clear evidence of a new campaign impacting VPS cloud infrastructures based on\r\nCentOS operating systems.\r\nThe investigation revealed that the initial access was accomplished via a Secure Shell (SSH) brute force attack on\r\nthe victim’s assets, during which the threat actor uploaded a malicious script.\r\nOur DFIR experts analyzed the script, which, once executed, checks if the host has already been compromised by\r\nsearching for traces of logs generated by other miners.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 3 of 15\n\nFigure 2. Checking miner existence\r\nModifications to System Security\r\nEssentially, in the first lines of the script, it checks the presence of the log file named xmrig.log, within the folder\r\netc/.system/rtm/. If the file exists, it verifies that the file was written within the last 600 seconds; if both these\r\nconditions are met the script quits immediately.\r\nAfter the execution, the script implements several changes affecting the security configuration of the system,\r\nincluding:\r\nDisabling the firewall (iptables and UFW)\r\nDisabling NMI Watchdog\r\nDeleting the folder /var/log/syslog\r\nChanging the attributes of folders like /tmp, /var/tmp and /root/.ssh\r\nChanging the attributes of the file /root/.ssh/authorized_keys\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 4 of 15\n\nFigure 3. Disabling security settings\r\nNext, the script searches for a daemon related to the cloud provider Alibaba, named aliyun.service. If it detects this\r\ndaemon, it downloads a bash script from update.aegis.aliyun.com to uninstall the service.\r\nFigure 4. Disabling daemons\r\nAfter removing the daemon, it proceeds to disable SELINUX and AppArmor.\r\nFigure 5. Disabling AppArmor and SELINUX\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 5 of 15\n\nOnce SELINUX and AppArmor have been disabled, the script looks for all the cryptocurrency mining processes\r\nand it kills them.\r\nFigure 6. Example of commands to kill coin miners processes\r\nThe list of commands includes a long list of signatures including strings, service ports, IP addresses, paths, process\r\nnames, email accounts, usernames, domains, and file IDs. These signatures are used by the script for hunting and\r\nidentifying as many processes related to coin miners as possible.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 6 of 15\n\nFigure 7. Screenshot of commands executed to remove traces left by other miners\r\nThe script also interacts with Docker, invoking it to terminate containerized processes and remove images\r\nassociated with any coin miner previously implanted by a threat actor.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 7 of 15\n\nFigure 8. Screenshot of commands executed to remove any miner running via docker\r\nIt then changes the attributes of /etc/resolv.conf and adds the IP addresses of Google DNS servers.\r\nFigure 9. Screenshot of dns configuration change\r\nThese lines also contain a custom tool developed by the threat actor named “tntrecht”, which is loaded into\r\n/usr/local/bin/tntrecht within the compromised host. This tool has been observed during the threat actor attacks to\r\nmodify the permissions of legitimate processes, which then are renamed by adding the “tnt” prefix, for example,\r\ntntcurl and tntwget.\r\nEstablishing Persistence\r\nAfter completing these tasks, the script changes the attributes of /var/spool/cron, /etc/crontab, /etc/cron.d and\r\n/var/spool/cron/crontabs again with the custom ‘tntrecht’ tool.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 8 of 15\n\nFigure 10. Screenshot of commands executed to set persistence via crontab\r\nIt cleans up the crontab jobs and then implants the malicious code into the crontab to ensure persistence and\r\nlockdown.\r\nFigure 11. Screenshot of the cron job configuration\r\nTo ensure payload persistence, the script adds a cron job that downloads a copy of the patload every 30 minutes\r\nfrom the command-and-control (C2) server with IP address 65.108.48.150, where it is hosted.\r\nThe crontab file is timestamped 2018-05-15, likely as a time-stomping attempt to deceive security analysts who\r\ncould look for a recent creation of malicious files.\r\nFigure 12. Screenshot of the command to change the timestamp as explained in the previous lines.\r\nDeploying Diamorphine\r\nAt this point, the script checks whether the user is root, and if the condition is satisfied it creates the new folder\r\n/var/tmp/…/dia/ where a base64 encoded payload is copied as dia.tar.gz and then uncompressed.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 9 of 15\n\nFigure 13. Screenshots of commands used to deliver the encoded payload\r\nWithin this new folder will contain three files:\r\ndiamorphine.c,\r\ndiamorphine.h\r\nMakefile\r\nThese files have been identified as the source code of a rootkit named Diamorphine, which was found by our\r\nDFIR experts within the GitHub repository https[:]//github[.]com/m0nad/Diamorphine.\r\nFigure 14. Screenshot of the description of Diamorphine on the GitHub repository\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 10 of 15\n\nOur analysts found no difference between the source code published on GitHub and the same payload embedded\r\nin this script, indicating that the attacker did not modify the source code.\r\nThe rootkit source files are compiled to create a new kernel object diamorphine.ko, which is loaded as a kernel\r\nmodule through the insmod command.\r\nFigure 15. Screenshot of the diamorphine kernel module loading\r\nDiamorphine is a loadable kernel module (LKM) rootkit for Linux kernels, which has recently been observed in\r\nthe wild also by other security researchers.\r\nOnce loaded as a kernel module with higher privileges, it allows the attacker to covertly execute  malicious\r\nactivities on the compromised host.\r\nKey features of the rootkit include:\r\nSilent execution as a hidden module.\r\nThe ability to hide/unhide any process by sending a signal 31.\r\nIt becomes a (in)visible module by sending a signal 63(to any pid).\r\nIt allows any user to become root by sending a signal 64(to any pid.\r\nFiles or directories starting with the MAGIC_PREFIX become invisible.\r\nLocking Down the System\r\nAt this point, the threat actor has essentially accomplished the typical  tasks associated with compromising and\r\nremotely controlling a victim’s asset. TeamTNT went beyond mere compromise by actively blocking any recovery\r\nattempts made by the system’s owner.\r\nSpecifically, the script executes the command chattr to lock and unlock various file attributes, in particular write\r\nand execute permissions. It then executes the ‘tntrecht’ tool to disable the execution of chattr, preventing the\r\nsystem administrator from unlocking the protected files and hindering any recovery efforts.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 11 of 15\n\nFigure 16. Screenshot of commands used to lock the system\r\nThe threat actor secures their control over the system by locking it down, preventing the administrator from even\r\nrebooting, powering off, or also recovering access to the system.\r\nFinally, the script initiates the installation of a backdoor account and an authorization key to allow the attacker to\r\nsecurely access the system via SSH.\r\nThe threat actor creates a new user named hilde—used also on Github as we have previously seen in this article\r\n(Figure 1)—and adds it to the group ‘sudoer’ group, granting root privileges for executing commands with sudo.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 12 of 15\n\nFigure 17. Screenshot of changes implemented on ssh service.\r\nThe configuration also includes the use of a public key (detailed below), which the threat actor hasadded within\r\nthe authorized_keys files related to the aforementioned user and related to the root user.This method ensures\r\npersistence and opportunity to access the system.\r\nLeave No Trace Behind\r\nThe threat actor leaves nothing to chance; indeed, the script implements various changes within the SSH and\r\nfirewall service configuration:\r\nSSH port set to 11222\r\nAuthentication via public key\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 13 of 15\n\nFirewall rule to allow inbound connections towards 11222/TCP port\r\nFigure 18. Screenshot of ssh configuration changes\r\nFinally, to eliminate any traces of their activities, the script clears the entire bash history by executing the history -\r\nc command, erasing all records of previously executed commands.\r\nFigure 19. Screenshot of the command used to delete the bash history.\r\nConclusion\r\nThe entire analysis underscoresTeamTNT advanced skills in automating their attacks and considering every single\r\naspect and detail, from the initial access to preventing recovery attempts, aiming to inflict significant damage on\r\nthe victim.\r\nWhile we cannot definitively confirm that TeamTNT is behind this attack, recent observations and analysis of\r\ntactics, techniques, and procedures (TTPs) lead our DFIR experts to attribute this attack to them with moderate\r\nconfidence.\r\nWe will continue with our research to uncover any additional traces left by this threat actor, and update this blog\r\nwith new information.\r\nRecommendations\r\nThe Group-IB DFIR team recommends hardening any publicly accessible cloud instance and implementing\r\nseveral key security countermeasures, including:\r\nApply the latest security patches and updates.\r\nConfigure the firewall to allow only essential services.\r\nChange the default SSH port to a higher number, such as 10000 or beyond, to avoid common scanning\r\nranges (1-1024) used by threat actors.\r\nSet up SSH to use key-based authentication exclusively, which helps prevent brute-force attacks, as\r\nattackers are likely to abandon attempts when faced with non-standard authentication methods.\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 14 of 15\n\nRestrict SSH access to a select set of IP addresses through the firewall.\r\nInstall and activate Fail2Ban to automatically block brute-force attempts.\r\nEnable and configure SELinux and AppArmor for enhanced security.\r\nInstall and configure Auditd with DISA-STIG recommended rules to monitor changes to system files.\r\nDisable root login and ensure that only the root user has UID 0.\r\nLock the root account to prevent unauthorized access.\r\nRestrict permissions related to cron jobs to minimize security risks.\r\nRestrict system settings to limit potential vulnerabilities.\r\nInstall and enable PSAD to enhance intrusion detection.\r\nInstall and enable AIDE for file integrity monitoring.\r\nLimit sudo access to authorized users only.\r\nInstall and enable rkhunter to detect rootkits and other malicious software.\r\nIOCs\r\n65.108.48.150\r\n/etc/.system/rtm/xmrig.log\r\n/var/tmp/…/dia\r\n/var/tmp/…/dia/diamorphine.ko\r\n/usr/bin/tntrecht\r\n/var/tmp/.alsp\r\nSource: https://www.group-ib.com/blog/teamtnt/\r\nhttps://www.group-ib.com/blog/teamtnt/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.group-ib.com/blog/teamtnt/"
	],
	"report_names": [
		"teamtnt"
	],
	"threat_actors": [],
	"ts_created_at": 1777949130,
	"ts_updated_at": 1777949196,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cfa1b91e1d42cd6d86d703f1f4ccf1e27b00340d.pdf",
		"text": "https://archive.orkl.eu/cfa1b91e1d42cd6d86d703f1f4ccf1e27b00340d.txt",
		"img": "https://archive.orkl.eu/cfa1b91e1d42cd6d86d703f1f4ccf1e27b00340d.jpg"
	}
}