A couple of weeks ago the folks at Carbon Black discovered a new Ransomware strain that they dubbed “PowerWare”. What makes PowerWare interesting is its ability to encrypt files using the Windows PowerShell scripting language. Unlike other Ransomware, Powerware doesn’t need to install a binary on the infected machine. When enabled, Macros inside a weaponized document file silently extract and run the malicious PowerShell script.
PowerWare’s uniqueness pretty much ends there however. While likely to cause problems for unsophisticated users, PowerWare seems to be the work of amateur hackers. What’s even more interesting is that some of the claims made by PowerWare are completely false.
- The HTML code for the ransom notice is actually a direct copy/paste from another ransomware malware called CryptoWall (a much more powerful ransomware trojan).
- The ransom note claims to use RSA 2048 encryption (like other advanced ransomware) but in reality PowerWare uses a symmetric AES 256 bit cipher, which is relatively easier to break.
- PowerWare encrypts only the first two kilobytes of each file. A large part of the files, especially in case of text files, can be retrieved very easily.
- Unlike other ransomware, it doesn’t delete the Windows backup shadow copies, so files can be restored without paying the attackers.
- Their is no safe guard to ensure that the malware doesn’t encrypt the same file twice.
- No obfuscation is used to hide the code.
Ransom note used by PowerWare.
Ransom note used by CryptoWall
The only difference between two notes is the different TOR gateways and, in case of PowerWare, the note doesn’t mention the word CryptoWall. The borrowed HTML code for the ransom note is embedded inside the PowerShell script in the form of a base64 encoded string.
Asymmetric or public-key encryption schemes like RSA rely on two different keys to perform encryption and decryption. The private key is needed only for decryption and doesn’t ever need to be exposed.
By comparison AES is a symmetric or single-key encryption scheme where the same key is used both for the encryption and decryption. What this means is that the key that PowerWare generates to encrypt files needs to be communicated back to a C&C server to build the decryption tool. If one is able to intercept this key while it’s being communicated back to the C&C server, there is no need to pay any ransom (since the same key is used to reverse the encryption process).
The encryption algorithm (Key Generation to Actual Encryption) is visible in plain text inside the PowerShell script. Here is the how the encryption process works:
PowerWare uses 256 bit AES encryption that requires the key size to be 32 bytes. The 32 byte key is generated at runtime and is a function of 2 variables and a constant: a 50 bytes long password string, a 20 bytes long salt string and the number of iterations (fixed at 5).
50 Random bytes are generated at runtime between ASCII ranges 48 – 57 , 65 – 90 and 97 – 122. These numbers are converted to their character representation in order to form a password string.
20 Random bytes are generated at runtime between ASCII ranges 48 – 57 , 65 – 90 and 97 – 122. Like the password, these numbers are converted to their character representation in order to form the salt string.
32 bytes key generation is achieved through the ‘Rfc2898DeriveBytes’ class that Implements PBKDF2 password-based key derivation, using a pseudo-random number generator based on HMACSHA1.
The salt and password are both sent back to the C&C server using a plain text HTTP POST request.
where string=password and string2=salt.
The C&C server will use both of these strings to generate the original key (using Rfc2898DeriveBytes) needed to build the decrypter tool for this unique/particular machine.
A 25 characters long ‘uuid’ string is also sent to C&C server as unique machine identification. This uuid is used by the attackers to locate the password/salt pair for a particular machine.
- The fixed string “alle” is converted into bytes
- A SHA1 hash is computed from the converted bytes
16 bytes of the computed SHA1 hash are then used as the Initialization Vector.
Encryption scheme used by PowerWare is based on the ‘Rijndael’ method encapsulated in the “System.Security.Cryptography.RijndaelManaged” class. The ‘Rijndael’ mode of operation sets the ‘CBC’. Additional padding is set to zeros (which as a matter of fact is unnecessary because PowerWare just encrypts first 2k byte block of a file that is a multiple of 32 bytes key size).
Recovering from PowerWare
Use your Windows shadow copies to recover files before paying any ransom. This article provides some details on files recovery through shadow copies.
If your organization is running a full packet capture solution, you can easily retrieve the password and salt from the http packet. If you are unsure about how to construct the decryption algorithm, send us an email and we can send you a Decrypter tool for free.
PowerWare’s greatest vulnerability is its use of PowerShell scripting. The life of a Crimeware is dependent on its ability to morph using so called polymorphic code. Once a malware is caught the first time, the element of surprise is over. In order to evade security products again malware must change its behavior and shape quickly. But the problem is Introducing obfuscation in a power shell based script is not an easy task. Third party PowerShell obfuscation tools are pretty much non-existent at the moment. That will force guys behind PowerWare to manually change the code prior to their next attack, that judging based on their coding skills seems unlikely. It is more likely that the bad actors behind PowerWare will soon revert back to mainstream binary obfuscation methods where third party hacking tools (FUD toolkits) can obfuscate their binary payload on the fly, enabling them to evade current signature and sandbox based detection systems again and again.