This post is authored by Matthew Molyett.
In March, Talos reported on the details of Crypt0l0cker based on an extensive analysis I carried out on the sample binaries. Binaries — plural — because, as noted in the original blog, the Crypt0l0cker payload leveraged numerous executable files which shared the same codebase. Those executables had nearly identical functions in each, but identifying all of those functions repeatedly is tedious and draws time away from improving the analysis. Enter FIRST, the Function Identification and Recovery Signature Tool released by Talos in December 2016.
FIRST allowed me to port my analysis from the unpacking dll to the payload file instantly. Once I was satisfied my analysis across both files, I was then handed a suspected previous version of the sample. FIRST was able to identify similar code across the versions and partially port the analysis back to the older file. When the next version of Crypt0l0cker comes out, I will be able to get a jump on my analysis by using FIRST to port that work forward to the similar code. You can use it to port my work to your sample as well. I will demonstrate doing just that with a Crypt0l0cker sample which appeared on VirusTotal in April 2017, more than a month after the Talos blog about it. There has been no targeted analysis of this file to provide background for this post.
Locating the Sample
Procuring a malware sample of a known family without analyzing it can feel like a heavy challenge to overcome. Thankfully, Talos can leverage Threat Grid sandbox reports of suspected malware samples that we receive. Such reports can be scanned for family IOCs. Per our previous analysis into Crypt0l0cker, the infection status of that version is stored in a file named ewiwobiz. By searching Cisco Threat Grid telemetry for files which created ewiwobiz, I identified a file which was probably a Crypt0l0cker executable.