Every day, Truesec works with thousands of alerts and incidents from various security technologies. In most of these cases, vendor detection rules function as expected. However, in some cases, the vendor’s detections are not enough.
Most security technologies support the use of custom detections, which allows our SOC engineers to create their own alerts based on insights from our security operations center, incident response missions, and our threat intelligence research. This is useful in several different scenarios, either during emerging campaigns or to fill in detection gaps in the product’s baseline.
Custom detections for EDRs can include but are not limited to network, process, file, and even some WinAPI calls, depending on the vendor.
As an example of a case where custom detections played an important role in identifying and stopping emerging threats, at the beginning of this year Truesec investigated a Qbot phishing campaign using OneNote files attached to emails. Qbot is an initial access broker, which means they’re leveraging vulnerabilities, misconfigurations and social engineering to gain unauthorized access to systems. The access is then sold to other threat actors who can carry out post-exploitation activities in the compromised organization. Successful Qbot deployments often lead to ransomware being deployed. At the time, there were no default detections for this type of alert.
In this scenario, custom detections were implemented to detect this specific technique, before it was detected by the product. This was possible as we had enough event data to enrich the detection capabilities.
The screenshot below shows a process tree in Microsoft Defender for Endpoint (MDE). A OneNote file has been executed from a zip archive that arrived via email, which contains an hta file. This is executed by mshta.exe which downloads a DLL from a malicious domain. In the final stage, the downloaded payload is executed by rundll32.
As seen in this case, an alert was triggered by a Truesec custom detection rule designed to detect Office (and other) products spawning suspicious applications, even though the built-in detection mechanisms in the EDR had not reacted to this behavior. Similar to this campaign, custom detections can be applied to extend detection capabilities. The SOC can focus on detecting techniques, tactics, and procedures (TTP) rather than focusing on static Indicators of compromise (IoC) which often quickly become irrelevant as filenames, hashes and domains are continuously changed by threat actors.
Going Beyond Custom Detections
Earlier this year, Truesec discovered that it was possible to extract credentials from a remote Windows host using the RemoteRegistry service in an elevated session. At the time, this was undetected by MDE.
In this attack the credentials are extracted from SAM and SECURITY hives using the RemoteRegistry service. First, the service is queried to see if it’s running, if not it will be started remotely. RemoteRegistry uses the RegSaveKey operation to save the keys onto disk. In this attack, the keys are saved to disk as .tmp files with random characters as filenames. The .tmp files are then transferred back to the attacker via SMB and the service will be stopped if it wasn’t initially running.
Below, we see the event stream of the attack. There is a network logon, named pipes created towards DeviceNamedPipewinreg and unknown process files being observed on the host.
These events are very common in an enterprise environment, searching back 30 days in the events, 10k+ events were presented.
The challenge of working with a third-party EDR is that we have limited control over which information will appear in the event stream, as this is based on the data available within the tool itself.
How do we detect something like this, when the events shown could be legitimate behavior and the information provided is not enough to create custom detections? How can we improve the underlying tool?
We turn to the vendor!
As soon as we had enough information, we contacted Microsoft with all the necessary details.
Following our reporting, Microsoft implemented detection capabilities for this attack, as seen in the screenshot below. In addition to detecting the attack technique, the update also extended the events and information displayed during an attack like this.
The benefit in this scenario compared to creating custom detections is that it resulted in the new detections being rolled to all MDE customers globally as well as further extending the events generated.
Summary
The goal of Detection Engineering is to always stay one step ahead of the threat actors.
During the past year, Truesec has observed multiple campaigns where threat actors have been using increasingly stealthy methods to bypass and avoid security technologies. As previously mentioned in this blog post, Truesec has observed several attacks where custom detections have been the only detections visible in the console.
In this article, the focus has been on EDR. However, working with detection engineering applies to all security tooling that supports customization.
As threat actors evolve, detections need to evolve to identify new attacks, and even predict the next ones.