{
	"id": "30c02cfc-a906-4fd8-af24-f7da4f737f2e",
	"created_at": "2026-04-06T00:17:33.289397Z",
	"updated_at": "2026-04-10T03:35:59.542721Z",
	"deleted_at": null,
	"sha1_hash": "603ca5a30dbb70f4435e6fcb27820241f7b330c1",
	"title": "The Chrysalis Backdoor: A Deep Dive into Lotus Blossom’s toolkit",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 517170,
	"plain_text": "The Chrysalis Backdoor: A Deep Dive into Lotus Blossom’s toolkit\r\nBy Rapid7\r\nPublished: 2026-02-02 · Archived: 2026-04-05 16:50:29 UTC\r\nRapid7 Labs, together with the Rapid7 MDR team, has uncovered a sophisticated campaign attributed to the\r\nChinese APT group Lotus Blossom. Active since 2009, the group is known for its targeted espionage campaigns\r\nprimarily impacting organizations across Southeast Asia and more recently Central America, focusing on\r\ngovernment, telecom, aviation, critical infrastructure, and media sectors.\r\nOur investigation identified a security incident stemming from a sophisticated compromise of the infrastructure\r\nhosting Notepad++, which was subsequently used to deliver a previously undocumented custom backdoor, which\r\nwe have dubbed Chrysalis.\r\n⠀\r\nFigure 1: Telemetry on the custom backdoor samples\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 1 of 23\n\n⠀\r\nBeyond the discovery of the new implant, forensic evidence led us to uncover several custom loaders in the wild.\r\nOne sample, “ConsoleApplication2.exe”, stands out for its use of Microsoft Warbird, a complex code protection\r\nframework, to hide shellcode execution. This blog provides a deep technical analysis of Chrysalis, the Warbird\r\nloader, and the broader tactic of mixing straightforward loaders with obscure, undocumented system calls.\r\nInitial access vector: Notepad++ and update.exe\r\nForensic analysis conducted by the MDR team suggests that the initial access vector aligns with publicly disclosed\r\nabuse of the Notepad++ distribution infrastructure. While reporting references both plugin replacement and\r\nupdater-related mechanisms, no definitive artifacts were identified to confirm exploitation of either. The only\r\nconfirmed behavior is that execution of “notepad++.exe” and subsequently “GUP.exe” preceded the execution of\r\na suspicious process “update.exe” which was downloaded from 95.179.213.0.\r\nAnalysis of update.exe\r\nFigure 2: Execution diagram of update.exe\r\n⠀\r\nAnalysis of “update.exe” shows the file is actually an NSIS installer, a tool commonly used by Chinese APT to\r\ndeliver initial payload.\r\nThe following are the extracted NSIS installer files:\r\n[NSIS].nsi\r\nDescription: NSIS Installation script\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 2 of 23\n\nSHA-256: 8ea8b83645fba6e23d48075a0d3fc73ad2ba515b4536710cda4f1f232718f53e\r\nBluetoothService.exe\r\nDescription: renamed Bitdefender Submission Wizard used for DLL sideloading\r\nSHA-256: 2da00de67720f5f13b17e9d985fe70f10f153da60c9ab1086fe58f069a156924\r\nBluetoothService\r\nDescription: Encrypted shellcode\r\nSHA-256: 77bfea78def679aa1117f569a35e8fd1542df21f7e00e27f192c907e61d63a2e\r\nlog.dll\r\nDescription: Malicious DLL sideloaded by BluetoothService.exe\r\nSHA-256: 3bdc4c0637591533f1d4198a72a33426c01f69bd2e15ceee547866f65e26b7ad\r\n⠀\r\nInstallation script is instructed to create a new directory “Bluetooth” in “%AppData%” folder, copy the\r\nremaining files there, change the attribute of the directory to HIDDEN and execute BluetoothService.exe.\r\nDLL sideloading\r\nShortly after the execution of BluetoothService.exe, which is actually a renamed legitimate Bitdefender\r\nSubmission Wizard abused for DLL sideloading, a malicious log.dll was placed alongside the executable, causing\r\nit to be loaded instead of the legitimate library. Two exported functions from log.dll are called by Bitdefender\r\nSubmission Wizard: LogInit and LogWrite.\r\nLogInit and LogWrite - Shellcode load, decrypt, execute\r\nLogInit loads BluetoothService into the memory of the running process.\r\nLogWrite has a more sophisticated goal – to decrypt and execute the shellcode.\r\nThe decryption routine implements a custom runtime decryption mechanism used to unpack encrypted data in\r\nmemory. It derives key material from previously calculated hash value and applies a stream‑cipher–like algorithm\r\nrather than standard cryptographic APIs. At a high level, the decryption routine relies on a linear congruential\r\ngenerator, with the standard constants 0x19660D and 0x3C6EF35F, combined with several basic data\r\ntransformation steps to recover the plaintext payload.\r\nOnce decrypted, the payload replaces the original buffer and all temporary memory is released. Execution is then\r\ntransferred to this newly decrypted stage, which is treated as executable code and invoked with a predefined set of\r\narguments, including runtime context and resolved API information.\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 3 of 23\n\nFigure 3: LogWrite internals\r\nIAT resolution\r\nLog.dll implements an API hashing subroutine to resolve required APIs during execution, reducing the likelihood\r\nof detection by antivirus and other security solutions.\r\nAPI hashing subroutine\r\nThe hashing algorithm will hash export names using FNV‑1a (fnv-1a hash 0x811C9DC5, fnv-1a prime\r\n0x1000193 observed), then apply a MurmurHash‑style avalanche finalizer (murmur constant 0x85EBCA6B\r\nobserved), and compare the result to a salted target hash.\r\nAnalysis of the Chrysalis backdoor\r\nThe shellcode, once decrypted by log.dll, is a custom, feature-rich backdoor we've named “Chrysalis”. Its wide\r\narray of capabilities indicates it is a sophisticated and permanent tool, not a simple throwaway utility. It uses\r\nlegitimate binaries to sideload a crafted DLL with a generic name, which makes simple filename-based detection\r\nunreliable. It relies on custom API hashing in both the loader and the main module, each with its own resolution\r\nlogic. This is paired with layered obfuscation and a fairly structured approach to C2 communication. Overall, the\r\nsample looks like something that has been actively developed over time, and we’ll be keeping an eye on this\r\nfamily and any future variants that show up.\r\nDecryption of the main module\r\nOnce the execution is passed to decrypted shellcode from log.dll, malware starts with decryption of the main\r\nmodule via a simple combination of XOR, addition and subtraction operations, with a hardcoded key\r\ngQ2JR\u00269;. See below the pseudocode of decryption routine:\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 4 of 23\n\n⠀\r\nchar XORKey[8] = \"gQ2JR\u00269;\";\r\nDWORD counter = 0;\r\nDWORD pos = BufferPosition;\r\nwhile (counter \u003c size) {\r\nBYTE k = XORKey[counter \u0026 7];\r\nBYTE x = encrypted[pos];\r\nx = x + k;\r\nx = x ^ k;\r\nx = x - k;\r\ndecrypted[pos] = x;\r\npos++;\r\ncounter++;\r\n}\r\n⠀\r\nXOR operation is performed 5 times in total, suggesting a section layout similar to PE format. Following the\r\ndecryption, malware will proceed to yet another dynamic IAT resolution using LoadLibraryA to acquire a handle\r\nto Kernel32.dll and GetProcAddress. Once exports are resolved, the jump is taken to the main module.\r\nMain module\r\nThe decrypted module is a reflective PE-like module that executes the MSVC CRT initialization sequence before\r\ntransferring control to the program’s main entry point. Once in the Main function, the malware will dynamically\r\nload DLLs in the following order: oleaut32.dll, advapi32.dll, shlwapi.dll, user32.dll, wininet.dll, ole32.dll and\r\nshell32.dll.\r\nNames of targeted DLLs are constructed on the run, using two separate subroutines. These two subroutines\r\nimplement a custom, position-dependent character obfuscation scheme. Each character is transformed using a\r\ncombination of bit rotations, conditional XOR operations, and index-based arithmetic, ensuring that identical\r\ncharacters encrypt differently depending on their position. The second routine reverses this process at runtime,\r\nreconstructing the original plaintext string just before it is used. The purpose of these two functions is not only to\r\nconceal strings, but also to intentionally complicate static analysis and hinder signature-based detection.\r\nAfter the DLL name is reconstructed, the Main module implements another, more sophisticated API hashing\r\nroutine.\r\nAPI hashing subroutine\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 5 of 23\n\nFigure 4: API hashing diagram\r\n⠀\r\nThe first difference between this and the API hashing routine used by the loader is that this subroutine accepts\r\nonly a single argument: the hash of the target API. To obtain the DLL handle, the malware walks the PEB to reach\r\nthe InMemoryOrderModuleList, then parses each module’s export table, skipping the main executable, until it\r\nresolves the desired API. Instead of relying on common hashing algorithms, the routine employs multi-stage\r\narithmetic mixing with constants of MurmurHash-style finalization. API names are processed in 4-byte blocks\r\nusing multiple rotation and multiplication steps, followed by a final diffusion phase before comparison with the\r\nsupplied hash. This design significantly complicates static recovery of resolved APIs and reduces the effectiveness\r\nof traditional signature-based detection. As a fallback, the resolver supports direct resolution via GetProcAddress\r\nif the target hash is not found through the hashing method. The pointer to GetProcAddress is obtained earlier\r\nduring the “main module preparation” stage.\r\n⠀\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 6 of 23\n\nFigure 5: API hashing internals\r\nConfig decryption\r\nThe next step in the malware’s execution is to decrypt the configuration. Encrypted configuration is stored in the\r\nBluetoothService file at offset 0x30808 with the size of 0x980. Algorithm for the decryption is RC4 with the key\r\nqwhvb^435h\u0026*7. This revealed the following information:\r\nCommand and Control (C2) url: https://api.skycloudcenter.com/a/chat/s/70521ddf-a2ef-4adf-9cf0-\r\n6d8e24aaa821\r\nName of the module: BluetoothService\r\nUser agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/80.0.4044.92 Safari/537.36\r\nThe URL structure of the C2 is interesting, especially the section /a/chat/s/{GUID}), which appears to be the\r\nidentical format used by Deepseek API chat endpoints. It looks like the actor is mimicking the traffic to stay below\r\nthe radar. \r\nDecrypted configuration doesn’t give much useful information besides the C2. The name of the module is too\r\ngeneric and the user agent belongs to Google Chrome browser. The URL resolves to 61.4.102.97, IP address based\r\nin Malaysia. At the time of the writing of this blog, no other file has been seen to communicate with this IP and\r\nURL.\r\nPersistence and command-line arguments\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 7 of 23\n\nTo determine the next course of action, malware checks command-line arguments highlighted in Table 1 and\r\nchooses one of four potential paths. If the amount of the command-line arguments is greater than two, the process\r\nwill exit. If there is no additional argument, persistence is set up primarily via service creation or registry as a fall\r\nback mechanism.\r\nSee Table 2 below:\r\nArgument Mode Action\r\n(None) Installation\r\nInstalls persistence (Service or Registry) pointing to binary with -i flag, then\r\nterminates.\r\n-i Launcher\r\nSpawns a new instance of itself with the -k flag via ShellExecuteA, then\r\nterminates.\r\n-k Payload\r\nSkips installation checks and executes the main malicious logic (C2 \u0026\r\nShellcode).\r\n⠀\r\nWith the expected arguments present, the malware proceeds to its primary functionality - to gather information\r\nabout the infected asset and initiate the communication with C2.\r\nInformation gathering and C2 communication\r\nA mutex Global\\\\Jdhfv_1.0.1 is registered to enforce single instance execution on the host. If it already exists,\r\nmalware is terminated. If the check is clear, information gathering begins by querying for the following: current\r\ntime, installed AVs, OS version, user name and computer name. Next, computer name, user name, OS version and\r\nstring 1.01 are concatenated and the data are hashed using FNV-1A. This value is later turned into its decimal ascii\r\nrepresentation and used most likely as a unique identifier of the infected host. \r\nFinal buffer uses a dot as delimiter and follows this pattern: \r\n⠀\r\n\u003cUniqueID\u003e.\u003cComputerName\u003e.\u003cUserName\u003e.\u003cOSVersion\u003e.\u003c127.0.0.1\u003e.\u003cAVs\u003e.\u003cDateAndTime\u003e\r\n⠀\r\nThe last piece of information added to the beginning of the buffer is a string 4Q. The buffer is then RC4 encrypted\r\nwith the key vAuig34%^325hGV.\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 8 of 23\n\nFollowing data encryption, the malware establishes an internet connection using previously mentioned user agent\r\nand C2 api.skycloudcenter.com over port 443. Data is then transferred via HttpSendRequestA using the POST\r\nmethod. Response from the server is then read to a temporary buffer which is later decrypted using the same key\r\nvAuig34%^325hGV.\r\nResponse and command processing\r\nNote: C2 server was already offline during the initial analysis, preventing recovery of any network data. As a\r\nresult, and due to the complexity of the malware, parts of the following analysis may contain minor inaccuracies.\r\nThe response from the C2 undergoes multiple checks before further processing. First, the HTTP response code is\r\ncompared against the hardcoded value 200 (0xC8), indicating a successful request, followed by a validation of the\r\nassociated WinInet handle to ensure no error occurred. The malware then verifies the integrity of the received\r\npayload and execution proceeds only if at least one valid structure is detected. Next, malware looks into the\r\nresponse data for a small tag to determine what to do next. Tag is used as a condition for a switch statement with\r\n16 possible cases. The default case will simply set up a flag to TRUE. Setting up this flag will result in\r\ncompletely jumping out of the switch. Other switch cases includes following options:\r\n⠀\r\nChar representation Hex representation Purpose\r\n4T 0x3454 Spawn interactive shell\r\n4U 0x3455 Send ‘OK’ to C2\r\n4V 0x3456 Create process\r\n4W 0x3457 Write file to disk\r\n4X 0x3458 Write chunk to open file\r\n4Y 0x3459 Read \u0026 send data\r\n4Z 0x345A Break from switch\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 9 of 23\n\n4\\\\ 0x345C Uninstall / Clean up\r\n4] 0x345D Sleep\r\n4_ 0x345F Get info about logical drives\r\n4` 0x3460 Enumerate files information\r\n4a 0x3661 Delete file \r\n4b 0x3662 Create directory\r\n4c 0x3463 Get file from C2\r\n4d 0x3464 Send file to C2\r\n⠀\r\n4T - The malware implements a fully interactive cmd.exe reverse shell using redirected pipes. Incoming\r\ncommands from the C2 are converted from UTF‑8 to the system OEM code page before being written to the\r\nshell’s standard input, while a dedicated thread continuously reads shell output, converts it from OEM encoding to\r\nUTF‑8 using GetOEMCP API, and forwards the result back to the C2.\r\n4V - This option allows remote process execution by invoking CreateProcessW on a C2-supplied command line\r\nand relaying execution status back to the C2.\r\n4W - This option implements a remote file write capability, parsing a structured response containing a destination\r\npath and file contents, converting encodings as necessary, writing the data to disk, and returning a formatted\r\nstatus message to the command-and-control server.\r\n4X - Similar to the previous switch, it supports a remote file-write capability, allowing the C2 to drop arbitrary\r\nfiles on the victim system by supplying a UTF-8 filename and associated data blob.\r\n4Y - Switch implements a remote file-read capability. It opens a specified file with, retrieves its size, reads the\r\nentire contents into memory, and transmits the data back to the C2. \r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 10 of 23\n\n4\\\\ - The option implements a full self-removal mechanism. It deletes auxiliary payload files, removes\r\npersistence artifacts from both the Windows Service registry hive and the Run key, generates and executes a\r\ntemporary batch file u.bat to delete the running executable after termination, and finally removes the batch script\r\nitself. \r\n4_ - Here malware enumerates information about logical drivers using GetLogicalDriveStringsA\r\nand GetDriveTypeA APIs and sends the information back to the C2.\r\n4` - This switch option shares similarities with previously analyzed data exfiltration function - 4Y. However, its\r\nprimary purpose differs. Instead of transmitting preexisting data, it enumerates files within a specified directory,\r\ncollects per-file metadata (timestamps, size, and filename), serializes the results into a custom buffer format, and\r\nsends the aggregated listing to the C2.\r\n4a - 4b - 4c - 4d - In the last 4 cases, malware implements a custom file transfer protocol over its C2 channel.\r\nCommands 4a and 4b act as control messages used to initialize file download and upload operations\r\nrespectively, including file paths, offsets, and size validation. Once initialized, the actual data transfer occurs in a\r\nchunked fashion using commands 4c (download) and 4d (upload). Each chunk is wrapped in a fixed-size 40-byte\r\nresponse structure, validated for successful HTTP status and correct structure count before processing. Transfers\r\ncontinue until the C2 signals completion via a non-zero termination flag, at which point file handles and buffers\r\nare released.\r\nAdditional artifacts discovered on the infected host\r\nDuring the initial forensics analysis of the affected asset, Rapid7’s MDR team observed execution of following\r\ncommand:\r\n⠀\r\nC:\\ProgramData\\USOShared\\svchost.exe-nostdlib -run\r\nC:\\ProgramData\\USOShared\\conf.c\r\n⠀\r\nThe retrieved folder “USOShared” from the infected asset didn’t contain svchost.exe but it contained “libtcc.dll”\r\nand “conf.c”. The hash of the binary didn’t match any known legitimate version but the command line arguments\r\nand associated “libtcc.dll” suggested that svchost.exe is in fact renamed Tiny-C-Compiler. To confirm this, we\r\nreplicated the steps of the attacker successfully loaded shellcode from “conf.c” into the memory of “tcc.exe”,\r\nconfirming our previous hypothesis. \r\nAnalysis of conf.c\r\nThe C source file contains a fixed size (836) char buffer containing shellcode bytes which is later casted to a\r\nfunction pointer and invoked. The shellcode is consistent with 32-bit version of Metasploit’s block API.\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 11 of 23\n\nThe shellcode loads Wininet.dll using LoadLibraryA, resolves Internet-related APIs such as InternetConnectA\r\nand HttpSendRequestA, and downloads a file from api.wiresguard.com/users/admin. The file is read into a\r\nnewly allocated buffer, and execution is then transferred to the start of the 2000-byte second-stage shellcode. \r\n⠀\r\nFigure 6: Shellcode decryption stub\r\n⠀\r\nThis stub is responsible for decrypting the next payload layer and transferring execution to it. It uses a rolling\r\nXOR-based decryption loop before jumping directly to the decrypted code.\r\nA quick look into the decrypted buffer revealed an interesting blob with a repeated string CRAZY, hinting at an\r\nadditional XORed layer, later confirmed by a quick test.\r\n⠀\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 12 of 23\n\nFigure 7: Repeated XOR key “CRAZY”\r\n⠀\r\nFigure 8: Decrypted configuration\r\n⠀\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 13 of 23\n\nParsing of the decrypted configuration data confirms that retrieved shellcode is Cobalt Strike (CS) HTTPS\r\nbeacon with http-get api.wiresguard.com/update/v1 and http-post api.wiresguard.com/api/FileUpload/submit\r\nurls.\r\nAnalysis of the initial evidence revealed a consistent execution chain: a loader embedding Metasploit block_api\r\nshellcode that downloads a Cobalt Strike beacon. The unique decryption stub and configuration XOR key\r\nCRAZY allowed us to pivot into an external hunt, uncovering additional loader variants.\r\n⠀\r\nFigure 9: Execution flow followed by conf.c and other loaders\r\nVariation of loaders and shellcode\r\nIn the last year, four similar files were uploaded to public repositories.\r\nLoader 1:\r\nSHA-256: 0a9b8df968df41920b6ff07785cbfebe8bda29e6b512c94a3b2a83d10014d2fd\r\nShellcode SHA-256: 4c2ea8193f4a5db63b897a2d3ce127cc5d89687f380b97a1d91e0c8db542e4f8\r\nUser Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/92.0.4472.114 Safari/537.36\r\nURL hosting CS beacon: http://59[.]110.7.32:8880/uffhxpSy\r\nCS http-get URL: http://59[.]110.7.32:8880/api/getBasicInfo/v1\r\nCS http-post URL: http://59[.]110.7.32:8880/api/Metadata/submit\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 14 of 23\n\nLoader 2:\r\nSHA-256: e7cd605568c38bd6e0aba31045e1633205d0598c607a855e2e1bca4cca1c6eda\r\nShellcode SHA-256: 078a9e5c6c787e5532a7e728720cbafee9021bfec4a30e3c2be110748d7c43c5\r\nUser Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/92.0.4472.114 Safari/537.36\r\nURL hosting CS beacon: http://124[.]222.137.114:9999/3yZR31VK\r\nCS http-get URL: http://124[.]222.137.114:9999/api/updateStatus/v1\r\nCS http-post URL: http://124[.]222.137.114:9999/api/Info/submit\r\nLoader 3:\r\nSHA-256: b4169a831292e245ebdffedd5820584d73b129411546e7d3eccf4663d5fc5be3\r\nShellcode SHA-256: 7add554a98d3a99b319f2127688356c1283ed073a084805f14e33b4f6a6126fd\r\nUser Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/134.0.0.0 Safari/537.36\r\nURL hosting CS beacon: https://api[.]wiresguard[.]com/users/system\r\nCS http-get URL: https://api[.]wiresguard[.]com/api/getInfo/v1\r\nCS http-post URL: https://api[.]wiresguard[.]com/api/Info/submit\r\nLoader 4:\r\nSHA-256: fcc2765305bcd213b7558025b2039df2265c3e0b6401e4833123c461df2de51a\r\nShellcode SHA-256: 7add554a98d3a99b319f2127688356c1283ed073a084805f14e33b4f6a6126fd\r\nUser Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/134.0.0.0 Safari/537.36\r\nURL hosting CS beacon: https://api[.]wiresguard[.]com/users/system\r\nCS http-get URL: https://api[.]wiresguard[.]com/api/getInfo/v1\r\nCS http-post URL: https://api[.]wiresguard[.]com/api/Info/submit\r\n⠀\r\nFrom all the loaders we analyzed, Loader 3 piqued our interest for three reasons - shellcode encryption\r\ntechnique, execution , and almost identical C2 to beacon that was found on the infected asset. All the previous\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 15 of 23\n\nsamples used a pretty common technique to execute the shellcode - decrypt embedded shellcode in user space,\r\nchange the protection of memory region to executable state, and invoke decrypted code via CreateThread /\r\nCreateRemoteThread; Loader 3 (original name “ConsoleApplication2.exe”) violates this approach. \r\nAnalysis of Loader 3 - ConsoleApplication2.exe \r\nAt the first glance, the logic of the sample is straightforward: Load the DLL clipc.dll, overwrite first 0x490 bytes,\r\nchange the protection to PAGE_EXECUTE_READ (0x20), and then invoke NtQuerySystemInformation. Two\r\ninteresting notes to highlight here - bytes copied into the memory region of clipc.dll are not valid shellcode and\r\nNtquerySystemInformation is used to “Retrieve the specified system information”, not to execute code.\r\n⠀\r\nFigure 10: Snippet from ConsoleApplication2.exe\r\n⠀\r\nLooking into the copied data reveals two “magic numbers” DEADBEEF and CAFEAFE, but nothing else.\r\nHowever, the execution of shellcode is somehow successful, so what’s going on?\r\n⠀\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 16 of 23\n\nFigure 11: Data copied into clipc.dll\r\n⠀\r\nAccording to the official documentation, the first parameter of NtQuerySystemInformation is of type\r\nSYSTEM_INFORMATION_CLASS which specifies the category of system information to be queried. During\r\nstatic analysis in IDA Pro, this parameter was initially identified as SystemExtendedProcessInformation|0x80\r\nbut looking for this value in MSDN and other public references didn’t provide any explanation on how the\r\nexecution was achieved. But, searching for the original value passed to the function (0xB9) uncovered something\r\ninteresting. The following blog by DownWithUp covers Microsoft Warbird, which could be described as an\r\ninternal code protection and obfuscation framework. These resources confirm IDA misinterpretation of the\r\nargument which should be SystemCodeFlowTransition, a necessary argument to invoke Warbird functionality.\r\nAdditionally, DownWithUp’s blog post mentioned the possible operations:\r\n⠀\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 17 of 23\n\nFigure 12: Warbird operations documented by DownWithUp\r\n⠀\r\nReferring to the snippet we saw from “ConsoleApplication2.exe”, the operation is equal to WbHeapExecuteCall\r\nwhich gives us the answer on how the shellcode gained execution. Thanks to work of other researchers, we also\r\nknow that this technique only works if the code resides inside of memory of Microsoft signed binary, thus\r\nrevealing why clipc.dll has been used. The blog post from cirosec also contains a link for their POC of this\r\ntechnique which is almost the same replica of “ConsoleApplication2.exe”, hinting that author of\r\n“ConsoleApplication2.exe” simply copied it and modified to execute Metasploit block_api shellcode instead of\r\nthe benign calc from POC. The comparison of the Cobalt Strike beacon configuration delivered via “conf.c” and\r\n“ConsoleApplication2.exe” revealed shared trades between these two, most notably domain, public key, and\r\nprocess injection technique.\r\nAttribution to Lotus Blossom\r\nAttribution is primarily based on strong similarities between the initial loader observed in this intrusion and\r\npreviously published Symantec research. Particularly the use of a renamed “Bitdefender Submission Wizard” to\r\nside-load “log.dll” for decrypting and executing an additional payload.\r\nIn addition, similarities of the execution chain of “conf.c” retrieved from the infected asset and other loaders that\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 18 of 23\n\nwe found, supported by the same public key extracted from CS beacons delivered through “conf.c” and\r\n“ConsoleApplication2.exe” suggests with moderate confidence, that the threat actor behind this campaign is likely\r\nLotus Blossom.\r\nConclusion\r\nThe discovery of the Chrysalis backdoor and the Warbird loader highlights an evolution in Lotus Blossom's\r\ncapabilities. While the group continues to rely on proven techniques like DLL sideloading and service persistence,\r\ntheir multi-layered shellcode loader and integration of undocumented system calls (NtQuerySystemInformation)\r\nmark a clear shift toward more resilient and stealth tradecraft.\r\nWhat stands out is the mix of tools: the deployment of custom malware (Chrysalis) alongside commodity\r\nframeworks like Metasploit and Cobalt Strike, together with the rapid adaptation of public research (specifically\r\nthe abuse of Microsoft Warbird). This demonstrates that Lotus Blossom is actively updating their playbook to stay\r\nahead of modern detection.\r\nRapid7 customers\r\nInsightIDR and MDR\r\nInsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7's\r\nexpansive library of detection rules. Suspicious Process - Child of Notepad++ Updater (gup.exe) and Suspicious\r\nProcess - Chrysalis Backdoor are two examples of deployed detections that will alert on behavior related to\r\nChrysalis. Rapid7 will also continue to iterate detections as new variants emerge, giving customers continuous\r\nprotection without manual tuning.\r\nIntelligence Hub\r\nCustomers using Rapid7’s Intelligence Hub gain direct access to Chrysalis backdoor, Metasploit loaders and\r\nCobalt Strike IOCs, including any future indicators as they are identified.\r\nIndicators of compromise (IoCs)\r\nFile indicators\r\nNote: data may appear cut-off or hidden due to the string lengths in column 2. You can copy the full string by\r\nhighlighting what is visible.\r\nupdate.exe a511be5164dc1122fb5a7daa3eef9467e43d8458425b15a640235796006590c9\r\n[NSIS.nsi] 8ea8b83645fba6e23d48075a0d3fc73ad2ba515b4536710cda4f1f232718f53e\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 19 of 23\n\nBluetoothService.exe 2da00de67720f5f13b17e9d985fe70f10f153da60c9ab1086fe58f069a156924\r\nBluetoothService 77bfea78def679aa1117f569a35e8fd1542df21f7e00e27f192c907e61d63a2e\r\nlog.dll 3bdc4c0637591533f1d4198a72a33426c01f69bd2e15ceee547866f65e26b7ad\r\nu.bat 9276594e73cda1c69b7d265b3f08dc8fa84bf2d6599086b9acc0bb3745146600\r\nconf.c f4d829739f2d6ba7e3ede83dad428a0ced1a703ec582fc73a4eee3df3704629a\r\nlibtcc.dll 4a52570eeaf9d27722377865df312e295a7a23c3b6eb991944c2ecd707cc9906\r\nadmin 831e1ea13a1bd405f5bda2b9d8f2265f7b1db6c668dd2165ccc8a9c4c15ea7dd\r\nloader1 0a9b8df968df41920b6ff07785cbfebe8bda29e6b512c94a3b2a83d10014d2fd\r\nuffhxpSy 4c2ea8193f4a5db63b897a2d3ce127cc5d89687f380b97a1d91e0c8db542e4f8\r\nloader2 e7cd605568c38bd6e0aba31045e1633205d0598c607a855e2e1bca4cca1c6eda\r\n3yzr31vk 078a9e5c6c787e5532a7e728720cbafee9021bfec4a30e3c2be110748d7c43c5\r\nConsoleApplication2.exe b4169a831292e245ebdffedd5820584d73b129411546e7d3eccf4663d5fc5be3\r\nsystem 7add554a98d3a99b319f2127688356c1283ed073a084805f14e33b4f6a6126fd\r\ns047t5g.exe fcc2765305bcd213b7558025b2039df2265c3e0b6401e4833123c461df2de51a\r\nNetwork indicators\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 20 of 23\n\n95.179.213.0\r\napi[.]skycloudcenter[.]com\r\napi[.]wiresguard[.]com\r\n61.4.102.97\r\n59.110.7.32\r\n124.222.137.114\r\nMITRE TTPs\r\nATT\u0026CK ID Name\r\nT1204.002 User Execution: Malicious File\r\nT1036 Masquerading\r\nT1027 Obfuscated Files or Information\r\nT1027.007 Obfuscated Files or Information: Dynamic API Resolution\r\nT1140 Deobfuscate/Decode Files or Information\r\nT1574.002 DLL Side-Loading\r\nT1106 Native API\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 21 of 23\n\nT1055 Process Injection\r\nT1620 Reflective Code Loading\r\nT1059.003 Command and Scripting Interpreter: Windows Command Shell\r\nT1083 File and Directory Discovery\r\nT1005 Data from Local System\r\nT1105 Ingress Tool Transfer\r\nT1041 Exfiltration Over C2 Channel\r\nT1071.001 Application Layer Protocol: Web Protocols (HTTP/HTTPS)\r\nT1573 Encrypted Channel\r\nT1547.001 Boot or Logon Autostart Execution: Registry Run Keys\r\nT1543.003 Create or Modify System Process: Windows Service\r\nT1480.002 Execution Guardrails: Mutual Exclusion\r\nT1070.004 Indicator Removal on Host: File Deletion\r\n*IOCs contributed by @AIexGP on X.\r\nMitigation guidance\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 22 of 23\n\nRapid7 recommends updating to the latest version of Notepad++.  In addition, the IoCs provided above and within\r\nRapid7 Intelligence Hub can be used to hunt within your logs during the timeframe of June through November,\r\n2025, as this is the timeframe when the backdoor activity is known to have been taking place. \r\nInterested in learning more?\r\nCatch Inside Chrysalis, Rapid7's webinar led by Christiaan Beek, on-demand via BrightTALK.\r\nSource: https://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nhttps://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/"
	],
	"report_names": [
		"tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit"
	],
	"threat_actors": [
		{
			"id": "2fa14cf4-969f-48bc-b68e-a8e7eedc6e98",
			"created_at": "2022-10-25T15:50:23.538608Z",
			"updated_at": "2026-04-10T02:00:05.378092Z",
			"deleted_at": null,
			"main_name": "Lotus Blossom",
			"aliases": [
				"Lotus Blossom",
				"DRAGONFISH",
				"Spring Dragon",
				"RADIUM",
				"Raspberry Typhoon",
				"Bilbug",
				"Thrip"
			],
			"source_name": "MITRE:Lotus Blossom",
			"tools": [
				"AdFind",
				"Impacket",
				"Elise",
				"Hannotog",
				"NBTscan",
				"Sagerunex",
				"certutil"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "c21da9ce-944f-4a37-8ce3-71a0f738af80",
			"created_at": "2025-08-07T02:03:24.586257Z",
			"updated_at": "2026-04-10T02:00:03.804264Z",
			"deleted_at": null,
			"main_name": "BRONZE ELGIN",
			"aliases": [
				"CTG-8171 ",
				"Lotus Blossom ",
				"Lotus Panda ",
				"Lstudio",
				"Spring Dragon "
			],
			"source_name": "Secureworks:BRONZE ELGIN",
			"tools": [
				"Chrysalis",
				"Cobalt Strike",
				"Elise",
				"Emissary Trojan",
				"Lzari",
				"Meterpreter"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "87a20b72-ab72-402f-9013-c746c8458b0b",
			"created_at": "2023-01-06T13:46:38.293223Z",
			"updated_at": "2026-04-10T02:00:02.915184Z",
			"deleted_at": null,
			"main_name": "LOTUS PANDA",
			"aliases": [
				"Red Salamander",
				"Lotus BLossom",
				"Billbug",
				"Spring Dragon",
				"ST Group",
				"BRONZE ELGIN",
				"ATK1",
				"G0030",
				"Lotus Blossom",
				"DRAGONFISH"
			],
			"source_name": "MISPGALAXY:LOTUS PANDA",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "eaa8168f-3fab-4831-aa60-5956f673e6b3",
			"created_at": "2022-10-25T16:07:23.805824Z",
			"updated_at": "2026-04-10T02:00:04.754761Z",
			"deleted_at": null,
			"main_name": "Lotus Blossom",
			"aliases": [
				"ATK 1",
				"ATK 78",
				"Billbug",
				"Bronze Elgin",
				"CTG-8171",
				"Dragonfish",
				"G0030",
				"G0076",
				"Lotus Blossom",
				"Operation Lotus Blossom",
				"Red Salamander",
				"Spring Dragon",
				"Thrip"
			],
			"source_name": "ETDA:Lotus Blossom",
			"tools": [
				"BKDR_ESILE",
				"Catchamas",
				"EVILNEST",
				"Elise",
				"Group Policy Results Tool",
				"Hannotog",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"Mimikatz",
				"PsExec",
				"Rikamanu",
				"Sagerunex",
				"Spedear",
				"Syndicasec",
				"WMI Ghost",
				"Wimmie",
				"gpresult"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "bc289ba8-bc61-474c-8462-a3f7179d97bb",
			"created_at": "2022-10-25T16:07:24.450609Z",
			"updated_at": "2026-04-10T02:00:04.996582Z",
			"deleted_at": null,
			"main_name": "Avalanche",
			"aliases": [],
			"source_name": "ETDA:Avalanche",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434653,
	"ts_updated_at": 1775792159,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/603ca5a30dbb70f4435e6fcb27820241f7b330c1.pdf",
		"text": "https://archive.orkl.eu/603ca5a30dbb70f4435e6fcb27820241f7b330c1.txt",
		"img": "https://archive.orkl.eu/603ca5a30dbb70f4435e6fcb27820241f7b330c1.jpg"
	}
}