Security - Dropping

In the context of cybersecurity, "dropping" refers to the act of a primary program (the "dropper") creating a secondary file on a victim's storage and then executing it.

A dropped payload or dropped script is the "actual" malicious content that was carried inside a seemingly harmless file.

The Strategy: Why "Drop" at all?

Hackers rarely send a 50MB ransomware file directly via email because it would be immediately flagged by antivirus (AV) scanners. Instead, they use a multi-stage attack:

Stage 1 (The Dropper): They send a tiny, simple file (like a Word document with a macro or a small .exe). This file isn't overtly malicious; its only job is to bypass the initial "gates" of security.
Stage 2 (The Drop): Once the Dropper is running inside your computer, it writes a new file to your disk. This is the Dropped Payload.
Stage 3 (Execution): The Dropper then tells the operating system to run that new file. This is when the actual damage (data theft, encryption, etc.) happens.

Dropped Payload vs. Dropped Script

Dropped Payload

This is usually a compiled binary (like a .exe, .dll, or .so file).

Characteristics: It is a standalone "tool" designed for a specific task, such as a keylogger or a remote access trojan (RAT).
Example: A "Flash Player Update" (the dropper) runs and secretly writes a file called system_update.exe (the payload) to a hidden folder and runs it.

Dropped Script

This is a text-based file containing commands for an interpreter (like PowerShell, Python, Bash, or VBScript).

Characteristics: Attackers love scripts because they can use "Living off the Land" (LotL) techniques. Instead of bringing their own "gun" (a binary), they use the "tools already in your house" (like PowerShell) to attack you.
Example: A malicious Excel file drops a .ps1 (PowerShell) script into your temporary folder. This script then downloads and installs a virus. Scripts are often heavily obfuscated (made unreadable) to hide their intent from scanners.

How this relates to Sandboxing

A good sandbox stops a payload from being dropped in two ways:

File System Isolation: In a sandbox like gVisor, the application is given a "Virtual File System." If the malware tries to "drop" a payload, the sandbox catches the syscall. The malware thinks it wrote the file, but in reality, it wrote it into a temporary, isolated bubble in RAM that is deleted the moment the program closes. The host system remains clean.
No-Execute (NX) Policies: A sandbox can be configured to allow an app to write files but forbid it from executing them. The dropper might successfully "drop" the script, but when it tries to call execve() to run it, the Sentry (in gVisor) or the seccomp-bpf filter (in Sandbox2) will block the request and kill the process.

Anatomy of a "Dropped" Attack (Linux Example)

The Hook: You download a legitimate-looking maintenance script, for example, reindex_db.sh.
The Extraction: Hidden inside the bash script is a large block of Base64-encoded text. The script runs a command like echo "BASE64_DATA..." | base64 -d > /tmp/.internal_service.
The Drop: The encoded data is decoded into a hidden ELF binary located in a temporary directory, such as /tmp or /dev/shm (which resides in RAM to avoid leaving traces on the physical disk). This is the Dropped Payload.
The Preparation: The script changes the file permissions to make the payload executable: chmod +x /tmp/.internal_service.
The Launch: The script executes the binary in the background: /tmp/.internal_service &.
The Cleanup: To hide its tracks, the original script finishes by running rm /tmp/.internal_service and deleting itself. The malicious process continues to run purely in the system's memory.

Summary

Dropper: The delivery truck.
Dropped Payload/Script: The "package" (bomb) inside the truck.
The Drop: The act of taking the package out of the truck and putting it on the victim's "porch" (disk).
The Sandbox: The security fence that prevents anything from being taken out of the truck and placed on the porch.