Stealthy Fileless Attacks Exploit Windows Tools to Evade Traditional Security Defenses

Traditional antivirus software looks for suspicious files, but not every attack leaves one behind. In a fileless attack, criminals use tools that are already built into Windows, like PowerShell, MSBuild, and Windows Script Host, to run malicious code directly in memory. Because these tools are legitimate, they don’t automatically raise suspicion. There may be no obvious executable for antivirus software to find, and the activity can look normal. Attackers have been using this for many years, and recent campaigns show how easily they can adapt it.

What Happens to Fileless Malware When You Restart Windows?

Some malware exists only in a computer’s memory. But which type of malware resides only in RAM? This is memory-resident malware. In such a case, restarting the machine can clear the active payload. But attackers rarely rely on memory alone. They often make changes elsewhere so the malware can return after a reboot. 

For example, they might save an encoded script in the Windows Registry, create a WMI event subscription, or add a scheduled task that launches PowerShell when someone signs in. The malicious code may disappear from memory on restart, but the persistence mechanism can load it again. That’s why there are steps to take before starting fresh and why a clean antivirus scan after restarting isn’t enough to confirm safety, as detailed by Moonlock. If you can’t establish what ran or how long the system was compromised, reinstalling Windows may be safer than trying to find every trace manually.

It’s also worth saving software license information and 2FA recovery codes before wiping everything. Assume that passwords and other credentials on the infected device have been exposed, so change them from a separate, trusted device, especially if the infection involved an information stealer like PureLog.

How Attackers Abuse Built-In Windows Tools

Several recent investigations show just how different the attacks can look.

Trellix tracked one campaign that started with a phishing email written in Korean. It pretended to be a FedEx tax invoice and included a ZIP attachment. Inside was a PDF that appeared to be blank when opened. That was part of the trick, as an action hidden in the PDF’s structure triggered the infection, eventually delivering a new version of the Sirius backdoor.

Securonix uncovered another one called Veil#Drop. This one relied on a script disguised as a PDF. Windows hides extensions by default, which makes it easier for someone to give a malicious file a convincing name. Once opened, the script launches PowerShell with security checks disabled. It then gets additional code from attacker-controlled Blogspot pages and runs it in memory. That final payload is the PureLog information stealer.

Also, a February 2026 investigation by ASEC showed a slightly different thing, where attackers included a renamed copy of MSBuild.exe in an archive. That carried Microsoft’s digital signature, making it look legit, but when opened, it automatically reads a project file from the same folder and runs its embedded C# code in memory.

The attack doesn’t stop there, as the code downloaded an executable, a DLL, and a data file, which is why it’s important to remember that fileless malware mitigation doesn’t mean that files aren’t created. Often, it describes how the initial malicious code runs instead of what happens at each stage of the attack.

How to Reduce the Risks of Fileless Attacks

Since attackers are using legitimate Windows programs, simply looking for suspicious files isn’t enough. Security teams need to monitor what those programs are doing and which processes are launching them.

Start with logging. PowerShell script block logging records the commands and scripts PowerShell executes, while AMSI (Antimalware Scan Interface) helps products inspect scripts and other content. So, together, they can expose malicious code that attackers try to hide using Base64 encoding. Without this information, it can be difficult to work out what happened during an intrusion.

Regularly check WMI event subscriptions and scheduled tasks as well, as unexpected entries in either location could indicate that malware has created a way to run again after a restart.

Application controls provide another layer of protection, where Windows Defender and AppLocker can restrict which programs are allowed to run. For example, a workstation used mainly by an accounts-payable team probably has no reason to launch MSBuild.exe or compile C# projects. Blocking tools that employees don’t need reduces the chances attackers have to misuse them.

Rolling out these restrictions across an entire organization can take time, so it’s sensible to start with computers that have no legitimate reason to use the affected tools. Once the policies have been tested, they can be expanded to other departments.

Then there’s the joint guide from CISA, the NSA, and the FBI, which explains why these attacks remain a problem. Known as living-off-the-land techniques, they take advantage of tools that organizations already trust. The guide draws on real incident response cases, including attacks linked to the Volt Typhoon group, and emphasizes practical defenses such as better logging and stronger authentication.

What to Look for When Detecting Fileless Malware

Fileless attacks are difficult to catch with traditional antivirus scans because their main payload may never exist as a recognizable file. That doesn’t mean they leave no clues. Unexpected PowerShell activity, unusual WMI subscriptions, and suspicious parent-child process relationships can all point to something deeper.

One of the simplest places to start is PowerShell script block logging. Check whether it’s enabled before an incident, not after. If an attack does happen, having those records available can make the difference between understanding what happened and being left with very little evidence.