{
	"id": "97847426-2b7e-4740-91ac-f3ccf705688d",
	"created_at": "2026-04-06T00:08:44.074876Z",
	"updated_at": "2026-04-10T13:11:25.444293Z",
	"deleted_at": null,
	"sha1_hash": "fc69c34f5de302538fed6626a2a90e8a88332472",
	"title": "BendyBear: Novel Chinese Shellcode Linked With Cyber Espionage Group BlackTech",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2088091,
	"plain_text": "BendyBear: Novel Chinese Shellcode Linked With Cyber\r\nEspionage Group BlackTech\r\nBy Mike Harbison\r\nPublished: 2021-02-09 · Archived: 2026-04-05 16:20:40 UTC\r\nExecutive Summary\r\nHighly malleable, highly sophisticated and over 10,000 bytes of machine code. This is what Unit 42 researchers\r\nwere met with during code analysis of this “bear” of a file. The code behavior and features strongly correlate with\r\nthat of the WaterBear malware family, which has been active since as early as 2009. Analysis by Trend Micro and\r\nTeamT5 unveiled WaterBear as a multifaceted, stage-two implant, capable of file transfer, shell access, screen\r\ncapture and much more. The malware is associated with the cyber espionage group BlackTech, which many in the\r\nbroader threat research community have assessed to have ties to the Chinese government, and is believed to be\r\nresponsible for recent attacks against several East Asian government organizations. Due to the similarities with\r\nWaterBear, and the polymorphic nature of the code, Unit 42 named this novel Chinese shellcode “BendyBear.” It\r\nstands in a class of its own in terms of being one of the most sophisticated, well-engineered and difficult-to-detect\r\nsamples of shellcode employed by an Advanced Persistent Threat (APT).\r\nThe BendyBear sample was determined to be x64 shellcode for a stage-zero implant whose sole function is to\r\ndownload a more robust implant from a command and control (C2) server. Shellcode, despite its name, is used to\r\ndescribe the small piece of code loaded onto the target immediately following exploitation, regardless of whether\r\nor not it actually spawns a command shell. At 10,000+ bytes, BendyBear is noticeably larger than most, and uses\r\nits size to implement advanced features and anti-analysis techniques, such as modified RC4 encryption, signature\r\nblock verification, and polymorphic code.\r\nThe sample analyzed in this blog was identified by its connections to a malicious C2 domain published by\r\nTaiwan's Ministry of Justice Investigation Bureau in August 2020. It was discovered absent additional information\r\nregarding the exploit vector, potential victims or intended use.\r\nPalo Alto Networks customers can be protected from the attacks outlined in this blog with the Next-Generation\r\nFirewall alongside DNS Security, URL Filtering and WildFire security subscriptions, and Cortex XDR.\r\nA New Class of Shellcode\r\nAt a macro level, BendyBear is unique in that it:\r\nTransmits payloads in modified RC4-encrypted chunks. This hardens the encryption of the network\r\ncommunication, as a single RC4 key will not decrypt the entire payload.\r\nAttempts to remain hidden from cybersecurity analysis by explicitly checking its environment for signs of\r\ndebugging.\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 1 of 15\n\nLeverages existing Windows registry key that is enabled by default in Windows 10 to store configuration\r\ndata.\r\nClears the host’s DNS cache every time it attempts to connect to its C2 server, thereby requiring that the\r\nhost resolve the current IP address for the malicious C2 domain each time.\r\nGenerates unique session keys for each connection to the C2 server.\r\nObscures its connection protocol by connecting to the C2 server over a common port (443), thereby\r\nblending in with normal SSL network traffic.\r\nEmploys polymorphic code, changing its runtime footprint during code execution to thwart memory\r\nanalysis and evade signaturing.\r\nEncrypts or decrypts function blocks (code blocks) during runtime, as needed, to evade detection.\r\nUses position independent code (PIC) to throw off static analysis tools.\r\nIn the following sections, we provide an in-depth technical breakdown of each of these capabilities.\r\nTechnical Details\r\nShellcode Execution\r\nThe shellcode (SHA256:\r\n64CC899EC85F612270FCFB120A4C80D52D78E68B05CAF1014D2FE06522F1E2D0) is considered to be a\r\nstager, or downloader, whose function is to download an implant from a C2 server. During execution, the code\r\nemploys byte randomization to obscure its behavior. This is achieved by using the host’s current time as a seed for\r\na pseudorandom number generator, and then performing additional operations against that output. The resulting\r\nvalues are used to overwrite blocks of previously executed code. This byte manipulation is the first anti-analysis\r\ntechnique observed in the code, as any attempt to dump the memory segment would result in illegitimate or\r\nincorrect operations. Figure 1 shows an example of the shellcode main entry point before and during runtime\r\nexecution.\r\nFigure 1. Modified shellcode runtime example.\r\nBecause shellcode lacks the ability to run on its own, a Windows loader is required to allocate an environment in\r\nmemory for it to execute. At the time of analysis, no loader had been identified for this shellcode; Therefore, Unit\r\n42 created a custom loader to study the code during its runtime execution. Since then, however, several older\r\ninstallers were discovered with embedded WaterBear shellcode based on attributes identified from this sample.\r\nMore information on these loaders can be found in the Appendix section “x86 WaterBear Loaders”.\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 2 of 15\n\nThe shellcode begins by locating the target’s Process Environment Block (PEB) to check if it’s currently being\r\ndebugged. However, the code is written such that it pulls both the “BeingDebugged” and “BitField” values from\r\nthe PEB, resulting in code logic that invalidates the debugger check. Because of this, the shellcode will always fail\r\nto recognize when a debugger is attached. This routine is performed 52 times in a while loop.\r\nNext, the shellcode iterates through the PEB’s loader module list looking for the base address of Kernel32.dll.\r\nThis is typical of shellcode, as the Kernel32.dll base address is necessary to resolve any dependency files required\r\nby the shellcode to run. With this address, the shellcode loads its dependency modules and resolves any necessary\r\nWindows Application Programming Interface (API) calls using standard shellcode API hashing. The following\r\nmodules are loaded:\r\nAdvapi32.dll\r\nKernel32.dll\r\nMsvcrt.dll\r\nUser32.dll\r\nWs2_32.dll\r\nWith the shellcode initialization complete, it moves onto its main function. It begins by querying the target’s\r\nregistry, at the following key:\r\nHKEY_CURRENT_USER\\Console\\QuickEdit\r\nThis registry key is used by the Windows command prompt to enable Quick Edit mode. Quick Edit mode allows\r\ncopy and paste from the command prompt to the clipboard. By default, this key contains a REG_DWORD, a 32-\r\nbit number of either 1 for enabled or 0 for disabled. BendyBear reads this value, multiplies it by 1000 and\r\nperforms the following calculation on the result:\r\nIf the result is less than 1,000 or greater than 3,300,000 the shellcode configuration (QuickEdit) is 4,000 (0xFA0)\r\notherwise it is the result of the computed value.\r\nRefer to the highlighted light blue value in Figure 2 Shellcode configuration.\r\nThis check is performed each and every time the shellcode is executed. One explanation for the use of this key is\r\nthat the value is written to by the shellcode loader (to a value other than 0 or 1) and it’s used by the shellcode to\r\nobtain configuration settings.\r\nIt then decrypts its internal configuration structure, which is 1,152 bytes. An example is shown in Figure 2.\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 3 of 15\n\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 4 of 15\n\nFigure 2. Shellcode configuration structure.\r\nA breakdown of the configuration structure shown in Figure 2 is below (from top to bottom):\r\nHighlighted in neon green are the two, 16-byte keys used for XORing values throughout the shellcode.\r\n7D 38 BA FD E1 C8 D2 DF B6 EE 33 F9 14 BF 52 96\r\n71 17 DF E4 AE 3B A9 F2 D5 3D 75 CC D3 0D 57 72\r\nHighlighted in light blue are the two bytes computed from the host’s Quick Edit Registry key.\r\nE8 03\r\nHighlighted in orange are the four bytes that represent the shellcode version.\r\n30 2E 32 34 (0.24)\r\nHighlighted in pink are the 17 bytes that make up the C2 domain. Bitwise NOT (unsigned byte) to decode\r\nthe values including the NULL.\r\n88 98 CE D1 96 91 94 9A 8C 93 96 89 9A D1 9C 90 92\r\nHighlighted in dark green are the 103 bytes that are used for pattern elimination. XOR with 0xFF to NULL\r\nvalues.\r\nFF FF FF FF FF FF FF FF FF FF FF...\r\nHighlighted in magenta are the two bytes that make up the target C2 port.\r\nBB 01\r\nHighlighted in light yellow are the resolved function pointers used by the shellcode.\r\n92 13 73 33 37 02\r\nHighlighted in dark cyan are the 112 bytes that make up the function pointer sizes used to encrypt or\r\ndecrypt function blocks.\r\nEE 01\r\nHighlighted in dark red are the 289 bytes that make up the resolved Windows API functions used by the\r\nshellcode\r\nA0 2E 52 CC FC 7F 00 00...\r\nNetwork Communications\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 5 of 15\n\nFigure 3. Stager communication flow.\r\nBefore communicating with the C2 server, the shellcode flushes the host’s DNS cache by performing the\r\nfollowing:\r\n1. Loads module dnsapi.dll\r\n2. Calls API DnsFlushResolverCache\r\nWhen this API is called, all domains resolved are cleared from the host’s DNS cache, not just the target C2 server.\r\nThis forces the host to resolve the current IP associated with the C2 domain, ensuring that communication\r\ncontinues as network infrastructure becomes compromised or unavailable. It also implies the developers own the\r\ndomain and can update the IP.\r\nThe stager begins by computing 10 bytes of data to send to the C2 server. These 10 bytes make up a challenge\r\nrequest packet. The stager sends the challenge request to the C2 and waits for a challenge response. When\r\nreceived and properly decrypted, the stager checks for magic values or signature bytes at specific offsets. If this\r\ncheck fails, the network connection is aborted. This check ensures trusted communication with the intended C2\r\nserver and initiates the download of the payload.\r\nI. Stager Generates Challenge Request Packet\r\nThe stager computes a 10-byte challenge request containing information for the C2, to include the size of the data\r\n(being the session keys) to be received next. The challenge request and session keys are sent to the C2\r\nsimultaneously. Example request:\r\n26BCFCCE738A211F3763\r\nII. C2 Server Decrypts Challenge Request Packet\r\nThe C2 decrypts the challenge request packet using the following steps:\r\n1. First byte will be XORed with the second byte, second byte with third byte…until byte 10, followed by:\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 6 of 15\n\nA. Byte 7 is updated from the result of ( byte 7 XORed with byte 3 ).\r\nB. Byte 2 is updated from the result of ( byte 2 XORed with byte 0 ).\r\nC. Byte 8 is updated from the result of ( byte 8 XORed with byte 0 ).\r\nD. Byte 9 is updated from the result of ( byte 9 XORed with byte 5 ).\r\n2. Final value is XORed with key 0x3FDA5F9AD85D50C77E6A\r\nThe challenge request decrypts to the following (represented as hex bytes):\r\nFigure 4. Decrypted request challenge.\r\nThe last four bytes of the decrypted request packet inform the C2 server of the size of the expected network traffic\r\nto follow. As shown above, the value is 0x20, or 32 bytes. These 32 bytes make up the session keys used by the\r\nC2 server to encrypt a server challenge response and encrypt the payload.\r\nExample of session keys received by the C2 server:\r\nSession key 1--\u003e 8C931D4F764B0661C26D77239EB454CA\r\nSession key 2--\u003e 7A4DD0AA6C3F37CDBDAFA4CBD6B27697\r\nThe challenge request packet and session keys are computed for each beacon and therefore would always be\r\nunique.\r\nIII. C2 Authenticates With the Stager\r\nThe C2 uses the session keys to build the RC4 state box and as an XOR key for encryption and decryption.\r\n*It should be noted that the use of session key 2 is not yet fully understood, and it did not appear to be used to\r\ncommunicate with the stager.\r\n1. The pre-session key is computed using session key 1 (first 16 bytes) as follows:\r\nPre-Session Key = session key 1 XOR\r\n0X6162636465666768696A6B6C6D6E6F00\r\n2. Using the computed pre-session key from step 1, the C2 server builds the RC4 Key Scheduling Algorithm\r\n(KSA). It is computed as follows:\r\na. Build the RC4 KSA using the following inputs to the below function:\r\ndata = 16-byte key 0x0C2F65194FF37B2D63D34635C7B205E4\r\nkey = 16-byte computed pre-session key from step 1\r\n   Example RC4 (modified) KSA routine:\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 7 of 15\n\ndef rc4_KSA(data, key):\r\n      x = 0\r\n      box = range(258)\r\n      box[256] = 0\r\n      box[257] = 0\r\n      for i in range(256):\r\n      x = (x + box[i] + ord(key[i % len(key)])) % 256\r\n      box[i], box[x] = box[x], box[i]\r\n      return box\r\n*Note about the input parameter “data” for the KSA routine: It is the XOR result of the two 16-byte keys shown\r\nneon green in Figure 2. Shellcode Configuration Structure.\r\n3. Construct 10-byte server challenge response header using the hex values shown in Figure 5.\r\nFigure 5. Server Command Challenge Header\r\n4. Encrypt server challenge response header from step 3:\r\na. XOR 10-byte server challenge with key 0x33836E6B3FAA6AC464DA and perform the following:\r\ni. Byte 7 is updated from the result of ( byte 7 XORed with byte 3 ).\r\nii. Byte 2 is updated from the result of ( byte 2 XORed with byte 0 ).\r\niii. Byte 8 is updated from the result of ( byte 8 XORed with byte 0 ).\r\niv. Byte 9 is updated from the result of ( byte 9 XORed with byte 5 ).\r\nb. Encrypted server challenge response header = result of 4(a)\r\n5. Compute final authentication key:\r\na. XOR the following values:\r\ni. 0x0C2F65194FF37B2D63D34635C7B205E4\r\nii. Value computed from step 1, i.e. Pre-Session Key\r\n*The 16-byte value in 5.a.i is the same input parameter used in the KSA algorithm in step 2. The stager expects\r\nthis key from the C2 otherwise the session is aborted.\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 8 of 15\n\nThe values generated in steps 4 and 5 make up the complete server challenge response. At this point, the C2 sends\r\nthe server challenge response to the stager, completing the authentication process.\r\nIV. C2 Encrypts and Transmits Payload\r\nNext, the C2 prepares to send a command to the stager. BendyBear only supports one type of command: payload\r\ndownload.\r\n1. Build a 10-byte command header using the hex values shown in Figure 6.\r\nFigure 6. Updated server command challenge header.\r\nThe only change to the header is the fixed signature value from 0x40 to 0x43.\r\n2. Encrypt the command header from step 1:\r\nThe following is an example of a RC4 modified routine that can be used. The first argument, box, would be the S-Box computed in step III.2 and the second argument, data, would be the command header from step 1.\r\ndef rc4_Mod_Crypt(box, data):\r\n    x = box[256]\r\n    y = box[257]\r\n    c = 0\r\n    out = []\r\n    for char in data:\r\n        x = (x + 1) % 256\r\n        y = (y + box[x]) % 256\r\n        box[x], box[y] = box[y], box[x]\r\n        z = ( (box[x] + box[y] )\u00260xff ) % 256\r\n        al = rol( box[z],4,8 )\r\n        out.append( chr( ord( data[c] ) ^ al ) )\r\n        box[z] = al\r\n        c+=1\r\n    box[256] = x\r\n    box[257] = y\r\n    return ''.join(out)\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 9 of 15\n\n3. Obtain the size of the payload and encrypt that value using the same RC4 algorithm as in step 2. The size of the\r\npayload should be the total decrypted size of the payload.\r\n4. Encrypt and send the payload to the stager in chunks:\r\na. Read 4,086 bytes from the payload. This is the maximum chunk size that the stager will accept.\r\nb. Build a command header (step 1 above) and update the following fields:\r\ni. Header size = size of payload chunk.\r\nii. Command = 1.\r\nc. Send the updated 10-byte command header to the stager.\r\nd. Send the encrypted payload chunk.\r\ne. Repeat steps a - d until payload is sent.\r\nFigure 7 shows an example of one payload chunk that is sent to the stager.\r\nFigure 7. Encrypted payload header and data.\r\nUpon receiving each chunk, the stager strips the command header and decrypts the payload chunk in memory.\r\nPayload In-Memory Loading\r\nOnce the payload is fully decrypted, the stager performs some basic checks to ensure that the payload conforms to\r\na Windows executable. It validates the DOS and PE header and that the payload is a DLL. It then direct-memory\r\nloads the payload and calls into its entry point (AddressOfEntryPoint). The direct memory load of the payload\r\nemulates that of the Windows PE loader – LoadLibrary. As a result, the PEB LDR_DATA_TABLE_ENTRY\r\nmetadata structures are not created and the PEB for the process running the shellcode has no record of the DLL\r\nloading, which can be used to detect rogue modules running on your host. This is visible in WinDbg running the\r\ncommand !address within the process that loaded the shellcode. An example is shown in Figure 8.\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 10 of 15\n\nFigure 8. Artifact of direct in-memory loaded DLL.\r\nIn-memory artifacts:\r\nType is MEM_PRIVATE, meaning it is private to the process that loaded it. On Windows platforms, DLLs\r\nare typically loaded as MEM_IMAGE so that they can be shared between different processes to save\r\nmemory space.\r\nProtection is PAGE_EXECUTE_READWRITE(RWX), which means the area is writable and executable\r\nwith a memory area containing an MZ header. The MZ header is the in-memory loaded module.\r\nThe output of the WinDbg !address command shown in Figure 8 spots the anomalous entry. The memory address\r\nof module 0x7ff4c2450000 was the result of private memory allocation, protection set to RWX and usage\r\ncontaining an MZ header.\r\nx64 Shellcode Behaviors\r\nThe following table describes the main behaviors of BendyBear.\r\nTable 1. x64 shellcode commands executed.\r\nBendyBear vs. WaterBear\r\nTable 2. Comparison of BendyBear and WaterBear.\r\nFile Type – WaterBear is a standalone PE/EXE. BendyBear is a x64 Shellcode that requires loader or code\r\ninjection.\r\nImplant Type – WaterBear is a stage-2 implant with many capabilities; BendyBear is a stage-0 downloader.\r\nModified RC4 Encryption – Both WaterBear and BendyBear use a modified RC4, but implement them slightly\r\ndifferently. WaterBear uses a 256 RC4 state box with byte shifting and addition within the key scheduling\r\nalgorithm. BendyBear uses a 258 RC4 state box and performs XOR within the key scheduling algorithm.\r\nAdditional Encryption – While both use encryption as a way to conceal artifacts, BendyBear was found to\r\ncontain additional XOR encryption steps.\r\n16-Byte XOR Key – Both use the same 16-byte XOR key to create the pre-session key:\r\n0x6162636465666768696A6B6C6D6E6f00\r\nAuthenticated C2 Communications – Both send an initial 10-byte challenge request followed by 32-byte session\r\nkeys.\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 11 of 15\n\nSignature Verification Magic Bytes – Both use the same matching magic byte verification values.\r\nChunked Payload – Both expect the payloads to be sent in encrypted chunks.\r\nPolymorphic Code – Both employ code manipulation during runtime execution with random bytes.\r\nIn-Memory Loading – Both support the in-memory loading of payloads.\r\nPEB Debugger Check – Both check to see if the code is being debugged.\r\nPattern Elimination –Both re-encrypt any decrypted strings upon use.\r\nEncrypt/Decrypt Function Routines – Both WaterBear and BendyBear obfuscate runtime function addresses.\r\nAPI Hooking – Variants of WaterBear implement API hooking, while BendyBear does not.\r\nProcess Hiding – Variants of WaterBear can hide processes via API hooking, while BendyBear does not support\r\nthis capability.\r\nNetwork Traffic Filtering – Variants of WaterBear can filter or hide network traffic via API hooking, while\r\nBendyBear does not support this capability.\r\nConclusion\r\nThe BendyBear shellcode contains advanced features that are not typically found in shellcode. The use of anti-analysis techniques and signature block verification indicate that the developers care about stealth and detection-evasion. Additionally, the use of custom cryptographic routines and byte manipulations suggest a high level of\r\ntechnical sophistication.\r\nPalo Alto Networks customers can be protected from the attacks outlined in this blog in the following ways:\r\nThe C2 domain used in this shellcode has been categorized as malware in DNS Security, URL Filtering and\r\nWildFire, which are security subscriptions for Next-Generation Firewall customers.\r\nCortex XDR can identify and block the shellcode during execution.\r\nApp-ID, the traffic classification system in Next-Generation Firewalls, is capable of identifying\r\napplications irrespective of port, protocol, encryption (SSH or SSL) or any other evasive tactic used by the\r\napplication. This shellcode attempts to communicate over TCP port 443 with traffic that does not conform\r\nto proper SSL or any other known application. As a matter of best practice, we advise customers to block\r\nunknown outbound TCP traffic in their security policies.\r\nIndicators of Compromise\r\nShellcode Samples\r\nx64 - (version 0.24)\r\n64CC899EC85F612270FCFB120A4C80D52D78E68B05CAF1014D2FE06522F1E2D0 wg1.inkeslive[.]com\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 12 of 15\n\nx86 - (version 0.1)\r\n49901034216a16cfd05c613f438eccee4a7bf6079a7988b3e7094d9498379558 web2008.rutentw[.]com\r\nx86 WaterBear Loaders\r\nThe following executables have been identified as loaders/injectors that contain older WaterBear x86 shellcode.\r\nThe shellcode code is identical to the x86 sample 49901034216.... (version 0.1) listed above.\r\n5d1414b47d88e95ae6612d3fc211c29b35cc5db4a8a992f5e27cff5203ebf44b\r\n9880ba4f93cade2f6bbb4cc8efdcf087e8ac51b5c209ee32ad8134eb87ef70e1\r\n682122f34027e3f8025928d446989b02952449f5e5930c2670f8f789f41573ff\r\n2a09ec2d6edadd06e18c841e0ed794ba3eeb21818476f75ccc0e5d40e08eac80\r\n76ef704d21fbaaceca8a131429ccfb9f5de3d8f43a160ddd281ffeafc391eb98\r\nAdditional Resources\r\nTaiwan News – Taiwan urges blocking 11 China-linked phishing domains.\r\niThome News – The Bureau of Investigation’s recent investigation of several cases of Taiwan Government\r\nagencies hacked.\r\nTeamT5 – Evil Hidden in Shellcode: The Evolution of malware DbgPrint.\r\nTrendMicro – WaterBear Returns, Uses API Hooking to Evade Security.\r\nTrendMicro – The Trail of BlackTech’s Cyber Espionage Campaigns.\r\nCryCraft Technology Corp - Taiwan Government Targeted by Multiple Cyberattacks in April 2020 Part 1:\r\nWaterbear Malware\r\nJPCERT/CC Eyes - ELF_PLEAD - Linux Malware Used by BlackTech\r\nAppendix\r\nShellcode Proof of Concept\r\nMock C2 server serving request to stager and sending a payload (DLL) that displays a message box:\r\npython.exe U42ETHOS_C2.py -l 8080 -p c:\\temp\\DLLSample.dll\r\n[+] Started U42ETHOS_C2.py ver 1.0.0 waiting for connection on TCP port 8080\r\n[!] Using payload file c:\\temp\\DLLSample.dll\r\n[!] Received new connection from: ('192.168.163.138', 49918)\r\n[-] Received Encrypted challenge Request Packet--\u003e 40da9a64bf3992d39db6\r\n[-] Decrypted challenge Request packet--\u003e 46401f8c032320000000\r\n[+] Session key 1--\u003e 9816f78b57fff54efb5419202d81a729\r\n[+] Session key 2--\u003e 6ec83a6e4d8bc4e28496cac865878574\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 13 of 15\n\n[+] Computed PreSessionKey--\u003e f97494ef32999226923e724c40efc829\r\n[+] Challenge command--\u003e a3601149a495d02598b7\r\n[-] Challenge key is--\u003e f55bf1f67d6ae90bf1ed3479875dcdcd\r\n[+] Payload Size is 00920100\r\n[!] Payload sent to stager. Check if executed\r\nFigure 9. Unit 42 mock C2 server.\r\nFigure 10. Example stager in-memory loading test DLL\r\nFigure 9 is a Python mock C2 server that was created by Unit 42 to interact with the stager. It is configured to\r\nlisten on TCP port 8080, and the payload is a test DLL that launches calc.exe and displays a message box (Hello,\r\nImplant). Figure 10 is a Windows 10 host running the shellcode in memory via a custom loader. The shellcode\r\nwas configured to communicate with the mock C2 server.\r\nNetwork Traffic for the Above Payload (truncated):\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 14 of 15\n\nFigure 11. Network traffic capture example.\r\nSource: https://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nhttps://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/bendybear-shellcode-blacktech/"
	],
	"report_names": [
		"bendybear-shellcode-blacktech"
	],
	"threat_actors": [
		{
			"id": "efa7c047-b61c-4598-96d5-e00d01dec96b",
			"created_at": "2022-10-25T16:07:23.404442Z",
			"updated_at": "2026-04-10T02:00:04.584239Z",
			"deleted_at": null,
			"main_name": "BlackTech",
			"aliases": [
				"BlackTech",
				"Canary Typhoon",
				"Circuit Panda",
				"Earth Hundun",
				"G0098",
				"Manga Taurus",
				"Operation PLEAD",
				"Operation Shrouded Crossbow",
				"Operation Waterbear",
				"Palmerworm",
				"Radio Panda",
				"Red Djinn",
				"T-APT-03",
				"TEMP.Overboard"
			],
			"source_name": "ETDA:BlackTech",
			"tools": [
				"BIFROST",
				"BUSYICE",
				"BendyBear",
				"Bluether",
				"CAPGELD",
				"DRIGO",
				"Deuterbear",
				"Flagpro",
				"GOODTIMES",
				"Gh0stTimes",
				"IconDown",
				"KIVARS",
				"LOLBAS",
				"LOLBins",
				"Linopid",
				"Living off the Land",
				"TSCookie",
				"Waterbear",
				"XBOW",
				"elf.bifrose"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "2646f776-792a-4498-967b-ec0d3498fdf1",
			"created_at": "2022-10-25T15:50:23.475784Z",
			"updated_at": "2026-04-10T02:00:05.269591Z",
			"deleted_at": null,
			"main_name": "BlackTech",
			"aliases": [
				"BlackTech",
				"Palmerworm"
			],
			"source_name": "MITRE:BlackTech",
			"tools": [
				"Kivars",
				"PsExec",
				"TSCookie",
				"Flagpro",
				"Waterbear"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "75024aad-424b-449a-b286-352fe9226bcb",
			"created_at": "2023-01-06T13:46:38.962724Z",
			"updated_at": "2026-04-10T02:00:03.164536Z",
			"deleted_at": null,
			"main_name": "BlackTech",
			"aliases": [
				"CIRCUIT PANDA",
				"Temp.Overboard",
				"Palmerworm",
				"G0098",
				"T-APT-03",
				"Manga Taurus",
				"Earth Hundun",
				"Mobwork",
				"HUAPI",
				"Red Djinn",
				"Canary Typhoon"
			],
			"source_name": "MISPGALAXY:BlackTech",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3b93ef3c-2baf-429e-9ccc-fb80d0046c3b",
			"created_at": "2025-08-07T02:03:24.569066Z",
			"updated_at": "2026-04-10T02:00:03.730864Z",
			"deleted_at": null,
			"main_name": "BRONZE CANAL",
			"aliases": [
				"BlackTech",
				"CTG-6177 ",
				"Circuit Panda ",
				"Earth Hundun",
				"Palmerworm ",
				"Red Djinn",
				"Shrouded Crossbow "
			],
			"source_name": "Secureworks:BRONZE CANAL",
			"tools": [
				"Bifrose",
				"DRIGO",
				"Deuterbear",
				"Flagpro",
				"Gh0stTimes",
				"KIVARS",
				"PLEAD",
				"Spiderpig",
				"Waterbear",
				"XBOW"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434124,
	"ts_updated_at": 1775826685,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fc69c34f5de302538fed6626a2a90e8a88332472.pdf",
		"text": "https://archive.orkl.eu/fc69c34f5de302538fed6626a2a90e8a88332472.txt",
		"img": "https://archive.orkl.eu/fc69c34f5de302538fed6626a2a90e8a88332472.jpg"
	}
}