Log4Shell, a comprehensive approach

First, what is the Log4Shell vulnerability? Log4j is a common Java-based tool for sending text to be stored in log files or databases. As a part of multiple Apache frameworks, it’s used by websites and applications globally. The vulnerability is triggered by sending a specific JNDI (Java Naming and Directory Interface) string to the Log4j software. A correctly formatted text string, if the input is not sanitised, will be executed as code, instructing the Log4j instance to download a malicious Java class from an attacker-controlled LDAP server. The malicious Java class is deserialised and installed.

One of the catches with the Log4Shell vulnerability is that the vulnerability doesn’t have to be on a perimeter device for an external attacker to interact with it, which broadens the exposure. If a webserver that an external party can reach is sent the JNDI string, that webserver can pass that string to an internal Log4j instance. That internal Log4j instance will then pass a request back out to the attacker-controlled LDAP server, resulting in exploitation.

Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through to 2.15.0 are vulnerable to CVE-2021–44228. From log4j 2.15.0, the behaviour that does not sanitise inputs has been disabled by default. This could be turned on mistakenly at a later date though. From version 2.16.0, this functionality has been completely removed.

Now we have a basic understanding of the vulnerability, what does the focus on patching potentially miss? Perhaps you’re in an industry where you can’t take servers and systems down for regular patching easily. Your systems might be providing key resources to people and have uptime requirements, like utilities. You may also not be able to turn your network off as you’re not sure what elements will come back on. Many organisations run on networks that are older and frailer than they’d care to admit.

But the most common reason for leaving elements of a systems unpatched is simply because the organisation didn’t know that element was even there. Does your organisation have a perfect, thorough and constantly up to date configuration management database (CMDB)? Even if you answered yes, the correct answer is likely no.

The level of attention the Log4Shell vulnerabilities are getting can also lead to tunnel vision. Patching is important, but it’s not the start and end of your security to do list. You may miss some vulnerable servers, or attackers may come in another way. At the end of the day that’s what you’re concerned about, having an attacker in your environment. Log4j might lead to that, but being phished could just as easily land an attacker in your network.

Alongside working through patching difficulties, you need to take a defence in depth approach. Assume the attacker has already gotten in and be on the look out for post exploitation behaviour while also deploying controls (or auditing existing controls) to mitigate or prevent this behaviour. To do this, you need to know what an attacker is likely to do once they have access. To take a further step back, you need to know who your attackers are likely to be to know what they may do.

As an example of figuring out who your threats are, a threat model for the New Zealand financial sector was built based off the methodology defined in SANS MGT551 Building and Leading Security Operations Centres. The below threat modelling exercise was conducted at the beginning of 2021 and considers information about attackers up to the middle of 2021. Threat modelling should be regularly conducted to incorporate new information.

To start with, three questions were considered:

• Who targets New Zealand specifically, or is indiscriminate and may target New Zealand through the normal course of their operations?
• Who targets the financial sector?
• Who is active?

Using open-source intelligence techniques, seventy-three threat actors were identified that had either targeted New Zealand previously, were indiscriminate in their targeting, or specifically targeted the financial sector. This was a point in time assessment, which will always be evolving.

Of those seventy-three threat actors, the number was then reduced. If the group had ever specifically targeted New Zealand, the threat actor was left in the final model. This is because these are the actors that know the New Zealand landscape well and have demonstrated motivation. If they don’t show recent activity, they were shifted to a lower tier of the threat model.

If the group targeted the financial sector but showed that they consistently stuck to only a single geography, they were removed from the threat model. An example being groups that appear to only speak Portuguese solely targeting Brazil and Portugal. Those that didn’t demonstrate such restrictions remained.

Of the remaining groups yet to be ruled in or out, if they were not active in recent years they were excluded. Of the starting seventy-three threat actors, twenty-three remained. They were broken into two categories, a higher threat and lower threat category. The threat actors currently deemed most relevant to the New Zealand financial sector are:

• UNC2546, UNC2582, FIN11 — Attributed to the RBNZ/Accellion breach
• REvil, Mummy Spider, Wizard Spider, Indrik Spider, Doppel Spider — Active and indiscriminate financially motivated groups
• Lazarus Group and all subsets — Widespread financial targeting
• Deathstalker — Active and indiscriminate mercenary group
• APT41 — Widespread financial targeting
• Sandworm — Indiscriminate damage

For these groups, the most common TTPs have been defined as:

T1486 — Data Encrypted for Impact. There is a current prevalence of ransomware amongst both financially motivated groups to raise funds, politically motivated groups to cause damage, and the blurring between these two actor groups.

T1105 — Ingress Tool Transfer. Most cited instances were ransomware crews deploying tools as they attempt to move laterally in an environment, locate domain controllers and backups before pushing the ransomware across the environment.

T1059.001 — PowerShell. Most threat actors need access to a command and scripting interpreter once they are in the environment, PowerShell being the most used.

T1027 — Obfuscated Files or Information. Most tools used by threat actors will use different methods to obfuscate the tool’s code to impede reverse engineering, and to obfuscate indicators to avoid detection.

T1083 — File and Directory Discovery. All threat actors need to move laterally in an environment and need to discover where they can move to. Politically motivated threat actors will often look for information to exfiltrate based on file types, and ransomware groups will use similar tactics, with the ransomware itself looking for specific file types to encrypt.

Given this, next we will discuss the controls to go along with patching CVE-2021–44228.

Mitigation:

• Data Backup

Detections:

• Use process monitoring to monitor the execution and command line parameters of binaries involved in data destruction activity, such as vssadmin, wbadmin, and bcdedit. Monitor for the creation of suspicious files as well as unusual file modification activity. In particular, look for large quantities of file modifications in user directories.
• In some cases, monitoring for unusual kernel driver installation activity can aid in detection.
• In cloud environments, monitor for events that indicate storage objects have been anomalously replaced by copies.

Mitigation:

• Network Intrusion Prevention

Detections:

• Monitor for file creation and files transferred into the network. Unusual processes with external network connections creating files on-system may be suspicious. Use of utilities, such as FTP, that does not normally occur may also be suspicious.
• Analyse network data for uncommon data flows (e.g., a client sending significantly more data than it receives from a server). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Analyse packet contents to detect communications that do not follow the expected protocol behaviour for the port that is being used.

Mitigations:

• Antivirus/Antimalware
• Code Signing
• Disable or Remove Feature or Program
• Privileged Account Management

Detections:

• If proper execution policy is set, adversaries will likely be able to define their own execution policy if they obtain administrator or system access, either through the Registry or at the command line. This change in policy on a system may be a way to detect malicious use of PowerShell. If PowerShell is not used in an environment, then simply looking for PowerShell execution may detect malicious activity.
• Monitor for loading and/or execution of artifacts associated with PowerShell specific assemblies, such as System.Management.Automation.dll (especially to unusual process names/locations).
• It is also beneficial to turn on PowerShell logging to gain increased fidelity in what occurs during execution (which is applied to .NET invocations). PowerShell 5.0 introduced enhanced logging capabilities, and some of those features have since been added to PowerShell 4.0. Earlier versions of PowerShell do not have many logging features. An organization can gather PowerShell execution details in a data analytic platform to supplement it with other data.

Mitigation:

• Antivirus/Antimalware

Detections:

• Detection of file obfuscation is difficult unless artifacts are left behind by the obfuscation process that are uniquely detectable with a signature. If detection of the obfuscation itself is not possible, it may be possible to detect the malicious activity that caused the obfuscated file (for example, the method that was used to write, read, or modify the file on the file system).
• Flag and analyse commands containing indicators of obfuscation and known suspicious syntax such as uninterpreted escape characters like ‘’’^’’’ and ‘’’”’’’. Windows’ Sysmon and Event ID 4688 displays command-line arguments for processes. De-obfuscation tools can be used to detect these indicators in files/payloads.
• Obfuscation used in payloads for Initial Access can be detected at the network. Use network intrusion detection systems and email gateway filtering to identify compressed and encrypted attachments and scripts. Some email attachment detonation systems can open compressed and encrypted attachments. Payloads delivered over an encrypted connection from a website require encrypted network traffic inspection.
• The first detection of a malicious tool may trigger an anti-virus or other security tool alert. Similar events may also occur at the boundary through network IDS, email scanning appliance, etc. The initial detection should be treated as an indication of a potentially more invasive intrusion. The alerting system should be thoroughly investigated beyond that initial alert for activity that was not detected. Adversaries may continue with an operation, assuming that individual events like an anti-virus detection will not be investigated or that an analyst will not be able to conclusively link that event to other activity occurring on the network.

Mitigation:

• This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Detections:

• System and network discovery techniques normally occur throughout an operation as an adversary learns the environment. Data and events should not be viewed in isolation, but as part of a chain of behaviour that could lead to other activities, such as Collection and Exfiltration, based on the information obtained.
• Monitor processes and command-line arguments for actions that could be taken to gather system and network information. Remote access tools with built-in features may interact directly with the Windows API to gather information. Information may also be acquired through Windows system management tools such as Windows Management Instrumentation and PowerShell.

For a more thorough breakdown that covers threat actors and their tools, please see the full report or feel free to contact us.