I recently performed some forensics on workstation for a client that had been infected with ransomware, which had resulted in a large number of their files being encrypted. This blog post discusses how the compromise took place, and also some thoughts about methods to prevent future compromises.
Infection Vector
A user’s workstation was infected with ransomware while browsing an innocent website during their lunch break. This website included adverts from a number of third party ad networks – including networks known for not properly verifying advert contents. In this case, the malicious adverts were from the ads1[.]solocpm[.]com domain – which has been linked to a number of malware campaigns, including CryptoWall. One of these adverts loaded the RIG exploit kit – a fairly recent exploit kit that emerged in April 2014, and has been used in a number of high profile attacks, such as the recent JQuery.com compromise. There have been a number of good articles discussing RIG (see Cisco), so I won’t go into it in any detail here. RIG contains a small number of exploits for browser plugins, and some sources also list a pair of Internet Explorer exploits.
Silverlight: CVE-2013-0074 Java: CVE-2012-0507 and CVE-2013-2465 Flash: CVE-2013-0634 IE 7/8/9: CVE-2013-2551 IE 10: CVE-2013-0322
The first thing that should stand out from that list is the age of the exploits – all of the exploits included were at least a year old when RIG was first seen in April 2014, but despite this, it was still an expensive and highly successful exploit kit. This is due to the fact that the vast majority of users fail to keep browser plugins up to date, regardless of whether they’re home or corporate users. It’s also interesting to note that increasing popularity of Silverlight exploits – for a long time these were pretty rare due to the limited usage of the Silverlight plugin. However, as NetFlix has risen in popularity (and requires the use of Silverlight, although they’ve announced plans to migrate slowly towards HTML5 since Microsoft announced Silverlight was going EoL in 2021), Silverlight has become more widely used, and thus a more popular target. The exploit kit was hosted on a compromised WordPress site. Hosting exploit kits on hacked websites is becoming increasingly popular, as it avoids the issue of having to register your own domains (with fake details, obviously), and also has some advantages that your kit is on a legitimate and trusted domain. The path it was hosted on (below) is a signature of the early users of RIG, which relied heavily on compromised WordPress sites. This kind of predictable URL makes it easier for to block the exploit kit with egress filtering, so was later dropped by RIG in favour of more varied URLs.
https://[host]/wp-content/themes/weaver-ii/proxy.php?PHPSSESID=[...]
It’s also worth noting that RIG is fairly crude in how it delivers the exploits to the end user. Many exploit kits will use JavaScript to enumerate the plugins (and versions) installed on the victim’s browser, and will then load a specific exploit based on that information, but RIG just loads all of its exploits into the page in the hope that one of them will work. This is a slow and noisy approach (more likely to trigger AV or other warnings), but seems to be effective.
Payload
The exploit kit was used to install CryptoWall on the compromised workstation, despite the antivirus protection that was in place. CryptoWall is similar to other ransomware (such as the more famous CryptoLocker), and encrypts all accessible documents with 2048 bit RSA and then demands a ransom. Again, other people have performed excellent analysis on CryptoWall (such as Dell Secureworks), so I won’t go into detail. As with a number of previous ransomware examples, CryptoWall searches for any drives which contain documents, photos or other data files, and encrypts them. While this can be very bad for a home user, in the context of a business where users have mapped drives to the corporate fileserver this can be devastating, and could potentially paralyse a company until the ransom is paid. In the case of our client, approximately 15,000 business documents were encrypted on the fileserver.
Mitigations
There are a number of different options that could be taken by a company to attempt to prevent infection by ransomware, or to mitigate the damage if an infection does occur. Bil has written an article discussing a number of these from a high level, so I won’t repeat what he’s written there. However, I will raise a few more unusual approaches that may be effective based on what I saw in this case.
Block Adverts Using malicious adverts to load exploit kits is becoming a very popular method for attackers to compromise systems, because of the relative ease of distributing malware to a wide audience. Many ad networks allow you to be very precise in targeting your adverts against a specific demographic, which is also an advantage for the attackers. And it’s not just small dodgy ad networks that are failing to properly verify adverts – a couple of weeks ago MalwareBytes reported malicious adverts from Google being loaded into high profile websites. Compromises like this one could be prevented by using ad blocking software, which prevents third party advertising networks from injecting arbitrary (clearly unvetted) code into legitimate websites as you browse them. There are fantastic free solutions like Adblock Plus that exist on all major browsers, and will provide you with a level of protection (although there have been some slightly suspicious changes to AdBlock – one of the other major solutions). Quite aside from that, adblocking also makes the internet much more pleasant, decreases bandwidth usage and page load time, and help prevent websites tracking you. Consider including Adblock Plus in your standard install – your users will thank you for it. Note that Adblock Plus allows some “Acceptable” adverts by default (which includes the Google subsidiary that was serving malware a few weeks ago), so make sure you disable this “feature”. For a large business blocking adverts at the network level is probably a more viable solution. This could be done on a corporate proxy server, or at the gateway if the device supports it. Failing that you could just DNS blackhole ad network domains (there are plenty of lists available online).
Disable Browser Plugins The vast majority of users do not need most browser plugins enabled, especially the Java plugin. Given the number of vulnerabilities that are reported in it, if you don’t absolutely need a plugin then it should be disabled. If a plugin is required for business reasons, then consider running it on an isolated system (or VM), with extremely restricted permissions. It’s also possible to configure the browser to only load certain plugins on specific whitelisted websites – so if the previous approaches aren’t feasible then consider doing so. There are plenty of guides online on how to perform this, such as this one on Stack Overflow.
Restrict Personal Web Browsing From Domain Accounts In the case I investigated, the compromise happened while the user was browsing a non-work related website during their lunch. While it’s equally possible for work related websites to be compromised, this may be far less likely depending on the nature of the business. Additionally, there are a fairly small set of website that most employees will need to access as part of their job. Most companies have acceptable use policies (AUPs) to prevent personal use of company systems during working hours, but many will take a more relaxed view on access during personal time (such as over lunch). However, as personal browsing can lead to a system compromise, which potentially expensive consequences for the business, this is perhaps a policy that should be reconsidered. Preventing personal internet access is not a problem that can be solved technically (as users will always find a way around your filters, unless you’re using a very aggressive whitelist which quickly becomes unworkable). Alternative approaches could be considered, such as providing users with separate, shared PCs to use for personal browsing at lunch time. These could be highly restricted systems, isolated from the main domain, perhaps with some kind of Linux installed to reduce the likelihood of a compromise.