What is a dropper?¶

A dropper is code designed to place another malicious component onto a system.

Avoid the dangerous assumption¶

The dangerous assumption is that the dropper itself performs the final harmful action.

Often it does not.

A dropper may contain the next component inside itself, decrypt it, write it to disk or load it directly into memory.

Its purpose is to establish the next stage of the attack.

Evidence may include:

• the original dropper file
• the process that launched it
• new files created
• temporary files
• memory activity
• registry or startup changes
• security detections
• the resulting payload.

Investigators should ask:

• how the dropper arrived
• whether it executed
• what it created or loaded
• where the next component was placed
• whether security tooling interrupted the process
• what happened afterwards.

The presence of a dropper does not prove that the payload was successfully installed or run.

Likewise, finding the payload does not automatically prove which dropper created it unless the process and timeline support that link.

Droppers may use legitimate installers, scripting engines or system tools. This can make the activity look like ordinary software deployment.

Do not treat a vendor family name as a complete explanation. The evidential question is what this sample did on this system.

Preserve the process chain and any created files before remediation removes them.

The dropper may also delete itself after use or create files with misleading names. Absence of the original component later in the incident does not exclude its earlier involvement if other records preserve the chain.

Operational takeaway¶

Treat a dropper as a delivery stage and establish whether it executed, what it created or loaded and whether the next stage actually ran.