Malware authors are always looking for an edge to evade detection and extend the useful life of their creations. In the constant cat-and-mouse game between malware authors and security vendors, malware authors must constantly revise and reinvent their product. They will consider anything they can do to avoid detection. Along these lines, Microsoft PowerShell has gained popularity recently as a method for both installing malware and embedding malicious functionality within the script. We’ll take a look here at an example of the latter where the script itself executed malicious behavior.
Infection Vector
The typical infection path to the target is email – an attachment in a phishing email for example.
The PowerShell malware can be embedded in an attached Word document for example. When the user opens the Word Document attachment, a macro (actually a Visual Basic script) will run which loads and runs a PowerShell script. Macros will not normally run by default so the user must feel confident enough in the authenticity of the document to override the Windows warning and run the macro.
Analysis of the PowerShell malware
As shown in Figure 1, the PowerShell script is obfuscated with meaningless variable-names and base64 encoding. This obfuscation has no impact on dynamic behavioral analysis such as we did with VMRay, but can make life more difficult for a reverse engineer doing static analysis.
We start the analysis by uploading the PowerShell script. As we see from the VMRay Threat Identifier (VTI) Score in Figure 2, the PowerShell script is categorized as malicious. VMRay also posted the sample to OPSWAT Metadefender. Interestingly, of 40+ AV engines, only 5 flagged the file as malicious at the time (AV detection rates will typically rise quickly over time as vendors respond and update signatures). This certainly validates the value of multi-AV scanning, and highlights the risk of relying solely on any one AV vendor.
We can see in Figure 3 that a lot of files were created with the same name. The name is of particular interest: ‘files_encrypted-read_me.html’. This indicates that we are dealing with a ‘PowerShell Ransomware‘.
A look at one of these HTML-files confirms the suspicion (Figure 4). It tells you that all your files are encrypted with RSA-2048 encryption and you have to pay $500 to $1000 for the decryption program.
Let’s have a deeper look. A typical ransomware contacts its command and control (C&C) server to register and manage the new victim. This is exactly what we find in the network behavior (Figure 5).
The PowerShell ransomware connects to hxxp://skycpa.in/pi.php and sends a plain text POST-Request with the information about the key and user-id from the victim. Luckily for us, the malware author neglected to encrypt (ironically) the network traffic and we can read the key from the network traffic dump (Figure 6).
We can look further at the PowerShell ransomware by renaming the obfuscated variables. This shows us that the Post parameters ‘string’ and ‘string2’ build the encryption key.
$randomKey01 = ([ChaR[]](GeT-RandOm -Input $(48..57 + 65..90 + 97..122) -Count 50)) -join “” $randomKey02 = ([ChaR[]](GeT-RandOm -Input $(48..57 + 65..90 + 97..122) -Count 20)) -join “” $randomUUID = ([ChaR[]](GeT-RandOm -Input $(48..57 + 65..90 + 97..122) -Count 25)) -join “” … $postParameter = “string=$randomKey01&string2=$randomKey02&uuid=$randomUUID” … [byte[]]$byteArrayOfRandomKey01=[system.Text.Encoding]::Unicode.GetBytes($randomKey01) … $byteArrayOfRandomKey02 = [Text.Encoding]::UTF8.GetBytes($randomKey02) $RijndaelAES = new-Object System.Security.Cryptography.RijndaelManaged $RijndaelAES.Key = (new-Object Security.Cryptography.Rfc2898DeriveBytes $randomKey01, $byteArrayOfRandomKey02, 5).GetBytes(32)
Voila! We can now decrypt of all the files without paying up to $1000 for a decryption program from the authors.
Conclusion
The PowerShell ransomware has been kept very simple. It encrypts any files it finds that have common file extensions such as .doc, .wav (Figure 7) and tells the victim the bad news with a html-file ‘FILES_ENCRYPTED-READ_ME.HTML’. Contrary to what is suggested by the authors in the ‘FILES_ENCRYPTED-READ_ME.HTML’ information, the actual encryption algorithm used is Rijndael (better known as AES). The AES key should have been then encrypted with RSA for the key exchange. However, their lack of understanding of even the most basic aspects of encryption led them to make a critical mistake – not encrypting the network traffic itself. The AES key should have been then encrypted with RSA for the key exchange. This simple oversight made it rather trivial to uncover the decryption key through dynamic behavioral analysis.
Additional Links
OPSWAT Metadefender results
https://blog.gdata.de/2014/07/23801-poweliks-hartnackige-malware-ohne-datei
https://www.carbonblack.com/2016/03/25/threat-alert-powerware-new-ransomware-written-in-powershell-targets-organizations-via-microsoft-word/
https://securingtomorrow.mcafee.com/technical-how-to/malware-employs-powershell-to-infect-systems/
https://www.carbonblack.com/2016/04/06/who-needs-malware-powershell-and-wmi-are-already-there/
http://www.theregister.co.uk/2016/03/29/powershell_ransomware_hits_healthcare/
http://www.computerworld.com/article/3048282/security/new-ransomware-abuses-windows-powershell-word-document-macros.html
