Let’s Talk About NewPosThings
by Dennis Schwarz and Dave Loftus
NewPosThings is a point of sale (PoS) malware family that ASERT has been tracking for a few weeks. It operates similarly to other PoS malware by memory scraping processes looking for credit card track data and then exfiltrating the spoils to a command and control (C2) server. Based on compilation times, it has been in active development since at least October 20, 2013—with the latest timestamp being August 12, 2014. Since we haven’t come across any public details of this family, we’re releasing our malware analysis for posterity and to get ahead of the threat.
The analyzed sample has an MD5 of 4196c67648003a18f61573a77b6d3be6.
Its name comes from an embedded PDB pathname string from the analyzed sample:
C:\Users\Tom\documents\visual studio 2012\Projects\NewPosThings\Release\NewPosThings.pdb
The malware initializes itself as follows:
- Sets some insecure file flags in the Registry:
- “LowRiskFileTypes” in “HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations”
- “1806” in “HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0”
- Copies itself to “%APPDATA%\Java\JavaUpdate.exe”
- Checks whether it is running as 64-bit and if so, exits with a MessageBox of “Use 64bit version.”
- Kills any existing “JavaUpdate.exe” processes
- Sets up Registry Run persistence (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) under “Java Update Manager”
- Executes copied executable passing the original executable’s pathname and “RM” as command line arguments
- Original process exits
Second copy continues:
- Deletes original executable
- Phones home to the C2
- Searches the Registry for VNC passwords. The following keys and values are checked:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Ultravnc2_is1[InstallLocation] (then opens ultravnc.ini looking for “passwd=/passwd2=”)
- Sets “SeDebugPrivilege” privilege
- Starts memory scraping thread
- Starts C2 communications thread
- Starts key logging thread
The initial C2 phone home is HTTP POST based and looks like:
Header-wise: there is a bug with Accept as, per the code, it is supposed to be “*/*” and the User-Agent is hardcoded to “Mozilla/4.0(compatible; MSIE 7.0b; Windows NT 6.0)”. The POST parameters break down into:
- cs – is in base64 and decodes to “insert”
- The base64 charset used in this malware is “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_”
- p – contains Windows version, “+32” is hardcoded (most likely a placeholder for architecture type), and computer name
- m – the volume serial number of the root drive (used as an identifier)
An example response from the C2 is:
If any VNC passwords were found in the Registry they are exfiltrated to the C2:
The parameters are:
- cs – base64, decodes to “log”
- m – the volume serial number of the root drive (used as an identifier)
- ls – base64, example below
The response from the C2 can contain a couple of other commands:
- “update => url” – update self
- “install => url” – download and execute
- “not found” – remove self
Update and install both download to and execute from “%APPDATA%\Java\Explorer.exe”.
Credit Card Track 1 and 2 Memory Scraping Thread
Running in a loop, this thread takes a snapshot of all running processes it has access to on the system. For each process it:
- Skips if it is a system process, one of:
- Skips if the process is the malware itself
- Reads all accessible read/write memory
- Parses each byte looking for “^” or “=” – field separators used in credit card track 1 and track 2 data respectfully
- If there’s a match, further checks are done (track 1 and 2 are checked similarly):
- Working backwards from the separator looks for 13-20 digits that could make up the Primary Account Number (PAN). Ends at a non-digit start sentinel
- Checks the possible PAN with the Luhn algorithm—used to validate credit card numbers
- Checks that the expiration date is reasonable: year is between 13 and 19 and month starts with a 0 or 1
- Checks whether rest of the characters after the separator are digits
- If the checks pan out, the track data is RSA encrypted with an embedded PUBLICKEYBLOB, see IDA screenshot below
- It is then base64 encoded
- If RSA encryption fails for whatever reason, the track data is just base64 encoded
- Encrypted data is stored for later exfiltration to the C2
Credit card track data is exfiltrated very similarly to VNC passwords:
The “ls” parameter decodes to newline-separated entries:
>>> ls = myb64.b64decode("U2Nhbm5pbmcgc3RhcnRlZAo0MUR1ekN5NF9oOGJiOVpUSDV0blRpWXhUbG5INnB4V0g2OXhZcVBLckJ2SjN0RXlvT1ZaanJnei1EOVpsOURPVTlsYVBnejVpWndkZ3FxUkw3U3RzeEdwVUs1YWwzRHR3aTZvTW9hNjRXWF9LSm9Da0QxRENmTHRwQ1NTTUhvYkNKY3lJVWJJanBBR2hfUWlaMDNYOHRPZUpZTmJrbDRzclptU05qMjlPUmM9CmV2NzA2QXYyZTlKTUpKRmlWZzZOaGMwSE85dlFvNy15RFJ2ZlJ5TmpFVVA0SlVTQU8wYUh3eUFERTVDWWRQVWNYWWhmRThqX0Q0b1I2NnNxejZ1ZzlyVmR2N0c4ZTRPLWdQYW9aVjdVSmJaaS1pN2NWUDJlb3hxb0ZCZTdkZ2pJeWZUNTRNelRDamlqanF4VzV1a080ek1HaThvVUdkUGpEamVoN0RiMEtYQT0K")
['Scanning started', '41DuzCy4_h8bb9ZTH5tnTiYxTlnH6pxWH69xYqPKrBvJ3tEyoOVZjrgz-D9Zl9DOU9laPgz5iZwdgqqRL7StsxGpUK5al3Dtwi6oMoa64WX_KJoCkD1DCfLtpCSSMHobCJcyIUbIjpAGh_QiZ03X8tOeJYNbkl4srZmSNj29ORc=', 'ev706Av2e9JMJJFiVg6Nhc0HO9vQo7-yDRvfRyNjEUP4JUSAO0aHwyADE5CYdPUcXYhfE8j_D4oR66sqz6ug9rVdv7G8e4O-gPaoZV7UJbZi-i7cVP2eoxqoFBe7dgjIyfT54MzTCjijjqxW5ukO4zMGi8oUGdPjDjeh7Db0KXA=', '']
After the first entry, the rest are base64 and RSA encrypted credit card track data:
Credit Card Track 2 Key Logging Thread
The last thread starts by extracting a DLL from an executable resource and writes it to “%APPDATA%\Java\DLLx64.dll”. The filename is hardcoded even though the DLL is 32-bit. The “InstallHooks” export is executed which installs a keyboard hook via the SetWindowsHookEx function. After hook installation, the thread loops looking for Windows messages with an ID of 2023 (sent by the hook function). On receiving the message, a buffer of 400 keystrokes is collected and is searched for track 2 data as above—not particularly sure why the malware is looking for credit card track data in typed input though.
Command and Control Login
Samples and Campaigns
The following are the samples and campaigns known to ASERT:
Compilation date: 2013-10-20 23:15:49
Notes: I believe this is an earlier development version that differs somewhat from the above analysis. Copies itself to “%APPDATA% \Java\javaj.exe”.
Compilation date: 2013-10-22 00:40:30
Notes: Also an earlier development version using “javaj.exe”.
Compilation date: 2013-12-21 20:34:39
Notes: Also an earlier development version using “javaj.exe”. This IP has hosted a Citadel 184.108.40.206 C2 at hXXp://220.127.116.11/mentelbe/cita/server/file.php in the past.
Compilation date: 2014-05-11 10:31:02
Notes: Per Google Translate, “eklemek” is the Turkish word for “adding”.
Compilation date: 2014-05-12 19:00:35
Compilation date: 2014-05-12 19:03:08
Compilation date: 2014-05-15 12:30:47
Compilation date: 2014-05-15 12:32:05
Compilation date: 2014-05-20 19:32:42
Notes: Live C2 panel at time of writing. hXXp://vacation-promos.com/haefk/ek.php is also a live C2 at the time of writing, but I don’t have the associated sample.
Compilation date: 2014-08-12 15:43:20
Notes: This sample returns to copying to “%APPDATA% \Java\JavaJ.exe”, just using camel-case. The PDB pathname has also changed to “C:\Users\Tom\documents\visual studio 2012\Projects\jsd_12.2\Release\jsd_12.2.pdb” so the author may have rebranded it from “NewPosThings” to “jsd”. At the time of writing, the C2 panel is live and the domain has hosted an Andromeda C2 at hXXp://wordpress-catalogs.com/forum/gate.php in the past.
We’ve been using the following Yara rule for tagging and hunting:
// newposthings, Dennis Schwarz, Arbor Networks ASERT, September 2014
$pdb1 = "C:\\Users\\Tom\\documents\\visual studio 2012\\Projects\\NewPosThings\\Release\\NewPosThings.pdb" nocase
$pdb2 = "C:\\Final32\\Release\\Final.pdb" nocase
$pdb3 = "C:\\Users\\Tom\\documents\\visual studio 2012\\Projects\\jsd_12.2\\Release\\jsd_12.2.pdb" nocase
$str1 = "install =>"
$str2 = "update =>"
$str3 = "cs=bG9n&m="
$str4 = "cs=aW5zZXJ0&p="
(any of ($pdb*)) or (all of ($str*))
This post has been an analysis of a point of sale malware known as NewPosThings. Its modus operandi is similar to that of other PoS malware where it memory scrapes for credit card track data, does some basic verification with the Luhn algorithm, and then exfiltrates to a command and control server. While it appears to be in active development, the scope and distribution of this threat is currently unknown. ASERT continues to monitor NewPosThings and other PoS malware threats.