After Brian Krebs reported the September arrests of alleged key figures in the cyber crime gang that developed and operated Dridex, Unit 42 observed a marked decrease in activity related to this banking Trojan – at least until today. Dridex re-entered the threat landscape with a major e-mail phishing campaign. Leveraging the Palo Alto Networks AutoFocus platform, we identified samples associated with this resurgence.
Malware
True to form, the Dridex crew continues to utilize Microsoft Word Doc files with embedded macros, just as they did at the start of 2015. The Bartalex kit, a favorite for various cybercriminals, constructs these macros to deliver their malicious payload. When a user opens the malicious document, the macro code reaches out to a URL and downloads the Dridex executable. We identified the following associated Microsoft Word Doc files and URLs from today’s campaign:
As of today, only 17 out of the 56 VirusTotal Anti-Virus (AV) scanners recognize the Doc files associated with this resurgence as malicious, and only two recognize the associated implant. The Palo Alto Networks AutoFocus platform correctly identifies all components of this threat under the Unit 42 Dridex tag.
Targeting and Delivery
Our analysis revealed that this return of Dridex is heavily targeted at the United Kingdom (UK).
AutoFocus map of today’s Dridex targets
Dynamoo’s Blog (Conrad Longmore) posted an example of one of this latest series of Dridex phishing messages. The malicious Doc files that we identified all employ a similar order theme in their naming convention (e.g., “Order-SO00653333-1.doc”), requesting that the recipient print out the attachment. While this phishing lure is not particularly sophisticated, it remains surprisingly effective for fulfilling the malicious actor’s objective.
Conclusion
Cybercriminals – especially those that have established prosperity and longevity – will continue to present threats to enterprises and home users alike, despite any setbacks as a result of arrests or other operational challenges. Even though key players in the Dridex crew may have been removed from the equation for the time being, the organization that they leave behind could very well remain viable; alternatively, other criminal groups are always waiting in the wing to assume control of certain endeavors should a vacuum or opportunity present itself. The October 2015 resurgence of Dridex is an example of how these threats continue to adapt and evolve.
Earlier this week we added two new members to the team: retired U.S. Army Major General John Davis and Sir Iain Lobban. We’re honored two decorated military and intelligence leaders have joined Palo Alto Networks, and we’re confident they’ll bring their decades of experience to further enhance the company’s cybersecurity strategy and global policy expertise.
Retired U.S. Army Major General John Davis joins us from the Department of Defense and will serve as Vice President and Federal Chief Security Officer (CSO) here at Palo Alto Networks. His responsibilities include expanding cybersecurity initiatives and global policy for the international public sector and assisting governments around the world in successfully preventing cybersecurity attacks. He left the Pentagon in May 2015 as the Senior Military Advisor for Cyber to the Under Secretary of Defense for Policy and served as the Acting Deputy Assistant Secretary of Defense for Cyber Policy. Prior to this assignment, Davis served in multiple leadership positions in special operations, information operations, and cyber, earning multiple military decorations. We’re honored he’s joined the team and confident his decades of experience will further enhance our cybersecurity strategy and global policy expertise.
Sir Iain Lobban has joined the Palo Alto Networks Public Sector Advisory Council, which serves as a sounding board for the Palo Alto Networks roadmap and vision for the needs of the international public sector, as well as strategy and policy relevant to global cybersecurity. An internationally respected leader, he was the Director of Government Communications Headquarters (GCHQ) in the United Kingdom from 2008 to 2014, having served as the Director General of Operations from 2004 to 2008. This is where Lobban pioneered an integrated service of intelligence and security. A partner and senior strategy adviser at C5 Holdings, he is also on the Board Financial Crime Risk Committee at Standard Chartered Bank.
These distinguished public servants will be tremendous allies in our efforts to prevent cyberattacks around the world. Welcome to the team!
How much should the U.S. government be involved in securing midmarket enterprises? It was one of several hot topics during this week’s “Accelerating America’s Middle Market” conference in Washington DC, hosted by The Wall Street Journal.
Scott Stevens, Palo Alto Networks VP, Technology and Worldwide Systems Engineering, was part of a panel titled “Can Cybersecurity Be Fixed?” alongside Michael Daniel, Special Assistant to the President and Cybersecurity Coordinator at the White House. Among discussions over private-public sector collaboration in cybersecurity and how midmarket companies should prioritize cyber investments, Scott was pressed on how those organizations should re-architect security to meet the challenge of today’s sophisticated cyber threats.
“We all got comfortable, but what we we have been doing is no longer working,” said Scott, describing how a poorly automated, point product approach to securing networks and endpoints has stymied our collective efforts to thwart cyber attackers. “Attackers are automated. Why are we fighting them with all these manual processes?”
Scott also highlighted the need for better information sharing and collaboration among peers in security. Attackers are organized, he explained.
“They don’t do it because they like each other,” he said. “They share techniques.”
Check out some photos from The Wall Street Journal event below, and learn more about Palo Alto Networks next-generation security platform here.
Left to right: John Bussey, Associate Editor from the WSJ; Michael Daniel, Special Assistant to the President and Cybersecurity Coordinator at the White House; and Scott Stevens, Palo Alto Networks VP, Technology and Worldwide Systems Engineering
If you’ve got your AWS re:Invent 2015 pass (Oct. 6–9, Las Vegas) and you’re building your schedule, be sure to set time aside to visit us at booth #331, where you can learn more about using our next-generation firewall and threat prevention features to protect your applications and data.
Common VM-Series for AWS deployment scenarios include using it as a firewall gateway and IPSec VPN termination point, allowing you to effectively extend your on-premises data center into AWS in a secure manner. A more involved scenario is to use it for VPC-to-VPC protection, controlling which applications can communicate with each other and blocking lateral threat movement. For employee remote access, we are seeing customers deploy GlobalProtect on the VM-Series for AWS – taking full advantage of the scalability and ubiquitous access that AWS brings to bear.
Can’t make it to AWS re:Invent? Then, check out these VM-Series for AWS resource to learn more:
In recent years, ransomware families are often glamorized as being some of the most dangerous types of malware. They’ve certainly caused a wealth of damage to end users with some of the more prominent malware families, such as CryptoLocker, CryptoWall,TorrentLocker, and TeslaCrypt infecting millions of users overall.
For readers that might be unfamiliar with ransomware, it’s a type of malware that is responsible for encrypting a user’s files with a key known only to the attackers. Examples of files that might be encrypted include financial documents, home movies, photos, or business-related files. In order to decrypt these files, the victim must provide a ransom, or payment, to the attacker, often in the form of a digital currency.
While ransomware is often thought to be bullet-proof, it is certainly not always the case. In early 2015, Emnisoft identified a new family of malware named PClock. At the time, the malware was riddled with issues, specifically in the way it encrypted files. It used a simple XOR encryption routine with a static key, allowing victims to easily recover their files without paying a ransom.
In August, we started detecting updated copies of PClock, which has been improved upon by the malware author. We set out to determine if this updated version of PClock holds up to some of the more prominent families. For the sake of clarity, I will refer to this newer version of PClock as PClock2 going forward.
PClock2 is written in Visual Basic. For a copy of this file’s IDA Pro database (idb), please referhere.
When initially executed, PClock2 performs a very simple anti-analysis check where it will sleep for a random amount of time and compare the time spent sleeping against a set value. This check is essentially looking for sandbox systems where the sleep function accelerates analysis.
Figure 2. Check by PClock2 for hooking of sleep function
A simple check is performed to determine if the malware is running with administrative privileges. Once completed, the malware sends the result via an HTTP POST request to a remote server. All data sent via HTTP POST requests is sent in the clear.
Figure 3. HTTP POST request containing administrative privileges
The ‘P0’ is statically set by the malware in the above request. The ‘1828’ represents the thread ID (TID) of the malware, while the ‘rnd’ GET variable is randomly generated.
Throughout the runtime of PClock2, it makes multiple HTTP POST requests to a remote server using the same characteristics, including the ‘PO[TID]’ and the current time. Additionally, the user-agent used by the entire PClock family, including PClock2, is consistent across samples.
PClock2 proceeds to copy itself with the name “winjab.exe” in the following path. While this particular sample is seen installing itself to the %ALLUSERSPROFILE% path, other samples have been witnessed using %APPDATA% instead.
%ALLUSERSPROFILE%\WinJab\winjab.exe
PClock2 also enables persistence by setting the following registry key. All instances of the entire PClock family have been found to use this particular registry key.
After installation is complete, the malware makes another HTTP POST containing the various file paths it used.
Figure 4. HTTP POST request containing file paths of malware
After installation, PClock2 will also set the following registry key with a value of ‘INSTALL_OK’.
HKCU\Software\VB and VBA Program Settings\CLOCK\SData\S
This particular registry key is used to hold the latest state of the malware. Other messages that might be present in this key include the following.
FSO object created
WALLET_OK
SCANNER_OK
EXPORTKEY_OK
CRYPTED_OK
SHADOWS_OK
EXPORTINFO_OK
PREPARE_OK
The following registry keys are also used within the CLOCK sub-path by PClock2:
Registry Path
Description
\BData\B
Holds current Bitcoin price
\CData\C
Holds key generated by PClock2 used in encryption
\EData\E
Date when key will be destroyed
\FData\F
The number of files identified for encryption
\WData\W
Unique bitcoin address used to forward payments to the attackers true bitcoin address
\PData\P
Version
PClock2 proceeds to use the API from blockchain.info to generate a unique Bitcoin (BTC) wallet identifier, which is configured to automatically forward payments to a hardcoded wallet identifier of ‘1MRfkK134ErfbcadUSoSUCBahngCqoBKju’. The following HTTPS request accomplishes this.
PClock2 will also make a request to the following blockchain.info address to determine the current value of BTC. This information is stored in the ‘\BData\B’ registry key as previously stated.
The malware proceeds to generate a unique key that will be used in subsequent file encryption using the following data:
Current Time
Process ID
Process Heap
Active Window
Clipboard Owner
Desktop Window
Foreground Window
Shell Window
This data is concatenated to form a string similar to the following:
Figure 5. Data collected to be used in formation of unique key
This data is then hashed using the SHA256 algorithm to generate a unique key. This key is stored in the ‘\CData\C’ registry key as previously stated. This key is also sent via a HTTP POST request.
Figure 6. HTTP POST request containing unique SHA256 key
PClock2 scans the file system of the victim in order to identify files that are to be encrypted. The following paths are ignored:
\AppData
\Application Data
\Boot
\Local Settings
\PerfLogs
\ProgramData
\Program Files
\AMD\
\Dell\
\HP\
\Intel\
\Norton\
Drivers
Microsoft
Setup
Windows
Games
iTunes
Sample Music
Sample Pictures
Steam
Additionally, for a list of targeted file types, please see the following link.
Once files are identified, PClock will begin encrypting them, one-by-one. Unlike the original version of PClock, this variant has forgone the simple XOR encryption routine in place of using RC4. The RC4 key is generated by concatenating the SHA256 value previously generated with the path to the file being encrypted.
250dd811187959220220574a185ccf669e06c0ee3926773a7cb94750c401812cC:\Documents and Settings\Administrator\Desktop\Form1.cs
It should be noted that PClock takes a very long time to encrypt these files. On a test sandbox, the malware took upwards of 20 minutes to complete encryption, which is less than ideal for an attacker as it gives the victim time to notice the infection and stop it. By comparison, the latest version of the CryptoWall malware family takes roughly 1-3 minutes to complete its encryption routine.
It’s also interesting to note that each time PClock2 scans a directory or encrypts a file, it makes an HTTP POST request to the C2 server.
Figure 7. HTTP POST request indicating a folder is being scanned
This resulted in over 1,000 requests being made on a sandbox machine, which contained little data of interest.
After it finished the encryption routine, PClock2 generates a VBScript file in the following directory:
%ALLUSERSPROFILE%\WinJab\tmp.vbs
This script file contains the following commands, which will delete shadow copies on the Windows operating system.
On Windows XP, the following dialog box appears to the victim when this script runs, making it fairly apparent that something suspicious is occurring:
Figure 8. Dialog box that appears to victim when VBS attempts to run
After running the clean up script the malware overwrites the ‘\CData\C’ registry key with a value of zero, which removes the unique SHA256 key. Finally, the malware changes the victim’s wallpaper and generates a GUI instructing the victim how they can provide payment and retrieve their files. This dialogue mimics the more-capable “CryptoLocker” malware family and provides instructions in both English and Spanish.
Figure 9. Ransom demand
Conclusion
I originally wished to determine if the new version of PClock, PClock 2, included enough improvements to compete with some of the larger ransomware malware families, such as CryptoWall, TeslaCrypt, or TorrentLocker. In truth, this version has made a number of improvements, such as adding more file types to target, ignoring certain directories, and using a better encryption routine.
However, a number of strong issues still plague this malware family, such as the following:
20+ minute runtime for the malware to complete
1000+ HTTP POST requests made
Dialog pop-ups to the victim requiring user input
While this version is an improvement, it still lacks many of the features and stealth that are currently present in the larger ransomware families. While ransomware is a large problem for users, it’s important to realize that not all malware families are created equal. Like most things in life, malware comes in many shapes and forms, from the more elegant and robust solutions, to those that come up lacking.
All PClock malware family samples are properly classified as malicious by WildFire. AutoFocususers can find more information on samples and indicators related to this attack by viewing the PClock tag.
