MDR
To effectively counter cyberthreats that circumvent basic security measures, a managed detection and response (MDR) service must ensure the right data collection tools are in place in the protected organization from the start. In addition, the service team and the client team should regularly discuss how to improve telemetry collection, and what other data should be collected in order to stay ahead of evolving attacker tactics. Our experts not only advise clients on proper data collection, but also closely monitor the changing threat landscape to continuously refine the process. Our latest MDR service report details incidents in client infrastructures and the tactics attackers have used. A dedicated section of the report covers the most frequently triggered detection rules in 2024, and what’s required for them to function effectively.
Dumping registry hives
Among the suspicious operations frequently detected in high-severity incidents, the most common by far is the extraction of security-critical data from the system registry (dumping of sensitive registry hives). This activity was observed in 27% of high-severity incidents.
To detect such extraction, the MDR provider must have telemetry from an EDR system installed on all computers and servers in the protected organization. If there’s an endpoint protection system (EPP) that can detect suspicious (not necessarily malicious) activity, this can also serve as a source of the necessary data. An event that most definitely should be logged is registry access.
Malicious code in memory
Many attacks occur in such a way that malicious files are never stored on the hard drive. However, an endpoint protection system can detect malicious code in the memory of a system process or another memory segment. This occurred in 17% of high-severity incidents, and such events from the EPP must be instantly visible to the MDR service.
Suspicious services
The creation and execution of Windows services containing suspicious arbitrary code is a strong indicator of an unfolding cyberattack. This was also detected in nearly 17% of high-severity incidents. To detect this activity, telemetry must include OS system events, process launch information, and the complete contents of all startup lists.
Access to a malicious host
Though seemingly simple, this event appeared in 12% of high-severity incidents, and requires an up-to-date IP reputation database for detection. In a company’s infrastructure, access attempts can be tracked in multiple ways: EPP detection, network-level monitoring, and DNS/HTTP request analysis. The MDR provider can also use threat intelligence databases to enrich the client’s telemetry.
Memory fragment dumps
To escalate an attack within a victim’s network after the initial compromise, attackers often try to obtain credentials on an infected machine. If they get lucky, these may be network administrator credentials, allowing them to quickly take over servers. A classic technique for achieving this is extracting and saving memory fragments related to the LSASS (Local Security Authority Subsystem Service). In 2024, we detected this technique in nearly 12% of high-severity incidents.
Attempts to capture LSASS memory can be detected in multiple ways: using certain EPP and EDR rules, analyzing command-line parameters when launching applications, scripts and processes, and monitoring access to LSASS.
Executing a low-reputation object
Although a file, script, or document may not be definitively malicious, if it was previously observed in suspicious activity, MDR specialists must check whether a cyberattack is underway. This requires telemetry that logs processes launching suspicious files. And, of course, threat intelligence is needed to flag the file’s bad reputation. Execution of low-reputation objects was observed in 10% of high-severity incidents.
Adding privileged users
Beyond stealing administrator accounts, attackers often create their own accounts and then elevate their privileges. In 9% of high-severity incidents, an account was added to a privileged corporate domain group. To detect this, OS event collection must capture all account modifications.
Remote process execution
In over 5% of incidents, there was a process involved that was launched by a remote user. To monitor such events, computers must log process launch events and the loading of executable file sections into memory.
Malicious address in event parameters
In any event-parameters — but most commonly in the command line of the running process — a known malicious URL may appear. This was observed in nearly 5% of high-severity incidents, making it crucial to always include detailed parameters of logged events, including the full command line, in the telemetry. For MDR providers, such detection is only possible with access to a large URL-reputation database (which we, of course, have).
Telemetry sources
Above, we’ve highlighted the most critical events that help an MDR team detect and prevent serious incidents. The full report covers additional events and a deeper analysis of attacker tactics. The list above makes it clear what types of data must be transmitted to an MDR service in real time for it to work effectively. First and foremost, this includes:
- Telemetry from endpoint protection solutions (EPP) or EDR agents. In today’s organizations, traditional “antivirus” and detection and response tools are often integrated into a single product. This provides key telemetry from computers and servers, so its presence is essential on all machines, along with the configuration of detailed event logging in collaboration with the MDR team.
- OS events. Properly configured Windows logs provide critical information about account manipulations, process launches and terminations, and more. On Linux systems, the same role is played by Audit Daemon (aka auditd). Special attention must be given to configuring logging on all of the organization’s servers. Detailed recommendations for settings for Windows can be found in our knowledge base. The Sysmon tool from the Microsoft Sysinternals suite enhances the effectiveness of Windows logs.
- Events from network devices. It’s critical to configure detailed logging on network devices — primarily firewalls and web filters, but also routers, proxies, and DNS servers if used in the company.
- Cloud environment logs. Attackers frequently compromise cloud infrastructure and SaaS tools, where the previously mentioned logs are typically not available. Therefore, it’s essential to set up comprehensive security-focused logging using cloud-native tools, such as AWS CloudTrail.
Tips