Real-time vs After the Fact: Pitfalls of Log-based Behavioral Threat Detection
It was recently published that Shadow Brokers, the group behind the Equation Group leak, are selling a new set of tools that have the ability to tamper with Windows event logs. What stood out to me is the inefficiency of security solutions that rely solely on logs for detecting threats. Implementing security analytics or a UEBA product that relies on logs for the detection of advanced cyber threats has advantages, but it is also risky.
As traffic is often encrypted, and DPI technologies are far more complex, ingesting logs is easy in log-based UEBA solutions, which means they offer a wide set of data sources as opposed to network/endpoint-based security products that often use fewer data sources but use real-time network activity combined with other critical assets within the organization that can provide deeper context. So, relying solely on logs for threat detection is not a recommended course of action for a few reasons:
Shadow Brokers’ new set of tools is only one example of pen-testing tools that have the ability to either delete logs or even simply stop logs from ever being created. One such tool is Mimikatz, which has the ability to prevent malicious pass-the-hash authentication of reaching logs.
In a recent study published by Kaspersky Labs that discussed recent worldwide attacks on financial organizations, they state the following: “In fact, detection of this attack would be possible in RAM, network, and registry only.”
Let’s hit pause on that statement. Some of the best security researchers in the world looked at logs in a network that had undergone an APT and found no evidence of it in server logs. This is a critical point. The bad guys who perpetrate such APTs are technologically savvy. They use tailormade malware to avoid leaving evidence of an attack on hard-drives and they take great steps to disguise their actions. And in most cases, they have the ability to either stop or purge the evidence of any malicious activity from logs.
Even in the cases where an attacker doesn’t have the ability to manipulate logs, another issue is whether an attack will even be noticeable in a log.
Log design usually faces two major challenges:
First, logs need to be designed to be compact so they will not add a significant burden to system-under-audit. This means that by design, some data isn’t logged anywhere or that enabling all available logs could potentially incur a penalty on a system’s performance, which you definitely don’t want to do with mission-critical servers.
Secondly, during system design, it is often unclear what the system “weak spots” will be that need special auditing. This becomes evident each time a new zero-day vulnerability is published and traditional system logs don’t offer any indicator that is able to spot the attack.
To illustrate this point, let’s look at Active Directory security as an example. Most AD attacks are either very hard or impossible to detect through logs (Table 1). As mentioned before in Avi Kama’s excellent blog post on how to disrupt an attacker on exploiting domain credentials and in Kaspersky Labs report mentioned above, credentials compromised with tools similar to Mimikatz are usually a part of an APT. Having blind spots in this area is very worrying.
Table 1 – Ability to detect different Active Directory attacks in Windows event logs
Real-time Action Versus After the Fact
Security solutions working with raw data (network packets, endpoint protection) have the ability to take action in real-time when a threat is detected. This action could be a quarantine of a file, block of an IP, or issuing a re-authenticate request.
With log-based systems, the reaction is after the fact. At best, there will be a few minutes delay. In the world of cyber incident-response, sometimes a few minutes is all an attacker needs. Even if an attack is discovered through log analysis, an attacker can use the delay in detection to install backdoors, exfiltrate data, or even wreak havoc in your network.
Another aspect of this issue is forensics: some attacks are easy to discover, but some attacks are very difficult, leaving only subtle hints that anything wrong had occurred, even when using advanced machine learning algorithms. In this case, a security analyst will probably want to further diagnose the alert. But, unfortunately, some of these diagnostic activities lose their edge the longer you wait (e.g., scanning endpoint memory) and some are even impossible (e.g., issuing a multi-factor challenge).
While using log-based security analytics solutions are tempting due to low cost and wide coverage, there are pitfalls. They cannot stop zero-day vulnerabilities and advanced attacks will usually go undetected in logs. For these purposes, to achieve decent protection, you should look to include network inspection and endpoint protection tools for the full picture and context you need. Once you have a good protection of the core assets in your organization, logs are a good way of augmenting existing coverage.
1. Pass-the-Hash detection is a difficult task. Even DPI inspection has the potential of missing a trained attacker using custom attack tools that know how to camouflage his activities
Posted by Yaron Zinar on April 13, 2017 7:52 AM