The recent Notepad++ compromise should make you pause for a moment because the Chrysalis backdoor is exactly the type of malware those of in the industry lose sleep over.
Rapid7’s write-up on the Chrysalis backdoor is not alarming because it introduces a new malware technique. It’s alarming because it doesn’t.
There’s no zero-day exploit here. No exotic vulnerability chain. No clever trick that defenders haven’t seen before. Chrysalis works because it applies familiar techniques carefully, patiently, and in the exact places most environments assume are safe.
That discipline is what makes it dangerous.
The activity is tied to Lotus Blossom and, critically, to the recent Notepad++ supply chain compromise. That matters because it short-circuits a large portion of defensive controls before the malware ever runs. When a trusted application installer is abused, the malware doesn’t have to evade controls after execution. It arrives already inside the trust boundary, running where it is expected to run.
Once present on a system, Chrysalis executes using DLL sideloading. A legitimate Windows executable is placed alongside a malicious DLL that shares the name of a dependency the executable expects. When the binary starts, Windows resolves the dependency according to its normal search order and loads the malicious DLL automatically. No exploit is triggered. No warning is generated. The system behaves exactly as designed.
This is where the distinction between DLLs and executables matters. Executables are explicit. They are launched directly, logged clearly, and often scrutinized. DLLs are not. They exist to be loaded by other processes and inherit the identity and trust of whatever loads them. When a trusted binary loads a malicious DLL, execution remains within a trusted context.
As a result, the process tree remains unremarkable. A known executable starts, loads its dependencies, and continues running normally. There are no unusual parent-child relationships, no suspicious command-line arguments, and no secondary processes that clearly warrant escalation. From a monitoring perspective, nothing looks wrong.
After execution, Chrysalis minimizes its footprint by operating largely in memory. Instead of dropping a standalone payload to disk, functionality is loaded directly into the address space of the running process. This limits file artifacts, reduces opportunities for static detection, and complicates post-incident forensic analysis.
Chrysalis is not a single-purpose payload, either. It functions as a backdoor and loader. Once communication with attacker-controlled infrastructure is established, it can receive instructions, collect basic system information, and load additional code on demand. Reconnaissance is quiet and targeted, designed to answer simple questions about the host and environment rather than perform noisy scanning.
Command execution is supported directly. File operations, process interaction, and system-level actions occur under the identity of the trusted process that loaded the DLL. There is no separate malware process to observe. Everything happens inside execution paths defenders, systems, and security software already inherently trust.
Persistence is implemented using standard Windows mechanisms that survive reboot and time. These mechanisms are selected to blend into normal system behavior rather than stand out. The intent is durability without attention. The backdoor is designed to remain present quietly, not to announce itself.
That design choice explains why Chrysalis remained undetected for extended periods. It did not rely on unusual behavior. It did not generate conspicuous network traffic. It did not break systems or force investigation. It operated entirely within patterns that many environments implicitly accept as normal.
Chrysalis was not effective because it was novel. It was effective because it abused trust end to end: trusted software, trusted binaries, trusted execution paths, and trusted persistence mechanisms. The absence of alerts was not an accident. It was the goal.
We’ll be sending a separate Threat Intelligence email with indicators, hunting guidance, and deeper technical detail. This post is about understanding the mechanics and the shape of the threat, not enumerating every possible response.
What You Should Do Now
Identify where Notepad++ exists in managed environments and how it was deployed.
Validate whether application control and allow-listing policies account for DLL behavior, not just executables. Many environments implicitly trust DLL loads once the parent binary is allowed.
Apply targeted detection using the Chrysalis-specific indicators and behaviors provided in the Threat Intelligence update.
Chrysalis didn’t win by being loud or clever. It won by behaving exactly like something defenders expect to see.
And that should make everyone pause.
