5 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

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 waysways 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.

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.

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.

4 fixed typo
source | link

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 mancan 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.

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 man 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.

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.

3 added 215 characters in body
source | link

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 man 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.

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

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 man 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.

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 man 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.

2 added 282 characters in body
source | link
1
source | link