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.

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.

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.

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.

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.

Many of you are probably familiar with VirusTotal, a service that allows you to scan a file or URL using multiple antivirus and URL scanners. VirusTotal results are often used in write-ups about new malware to show how widely a sample is detected by the AV community. We receive links to VirusTotal results via our support system and on the Webroot Community. Computer support forums will also suggest a user submit a file to VirusTotal in order to determine whether or not a file is malicious. VirusTotal can be a very useful service – if you know how the service works and how to interpret the results. A good place to start is the About page, paying special attention to the Important notes and remarks section of the page.

I’ve written before about how inconsistent the results for a file can be, and this makes a bit more sense when you understand more about how VirusTotal works. To put it simply, because of the way that VirusTotal works, files that show no detections in VirusTotal may actually be detected by the scanners used in real-world situations, and the opposite is also true. (Knowing how it works can also help understand why a next-generation cloud-based solution like Webroot SecureAnywhere is not one of the scanners used in VirusTotal.) I’ve seen many instances where a write-up on new malware shows few detections in VirusTotal, but a quick check of our database shows that we had seen and were detecting the sample prior to the date it was submitted. There have also been countless times where our own Webroot SecureAnywhere process showed as being detected by multiple scanners in VirusTotal.

As VirusTotal clearly states, “the service was not designed as a tool to perform antivirus comparative analyses” yet we see it used to gauge how widely detected a new malware sample is all the time. When looking at VirusTotal results, I tend to make two assumptions. The first is that I always assume that all of the scanners are set to their highest heuristic settings – what I like to refer to as “tin-foil hat heuristics” – which will cause a much higher number of False Positives.

The second assumption is that the scanners will be using their full Enterprise signature set which will detect various legitimate programs that administrators might not want on their networks such as administrative tools or remote access tools. Over time, you can become familiar with some of the more common detections and naming conventions used by the various scanners that can help make a more informed interpretation of the results.

As with any tool, knowing the intended use and limitations helps use it more effectively.

Bring Threat Intelligence to the world of IoT

Threat Intelligence has become common throughout the cyber security landscape used in traditional information technology platforms from next generation firewalls, application load balancers, SIEM and other threat monitoring and prevention tools. With the pervasive growth of IoT initiatives and concerns around how to protect operational infrastructures from malicious actors an understanding of how existing threat intelligence can play a role in protecting an organization’s technology infrastructure is needed. Additionally, the existing methods for collecting and analyzing threat data do not directly translate to meet all of the potential security issues found in the IoT space. Therefore, a deep dive into what existing security technology can and cannot do for an organization’s operational infrastructure will help determine what can be done today and what technologies need to be developed to better secure entire ecosystems.

This five-part blog will walk through each aspect of threat intelligence from a general overview to help provide a basic understanding to the future of threat intelligence as it relates to IoT. Part 1 will give a high-level overview of what threat intelligence is, how it is gathered, analyzed and consumed. Parts 2 and 3 will focus on IP and URL data, how it can be applied to IoT and an example of implementing this data in an IoT Gateway. The last two articles will discuss what the future holds in store for protecting devices and creating purpose-built protection for the IoT.

Threat Intelligence: An Overview

Traditional Threat Intelligence consists of the collection and analysis of four main data types: IP Addresses, URLs, Files and Mobile Applications. The focus of this data collection and analysis revolves around protecting workstations and servers from becoming infected with malicious software, preventing command and control servers from activating dormant code living in an organization’s network and helping to identify and prevent the exfiltration of data. This was initially done through the use of human analysts who spent time manually identifying and evaluating threats but has now evolved to a more automated process through the use of machine learning and big data analytics.

As stated above, threats in the cyber security space can be broken down into four main components. Of course, there are other vectors a malicious actor can use to attack an organization but the elements below comprise the bulk of threats a typical organization will regularly face:

• IP Addresses: IPv4 and IPv6 addresses that are typically analyzed for threats inbound to an organization. Typical attacks include spam sources, command and control servers, and botnet servers.
• URL: Not often thought of as a threat category as many organizations consider URLs as policy control but they are heavily used as dynamic embedded delivery endpoints for phishing and malware. It should also be noted that URLs can contain IP addresses.
• Files: Traditional malicious files, think viruses, used to encrypt user data, listen to user activity, destroy systems and/or exfiltrate data.
• Mobile Applications: These have been identified separately from traditional files as they require special analysis due to their specific platforms and the functionality they provide in terms of network connectivity and application performance.

There are three main steps to any threat intelligence system:

• Data Collection and Aggregation: There are three main ways to gather data in the wild for analysis.
• Active: This includes web crawlers and IP port scanning techniques. Since it can be controlled this method provides a robust amount of data but does not typically result in identifying the high-value zero-day threats.
• Passive: By deploying victim machines, web app honeypots, endpoint agents and other exploitable devices on the Internet it is possible to attracted attackers and record malicious activity as it occurs. This technique results in a better set of threat data but requires patients while waiting for a malicious actor to attempt to take advantage of weakened system.
• 3^Rd Party Data: There are several international, governmental and independent bodies that collect threat data for use by security teams. This data, though valuable, must be vetted for accuracy and often times because outdated quickly as threat actors subscribe to the same data sets and change or avoid the items published in these lists.
• Classification: Once data has been gathered and aggregated it can be fed into purpose-built machine learning engines for analysis. This involves the creation and training of engines for each of the data types identified above. Analysts move from doing deep dive identification of threats to maintaining and tuning the engines for better accuracy. This is done by continually feeding the engines more highly refined data for the engine type.
• Analysis and Consumption: Once the data has been collected and classified it is a simple Big Data issue of provided tools such as APIs or SDK to access each of the individual data types.

A relatively new component to the threat intelligence space is the generation of contextualized data made possible through advancements in big data analytics. Contextualization involves walking through disparate data sources looking for linkages between the data in an effort to help prevent future threats before they occur or allow an analyst to better understand the effect of an identified threat may have on an organization.

Typical applications of threat intelligence range from policy management in next generation firewalls to network traffic analysis in security operation centers. Depending on the type of threat data an organization uses and their ability to apply that data to their infrastructure will directly correlate with how well they can detect, identify and resolve threats.

Next week Part Two of this series will explore what traditional URL and IP data can and cannot do for the IoT.

As a concept, the IoT (Internet of Things) has been with us since the late 1990’s, and has evolved from simple M2M (Machine-to-Machine) connectivity into a vision for Operational Productivity enabled by Interoperability.  Innovation and investment in new IoT technology and business models are driven by the pursuit of key operational benefits such as:

• Provisioning Assets as Services
• Efficiency through Automation
• Resource Utilization
• Environmental Impact
• Safer and more productive Critical infrastructure

Next-generation IoT devices and platforms are now being deployed in critical infrastructures such as Integrated Transportation (auto, railway, airports,…), oil & gas operations, industrial & manufacturing facilities, energy distribution, and ‘SmartCity’ systems.  Operations are becoming dependent on these efficient and high-availability IP-aware systems.

New systems are being deployed and older non-IP based systems are being modernized with IP-aware functions at a rapid rate. Supporting this movement has driven device manufacturers to deploy new classes of devices and systems that can take advantage of direct and indirect internet connectivity in order to leverage public and private IoT Cloud Services Platforms.  Theses next-generation smart systems can perform many advanced functions such as data aggregation and storage, advanced analytics, prediction, prognostication, and even limited decision-making.   What was considered advanced data processing and decision- making in a data center just two years ago is now being deployed regularly in stand-alone IP-connected devices at the internet edge.   This along with rapid developments in semiconductor and control technology is paving the way for a new wave of robotics and autonomous systems where cloud processes like machine learning are being brought down to the edge (FOG computing).

In order to deliver the vision of IoT business models, the lines between traditional enterprise IT systems (IT) and the high-availability autonomous operational infrastructures are undergoing radical evolution with new standards and vendors.  As with many new waves of technology advancement, there are those who seek to leverage weaknesses for criminal exploit, state-sponsored espionage, or simply mischief on a grand scale.  These new systems are very enticing to those who specialize in advanced exploits.  Increasingly, malicious actors who have targeted personal computing with malware, viruses and phishing exploits, are now targeting critical infrastructure elements for profit and other motives.  Modern cyber attacks on critical infrastructure take advantage of compromised IP addresses (servers, websites, etc.) to carry out DDoS, botnet and other forms of remote command and control exploits.

Webroot deployed the cyber-security industry’s first, most advanced, and most effective real-time cloud-based Threat Intelligence.  We have been providing this service exclusively to leading Security Appliance, NGFW, and Access Point OEMs for over 5 years.  These OEMs are leaders in bringing the latest cyber security approaches to corporate and public IT enterprises.  This same technology, which has armed advanced networking equipment providers with a real-time defense against Internet launched attacks, is now made available to non-telecom equipment developers for cyber protection to support the growing new classes of IoT systems, such as connected automobiles, industrial automation, process control, aviation, railway, power management, and home energy management.

As system designers look to protect new and existing IoT devices and networks, they are increasingly applying techniques formerly used by the most advanced firewall and network security appliance manufacturers.   IoT gateways are emerging as this new class of OEM appliance. They are being designed to locally integrate single and multi-vendor platforms.  Common functions are real-time data stream analytics, protocol translations, networking control, endpoint control, storage, and manageability.  However, until recently, IoT gateways were being built without sufficient security or intelligence to properly protect critical infrastructure.  What is new and very exciting now is that non-security appliance vendors are now able to bring advanced cyber-security into IoT Gateways and offer Cyber-Security-as-a-Service to critical infrastructure. IoT Gateways can now utilize cloud-based cyber-security to securely connect legacy and next-generation devices to the Internet of Things.

I am pleased and excited to be part of the efforts by Webroot and our partners to ensure that the latest techniques are leveraged across these new IoT devices, appliances, systems and platforms.  We look forward to our continued dialogue with you in advancing collective threat intelligence.