Threat Lab

GDPR represents a massive paradigm shift for global businesses. Every organization that handles data belonging to European residents must now follow strict security guidelines and businesses are now subject to hefty fines if data breaches are not disclosed. Organizations around the world have been busy preparing to comply with these new regulations, but many internet users are unaware of how GDPR will impact them. While this new oversight enhances user privacy protection, its implementation also opens the door for GDPR-specific cyber threats.

Anyone with even the slightest online presence has been subject to a barrage of new terms and conditions released by companies concerning GDPR, which became effective on May 25, 2018. Criminals are taking advantage of this overwhelming surge of new terms of agreements to execute scams.

A phishing scam purporting to come from Apple is the most popular that we’ve seen. It declares that “For Your Safety, Access To Your Apple ID Has Been Restricted”, then prompts users to update account information before being allowed back in. This particular campaign was designed to capitalize on fatigue from the myriad of updated terms of agreement and privacy policy notifications internet users have encountered in the weeks leading up to GDPR, hoping to catch them off guard. The idea behind the scam is that potential victims are less alert and more likely to agree to and click through anything related to updated terms and conditions. Here’s what the phishing page looks like:

Source: hxxps://www.securitycentre-appleid.com [phishing URL]

When victims click “Update Your Account”, they’re then presented with a fake login page designed to capture their Apple ID credentials.

Source: hxxps://www.securitycentre-appleid.com/Locked.php [Phishing URL]

Targeted Ransomware

Beyond simple phishing scams, GDPR brings new pressure criminals can leverage concerning personal data that companies are responsible for. Targeted ransomware has become popular recently, especially through the RDP attack vector. Cybercriminals are now in a much better position to demand substantially larger ransoms when dealing with company data belonging to EU residents than before.

Were criminals to target an organization handling EU resident data, they’d be in a position to leverage a ransom amount closer to fines meted out under GDPR laws once they’ve breached and encrypted the data. We expect to see an increase in targeted ransomware hoping to exploit the hefty GDPR fine structure.

Another win for cybercriminals comes in the form of the recent change to the WHOIS lookup, made in response to GDPR data privacy restrictions. The Internet Corporation for Assigned Names and Numbers (ICANN), the organization that manages the global domain system, has removed crucial bits of data from public WHOIS lookups to comply with GDPR.

Before this change, when queries were made on domains using WHOIS lookup, information such as registrant’s name, address, email, and phone number was accessible. This proved invaluable when tracking malicious domains linked to malware campaigns. Now, with GDPR, that information will no longer be available publicly, giving cybercriminals another edge. ICANN has since filed a lawsuit seeking to clarify the law as it relates to WHOIS data collection, according to Threatpost.

GDPR Fails

We’ve also seen some unfortunate failures from legitimate companies sending emails trying to educate and inform their customers of GDPR-related changes—and actually violating the regulations while doing so.

Source: @ashstronge on Twitter

In sending this email on blast to their contacts, the company above failed to hide email addresses, thereby sending their users’ contact information to everyone on their email list. A mistake like this may carry costly consequences under the EU’s new rules. It should serve as a reminder to businesses of all sizes– there’s a lot at stake when handling personal data. With only 42 percent of organizations in the U.S., U.K. and Australia reporting they are ready to comply with recent privacy regulations, ramping up information security safeguards will continue to be imperative in 2018.

Be on alert for scams related to GDPR. Interact carefully with the many privacy policy updates you’ve likely received in recent weeks. Remember to practice good cyber hygiene, and always double check website URLs whenever entering personal data.

What do you think about GDPR’s implications for the evolving threat landscape? Let us know in the comments below or join our Tech Talk discussion in the Webroot Community.

In light of the publicity, panic, and lingering despair around Spectre and Meltdown, I thought this might be a good time to clear up the differences between vulnerabilities, exploits, and malware. Neither Spectre nor Meltdown are exploits or malware. They are vulnerabilities. Vulnerabilities don’t hurt people, exploits and malware do. To understand this distinction, witness the CLIMB exploit:

The CLIMB Exploit

Frequently, when a vulnerability is exploited, the payload is malware. But the payload can be benign, or there may be no payload delivered at all. I once discovered a windows vulnerability, exploited the vulnerability, and was then able to deliver the payload. Here’s how that story goes:

It’s kind of embarrassing to admit, but one evening my wife and I went out to dinner, and upon returning, realized we had a problem. It wasn’t food poisoning. We were locked out of our house. The solution was to find a vulnerability, exploit it, and get into the house. The vulnerability I found was an insecure window on the ground floor.

With care I was able to push the window inward and sideways to open it. From the outside, I was able to bypass the clasp that should have held the window closed. Of course, the window was vulnerable for years, but nothing bad came of it. As long as nobody used (exploited) the vulnerability to gain unauthorized access to my home, there was no harm done. The vulnerability itself was not stealing things from my home. It was just there, inert. It’s not the vulnerability itself that hurts you. It’s the payload. Granted, the vulnerability is the enabler.

The window was vulnerable for years, but nothing bad happened. Nobody attacked me, and while the potential for attack was present, an attack (exploit) is not a vulnerability. The same can be true of vulnerabilities in software. Opening the window is where the exploit comes in.

My actual exploit occurred in two stages. First, there was proof of concept (POC). After multiple attempts, I was able to prove that the vulnerable window could be opened, even when a security device was present. Next, I needed to execute the Covert Lift Intrusion Motivated Breach (CLIMB) exploit. Yeah, that means I climbed into the open window, a neat little exploit with no coding required. I suppose I could have broken the window, but I really didn’t want to brick my own house (another vulnerability?).

Now we come to the payload. In this case, the payload was opening the door for my wife. You see, not all payloads are malicious. If a burglar had used the CLIMB exploit, they could have delivered a much more harmful payload. They could have washed the dishes (they wouldn’t, unless they were Sheldon Cooper), they could have stolen electronic items, or they could have planted incriminating evidence. The roof is the limit.

Not all vulnerabilities are as easy to exploit as others. All of my second-floor windows had the same vulnerability, but exploiting them would have been more difficult. I am sure happy that I found the vulnerability before a criminal did. Because I was forgetful that fateful night, I’m also happy the vulnerability was there when I found it. As I said, I really didn’t want to break my own window. By the way, I “patched” my windows vulnerability by placing a wooden dowel between the window and the wall.

There you have it. Vulnerabilities, exploits, and payloads explained through the lens of the classic CLIMB exploit.

NOTE: This blog post discusses active research by Webroot into an emerging threat. This information should be considered preliminary and will be updated as more data comes in.

New variants of Locky—Diablo and Lukitus—have surfaced from the ransomware family presumed by many to be dead. After rising to infamy as one of the first major forms of ransomware to achieve global success, Locky’s presence eventually faded. However, it appears this notorious attack is back with distribution through the Necurs botnet, one of the largest botnets in use today.

Webroot protects against Diablo and Lukitus

We first detected Diablo on August 9, 2017, and Lukitus yesterday, August 16. Since then, we’ve seen activity hitting Windows XP, Windows 7, and Windows 10 machines in the United States, United Kingdom, Italy, Sweden, China, Botswana, Russia, Netherlands, and Latvia.

How are these attacks deployed?

As with previous versions, the initial attack vector is through malspam campaigns in which phishing emails contain a zipped attachment with malicious javascript that downloads the Locky payload.

Once the Locky payload is dowloaded, it encrypts the users’ files with “.diablo6” and “.Lukitus”, respectively.

Then it changes the desktop background and provides the rescue pages “diablo6.htm” and “lukitus.htm”, which are identical.

Following what’s been standard for years, the Locky ransomware instructs the user to install a Tor Browser, then navigate to your unique .onion address to pay the ransom.

There is currently no available decryption tool that will work, other than paying the ransom to obtain the decryption keys. Although Webroot will stop this specific variant of Ransomware as a Service in real time—before any encryption takes place—don’t forget that the best protection in your anti-ransomware arsenal is a strong secure backup. You can use a cloud service or offline external storage, but remember to keep it up to date for personal productivity and business continuity.

For best practices for securing your environment against encrypting ransomware, see our community post.

Initial list of MD5s analyzed by Webroot

NOTE: This exhaustive list is current as of publication of this blog. We will continue to update internal lists but will not publish further additions until such time that we deem it necessary.

2E1A3A5F24AA6D725405E009949E6F0B

7821C8F49773EC65B9DFE8921693B130

544BC1C6ECD95D89D96B5E75C3121FEA

A2AEC1429D045355098355CAA371F23E

4779E473C909104272853EA1313BEE37

D7D22FFB1E746C20828422DA5CDF93DA

5245A7FA2351212EBF8257C55536791D

FE1CBC72C53AE7D8D16A5C943B5769FC

EA1832B7539BE8F265C08C0075CCB4DE

ACEA79268714A4752E3BF22161B90471

4BAA57A08C90B78D16C634C22385A748

0816080383AB3F33FEB9B6B51E854C73

0E05A7B9F1F2A19B678D2D92ABF70E47

F83DDED266CA056804BCC60EB998FA6C

4938F1D87F52473BC13C88498D6FC7AF

4BAA57A08C90B78D16C634C22385A748

F83DDED266CA056804BCC60EB998FA6C

8009E4433AAD21916A7761D374EE2BE9

E7E5628F67CB2FA99A829C5A044226A4

4BAA57A08C90B78D16C634C22385A748

3506AB24DB711CF76F95F89B4990981A

ECDAFEF0E38D2B5F24B806AF4FD54CC6

89ED8780CAE257293F610817D6BF1A2E

E613CF78955A4C1D8732B0ECB202CAEC

45021A1A159DEA9952AD3494B8D49852

993608B9AEA2B351E4BA883FEE8916B0

FBE9106026AF42CD24AB970ED718A579

23CCA546A85B5CAA12441F7F4C6B48E4

01DA2F592A64F2ABA0986319436177A5

96E214BAF7F26B879BAF0D87D830F916

040C537F575ED64374AB7F38F27E03F1

D3C856485116A09CAA37D867561BD634

BA82AA75BF6FC2549049877ACE505A24

9C6F2921CE536393198C605C15AE8C91

941CDFF8A86E56D11FCAF25CF7C2129B

Webroot SecureAnywhere® Business solutions will now give admins more ease of control within the Global Site Manager (GSM). From web overrides to Mac- and PC-specific enhancements, we’re delivering new features you asked for to ensure the best multi-vector protection possible.

Webroot protects endpoints against myriad threats at multiple attack stages spanning a variety of attack vectors. One way we do that is through Web Threat Shield evaluating the risk of a given website based on its history and association with other internet objects, i.e., its reputation.

Enable Web Overrides

We’ve released a GSM Console update giving admins the ability to configure create overrides on the default blocking behavior of Web Threat Shield. This ability to whitelist certain websites will give admins greater control and customization over which sites are allowed, in the event that a particular site with a lower reputation score is necessary to complete certain business tasks.

Mac-Specific Changes

An improvement you can expect to see over the coming weeks will be managing Mac endpoints via policy. Updating the Web Threat Shield browser plug-in for Mac is an important first step towards providing more similar experiences across Mac and Windows platforms.

Please notify your clients of this update

Due to security measures specific to Mac browsers, your clients may receive a message when the browser extension updates. When agents receive the update, the Safari and Chrome browsers will launch themselves. Safari will ask the user to indicate they trust the updated browser extension, while Chrome’s message will be purely informational and can be closed without further action. Firefox will wait until the user launches it to throw a notification for the new browser . View a video of the anticipated user experience here:

PC-Specific Changes

Throughout June and July 2017, Windows endpoints will also receive an update. The update will be largely silent; however, individuals with older versions of Firefox will experience a pop-up.

Based on customer feedback, we’ve reduced the number of risk levels from five to three. The new categories will be Trustworthy, Suspicious, and High Risk. Additionally, we will no longer block specific categories (e.g., “proxy”), and will instead block by reputation only. Finally, we will provide more straightforward explanations for why websites have been blocked.

To learn more about these updates, visit the following update bulletins:

• Enabling Web Over ride from the GSM Console: (GSM Console 0)
• Web Threat Shield 1.2.0.82 –
• Mac Browser Extension Update
• PC Agent 9.0.17.24 Update

Locky (.osiris)

O Locky, Locky! Wherefore art thou, Locky?

Alas, could Locky be no more? At the beginning of 2017, data from the field suggested potential Locky infections had decreased dramatically, so we were hoping it was on its way out. Unfortunately, Locky returned with a vengeance, though it had changed its methods somewhat. Upon further investigation, we located a number of binaries in %temp%, “a1.exe” and “a2.exe “, instantly seeing a connection to Nemucod; a name given to a family of Javascript droppers.

After additional research and decompiling several scripts, we’ve come to the conclusion that the same scripts used in previous months to distribute the .crypted “Nemucod” ransomware were suddenly downloading Locky and Kovter instead. Why the change?

Various online reports suggest that Necurs—a set of rootkit/botnet control servers—had gone offline. These were the same servers that sent out massive amounts of spam containing Locky droppers. Based on the information available, we think the bad guys changed their delivery method when these servers fell out of commission. (Incidentally, blocking the %temp% files blocks the infection, so we’re in a good position here!)

Nemucod

The Nemucod script developer used a simple script that runs another script which is then hosted on a compromised website. Those websites then randomize the contents of the script every few minutes. This means that security solutions that still use static signatures are often laughably ineffective at stopping these threats. The randomized website script is not part of the initial script, and is only readable via attachment to the WSCRIPT.exe process.

Initial script received via email:

As you can see, the script above uses “GET” to grab the response text from 1 of 5 compromised websites (var x) and evals that response text.

Sample response text from a compromised site:

When de-obfuscating scripts, I find it simpler to reverse the function used to evaluate the obfuscated content. I de-obfuscated this response script by using the initial script above with the previous function for the variable z2, which is actually eval, as follows:

was modified to

Here’s the final script, which downloads and runs the files (a1.exe and a2.exe).

Below is an example of the network traffic from this script, where the &r parameter is the downloaded payload.

CRYSIS

This ransomware is still only being distributed via compromised user accounts on RDP enabled machines. The most recently used extension is “.wallet” and it’s very common to see the ransom note email as *@india.com.

Below is a ransom note example:

Samples:

https://www.virustotal.com/en/file/31fc83f5e70515777fb4919cf249e3d2208895b96060f68a270f97377944b362/analysis/
https://virustotal.com/en/file/79b08105bbe4b7b407be42656f43c1533c725f951bc4f73c3aa9f3e68d2b3a15/analysis/

Spora

We discovered Spora last month, but data from the field suggests it isn’t too prevalent. The most common infection vector for Spora is Google Installer messages, which are displayed from third party advertisers while browsing the web. The total cost of all services is $120, which is significantly less costly than other ransomware variants, many of which demand at least 2 Bitcoins.

The image below illustrates the different prices for various services.

It also attempts to clear shadow copies via vssadmin.

SAMAS

This ransomware is distributed via compromised JBOSS servers and usually propagates to every system on a network. The most recently used extension is an ironic “.weareyourfriends”. It usually installs in %System32%, since it is typically runs with administrative rights.

Ransomware Staging Tool

Script kiddies looking to make some money need look no further. This ransomware staging tool is exactly what it sounds like: a utility where you just enter your information, browse the folders you want to encrypt, and wait for the money to roll in! We’ve seen a number of variants similar to the binary below. This is so new that it doesn’t yet have its own name, but all variants have been found on compromised RDP systems.

Statistics

Over the last couple of months, the data we’ve seen underscores how important it is for system admins to secure RDP. Unsecured RDP essentially leaves the front door open for cybercriminals. And since modern criminals can just encrypt your data, instead of having to go through the trouble of stealing it, we shouldn’t make it any easier for them to get what they want.