Security Research
Showing results for 
Search instead for 
Do you mean 

POS malware - a look at Dexter and Decebal

spovolny ‎10-23-2014 01:51 PM - edited ‎10-23-2014 02:05 PM

Editor’s Note: the following is offered to our readers by HP DVLabs authors Vib Chhabra and Said Bin.. While the information included here was very relevant a few months ago it was not published. We are dusting it off and giving the authors their due.

 

GUEST AUTHORS: Vib Chhabra and Said Bin, HP DVLabs

 

Point of Sale (POS) systems consist of the hardware and software used in processing a retail purchase of goods or services. The information stored on the magnetic stripe of the card is collected and processed by the attached computer or device for the purchase. The data stored on the magnetic stripe is what is referred to as Track 1 and Track 2 data. Track 1 data is the information associated with the account number and cardholder’s name and Track 2 data contains information such as the credit card number and expiration date. 

 

Dexter

Dexter POS mainly targets credit and debit card data. It steals Track 1 / Track 2 magnetic card data through memory scraping or parsing of some specific processes. It then relays this information back to the command and control (C&C) systems for the malware.

 

How Dexter Propagates

Some targeted POS systems include major retailers, restaurants, hotels and any businesses using Track 1 / Track 2 at the point of purchase around the world. Even though the exact method of how it compromises the system can vary, POS systems are known to suffer from the same security challenges and vulnerabilities as Windows-based systems. They are mainly built with high functionality in mind at the expense of security. Removable media, email, phishing, websites, social networks or social engineering, and pirated software are some of the known ways that malware propagates today. Dexter could have used anyone of these means to compromise the POS.

 

Processes and Registry Activities

These are highlights of what the malware does once it establishes its presence in the compromised POS machine

  • Marks its presence by creating multiple mutexes of itself
  • Injects itself into iexplore.exe
  • Creates a loop for the process protect
  • Calls for kernel32.ReadProcessMemory to analyze the memory
  • Communicates with C&C

In this post we will focus on the way the malware communicates data back to the C&C. Upon execution, the malware creates multiple different mutex values to mark its presence. In computer programming, a mutex (mutual exclusion) is a program object that allows multiple program threads to share the same resource, but not simultaneously. This will allow it to lock a process or program object to avoid simultaneous access to a variable or other resources. In other words, it stops itself from infecting the compromised machine twice by checking the current PID if it is infected. There are five mutexes created by Dexter:

  • ShimCacheMutex
  • WindowsResilienceServiceMutex
  • ZonesCacheCounterMutex
  • ZonesCounterMutex
  • ZonesLockedCacheCounterMutex

In order for the malware to persist it must inject itself into a running process. It does this by creating a new instance of iexplorer.exe into which it injects its malicious payload before terminating the original instance of the process. Once the infected payload is started the following registry key is created:

 

"RegKey_Name": "USER\\S-1-5-21-1202660629-583907252-1801674531-1003\\SOFTWARE\\MICROSOFT\\WINDOWS\\CURRENTVERSION\\POLICIES\\ASSOCIATIONS",

"Process_ID": 1148,

"Process_Name": "iexplore.exe",

 

The malware maintains its presence by running a loop for the process protection. It runs MonitorChild function every 2 seconds to monitor the status of the currently running malicious process. In the event that this process is killed the malware detects it and creates a new Mutex of a previously suspended child process. Once the child process is in running state, it assumes the status of parent process and a new child process is created and suspended for future use.  

 

The primary function of this malware is to steal Track 1 / Track 2 data and relay that information to the C&C server(s). This is done by calling Kernel32.ReadProcessMemory to analyze memory data of these processes: svchost.exe","iexplore.exe","explorer.exe","System","smss.exe","csrss.exe","winlogon.exe","lsass.exe","spoolsv.exe","alg.exe", and "wuauclt.exe". Memory dumps from these processes are collected and parsed to extract the card data. 

 

The malware establishes an internet connection with its C&C and proceeds to submit HTTP POST requests. It posts the initial request shortly after compromising the system. The first request contains full information gathered from the host which an attacker can use as intelligence gathering and system identifier.  The string for the parameter names are hardcoded in the malware, but the values will vary based on the transmitted information. The following parameters are sent as the “full” request in the initial transmission:

 

  • page: (UUID of the host machine)
  • ump: (Track data)
  • unm: (Username)
  • cnm: (Computer name)
  • query: (OS name)
  • spec: (Processor type)
  • opt: (Unknown)
  • view: (Process list)
  • var: (bot version)
  • val: (5 bytes key string)

 

The malware detects if the host has previously connected to the command and control server to avoid resubmitting the full set of information; hence in recurring communication with the C&C it only submits a subset of the full information. The following parameters are contained in the partial/recurring transmission:

 

  • page: (UUID of the host machine)
  • opt: (Unknown)
  • view: (Process list)
  • var: (bot version)
  • val: (5 bytes key string)

 

Dexter malware employs a simple encrypting and encoding scheme on the variable data it collected from the POS system. This is achieved with XOR encryption and Base64 encoding of the resulting ciphertext. The XOR encryption key is a 5 byte random string stored in the ‘val’ parameter. It uses the Base64 encoding to avoid any null bytes which would terminate the POST request due to being invalid characters.

 

The malware does not use a hard coded host address. Rather, it contains a config file which, among other options, allows the attacker to specify one or more hosts for command and control. 

 

Figure 1: Encoded payload to command and control server

 

The parameter string values are first XOR encrypted with the random 5 byte key value and then encoded in Base64 before they are sent over the wire to a C&C host.  Let’s analyze the above communication attempt after running the sample. The string value stored in val is “eWjpb2s=” which can be easily Base64 decoded to retrieve the original 5 byte key of “ybiok”. This value is used as the XOR encryption algorithm to run against the plaintext data that needs to be sent over the wire.  For illustrative purposes we’ll use the username of “MDX” in plaintext and our 5 bytes encryption key ybiok.

 

 

 

 

 

 

 

As you can see the first byte of the plaintext is XORed with the first byte of the key, and the result is subsequently XORed with the remaining bytes of the key. Finally, the resulting ciphertext is Base64 encoded and placed into the “val” parameter for HTTP communication. 

 

We have demonstrated how Dexter relays information to its C&C server. The remaining part is how it receives further instructions from the C&C. 

 

The response comes in the form of a Cookie containing the parameter strings below. The server side follows the same convention as the POS client encrypting and encoding the response back to the infected host. 

 

  • update: (Updates the malware)
  • checkin: (Detect shutdown)
  • scanin: (Memory scraping for track data)
  • uninstall: (Uninstalls the malware)
  • download: (Download arguments)

The server uses the same key from the victim machine’s communication to XOR each plaintext string value of the parameter before responding. It isn’t much of a stretch to see how the above instructions can be used to extract further information and perform additional actions. 

 

Conclusion

Point of Sale systems present attackers a with target rich environment.  Attackers often exploit a basic flaw in the way credit and debit card data is handled on the POS system. Card data is usually encrypted as it is sent over the wire but it is not often encrypted while the payment is being processed at the POS terminal. Dexter is classical malware that takes advantage of this security weakness in the system. This specific malware does not have a self-propagating mechanism, but may spread via some of the techniques referenced earlier. Some indicators of compromise (IoC) include the creation of multiple registry entries and mutexes, iexplore.exe process hijacking and self-preservation techniques. Generally, this is a fairly simple and easily detectible piece of malware. It is highly unlikely that development was funded by a larger organization or nation state. Rather, based on the basic encryption and encoding scheme and the all-around lack of advanced techniques or features, it is the work of an individual with basic coding expertise.

 

Decebal

To compromise a computer system malware needs a point of entry, and most employ a social component.  Sites that have a high user interaction, such as POS systems, forums and social networking sites, offer a higher probability of infecting a system.  A user may click on a seemingly benign link in a phishing email or on a web page and unknowingly compromise their system.

 

The second step is to create an environment that runs the malware in the background. The goal of this process is to escalate privileges for the malware in order to gain access to subsystems that handle communication and storage. During this time the malware acts like a bot, where it tries to establish connection with a remote host in order to perform data exfiltration. For all those Star Trek fans this process is analogous to how the Borg assimilate certain species: they infect the host, compromise its defenses and then communicate with the queen.  In our case the “exfil” server is the Borg queen. The last stage of any malware is to deliver stolen information to its home base. The control server typically runs a PHP script that processes stolen information for storage.

 

To illustrate this we will be looking at a specific POS malware called Decebal. Decebal is named after the Romanian Emperor ‘Decebalus’, the last king of Dacia, and is a VBScript-based POS malware created by Romanian cyber criminals.

 

Decebal had been observed in early 2014 though various samples date it back to mid-2013.  Figure 2 shows a compromised server with a data drop – file “lindic.txt” - containing stolen credit card information:

 

Figure 2: Stolen track data on compromised server

 

To understand malware it’s often important to understand the mindset of its authors. Script kiddies typically seek the path of least resistance, while more complex malware may be backed by large organizations and even nation-states. The former condition is evident in the case of this particular malware. Decebal is written in Microsoft Visual Basic, which is an event-driven programming language that follows the COM programming model. This makes it ideal for the malware to target point of sale systems that run OPOS systems – OLE retail POS systems also based on the COM structure.

 

Basic analysis

All Visual Basic programs have both form(s) and modules.  Forms provide a graphical representation and modules contain event procedures – sections of code that are triggered by specific events. Our main focus in this malware is the Form_Load() sub procedure.

 

 

Figure 3: Malware execution flow

 

Ensure persistence and create an ideal environment for infection

 

In this sub procedure Decebal ensures its persistence and creates an environment for its targeted application, which is eventually used to transfer stolen information. The malware then proceeds to alter policies of startup programs located at “\software\microsoft\windows\currentversion\Policies\Explorer\Run” in order to run the target application at high privileges. Policies are features in Windows systems that control the working environment of a user account. It is a central management system of what the user can or cannot do on the system (Bott, Siechert & Stinson, 2009).  Once an ideal habitat is created, the malware replaces the user’s Microsoft Internet Explorer application with an altered version. It then proceeds to place a shortcut the startup folder of the user “\Microsoft\Windows\Start Menu\Programs\Startup.”  This is done to ensure the program is persistent through reboot, loading every time the operating system loads. With the policy changes in place, the target program (iexplorer.exe) is now ready to run without restrictions. It is also worth noting that the malware makes certain only one instance is running by using mutex objects. With this in mind the malware avoids the possibility of re-infecting the host. Such actions could interrupt its processes or actions during runtime.

 

Steal Credit Card Information from Memory

With the stage set its time to dance.  The code now performs memory-scraping. It examines regions of memory for sensitive information; in our case this information is credit and debit cards. This is done in the processing module of the visual basic form. Below is a graphical representation of how the malware approaches this task.

 

 

Figure 4: Malware memory scraping process

 

Like any process the first stage is to gather information, which reveals the vulnerable location where the application can execute its intended course of action.  Decebal takes a snapshot of all system processes that are running on the host system.  It then checks if those process IDs match with a calling process, in this case the current process spawned by the malware.  After this condition is met it ensures the process is not a critical process native to Windows.  This could be a failsafe mechanism required by the malware before it creates its own process.  Things are in motion now – the malware continues to gather system and memory information.  SYSTEM_INFO structure is used to define from where the memory needs to be scanned. This is accomplished by the lpMinimumApplicationAddress data member (a pointer to the lowest memory address accessible to applications). This value defines the minimum range for the malware to scan.  In conjunction to this, lpMaximumApplicationAddress is used for the maximum range.  The ranges are used in a Do-While loop as shown in Figure 5.

 

  

Figure 5: Defining access boundaries

 

Figure 6: Validating criteria for memory scraping

With ranges set the next step is to find valuable information.  Decebal checks for three important conditions:

1. Is the size of the memory region greater than zero?

2. Is the memory space private?

3. Is it accessible?

 

These are reasonable expectations as the first condition checks to see if we are looking at a valid memory location. RegionSize, a data member of the MEMORY_BASIC_INFORMATION structure, is used here to validate this condition. The second condition checks to see if we are looking at private information in memory.  This is done by looking at the memory type MEM_PRIVATE, associated by the hex value 0x20000.  The final condition checks if the memory is committed to memory or a pagefile.  A pagefile is a reserved location on a hard disk that is used as an extension of Random Access Memory (RAM). This is done by checking if the memory state is MEM_COMMIT, which is associated with the hex value 0x1000.  Once all these conditions are met, the malware proceeds to extract information and store it to a buffer.  The buffer is then passed to a function (ReadProcessMemory) that reads data from an area in memory (Figure 7).

 

Figure 7: Storing stolen information

 

Process the Stolen Information

Before going in to detail of how the credit card information is processed, let’s take a look at how it’s stored.  Any card that stores information can have up three tracks.  A track is the magnetic strip that contains information about the current card at hand. Credit cards have their information stored in track 2. This format was developed by the American Banking Association (ABA). Below is the layout description of track 2 data.

 

*** Track 2 Layout: ***

| SS | PAN | FS | Additional Data | ES | LRC |

SS=Start Sentinel ";"

PAN=Primary Acct. # (19 digits max)

FS=Field Separator "="

Additional Data=Expiration Date, offset, encrypted PIN, etc.

ES=End Sentinel "?"

LRC=Longitudinal Redundancy Check

 

Based on this information the malware uses a regular expression to extract the credit card information.  Figure 8 demonstrates that it targets the Primary Account information by checking to see if the number has a minimum of thirteen decimal digits and a maximum of nineteen. It then proceeds to look for the field separator “=” along with Additional Information following the field separator. Finally, it checks for a match in the form of alphanumeric characters that are anchored by the End Sentinel “?”. Figure 8 highlights the regular expression used in Decebal.

 

 

Figure 8: Validating the track data

 

This information is validated by the Luhn algorithm to confirm if those numbers are actual credit card numbers. . Figure 9 shows the variables Fata (Credit Card information) and Spate (Expiration Date information) being passed in the Luhn() and Validare_Spate() functions.

 

 

Figure 9: Luhn validation

 

Exfiltrate Data to the Home Base (C&C Server)

 

 

Figure 10: Command and control processing

 

The primary goal of most prolific malware is to infect a host, and then communicate back to its C&C for additional upload/download and other nefarious purposes.  Information stolen is worthless if it doesn’t reach its final destination. To accomplish this the malware initializes WinInet API functions named InternetOpen() and InternetOpenURL().  These functions are built on the Windows socket protocol and are essential for transmitting information from the infected host to its command and control overlord.  InternetOpen() establishes an internet session and InternetOpenURL() refers the handle to the current internet session. Figure 11 illustrates how these functions are used in unison.

 

 

Figure 11: Information processing

 

The parameters defined in this example include: co (computer name), us (username), av (anti-virus), os (version of windows operating system) and tr2 (track 2), and are hardcoded in the order shown above.  Each carries specific information about the infected host system.  The malware also validates no cookies are created by defining the internet flag no cookie popup associated with the hex value 0x200.

 

 

Figure 12:  Decoding and dumping

 

As an end point to the established connection, the C&C uses a PHP script to translate information it receives from the infected host.  Information encoded in hex format is converted back to string format and stored in a file called “lindic.txt”. This is seen in the following code snapshot:

 

 

Figure 13: Sorting the data

 

Conclusion

On the whole this malware appears to be the work of a junior developer.  It uses a basic encoding scheme to encrypt its information to hex data.  Some conditional checks have glaring issues that could easily cause the malware to not validate a process correctly.  Figure 14 describes a conditional statement that checks if current snapshot of processes are not a Windows internal process.

 

 Figure 14: Process monitoring

 

This condition would better meet its purpose with an AND operator rather than an OR operator. Such coding practices are hints that this malware was developed by an inexperienced programmer. This doesn’t reduce the impact the malware could have if deployed in a POS environment.  The general techniques used to create persistence, and hide under system processes could still be effective in avoiding detection.

 

About the Author

spovolny

Steve Povolny is a Senior Manager for DVLabs Security Research and Development teams at HP TippingPoint.

Comments
Giorgio di Grazia
on ‎10-24-2014 11:41 AM

Both Track 1 and Track 2 contain the Primary account number (PAN) and the Expiration date: http://www.gae.ucm.es/~padilla/extrawork/tracks.html.

Labels
Events
June 6 - 8, 2017
Las Vegas, Nevada
Discover 2017 Las Vegas
Join us for HPE Discover 2017 in Las Vegas. The event will be held at the Venetian | Palazzo from June 6-8, 2017.
Read more
Apr 18, 2017
Houston, TX
HPE Tech Days - 2017
Follow a group of tech bloggers for a new HPE Tech Day, a full day of sessions about how to create a hybrid IT, from hyperconverged to Composable Infr...
Read more
View all
//Add this to "OnDomLoad" event