{
	"id": "b5b2cfb5-5c6a-42ca-ade4-089c6180c37d",
	"created_at": "2026-04-06T00:06:45.4121Z",
	"updated_at": "2026-04-10T03:27:04.716744Z",
	"deleted_at": null,
	"sha1_hash": "72d4f3e80ac309aa044098d77b0237b59482aee9",
	"title": "HeadCrab: A Novel State-of-the-Art Redis Malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3543140,
	"plain_text": "HeadCrab: A Novel State-of-the-Art Redis Malware\r\nBy Asaf Eitani\r\nPublished: 2023-02-01 · Archived: 2026-04-05 15:16:21 UTC\r\nAqua Nautilus researchers discovered a new elusive and severe threat that has been infiltrating and residing on servers\r\nworldwide since early September 2021. Known as HeadCrab, this advanced threat actor utilizes a state-of-the-art, custom-made malware that is undetectable by agentless and traditional anti-virus solutions to compromise a large number of Redis\r\nservers. The HeadCrab botnet has taken control of at least 1,200 servers.\r\nThis blog will delve into the details of the HeadCrab attack, examining its methods of operation, techniques used to evade\r\ndetection, and steps organizations can take to safeguard their systems.\r\nWhat is Redis?\r\nRedis is an open-source, in-memory data structure store that can be used as a database, cache, or message broker. By default,\r\nRedis servers do not have authentication enabled and are meant to run on a secure, closed network rather than being exposed\r\nto the internet. This makes default Redis servers that are accessible from the internet vulnerable to unauthorized access and\r\ncommand execution.\r\nA Redis Cluster provides a way to run a Redis installation where data is automatically divided and stored across multiple\r\nRedis nodes. Within a cluster, there is a Master server and Slave servers, allowing for easy replication and synchronization\r\nof data.\r\nOne of the default Redis commands is SLAVEOF, which designates a server as a Slave server for another Redis server in the\r\ncluster. When a server is defined as a slave, it will synchronize with the Master server, including downloading any Redis\r\nmodules present in the Master.\r\nRedis modules are executable Shared Object files that can be used to enhance the functionality of the server in various ways.\r\nA module is loaded onto a server by uploading it and using the MODULE LOAD command through the Redis port. Redis\r\nmodules use the Redis API to perform various tasks related to server management and control such as defining custom\r\ncommands with the RedisModule_CreateCommand API.\r\nIn recent years, Redis servers have been targeted by attackers, often through misconfiguration and vulnerabilities. As Redis\r\nservers have become more popular, the frequency of attacks has increased. You can read about further attacks such as\r\nRedigo malware and TeamTNT targeting Redis servers.\r\nAttack Flow\r\nThis story begins with an attack on one of our honeypots when a threat actor targeted a Redis server. The server was\r\neventually compromised using the SLAVEOF command, setting it as a Slave server of another Redis server controlled by\r\nthe attacker. The Master Redis server then initiated a synchronization of the Slave server which in turn downloaded a\r\nmalicious Redis module, the HeadCrab malware, onto the Slave server (our honeypot). This technique has been utilized by\r\nattackers for some time and allows them to load malicious Redis modules onto affected hosts.\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 1 of 13\n\nAs depicted in the screenshot below, these are the Redis command logs obtained from our inbound network data collection.\r\nThe attacker starts by listing all available modules, configuring the server to allow for the upload of a new module, and\r\ndownloading the module to the /tmp directory.\r\nSetting the victim Redis server as a slave server\r\nOnce the module was downloaded to the /tmp directory on the victim server, it was loaded into the Redis process using the\r\nMODULE LOAD /tmp/\u003cmodule_name\u003e command. As demonstrated in the screenshot below, the attacker attempted to load\r\nmultiple modules before finally succeeding.\r\nHeadCrab malware module loading\r\n0:00 / 0:56\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 2 of 13\n\nUpon reverse-engineering the loaded module, we discovered a sophisticated, long-developed malware. It provides the\r\nattacker with numerous advanced abilities and eventually full control over the targeted server. The module introduces 8\r\ncustom commands, named with the pattern rds*, used by the attacker to carry out actions on the compromised server. A\r\ncomprehensive list of the malware’s capabilities and commands is discussed in the Technical Analysis of the HeadCrab\r\nMalware section.\r\nOur honeypot showed that the main impact of the attack was resource hijacking for cryptocurrency mining. The miner\r\nconfiguration file was extracted from memory and showed that the mining pools were mostly hosted on private legitimate IP\r\naddresses. Inspection of these IP addresses revealed that they belong to either clean hosts or a leading security company,\r\nmaking detection and attribution more difficult. One public Monero pool service was found in the configuration file but\r\nwasn’t used by the miner in runtime. The attacker’s Monero wallet showed an annual expected profit of almost 4,500 USD\r\nper worker, much higher than the typical 200 USD per worker.\r\nWe discovered not only the HeadCrab malware but also a unique method to detect its infections in Redis servers. Our\r\nmethod found approximately 1,200 actively infected servers when applied to exposed servers in the wild. The victims seem\r\nto have little in common, but the attacker seems to mainly target Redis servers and has a deep understanding and expertise in\r\nRedis modules and APIs as demonstrated by the malware.\r\nA map depicting the amount and locations of compromised Redis servers\r\nA distribution of the attacked Redis servers’ versions in the wild\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 3 of 13\n\nWe have noticed that the attacker has gone to great lengths to ensure the stealth of their attack. The malware has been\r\ndesigned to bypass volume-based scans as it runs solely in memory and is not stored on disk. Additionally, logs are deleted\r\nusing the Redis module framework and API. The attacker communicates with legitimate IP addresses, primarily other\r\ninfected servers, to evade detection and reduce the likelihood of being blacklisted by security solutions. The malware is\r\nprimarily based on Redis processes which are unlikely to be flagged as malicious. Payloads are loaded through memfd ,\r\nmemory-only files, and kernel modules are loaded directly from memory, avoiding disk writes. Our analysis has also found\r\nthat there are no detections of these binaries as malicious on Virus Total.\r\nTechnical Analysis of the HeadCrab Malware\r\nThe HeadCrab malware is a highly sophisticated and complex state-of-the-art threat. Constructed as a malicious Redis\r\nmodule framework, it boasts numerous options and capabilities. This section will outline the primary functions of the\r\nmalware as determined through our static and dynamic analysis.\r\nAs the screenshot demonstrates, the HeadCrab sample has produced no results on Virus Total\r\n(MD5=c5b992c76b7c9fa3b9bd755dd3b5af76). Despite our attempts to acquire additional samples, we were unable to find\r\nany, reinforcing our suspicions that this is a highly evasive, novel malware.\r\nVerifying that it runs only once upon execution\r\nUpon initial execution, the malware utilizes the RedisModule_OnLoad function which is triggered when the Redis server\r\nloads the module. The malware then saves the addresses of relevant Redis API functions for later use and checks if a module\r\nnamed rds is already loaded, and, if so, immediately exits without conducting any malicious actions.\r\nInitial environment scoping\r\nThe connection information that initiated the module loading is stored for future checks. In addition, the malware checks if it\r\nruns as a privileged root user or as a less privileged user named redis .\r\nPlacing emphasis on operation security (magic numbers)\r\nThe module can be loaded with 2 arguments (magic numbers) which are in fact 2 global magic numbers that are used as\r\nencryption keys and to validate that the operator of it is really the threat actor. Later, the malware can do some manipulations\r\non these magic number in various locations across its execution flow. The module can be loaded with or without the magic\r\nnumbers, and this will affect some of the functionalities during the malware execution.\r\nIf the module is loaded with the 2 arguments, some of the Redis default commands (8 commands: Module, Client, Debug,\r\nShutdown, Monitor, Slaveof, Replicaof, Config ) are being overridden by commands which mostly return errors. This is\r\ndone to avoid the malware detection. If the module isn’t loaded with the 2 arguments, this step is skipped.\r\nThe modified default commands are the following:\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 4 of 13\n\nFurthermore, the malware deletes the Redis log file and empties it if it was recreated by truncating it to size 0.\r\nMaking preparations\r\nSome inspections are made by the malware to decide on the course of action. We will not get into the detail of these\r\ninspections, but for instance /testing path and the execution date are inspected and based on that some of the\r\nfunctionalities are being executed or not.\r\nThe signal handling functions were replaced and used by the malware to communicate with its child processes.\r\nHidden code execution\r\nThe malware locates the path to the dynamic loader so it can execute processes. The dynamic loader can be used to execute\r\nprocess under its name by simply providing a path to the wanted executable as an argument. This can be used to bypass\r\nsecurity solution which detect malicious files based on examining processes execution. Since the dynamic loader is a\r\nlegitimate binary, it won’t be marked as malicious, and malware can hide itself from these security solutions.\r\nExecution from memory\r\nThe malware tries to create a fileless file with the help of memfd_create syscall. If it succeeds, it creates 10 memfd or\r\ntemp files and saves them for later usage.\r\nEmphasis to execution in containers\r\nThe malware checks if the process ID is below 31. We speculate that this is done to detect whether the service is running in a\r\ncontainer. If the malware doesn’t run on a container several service management programs like systemd, initd, upstart and\r\nmore are checked. If any of them are installed, they are marked and will later be used to place persistent services and scripts\r\nin the appropriate location. We assume the malware skips this step on containers as it will be ineffective.\r\nCreating new Redis commands\r\nThe malware then creates new Redis commands, which are used to enable the threat actor to operate the malware:\r\n1. rdsa This command accepts two arguments. One is a path to Redis config file and the second is a path to a malicious\r\nRedis module. This function adds a line to the Redis config that loads the malicious module with magic numbers. In\r\norder to gain further persistence for the malware, it obscures the loadmodule command output. This command is\r\nused to load the malicious module and by adding padding to the output printed to screen it hides its activity.\r\n2. rdss Executes a command with popen and returns the process output as the command output\r\n3. rdsp Replaces the default commands with malicious functions to evade detection.\r\n4. rdsi Updates the magic numbers used in encryption and empty logs by truncating them.\r\n5. rdsm  MONITOR is a Redis debugging command that streams back every command processed by the Redis server. It’s\r\nalso replaced by the rdsp command or loading the module with 2 arguments. This new command is responsible to\r\nrevert the change on the MONITOR command – reenabling debugging of the server.\r\n6. rdsc Listens to an incoming connection on a desired port and enables to establish an encrypted communication\r\nchannel with a C2 server. The available commands are described in detail in the appendix section below. To\r\nemphasize some of its great capabilities, the malware can create a new socket and connect it to the C2 command\r\nsocket, tunnel network to another IP address and port pair, execute shell commands, sends a file content to the C2,\r\nwrites data to an open memfd file, read content of a saved memfd file and send back to C2, load a fileless kernel\r\nmodule, and many other strong capabilities.\r\n7. rdsr Establishes an encrypted communication channel with a C2 server. Same as in rdsc above.\r\n8. rdsx Restores overridden command and restores them back to default Redis commands.\r\nIn the screenshot below you can see our simulation of some of these commands:\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 5 of 13\n\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 6 of 13\n\nAn example to default commands being overridden and restored\r\nWho is HeadCrab? Or, What is HeadCrab?\r\nThe question is why do we call the threat actor and the malware HeadCrab. The answer is simple. The threat actor left us a\r\nnote. And when we are saying “us”, we really mean US – Aqua Security. The HeadCrab threat actor left a “miniblog” inside\r\nthe malware.\r\nAs you can see in the screenshot above, the threat actor is identifying as HeadCrab, a monster from the game HalfLife which\r\nattaches itself to humans and turns them to zombies. This makes perfect sense since we’ve seen this threat zombifying Redis\r\nservers and using them to move laterally to other servers.\r\nFurthermore, the threat actor also makes a blog entry which is dedicated to the Nautilus team. Looks like he reads our blogs.\r\nThis reference is for a blog about Redigo. We recently discovered Redigo which is a novel malware that targets Redis\r\nservers. In our blog Aqua Nautilus Discovers Redigo — New Redis Backdoor Malware, we wrote that the attacker exploited\r\na vulnerability that allows escaping from the LUA sandbox and led to Remote Code Execution (CVE-2022-0543) on the\r\ntargeted server. After a further review of the newly found malware and a personal dedicated comment in the malware to\r\nAqua Security, we realized that the Redigo malware is also exploiting the master-slave technique rather than the LUA\r\nsandbox escape.\r\nThis threat actor is highly discrete, so we couldn’t find many indications to its activity in the open source. We did find one\r\nindication to the ‘pamdicks’ which appears in the “miniblog”. In a blog by Trend Micro, it is mentioned that a rootkit named\r\nnetlink is used to alter the CPU-related statistics (can hide the pamdicks process and CPU load) to hide cryptomining.\r\nAlthough this is not 100% aligned with the “miniblog”, it is most probably what the threat actor is referring to.\r\nRuntime Detection\r\nHeadCrab malware is designed to stealthily attack Redis servers whether they are running in a container or on the VM. Our\r\nRedis honeypot is protected by Aqua’s Cloud Native Detection and Response (CNDR) solution that utilizes low-level eBPF\r\nevents to detect in uses real-time malicious behavioral indicators to identify stealthy attacks such as HeadCrab malware.\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 7 of 13\n\nAs you can see in the screenshot below from our Aqua platform, the first detection shows that a new executable was dropped\r\nto /tmp path. This is the Shared Object (SO) file. Next, a detection of the SO file is injected, which is highlighted in timeline\r\nand severity.\r\nThe next detection in the timeline is the reverse shell over socket, which is created by the HeadCrab malware.\r\nLastly, we can see the XMRIG malware written and executed in-memory.\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 8 of 13\n\nAs you can see, the detections show what processes are responsible for these events which can further clarify what happened\r\nand the sequence of events. Any of these detections may indicate that something bad is happening in our Redis container or\r\nVM. But all of them together imply the gravity of this attack and depict a coherent chain of events since initial access to\r\nimpact.\r\nMapping the Attacks to the MITRE ATT\u0026CK Framework\r\nHere we map the components in the attacks described above to the corresponding techniques of the MITRE\r\nATT\u0026CK framework:\r\nSummary, Remediation, and Mitigation\r\nIn this blog, we bring to light the menace of HeadCrab, the threat actor responsible for creating an advanced malicious Redis\r\nframework. We delve into the inner workings of the malware and showcase its extensive capabilities. Our investigation has\r\nrevealed that HeadCrab’s botnet has already taken control of over 1,200 servers, all infected with this malware. It is our\r\nconviction that HeadCrab will persist in using cutting-edge techniques to penetrate servers, either through exploiting\r\nmisconfigurations or vulnerabilities.\r\nImmediate remediation for infected servers\r\nThroughout this blog, we have repeatedly emphasized the significant capabilities of the HeadCrab malware.\r\nIf your server has been compromised, it is essential to assume that your network has also been breached and to immediately\r\ninitiate your incident response protocol. This will help you to detect the extent of the breach, isolate the infected systems,\r\nand clean up the impacted environments. While it is possible to remove the malware by deleting the associated services and\r\nscripts, removing the loadmodule  from the Redis configuration, and restarting the server, the attacker still retains several\r\nabilities, including the ability to drop files, execute binaries, steal SSH keys, scan and communicate with other systems, and\r\nload kernel modules. This makes it possible for the attacker to move laterally across the network. Completely removing the\r\nattacker’s presence from the server can be a difficult task. To ensure the security of your network, we recommend saving a\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 9 of 13\n\nbackup of the Redis database to a file and migrating it to a new server that has proper authorization and traffic controls and\r\nis not directly accessible from the internet, if possible.\r\nMitigation\r\nTo mitigate risks to Redis servers, you’d like to harden the environments by assuring the Redis configuration is aligned with\r\nsecurity best practices.\r\nIn this blog the threat actor is using the “master-slave” technique to replicate the database from a remote server at his\r\ndisposal with the target server (our honeypot). This feature was originally created by Redis to improve performance and\r\ncreate redundancy but is actively used by attackers to promptly infect targets and evade detection.\r\nWe advise taking the following steps to harden your Redis servers’ security:\r\n1 – Redis is designed to be accessed by trusted clients inside trusted environments.\r\nThis means that usually, it is not a good idea to expose the Redis instance directly to the internet or, in general, to an\r\nenvironment where untrusted clients can directly access the Redis TCP port or UNIX socket.\r\n2 – Whenever you’re using Redis in the cloud, it’s better to enable protected mode for enhanced security. Protected mode\r\nensures that the database only responds to the loopback address and generates an error as a reply to all the nodes connecting\r\nfrom other IP addresses.\r\n3 – Accept communication from known hosts using the bind parameter\r\nYour Redis server will only listen to connections made to the address specified in via the bind option. This is a security\r\nmeasure that allows for dropping connections not made inside the network.\r\n4 – If the ‘slaveof’ feature is not being actively used, we strongly advise disabling it.\r\n5 – You can read further security advice in the Redis security management section or in a blog they wrote about this matter.\r\nAqua platform can help you scan your Redis configuration file for misalignment to best practice. Utilizing custom assurance\r\npolicy, you can customize a new policy to scan your Redis configuration.\r\nAs can be seen in the screenshot above, we customized 2 scan policies, which look for protection mode disabled, namely\r\nRedis allow unauthorized access to the server. Furthermore, our second policy looks for bind 0.0.0.0 which means that any\r\nIP address can connect to the Redis.\r\nWe scanned a Redis vanilla container image with a permissive configuration that allows bind 0.0.0.0 and protection is\r\ndisabled. Aqua platform detected both misconfigurations and alerted us on the issue.\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 10 of 13\n\nSome further steps can be taken to mitigate threats to your software development lifecycle in the cloud, we recommend\r\nfollowing these guidelines:\r\n•    Unknown threats and zero-days are here to stay. Even if you do everything right you can’t always protect your runtime\r\nenvironments from such attacks. Thus, you need to monitor runtime environments. Deploy the Aqua Lightning Enforcer to\r\nprotect your runtime environments. Runtime monitoring is a fundamental practice to help mitigate issues quickly and\r\nminimize disruptions. The monitoring process also applies to the runtime environment where suspicious activity can occur\r\n(e.g., download of malicious binary files).\r\n•    Scan your software supply chain. You can use open source tools such as Chain-bench designed to audit your software\r\nsupply chain stack for security compliance based on a new CIS Software Supply Chain benchmark.\r\n•    Empower your developers, DevOps and security teams with tools that scan for vulnerabilities and misconfigurations.\r\nAlong with Aqua’s tools for organizations, you can find particular open-source tools such as Trivy to scan for such\r\nvulnerabilities.\r\nThe Aqua platform scans container images with tools that rely on a constantly updated stream of threat intelligence –\r\naggregate sources of vulnerability data (CVEs, vendor advisories, and proprietary research) which ensure up-to-date, broad\r\ncoverage while minimizing false positives.\r\nAppendix: Available malicious C2 commands accepted by rdsr and rdsc\r\n0x1: kill child process and close files.\r\n0x2: create a new socket and connect it to the C2 command socket.\r\n0x4: execute a shell command with HISTFILE environment variable pointing to /dev/null. This is done to prevent saving\r\nhistory of ran commands in the shell.\r\n0x5: write data to a file in a selected offset.\r\n0x6: tunnel network to another IP address and port pair.\r\n0x7: listen to a new connection and tunnel communication back to C2 connection.\r\n0xA: sends a file content to the C2\r\n0xB: perform interactive shell hijacking or start an interactive bind shell on top of existing connection.\r\n0xC: download a .so file to /dev/shm/rupd, load and delete it.\r\n0xD: execute a shell command with HISTFILE environment variable pointing to /dev/null. This is done to prevent saving\r\nhistory of ran commands in the shell.\r\n0xE: calculate sha256 of a file and send it back to the C2 server\r\n0xF: send a signal to a process\r\n0x10: gather information about the running process and send it back to the C2 server\r\n0x14: gather system information and send it back to the C2 server\r\n0x15: change a file permissions and perform a timestomping attack, which modifies the last change time to that of a\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 11 of 13\n\nlegitimate file. This is used to avoid detection of changed files.\r\n0x16: delete a file or directory by path\r\n0x17: use the dynamic loader to execute a new process or, if the dynamic loader could not be found, execute the process\r\nnormally. If the dynamic loader is used the process directory will start from /tmp.\r\n0x18: send kill signals to all processes of the malware.\r\n0x1A: send continue signal to a process\r\n0x1B: write data to an open memfd file\r\n0x1C: send data saved from communicating with a unix socket\r\n0x1E: create a new connection to IP address and save content sent to an open memfd file.\r\n0x20: read content of a saved memfd file and send back to C2\r\n0x21: xor content and save to an open memfd file\r\n0x22: send an action code to the parent process\r\n0x23: send an action code to the parent process\r\n0x24: install systemd service or initd service to /etc/ice9j or /etc/init.d/ice9j respectively. The service masquerade as an sshd\r\nservice, and adds an LD_PRELOAD entry for each new connection, allowing the threat actor to steal ssh keys.\r\n0x25: send data to parent process\r\n0x26: send stored encryption key to C2 server.\r\n0x27: updates malware configuration values.\r\n0x28: send a signal to a list of processes\r\n0x29: load a kernel module from memory using init_module syscall\r\n0x2A: communicate with another process using a unix socket with a sha256 as name.\r\n0x2B: save a decompressed file.\r\n0x2D: send a saved buffer to back to C2 server.\r\n0x2E: restart malicious systemd service\r\n0x2F: send an action code to the parent process\r\n0x30: send an action code to the parent process\r\n0x32: pass commands to parent process via unix sockets\r\n0x33: save magic numbers used for encryption and the malware config to /etc/ice9j as an attribute named trusted.conf.\r\n0x37: map an open memfd to process or create a new memfd file.\r\n0x39: listen to a new connection and pass content to the C2 server.\r\n0x3A: send kill signal to child process\r\nIndications of Compromise (IOCs)\r\nType Value\r\nMonero\r\nwallet ID\r\n85o3miXCHdWduE6V2xTMVsEofzrDoTyquGAXwW35mAPuRtkW6Xf5jET35QNSnHQL68gZNh96RrZBnPuGgwR6FoyoUEhbZ\r\nHeadCrab\r\nmalware\r\nMD5\r\nc5b992c76b7c9fa3b9bd755dd3b5af76\r\nRedis\r\nMaster\r\n116.202.102.79\r\nReverse\r\nshell IP\r\naddresses\r\n178.62.32.29\r\nMining\r\npool IP\r\naddresses\r\n44.224.209.130\r\nMonero\r\npool\r\n44.224.209.130\r\nHijacked\r\nIP serves\r\nas a\r\nmining\r\npool\r\n182.74.78.10\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 12 of 13\n\nAsaf is a Security Researcher at Aqua Nautilus research team. He focuses on researching Linux malware, developing\r\nforensics tools, and analyzing new attack vectors in cloud native environments. In his spare time, he likes painting, playing\r\nbeach volleyball, and carving wood sculptures.\r\nAssaf Morag\r\nAssaf is the Director of Threat Intelligence at Aqua Nautilus. He is responsible of acquiring threat intelligence related to\r\nsoftware development life cycle in cloud native environments, supports the team's data needs, and helps Aqua and the\r\necosystem remain at the forefront of emerging threats and protective methodologies. His research has been featured in\r\nleading information security publications and journals worldwide, and he has presented at leading cybersecurity\r\nconferences. Notably, Assaf has also contributed to the development of the new MITRE ATT\u0026CK Container Framework.\r\nAssaf is leading an O’Reilly course, focusing on cyber threat intelligence in cloud-native environments. The course covers\r\nboth theoretical concepts and practical applications, providing valuable insights into the unique challenges and strategies\r\nassociated with securing cloud-native infrastructures.\r\nSource: https://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nhttps://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.aquasec.com/blog/headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware/"
	],
	"report_names": [
		"headcrab-attacks-servers-worldwide-with-novel-state-of-art-redis-malware"
	],
	"threat_actors": [
		{
			"id": "f809bfcb-b200-4988-80a8-be78ef6a52ef",
			"created_at": "2023-01-06T13:46:39.186988Z",
			"updated_at": "2026-04-10T02:00:03.240002Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"Adept Libra"
			],
			"source_name": "MISPGALAXY:TeamTNT",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "c3ca592f-0669-49bd-ab5c-310007ab2fb4",
			"created_at": "2022-10-25T15:50:23.334495Z",
			"updated_at": "2026-04-10T02:00:05.264841Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"TeamTNT"
			],
			"source_name": "MITRE:TeamTNT",
			"tools": [
				"Peirates",
				"MimiPenguin",
				"LaZagne",
				"Hildegard"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434005,
	"ts_updated_at": 1775791624,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/72d4f3e80ac309aa044098d77b0237b59482aee9.pdf",
		"text": "https://archive.orkl.eu/72d4f3e80ac309aa044098d77b0237b59482aee9.txt",
		"img": "https://archive.orkl.eu/72d4f3e80ac309aa044098d77b0237b59482aee9.jpg"
	}
}