Ransomware is a class of crimeware that locks down an infected system by preventing user’s access to their data stored locally or via accessible shared network drives. Access is only sometimes restored to the victim after a sum of money is transferred to a digitally remote blackmailer.

CryptoLocker is one of the latest variants in this family surfacing over the last few months has recently made some noise across the industry. Ransomware is one of the busiest (and most annoying) threats of 2013, and is experiencing another comeback tour so we decided it’s time to take a peek under the hood of the latest variant’s campaign to see what the author team is up to as of late and how different is the actual threat compared to the evasion techniques.

According to Virus Total, before the 7th of November this specific Cryptolocker variant was only detected by one Anti-Virus engine, AntiVir (woot, good job!). After hitting International threats lists, feeds and sandboxes this campaign, by about 0935 the morning of the 7th, the security Industry awoke to new detections for Cryptolocker that had been quietly active for over a week began to lose its edge of newness and stealth to the security industry. By end of the day on the 7th Cryptolocker had been detected by 22 antivirus engines.

Just this week on the 19th of November a new CryptoLocker campaign was identified using a new armoring technique to lower its detection rates significantly below its trailing detection rates against virus engines. Here’s a brief look at a sample from the new campaign this week. There are always subtle differences in the ‘threat post-mortem’ that could decrease the detection of the same threat only weeks later, at a substantially lower volume.

We analyzed each variant for about 40 minutes to compare what is so different under the hood between these two campaigns, which are part of the same class and family of threat. In the two figures below, we have a timeline of about 25 minutes and 44 seconds with enough activity to demonstrate enough malicious activity within only 10 seconds. Two weeks later the same threat re-armored and ran for over 34:31 before performing the same actions on the endpoint that generated observable effects. The grey columns indicate activity, with orange being indicating known malicious traits and effects, and finally red matching a specific condition that triggered analysis.

Based on the activity in the above timelines, we first want to look at the activity of the threat associated with file activity. When,what, and where did this process drop files across the endpoint to remain persistent? Let’s look at the figure below. First glance looks like the stage 1 downloader sample, executed wrote a file structure that looks similar to a Zeus binary based on the analysis of bukw.exe, logo[1].exe, bukt.exe, and ycso.exe, which all seem to be operating as backup downloaders self-spread by an armored version of Zeus. The stage 1 downloader then reaches out to the Internet and grabs bc.exe and update.exe, which is actually our stage 2 threat (aka Cryptolocker). What do we know now?

Exactly what we need to know about the file write activity from this threat, or do we need more? Let’s continue! Two weeks later the same threat was being delivered using not Zeus as a dropper but a different tool we haven’t seen previously, and one where we aren’t sure of its precise name. Though without analysis tools we do not need to know what it is. For actionable response purposes we only need to know the motive and intent of the threat (e.g. dropper, downloader, rootkit, worm, RAT, etc) to understand whether immediate or tactical actions should be taken against the newly introduced code to our endpoint.

As you can see in the 1st sample from the 7th that there was a fast track to anchoring the threat to the endpoint that was completed within the first two minutes after execution. Now two weeks later there was a 30-minute + delay while the process wrote to multiple areas of the endpoint’s Operating Systems. At this point, they are seemingly benign in nature, and not necessarily a threat to the Operating System where the sample from 7th had performed all of its primary functions within first two minutes. When analyzing the types of files written in the 1st timeline figure for the sample from the 19th (ced1eb3f884219e204565bdf68a16eb4) you will see there are significant differences in behavior, the most notable being the delay in execution, which amounts to a 30-minute difference.

Why is this important? Well there are many sandboxing technologies that run on an analysis timeframe, and traditional antivirus technologies typically are only able to monitor specific types of behaviors exhibited by a process. Additionally, they can’t make a decision based on a rule-set where specific actions exhibited are benign after a period of analysis time to effectively detect a creeping threat. There’s enough intelligence in the above file timeline alone to make some level of command decision within the first 28 seconds.

More importantly, the shell session captured when the batch file executed and deleted bukt.exe had already deleted the other remnants of Zeus’s stage 1, which is a fairly common tactic -- wiping your tracks via a script. A process killing another process is actually a common trigger for antivirus engine analysis and detection, but the use of a simple batch file to increase evasion and stealthiness to only have it delete itself upon completion is extremely clever!

In the above figures of each sample you can see a common batch file that was written to the file system and executed by each of the samples. The commonality of each of the threats is staggering when you look at the time of malicious intent exhibited by each. If that isn’t enough information to get you out of your seat, looking for more evidence is like an adventure. In the first 13 seconds of activity, not only did this threat install itself as a new system service, it also added entries into the user’s run at login, that is typically associated with ycso.exe (\AppData\Roaming\Voto\ycso.exe) listed above in the file timeline in figure 3.

Within 13 seconds there is enough to classify both the stage 1 and stage 2 as malicious and the need for action. You can see Cryptolocker running as a piece of lockware below, along with the nature of the trojan itself as it generated three classifications.

Finding malicious behaviors, traits, and effects isn’t difficult if you have the right vantage point to view all of the activity in-progress, while it is occurring as a means to understand the intent based on the endpoint effects within time, to counter the threat before it has finished its objectives. Below is a breakdown of the second campaign as a comparison to the first to see what actually changed between two weeks, and second, why detection rates decreased based on the observable effects the crimeware exhibited…that all of the traditional security products missed.

The difference is our vantage point across the Operating System provides a highly unique class of data, allowing our team to identify the traits exhibited by a threat; akin to standing chest deep in a lake and trying to find and stop a poisonous snake by looking into the water. This is how almost every security product’s approach to security is implemented – look for and check every possible angle.

There is a simpler way… You can stand fast and hold your ground and find the snake by looking for the ripples in the water generated by the snake’s movements. The only constant is the Operating System, as well as the impacts and effects on the endpoint that cannot be easily hidden in order to carry out tasks desired by persistent threats.