I'm trying to analyze a piece of malware that is most-likely a downloader. During dynamic analysis on an isolated VM network, Wireshark registered a GET request to a server for what I believe is the payload (a .bin file).

What is a safe way to download the payload? Is there a tool that will allow me to replicate only the GET request? I do not want to run the malware connected to the internet.


  • 3
    Leech the url and use wget , curl to download it ?
    – blabb
    Apr 2, 2017 at 5:46
  • 2
    use wget + torsocks
    – julian
    Apr 2, 2017 at 14:45

2 Answers 2


This sounds like a straightforward question at first glance, but may prove a little more complicated at second thought.

Before we go into how to retrieve the payload, I should highlight the importance of backing up your machine and taking extra precautions. Running malware, even inside a VM, is a dangerous business. Tread safely.

The safest way will probably be using wget or a similar tool to download the payload. There are plenty of ways to download an asset. There are even some tools that let you "replay" a .pcap (network capture) file as if the HTTP client is connected to the original server, but that does not sound like what you're looking for.

However downloading the manually payload from a different computer might not be the best way to do what you're trying to do, for several reasons:

  1. Server might be only serving correct payloads for specific request nuances.

    It is possible that the server filter any http request nuances to detect a payload being downloaded outside of the malware. That might happen using a specific UserAgent, specific headers or request parameters (such as post data).

  2. Payload might be scrambled in a way that would make it useless without being served to the malware.

    If you plan on faking web responses from your internal network this is less of an issue (although a simple challenge-response is possible here), but if you plan to download and reverse engineer the payload, you might encounter a scrambled payload that will require further analysis of the original malware downloader before you can continue your research.

  3. Malware might rely on further server communication afterwards.

    If you plan on serving the payload to the malware downloader and continue it's execution, the downloader itself or even the downloaded payload might require further consistent connection to the C&C server. This will make any additional dynamic investigation difficult at best, without a live internet connection.

  4. Several download attempts might get your IP/IP range blocked.

    In case any of the previous steps fail you will attempt to download the payload again several times. Oddly enough, this might get your IP or IP range banned from that malware server precisely to prevent any investigation attempts. This is common practice among malware ops, and often enough you'll simply get a benign executable instead of being bluntly blocked.

  5. Connecting a malware to the internet is not that risky.

    If the malware is running in an up-to-date virtual machine, the risk of letting the downloader download it's payload is minimal. Most samples will not have any VM guest to host zero-days (and those that do, might just as well include it in the first stage executable). You should consider the reasons for and against letting the malware payload connect to the internet and make sure keeping the malware disconnected is right for you. For additional security, you might connect the malware to a different (limited) network interface or one that's even connected to a different ISP/internet account.

  • And keep good backups of your system before doing this.
    – SDsolar
    Apr 2, 2017 at 21:58
  • Yes. That's important. I'll add that!
    – NirIzr
    Apr 2, 2017 at 22:15
  • Thanks for the great answer, it's very helpful to know the details.
    – qwersjc
    Apr 6, 2017 at 2:30

If you've got the GET reply captured in the wireshark session, then I'd suggest you to just extract the binary from it. This also way you also avoid situations where downloader uses some kind of challenge/response or time-based protocol which means second attempt with the same URL would fail or it was a fast-flux or hijacked server which could be down by the time you get to trying the download again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.