An alert fires: a workstation is reaching out to a known command-and-control address every minute. The responder pulls the machine, runs a full antivirus scan, and gets a clean result. No malicious files. No new programs installed. Nothing in the usual startup locations. And yet the beacon continues. The malware is real, but there is almost nothing on disk to find, because it is living inside memory and riding on tools Windows ships with.
This is the kind of attack that breaks the habit of "scan the files and clean what's flagged." On the CompTIA Security+ SY0-801 exam this sits under objective 2.5, which asks you to analyze indicators of malicious activity given a scenario, and fileless techniques are where a clean scan result is easiest to misread. This lesson covers fileless malware, in-memory execution and persistence that avoids dropping files, and living-off-the-land attacks, where adversaries abuse the legitimate, signed tools already on the system. You will learn why file scanners miss them and which indicators give them away.
Fileless malware runs in memory, so there is little on disk to scan
Fileless malware is malicious code that operates primarily in memory rather than as a file written to disk. Traditional antivirus works largely by inspecting files, so an attack that never writes a malicious file, or writes only a tiny, innocuous-looking one, gets past it. The code is injected into and runs inside the address space of a legitimate process, so what the system shows is a trusted program behaving strangely rather than an unknown executable.
A typical chain starts with something allowed: a phishing document with a macro, a malicious script, or an exploit in a browser or plugin. Instead of saving a program, it launches a script interpreter that pulls a payload straight into memory and runs it there. The payload may inject itself into a process like explorer.exe or a svchost.exe instance so it blends in. Because it lives in RAM, a reboot often clears it, which is why attackers add persistence that also avoids obvious files, as the next section describes.
The indicators move from the disk to behavior and memory. You stop asking "what file is this" and start asking "why is a trusted process doing that." Signs include a legitimate process making unexpected network connections, a script interpreter spawned by an office application, code executing from memory regions that normally hold data, and odd parent-child process relationships. The defenses that matter are behavioral: endpoint detection and response (EDR) that watches process behavior and memory, script and command-line logging, and the principle that a clean file scan does not clear a host when telemetry says otherwise. On the exam, "antivirus found nothing but the host is clearly compromised, and analysis shows code running in memory" is fileless malware, and the right move is behavioral analysis, not another file scan.