Threat actors are increasingly turning legitimate software into part of their attack chains. Instead of deploying an obviously malicious executable, attackers can abuse trusted tools that already have legitimate uses on Windows systems, making malicious activity harder to distinguish from normal software behavior.
According to Cybersecurity News, Iran-linked operators are abusing the legitimate Deno JavaScript and TypeScript runtime to conceal a backdoor called Dindoor inside Windows environments. The activity has been linked to MuddyWater, an Iran-linked threat group, with researchers observing Dindoor in spearphishing intrusions targeting U.S. software and banking organizations and a Canadian nonprofit.
The campaign is notable because Dindoor combines a legitimate signed runtime, Base64-encoded code, virtual machine checks, and Windows persistence mechanisms to reduce the number of obvious indicators available to defenders.
Dindoor does not appear as the initial infection vector.
According to the report, the backdoor has been observed as a later-stage payload following spearphishing intrusions. An earlier phishing stage places the loader onto the victim’s device.
This means the attack begins with a familiar social engineering technique, but the subsequent malware execution chain is designed to make detection considerably harder.
Once the loader is present, it checks whether Deno is already installed on the compromised Windows system.
If Deno is not present, the malware uses curl to download the legitimate Deno runtime.
The attackers then launch Deno with a long Base64-encoded argument containing the Dindoor code.
This is an important part of the attack.
Deno itself is legitimate signed software used to execute JavaScript and TypeScript. Its presence on a system therefore does not automatically indicate malware.
The attackers are effectively using trusted software as part of the execution chain.
After Deno is launched with the encoded payload, the first script begins gathering information about the compromised host.
It then:
This creates a layered infection chain in which different stages perform different functions.
The multi-stage structure also gives the operators flexibility because later components can be changed without replacing the entire infection chain.
Before establishing persistence, Dindoor performs an environment check.
The malware uses PowerShell and Windows Management Instrumentation (WMI) to query the system’s graphics adapter.
It looks for names associated with:
These names can indicate that the malware is running inside a virtual machine or automated analysis environment.
If the system appears to be an analysis environment, the malware can stop before exposing its more harmful behavior.
This gives defenders another behavioral signal to look for: a PowerShell graphics-adapter query launched through cmd.exe, particularly when it appears alongside other suspicious execution activity.
After the environment check, Dindoor establishes persistence.
The malware creates a Windows Run registry entry that launches a VBScript through wscript when the user signs in.
According to the report, the observed persistence script was:
C:\Users\Admin\AppData\Local\Serial\Lynx_system59.vbs
This allows the backdoor to return automatically when the user logs into Windows.
The persistence chain therefore involves multiple legitimate Windows components:
Run Registry Key → wscript.exe → VBScript → Dindoor
This makes process and registry behavior particularly important for detection.
The backdoor also attempts to make its network traffic less obvious.
According to the report, Dindoor uses Deno’s listen function to create a TCP listener, while the exchanged data is Base64-encoded to conceal its contents.
This creates another example of the campaign’s broader strategy.
The malware does not depend on a single suspicious executable or obviously malicious technology. Instead, it combines legitimate software and ordinary Windows functionality with malicious code.
The most important characteristic of this campaign is the use of legitimate tools.
Deno, curl, PowerShell, cmd, and wscript are all legitimate components or utilities.
Individually, their presence may not be suspicious.
The risk becomes visible when they appear together in an unusual sequence:
Spearphishing → Loader → curl → Deno → Encoded Payload → PowerShell/WMI Check → Run Registry Key → wscript → VBScript → Backdoor
This is why detecting the behavior of the entire chain is more valuable than simply searching for one malicious file.
The report identifies several particularly useful behavioral signals.
Security teams should investigate:
These signals become considerably stronger when correlated rather than investigated individually.
This attack is primarily an endpoint behavior, script execution, persistence, and command-and-control problem. The most relevant Seceon capabilities are therefore aiXDR-PMax and aiSIEM / CGuard.
Seceon’s aiXDR-PMax is directly relevant to the endpoint execution chain.
It can help security teams identify behavioral activity such as:
This type of behavioral visibility is important because the attackers are deliberately using legitimate software rather than relying on a clearly malicious executable.
Seceon’s aiSIEM / CGuard adds cross-environment correlation to the detection process.
It can help correlate:
For an attack such as Dindoor, this correlation can connect the initial phishing event to the later endpoint execution and persistence activity, helping the SOC understand the complete intrusion chain.
The Dindoor campaign demonstrates how legitimate developer and operating system tools can become powerful components of a malware infection chain.
MuddyWater-linked operators are not relying on Deno itself being malicious. They are abusing the trust associated with a legitimate runtime and combining it with encoded payloads, analysis-environment checks, Windows scripting components, and registry persistence.
The key defensive lesson is clear.
A legitimate tool is not automatically legitimate activity.
Deno running on a developer workstation may be completely normal. Deno unexpectedly downloaded through curl on a non-developer endpoint, launched with a long encoded argument, followed by PowerShell reconnaissance and a new Run-key persistence mechanism, tells a very different story.
Detecting that sequence of behavior is where continuous endpoint monitoring and cross-event correlation become critical.
