A water-utility alert shows malware that performs environment checks and only then retrieves a final tool from the network. Which malware stage best describes that sample?

A downloader retrieves additional components after initial execution, often only after environment, sandbox, or configuration checks succeed. When a water-utility alert shows those checks followed by retrieval of a final tool from the network, the sample is staging what comes next; it is not yet a completed destructive payload. Recognizing this behavior helps civic incident responders anticipate later modules, monitor egress for retrieval URLs and IPs, and interrupt the chain before encryption, credential theft, or OT-adjacent tooling reaches the estate. A completed ransomware payload that has already encrypted SCADA historians does not fit: the observed checks and retrieval describe pre-objective staging, not finished encryption. A deepfake audio generator used for municipal vishing drills is a different kind of tool, not a malware stage that retrieves a final tool after environment checks. An OSINT scraper cataloging public utility websites collects public information; it does not stage a final tool inside the utility environment. Exam caveat: a dropper, which installs or launches a component already present or written, and a downloader, which retrieves later components, are adjacent concepts; network retrieval after checks points to downloader/staging. Do not infer ransomware just because utilities are mentioned. For a practical check, capture the environment-check logic and outbound retrieval indicators, block staging destinations, hunt for the retrieved tool by hash and path, isolate affected jump or engineering hosts per policy, and verify historians and control-adjacent Windows systems show no follow-on payload activity. Do not scan OT controllers if your charter prohibits it.