Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Alina POS malware 'sparks' off a new variant

Alina is a well-documented family of malware used to scrape Credit Card (CC) data from Point of Sale (POS) software. We published a series of in-depth write-ups on the capabilities Alina possesses as well as the progression of the versions. Xylitol has a nice write-up on the Command and Control (C&C) aspects of Alina.

In this blog post I'd like to discuss a variant that first cropped up in late 2013 and has been seen in the wild as recent as a month ago. Some anti-virus companies have identified similar samples as JackPOS, but there are several interesting behaviour differences that haven't been posted about in any other write-ups. It is clear that Alina, JackPOS, and this variant all bear close resemblances to each other, but there are behavioural differences that distinguish this version from the others which I have not seen detailed elsewhere. For the purposes of this write-up I will be referring to this variant as Spark.

AutoIt Staged Loader

The first and most interesting difference between Alina and Spark is that several of the samples have been found embedded in a compiled AutoIt script, which then loads the malware into memory. Both Security Affairs and Security Intelligence posted about a similar type of AutoIt compiled script being used as a loader with a JackPOS binary instead of Spark here and here, but did not provide many details. We will take a closer look at how the loader works.

AutoIt "is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting". This AutoIt script contains functions to allocate space in memory, map a binary into that memory, fix the relocations and Import Address Table, and execute the binary. A malicious binary is concatenated into a variable 4,000 bytes at a time and the script's functions are used to load and execute it. The script is converted into a windows executable by running the utility Aut2Exe, which produces a new binary with the malware inside it.


Figure 1: Compiling an AutoIt Script

Converting a script into an executable is a normal and useful part of AutoIt's functionality. I used a third party utility called Exe2Aut to recover the original script and retrieve the binary.


Figure 2: Decompiling an AutoIt Script

The use of AutoIt as a loader is an interesting tactic. We typically see malware authors writing a script to execute another binary on the system or perform some function needed to accomplish the dastardly deed the author set out to do. This script is then compiled using Aut2exe for AutoIt, py2exe for python, or perl2exe for perl. These programs include their respective interpreters in the compiled binary for executing the script and are generally considered to be unsophisticated malware. In this case, however, the script has a binary in a variable that is loaded into dynamic memory and fixes up all the addresses required for execution. This is a much more advanced technique and is reusable with different embedded binaries. Like all such loaders, the binary is initially obfuscated artefacts such as strings and import tables from the malicious binary.

Start up

Previous versions of Alina picked a name from a list of legitimate sounding executable names and copied itself into the oh-so-common %APPDATA% folder under the chosen name. Instead, Spark creates a sub-folder in (surprise) %APPDATA% called "Install" and stores its malicious goodies in there. These malicious goodies include copying the original executable to %APPDATA%/Install/hkcmd.exe and writing a file called ntfs.dat. Spark will always copy itself as hkcmd.exe as opposed to previous Alina versions that selected from a list of varying names.


Figure 3: Spark Install Directory

At start up, the malware builds the path to %APPDATA%/Install/ntfs.dat and checks to see if the file exists. If the file does not exist, it uses the systems volume serial id and overwrites the first 6 digits with random upper and/or lower case characters. The result of this operation is written to ntfs.dat and is used as the unique ID for the bot. Here is an example:

Volume ID => "602C0256"

Random chars => "mRtyfo"

Unique ID => "mRtyfo56"


Figure 4: Random Character Generation

This differs from earlier variants, which just used the volume serial id to identify the bot. If the ntfs.dat does exist, the identifier is read into memory. This unique identifier is included in the POST message for all communication with the C&C server.

Like all the other versions of Alina, Spark also adds itself to the commonly used HKCU\Software\Microsoft\Windows\CurrentVersion\Run\hkcmdkey in order to maintain persistence through reboot.

Spark uses a named pipe to synchronize moving the malware from its original execution folder to the %APPDATA%/Install directory. The pipe name is generated as \\.\pipe\spark<uniqueID> where <uniqueID> is the same as what is generated above. Using our previous example the pipe name would be\\.pipe\sparkmRtyfo56.

Black List

Alina includes a black list of processes that are not scraped for CC data. Spark takes the same black list as before and adds additional applications to the list:

Figure 5: Black List Differences

Since the author is looking for CC data, the choice to add additional processes is an easy one since these applications are highly unlikely to contain the data they are seeking. The majority of the additions are system and common processes.

Spark Execution Flow

Here is a general picture overview of Spark's execution flow:

12769_f82e9626-d40f-4ce5-93ed-d207d4796325Figure 6: Spark Execution Flow


The final two differences in this variant have to do with communication to the C&C server. Where previous versions used "Alina vx.x" as the User-Agent, Spark now uses something that is supposed to look legitimate.

9878_70358641-49b3-4271-9e46-668aece4bd3aFigure 7: Spark POST Example

As you can see, in their attempts to look legitimate, the author still includes the bot version but forgets to include the closing parenthesis. Here is an IDS signature that has been used to detect Spark.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN JackPOS Checkin"; flow:established,to_server; content:"POST"; http_method; content:".php"; http_uri; content:"User-Agent|3a 20|Mozilla/4.0 (compatible|3b| MSIE 7.0|3b| Windows NT 5.1|3b| InfoPath.1 Spark v1.1|0d 0a|"; http_header; fast_pattern:66,20; content:!"Referer|3a|"; http_header; pcre:"/\.php$/U"; reference:md5,3959fb5b5909d9c6fb9c9a408d35f67a; reference:url,; classtype: slr-et; sid:4004777; rev:1;)

This signature refers to the sample as JackPOS, but I think this sample falls somewhere in the spectrum of malware between Alina and JackPOS.

As you can see the Spark name has come up several times, both in the POST communication and the named pipe used by the malware. The usage of a version number suggests that the malware author had intentions to produce additional versions.

The POST data communication with the C&C server retains the same structure as Alina from v5.2 on, however, Spark chose to reverse the order of the XOR scheme used.


Figure 8: XOR'd POST Data

To recover the clear text message, bytes 18 through 35 (red) are used as a running XOR key for bytes 76 (green) to the end of the data and then the entire message is XOR'd with 0xAA. This will decrypt the entire message. The yellow section (including the red bytes) contains the header information, while the green is the dynamic data. Earlier variants would first XOR the entire message with 0xAA and then grab bytes 18-35 to decode bytes from 76 to the end. A minor change, but sufficient in that it breaks any tools made to decode any prior communications. I've written a ruby script that decodes and parses the traffic and can be found at spark.rb.


Spark and JackPOS have several similar techniques that relate them. The use of the AutoIt compiled script as a loader is a technique that we have not seen very much and its use with both JackPOS and Spark is a very interesting link. Both use similar blacklist approaches as well as custom functions for finding CC data. However, JackPOS almost exclusively attempts to masquerade as java or a java utility. It also either copies itself directly into the %APPDATA% directory or into a java based sub-directory inside %APPDATA%. JackPOS uses the MAC address as a bot ID and base64 encodes the CC data found on the system in order to obfuscate the exfiltration. In case you missed the link above, here is SpiderLabs' detailed write-up on JackPOS. It seems fairly clear that these are two different variants. So while these two samples appear to be related, Spark bears a much stronger resemblance to Alina than JackPOS.


There have been rumors and conjecture about Alina source code being sold off as well as JackPOS being a successor to the Alina code base. While I don't have a pony in the race, the Spark variant shows that someone has been updating the Alina source code recently. The Spark string that shows up in both the named pipe and the POST communication shows an obvious distinction from previous Alina versions. The use of AutoIt as a loader for both Spark and JackPOS variants indicate that it could have potentially been a version between the transition from Alina to JackPOS.

I believe it was Shakespeare who said, "Malware by any other name will still steal your credit card data", or something to that affect. Regardless of what you call these variants, the important part is to understand the details of this threat and how to keep your data secure.

Latest SpiderLabs Blogs

2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies

Trustwave SpiderLabs’ 2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies report details the security issues facing public sector security teams as...

Read More

How to Create the Asset Inventory You Probably Don't Have

This is Part 12 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

Guardians of the Gateway: Identity and Access Management Best Practices

This is Part 10 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More