A few days ago I was asked to have a look at the newly emerged crypto-ransomware threat “Locky” which utilises Dridex-like Command and Control (C&C) communications techniques. For some background reading, I recommend you read the following:
- http://sensorstechforum.com/aes-128-encryption-employed-by-locky-ransomware/
- https://nakedsecurity.sophos.com/2016/02/17/locky-ransomware-what-you-need-to-know/)
- http://www.theinquirer.net/inquirer/news/2447460/dridex-style-locky-ransomware-is-infecting-machines-via-microsoft-word
It looks like a new (FEB2016) addition to the crypto-ransomware family :
1. Dirty Decrypt
2. CryptoLocker
3. CryptoWall / Cryptodefense
4. Critroni / CTB Locker
5. TorrentLocker
6. Cryptographic Locker
7. TeslaLocker
8. Locky
Crypto-Ransomware is malware that encrypts files on the victims machine using cryptography (symmetric AES in most cases).
Once infected, the malware notifies the user of the “bad news” and demands ransom for decryption . The encryption keys reside on the attacker’s servers so victims cannot recover their files without paying the ransom . In locky’s case:
- It doesn’t steal victim’s information—instead it makes it impossible to access.
- Unlike most malware, it isn’t that stealthy after files are encrypted – for obvious reasons.
Macro (VBA) Malware
Concept was the first macro virus for Microsoft Word products seen in the wild, and was released in 1995. Whilst using the built-in capabilities of MS Word to deliver payloads is not new, it’s still an incredibly effective way of gaining access to the user and the host.
In recent years, this tactic has been used to form the basis of a very effective ransomware campaign using cryptography.
For this analysis, I leveraged dynamic methods and experimentation in a controlled environment as opposed to traditional debugging/disassembling approaches, which have also been followed to some extent. Due to the nature of the infector (crypted loader), it was not time efficient, nor even necessary, to statically analyse the infector in order to enumerate its pre/during/post infection behaviour patterns.
//delivery
Delivery is mostly via a MS Word document, making use of some social engineering in order to gain the trust of the user opening the document and executing the malware.
Using oledump, we could identify instances of VBA (Macro) code present within the Word document.
Further object analysis identified the presence of an Auto_Open() function and an ASCII (Chr())encoded array .
Ripped and replicated the VBA code revealing the “locky” infector download URL – and this is where all Dridex similarities end.
The URL was unavailable at the time of the analysis, so we had to pull the sample directly from VirusTotal .
The r34f3345g.exe binary is a VS C++ compiled 180kb PE executable with 4 sections of which one (.rscs) has a high entropy value. A high entropy value is a very reliable sign that the executable file has been processed with a packager or protector (crypter) of some sort.
The Basics
As a starting point, Locky creates a copy of itself in user\AppData\Local\Temp\svchost.exe, then conducts a series of HTTP POSTs calling main.php, removes any Volume Snapshot Service (VSS) files, also known as shadow copies, that you may have made preventing rolling back to a previous snapshot (vssadmin.exe Delete Shadows /All /Quiet).
Subsequently, it encrypts files and renames them to a 32 hexadecimal character identifier and appends a .locky extension ([unique_id][identifier].locky). So for instance when test.jpg is encrypted it would be renamed to something like F67091F1D24A922B1A7FC27E19A9D9BC.locky.
Finally it leaves a ransom note text file called “_Locky_recover_instructions.txt” in each directory that has been encrypted, pointing to servers on the Tor anonymizing network (both via Tor directly and through Internet relays) where the victim can make payment, and changes the Windows background image to a graphic version of the same message. It also stores some of the data in the Windows Registry file under HKCU\Software\Locky.
//brief static analysis
Performing some brief static analysis of the unpacked sample revealed some interesting anti-AV emulation techniques worth mentioning.
The code checks for MMX (Pentium 3) floating point SSE instructions. We assume this is in order to break out of Heuristics-based AV emulators, if it cannot emulate those.
The introduction of INT3 in a loop will cause the debugger to stop at INT3 (breakpoint) for each iteration, which will stop the AV emulator simply progressing through the loop.
Locky’s infector makes use of TLS (Thread Local Storage) callbacks, executing code before the official PE EP (Entry Point) is reached. The way that a debugger takes control over the process is to set a breakpoint at the process Entry Point (the first instruction that gets executed after the loader is done with mapping the file into memory in most cases e.g. in IDA, this place is labelled as start). However if TLS is used, the TLS callback functions are invoked even before the control is passed over to EP (start) and thus is effective in some cases in infecting the system before the debugger’s first breakpoint is reached.
The idea here is that anyone analysing the malware will fail to notice the presence of TLS. This in turn results in failure to understand the behaviour of the analysed code. In our case, locky performs some anti-emulation techniques in TLS.
What’s interesting about this particular sample is that the developers of Locky actively planned for the AV and Security industry to reverse engineer it and took active steps to throw off many in the process.
//system initialisation
On execution, the sample Melts (copies itself to Temp and removes the original executable from its “launch” location)
The next step is to remove shadow copies and set up persistence on the host via HKLM\Software\Microsoft\Windows\CurrentVersion\Run , this key is removed after successful encryption.
// communication
As with all good malware, it has to communicate to somewhere, with this particular sample, there were a number of hardcoded IP addresses so as timed based DGA (Domain Generator Alogrithm)
These IP’s are used for a number of campaigns and located in a number of geographic locations. As with all good malware campaigns, operating costs are kept low, so shared infrastructure is often used.
The communication between the host and the servers followed a standard process of situational awareness – profiling infected machine, determining network comms and making test calls back to control servers by iterating through what appeared to be a list of generated (DGA) domains/hardcoded IP addresses until a suitable reply was received.
All comms took place over HTTP (HTTP POST request to http://C&C IP/main.php )
//encryption
Once a reply is received, from one of the control servers, Locky sends an initial encrypted request, using an unknown built in obfuscation method. It then requests the server to provide an RSA1 key, which is presumably used to encrypt the AES-ECB key used for roll-on file encryption (which is returned to the C&C when encryption is complete ) – We are currently still performing research on this process and will update this post in due course .
The encryption WinAPI sequence used is as follows: CryptAcquireContext (Acquire a handle to a particular key container within a particular cryptographic service provider (CSP)) -> CryptImportKey (Creates a key object from key data in a buffer.) -> CryptEncrypt (Encrypt using the key held by the CSP module )
Once this step is complete, it reports to the control server and removes itself from the infected box, leaving a registry key. This indicates the successful encryption ,and a “polite message“.
Tools used:
oledump
ida
ollydbg
api-mon from rohitab (with hooking lib)
process explorer
procmon
Overall a interesting piece of malware that can be prevented by common sense, good backups and not trusting files sent via the Internet.
We perform a large number of incident response investigations for clients, if you are struggling to understand malware or breaches on your network, get in touch with our sales team.