{
	"id": "72586fb0-5323-4b00-9852-d073147b3efb",
	"created_at": "2026-04-06T00:06:41.66127Z",
	"updated_at": "2026-04-10T13:12:39.292942Z",
	"deleted_at": null,
	"sha1_hash": "101b3ae61a45c50592096816606656af4d351911",
	"title": "Dropping the Anchor | NETSCOUT",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 287198,
	"plain_text": "Dropping the Anchor | NETSCOUT\r\nArchived: 2026-04-05 19:33:36 UTC\r\nExecutive Summary\r\nTrickbot has long been one of the key banking malware families in the wild. Despite recent disruption events, the\r\noperators continue to drive forward with the malware and have recently begun porting portions of its code to the Linux\r\noperating system. As this technical deep dives shows, the  communication between the command-and-control (C2)\r\nserver and the bot are extremely complex. Additionally, we have  analyzed  the C2 communication process of the\r\nLinux2 version of Trickbots’ Anchor module.\r\nKey Findings\r\nTrickbot operators leverage a complex communication schema to control infected machines. \r\nRecent efforts show the operators moving portions of their code to Linux,  thus increasing the portability and\r\nrange of possible victims. \r\nThe Anchor module can implement techniques such as process hollowing and process doppelgänging to evade\r\nanalysis.\r\nBoth Windows- and Linux -based bots have the ability to install additional modules in a victim’s system.\r\nCommunication Setup\r\nTrickbot’s Anchor framework is a backdoor module discovered in 2018. Unlike Trickbot’s typically broad-based\r\ncampaigns, Anchor is deployed exclusively on selected targets. Anchor’s communication with the C2  currently uses\r\nDNS tunneling, which we will break down later.\r\nThis communication involves a few different steps. The purpose of this blog is to make sense of this communication\r\nand understand how the C2 operates the bot.\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 1 of 11\n\nFigure 1: Parts of communication between Bot and C2\r\nFrom a high-level view, Figure 1 shows the flow of communication between the bot and the C2. Throughout the\r\ncommunication process; there are commands meant for the bot (which will be termed as bot_commands) as well as the\r\nC2 (termed as c2_commands). A description of the commands seen in Figure 1 is provided in Table 1 below.\r\n1. Part 1 of the communication is the initial setup between the bot and the C2. The bot sends the c2_command 0 to\r\nthe C2, which contains information about the client, including the bot ID (part 1 of Figure 1). Once the initial\r\ncommunication is established, the C2 responds with a message that contains the signal /1/. \r\n2. In part 2 of the communication, the bot sends back the same signal (which is also the c2_command 1), and the\r\nC2 responds with a bot_command (part 2 of Figure 1). \r\n3. The bot may make further request for the C2 to send an executable file, depending on the initial bot command\r\nreceived (part 3 of Figure 1). \r\n4. Finally, the bot sends back the result of the execution to the C2 (part 4 of Figure 1).\r\nTable 1: Parts of communication between bot and C2\r\nC2 Commands Purpose Bot Commands (Windows) Purpose Bot Commands (Linux) Purpose\r\nC2\r\nCommands\r\nPurpose\r\nBot\r\nCommands\r\n(Windows)\r\nPurpose\r\nBot\r\nCommands\r\n(Linux)\r\nPurpose\r\n\u003cfilename\u003e Obtain PE file 5 or 6\r\nExecute PE\r\nfile using\r\nprocess\r\nhollowing\r\n10, 11, or\r\n12\r\nExecute Linux file\r\n    9 Execute\r\ninstruction via\r\n   \r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 2 of 11\n\nC2\r\nCommands\r\nPurpose\r\nBot\r\nCommands\r\n(Windows)\r\nPurpose\r\nBot\r\nCommands\r\n(Linux)\r\nPurpose\r\npipe object to\r\ncmd.exe\r\n    10\r\nExecute\r\ninstruction via\r\npip object to\r\npowershell.exe\r\n   \r\n    11 or 12\r\nInject PE into\r\nmultiple\r\nprocess\r\n   \r\n    13\r\nChange the\r\nbot's scheduled\r\ntask\r\n   \r\n    14\r\nUninstall the\r\nbot\r\n   \r\n0\r\nInitial C2 Comms\r\nsetup/register bot\r\n0\r\nexecute\r\ninstruction via\r\ncmd.exe\r\n0\r\nExecute instruction via\r\ncmd.exe in the Windows\r\nshares\r\n1\r\nAsk C2\r\nfor bot_command\r\n1 or 2\r\nExecute EXE\r\nin %TEMP%\r\n1 or 2\r\nExecute file in Windows\r\nshare\r\n10\r\nResult of the\r\nexecution of\r\nthe bot_command\r\n7 or 8\r\nExecute PE\r\nusing process\r\ndoppelganging\r\n100 Check bot GUID\r\n5 Obtain PE file 3 or 4\r\nExecute DLL\r\nin %TEMP%\r\n3 or 4\r\nExecute DLL with\r\nexport control_RunDLL in\r\nWindows shares\r\nCreation of DNS queries\r\nEvery part of communication (Figure 1) made to the C2 follows a sequence of 3 different DNS queries (Figure 2).\r\nNTT previously published an article that explores how the DNS queries were created by the bot to the Anchor C2\r\nserver. In this blog, we researched further into the protocol to  better understand the role of each part of the DNS query.\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 3 of 11\n\nFigure 2: High-level overview of the DNS queries\r\nFigure 2 gives a high-level overview of what the DNS queries look like. Each of these queries have their own format\r\non the type of data that is sent to the malware C2, as explained below:\r\nQuery 0 \r\nBot DNS Query\r\n0\u003cUUID bytes\u003e\u003ccurrent_part\u003e\u003ctotal_parts\u003e/anchor_dns/\u003cBot_GUID\u003e/\u003cc2_command\u003e/\u003ccontent\u003e/\r\n0 – Indicating type 0 query\r\nUUID – 16 bytes in length generated by the bot\r\ncurrent_part – The current part of the data being sent (this is further explained below)\r\ntotal_parts – Total number of parts the data is divided into\r\nanchor_dns – The type of Anchor bot that is communicating to the C2.\r\nBot_GUID – The GUID generated is different for Windows and Linux platforms\r\nc2_command – The command meant for the C2\r\ncontent – The content to send based on the type of command (Table 2)\r\nThe Anchor module generates a GUID which is different for each platform:\r\nWindows - \u003chostname_windowsVersion\u003e.\u003c32 bytes client id\u003e\r\nLinux – \u003csystem_linnuxVersion\u003e.\u003c32 bytes client id\u003e\r\nEach command sent to the C2 is followed by its own set of content (Table 2):\r\nTable 2: Content for c2_command\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 4 of 11\n\nc2_command Content\r\nc2_command Content\r\n\u003cfilename\u003e N/A\r\n0\r\n/\u003cWindows OS Info\u003e/1001/\u003cbot_IP\u003e\u003c64 bytes random bytes\u003e\u003c32 bytes random alphanumeric\r\ncharacters\u003e/\r\n1 /\u003c32 bytes random alphanumeric characters\u003e/\r\n10 /\u003cbot_command\u003e/\u003cbot_command_ID\u003e/\u003cresult of bot execution\u003e/\r\n5 /\u003cfilename\u003e/\r\nSince the maximum length of a DNS name is 255 bytes, the data sent for the first query gets sent in parts. This also\r\nexplain the fields current_path and total_parts seen in the type 0 query. Below is the pseudocode on how many parts\r\nthe data gets divided into:\r\ndef get_total_parts(c2, data):\r\n divider = ((0xfa - len(c2)) \u003e\u003e 1) - 0x18\r\n size = len(data)\r\n return (size / divider) + 1\r\nThe data sent to the C2 is crafted as subdomains after it is xor’ed with the key. The key continues to remain 0xb9.\r\nThe example below shows what this data would look like with content sent to c2_command 0 and how many parts it\r\ngets divided into:\r\n0\u003cGUID\u003e\\x00\\x03/anchor_dns/WIN-COMP_W617601.HGDJ3748EURIHDGV192873645672DFGW/0/Windows 7/1001/0.0.0.0/\r\n0\u003cGUID\u003e\\x01\\x03EAA477CDE0E29EF989E433E633F545A09FD31789937121144906202B0EFD32CB/Tb1i5Xc\r\n0\u003cGUID\u003e\\x02\\x03Zih0P1wW70rhjGp7G75WsFu69/\r\nC2 Response\r\nAfter every part of the query gets sent, the C2 responds with an IP. The bot uses this IP to obtain the identifier value\r\nthat will be used in the next query sequence.\r\ndef get_identifier(IP):\r\n return inet_aton(IP) \u003e\u003e 6\r\nQuery 1:\r\nBot DNS Query\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 5 of 11\n\nBoth platforms have the same query for type 1. And similarly, the data is created as a subdomain after being xor’ed\r\nwith 0xb9.\r\n1\u003cUUID\u003e\u003cdw_Identifier\u003e\r\ndw_Identifier – The same value that was sent by the C2 to the bot for query type 0\r\nC2 Response\r\nThe C2 responds with an IP. This IP is also passed through the same function routine as get_identifier in the\r\npseudocode above, and the resulting value is the size of the data to be expected from the final query type.\r\nQuery 2:\r\nBot DNS Query\r\nBoth platforms have the same query for type 2.\r\n2\u003cUUID\u003e\u003cdw_Identifier\u003e\u003cdw_DataReceivedSize\u003e\r\ndw_Identifier – The same value that was sent by the C2 to the bot for query type 0\r\ndw_DataReceivedSize – The size of the data that has been received thus far.\r\nThe bot keeps sending a query type 2 request until the total size of the data received from the C2 matches that of the\r\nvalue sent by C2 in response to query type 1. \r\nC2 Response\r\nWith each type 2 DNS query made by the bot, the C2 responds with a list of IP records. This list of IPs (Figure 3) is a\r\nstructure on how the data is constructed and is exactly as that mentioned by NTT.\r\nFigure 3: Records of IPs sent by the C2\r\nThe first dotted decimal number of the IP gives the order in which the list of IPs is parsed by the bot. \r\nIPs of this form 4.?.?.? show how much data has been sent by the C2, with the last 3 dotted decimal numbers of\r\nthe IP indicating the size.\r\nIPs of this form 8.?.?.? show the size of data in the current record list,  with the last 3 dotted decimal numbers of\r\nthe IP indicating the value.\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 6 of 11\n\nThe additional IPs in Figure 3 are all data in which the last 3 dotted decimal numbers of the IP are concatenated\r\ntogether.\r\nIn Figure 4 below, we see an example PE file payload of IP records sent by the C2.\r\nFigure 4: Example PE file payload\r\nWindows Anchor\r\nThe final data received from the C2 has the following structure:\r\n/\u003cbot_command\u003e/anchor_dns/\u003cBot_GUID\u003e/\u003c32_bytes_random_alphanumeric\u003e/\u003cbot_command_ID\u003e/\\r\\n\u003cbase64_encoded_\r\nbase64_encoded_data: Information used by the resulting bot_command subroutine.\r\nBot_Command 0 \r\nbase64_encoded_data from C2 – decodes to a series of arguments\r\nExecutes a series of arguments through cmd.exe \r\nBot_Command 1 \u0026 2\r\nbase64_encoded_data from C2 – decodes to filename and/or file arguments\r\nThe bot makes DNS queries to C2 for a PE file.\r\nbot_command 1 sends c2_command 5\r\nbot_command 2 sends c2_command \u003cfilename\u003e\r\nThe EXE is created in the %TEMP% directory with a prefix tcp and executed.\r\nBot_Command 3 \u0026 4 \r\nbase64_encoded_data from C2 – decodes to filename and/or file arguments\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 7 of 11\n\nThe bot makes DNS queries to C2 for a PE file.\r\nbot_command 3 sends c2_command 5\r\nbot_command 4 sends c2_command \u003cfilename\u003e\r\nThe DLL is created in the %TEMP% directory with a prefix tcp and executed (Figures 5 and 6). \r\nFigure 5: 64bit Anchor PE run being run\r\nFigure 6: 64bit Anchor PE executing a DLL\r\nBot_Command 5 \u0026 6 \r\nbase64_encoded_data from C2 – decodes to filename and/or file arguments\r\nThe bot makes DNS queries to C2 for a PE file.\r\nbot_command 5 sends c2_command 5\r\nbot_command 6 sends c2_command \u003cfilename\u003e\r\nThe PE file is injected into a process via process hollowing.\r\nBot_Command 7 \u0026 8\r\nbase64_encoded_data from C2 – decodes to filename and/or file arguments\r\n•    The bot makes DNS queries to C2 for a PE file.\r\no    bot_command 5 sends c2_command 5\r\no    bot_command 6 sends c2_command \u003cfilename\u003e\r\n•    The PE file is injected into a process via process doppelgänging.\r\nBot_Command 9\r\nbase64_encoded_data from C2 – decodes to a series of arguments\r\nExecutes a series of arguments through a pipe object to cmd.exe \r\nBot_Command 10\r\nbase64_encoded_data from C2 – decodes to a series of arguments\r\nExecutes a series of arguments through a pipe object to powershell.exe \r\nBot_Command 11 \u0026 12\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 8 of 11\n\nbase64_encoded_data from C2 – decodes to filename\r\nThe bot makes DNS queries to C2 for a PE file.\r\nbot_command 11 sends c2_command 5\r\nbot_command 12 sends c2_command \u003cfilename\u003e\r\nThis PE file is injected into 3 different running processes that get created.\r\nThese processes are explorer.exe, mstsc.exe, and notepad.exe\r\nBot_Command 13 \r\nbase64_encoded_data from C2 – decodes to a scheduled task string\r\nThe bot changes the scheduled task of the bot\r\nBot_Command 14 \r\nUninstall the Anchor\r\nLinux Anchor\r\nThe Linux Anchor module was first discovered by Stage 2 Security. The analysis done by Stage 2 Security is extensive,\r\nbut we wanted to take a closer look at the C2 communications in the same way we did with the Windows version\r\nabove. \r\nThe bot_commands from 0-4 contains smb2 information (which includes domain, user, and password) to be used by the\r\nLinux module when attempting to connect to any Windows shares. The module has an embedded PE file that is used to\r\nexecute commands or files on the Windows shares.\r\nBot_Command 0\r\nbase64_encoded_data from C2 - decodes to a series of arguments\r\nExecutes a series of arguments through cmd.exe on the Windows shares.\r\nBot_Command 1 \u0026 2\r\nbase64_encoded_data from C2 - decodes to filename and/or file arguments\r\nThe bot makes DNS queries to C2 for a PE file.\r\nbot_command 1 sends c2_command 5\r\nbot_command 2 sends c2_command \u003cfilename\u003e\r\nThe file gets executed.\r\nBot_Command 3 \u0026 4\r\nbase64_encoded_data from C2 - decodes to filename and/or file arguments\r\nThe bot makes DNS queries to C2 for a PE file.\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 9 of 11\n\nbot_command 3 sends c2_command 5\r\nbot_command 4 sends c2_command \u003cfilename\u003e\r\nThe DLL files export function Control_RunDLL gets executed.\r\nBot_Command 10 \u0026 11 \u0026 12\r\nbase64_encoded_data from C2 \r\nFor bot_command 10, the encoded data is a Linux file that is executed by the bot.\r\nBot_Commands 11 and 12 make DNS queries to C2 for a Linux file.\r\nbot_command 11 sends c2_command 5\r\nbot_command 12 sends c2_command \u003cfilename\u003e\r\nThe bot sets the file’s permissions to 777 and executes it.\r\nBot_Command 100\r\nbase64_encoded_data from C2 - decodes to a GUID\r\nThe bot checks whether the GUID sent by the C2 matches that of the bot’s GUID.\r\nIf the GUIDs do not match, the bot terminates C2 communication.\r\nConclusion\r\nThe complexity of Anchor’s C2 communication and the payloads that the bot can execute reflect not only a portion of\r\nthe Trickbot actors’ considerable capabilities, but also their ability to constantly innovate, as evidenced by their move\r\nto Linux.  It is important to note that Trickbot operators aren’t the only adversaries to realize the value of targeting\r\nother operation systems. Earlier this year, we analyzed a DDoS bot called Lucifer designed to run on both Windows\r\nand Linux platforms. As we see more adversaries building cross-compile malware families, it seems clear that security\r\nprofessionals must re-evaluate security practices for Linux systems to ensure they are well-prepared to defend against\r\nthese increasing threats. \r\nIndicators of Compromise:\r\nAnchor C2s:\r\nwesturn[.]in\r\nonixcellent[.]com\r\nwonto[.]pro\r\nericrause[.]com\r\nAnchor PE 64bit\r\nSHA256 - c427a2ce4158cdf1f320a1033de204097c781475889b284f6815b6d6f4819ff8\r\nSHA256 - 4e5fa5dcd972170bd06c459f9ee4c3a9683427d0487104a92fc0aaffd64363b2\r\nAnchor ELF 64bit\r\nSHA256 - 4655b4b44f6962e4f9641a52c24373390766c50b62fcc222e40511c0f1ed91d2\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 10 of 11\n\nAnchor PE 32bit Helper file for Linux\r\nSHA256 - 7686a3c039b04e285ae2e83647890ea5e886e1a6631890bbf60b9e5a6ca43d0a\r\nSource: https://www.netscout.com/blog/asert/dropping-anchor\r\nhttps://www.netscout.com/blog/asert/dropping-anchor\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.netscout.com/blog/asert/dropping-anchor"
	],
	"report_names": [
		"dropping-anchor"
	],
	"threat_actors": [],
	"ts_created_at": 1775434001,
	"ts_updated_at": 1775826759,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/101b3ae61a45c50592096816606656af4d351911.pdf",
		"text": "https://archive.orkl.eu/101b3ae61a45c50592096816606656af4d351911.txt",
		"img": "https://archive.orkl.eu/101b3ae61a45c50592096816606656af4d351911.jpg"
	}
}