What is Fileless Malware or a Fileless-based attack?

Fileless malware refers to a category of malicious code execution where the attacker's payload operates entirely within a system's volatile memory, RAM, CPU registers, and kernel structures, without writing executable artifacts to the filesystem. Unlike conventional malware that drops binaries, scripts, or DLLs to disk, fileless attacks exploit trusted, pre-installed system components to execute malicious logic, making them difficult to detect by traditional signature-based detection.

At its core, a fileless attack is a "living-off-the-land (LOTL)" strategy. Threat actors weaponize native OS utilities like PowerShell, WMI, the Windows Script Host, 'mshta.exe', 'certutil.exe', and others as an execution foundation. Because these binaries are signed by the OS vendor and routinely used in legitimate administrative workflows, it rarely raises alerts in traditional endpoint security tools. There is no malicious binary hash to match, no on-disk artifact to quarantine, and no persistent file to recover during incident response. The attack surface shifts from the filesystem to process memory, Windows registry hives, WMI repositories, and scheduled task stores; surfaces that many organizations log inconsistently or not at all.

However, the initial infection may still involve a file; a phishing document with a malicious macro, for instance, but once execution begins, the payload is loaded directly into memory, and all subsequent malicious activity runs within the context of legitimate processes (ex, powershell.exe). The file that triggered the compromise is temporary; the payload that matters never touches the disk. Apart from phishing as an initial infection vector, attackers who have found vulnerabilities like OS command injection, command injection, or RCE on the victim system can chain this bug to exploit and deploy the fileless-based attack using system utilities like Python, PowerShell, PHP, etc. We will discuss this attack vector in detail in the section "Case Study Walkthrough: MSF & Fileless Malware" below.

Process-based vs File-based Attack

"File-based attacks" follow a well-understood execution model. A malicious artifact, like an executable, a DLL, or a script file, is written to disk and subsequently invoked by the operating system or a user action. This model creates multiple detection opportunities: the file can be scanned on write, on access, or on execution. Security tools can compute cryptographic hashes, match signatures against threat intelligence feeds, and quarantine or delete the offending artifact. Even after execution, forensic investigators can recover the file, analyze it statically, and reconstruct the attack chain.

"Process-based attacks" dismantle the above model entirely. Rather than introducing a new binary to the system, the adversary injects malicious code; shellcode, a reflectively loaded DLL, or a hijacked thread; directly into the address space of a legitimate, already-running process. The attack lives and operates within trusted system processes such as 'explorer.exe', 'svchost.exe', 'powershell.exe', or 'python.exe'. From the OS scheduler's perspective, nothing unusual is occurring; the process is authorized, signed, and expected to be running.

Interestingly, for both process-based and file-based attacks, there is a way to migrate the attacker's remote session (say meterpreter session) from the malicious running process or suspicious process to a normal, unsuspicious process, which remains active most of the time on the OS. This not only ensures stealth operations but also provides persistence in case the original malicious process gets terminated.

Living Off the Land (LOTL) and Fileless-based attacks: How it operates

Img: Fileless-based attack chain

Living off the Land is the operational backbone of most fileless-based attacks. Rather than deploying custom malware binaries that could be detected, flagged, or reverse-engineered, adversaries repurpose the target system's own native utilities as their execution infrastructure. The attack runs entirely through tools the OS inherently trusts, meaning no new executables are introduced, no signatures can be matched, and no traditional file-based controls apply.

The most commonly abused LOTL binaries, referred to as "LOLBins,"; include:

• "PowerShell": the most widely abused LOTL tool. Attackers use it to download remote payloads directly into memory via 'Invoke-Expression' and 'DownloadString', execute encoded commands with '-EncodedCommand', and interact with the Windows API through .NET reflection; all without writing a single file to disk.
• "WMI (Windows Management Instrumentation)": used for remote code execution, lateral movement across hosts, and establishing persistent event subscriptions that survive reboots without filesystem artifacts.
• "mshta.exe": executes HTML Application (HTA) files hosted on attacker-controlled remote servers, loading and running embedded JavaScript or VBScript entirely in memory.
• "certutil.exe": a certificate management utility routinely abused to decode base64-encoded payloads or download files from remote URLs, behaviors far outside its intended purpose.
• "regsvr32.exe": used via the Squiblydoo technique to load and execute remote COM scriptlets, bypassing AppLocker controls since the binary is a trusted, signed OS component.
• "rundll32.exe": invokes arbitrary DLL exports, including reflectively loaded in-memory DLLs, providing a trusted execution wrapper for injected code.

None of these tools is inherently malicious; they are daily-use administrative utilities in most enterprise environments. Blocking them outright is operationally disruptive; allowing them unrestricted access creates significant exposure. Defenders must therefore focus on "contextual behavioral analysis," examining who invoked the tool, from which parent process, with what arguments, and whether that pattern is consistent with known-good administrative activity, rather than relying on binary allow or block decisions.

Detonation Case-Study Walkthrough: MSF & Fileless Malware

In Metasploit Framework, we can generate fileless payloads using the module “Script Web Delivery”. Threat Research & Intelligence (TRI) team at bloo had earlier discussed this module in our past article “MSFDefender: From Payload Delivery to Remote Shell, Analyzing Windows Exploitation Modules in Metasploit”.

In this article, we will discuss how “fileless payloads” are generated using the “Script Web Delivery” module, what are the various target OS available, and how these one liner commands (generated from the “Script Web Delivery” module) execute a fileless payload (In RAM/Memory execution & no write to the victim system disk) and render a metasploit session on successful execution.

Module: Script Web Delivery

Metasploit module “exploit/multi/script/web_delivery” is a web delivery module, which is basically a combination of payload generator, command generator, web server, and payload handler. The generated command is to be run on the victim system, the web server holds the payload, and the payload handler is there for handling the Metasploit session.

So, if a threat actor/attacker already has a way to run a command on the victim system, this module (web delivery) helps the attacker to turn that command execution vulnerability into a successful Metasploit session (Meterpreter or shell as per the payload). This module is NOT responsible for obtaining code execution. There are certain use cases for this web delivery module, like:

• You have an RCE on the victim system, but no interactive shell
• Getting initial access to the victim system via social engineering. Ex: Embedding one liner command generated from the module in a phishing email or a malicious script, the victim runs it, and a remote session appears.
• Utilising the clickfix attack technique for executing the web delivery module command on the victim system.

As mentioned earlier, this module fires up an HTTP web server that holds the payload. The payload is hosted on the web server “http://attacker-IP:port/random-byte-payload-code”. Finally, this module will provide a command to be run on the victim system. Before generating the one-liner command to be run on the victim system, we need to select the target type module and generate a command for that target & platform. There are certain matching modules (targets) available inside the ‘exploit/multi/script/web_delivery’ module, as they appear when you run “show targets” in the msfconsole.

0 Python (System with python installed) Multi python/meterpreter/reverse_tcp 1 PHP (System with php installed) Multi php/meterpreter/reverse_tcp 2 PSH (In memory Execution)) Windows windows/x64/meterpreter/reverse_tcp 3 Regsvr32 Windows windows/x64/meterpreter/reverse_tcp 4 pubprn Windows windows/x64/meterpreter/reverse_tcp 5 SyncAppvPublishingServer Windows windows/x64/meterpreter/reverse_tcp 6 PSH (Binary. Writes a file to the disk) Windows windows/x64/meterpreter/reverse_tcp 7 Linux Linux linux/x64/meterpreter/reverse_tcp 8 Mac OS X Mac OS osc/x64/meterpreter/reverse_tcp

Note:

• Regarding “squiblydoo”, which is a well-known application whitelisting bypass technique that uses “regsvr32.exe” [a genuine exe]. Since many organizations allow “regsvr32.exe” because it is a microsoft signed, the module (with ID 3) can be used to get a remote Metasploit session.

Overall, the script web delivery module does not write to the disk; it’s a fileless execution. It uses the RAM to execute the generated payload.

Sample Detonation [Target: Python]