Ransomware has been used to extort millions from individuals and organizations over the years, with attacks dating back as far as the AIDS/PC Cyborg trojan of 1989. Since then, file-encrypting ransomware such as CryptoWall and CryptoLocker has emerged as a favorite tool of cybercriminals for rendering data and devices useless while demanding massive bounties.

Late 2013 saw a rash of CryptoLocker attacks in which the malware encrypted users’ data and required users – via pop-ups claiming to be from the FBI – to submit payment for cybercrimes they had purportedly committed. With over 500,000 individuals falling victim to the attacks, it wasn’t long before researchers and media began calling CryptoLocker and similar ransomware the “worst malware ever.” In a Black Hat 2014 briefing called “The New Scourge of Ransomware,” CryptoLocker and CryptoWall were noted as breakthrough developments in ransomware due to the strength of their cryptographic capabilities. Since then, ransomware has only continued to spread and evolve, with a CryptoWall campaign claiming another 600,000 devices and encrypting 5 billion files throughout 2014. According to the FBI, the two families of ransomware have netted cybercriminals over $18 million to date; CryptoWall has accounted for at least $15 million of that figure since it first appeared in April 2014.

From an organizational perspective, a ransomware attack can be devastating and costly. While many of these threats are known, they remain highly elusive and difficult to detect due to the amount of variants being produced specifically to circumvent existing detection methods. As such, being able to detect and stop ransomware attacks before the damage is done is critical. With this in mind, we’d like to share a case from the Digital Guardian Lab to demonstrate a more effective method for detecting ransomware attacks through event correlation. This demo uses a fully patched Windows 7 x64 virtual machine.

Starting out, we see an unusual explorer.exe launch in which explorer.exe got relaunched independently by an unknown process:

Normally, explorer.exe would be launched as a child process of userinit.exe, which is one of the base-level processes triggered when a user first logs in or starts a computer. However, startup processes like userinit.exe close out once the computer is started, so it is uncommon to see userinit.exe or similar parent processes launching explorer.exe after initial boot up. In this case, explorer.exe launches from an unknown parent process, not userinit.exe. There are other legitimate/benevolent processes that can launch explorer.exe, so although seeing an explorer.exe launch from a parent process other than userinit.exe is unusual, it is not a unique enough trait to deem this as malware quite yet.

Within the same second, we see the process setting autorun registry keys – 4 times in total. This would enable a malicious process/malware to run automatically and avoid detection by the user. Again, this could be a normal process, but seeing this immediately after an abnormal explorer.exe launch gives us a better indication that it could be malicious. Still, it’s not enough to rule out the fact that this could be a normal application, so let’s move on.

Next we detect an abnormal svchost.exe execution in which svchost.exe launched as a child process of the suspicious explorer.exe process. While svchost.exe is a completely normal and highly common process, it is also known that CryptoWall 3.0 relies on svchost.exe to inject code that performs key malware functions (other factors that could point to a process being malicious include launch context, an unknown file hash, or VirusTotal scoring – there’s even the possibility that the process itself is spoofed and is masquerading as svchost.exe only to appear legitimate). Considering this, in correlation with the fact that we just saw an abnormal explorer.exe launch followed by suspicious autorun registry keys being set, we can take the suspicious child svchost.exe execution as evidence that a malicious process is being run on the computer. At this point, the Digital Guardian Agent would automatically block this process, but for the sake of a demonstration in a secure lab environment, we’ve let it continue to run.

By letting the process continue to run, we see repeated attempts at outbound network connections as the malware beacons out to find an active command and control infrastructure. This is the key step in the execution process where the CryptoWall 3.0 variant fetches its configuration file. At this point (in the wild) the malware would exchange keys with the command and control server and begin encrypting the host computer with 2048 bit RSA encryption - which is nearly unbreakable and would effectively turn the host computer into a very expensive paperweight.

It’s important to note that, from start to infection, this process spanned four seconds. Being able to block this activity in real time as it unfolds – in this case the abnormal svchost.exe process at the one second mark – is critical to successfully mitigating the malware attack. While many of these processes may seem commonplace on their own, the insights gained through the correlation of suspicious indicators enable us to proactively stop a ransomware attack in progress and before the damage – be it data loss, extortion, the opening of a backdoor for further attacks, or the “paperweight” scenario described above – occurs. Even more, by building a model for malware events based off of a unique series of processes, we have a baseline to help detect and prevent similar events in the future.

Dimitris Tsapakidis is professional services team leader for Digital Guardian EMEA. Andy Passidomo is a cyber security researcher at Digital Guardian.