As discussed in the an advisory published by US-CERT, Trustwave SpiderLabs has discovered a previously unidentified family of Point of Sale (PoS) malware. This blog post serves as a technical analysis of the Backoff malware family. While a number of variants have been discovered, this post will focus on the most recent version encountered (1.56 "LAST").
Installation
When the malware is originally run, it will to attempt to remove a previous version of itself (version 1.55 "backoff"). All associated files and processes are terminated. It will then attempt to open a pre-defined mutex to ensure it is not already running.
The executable then proceeds to copy itself to the following location if it is discovered that it is not already running within this path. This newly copied file is configured with the READONLY, SYSTEM, and HIDDEN attributes.
- %APPDATA%\OracleJava\javaw.exe
Additionally, if it is not running within the context of this path, it will spawn a new instance of this newly copied executable with the '-m [original_executable]' argument. The '-m' argument ensures that the file provided is deleted upon runtime. In doing so, the malware will remove the original executable when run from an incorrect location.
Finally, in order to ensure persistence across reboots, the following registry keys are set:
- HKCU\Software\Microsoft\Windows\CurrentVersion\Run [Windows NT Service] - %APPDATA%\OracleJava\javaw.exe
- HKLM\Software\Microsoft\Windows\CurrentVersion\Run [Windows NT Service] - %APPDATA%\OracleJava\javaw.exe
- HKCU\Software\Microsoft\Active Setup\Installed Components\{B3DB0D62-B481-4929-888B-49F426C1A136} [StubPath] - %APPDATA%\OracleJava\javaw.exe
- HKLM\Software\Microsoft\Active Setup\Installed Components\{B3DB0D62-B481-4929-888B-49F426C1A136} [StubPath] - %APPDATA%\OracleJava\javaw.exe
These registry keys ensure persistence via the common Run registry key, as well as the somewhat less common Active Setup technique. More information about the Active Setup registry key(s) can be found here: blogs.msdn.com/b/aruns_blog/archive/2011/06/20/active-setup-registry-key-what-it-is-and-how-to-create-in-the-package-using-admin-studio-install-shield.aspx
At this point, the malware is properly installed and configured for persistence across reboots.
Memory Scraping
As it is extremely common within PoS malware, this family performs memory scraping against any process not in the following list:
- explorer.exe
- lsass.exe
- spoolsv.exe
- mysqld.exe
- services.exe
- wmiprvse.exe
- LogonUI.exe
- taskhost.exe
- wuauclt.exe
- smss.exe
- csrss.exe
- winlogon.exe
- alg.exe
- iexplore.exe
- firefox.exe
- chrome.exe
- devenv.exe
Scraping of memory is performed via the common CreateToolHelp32Snapshot/VirtualQueryEx/ReadProcessMemory combination, as we can see below.
Unlike some PoS malware families, 'Backoff' doesn't use a hardcoded regular expression in order to discover track data, but instead uses a custom function.
Any discovered data is exfiltrated via a HTTP POST request. Please see the 'Command and Control' section for further information.
Keylogging
As we've seen more and more lately, this malware family includes a keylogging component in almost all of its variants. The notable exclusion is the first witnessed variant, version 1.4.
The technique used for this keylogger has been seen many times before. The malware registers a new class with the name 'wndRawClass', and creates a new message-only window via a call to CreateWindowExA. The procedure for this message-only window registers a new input device via a call to RegisterRawInputDevices. This newly created input device allows the author to capture keyboard input data. Finally, the malware makes calls to GetRawInputData in order to filter out input for keyboard input and to capture this data.
Non-ASCII input, such as when a user hits the SHIFT key, CTRL key, etc. are handled, as seen below. Additionally, the malware will obtain the text of the foreground window via calls to GetForegroundWindow and GetWindowTextA.
This data is then written to the %APPDATA%\OracleJava\Log.txt file. This data is not obfuscated in any way, and can be uploaded to the attacker via a specially crafted command. This is discussed further in the 'Command and Control' section.
Explorer.exe Injection
Another interesting feature of this malware family is that it attempts to inject a malicious stub of code into the explorer.exe process. Prior to injecting this stub, the malware will encrypt a copy of itself and write this data to the following location:
RC4 encryption is used, with a password of 'Password'.
The malware then injects a stub of malicious code via calls to WriteProcessMemory and CreateRemoteThread. The stub has a number of hardcoded kernel32 functions via their static addresses.
Once we map these addresses to their functions, as seen above, we can get a clear view of what this stub is doing.
The stub enters an infinite loop and attempts to continually open the mutex created by the malware originally during runtime. If at any point it discovers that it can open the mutex (indicating that the malware is no longer running), it will proceed to read and decrypt the nsskrnl file that was previously created. This decrypted read data is then written to the following file prior to being executed via a call to the ShellExecuteA function:
Finally, the stub will delete the winserv.exe binary after 300 seconds. Finally, the thread the stub is running in will terminate.
The described routine acts as an immediate persistence mechanism. If, for any reason, the malware is found to not be running, the injected code will decrypt and copy a new instance of the malware prior to running it. This newly created file is eventually removed to ensure unnecessary files are not remaining on the file system.
Command and Control (C&C)
All C&C communication occurs via HTTP. Specifically, POST requests to one or more statically defined URLs are made on a regular basis. These POST requests look like the following:
Please note that all data in the above example was generated in a closed sandboxed environment. No legitimate track data is being shown in this example.
The POST parameters seen in the above example contain the following information:
- op : Static value of '1'
- id : randomly generated 7 character string
- ui : Victim username/hostname
- wv : Version of Microsoft Windows
- gr (Not seen in version 1.4) : Malware-specific identifier
- bv : Malware version
- data (optional) : Base64-encoded/RC4-encrypted data
The 'id' parameter is stored in the following location, to ensure it is consistent across requests:
- HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\identifier
If this key doesn't exist, the string will be generated and stored.
Data is encrypted using RC4 prior to being encoded with Base64. The password for RC4 is generated from the 'id' parameter, a static string of 'jhgtsd7fjmytkr', and the 'ui' parameter. These values are concatenated together and then hashed using the MD5 algorithm to form the RC4 password. In the above example, the RC4 password would be '56E15A1B3CB7116CAB0268AC8A2CD943 (The MD5 hash of 'vxeyHkSjhgtsd7fjmytkrJosh @ PC123456).
An example of decoding the above example can be seen below.
When the malware makes a POST request to the attacker's server, the attacker has the ability to provide a command as a response. The malware accepts the following commands:
- Update
- Terminate
- Uninstall
- Download and Run
- Upload KeyLogs
- Thanks!
Most, if not all, of these commands are self-explanatory. The 'Thanks!' command is treated the default response for the server, and does not instruct the malware to perform any actions. The "Update" and "Download and Run" commands both provide a single argument of a location to download an executable file.
Conclusion
None of the techniques described within this write-up should be considered innovative, as the author simply made use of pre-existing practices when writing this malware.
While this malware is not revolutionary, it should still be treated as a threat. It is my hope that this blog post, in addition to the CERT advisory will help others create protections against this family.
***UPDATE***
Someone online noticed that the ET Pro Snort Sig #2807775 matched on Backoff traffic. Sure enough, the hash referenced in that signature is referencing a previously unseen Backoff variant. Specifically, the sample looks to be version 1.55 'thu'. I've included some IOC information about this variant below.
- Packed MD5: D0C74483F20C608A0A89C5BA05C2197F
- Unpacked MD5: 765E937D9405C7FBD084775D1DC32DF1
- Install Path: %APPDATA%\AdobeFlashPlayer\mswinhost.exe
- Mutexes:
- Undsa8301nskal
- uyhnJmkuTgD
- Files Written:
- %APPDATA%\mskrnl
- %APPDATA%\winserv.exe
- %APPDATA%\AdobeFlashPlayer\mswinhost.exe
- Static String (POST Request): ihasd3jasdhkas9
- Registry Keys:
- HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\identifier
- HKCU\ SOFTWARE \Microsoft\Windows\CurrentVersion\Run\Windows NT Service
- User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0
- URI(s): /hello/flash.php
