Alina: Casting a Shadow on POS

Over the pastfew months, a number of malware families targeting Point of Sale (POS) systems have been discussed. First there was Dexter (Seculert / SpiderLabs), then there was its big brother vSkimmer, and more recently there was Dump Memory Grabber / BlackPOS. One of the most interesting threads of commonality between these samples is the command and control (C&C) structure used between them. Utilizing a C&C communication channel for data exfiltration, while previously rare, has become more and more common in POS malware. I'd like to use this blog post to discuss another similar sample that I recently got the chance to look at, named Alina. We've seen Alina on a number of active forensic cases in the past few months, which is how I was originally made aware of this malware family.

Alina is not completely unknown in the reversing community. Xylitol has a nice writeup on a slightly older version, which you can find here. While an excellent read, I'd like to use this opportunity to dig into the mechanics of the malware further. There are a number of versions of the Alina malware family. For this post, I'm going to focus on version 4.0, which looks to have been created on February 7th based on the PE timestamp information. I have some newer versions, but I'm going to hold off talking about those until my next blog post, where I will discuss the evolution of this malware family and the changes made between revisions. So without further adieu, let's dig in.

Startup

Alina has the ability to be run with a few different arguments. If the following argument is provided, the malware will attempt to delete the specified file during execution.

alina=<path_to_executable>

Additionally, it will skip the installation process. Both this argument and the installation process are described in further detail later on. Alina can also take the following argument, which will alert Alina to update itself with the executable specified.

update=<orig_exe>;<new_exe>

In other words, we're updating the malware to a (presumably) newer version when we see this argument.

By default, Alina will attempt to install itself to the victim machine.

Installation

Installation is a multi-step process. Like many other pieces of malware, Alina makes use of the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key. However, unlike many other samples, this key is set to a random name from the following list:

• java
• jusched
• jucheck
• desktop
• adobeflash
• win-firewall
• dwm

If one of these keys are already found present on the system, it is deleted and a different name is used in its place. Additionally, the associated executable file that registry key pointed to is also deleted. This technique is essentially used to ensure multiple copies of Alina are not installed simultaneously.

Once one of the names above are chosen, and the registry key is set, the malware will then attempt to copy itself to the victim user's %APPDATA% directory using that name plus '.exe'. So, for example, if Alina decided to install itself under the 'java' name, it would copy itself to %APPDATA%\java.exe.

Once persistence has been achieved using this technique, the malware proceeds to call this newly copied executable with the argument of 'alina=<path_to_original_executable>'. As you may remember from earlier, this argument instructs Alina to delete that executable file. So in essence, Alina copies itself to a different location and instructs that new copy to delete the original when it's run. Just in case I've confused anyone, I've attempted to illustrate this process below:

Execution

So at this point Alina is installed and persistence on the victim machine is set. Now we get into the 'meat' of the sample. I.e. what does this thing actually do. Well, as mentioned at the beginning of this post, Alina is POS malware, which means it will attempt to target track data. Alina is in short a simple memory dumper with a lot of bells and whistles.

Alina, like many other memory dumpers, makes use of the Windows API call CreateToolhelp32Snapshot() and Process32First() / Process32Next() in order to iterate through every process on the machine. In order to expedite the process of dumping memory, Alina utilizes a blacklist approach to ignore well-known processes that may be running on the system. Specifically, the following process names are ignored:

• explorer.exe
• chrome.exe
• firefox.exe
• iexplore.exe
• svchost.exe
• smss.exe
• crss.exe
• wininit.exe
• steam.exe
• devenv.exe
• thunderbird.exe
• skype.exe
• pidgin.exe

If the process isn't in this list, it is added to a list of processes that will be subsequently scanned for track data. Once this process completes, the malware then proceeds to iteratively read through the process' memory and utilizes a series of regular expressions to determine if track data is present. As another technique to speed things up, the malware author decided to only look at memory pages that have the read/write attribute. If we take a second to think about the logic behind this, it makes complete sense. If a process is handling track data, it will have to read and write to the memory location where this data is stored. This allows the malware author to only concern (him/her)self with sections of memory that fit these attributes. The malware author is also concerning himself or herself with memory that is accessible to the process, further saving time.

I mentioned earlier that regular expressions were used by Alina to find track data. Specifically, the following three regular expressions are used to find information that it deems to be important:

Once Alina discovers any interesting data, it begins the exfiltration process.

Exfiltration

Exfiltration takes place over plain HTTP in the form of a POST request. I hope you'll forgive me in not revealing the server IP addresses or domains, but unfortunately this information has to remain confidential at this time. For what it's worth, plain HTTP is still by far one of the most common exfiltration channels we at Trustwave SpiderLabs see when looking at POS malware. To be fair, HTTP is easy to implement, and it works, so there's no real need for these attackers to reinvent the wheel per se. We have begun seeing much more advanced techniques for data encryption and exfiltration; however, these situations are still considered outliers.

Before exfiltration takes place, Alina encodes the data using a simple XOR key of "0xAB", and then proceeds to convert this data to its hex representation. This prevents the casual network administrator from easily determining what data is being sent across the wire, and also ensures that all data is within the ASCII range. We can see an example of this later on, along with a simple decryption routine that shows us the original data.

Alina has a number of POST parameters that contain various pieces of information (described in more detail in the C&C section). The parameter we care about below is the 'ldata'/'cdata' param (Log Data / Card Data respectively).

Log Data Example

Card Data Example

Using my favorite scripting language (Ruby), we can easily extract the original data.

Log Data Decode

Card Data Decode

I briefly mentioned the other POST parameters in these exfiltration requests. Let's look at them in more detail. Through simply deduction, I've been able to determine the meaning behind a number of these parameters, which I've outlined below:

In the event a correct request is made to the C&C server, it will respond with a 666 status code, which is extremely odd for anyone that is familiar with HTTP.

Those of you reading this blog post that are more awake than your sleepy friends might notice the 'd' (Download) above, which I haven't spoken about yet. Remember way back in the beginning of this blog post where I talked about how Alina can take the 'update=<orig_exe>;<new_exe>' argument, and has the ability to update itself? That's where this download option comes into play. Every 'x' seconds Alina will make this POST request and see if there is a new version available.

If there is a new version available, we will see the remote server reply with data in the following format:

iu:<update_interval>:<http_url>

The 'update_interval' parameter specifies the time to wait between making the update request. This value is read in as seconds. In order to add a bit of randomness to prevent detections from network-based security products that may look for repeated patterns, the author adds a random value between 0 and 9 seconds to this value. By default, Alina is configured to set this update interval to 300 seconds. Therefore, by default, we will see these update requests every 300 to 309 seconds.

The second parameter specifies the location of the updated copy of Alina. This file is downloaded to the %TEMP% directory (using a random 10 letter name), and the malware updates itself with this file using the 'update=' technique we saw in the Startup section of this blog post.

I realize this write-up is already becoming somewhat lengthy, but there's one more item I'd like to talk about before I wrap things up. The following response can be provided by the server when a log message is sent:

li:<log_level>:<log_interval>

The log_level parameter specifies the level of logging used by the Alina malware. By default, this value is set to '2'. Setting this to '0' will configure Alina to a debugging state, where all messages will be uploaded via a series of POST requests. I've shown some of these messages below (it's quite noisey):

The log_interval setting is used very similarly to the update_interval option used previously. This setting specifies the amount of time to wait between when logs are uploaded. By default this value is set to 120 seconds. A random value between 0 and 9 seconds is added to this in order to prevent predictable POST requests.

Conclusion

As we see POS malware authors evolve and continue to improve, it is likely that a C&C structure will become increasingly common. While it is not my intention to scare anyone reading this, the prevalence of automation with regard to control and exfiltration should help to paint a picture of the currently threat landscape, as hackers are continuing to gain access to POS devices across the globe. If you are responsible for managing a POS device, please be sure to set a strong remote access password, apply any necessary patches, remove unnecessary services, and follow general security practices to help prevent this sort of malware from being installed on your device.

With that said, thanks for reading, and be sure to keep any eye out for my next post, where I will go into the evolution of Alina, and how the author(s) have continued to improve and tweak the malware over the course of the past seven months.

Continue Reading "Alina: Following the Shadow Part 1".