IT officials from the Department of Defense (DoD) have released an update to the Cloud Computing Security Requirements Guide (CC SRG), which establishes security requirements and other criteria for commercial and non-Defense Department cloud providers to operate within DoD. These kinds of updates are not uncommon. In fact, they are encouraged through an interesting use of a DevOps type methodology – as the DoD explains:
DoD Cloud computing policy and the CC SRG is constantly evolving based on lessons learned with respect to the authorization of Cloud Service Offerings and their use by DoD Components. As such the CC SRG is following an “Agile Policy Development” strategy and will be updated quickly when necessary.
The DoD offers a continuous public review option and accepts comments on the current version of the CC SRG at all times, moving to update the document quickly and regularly to address the constantly changing concerns of an evolving technology like public and private cloud infrastructure. The most recent update includes administrative changes and corrections and some expanded guidance on previously instated requirements, with the main focus on the updates being to clarify standards set in version one and alleviate confusion and any potential inaccuracy.
What is particularly interesting here is the DoD’s acknowledgment that management of cloud environments is constantly evolving, security requirements and best practices need to be iterative, and updates need to be made regularly to ensure relevancy. It’s also important to note that the CC SRG is only one of many government policies put in place to help government agencies securely and effectively implement cloud infrastructures. There are also guidelines like NIST SP 800-37 Risk Management, NIST 800-53, FISMA and FedRAMP to consider. All of these provide a knowledge base for cloud computing security authorization processes and security requirements for government agencies.
What the DoD’s updates to the CC SRG should reinforce for agencies is that they need to have a clear cloud strategy in place in order to ensure compliance and success in the cloud. Determining the best implementation of these guidelines for your needs is difficult in and of itself. Add to that the ongoing management and updates required to keep up with ever-evolving guidelines and an IT team can find itself struggling.
By partnering with systems integrators and software vendors, or working directly with a managed service provider, like Datapipe, government agencies can more easily develop a long-term cloud strategy to architect, deploy, and manage high-security and high-performance cloud and hosted solutions, and stay on top of evolving government policies and guidelines.
The Bucbi ransomware family, which dates back to early 2014, has received a significant update. In a recently observed attack, we also noted new tactics used to infect systems. The malware has historically been delivered via an HTTP download, most likely via an exploit kit or phishing email. However, in recent weeks, Palo Alto Networks researchers have observed attackers brute-forcing RDP accounts on Internet-facing Windows servers to deliver their malware. Additionally, the malware itself has been modified to no longer require an Internet connection.
Recent ransom notes left on infected systems identify the malware as belonging to the “Ukrainian Right Sector,” a far-right Ukrainian nationalist political party with paramilitary operations that opposes Russia but operate outside of the Ukrainian government’s authority. However, there are a number of Russian identifiers in the recent attacks. Consequently, it is unclear if the claims of responsibility by the “Ukrainian Right Sector” are accurate, and if so, what the reason behind and significance of the Russian identifiers.
Infiltration
Unlike many other ransomware families, this particular variant of Bucbi was delivered via a RDP brute force attack. The following five IP addresses were observed attacking the victim machine starting in late March 2016:
184.197.69
44.191.251
117.151.236
161.40.11
101.31.126
Many common usernames were used in attempted logins in this brute force attack, including a number of point of sale (PoS) specific usernames. It is likely that this attack originally began with the attackers seeking out PoS devices, and after a successful compromise, changed their tactics once they discovered that the compromised device did not process financial transactions. A truncated list of the usernames used in attempted logins can be found below.
Administrator
Aloha
Admin
BPOS
FuturePos
HelpAssistant
KahalaPOS
Oracle
POS
SALES
SERVER
Sqladmin
Staff
Администратор [‘Administrator’ in Russian]
Once the attackers successfully compromised this specific machine, they dropped an executable file that contains the following PDB string:
The Russian string above roughly translates to ‘Before running software’. Researching the filename above leads us to a number of Russian language forums that are discussing an RDP brute force utility named ‘RDP Brute (Coded by z668)’. While not confirmed, there is a possibility that this tool was used to gain access to the victim machine originally. A screenshot of this utility can be found below:
Figure 1 RDP brute force utility
Malware Analysis
The following sample was discovered on an attempted breach in early April 2016:
MD5: 410E395600C291C59D8C9B93FA82A7F3 SHA1: 2E385E8B8CEB01C9E638F8A95889B571D31AEF41 SHA256: 26F2BF1FC3EE321D48DCE649FAE9951220F0F640C69D5433850B469115C144FE Timestamp: 2016-04-02 16:40:13 UTC
This particular sample is configured to take one of the following two command-line (CLI) arguments. Should no argument be provided, it will attempt to start a service it expects to exist, named ‘FileService’.
/install
/uninstall
When provided a CLI argument of ‘/install’, the malware will proceed to create a service with the following properties.
Service Name: FileService Display Name: File Service Startup: Auto Path: [path of malware]
After the service has been successfully created, the malware outputs a printf statement of ‘Installation OK’.
When give a CLI argument of ‘/uninstall’, the malware will remove the previously created service and output a printf statement of ‘Uninstallation OK’.
When the service is run, the malware will generate a number of debugging statements that are written to a randomly named file with an extension of ‘.log’ in the %ALLUSERSPROFILE% directory. An example of this log file is below.
Figure 2 Log file written by malware
The malware begins by seeking out a file in the victim’s %ALLUSERSPROFILE% directory. The filename is generated by a unique algorithm that uses the victim’s volume serial number in conjunction with two 4-byte seeds provided to generate a unique 8-byte sequence. This sequence then has a search/replace performed on it in order to convert it into an alphabetic string. This function is represented below.
The algorithm above makes use of the GOST block cipher to generate a unique filename. GOST is fairly obscure, as it was developed in the 1970s by the Soviet government. It was declassified to the public in 1994. This particular technique for generating a unique filename looks to be specific to Bucbi, as no other malware families have been discovered using it.
The algorithm is used to determine if a key file is present on the victim. If this particular file is not present, the malware proceeds to generate one. Two files are created—one 580 bytes in size, and one 1060 bytes in size. Both files begin with a DWORD of 0x60000, as shown in the screenshot below.
Figure 3 Example key file written by malware
The cryptography used by Bucbi is still being researched by Palo Alto Networks. After the key files are generated, the malware will spawn a new thread that is responsible for encrypting network resources.
A call to WNetOpenEnum is made to enumerate all network disk resources available. Should a network disk be identified, the encryption routine will be run against this resource. The malware will ignore the following directories, but otherwise will encrypt every file it encounters.
C:\WINDOWS
C:\Windows
C:\Program Files
C:\Program Files (x86)
No file type blacklisting results in this particular malware being very inefficient, often taking several minutes before encryption is complete.
Files are overwritten, leaving them with the same filename that was originally present. Unlike other more popular ransomware families, Bucbi does not use a specific file extension for files that are encrypted.
It’s also important to note that the key files that were originally created are not removed. Additionally, the malware includes a decryption routine, which, while never called by the malware, exists and can be used with a simple binary modification to the sample. This would allow victims to recover their files without resorting to paying the ransom.
Once encryption completes, a README.txt file is placed on the victim’s desktop. This file contains the following information:
Figure 4 Ransom message dropped by malware
The BitCoin address mentioned in the above screenshot has a single payment of 0.00896 BTC at the time of writing. This payment, being so low in value, was likely a test transaction used. The email address of ‘dopomoga.rs@gmail.com’ has ties with the Ukrainian Right Sector in a number of external publications, as noted in the following examples.
Figure 5 Facebook post from November 4, 2015
Figure 6 Translated post from sectorpravdy.com
However, as mentioned earlier, there are a number of indications that the actor is of Russian origin or speaks the Russian language, such as the existence of Russian PE resources within the malware executable, as well as the Russian-related files discovered in the attack.
Similarities and Differences With Older Versions of Bucbi
As mentioned earlier, the Bucbi malware family is quite old, dating back to January 2014. Very little public information about Bucbi is available, other than an entry by Microsoft in mid-2014.
When comparing the newly discovered Ukrainian variant of Bucbi to an older sample, we see a number of similarities. Certainly one of the most noticeable similarities comes in the form of a debug string present in both samples:
The original filename of ‘FileCrypt’ is present in all observed Bucbi samples. Another glaring similarity comes in the form of how filenames are generated. All samples observed use the same GOST block cipher function mentioned in the malware analysis section. This function has only been observed in Bucbi samples to date.
Additionally, the key files used across samples is consistent, in both size and the leading 0x60000 DWORD value. Coding style between samples is consistent as well between all observed instances of Bucbi.
While these similarities are present, a number of changes have been observed as well. Most notably is the service installation method, as well as the command-line arguments of ‘/install’ and ‘/uninstall’. While the older Bucbi sample also took a command-line argument, it instead searched for the existence of the ‘-e’ parameter.
The implementation of a network-resource encrypt function looks to be new in the Ukrainian variant of Bucbi. Conversely, the use of an HTTP command and control (C2) channel looks to have been removed from this variant. Previous versions of Bucbi, seen as recently as June 2015, made use of a remote server, where victim information and the generated key information was uploaded.
Finally, we also observe a change in ransom notes. The following ransom page is presented to the victim in this older version of Bucbi:
Figure 7 Original Bucbi ransom page
Conclusion
Overall, this proved to be a curious attack, as the attackers originally gained access using techniques common to those of attacks seen against point of sale devices. It appears that once access was acquired, the attackers shifted gears to deploy a new variant of the fairly old Bucbi ransomware family. This particular variant purports to belong to the ‘Ukrainian Right Sector’, a far-right Ukrainian national political party. If true, this would indicate that this particular national political party has entered the ransomware space, potentially to fund their cause. However, various Russian-related strings and references leave doubt as to who exactly is behind this attack. Attribution of this particular attack is difficult as there simply isn’t enough evidence to conclusively determine who is behind it. Various conflicting evidence make it impossible to say for sure. However, what is clear is that attackers are shifting tactics in how ransomware is deployed, and ensuring their malware is constantly being updated to deter defenders.
Palo Alto Networks customers are protected against this threat in the following ways:
WildFire correctly identifies all Bucbi samples as malicious
A Bucbi AutoFocus tag has been created in order to track this malware family has been created in order to track this malware family
All domains/IPs used in this attack have been flagged as malicious.
