Yara is an initiative that’s become more and more popular for incident handling, especially over the last year. This project has been widely spoken about on this and other blogs.
Here I’m going to show you a practical example for using incident handling triggered by ransomware. Over the last months there has been an increase in this type of malware that, in spite of the many warnings from those of us working in security and incident handling, is still having quite a big impact. Fortunately, the most recent incidents of ransomware where I have been involved, the compromise has only affected one user each time, which allowed us to focus more on the scope of the encrypted archives than on identifying the equipment that may have been compromised.
Extension identification
One of the first cases we were involved in was an incident with CTB-Locker. On this occasion, a user reported a message appearing on his desktop informing him that his archives had been encrypted and asking for a ransom to recover them. Once part of the incident had been contained by disconnecting the equipment from the network and identifying it as the only one affected (let’s not go into this here) we went on to determine which archives had been encrypted and which ones could be recovered (we would never recommend paying the ransom).
Of course, a lot of local archives were encrypted and couldn’t be recovered but those that had shared resources could be. We would like to remind you that any documentation relevant to the organization shouldn’t be left on local resources, but in centralized servers for many reasons (among them, for making backups and controlling the information leaving the organization).
Once the incident on the local equipment had been analyzed, we found that the encrypted archives had an additional extension .GHHURFF. Knowing this, it was no longer necessary to define a Yara rule, as a simple search for archives with that extension in Windows Explorer or a simple find in GNU/Linux systems showed us an acceptable result in a very short time.
Header
Another case we encountered related to ransomware was one where the archives the malware had encrypted didn’t add an extension but kept them as they were, so now we had to fix a Yara rule.
After analyzing their content, we realized that all the files, from whatever type of archive it was, started with the same bytes ({4d 12 03 df b2 2b 2e f1 d0 3e 4e b5 8d 01 0c 27 }).
In this case, we created the following Yara rule:
rule ransomware : Ransomware
{
meta:
author="S2 Grupo"
date="10/03/2015"
description="Detection ransomware infection"
strings:
$signature1={4d 12 03 df b2 2b 2e f1 d0 3e 4e b5 8d 01 0c 27}
condition:
$signature1
}
By doing this we found a lot of archives whatever their extensions or the type of document.
Magic number
Another recent incident related to ransomware we were involved in had nothing to do with the previous cases, so we had to identify what the encrypted archives had in common.
Initially we were going to use the entropy calculation function, as we thought the encryption randomizes the archive bytes, increasing their entropy. We abandoned this approach as it was too complicated to determine a number indicating an encrypted archive (we’ll leave this solution for future exercises).
After the high rate of false positives triggered by the rule mentioned above, we opted for trying to identify the type of archive of the documents. If the archive is encrypted so that it modifies the archive magic number, it is disabled and is then detected as “data”. So we used the magic model (not available in the version for Windows).
rule magic_data_type: Trojan
{
meta:
author="S2 Grupo"
date="12/03/2015"
description="Data mime type"
condition:
magic.type() == "data"
}
We saw some false positives here but, taking the archive extensions into account, they could be separated from those that were encrypted and recuperated.
Conclusions
In all the cases above, the impact of the compromises was very low thanks to the different organizations’ backup policies allowing the recovery of encrypted archives from previous backups. Awareness workshops had trained users in the dangers of e-mail and its safe use meant that the number of users affected was small. Because of this we could concentrate more on identifying the entrance point of the malware and the encrypted files to be recuperated, than on the contention and eradication phases. As in all the cases mentioned here, there were few users whose systems had to be platformed.
It must be stressed that in all the cases mentioned above the number of archives encrypted soared into the tens of thousands, so if we hadn’t been able to recuperate them from the backups, the impact would have been significant.
