1.exe Revisited
We discovered that many of the libraries imported were related to network communications. MPR.dll, WS2_32.dll and RTM.dll are all noteworthy when it comes to this functionality so the next step would be to see how these functions are used in the decompiled executable. Hopefully we can obtain some clues about the destination IP addresses that are being reached out to. We decided to use Hopper disassembler to decompile this executable.
Examination of the graph and code appears to indicate that this malware attempts to maintain a persistent process on the host system. This is done by checking to see if the malware's own process is running. If it doesn't, a new process is created for the malware. It also checks to see if the process is active or idle. The following is a small snippet of the decompiled code that demonstrates the idle process check.
This appears to be a common trait amongst most malware. Malicious software is not effective unless it continues to run on the system so we need to look at some other portions of the assembly code to get a better idea of how this malware will communicate with remote hosts.
Network communications appear to occur at memory location 0x00406230. At this location we begin to see interesting function calls such as 'getprotobyname', 'WSAGetServiceClassNameByClassIdW' and 'getservebyport'. One issue that we notice is there are no network indications such as an IP address or hostname. This limits our ability to see which destinations will be contacted by the malware. Our strings analysis led us to believe this would be the case but it is further confirmed as we look at the disassembled code.
So it appears that additional analysis will be needed to see exactly how this executable will interact with the system and network once it is executed. To do this we will need to perform some dynamic analysis on the executable. While we could normally run the executable in a secure lab environment, there are also open source tools that allow us to submit executables to be run in sandbox environment. We will opt to use a tool such as this since the infrastructure is already in place and we will not have to worry about any mishaps.
Dynamic Analysis
Malwr was chosen to perform the analysis for this piece of malware. It utilizes the Cuckoo Sandbox technology to perform dynamic analysis for files that have been submitted. Using this online services allows malware analysts to share results as well as check the analysis of other files as well. This is contingent upon having the hash value for that file we are looking to analyze and another analyst previously submitting the file. Let's take a look at the analysis that is provided to us for our own file which has been renamed to garfield67-1.exe.Local Indicators
One particular area of interest when it comes to analyzing the consequences of running malware on a host would be any local changes made to the infected system. These files can be important for the purposes forensic investigation. Additional malware could also be downloaded to and executed on the host.Edg1.tmp (md5:d41d8cd98f00b204e9800998ecf8427e), 2.tmp (md5:b396cb453ecc5d2949f6cb73c263e563) and GARFIE~1.exe (md5:954858bc0f115a4d6442afb333ec44c2) are particularly interesting. The first file would appear to be empty and returns no detections when submitted to Virus Total. The final two files have high detection rates. The GARFIE~1.exe is actually a copied version of the original malware executable.
Virus Total's vendor antivirus engines have commonly shown the name 'Dridex'. Dridex is a known Trojan that is classified as a "Banking Trojan" and has been linked to malicious macro use. Sound familiar?
Moving along, we also observed a good amount of registry changes including a modification to the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. This will cause the malware to run each time a user logs in. This is quite common when it comes to malware as it needs to run after a user has logged off or shut down their system. Now that we have discovered some of local changes on a system, we know what indicators to look for in future incidents.
Network Indicators
In order to understand what type of network connections are being made we had to download the PCAP file from Malwr. One of the first things we noticed is an HTTP POST to destination host 84.40.9.34 over TCP port 8080. The posted information does not appear to be human-readable. It is possible that the data posted is encrypted but we have no real solid evidence to determine if this is the case.This HTTP POST results in a server response of 200 which is indicates a successful communication.A quick WhoIs query for this IP address reveals that it is registered to a hosting company, Hostway Management, out of London. Hosting services are a common way to serve malware since it can allow a certain level of anonymity so this does not provide any further context in regards to the malware authors.
Next we see an HTTP GET request to host 198.57.157.49 which belongs to another hosting company out of Utah, USA.
This request, however, is responded to with a 403 Forbidden message. This appears to be the only GET request within the entirety of the network traffic. All remaining activity looks very much like the initial POST request we observed, only this time it is to host 198.57.157.49. These requests, like the first, all appear to have possibly been encrypted and result in '200 OK' response codes.
Although we are unable to confirm, it would appear that this could be some form of data exfiltration as would be expected in information stealing malware.
Conclusion
Analysis of the file clearly identifies the type of damage that mass phishing campaigns can cause, especially if they target certain industries. Our initial Word attachment contained a malicious macro that lead to a quick downhill slide as it downloaded malware to the host. This infection vector may not be the most effective but it still works on many unsuspecting users by masquarading as a trusted company.
We were able to obtain enough supporting indications that allow us to conclude that this malware is sending information from the host systems to a remote system. This could include any number of credentials or private information. Luckily, most antivirus vendors appear to have signatures in place for this activity and the network communications allow for IDS/IPS signatures to effectively detect and prevent outbound communications. The best prevention, however, would be to disallow the running of Macros for Microsoft documents.
1.exe Malwr Analysis
Resources:
Trend Micro - Banking Trojan Dridex Uses Macros for Infection
My Online Security - Amazon Co UK Order Dispacthed
Part One
Part Two