Dropper and downloader
A dropper and a downloader are the two ways malware gets delivered onto a machine: the dropper carries the payload inside itself and writes it to disk, while the downloader carries nothing and fetches it from a server the moment it runs. Neither of them is the damage, both are the road it arrives on.
How it works
Both are delivery rather than payload, which is why they are studied together. A dropper brings the malware inside itself, usually obfuscated or encrypted as just another resource in the file, and its job is to write it to the machine and run it. A downloader brings nothing: it carries the logic to request the payload and an address to request it from.
How they arrive matters least, which is why it changes so often: an attachment that looks like an invoice, an installer that ranks first in a search, a script, a shortcut file. What both are after is identical, which is the first execution on the machine. After that, the rest of the attack no longer depends on email or on the browser.
And both usually establish persistence before fetching the real payload, because a stage that does not survive a reboot is not worth much. That is also the part that leaves the most trace, and therefore the part worth looking at once it has already happened.
What goes wrong
The downloader is the harder one to catch, and the reason is worth understanding, because it is not that it is more sophisticated. It is that at the moment you analyse it, it may be carrying nothing malicious at all. Static analysis sees a program making an HTTP request, which is what half the internet does. And a run in a controlled environment, carried out after the attacker’s infrastructure has gone down, sees a failed connection and signs the file off as clean. What is malicious is not in the file: it is in what the file is told to fetch.
From that follows the second consequence, and it is the one that breaks reports. Whoever runs the command and control decides what gets delivered and to whom, and can decide on the country, on the domain the machine is joined to, or on whether it is worth the trouble. The same campaign leaves an infostealer in one place and ransomware in another. So “we know what this campaign delivers” is a sentence with a short shelf life, and building the response around the payload seen yesterday leaves out tomorrow’s.
Where this shows up in an audit
In a phishing simulation the interesting question is not how many people click, which is the number that gets presented and the one that says least. The question is what happens AFTER somebody clicks. We send an attachment that behaves like a dropper without doing damage, and measure which layer stops it: the mail filter, the macro policy, application control, the EDR, or the person who reports it.
What usually turns up is that none of them stops it, and that the alert did fire but nobody read it. That is the finding, and it is written against the whole chain rather than against the user: a company where everyone gets it right the month of the training is still one click away the month after.