Join our Newsletter — 33% off our NHI Course
Home Glossary Cyber Security Dropper
Cyber Security

Dropper

← Back to Glossary
By NHI Mgmt Group Updated August 24, 2026 Domain: Cyber Security

A dropper is malware designed to deliver or stage another payload onto a target system. In package attacks, it may first fetch binaries or scripts from an external host, then execute them during install or load time so the malicious activity begins as soon as the package is used.

Expanded Definition

A dropper is a delivery mechanism whose job is to place, unpack, or launch a second-stage payload on a target system. It is distinct from a full-featured implant because its purpose is usually transient: establish execution, reduce suspicion, and hand off control to the payload that performs the main malicious activity. In software supply chain incidents, droppers may arrive inside a package, installer, script, or loader and execute at install time or load time.

Usage in the industry is still evolving because some analysts reserve the term for a small first-stage binary, while others apply it more broadly to any component that stages malware. In NIST Cybersecurity Framework 2.0 terms, the risk sits across identify, protect, detect, respond, and recover because the dropper is both an initial intrusion method and a mechanism for persistence or follow-on compromise. The most common misapplication is treating every malicious installer as a dropper, which occurs when defenders overlook whether the file merely bundles code or actually delivers and executes a separate payload.

For broader context on security governance, NIST Cybersecurity Framework 2.0 provides the control-oriented lens used to map delivery, execution, and response obligations.

Examples and Use Cases

Implementing detection for droppers rigorously often introduces a visibility-versus-usability tradeoff, requiring organisations to weigh inspection depth against false positives and operational friction.

  • A malicious email attachment installs a small loader that retrieves a ransomware payload from an external host after the user opens the file.
  • A compromised software update package includes a script that stages credential-stealing malware during installation, before any legitimate application functions begin.
  • A container image contains an entrypoint script that drops a backdoor binary into writable storage and executes it when the container starts.
  • A web-delivered installer fetches a second-stage payload only after checking system characteristics, helping the attacker avoid sandbox analysis.
  • A browser extension or package manager artifact appears benign on first inspection but launches a hidden downloader that stages the real malware later.

These patterns are often discussed alongside supply chain compromise, where the dropper is one link in a broader execution chain rather than the end goal itself. Guidance from sources such as MITRE ATT&CK and NIST-linked response practices can help teams distinguish initial delivery from later-stage behavior, but the key question remains whether the artifact is merely present or actively staging code. The practical value of the term is that it narrows attention to the moment malicious code crosses from inert packaging into execution.

Why It Matters for Security Teams

Droppers matter because they compress the timeline between exposure and impact. A security team that focuses only on the final payload may miss the earlier staging artifact, which can contain weaker indicators, temporary infrastructure, or short-lived files that disappear after execution. That makes hunting, containment, and forensic reconstruction harder. For identity and access environments, a dropper can be especially damaging when it targets administrative workstations, CI/CD runners, secrets stores, or machines that mint tokens and certificates, because the initial foothold can quickly expand into privilege abuse.

This term also intersects with modern agentic systems. If a package, plugin, or toolchain component can execute code automatically, a dropper can become the delivery path for malicious logic into an AI workflow, NHI runtime, or automation pipeline. Defenders should therefore treat unexpected payload retrieval, child process creation, and post-install execution as high-signal events, especially when they occur in trusted software channels. Organisationally, the issue becomes visible only after the staged payload has already executed, at which point the dropper’s earlier actions become operationally unavoidable to reconstruct and contain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0DE.CMDropper activity is detected through continuous monitoring of suspicious execution and delivery paths.
OWASP Non-Human Identity Top 10Droppers threaten non-human identities by staging code on systems that hold secrets and automation credentials.
OWASP Agentic AI Top 10Agentic toolchains can be subverted when a dropper enters a plugin, package, or automation path.
NIST AI RMFGOVERNAI governance must address malicious code delivery into systems used for AI operation and orchestration.

Monitor installers, loaders, and child processes for payload staging and trigger response when anomalous execution appears.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org