{
	"id": "4b9f1dee-db64-4b6b-8f1c-49d63961e3fc",
	"created_at": "2026-04-06T00:11:49.052402Z",
	"updated_at": "2026-04-10T03:21:39.893636Z",
	"deleted_at": null,
	"sha1_hash": "b14ef9e1273ebad88eb0ed1e744d577a95a220d6",
	"title": "Active C2 Discovery Using Protocol Emulation Part1 (HYDSEVEN NetWire)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 668862,
	"plain_text": "Active C2 Discovery Using Protocol Emulation Part1\r\n(HYDSEVEN NetWire)\r\nBy Takahiro Haruyama\r\nPublished: 2019-11-20 · Archived: 2026-04-05 17:43:21 UTC\r\nMalware C2 addresses can be an important IOC to detect known threats. In order to obtain C2 information, we\r\nfirst need malware samples which are then analyzed dynamically or statically. However the analysis task is often\r\ntimes not straightforward.  Increasingly anti-analysis methods are implemented in malware or C2 information is\r\nextracted from secondary or tertiary websites.\r\nVMware Carbon Black Threat Analysis Unit (TAU) analyzed HYDSEVEN NetWire samples then implemented a\r\nscanner to discover active C2 servers on the Internet by emulating the customized C2 protocol. In this blog post,\r\nthe latest protocol and scanner implementation are detailed for researchers and practitioners.\r\nFor background context, NetWire is a cross-platform remote access tool or trojan (RAT) for Windows/Linux/Mac\r\nand sold by World Wired Labs. In the past different threat actor groups have utilized this tool for targeted\r\nattacks, Palo Alto published a C2 protocol decoder five years ago.\r\nThe NetWire C2 protocol is TCP-based. The RAT and C2 server initially exchange an “authentication packet”\r\nincluding information required for the packet payload encryption. By emulating the exchange, we are able to\r\ndetect active NetWire C2 servers on the Internet.\r\nHYDSEVEN, that was named by LAC, is a threat actor targeting virtual currency exchange companies for\r\nfinancial motive. This actor utilizes NetWire. However, as LAC pointed out in their report, HYDSEVEN\r\ncustomized the C2 protocol with different data format. Additionally TAU found a completely-different algorithm\r\nfor the encryption key generation which was implemented in HYDSEVEN’s NetWire. Therefore, if we obtain any\r\ncorrect response after sending the customized “authentication packet”, the address of the respondent is a C2 server\r\nutilized by HYDSEVEN.\r\nhttps://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nPage 1 of 8\n\nThe following image is the flow of the key exchange by the customized “authentication packet”.\r\nFigure 1: HYDSEVEN NetWire key exchange\r\nThe protocol format and encryption are detailed in the following sections.\r\nProtocol Format\r\nThe customized “authentication packet” format is below. The packet is separated into the header and payload.\r\nstruct struc_pkt_header\r\n{\r\nchar cmd_id; // client = 0x7F (0x03 ^ 0x7C), server = 0xE6 (0x5 ^ 0xE3)\r\nint payload_len; // 0x40\r\nchar os_id; // client = 0xD8(win)/0xDB(linux)/0xDD(mac), server = 0\r\n};\r\nThe header values are well-documented in the previously referenced  LAC report. The command ID (cmd_id) 0x3\r\nand 0x5 specify the packets are used for an initial key exchange. The ID is encoded/decoded by one byte xor on\r\neach side. The platform ID (os_id) shows the client OS environment.\r\nstruct struc_pkt_auth_payload\r\n{\r\nchar random_seed[32]; // combined with fixed seed from config (HYDSEVEN uses “Password”)\r\nchar random_IV[16]; // only client IV used\r\nhttps://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nPage 2 of 8\n\nchar enc_TestPacket[16]; // encrypted from binary data “3b 0f db 9a 94 08 cd 6b 06 8c 93 c6 12 d8 b4 17”\r\n};\r\nThere are three values in the payload of the “authentication packet.” The random_seed is used for the AES key\r\ngeneration, combined with the hard-coded seed (“Password”). The random_IV is IV data for the AES encryption,\r\ngenerated and shared by the client side. The pcap data on VirusTotal (SHA256:\r\na2e449364b1bc148a19824984010485e2770a2f2e3098a7b59b557a59f735691) showed the random_IV from a C2\r\nserver was NULL.\r\nFigure 2: NULL random_IV value from a C2 server\r\nThe enc_TestPacket data is utilized in the validation of the exchanged keys and encrypted from the following\r\nhard-coded binary data called TestPacket.\r\nFigure 3: TestPacket data to be encrypted\r\nPayload Encryption\r\nhttps://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nPage 3 of 8\n\nThe HYDSEVEN NetWire’s payload encryption algorithm is AES in OFB mode, that is the same as normal\r\nNetWire. However, the key generation algorithm is totally different. The SHA1 algorithm is utilized in the\r\ncustomized key generation.\r\nFigure 4: AES key generation algorithm used by normal NetWire (from Palo Alto protocol decoder code)\r\nhttps://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nPage 4 of 8\n\nFigure 5: AES key generation algorithm used by HYDSEVEN-customized NetWire\r\nScanner Implementation\r\nVMware Carbon Black Threat Analysis Unit (TAU) initially implemented the POC scanner then continued\r\nimproving it for Internet scale.\r\nPOC Scanner\r\nWhile it is possible to implement the scanner based on the static code analysis result, the implementation should\r\nbe validated in another way. TAU utilized the pcap data described earlier for the validation.\r\nThe pcap data contains packets generated by both the client and server sides. The POC code took the client seed\r\nand IV from the client packet (auth_send.bin) and the server seed from the server packet (auth_recv.bin) as they\r\nare random data, then it generated the entire packets including the encrypted TestPacket (gen_send.bin and\r\ngen_recv.bin). As a result, the generated packets exactly matched the data in the pcap, so TAU concluded the POC\r\nscanner worked correctly.\r\n$ hexdump -C auth_send.bin\r\n00000000  7f 40 00 00 00 dd ee bc  b0 f1 d4 80 be ca 70 a2 |.@…………p.|\r\n00000010  68 fb ac 7a 4e 68 f8 80  55 60 26 14 de e2 f4 a9 |h..zNh..U`\u0026…..|\r\n00000020  99 c8 e4 8f f4 ad fc e4  fa f8 40 c8 8f 78 20 76 |……….@..x v|\r\n00000030  f4 74 78 85 b0 61 30 66  1f 60 59 79 d5 e7 b6 b0 |.tx..a0f.`Yy….|\r\n00000040  82 35 44 9a 39 ff                                 |.5D.9.|\r\n00000046\r\n$ hexdump -C auth_recv.bin\r\n00000000  e6 40 00 00 00 00 16 dc  62 17 32 33 e7 34 93 14 |.@……b.23.4..|\r\n00000010  40 95 02 d2 13 45 de d6  06 8e 77 7a f6 c3 e7 de |@….E….wz….|\r\n00000020  5f db 3a a9 da 05 00 00  00 00 00 00 00 00 00 00 |_.:………….|\r\nhttps://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nPage 5 of 8\n\n00000030  00 00 00 00 00 00 a3 61  08 67 08 7f 33 10 8e df |…….a.g..3…|\r\n00000040  3c a7 d8 36 c5 95                                 |\u003c..6..|\r\n00000046\r\n$ python client.py\r\n[*] gen_send.bin created\r\n[*] 127.0.0.1:443,suspicious\r\n[DEBUG] server key (0x20 bytes):\r\n‘XJ\\xad+\\xb2\\xea\\xbf\\xc9\\xa5\\xfe\\xd1\\x81\\xdb\\x9f\\xbd3\\xe1\\x12\\xc4\\xf8\\x81\\xc1\\xd6,\\xca\\x00\\xe2\\x82\u0026\\x98z\\x9e’\r\n[+] 127.0.0.1:443,active\r\n$ sudo python server.py\r\n[*] got custom NetWire packet from (‘127.0.0.1’, 51155)\r\n[*] client key: ‘gA6%\\x8f\\xfe\\x15#\\n\\x12\\xb5\\x1fg\\xe2;\\x086″Y\\x7foe\\x04\\xcb\\x89b/\\xc6\\xbb\\xc6d\\xb3’ (32\r\nbytes)\r\n[+] the key and IV are valid. sending response…\r\n[*] gen_recv.bin created\r\n$ md5 *_send.bin\r\nMD5 (auth_send.bin) = 50778a98ca957cf1ddb3d96f0b623133\r\nMD5 (gen_send.bin) = 50778a98ca957cf1ddb3d96f0b623133\r\n$ md5 *_recv.bin\r\nMD5 (auth_recv.bin) = 19493425e15c770d971be676bce14aa2\r\nMD5 (gen_recv.bin) = 19493425e15c770d971be676bce14aa2\r\nScanning the Internet\r\nTAU initially focused on port 443 for the scanning as all analyzed samples utilized the port.\r\nThe initial version of the scanner sent the customized “authentication packet” after checking if port 443 was open\r\non the host. However port scanning for all hosts on the Internet was too expensive for the scanner to finish in a\r\nrealistic window of time. Thus the second version would only send the authentication packets to hosts discovered\r\nby the MASSCAN port scanner.\r\nWhile the second version scanner had run for a few months, it was not effective as the port scanning practically\r\ndidn’t work. Specifically, the number of open hosts discovered by MASSCAN was much smaller than actual ones.\r\nspecified packet rate (packets per seconds) discovered open hosts completion time (hours)\r\n180,000 8,283 6\r\n100,000 13,435 11\r\n60,000 24,916 18\r\nTable 1: MASSCAN experiment result\r\nhttps://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nPage 6 of 8\n\nAs shown in the above table, the discovered open hosts changed according to the packet rates. Additionally, the\r\nsearch results by Censys and SHODAN were about 40 and 50 million. It was unknown why the majority of open\r\nhost were missed with the previous tool.\r\nThe external security researcher Tadashi Kobayashi, who published the OllyDumpEx/OllyMigrate IDA plugins,\r\nadvised the bottleneck was the broadband router performing NAT. Based off of his advice, TAU prepared a Linux\r\nVM directly-connecting to the Internet through PPPoE then run ZMap (MASSCAN didn’t support the scanning\r\noption against non-Ethernet interfaces). Using this method, TAU obtained 52,128,684 hosts, with port 443 open, \r\nfrom the Internet.\r\nResult\r\nTAU scanned against the 52 million open hosts in mid-Nov this year by sending the customized authentication\r\npacket but at the time of the scan there was no responsive C2 servers. This initial scanning result indicates a series\r\nof possibilities:\r\nHYDSEVEN was not active at that time or stopped utilizing the customized NetWire\r\nThe actor have changed the hard-coded data in the NetWire samples (e.g., fixed seed and TestPacket), as\r\nnew variants are used in campaigns.\r\nThe C2 is inaccessible to IP addresses not targeted by the actor\r\nWrap-up\r\nTAU analyzed the HYDSEVEN NetWire C2 protocol then implemented the scanner to discover the active C2\r\nservers on the Internet. No active servers were found by the scanning, indicating their inactivity or change of the\r\nTTPs.\r\nTAU also learned several takeaways for a large-scaled scanning initiative as part of this research. This knowledge\r\nwill be utilized during ongoing and future C2 research projects.\r\nAcknowledgement\r\nFor this research, TAU appreciates Tadashi Kobayashi’s insight and advice. Kobayashi provided tactics for\r\ndifferent port scanning strategies and the implementation details to identify the issues in MASSCAN and ZMap.\r\nIndicators of Compromise (IOCs)\r\nIndicator Type Context\r\n0499aa5c68c59d2d3a484d52d7f1afcc189722ae96dfdde2afd9e12c95085af4\r\nb8b776ebe5cf30c6dc1547ed35a79f42\r\nSHA256\r\nMD5\r\nHYDSEVEN\r\nNetWire for\r\nWindows\r\nshared by LAC\r\nhttps://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nPage 7 of 8\n\nc7c3d70337336fc183135038ce5d0a4bb83ab6d9f4cc1ad5cf600295e6a41e1b\r\n12def981952667740eb06ee91168e643\r\nSHA256\r\nMD5\r\nHYDSEVEN\r\nNetWire for\r\nWindows\r\nshared by LAC\r\na981a5fbeff782330871fb8a106466cbe61280536c162b3e3c3cbf441265b437\r\ncb75044f5941530d963df9a626c813ae\r\nSHA256\r\nMD5\r\nHYDSEVEN\r\nNetWire for\r\nLinux\r\nshared by LAC\r\n07a4e04ee8b4c8dc0f7507f56dc24db00537d4637afee43dbb9357d4d54f6ff4\r\nde3a8b1e149312dac5b8584a33c3f3c6\r\nSHA256\r\nMD5\r\nHYDSEVEN\r\nNetWire for\r\nMac OS\r\nshared by LAC\r\n41dfab4ade85a7ea2df6f726ea711b60ddac7aa29d77a6bc5654564dec46cef7\r\n50d4f0da2e38874e417bd13b59f4c067\r\nSHA256\r\nMD5\r\nHYDSEVEN\r\nNetWire for\r\nMac OS\r\na2e449364b1bc148a19824984010485e2770a2f2e3098a7b59b557a59f735691\r\n944b9c731cf3821f1392b40f82ea0947\r\nSHA256\r\nMD5\r\nHYDSEVEN\r\nNetWire for\r\nMac OS\r\nSource: https://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nhttps://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blogs.vmware.com/security/2019/11/active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html"
	],
	"report_names": [
		"active-c2-discovery-using-protocol-emulation-part1-hydseven-netwire.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434309,
	"ts_updated_at": 1775791299,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b14ef9e1273ebad88eb0ed1e744d577a95a220d6.pdf",
		"text": "https://archive.orkl.eu/b14ef9e1273ebad88eb0ed1e744d577a95a220d6.txt",
		"img": "https://archive.orkl.eu/b14ef9e1273ebad88eb0ed1e744d577a95a220d6.jpg"
	}
}