Malware
Loader
Loader is code that places a payload in memory and starts it. It sits between whatever delivered the malware and the harmful work itself.
How it is measured
Look at what the code does after it arrives: decrypt a blob, allocate memory, copy the payload in, and transfer execution. In a script, that is a decode step followed by `eval` or `Function`. In a binary, API calls like `VirtualAlloc` and `CreateThread` are the usual markers.
Sandboxes show the handoff: a first process runs, a second image appears in memory, and the second one makes the network calls.
Worked example
A WordPress site has `wp-content/mu-plugins/cache-helper.php`, 2.1 KB. It reads `wp-content/uploads/.cache.dat`, XOR-decodes it with a hard-coded key, and evaluates the result. The `.dat` file is 88 KB.
The owner saves both, removes them, and examines the decoded text offline. It holds a spam-link injector. The 2.1 KB loader was clean on every signature scan because it contained no spam code itself.
How it differs
A loader runs the payload; a dropper gets the payload onto disk or onto the machine. Some samples do both. The payload is the part that does the damage: spam, theft, encryption. Loaders are reused across many campaigns, which is why defenders often track the loader even when the payload changes.
Common errors
Searching only for the payload and missing the loader. Deleting the loader and leaving the encrypted blob. Assuming a tiny file is harmless. Forgetting that `mu-plugins` loads without being listed as active. Analyzing the loader by running it.
In practice
Check `mu-plugins`, `wp-config.php`, and the uploads folder for small PHP files and hidden data files. Remove both loader and blob together, and find what let the attacker place them.