Malware Analysis 101

Introduction

A common misconception about malware is the great difficulty of performing malware analysis and the technical requirements involved.

When many technical users are faced with a malware infection and asked to analyze it, they may think, “Hey, I’ve heard about this kind of malware. I’ve even read some malware reports, and they sound really complex! I’m not a professional malware analyst or a reverse engineer, so what can I possibly say about this malware?”

In this blog post, we break down some of these misconceptions and overcome the conceptual obstacles by demonstrating that most malware can be analyzed by practically anyone with basic technical abilities.

We will take you through a real life sample analysis and explain the mindset, individual steps, and some of the useful tools required to reveal the mystery behind malware.

The Case of the Mysterious POS Infection

The 2014 holiday season brought a great deal of joy, happiness, and credit card theft: many retailers reported being infected with malware intended to steal credit card data from their ‘Point-Of-Sale’ computers.

This seems to be a growing trend in the cyber-crime world, following some (in)famous malware revealed during the past year, such as the ‘Target’ and ‘BackOff’ malware.

Check Point became involved when a large US-based retail customer approached us, asking our assistance after being infected by a POS malware.

The customer provided us with 9 binary files to analyze that were identified on a “perimeter” host in his network. He also stated that, due to legal issues, he could not provide us with any additional information.

Every malware analysis should begin with a clear definition of the objectives. These are our main objectives:
• Understand the nature of the files.
• Understand the malware capabilities and estimate its damage potential.
• Explain how the malware was inserted.
• Explain how the malware extracts data.
• Obtain clues as to the identity of the actors behind the malware.

There are 2 methods for analyzing malicious files:
• ‘Static Analysis’ – Attempt to gather all possible evidence from the binary file without actually running it.
• ‘Dynamic analysis’ – Run the file and observe its behavior.

Static Analysis

The files are standard Windows executable files named sample01.exe, sample02.exe…sample09.exe. Windows files have many static properties that can contain useful clues. PEiD¹ and PEStudio² are the tools we used for static analysis of the windows executables.

This table sums up the major file properties:

Almost every executable file has embedded strings, and by reading those strings we can learn a lot about the file’s nature.

These are some of the interesting strings in our samples:

• Sample01 contains the embedded string –
‘C:local0asfreleasebuild-2.2.14supportReleaseab.pdb.‘ – This is a residue of the build environment, and gives information about the build computer local directories, the user name – “asf”, and the file name – “ab.”

For someone familiar with web systems or common hacking tools, ab should ring a bell. The name refers to the ‘Apache Benchmarking’ tool, which is commonly used as a stress testing tool for websites and produces custom web-based traffic patterns.

• Sample02 contains a lot of embedded strings. Surprisingly, some of those strings actually show us the file’s banner.

mimikatz 2.0 alpha x64 (oe.eo)
.#####. mimikatz 2.0 alpha (x64) release “Kiwi en C”
.## ^ ##.
## / ## /* * *
## / ## Benjamin DELPY `gentilkiwi`
‘## v ##’ http://blog.gentilkiwi.com/mimikatz
‘#####’

The name ‘mimikatz’ may also be familiar; it is a tool for extracting passwords from memory on a Windows OS. The rest of the strings confirm this theory as they are all located inside the ‘mimikatz’ open source code available on the Internet.

• Sample03 contains embedded strings which are basically the same as those found in Sample01. The sample also contains the string: ‘C:local0asfreleasebuild-2.2.14supportReleaseab.pdb.‘ We can therefore conclude that this is possibly the same file.

• Sample04 is really large. This is not very common; classic malware is not usually larger than 200K.
This sample contains many embedded resources, and is signed with a digital certificate issued to ‘SOFTPERFECT PTY. LTD.’ A Google search leads us to https://www.softperfect.com, which appears to be a legitimate software company with a wide range of products. Looking at the file`s vendor information, however, reveals that this is just an obfuscated version of the SoftPerfect network scanner.

• Sample07 does not contain a lot of imported strings, but most of the existing strings have suspicious system filenames: ‘svchost.exe’, ‘ntvdm.exe’, ‘lssas.exe’, and a text filename ‘tracks.txt’.

• Sample09 contains some interesting embedded strings, including ‘getmypass’, ‘1.ini’ and ‘rep.bin’.

One more thing to note is that most of these files are signed with the same digital certificate.

The certificate was issued to a company named ‘Bargaining Active’ by COMODO Code signing CA. The certificate was issued on May-8-2014 and was revoked just a few minutes later. The individual behind this certificate identified himself with the email address ‘pashulke67@gmail.com‘

A Google search for ‘Bargaining Active’ doesn’t lead to any relevant company, but does lead to many reports on POS malware. These are a few examples:

Report 1
Report 2
Report 3

Skimming through those links, it seems we have a possibly good match for Sample09 as the malware name and storage files match the ones we saw embedded in the binary. We can therefore safely conclude that this is a version of the ‘getmypass’ tool, which is designed to scrape RAM memory and steal credit card data.

A search for the email address ‘pashulke67@gmail.com’ we observed earlier brings us to this page, which contains a legitimate profile of Paul Pilyaki (a.k.a. pashulke), a teenager from Engels – Russia. The page is mostly about Russian pop music and web design.

To recap of what we already know about the samples, and which of our objectives have been reached, by performing basic static analysis:

Our Objectives:

1. Understand the nature of the files.
   The files we identified so far seem to be manually-operated hacking tools. No actual malware was detected. One of the files was identified as a memory scraping tool used to steal credit card data from POS systems.
2. Understand the malware capabilities and estimate its damage potential.
   An attacker with access to the infected host can: gather OS and domain passwords using the Mimikatz tool, scan network computers using the SoftPerfect network scanner, and scrape memory for credit cards using the Getmypass POS memory scraper.
3. Explain how the malware was inserted.
   Currently unknown.
4. Explain how the malware extracts data.
   Currently unknown.
5. Obtain clues as to the identity of the actors behind the malware.
   “Paul Pilyaki” may be directly or indirectly involved in this incident.

Dynamic Analysis

The next step is to actually run the files.
The easiest way to perform dynamic analysis is to run the files under a sandbox. This saves us the effort of setting up the environment and installing all the required tools.

We ran all the samples on Cuckoo sandbox³, using a Windows XP machine for the infection host. A summary of the gathered information is listed in this table:

The cuckoo reports of Samples 07 and 08 produced some very interesting results in the API call section:

Both of these systems have a very high rate of the ‘ReadProcessMemory’ API call. The API calls parameters appear to be simply reading the memory space of the running processes.

This is exactly the behavior we would expect to see from a memory scraper i.e. reading the processes’ memory space and searching for credit card numbers. We can therefore say with a high degree of certainty that samples 07 and 08 are also POS scraping tools.

To examine the dynamic strings, we ran the files one at a time on a virtual machine, and inspected the created processes using SysInternals Process Explorer⁴. Process Explorer allows us to see the runtime strings the process has stored in its memory space.

We obtained some very nice results for Samples 01 and 03 (suspected versions of the ‘ab’ tool):

This leaves us with no doubt that our initial hunch was correct, that those files are indeed a version of the ‘Apache Benchmark’ tool.

Our dynamic analysis stage is concluded. However, samples 5 and 6 still remain unknown. Unfortunately, there is no easy way to reveal their real nature without resorting to a debugger.

Without going into detail of the debugging phase, a quick analysis revealed that both those files are an obfuscated version of WinSCP, a common file transfer tool mostly used with Linux environments.

Once all of the samples were identified, we updated our objectives and summarized the new information we obtained:

1. Understand the nature of the files.
   These files are not malware but a set of hacking tools. These tools have been customized and obfuscated with the same techniques in order to avoid detection. (New)
2. Understand the malware capabilities and estimate the damage potential.
   An attacker with access to the host containing these files can scan the network, retrieve domain passwords, scrape processes’ memory, and transfer files. (No change)
   Since the attacker needs to have access to the computer in order to operate the tools, the damage extent can be anywhere from leaked private data and up to a full network disclosure. (New)
3. Explain how the malware was inserted.
   (No change)
4. Explain how the malware extracts data.
   Since one of the samples is a version of WinSCP it is safe to assume that the attacker have intended to use it to extract files from the network. The IPs this tool is automatically trying to connect might give out the file drop location. (New)
5. Obtain clues as to the identity of the actors behind the malware.
   “Paul Pilyaki” may be directly or indirectly involved with this incident. (No change)

Conclusions

The ”malware” in this case is a set of hacking tools that can be operated manually by gaining access to the machine or automatically by using a script, background job, scheduled task, autorun, etc.

Whoever planted the files on the network was seeking a foothold on at least one of the network hosts and planned to expand his operations by pivoting through machines using stolen domain passwords.

As the target was a retail customer, it is logical to assume that the attacker’s final objective was to steal credit cards data from POS machines.

We assume that the IP addresses used by the WinSCP variants were used as a location for dropping the extracted files. These IP addresses belong to private hosting companies based in Switzerland and Moldova, respectively. The hosts themselves are no longer active

The IP address used by AB tool was also involved in the attack, perhaps as a beacon server. This IP address is in the range of a UK broadband operator and seems to belong to a home user (although it might have been used as a proxy and may not directly lead to the attacker).

Paul Pilyaki, a.k.a. pashulke, is directly or indirectly involved in this attack as his name is registered on the certificate used to sign most of the attack files. This doesn’t necessarily mean he signed or implanted the files, as the certificate might have been stolen. However, pashulke failed to respond to any of our queries on both email and Skype.

As we do not have any access to the customer network, we cannot clearly determine how the attacker originally gained a foothold on the system. We also cannot estimate the extent of the compromise.

Epilogue

Having read this blogpost, individuals with no previous malware analysis experience should now feel more comfortable analyzing ‘mysterious’ samples.

While some malware is indeed very complex, well hidden, and technologically advanced, the majority of them are not any harder to crack than this case.

Table 1 – Sample Hashes

¹ http://www.aldeid.com/wiki/PEiD
² http://www.winitor.com
³ http://www.cuckoosandbox.org
⁴ https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx