Vulnerabilities like Log4Shell (CVE-2021-44228) are difficult to contain using traditional mitigation options and they can be hard to patch. It can be hard to identify where Log4j is being used in your organization and many Java applications rely on this logging utility.
According to some experts, it could take years for organizations and cloud providers to patch their applications to close this hole. Oracle, for example, is still patching some of its applications from different Log4j vulnerabilities discovered many years ago.
Often, detecting post-exploitation activity can be easier than trying to detect or prevent a specific attack scenario such as a vulnerability or misconfiguration. Read on to find out why post-exploitation detection is your best option for dealing with vulnerabilities like Apache Log4j.
Traditional Detection Methods Don’t Always Work
Log-based Detection
During the pandemic, the rise in cybersecurity threats showed rule-based security systems could not keep up with the increasing number of techniques. In log-based detection, rules are matched against collected logs to determine if there is anomalous or malicious activity occurring. New techniques and Living off the Land methods can often bypass these rules or blend in with noise. Attackers can often stay ahead and obfuscate strings, thus making rules creation to detect and block these attacks a cat and mouse game. With Log4Shell, we have already seen obfuscation techniques to bypass rules being used in the wild by threat actors.
Network-based Detection
Network-based intrusion detection systems (NIDS) provide visibility by monitoring traffic for suspicious and malicious activity. It is possible to monitor the outbound traffic from the vulnerable Java application but since the malicious server could be on any remote system or port, it can be hard to determine the difference between malicious and legitimate outbound traffic. Depending on the application, it could have many legitimate outbound connections that could look suspicious and generate a lot of false positive alerts that will overwhelm SOC analysts during triage.
Vulnerability Detection
Vulnerability detection systems may make it challenging to look for a specific dependency. Java packages are not usually tracked by the OS package manager, therefore, there may not be a record of a vulnerable version of Log4j being used. Java applications can be packaged up into files such as JAR, or WAR for web applications, with all dependencies included. These packages could sit anywhere on the filesystem. Therefore, vulnerability scanners might find it hard to detect vulnerable versions of Log4j. You cannot patch what you don’t know about.
Post-exploitation Detection is your Best Bet
The methods above require some prior knowledge of the vulnerability or attack in order to make rules or to detect vulnerable versions. Since this was a Zero-day, there were no prior rules or vulnerability information available. That also means there is a chance that you’ve already been exploited. The only way to protect against Log4j before defenses for other detection methods can be added, is by detecting post-exploitation activity or code on the server.
What is post-exploitation detection and why is it important?
Post-exploitation is any action taken after a session (or shell) from a successful exploit was opened. Post-exploitation detection is based on actions on objectives after successful exploitation has occurred, such as malicious behaviour or indicators.
This is important because there are always new vulnerabilities and techniques that are able to bypass the first layer of defenses. Zero-day exploits are discovered all the time. Employees often misconfigure applications that are hosted on cloud resources. It is important to have a safety net in the form of layered defenses that is able to act whenever the perimeter defenses fail.
With post-exploitation detection, you are able to understand the motive of the attacker and how they operate, including how they entered the system and what they did once inside, such as executing a cryptominer, in order to effectively mitigate the breach. This forms a core part of a Defense-in-Depth strategy.
Detect if your Machine is Already Compromised
You can’t always guarantee that you’re up-to-date with the latest patches or that you’re fully protected against all vulnerabilities or misconfigurations out there. Taking an assume breach mentality and checking for post-exploitation activity can provide you with evidence where other methods fall short.
Several tools are available to conduct post-exploitation detection, some open-source and some paid. Here is a helpful YouTube tutorial on detecting Log4Shell vulnerability with Intezer Protect. Using a free tool like Intezer Protect can help you check if your Linux servers are compromised by detecting post-exploitation activity and malicious code.
Just as detection is important, so is response. Patching alone doesn’t remove the existing compromise. Some organizations have already seen indicators of cyberciminals exploiting Apache Log4j in ways that could lead to ransomware attacks. Intezer Protect comes with built-in features to automatically detect and terminate ransomware and other destructive attacks immediately.
Steps for Successful Log4j Mitigation
1. Set “log4j2.formatMsgNoLookups” config to “true” https://therecord.media/log4j-zero-day-gets-security-fix-just-as-scans-for-vulnerable-systems-ramp-up/
2. Scan your Linux servers for traces of post-exploitation activity or code. You can do this for free on up to 10 hosts using protect.intezer.com
The post Log4Shell (Log4j RCE): Detecting Post-Exploitation Evidence is Best Chance for Mitigation appeared first on Intezer.
Article Link: Log4Shell Detecting Post-Exploitation Evidence Best Chance for Mitigation