Threat Insights and Trends from the 2016 Threat Brief

by Grayson Milbourne | Feb 26, 2016 | Industry Intel, Threat Lab

Intro from the 2016 Threat Brief:

“2015 was yet another record year for cybercrime, during which more malware, malicious IPs, websites, and mobile apps were discovered than in any previous year. It comes as no surprise that the cybercrime ecosystem continues to thrive, given new innovations and little in the way of risk for those who choose to participate. The continued onslaught of hacks, breaches, and social engineering scams targeting individuals, businesses, and government agencies alike has caused many in the security field to ask if it’s truly possible to defend against a persistent attacker.

…

At Webroot, we believe it is possible to effectively protect enterprises and users, but only by understanding your adversary and the techniques they employ for their attacks.

…

Our approach and security solutions reflect our in-depth understanding of the threat landscape and how attackers think, to provide cutting-edge, proven next-generation protection and real-time detection of threats as they emerge. The Webroot 2016 Threat Brief provides a glimpse into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks seen by our users over the past year.”

The brief in its entirety can be found here.

However, in this blog, I want to talk about two sections of the Threat Brief and what I found to be most interesting. The first has to do with new malware discoveries and how often malware ensures it is unique with each new infection. The other has to do with the prevalence and targets of phishing attacks, as well as a tactic to improve your personal online security.

Before I go on, it is first important to talk about the source of this data. With respect to malware and phishing site encounters, these stats are pulled directly from Webroot SecureAnywhere users and their real world encounters with these threats. This is an important distinction as it enables us to calculate how frequently different types of attacks occur and the likeliness that an average user encounters such an attack.

Let’s begin with what was interesting in the malware detection data, mainly the fact that around 97% of the time, malware is unique to the system it infects. That is to say that the specific malicious file is never seen elsewhere. This is intentionally done by malware authors and distributors to make the discovery of their threats more difficult. The technology behind this technique is not new however, and is known as polymorphism. The overwhelming trend is that malware uses polymorphism, either on the server side where the malware is distributed from, or through the malware itself where with each new infection, the samples change. While polymorphic malware has been around for over a decade, it is now the norm for nearly all threats today.

Beyond the polymorphic trend, malware encounter data also showed that Webroot SecureAnywhere users encountered more threats on average than in 2014. The per-user infection rate in 2015 was 1.6 infections per customer, compared to 1.2 in 2014. What this means is that infections are more common and during the course of a year, you will more than likely be exposed to a threat. The good news for Webroot customers is that we’ve protected you from these threats. That said, our users were 25% more likely to encounter threats in 2015 than in 2014.

The last bit I want to talk about with respect to malware, is the speed at which churn between variants occurs. We measure this by counting the number of examples per variant that are discovered, on average, before no new samples show up and a new variant is discovered. In 2015, this number plummeted to 97 examples per variant compared to 2014 where nearly 700 examples were discovered. Ultimately, what this shows is that malware authors and distributors are speeding up their variant release process in their efforts to evade detection. Thankfully, the Webroot model for threat discovery isn’t affected by the speed of new malware development, and instead relies on awareness at each individual endpoint we protect. This ensures that even if the samples per variant drops to one, we are still aware of that individual threat and are able to identify and protect against the infection.

The second threat type I want to talk about is the notorious phishing attack. These are malicious websites that impersonate legitimate websites as they look to steal login credentials and more. The vast majority of phishing URL’s show up in carefully crafted emails that use social engineering techniques to encourage some call to action. A common example is an email claiming your account has been suspended and to log in to restore access.

In 2015, over 4 million phishing URL’s were clicked on by Webroot SecureAnywhere users. The good news is that none of these users had the chance to give away their credentials as SecureAnywhere blocked the URL’s page from loading. The bad news is that that the volume of phishing URL’s has increased considerably over 2014. In 2015, about 50% of WSA users clicked on a phishing URL compared to 30% in 2014. There are a number of factors that are responsible for this increase, but the two main ones are that phishing sites are inexpensive to host and that they are an effective method for collecting credentials. In so long as people can be tricked into clicking on a malicious link, phishing sites aren’t going anywhere.

The other interesting data around phishing site detection surrounds correlating the phishing site to the company or entity that is being impersonated. In the Threat Brief, we break them into two main categories which are financial institutions and technology companies. When looking at all phishing sites discovered in 2015, a little more than 2/3 of sites were targeting a technology company such as Google or Apple. This might sound odd as you might think that breaking into someone’s bank account would be more valuable. However, quite the opposite is true. Google is by far the number one target of phishing attacks because the value of breaking into someone’s primary email account is very high. The reason is that an email account provides information about what other accounts an individual has (including financial accounts), as well as the ability to reset those accounts’ passwords as the password reset option validates through the associated email address.

This brings me to my final point, which is less about phishing and more about email security. The number one tip I recommend to help improve personal online security is to make sure your primary email account password is unique from all other passwords. This ensures that your email is difficult to break into when a password for another site is compromised. This happens all-too-often by no fault of a user, but rather because businesses are often attacked and credential data is compromised. The first thing hackers do with stolen credential data is to see what other accounts can be accessed. If your email password is unique, there is no chance of it being compromised through a collateral attack.

There are many other interesting observations in the full 2016 Threat Brief, and I encourage you to read the full report.

Cyber Threat Actors

by Blog Staff | Feb 23, 2016 | Industry Intel, Threat Lab

Cyber threats come from a wide array of sources, but can be grouped into three categories:

Hacktivists
These are tech-savvy individuals who are normally motivated by morality. These individuals are also classed by many (including the FBI) as terrorists. One of the main hactivist groups out there is anonymous. This group rose from one of the most popular image boards on the internet, 4chan, where users could post anonymously. Many of the influential figures in 4chan have now left, including the board founder moot (Christopher Poole). 4chan is no longer the entity it used to be. One of the most infamous attacks conducted by anonymous was Project Chanology, where the group targeted scientology.  Famously anonymous retrieved a video of Tom Cruise from the scientology group that was not intended to be seen by the general public: https://www.youtube.com/watch?v=UFBZ_uAbxS0

Cyber Criminals
These are individuals who are motivated by money. These are the people who are responsible for the distribution of ransomware. This is a very lucrative business. It was reported in 2013 that cryptolocker made over $30 million in 100 days. Politcal borders make it appealing for criminals to employ these tactics of making money as it is very hard to prosecute them. The encryption that ransomware hits these machines with is normally unbreakable, with the FBI encrouraging individuals to pay the ransom: http://uk.businessinsider.com/fbi-recommends-paying-ransom-for-infected-computer-2015-10?r=US&IR=T .

It has been observed that some ransomware variants have holes and can be cracked (most notably the linux encoder variant which was targeting web servers). Ransomware isn’t the only tactic cyber criminals employ. Another tactic they employ are botnets. This is where a criminal infects your computer, unknowingly to the individual. The criminal can then take control of the victims computer at any time for whatever purpose they see fit. Normally the attacker will either extract information from the victim, monitor the victim or use the victims computer to attack other systems. A recent case to note in relation to botnets is the arrest of one of the administrators of the Dridex botnet, Andrey Ghinkul. This arrest shows that law enforcement are making a good effort to tackle this problem.

State-Sponsored Threat Actors
These are individuals who are sponsored by a government. They act in political interest of the government sponsoring them. It has been reported by FireEye that China has over 20 APT (advanced persistent threat) groups. APT1 (dubbed by Mandiant) is linked with China’s PLA Unit 61398. It is believed this unit occupies a 12 story building employing hundreds of hackers. These groups pose a particular threat to the US, with the FBI putting some of the people involved on their most wanted list: https://www.fbi.gov/news/news_blog/five-chinese-military-hackers-charged-with-cyber-espionage-against-u.s . China isn’t the only country known for sponsoring cyber attacks. The revelations of Edward Snowden reveals much on the NSA’s antics. Another example of a state sponsored cyber attack is where Turkeys internet servers were attacked a couple of months ago, with the blame being pointed at Russia: http://www.todayszaman.com/anasayfa_political-hackers-suspected-as-turkey-suffers-intense-cyber-attack_407781.html

Locky Ransomware

by Nathan Wyman | Feb 22, 2016 | Industry Intel, Threat Lab

A new form of ransomware has hit the scene, and although this one has a playful nickname it is no fun at all. The bad news is that “Locky” ransomware will encrypt virtually every commonly used file-type and targets not only local drives, but any networked drives it can find, even if they are unmapped. The good news is that Locky is easily preventable because it relies on MS Word Macros to download and execute the actual malware. The only way to infect a computer with Locky ransomware is to open the attached document from a spam e-mail and allow the Word Macro script to run. (For a general overview of this type of execution, see our blog post about Microsoft Word & Excel Macros.)

Locky is most commonly distributed through spam e-mails that have similar subjects and messages. The subject is typically something like “ATTN: Invoice J-123456748” and the message is usually “Please see the attached invoice (Microsoft Word Document) and remit payment according to the terms listed at the bottom of the invoice”. If the victim follows the instructions to enable Macros, the script will download the Locky payload from a remote server and execute it.

The Locky executable will be stored and run from the %Temp% folder and it will immediately create and assign a unique 16-character Hexadecimal name to the victim (something like “A8678FDE2634DB5F”) which is then sent to the remote server for tracking and identification purposes. Once the Locky executable has launched and assigned the victim a unique ID, it will immediately begin scanning drives for files to encrypt. Not only will it encrypt local files, but it will search for any remote drives it can find (even unmapped network shares) and will encrypt their files as well.

Locky will use the AES encryption algorithm to encrypt all files with the following extensions:

.mid, .wma, .flv, .mkv, .mov, .avi, .asf, .mpeg, .vob, .mpg, .wmv, .fla, .swf, .wav, .qcow2, .vdi, .vmdk, .vmx, .gpg, .aes, .ARC, .PAQ, .tar.bz2, .tbk, .bak, .tar, .tgz, .rar, .zip, .djv, .djvu, .svg, .bmp, .png, .gif, .raw, .cgm, .jpeg, .jpg, .tif, .tiff, .NEF, .psd, .cmd, .bat, .class, .jar, .java, .asp, .brd, .sch, .dch, .dip, .vbs, .asm, .pas, .cpp, .php, .ldf, .mdf, .ibd, .MYI, .MYD, .frm, .odb, .dbf, .mdb, .sql, .SQLITEDB, .SQLITE3, .asc, .lay6, .lay, .ms11 (Security copy), .sldm, .sldx, .ppsm, .ppsx, .ppam, .docb, .mml, .sxm, .otg, .odg, .uop, .potx, .potm, .pptx, .pptm, .std, .sxd, .pot, .pps, .sti, .sxi, .otp, .odp, .wks, .xltx, .xltm, .xlsx, .xlsm, .xlsb, .slk, .xlw, .xlt, .xlm, .xlc, .dif, .stc, .sxc, .ots, .ods, .hwp, .dotm, .dotx, .docm, .docx, .DOT, .max, .xml, .txt, .CSV, .uot, .RTF, .pdf, .XLS, .PPT, .stw, .sxw, .ott, .odt, .DOC, .pem, .csr, .crt, .key, wallet.dat

However, Locky will not encrypt any files where the full Pathname and Filename contain one of the following strings:

tmp, winnt, Application Data, AppData, Program Files (x86), Program Files, temp, thumbs.db, $Recycle.Bin, System Volume Information, Boot, Windows

Like the CryptoWall ransomware that has been seen in the past year, Locky also changes the names of the encrypted files in order to make it more difficult for victims to restore the correct data. Locky uses the naming format of “[unique_id][identifier].locky” for encrypted files. For example, if Locky assigns the victim a unique name of “A8678FDE2634DB5F” and it encrypts a file like “example.doc”, the file may be renamed something like “A8678FDE2634DB5F0123456789ABCDEF.locky” . In addition to obscuring the original file names, Locky takes the extra step of deleting all Shadow Volume copies on the machine in order to prevent the victim from simply rolling back or restoring their files.

Since the main purpose of Locky is to coerce the victim into paying a ransom to retrieve/decrypt their data, Locky helpfully places recovery instructions in several places on the victim’s drive. Text files named “_Locky_recover_instructions.txt” will be dropped in every folder where files have been encrypted, and the Windows Wallpaper will be changed to “%UserpProfile%\Desktop\_Locky_recover_instructions.bmp”, which contains the same instructions as the text files.

The instructions that Locky provides contain links to a Tor site called the Locky Decrypter Page. The URL for this site is “6dtxgqam4crv6rr6.onion” , and it walks the the victim through the process of paying the ransom and retrieving their data. Details included: the amount of Bitcoins to send as payment, how to purchase Bitcoins, the Bitcoin address to submit payment, and a link to the Decrypter once payment is made.

Text Instructions

Desktop Background Instructions

Locky will also store various information in the Windows Registry under these keys:

HKCU\Software\Locky\id – Unique ID assigned to the victim

HKCU\Software\Locky\pubkey – RSA Public Key

HKCU\Software\Locky\paytext – Ransom Note Text

HKCU\Software\Locky\completed – Whether or not the ransomware finished encrypting all available files

HKCU\Control Panel\Desktop\Wallpaper (“%UserProfile%\Desktop\_Locky_recover_instructions.bmp”)

Because the Locky ransomware can encrypt all network drives, it is critically important to lock down the permissions on any available network shares. As always, it is also important to perform regularly scheduled backups of all important data, and to have the backup drive stored off-network when not in use. At this time, there is no known way to decrypt files encrypted by Locky (unless ransom is paid), and its deletion of the Shadow Volume copies makes this even harder to circumvent. It has been reported that Locky victims have been successful in retrieving their data after payment is made, but it is never advisable to pay cyber-criminals their requested ransom. With due diligence and good security habits, everyone should be able to avoid being infected by Locky.

Building a secure IoT Gateway using Threat Intelligence

by David Dufour | Feb 18, 2016 | Industry Intel, Threat Lab

Part 1 and Part 2 of this series provided an overview of Threat Intelligence and hopefully offered some understanding as to what role it can play in helping secure an IoT infrastructure. For those familiar with cybersecurity and how to implement Threat Intelligence in traditional network appliances, the jump to securing an IoT Gateway is fairly straightforward. For those new to the space, trying to put a plan together for integrating Threat Intelligence may seem a bit daunting. This blog is intended to be a guide of questions to start the process.

The first question that should be addressed when building an IoT Gateway is, “What is your audience?” For example, if the given environment in which the gateway will be implemented is closed, meaning no interconnectivity with the Internet, then traditional IP reputation or URL Categorization won’t provide much help. These technologies are built around the expectation that a malicious actor will attack from, or ex-filtrate data to, locations on the Internet. Therefore, with no connection to the Internet these technologies provide little in the way of additional security to an appliance manufacturer. That being said, by definition an IoT Gateway should provide connectivity to the Internet, so the rest of this blog will assume that is the case.

So, what is needed to build an IoT Gateway?

Obviously, there is the interconnectivity that bridges a proprietary physical layer and converts it to TCP/IP traffic. This blog won’t help much with that aspect of the appliance as the respective vendors would know best how to achieve this part of the solution. However, once data has been converted to Internet compatible protocols, building a basic gateway with IP blocking and URL categorization requires: 1) IP packet inspection to extrapolate incoming IP addresses or outgoing URLs, 2) a Threat Intelligence module that allows for the scoring of an IP or URL, and 3) a user interface to manage the policies. Here is a breakdown of each component:

• Deep Packet Inspection (DPI): Simply put, this is examining each data packet as it comes through the appliance, stripping out header information that contains the IP address for inbound traffic or the outbound URL. There are robust open source solutions such as nDPI from ntop that do a very good job analyzing traffic, but partnering with a provider such as Qosmos might be the right approach for those new to security. The problem isn’t in the ability to inspect packets but rather the ability to do it at line speeds. Those who aren’t experts or who are looking to go to market quickly would do well to find a partner in this space.

• Threat Intelligence Module: There are several considerations in terms on selecting a provider, how best to implement a solution and how to implement Threat Intelligence in such a way that it becomes a differentiator rather than an “also have”. Take the time to become educated on cost to performance aspects a Threat Intelligence provider offers and understand the ramifications of the level of false positives and uncategorized lookups that a solution will have on the overall implementation of the final product.

• Policy Management: Nearly as important as the Threat Intelligence itself is the ability for appliance administrators to configure and manage policies. Will there be a need to manage based on region, user, device type or some other granular method specific to an industry? Can the individual device management be done through a cloud-based interface allowing for quicker deployment and lower appliance resource requirements or will it need to be built into the operating system for a given appliance to be managed locally? Taking the time to ask these and other questions around the user interface is key to building a successful solution.

The intent of this post is to identify key considerations that must be addressed to successfully build a secure IoT Gateway. It is a complicated process with issues not limited to traffic management, threat identification at line speeds and the potential for complex policy and usage configurations. As daunting as this may appear, traditional appliance manufacturers have been addressing this need for Information Technology ecosystem for many years and bringing that technology to the Operational landscape is fairly straightforward. Part 4 of this series will push the edge of what is possible by walking through some theoretical configurations that bring Threat Intelligence down from the network appliance to the actual edge device.

New Ransomware PadCrypt: The first with Live Chat Support

by Tyler Moffitt | Feb 18, 2016 | Industry Intel, Threat Lab

A new ransomware has been discovered and what sets apart this variant from the rest is its implementation of a chat interface embedded into the product.

That link for “Live Chat” will prompt the window for live support. The window should look like this and will allow you to talk directly with the cyber criminal.

Currently the Command and Control servers are down so currently there is no encryption being performed and we were unable to chat with any “developer” to see what they would say. However, we presume it’s just to aid in the process of getting a bitcoin wallet address, filling it with coins, and sending the payment securely. This task can be complicated to unsavvy users so we suspect this feature was created to add a more human element to the aid of receiving the ransom.

These are the standard instructions that also are available if you click “decrypt help” and can be a daunting task for those not familiar with the process. This is why we suspect the chat feature was added. Also, for the first time that we’ve seen on any ransomware sample – it comes with a uninstaller. Located in %AppData%\PadCrypt\unistl.exe it will remove all files and registry entries associated with the infection. However, it will still leave all your files encrypted.

The rest of the drill with this ransomware is pretty standard – “.pdf.scr” extension on the encrypted files, Volume Shadow service is deleted, decryptor tool is provided to decrypt your files after paying ransom.

PadCrypt infection samples: From ZeroBin
MD5 8616f6c19a3cbf4059719c993f08b526 (C2: cloudnet.online)
MD5 aface93f4d6a193c612ea747eaa61eaa (C2: annaflowersweb.com)
Dropped files:
17822a81505e56b8b695b537a42a7583 (package.pdcr)
7d2822aedddd634900a4c009ef0791a9 (unistl.pdcr)

Webroot will catch this specific variant in real time before any encryption takes place. We’re always on the lookout for more, but just in case of new zero day variants, remember that with encrypting ransomware the best protection is going to be a good backup solution. This can be either through the cloud or offline external storage. Keeping it up to date is key so as not to lose productivity. Webroot has backup features built into our consumer product that allow you to have directories constantly synced to the cloud. If you were to get infected by a zero-day variant of encrypting ransomware you can just restore your files back as we save a snapshot history for each of your files up to ten previous copies. Please see our community post on best practices for securing your environment against encrypting ransomware.

Why Webroot is Proven Next-Generation Endpoint Security

by Mike Malloy | Feb 17, 2016 | Industry Intel, Threat Lab

Within the last several years, online threats have continued to evolve at disturbingly high rates, and are more robust than ever before. According to the data we’ve seen across the Webroot Threat Intelligence Platform, many new attacks are targeted, adaptive (polymorphic) malware variants that appear suddenly in several points across a targeted company’s network and then may never be seen in the same way again. When so many threats are tailor-made and can even be purchased as a service in the criminal networks, traditional, reactive cybersecurity just won’t cut it.

At Webroot, we know the only way to protect businesses and individuals is by understanding our adversary and predicting their next move. That’s why we’ve continued to expand our threat intelligence and integrate it more deeply with our endpoint protection solutions so that new, unknown threats are detected and destroyed as soon as they appear within the networks of any of our customers. This unique, collective protection means that all Webroot customers protect one another. It’s a community of cybersecurity. Our cloud-based threat intelligence is derived from millions of sensors and real-world endpoints around the world to provide proven next-generation endpoint security that can predict, prevent, detect, and respond to threats in real time. With 87,000 business customers (and counting) and partnerships with 40 of the industry’s top security vendors, Webroot is the proven choice for defending against modern malware. If you would like to learn more about out Threat Intelligence Platform, see our website.

In view of the tactics modern malware writers and other cybercriminals have adopted, we invite you to join us at the 2016 RSA conference to find out how our next-generation endpoint security solutions protect businesses and individuals in a connected world. To schedule a meeting with us at RSAC, visit www.webroot.com.

What IP/URL Based Threat Intelligence Can and Can’t do for the IoT

by David Dufour | Feb 11, 2016 | Industry Intel, Threat Lab

Part one of this series provided a high-level overview of Threat Intelligence, the underlying data types common in the current security landscape and how these data are gathered, analyzed and consumed. As cyber security becomes a key focus for the IoT it may appear, on the surface, much of the existing threat intelligence and the techniques used to gather these data do not directly play a role in protecting IoT devices from malicious actors. Though there are gaps in some areas, specifically with malicious files for IoT devices and closed network threat analysis, much of the threat data can be applied to the IoT once communication with, and across, the Internet occurs.

Many consumer and industrial IoT devices do use custom protocols to communicate with one another in a closed environment which presents a challenge for existing systems to gather and collate data specific to these environments. Fortunately, by definition, devices in the IoT must communication through the Internet requiring proprietary or non-TCP/IP traffic to be converted to TCP/IP. It is at this conversion point existing threat intelligence can play a critical role in protecting IoT devices through the use of traditional malicious IP blocking and traffic management to and from malicious or off category URLs. Some specific cases for the use of these data that directly affect how IoT Gateways can be secured are:

Malicious IP Blocking: One of the most basic ways to protect IoT devices is to prevent known malicious IP addresses from communicating from the Internet to devices inside of a network. If an OT network contains devices that are directly manageable over the Internet and whitelisting is not a viable option due to dynamic addressing, then a very straightforward and extremely successful solution in IT ecosystems, is to block known malicious IP addresses.

URL Categorization and Reputation: Another common, and extremely effective, security measure that is used throughout the IT landscape in perimeter appliances is to limit what a device can communicate with. Through the use of policy and security management filters devices can, at the gateway, be denied the ability to communicate with malicious IP addresses and URLs, preventing the exfiltration of data to unknown or unauthorized entities.

The aforementioned use of IP addresses and URLs in IoT Gateways to help prevent threats from entering an ecosystem does have limitations in terms of detecting threats in closed environments. Today, threat intelligence providers have focused on identifying threats on the Internet at large due to the vast amounts of data available for analysis. Machine learning engines have been a boon for the cyber security industry in their ability to be finely tuned to detect and identify Internet-borne threats but they require vast amounts of data to accurately identify a threat and reduce false positive results. Closed ecosystems, even TCP/IP-based networks, do not have the volume of data the current state of machine learning requires to accurately and definitively detect threats unique to these environments. Building tools and applying new methodologies to these smaller datasets associated with closed ecosystems will be the challenge security architects must overcome as more and more devices make their way into the IoT.

Part three of this series will continue with the discussion around threat intelligence and how to apply it to IoT Gateways to protect OT ecosystems. It will give an overview of a basic gateway, the submodules required to extract necessary data from a data stream for analysis, how to analyze the resulting data and the process for applying policy to the overall environment. The hope will be to keep the discussion moving forward on how existing technology can help protect the IoT.