Loaders and Droppers Explained: First-Stage Malware Delivery

The file that lands on a victim machine is rarely the malware that matters. It is a small, forgettable program whose entire purpose is to bring in something bigger. That first stage is a loader or a dropper, and understanding it is how defenders catch an intrusion before the real payload ever runs.

Attackers split their delivery into stages for the same reason a smuggler does not carry everything at once. A minimal first stage is easy to disguise, cheap to rebuild when it gets flagged, and keeps the valuable payload hidden until the last possible moment. If you only hunt for the final malware, you are looking too late.

Dropper versus loader

The two words get used loosely, and plenty of tools do both. The distinction that actually helps you is where the payload comes from.

A dropper carries the payload inside itself. The malicious code is embedded in the dropper, often obfuscated or encrypted, and the dropper writes it to disk and runs it. Everything needed is in the one file, which makes it self-contained but larger and easier to analyse once caught.

A loader does not carry the payload. It fetches the payload from a remote server, or it unpacks a payload delivered separately, then executes it, frequently straight into memory without ever writing the full malware to disk. A loader is smaller, and because the payload is external, the operator can swap what gets delivered without touching the loader at all.

Trait	Dropper	Loader
Payload location	Embedded inside the file	Fetched remotely or unpacked separately
Touches disk	Usually writes payload to disk	Often runs payload in memory
Size	Larger	Small
Payload swappable	Rebuild required	Change the server-side payload
Analysis exposure	Full payload recoverable from the sample	First stage reveals little on its own

In modern campaigns the loader model dominates, because keeping the payload off the victim disk and out of the delivered sample defeats a lot of file-based detection.

Why staged delivery exists

Staging is an evasion strategy. Each stage is built to survive the control it faces at that step.

• The first stage faces the email gateway and the download check. So it is tiny, benign-looking, and rebuilt constantly to stay ahead of signatures.
• The second stage faces the endpoint. By the time it arrives, execution is already underway inside a trusted process, so it has more room to operate.
• The payload faces analysts. Because it only appears after the loader has confirmed a real victim, it never lands in a sandbox that the loader can detect and avoid.

This separation also creates a business. Crews sell loader-as-a-service and pay-per-install, running someone else's payload on machines they have already compromised. The loader operator and the payload operator can be entirely different actors, which is why one loader family delivers many unrelated malware strains over time.

The delivery chain in practice

A staged intrusion usually follows a recognisable arc. The specifics vary, but the shape holds:

1. Lure. A phishing attachment, a fake installer, or a paste-a-command trick gets the first stage onto the machine.
2. First-stage execution. A weaponised file runs the loader or dropper, commonly by invoking a script host or a signed system binary rather than an obvious executable.
3. Fetch or unpack. A loader pulls the next stage from its server; a dropper decrypts the payload it already carries.
4. Execute the payload. The malware runs, often injected into a legitimate process to blend in.
5. Persist. The loader sets up a way to survive reboot so the foothold is not lost.

The file that starts this is almost always one of a small set of abused formats: a script, an archive, a shortcut, a malicious installer. Our File-Format Abuse Atlas maps which formats carry which first stages, from LNK targets that launch a script host to archives that hide a loader behind a decoy document. That first file is your earliest and cheapest place to break the chain.

How loaders hide the hand-off

The moment a loader hands control to the payload is the moment it is most visible, so loaders work hard to hide it. Common techniques:

• Process injection. The payload runs inside a legitimate process such as explorer.exe, so there is no new suspicious process to spot. This maps to Process Injection (T1055).
• In-memory execution. The payload never fully lands on disk, defeating file-scanning tools. This overlaps with fileless techniques.
• Living off the land. The loader invokes signed system binaries to do the downloading and executing, so no obviously malicious tool appears.
• Delayed or gated execution. The loader waits, checks for analysis environments, or only proceeds after a command-and-control server approves, so automated sandboxes see nothing.

The remote fetch itself maps to Ingress Tool Transfer (T1105), and the download destination is the loader's command-and-control channel, which is often the same infrastructure the payload will use later.

A worked example of a staged delivery

Walking one staged intrusion through from lure to persistence, conceptually rather than as working code, shows why each stage exists and where a defender can break it.

A user receives an email with an attachment that looks like an invoice. The attachment is not the malware. It is a small file, perhaps a shortcut or a script inside an archive, whose only job is to start the chain. This is the first stage, and it was built to survive the email gateway: tiny, unremarkable, and likely rebuilt recently enough that no signature matches it.

The user opens the attachment. Rather than running an obvious executable, the first stage invokes a script host or a signed system binary to do its work, so that the process that starts is a trusted component rather than something a naive scan would flag. This is the loader executing. In a dropper-style delivery, the payload is already embedded in the file, and this step decrypts and writes it out. In a loader-style delivery, the file carries no payload and instead reaches out to a remote server to fetch the next stage.

If it is a loader, the fetch happens now. The loader contacts its command-and-control server and pulls down the real payload. The server is often selective: it may only answer requests that look like a genuine victim, refusing connections from analysis infrastructure, so that a sample detonated in a sandbox receives nothing and appears harmless. This selectivity is why an empty-looking loader can still be part of a serious intrusion.

With the payload in hand, the loader runs it. Rather than starting a new, suspicious process, the loader frequently injects the payload into a legitimate running process, so that the malicious code executes under the identity of something trusted. Only now does the payload that matters, a remote access tool, an infostealer, or a ransomware component, actually run.

Finally the loader ensures the foothold survives a reboot. It creates a persistence mechanism, such as an autostart entry or a scheduled task, so the payload runs again after the machine restarts. With persistence set, the first stage has done its job and can even delete itself, leaving the payload running in memory or reinstalled at each boot.

Dropper and loader compared to related terms

Loader and dropper sit among several overlapping terms, and keeping them distinct helps when reading threat reporting. The distinctions are about role in the delivery chain, and a single piece of malware can wear more than one label at different moments.

Term	Role	Distinguishing trait
Dropper	First stage that carries the payload inside itself	Self-contained, writes the embedded payload to disk
Loader	First stage that fetches or unpacks the payload	Small, pulls the payload from elsewhere, often runs it in memory
Downloader	Retrieves a further component from a remote source	Emphasis on the download step specifically
Stager	Minimal first stage that pulls a larger stage	Common term in offensive tooling for the initial small footprint
Payload	The malware that actually achieves the objective	The thing the first stage exists to deliver
Packer	Compresses or encrypts a file to evade scanning	A technique applied to a file, not a delivery role

The terms downloader, stager, and loader overlap heavily, and reporting uses them loosely. The stable distinction worth holding is the dropper versus loader split from earlier: does the first stage carry the payload inside itself, or does it reach out to bring the payload in. A packer is a different axis entirely. It describes how a file is obscured, and a dropper or loader is frequently packed to help the first stage evade detection, so the labels combine rather than compete.

Why the loader model won

Modern campaigns favor loaders over self-contained droppers, and the reasons are practical.

The first is detection economics. A first stage gets flagged and burned constantly, so the operator wants it to be cheap to rebuild. A tiny loader with no embedded payload can be regenerated and re-obfuscated quickly, and because it carries nothing incriminating, a captured sample reveals little. A dropper that carries the full payload is larger, more expensive to rebuild, and exposes the payload the moment the sample is caught.

The second is operational flexibility. Because a loader fetches its payload from a server, the operator can change what gets delivered without touching the loader that is already deployed. The same loader can deliver a banking trojan today and ransomware tomorrow, simply by changing the server-side payload. A dropper is fixed at build time, so changing the payload means rebuilding and redelivering.

The third is the market it enables. Keeping the payload separate from the loader lets different actors specialize. One crew builds and operates loaders and sells installs, running whatever payload a customer provides on machines they have already compromised. This loader-as-a-service and pay-per-install model is why a single loader family delivers many unrelated malware strains over time, and why the loader operator and the payload operator are frequently different people entirely.

The fourth is analysis evasion. A loader that fetches from a selective server never exposes its payload to an automated sandbox that cannot convince the server it is a real victim. The payload only materializes for a confirmed target, which keeps it out of the hands of analysts and detection systems that rely on detonating samples.

Common mistakes and misconceptions

A few errors in how teams think about first-stage malware lead to missed intrusions.

The first is closing the investigation at the dropped file. A loader caught in isolation can look inert, especially if its server no longer answers or refused the sandbox. Treating that as the end of the incident misses the point of staging. A confirmed first stage is evidence a second stage was intended, and the process that launched it, the network destination it contacted, and any persistence created in the same window are where the rest of the chain lives.

The second is assuming an empty-looking loader is harmless. A loader that reveals no payload under analysis has often done exactly what it was designed to do: withhold the payload from anything that does not look like a genuine victim. Absence of a recovered payload is not evidence of a benign file.

The third is conflating the labels rigidly. Reporting that calls the same tool a dropper in one place and a loader in another is not necessarily contradictory, because a single tool can carry a payload in one configuration and fetch it in another. The useful question is always where the payload came from in the specific case at hand, not which label is universally correct.

The fourth is hunting only for the final malware. Signatures and detections tuned to the payload alone act too late, after the loader has already fetched, injected, and persisted. The cheapest and earliest interventions target the first stage and the hand-off, before the payload exists on the machine at all.

How to detect and defend

Because the first stage is designed to look harmless, detection has to watch the hand-off and the aftermath, not just the file.

1. Watch process chains. A document, script host, or benign-looking executable spawning powershell.exe, rundll32.exe, or a network-capable child is a classic loader signature. Office or a script host reaching the internet deserves a hard look.
2. Flag process injection. Remote thread creation, writes into another process's memory, and payloads running from memory regions with no backing file are high-value signals. Endpoint tools that surface injection catch loaders that leave no payload on disk.
3. Catch the fetch. Egress monitoring and DNS logging expose the download step. A newly executed file that immediately contacts an unknown host is worth alerting on.
4. Hunt fresh persistence. A new run key, scheduled task, or service appearing seconds after an unfamiliar process ran often marks the loader finishing its job. Correlate persistence creation with the process that created it.
5. Break delivery. Application control, macro restrictions, and blocking risky file types stop the first stage from executing at all. This is the cheapest intervention because it acts before any payload exists.
6. Constrain the tools loaders borrow. Constrained Language Mode for PowerShell, script-block logging, and removing script hosts you do not need raise the cost of the hand-off.

Loaders and droppers are the quiet front end of almost every serious intrusion. They are built to be boring so the interesting part stays hidden. Defend the first file, watch the moment it hands off, and you stop the attack while it is still small and cheap to contain.

Frequently asked questions

What is the practical difference between a loader and a dropper?

The useful distinction is where the payload comes from. A dropper carries the payload inside itself, embedded and usually obfuscated, and writes it to disk before running it. A loader carries no payload and instead fetches it from a remote server or unpacks one delivered separately, then often runs it straight in memory. The terms are used loosely in reporting, and some tools do both, so the reliable question in any specific case is whether the payload was self-contained or brought in from elsewhere.

Why do attackers split delivery into stages at all?

Because a single monolithic malware file has to defeat every control at once, while a staged delivery lets each stage handle one obstacle. The small first stage is built to slip past the email gateway and is cheap to rebuild when flagged. The fetch step withholds the payload from sandboxes that cannot pass as a real victim. The payload itself only appears after a genuine target is confirmed, keeping it away from analysts. Staging is an evasion strategy that spreads the detection problem across steps rather than concentrating it in one file.

Can antivirus catch a loader if it carries no payload?

Sometimes, through signatures on the loader itself, but a well-built loader is rebuilt and re-obfuscated often enough that file signatures lag behind it. The more reliable detections are behavioral: a document or script host spawning a network-capable child, process injection into a legitimate process, and fresh persistence appearing seconds after an unfamiliar process ran. These behaviors are harder for an attacker to change than the bytes of the file, which is why endpoint behavioral detection catches loaders that file scanning misses.

What is loader-as-a-service?

It is a criminal service model where one crew operates loaders and sells the ability to run a payload on machines they have already compromised. A customer provides their malware, and the loader operator delivers and runs it, often priced per install. This separation is why a single loader family delivers many unrelated malware strains over time, and why the person operating the loader and the person behind the final payload are frequently different actors with different goals.

Does running the payload in memory mean nothing touches disk?

Often the payload itself avoids being written to disk, which defeats file-scanning tools, but the first stage usually does leave some trace, and the persistence mechanism the loader creates is a durable on-disk or registry artifact. In-memory execution reduces the file footprint of the payload rather than eliminating all evidence. The hand-off, the network fetch, and the persistence are where a defender still finds the chain even when the payload never lands as a file.

If I find a loader but its server is offline, is the incident over?

No. A dead server means you may not recover the payload, but the loader being present is evidence that a second stage was intended. Pull the process that launched the loader, the network destinations it tried to contact, and any persistence created in the same window. The server being down at the moment you look does not mean it was down when the loader first ran, and treating a first-stage detection as a closed case is one of the common ways a staged intrusion is missed.

How is a loader different from a packer?

They describe different things. A loader is a role in the delivery chain: a first stage that brings in and runs the payload. A packer is a technique that compresses or encrypts a file to help it evade scanning. A loader is frequently packed to make the first stage harder to detect, so the two combine rather than compete. Asking whether a file is a loader is a question about its role, and asking whether it is packed is a question about how it is obscured. A dropper can be packed, a loader can be packed, and the payload they deliver can be packed too, so packing shows up at multiple points in the same chain.

Related guides

• Attacker File Formats Explained
• LOLBins Explained
• Command and Control Explained
• What Is Fileless Malware