What is a downloader?¶
A downloader is code or a script used to retrieve another file, configuration or set of instructions from a remote system.
The investigation should separate four questions: did the downloader run, did it make a request, did useful content return, and was that content then used?
Read the retrieval as a short transaction¶
In a fictional Windows incident, endpoint records show a helper process contacting updates.example. A proxy records an HTTP response, a new file appears, and a matching process starts shortly afterwards.
The domain is reserved fictional data. The sequence is what matters.
Attempted contact and successful retrieval are different¶
A DNS lookup shows that a name was resolved. A connection attempt shows that a destination was contacted or attempted. Neither alone proves that a payload arrived.
Useful joining details can include:
| Source | Detail to preserve | Question it helps answer |
|---|---|---|
| Process record | Image, parent, command line, account, time and process ID | What initiated the request? |
| DNS/network record | Name, address, port, protocol, result and time | Where did it try to connect? |
| Proxy or gateway | Method, host, path, status, byte count and content type | Did the service return content? |
| Endpoint/file record | New path, hash, creating process and time | What reached the device? |
| Memory/process evidence | Loaded code, child process and resulting activity | Was the returned content used? |
A server may return only configuration or an error page. Security controls may block the response. The downloaded component may be stored but never executed. Preserve the positive result at each stage rather than compressing the whole transaction into “downloaded malware”.
Legitimate tools can become the retrieval mechanism¶
Browsers, command-line transfer utilities, scripting engines and software updaters all retrieve content legitimately. Their presence is not the finding.
The useful comparison is between the particular process, instruction, destination, returned content and subsequent behaviour. Approved update infrastructure and a correctly signed expected package point in a different direction from an unusual parent process retrieving an unrecognised component and immediately launching it.
The destination also needs context. An address or domain may be shared, compromised, rented or fronted by another service. It can connect the event to infrastructure and another record holder without identifying the human controller.
When the content has disappeared¶
The response body may no longer be available because the server has gone, the file was deleted or the code ran only in memory. Request metadata can still establish that a particular process contacted a destination at a particular time and received a response of a recorded size or type.
That may be a useful line of enquiry, especially when joined to a new process, memory finding or later behaviour. Keep the conclusion within the available coverage.
The result should read as a transaction, not a label: the downloader ran, made a particular request, received a recorded response and passed content into a later stage. The component that performs the harmful objective is the payload; the downloader explains how it was retrieved.
