Alina: Following The Shadow Part 1
Last I spoke with you, I went into the details of a family of Point of Sale (POS) malware, named 'Alina'. At the time, I chose to talk about version 4.0, mainly because I felt it gave a good representation of the entire family itself. In the course of my research, I've been able to acquire 12 distinct versions. As you may recall from the last blog post, Alina is versioned in the User-Agent field for all HTTP-based communication. For example, the User-Agent last time around was "Alina v4.0". Knowing this, I plan on talking about the evolution of this malware today, going from version 0.1 up to 5.5. Just for reference, I have the following versions at this time:
0.1, 1.0, 2.0, 2.1, 3.1, 3.2, 3.3, 3.4, 3.5, 4.0, 5.2, 5.3, 5.5
I'm going to break up this post into a few different sections, and talk about how the malware family has evolved over time with respect to various categories. As I started writing this, it became apparent that it wouldn't fit into one blog post. As such, I've split it up into different parts. For this blog post I'm going to focus on the creation timeline, exfiltration, and C&C.
Creation Timeline
Anyone familiar with the PE file format knows that there is a time-stamp field in the File Header that typically stores the time the file was compiled (I briefly mention it in a previous blog post, "Basic Packers: Easy As Pie" ). Attackers have the ability to 'stomp' this field of course, but there is no indication that any of the Alina samples were time stomped. Using this information, along with the version information provided in the User-Agent field, we attempt to provide a timeline of just when these versions first appeared.
I realize you may be noticing a few discrepancies with this timeline. The most obvious is likely the fact that version 1.0 appears to be older than 0.1, or the fact that 3.1 is older than 3.2. It's not an exact science I'm afraid, as we don't know exactly what the author was doing at the time. It's possible that he or she decided to simply recompile an older version and use it during a compromise, or perhaps some other events took place that would cause these oddities. It is also curious to note that both version 3.1 and version 0.1 were compiled with the 'debug' flag enabled. These are the only two versions in my possession that are compiled using this flag, which further adds to the mystery surrounding these particular versions. At any rate, it provides us a decent look at a general timeline of when this malware was created.
Unfortunately, version 5.5 utilized a UPX Protector layer, which destroyed the timestamp information in the PE header, which I'll discuss further in part 2. Based on the other information we have, however, it's likely fair to assume it was compiled sometime in March 2013, or early April of that same year.
Exfiltration
I talked about the exfiltration of version 4.0 in-depth during my last blog post. Let's take a step back, however, and look at how the author originally exfiltrated data and evolved his or her technique's over time.
v0.1/v1.0
Version 0.1 and 1.0 had a very simplistic technique for data exfiltration. Simply put, everything was sent in the clear with no obfuscation/encryption whatsoever. We can see an example of this below:
As you can see, there is simply one POST parameter of 'alina' that contains the clear-text track data. The only difference regarding exfiltration between version 0.1 and 1.0 appears to be the addition of the 'hwid' POST parameter in 1.0, which contains the volume serial number of the victim device. This is likely used as a unique identifier that allows the attacker to easily differentiate between victims.
v2.0
We see a significant leap in the evolution of Alina's exfiltration in version 2.0 of the malware. Namely, the author has decided to change the POST parameter names to something more discrete. Specifically, the previously named 'alina' parameter has been changed to 'a', the 'hwid' parameter has been renamed to 'b', and a new POST parameter of 'c' has been included, which contains the victim's hostname. We also begin seeing the first signs of encryption, as the track data has been XORed with a key of 0xAB, and then converted to hex. We see this technique of XORing the data and converting it to hex throughout future versions of Alina.
(Decrypted 'a' parameter using Ruby)
v2.1
Version 2.1 of Alina makes another leap in the evolution of this malware's exfiltration capabilities. It is at this time that we begin to see actual commands being implemented (discussed further in the C&C section). The 'b' and 'c' parameters have remained untouched, however, track data is no longer contained within the 'a' parameter. Instead, it is contained within the POST parameter 'cdata'. The same encryption routine is used to obfuscate this track data. We also see the addition of the 'v' parameter, which contains the version of Alina that is running.
The constant changing of POST parameters suggests that the author was either attempting to evade detections of network-based security solutions, or, perhaps more likely, simply was indecisive and was attempting to decide on the best way of sending this data to the server he or she controlled.
It was during this version that we also begin to see log messages being exfiltrated by the malware. Specifically, the 'ldata' parameter was used to send out logs periodically when certain events transpired. This log data was encrypted using the same XOR/hex technique used for track data. The malware also implemented a log level parameter in this version, which specified what logs to exfiltrate. We see this logging characteristic throughout a number of future versions of Alina.
v3.1
Version 3.1 did not vary greatly with regard to data exfiltration. The only apparent difference with POST requests is the addition of the "p" parameter, which contains the path of the Alina malware on the victim machine.
Additionally, it is in this version that we begin seeing a requirement for a 666 status code from the remote server. As mentioned in the last blog post, seeing a 666 status code is extremely unusual, and should raise an eyebrow or two for anyone monitoring network traffic. The requirement for this status code is an unusual decision for the malware authors to implement.
One other interesting addition in this version is the support for multiple exfiltration URLs. In total, three distinct URLs were utilized in the sample analyzed. In the event that a URL did not respond with the correct status code, or was unreachable, Alina simply attempted to try the next URL in the list.
v3.2
The main difference we see at this point is the fact that version 3.2 does not look for the '666' HTTP status code, as well as the removal of the log exfiltration request. This is an anomaly, as we see these features reintroduced in versions 3.3 and above. This further adds to the evidence that version 3.2 was in fact created before version 3.1, as it doesn't make a lot of sense to remove this feature and then reintroduce it.
v3.3/v3.4/v3.5/v4.0
From an exfiltration point of view, this version acts the same as version 3.1. One minor change we discover in version 3.4-4.0 is the removal of a minor piece of information in outbound log requests. Specifically, the output of the call to the Windows API call GetLastError is removed.
At this stage the author appears to be quite content with the exfiltration of his or her malware, as we see minimal changes to the overall structure it employs. You can see an example 'download' request of both versions below, illustrating the current POST parameter structure for these versions:
v5.2/v5.3/v5.5
It's clear that a lot of change occurred between versions 4.0 and 5.2. Referring to our timeline, we see that about a month of time elapsed between these versions. This is abundantly clear with regard to exfiltration, as the author(s) have completely removed their previous structure and replaced it with a custom one. HTTP POST requests are still the transportation mechanism to exfiltrate data; however, the data inside this POST request is completely different. You can see this below. I display the raw hex of the request to illustrate that non-ASCII data is being sent across the wire:
After analysis of the binary, I was able to determine the encryption in use and map out the layout of the data being sent. Like previous versions, a simply XOR scheme is utilized to obfuscate this data. The first 76 bytes of data are simply XORed against the key of 0xAA. This provides us with the following (using the above request as an example):
Any data past 76 bytes utilizes a different XOR scheme forobfuscation. Specifically, the decoded data at byte offsets 18 through 35 areused as the XOR key. The screenshot below shows us the data starting at offset76:
Now that we've been able to decode the data, let's talkabout how it's structure. Specifically, let's discuss how the data between byteoffsets 0 through 75 is structured. I haven't been able to identify everything,but there should be enough to provide you with a good grasp of the data thatthis blob contains.
Bytes 0-1 : Static Value
Bytes 2-16 : Alina Version / User-Agent ("Alina v5.2")
Bytes 17-24 : Victim Volume Serial Number (Example: "bc0b5931")
Bytes 25-26 : 2 Random Bytes
Bytes 27-35 : Command ("update", "cards", etc.)
Bytes 36-67 : Victim Hostname
Bytes 68-71 : Unknown – Likely Random 4 Bytes
Bytes 72-75 : Unknown – Likely Random 4 Bytes
One other interesting thing to note regarding version 5.x. When we begin to see log requests being sent across the wire and decoded, we notice some very unusual/interesting strings being used, as shown below:
It's unclear what these strings, such as '[:112 <2>] {[!16!]}{[!46!]}' mean, however, if I had to speculate I'd guess they were parsed by the server and used to indicate what data was sent. In the above example, it's possible that the '{[!16!]}' may represent process name, while '{[!46!]}' represents its PID. This is purely guesswork, as I have not been able to obtain access to any Alina C&C servers.
Command and Control (C&C)
v2.1-v4.0
Command and control in Alina was not introduced until version 2.1. Up to this time, we simply see the author decide to automatically upload any discovered data to a single host. However, when version 2.1 was released, we notice the author's decision to add an option to update the malware running on the infected host. This update request allows the author to perform two tasks—Update the malware or update the time interval between update requests. It uses the same technique discussed in my previous blog post where I detailed version 4.0. In fact, this technique is seen in every version between 2.1 and 4.0. As a recap, the author sends a request with an 'update' or 'download' request, like the one shown below:
(The response seen below was created using a mock server I created in Ruby. It is not the actual attacker's response).
The attacker, seeing this request, then has the option of responding with the following command:
ie:<update_interval>:<update_exe_location>
If the 'update_exe_location' parameter is specified, the malware will attempt to download this file, copies it to a random name in the %TEMP% directory, and executes with an argument instructing the malware to delete the original and replace it with the new one.
By allowing the author to update the malware, it also gives him or her the option of updating the exfiltration URLs, which are hardcoded inside of the binary itself. This update function can in theory also be used as a download/execute component, which can be used to install other malware onto the system.
v5.x
As we noticed with the exfiltration in version 5.x, we see a complete revamp of the network traffic. This is equally true with regard to Alina's C&C. As you may recall from the Exfiltration section, Alina uses byte offsets 18 through 35 as a XOR key. You may also recall that Alina uses offsets 27 through 35 as a command. The following commands have been identified:card
- cards
- update
- diag
Additionally, the following server responses have been identified, along with their description:
updateinterval=<integer>: Change interval between update requests
cardinterval=<integer> : Change interval between card exfiltration
log=1 : Enable logging (not verified)
log=0 : Disable logging (not verified)
update=<url>| : Update malware
dlex=<url>| : Download/Execute file
chk=? : Unknown
It's interesting to see the addition of an actual download/execute operation in version 5.x, as I speculated earlier about how the update command could be used for that same thing. All of the commands above are sent across the wire after being XORed with the XOR key used in the original request, which again helps to deter simple inspection of the traffic.
Conclusion
I realize I've only touched the surface with Alina, as I still haven't even talked about its installation process, techniques for grabbing track data, packers/crypters in use, etc, but I promise I'll do my best to address those details in part 2 of this blog post. Over the course of 3-4 months, we've been able to see the Alina authors continually update and improve upon their malware. It is likely we will continue to see this trend continue in the future, making it increasingly difficult to analyze over the wire or on disk. I've included the exfiltration URLs for all of the samples I was able to obtain in the wild (not in active cases), and also included the hashes for all of the samples in the appendix. Thanks for reading!
Continue Reading "Alina: Following the Shadow Part 2".
Appendix
Exfiltration URLs
hxxp://84.22.106.87/asdwer/1.php
hxxp://204.188.242.201/ocz2/up.php
hxxp://204.188.242.201/dada123/up.php
hxxp://204.188.242.201/brand_new/up.php
hxxp://204.188.242.201/sucky/upload.php
hxxp://204.188.242.201/forum/login.php
hxxp://193.169.87.147/e107/login.php
hxxp://208.98.63.228/wp-admin/abc.php
hxxp://208.98.63.226/goose/push.php
hxxp://fastbussineslife.net/path/up.php
hxxp://host3.com/path/up.php
hxxp://jikobins.com/forum/login.php
hxxp://zwaonoiy.com/wordpress/sam.php
hxxp://jikobins.com/sucky/upload.php
hxxp://ioconzus.com/sucky/upload.php
Hashes (MD5 Format)
1efeb85c8ec2c07dc0517ccca7e8d743
37493eb319d126d0ab8f5a55da85563d
c9e5752eea81f7d3521b1d2232afd3b8
a418410fa8b2617f3109dc289fa151c5
71fbca87e863db0aca080b4f87cc36f2
d31eb6e7f39dde0c2015dc2804c84a85
5d333312e3dd0fb7b5823696e99000e9
2139e613dc20df19daa6d90a0ff05591
0de9765c9c40c2c2f372bf92e0ce7b68
7cf5a421c3403441d84a0e34f81c3f0c
1efeb85c8ec2c07dc0517ccca7e8d743
e7e13912af192abe2f6ec90f6d429c6c
6686eed5875f622f5ed21397acb41d86
a3ce818621074333723b07a5a5c22e5b
8cdb63b3bfe16c0517e96b316eda3514
99a307128daa407147d1c69d2824d703
0ec4fada5b72e60756bcecec62fd6901
7bef391ddb8f0058823b7aaa96b1ba43
04474d2723d328ce28029c050ec6c0bb
108785e2f5de11df0da4138b8dd819df