Detection and response means becoming an active defender

Using an endpoint detection and response (EDR) tool like ESET Inspect is a significant step forward in advancing your security stance. If the expected output from the security products you have been using until now is merely to be informed that detections have been made, threats blocked, and malicious files deleted, then your security stance has been largely passive. This approach is not ideal, but understandable when an organization’s IT staff does not have the time or the advanced technical skills to take a more active role in their security.

However, investing in a detection and response solution indicates a healthy curiosity about what is happening behind the curtain. A detection and response product gives IT admins visibility into the events happening on a computer, such as scripts that have been run, commands executed, HTTP(S) requests, TCP/IP connections, DNS requests, registry modifications, file operations, process changes, and so on.

Figure 1 shows part of a comprehensive list of events that ESET Inspect can serve up.

To help make sense of all this data, a detection and response product comes with rules to pinpoint specific events, or sequences of events, that are suspicious or worthy of monitoring. Since our EDR solution can connect with the ESET LiveGrid system, ESET’s security engineers have fine-tuned ESET Inspect’s rules to consider the reputation and popularity of executables where relevant.

Figure 2 shows how the rules prioritize the events presented to the IT admin sitting at the ESET Inspect console.

After initial deployment, many detections probably will be triggered by harmless events until the EDR solution is optimized. From here on out, we’ll only consider ESET’s EDR solution, unless stated otherwise.

Each organization has its baseline of benign events produced by the computers in its networks. Thus, the IT admin’s first job is to look through the detections and understand what “normal” looks like.

For example, Figure 3 shows detections from a rule designed to report probes about a system’s network configuration – a technique commonly used by cyberespionage malware and ransomware, and in this case by the Lenovo Vantage Service.

If the organization allows the use of Lenovo Vantage, then the IT admin can create an exclusion for this activity, as shown in Figure 4. And if the organization has no Lenovo devices in its fleet, or this activity occurred on a non-Lenovo device, this is probably an inherently suspicious event!

Here the exclusion only applies to version 3.13.14.0 of the Lenovo Vantage Service, but you could trim the version number off the end of the process path to exclude all versions. This decision centers on balancing risk against noise – a choice that must be constantly repeated during your time with any EDR console.

Developing all the exclusions needed for your organization’s baseline of expected events takes time. Although IT admins should take the time to familiarize themselves with their organization’s network by manually inspecting detections and creating exclusions for them where appropriate, ESET Inspect does offer a learning mode that automates the creation of exclusions and even has pre-written exclusions that can be enabled. In the former case, IT admins should review all automatic exclusions.

Although new releases of ESET Inspect typically come with new rules, IT admins don’t have to wait to write new rules of their own. ESET Inspect empowers security defenders by giving them both deep visibility into events and the decision-making power about what is monitored via custom rules and exclusions. Admins can even tune the default and custom rules with aggressive response actions, such as killing processes, blocking processes by their hashes, and isolating computers from the network.

Indeed, this is where organizations get the most value from their ESET Inspect investment: by writing rules that address their prioritized areas of risk. Let’s illustrate this with new rules taken from the desks of ESET’s security engineers.

In April 2022, ESET detected Emotet experimenting with a technique to bypass the Mark of the Web by sending shortcut (LNK) files in email attachments. Not to be outdone, other strains of malware, such as BumbleBee, Qbot, and BazarLoader, have also experimented with LNK files but in ISO disk images.

Because ESET Inspect can monitor LNK files and detect mounted ISOs (under the %CDROM% and %RemovableDrive% environment variables), this is an excellent opportunity for writing new rules that can monitor this technique. Let’s walk through four new rules released with ESET Inspect version 1.9.

This rule monitors for a suspicious DLL being loaded by a trusted process started from a removable or CD-ROM drive (including a mounted ISO image) and with an ancestor process started by a LNK file on a removable or CD-ROM drive.

Figure 5 shows this rule being tested against a delivery mechanism for a Brute Ratel C4 payload. A detection is made after a chain of events triggered by double-clicking a LNK file on a mounted ISO that has three components of interest:

1. LNK file – Roshan-Bandara_CV_Dialog.lnk
2. Executable – onedriveupdater.exe
3. DLL – version.dll

Here, the rule is triggered because the suspicious version.dll is loaded by a trusted process running onedriveupdater.exe. This was started by a process running cmd.exe, which was started by the victim double-clicking Roshan-Bandara_CV_Dialog.lnk.

In effect, this rule detects DLL side-loading, in which an attacker starts a legitimate executable and abuses the requirement of that executable for a specific DLL file by placing a malicious DLL with the required filename earlier in the prescribed load order than the legitimate DLL. In this case, the malicious DLL was placed in the same directory as the executable.

This rule monitors for a suspicious DLL being executed by rundll32.exe, regsvr32.exe, or odbcconf.exe, where both the DLL and the LNK file that started the process running one of these system binaries are on a removable or CD-ROM drive.

Figure 6 shows this rule being tested against a delivery mechanism for a BumbleBee payload. A detection is made after a chain of events triggered by double-clicking a LNK file on a mounted ISO that has two components of interest:

1. LNK file – project requirements.lnk
2. DLL – start.dll

Here, the rule is triggered because the suspicious start.dll is executed by the process running odbcconf.exe, which was started by the victim double-clicking project requirements.lnk. Both the LNK file and the DLL are located on a mounted ISO image.

This rule monitors for a process running a living off the land binary (LOLBin) that has an ancestor process started from a LNK file on a removable or CD-ROM drive.

Figure 7 shows this rule being tested against a delivery mechanism for a Qbot payload. A detection is made after a chain of events triggered by double-clicking a LNK file on a mounted ISO that launches a command shell and leads to the abuse of two living off the land binaries: regsvr32.exe and explorer.exe.

In effect, this rule detects the abuse of a LNK file in a mounted ISO to bypass the Mark of the Web and achieve command execution via trusted binaries.

IT admins can make these four rules more powerful now by including an action in the rule to kill the compromised process (which will be a default action with ESET Inspect 1.10). This can provide protection against new or unknown malware that has not yet been detected by an endpoint security product.

By keeping a sharp eye out for new and increasingly active malicious techniques and putting a hand to the creation of rules to detect them, IT admins can maximize their organization’s investment into ESET Inspect. Indeed, without this further investment into creating exclusions and writing new rules, the full potential benefits for defense remain untapped. ESET Inspect is at its strongest in the hands of active and studious defenders who are dedicated to learning more about the networks they are asked to protect and who are intrepid enough to grapple with the latest threats head-on.

If an organization lacks staff with sufficient skills or time to dive deeper into ESET Inspect, it is always possible to inquire about the availability of managed detection and response (MDR) at a local ESET partner. With MDR, the staff problem is handled by outsourcing the management of ESET Inspect to local ESET experts.

Watch a testimonial video of how ESET protects the Royal Swinkels Family Brewers with MDR.