Over the past few months, ransomware targeting healthcare organizations has been on the rise. While ransomware is nothing new, targeting healthcare organizations, at the extreme, can impact an organization’s ability to engage in anything from routine office visits to life-or-death diagnoses, treatments, and patient care.
With the recent increase in ransomware being leveraged to target healthcare organizations, the hospitality/gaming/entertainment industry, etc. (as well as other industries, both domestic and international), we often get questions about Corelight’s ability to detect and identify the spread of ransomware via network traffic analysis and protocol logging. The main question being, once ransomware is identified, how can an organization quickly and effectively respond to ransomware?
One of the many advantages to being a Corelight customer is the team of experts on our support and our roots with the open-source community. The power of the open-source community ranges from Zeek® content/script writers to Suricata® IDS signature writers and ruleset maintainers, and technical documentation specialists, trainers, and instructors, and others seeking to contribute to detection, defense and protection.
With ransomware, there’s a saying in the malware community; malware can attempt to hide, but malware has to run. On the contrary, with ransomware, there is no tactical reason to hide because the goal of threat actors that engage in the use of ransomware is similar to other forms of digital extortion—to get paid!
In phases ranging from initial compromise to setting up “crypto configuration and operations” to blasting through data on endpoints, and in many cases, exfiltrating data from a victim’s internal network, network visibility is critical. Corelight provides this critical network visibility via four primary resources:
Specifically, every connection involved with a ransomware incident will get entries in our conn.log. At the same time, there will be a spike or surge in DNS activity as various forms of symmetric encryption, and constant traffic to both C2 and data exfil receivers will require the engagement of DNS queries and answers which will be in the dns.log. Referencing symmetric encryption, there are 3 pivotal logs - the SSL, X509 and Files logs. Each of those logs will experience a surge in activity as the ransomware blasts through endpoints and laterally moves to other hosts.
Lateral movement is often logged in various network communication logs such as the smb_files, smb_mapping and smb_command logs. SMB is typically considered the carrier protocol or messenger mechanism, which means there will be ransomware indicators found in DCE_RPC, RDP or VPN logs.
Our team of experts have dedicated more than a decade of research, intensive lab development and collective knowledge directly to the production and deployment of Corelight’s Encrypted Traffic, Command and Control, and Entity Collections.
That brings us to a few critical questions:
How will my SOC team know when ransomware is in flight?
Detections and findings from most Zeek scripts appear in the notice.log. In the case of Corelight’s enhanced detection packages and collections, there are also focused logs that apply to the services, protocols, and applications leveraged by various ransomware families.
Here’s an example. Prior to COVID, we had customers that experienced live ransomware outbreaks which were originally detected through Corelight’s rdp.log. According to statistics provided by the United States Federal Bureau of Investigation (FBI), 70-80 percent of ransomware incidents initially started through compromising weak and poorly protected RDP servers.
Post-COVID, ransomware threat actors have shifted their focus to go after a target-rich environment that was created from the sharp increase in remote workforces using VPNs. Today, many organizations are challenged with detecting and identifying the wide range of VPNs throughout their enterprise. This is why our Labs team recently added the Corelight VPN Insights Package to the Encrypted Traffic Collection. The VPN Insights Package logs to the vpn.log.
A common tactic leveraged by ransomware threat actors is to compromise a VPN through various resources (a popular resource is to engage with an initial access broker). Once inside a network accessed through an initial access broker, many threat actors will deploy the use of a single or multiple VPNs in attempts to evade detection and streamline continued access. While on their VPN connections, threat actors can conduct recon activity such as asset scanning and landscape profiling to identify a high ground point by compromising one or more domain controllers (which are frequently used to infect other domain controllers). Once they are able to gain that level of compromise, it’s easy for them to push out ransomware droppers via domain controller policy or “update patches” that can literally infect entire domains and organizational entities within minutes.
While a third-party integration partner to one of our customers had those exact sequences of events happen, the customer was able to thwart similar activity from the same threat actor by quickly identifying VPN connections inbound to their network from a country that was unaffiliated to any business the customer had.
How does the open-source detection community relate to ransomware detection?
That’s another question that is often asked of our teams. In the case of Zeek, its open-source detection scripts can read into network events and be used to determine when ransomware user-agent strings, or “in flight” movement of file extensions associated with various families and groups, are logged.
In the case of Suricata, its open-source IDS signatures are a product of contributions from various Information Sharing and Collaboration (ISAC) groups. More than 4,700 signatures dedicated to known ransomware groups and families are available through just the ET/Emerging Threats Community Edition and Professional Edition of ProofPoint’s rulesets alone.
What steps do I need to take?
The time to determine the scope of your sensor deployment’s detection capabilities should not be during an incident. The best way to determine how your infrastructure can scope and detect various blast radius’ and perform in a virtual Network Fallout Zone is to “lab it” or “validate it” through security validation simulations and exercises. To do this, I recommend making sure that you have Zeek and Suricata IDS deployed, along with the right scripts and signatures, in a lab environment (on a test/lab network) that is separate from your production networks that have your Corelight sensors deployed.
If you’re a Corelight customer, ensure that you’re leveraging the best of the features within your Corelight sensor. Regardless of whether you’re a customer, be sure to deploy Zeek packages from the open-source community (i.e., Critical Path Security has contributed a Zeek package available that includes over 5,100 ransomware extensions defined for detections).
There are also many other Zeek packages for detections available here: https://zeek.org/packages/
Additionally, there is a package originally leveraging content from https://fsrm.experiant.ca/ on Corelight’s GitHub that can be integrated with sensors through our Fleet Manager.
Need help deploying Zeek and Suricata? Contact us. Already a customer and want guidance on scripts and signatures? Contact your technical account manager (TAM).
Want to read about the prevalence of ransomware within the healthcare & hospitality/gaming/entertainment industry? Check out these articles: