When legitimate software becomes the vehicle of an attack

We recently saw that a simple charging station could become an unexpected cybersecurity surface. The example was a reminder of how digital risks now reside in places that executives do not always spontaneously associate with IT. Another recent case pushes this reflection even further: this time, the risk did not come from a device we had forgotten to think of as a computer, but from perfectly legitimate software that users could reasonably believe was trustworthy.

A campaign observed in Ukraine used an authentic version of Notepad++ together with a fake plugin to install various malicious components. The official software and its distribution servers had not been compromised. Instead, the attackers had assembled their own archive containing a legitimate version of the application and a malicious library that was then loaded by the normal Notepad++ extension mechanism.

This case perfectly illustrates a reality that IT and cybersecurity teams face more and more often: attackers do not always need to break a technology. They can exploit its normal operation, its reputation, or the trust we place in it. For businesses and government organizations, this evolution requires moving beyond a view of cybersecurity based solely on hunting for malicious software or known vulnerabilities. Security must also make it possible to recognize when a legitimate component starts being used in a context that no longer is.

Discussion

The Notepad++ case is particularly interesting because the software itself was not responsible for the attack. According to the elements reported by CERT-UA, the user first received an archive containing, among other things, a script presented as a document. That script then downloaded a second archive containing an official version of Notepad++, a malicious library, and other components. When Notepad++ was launched, it loaded the library using its usual extension mechanism. The program was therefore doing exactly what it had been designed to do.

This nuance is essential. It shows that the traditional distinction between a “good program” and a “bad program” is becoming insufficient for understanding certain modern attacks. An authentic application can execute an unwanted component. An administration tool can be hijacked. A legitimate script can be used to automate an intrusion. A scheduled task, perfectly normal in Windows, can be used to maintain a persistent presence on a compromised system. Taken individually, each of these mechanisms has a legitimate function. It is their context, their sequence, and the intent behind their use that turns an ordinary operation into malicious activity.

Attackers understood the value of this ambiguity long ago. The better known and more commonly used a technology is, the less likely its appearance is to arouse immediate suspicion. An unknown executable attracts attention. Notepad++, PowerShell, a compression utility, or a remote administration tool can, by contrast, blend far more easily into an organization's normal activity. Trust then becomes an attack surface in its own right.

This evolution connects directly to the principles of Zero Trust. An authorized application should not necessarily enjoy unlimited trust simply because its name, its publisher, or its digital signature is known. Its behavior must also be examined. Which files does it load? Which processes does it launch? Which systems does it communicate with? Which privileges does it use? Does its activity really correspond to what that application should normally do? A recognized application whose behavior becomes unusual deserves just as much attention as an unknown program.

This obviously does not mean that digital signatures, application allowlists, or antivirus software have lost their usefulness. They remain essential layers of protection. The problem arises when an organization implicitly asks them to produce a certainty that no technology can genuinely offer. A signature can confirm the origin or integrity of a given component; it does not guarantee that the entire environment around it is equally trustworthy. In the case reported by Clubic, the official version of Notepad++ was indeed legitimate. It was the package assembled around it that was not.

This distinction brings us back to a fundamental principle of modern cybersecurity: the security of a system rarely depends on a single component. It depends on a chain. The software, its extensions, the libraries it loads, the user's rights, the execution mechanisms, the network connections, the security controls, and the organizational processes all contribute to the final outcome. A weakness or a faulty assumption somewhere in that chain can allow an attacker to bypass protections that are otherwise very strong elsewhere.

For organizations, one of the challenges therefore becomes better understanding the possible paths through their environment. A compromised workstation should not automatically open significant access to other systems. An application should have only the permissions necessary for it to function. A process should be able to communicate only with the resources corresponding to its function, where that restriction is realistic. This logic of least privilege and segmentation reduces the ability of a localized incident to become a far broader problem.

This is where resilience usefully complements prevention. A security strategy based exclusively on the idea of preventing any compromise inevitably ends up hitting its limits. There will always be new vulnerabilities, new evasion techniques, and new ways to exploit tools already present in the environment. A resilient architecture instead starts from the assumption that a first barrier may one day be crossed. It then seeks to limit the consequences, slow the attacker's progress, detect abnormal behavior, and enable a rapid response.

Behavior is taking on growing importance in this detection capability. A text editor that normally opens files has a certain activity profile. If it suddenly begins triggering a series of scripts, creating scheduled tasks, or establishing unusual communications, that context can be a meaningful signal. The challenge is therefore no longer only to recognize a known malicious file, but also to identify a sequence of activities that does not match the system's expected operation.

This approach becomes even more important as IT environments grow more complex. Organizations today use a combination of workstations, cloud services, SaaS software, APIs, connected devices, legacy applications, and, increasingly, artificial intelligence agents. Each of these components introduces its own trust mechanisms and its own dependencies. Internal teams must maintain their understanding of this environment while keeping up with the constant evolution of attack techniques.

The scale of this responsibility must be acknowledged. An IT or cybersecurity team can be extremely competent and still have to monitor thousands of assets, accounts, software versions, configurations, and relationships between systems simultaneously. Meanwhile, attackers can devote their efforts to finding a single exploitable weakness. This asymmetry explains why adding external expertise can be a risk-reduction strategy rather than an admission that existing teams are inadequate.

A specialized partner brings a different perspective on the same environment. Internal teams know their operations, their constraints, and the history of their systems in depth. That knowledge is irreplaceable. An outside view can nevertheless challenge assumptions that have become normal over time, spot dependencies that cut across several departments, or examine the architecture against attack scenarios that operational teams do not necessarily have time to explore.

It is precisely along these lines that Quantum Beyond can intervene. Our role is to work alongside existing teams to add an additional layer of understanding and risk reduction. Enterprise security architecture makes it possible to examine the relationships among the various components rather than considering each one in isolation. Security audits and assessments make it possible to verify configurations, controls, and dependencies. IAM and Zero Trust principles help reduce privileges and implicit trust. Segmentation limits the paths available when a system is compromised, while cyber resilience approaches seek to preserve operational capability when preventive measures alone are no longer enough.

This approach also matters from a financial point of view. Cybersecurity can easily turn into an accumulation of products: a new incident leads to a new tool, a new threat produces a new expense, and the architecture gradually becomes more complex. Yet an environment with more solutions is not necessarily proportionally more secure. Investments must be examined in terms of the risk reduction they actually produce.

Some controls have the advantage of reducing several categories of risk at once. Better identity management reduces the exposure of many systems. Least privilege limits the consequences of several compromise scenarios. A segmented architecture slows down various forms of lateral movement. A better asset inventory improves both vulnerability management and incident response. A resilient architecture makes it possible to recover more effectively when an unexpected event occurs. The objective therefore becomes to build coherent layers that reinforce one another rather than responding separately to each new threat.

Finally, the Notepad++ case helps explain why this work must be continuous. The attack reported in July 2026 will be analyzed, its indicators will be integrated into security tools, and organizations will be able to strengthen their controls. Attackers will then look for other methods. They will use another application, another extension mechanism, or another trust relationship. It is impossible for an organization to know in advance every technique that will be used against it. It can, however, prepare its environment to withstand them better.

This is probably one of the most important distinctions between a merely reactive cybersecurity strategy and a genuine resilience approach. The first mainly seeks to fix weaknesses that are already known. The second builds capabilities that remain useful even when the next attack takes a form no one had yet anticipated.

The incident involving Notepad++ adds a new dimension to the reflection on how pervasive cyber risk has now become. After observing that a charging station could become a network interface and an unexpected exposure surface, we see here that perfectly authentic software can also unintentionally take part in an attack without having been compromised.

The lesson is not that we should stop trusting legitimate software. An organization unable to extend any trust at all would simply become unable to function. The challenge is rather to turn that trust into something precise, limited, and continuously verifiable.

Modern cybersecurity must therefore look beyond the name of the software or the reputation of its vendor. It must understand the behaviors, permissions, identities, dependencies, and paths that connect the various components of the system. It must also accept that a first line of protection may fail and plan the subsequent layers that will limit the consequences.

For IT and cybersecurity teams, this responsibility is becoming increasingly complex as digital environments multiply and attack techniques evolve. It is in this context that Quantum Beyond can become a complementary partner: working with internal teams to challenge trust assumptions, examine architectures, reduce privileges and attack paths, improve segmentation, and strengthen the organization's ability to keep operating when an unexpected event occurs.

Our contribution does not rest on the unrealistic promise of eliminating all risk. It aims instead to add a specialized layer of vigilance, architecture, and resilience so that known and unknown risks have fewer opportunities to turn into major incidents. Because the growing difficulty in cybersecurity is no longer only recognizing what is dangerous. It also lies in knowing when something perfectly legitimate starts being used in a way that no longer is.