A good example of this was observed recently, and consisted of a method that was designed to trick users into downloading zip files containing malicious executables, while also providing the means to evade network defences.
This activity began with a tried and tested methodology that is likely familiar to many cyber security analysts: a malicious link contained within a phishing email, although in this instance the activity came to our attention due to the traffic we saw across the network, rather than from analysis of the phishing email itself. The image below gives an example of this suspicious initial request:
In this example the user clicked on the link and a subsequent request for the resource ‘faxmessage.php’ was sent to an attacker controlled domain, which in this instance was ‘novastore-print(dot)com’. Interestingly the victim’s user-agent information was also contained within the body of the request, likely for profiling purposes.
But here’s where things get interesting…
A response containing the resource was returned but there was something odd about the content. The response from the web server contained very little actual HTML, but it did include an iframe with a zip file base64-encoded and embedded within the page itself.
From the perspective of the user, they were presented with a simple webpage containing the text “Please read the document” along with a download dialog box pointing to the malicious zip file embedded within the page.
The HTTP standard, RFC 1945, states that “any HTTP/1.0 message containing an entity body should include a Content-Type header field defining the media type of that body”. Helpfully the attackers have complied with this as they have stated the data is “text/html” content, which is perfectly valid, but as we know this is not the whole story given the lurking zip file.
This highlights one of the problems of relying on standards definitions in network monitoring, as just monitoring the network for responses containing “Content-Type: application/zip” will not find the suspicious file as it is embedded in the body of the response, which is more-or-less legitimately marked as “text/html” content.
At this point fortunately our user did not proceed any further, but having caught our attention we had a quick closer look. After saving the PHP file and carving out the base64-encoded data, we used a simple bit of "bash-fu" to dump out the content and reveal its true nature…
'base64 --decode < carved_b64.txt > doc21641_pdf.mal’
A quick bit of open source research confirms that this is a malicious file. After running this sample across VirusTotal, it seems MalwareBytes have previously identified this executable masquerading as a PDF:
All of the variants of this first stage dropper that we’ve seen have attempted to connect to domains resolving to a wide range of IP addresses, indicating that the attackers have a large infrastructure at their disposal. The communications all resemble the following format:
GET /0112UK2/ADB7CB0C47E1463/0/51-SP3/0/ HTTP /1.1
The first stage malware acts as a dropper for a second stage crimeware implant. Once run, doc21641_pdf.exe will create or 'drop' another file, “fwygl.exe”, before launching it. The dropped file was constant across the various samples analysed and was created in the following location:
C:\Documents and settings\
The executable doc21641_pdf.exe then deletes itself. It does however leave forensic traces such as a Prefetch file in the Windows directory and Shim Cache entry in the registry. The dropped malware fwygl.exe then requests “/images/t2.pnj” from the domain “www.wholesale-motoroilonline[dot]com” which, at the time of analysis, resolved to the IP address 18.104.22.168.
Alternatively, if the dropper cannot connect to this address it attempts to download the same resource from “wholesalesyntheticmotoroil[dot].com”. Both of those domains and the resource string were found within the malware binary and within the subsequent network traffic.
If the dropper successfully connects to either of the destination domains above, the second stage implant is downloaded installed to C:\WINDOWS\ and given pseudo randomly generated name. Although this file is not currently identified as malicious on VirusTotal, it results in further malware which is detected as crimeware:
Once installed, the second stage will connect to the domain "icanhazip[dot]com" followed by the IP addresses below:
The network communication can be seen in the following FakeNet output:
An additional SSL connection was also seen attempting to connect to the IP address 22.214.171.124, using an autonomous system in Moldova which is associated with the Dyre botnet:
To conclude, in this example we see this method being used to serve crimeware, but this technique could easily be modified to download any file type in such a way that it would not be presented within web logs or obvious in network traffic. This simple technique will certainly evade some Intrusion Detection Systems that are monitoring for the download of a specific file type based on HTTP header information.
Without measures to specifically detect this activity, network forensics tools would most likely classify the file as HTML, based on the initial request for the PHP file, potentially allowing suspicious content through without adequate screening.