What is a dropper?¶

A dropper is code whose main job is to place, unpack or load another component on a system.

It is a delivery stage. The important evidence is the creation chain: what ran the dropper, what it produced, where that component went and whether the new component then ran.

See the placement event in context¶

Suppose a user launches the fictional DocumentViewerSetup.exe. Endpoint telemetry then records the installer process creating viewer-helper.dll in a program-data folder. Seconds later, a process-creation event records viewer-service.exe starting, and a separate image-load event records that process loading the library.

That sequence can support the proposition that the initial process created the helper component and that viewer-service.exe later loaded it. It is stronger than finding both files later and assuming they belong together.

Preserve both sides of the creation¶

For the dropper, retain:

• its original source, path, hash and launch event;
• parent process, command line and account context;
• embedded, encrypted or compressed content identified by analysis; and
• temporary files or memory associated with unpacking.

For the produced component, retain:

• creation time, path, hash and creating process;
• any rename, move or deletion event;
• process or module-load evidence;
• persistence or configuration changes; and
• later behaviour and network activity.

The shared process identifiers, hashes, paths and close timing make the relationship testable by another reviewer.

Ordinary software can use the same mechanics¶

Legitimate installers routinely extract libraries, write temporary files and launch services. Those actions become suspicious through their content and context, not because file creation is inherently malicious.

Compare the observed behaviour with:

• the software's claimed purpose and expected installation route;
• publisher and signature information;
• approved software records;
• the component actually produced; and
• what that component did next.

A dropper may also delete itself or its temporary files. Preserved creation and process events can still show the sequence after the disk artefact has gone.

Prove each transition¶

Security tooling may interrupt the chain after any one of these points. A completed file-write event does not prove the new component executed; a later copy of the component on another device does not prove this dropper created it there.

Treat the dropper as the placement stage: join its execution to the component it created, then establish what happened to that component separately. Where the next component was retrieved from another system rather than carried inside the original code, continue to what is a downloader?.