update Elastic telemetry based on evidence in public rules repos

[jdu2600]

Description

Just following up on #54. The Scheduled Task and Service telemetry is via the underlying file & registry activity - not EventLogs.

1. Does the proposed EDR feature align with our definition of telemetry?\ Yes.
2. Could you please provide documentation to support the telemetry you are proposing? Yes. Elastic includes 12 Scheduled Task and 12 Windows Service rules out of the box. The raw telemetry is the low-level file and registry events associated with this activity. https://github.com/search?q=repo%3Aelastic%2Fprotections-artifacts%20%22T1053.005%22&type=code https://github.com/search?q=repo%3Aelastic%2Fprotections-artifacts%20%22T1543.003%22&type=code

Type of change

• [x] Feature Improvement (non-breaking change which fixes an issue)

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have made corresponding changes to the documentation
• [ ] I have added tests that prove my corrections or additions are accurate
• [x] I have checked my code and corrected any misspellings

[tsale]

These detections are created based on command lines or other methods that they use to correlate upon execution. This is not telemetry associated directly with the corresponding subcategory that you are proposing changes for.

I have spoken with folks at Elastic and it would be nice in the future to tap into the system telemetry instead of relying on command lines. In this project we are looking for telemetry collected directly from a source and not as a result of a detection or a different alternative method based on correlation of different subcategories. I hope that makes sense.

[jdu2600]

These detections are created based on command lines

Ah. I suspect there is some confusion here - as Elastic has an EDR-agnostic SIEM as well as an EDR offering.

I believe that some of the Elastic SIEM detection rules are command line based (in order to be EDR-agnostic) - https://github.com/search?q=repo%3Aelastic%2Fdetection-rules%20%22T1053.005%22&type=code https://github.com/search?q=repo%3Aelastic%2Fdetection-rules%20%22T1543.003%22&type=code

However the Elastic EDR detections rules are not. They are robust rules based on the detecting changes to the backing OS final source of truth. The core of the Scheduled Task detection logic is file.path : "?:\\Windows\\System32\\Tasks\\*". The core of the Service logic is registry.path : "HKLM\\SYSTEM\\*ControlSet*\\Services\\*". https://github.com/search?q=repo%3Aelastic%2Fprotections-artifacts%20%22T1053.005%22&type=code https://github.com/search?q=repo%3Aelastic%2Fprotections-artifacts%20%22T1543.003%22&type=code

afaik the "system telemetry" (such as Microsoft-Windows-Services ETW) is actually less robust than this approach. See https://posts.specterops.io/thoughts-on-detection-3c5cab66f511

@brokensound77 @Samirbous - Am I misunderstanding anything?

[jdu2600]

@tsale - Any update based on the new information provided?

[tsale]

Hello @jdu2600, I appreciate you sharing the information. However, I wanted to clarify that currently, telemetry related to scheduled tasks and services cannot be directly obtained using ETW or other similar methods. In the example below, the rule is checking for process and file creation, which is still a useful way to detect such activity. However, for this specific project, we are interested in telemetry that can be collected from direct sources.

There are several vendors who generate similar telemetry by using only schtasks.exe, which is launched with specific parameters. We want to ensure that we remain fair and unbiased across all products on our EDR telemetry table. Therefore, we have decided not to include any telemetry that relies on other sub-categories. I hope this clarifies our approach.

[jdu2600]

Thanks for the response @tsale, but I remained highly confused.

Are you able to further clarify what the "direct sources" for Scheduled Tasks and Services are? Specifically, what do you believe other vendors are collecting from the OS that you deem Elastic is currently not doing?

I can understand why you are excluding (brittle) approaches based on command line options of specific tools. Elastic's (robust) approach, based on monitoring for changes to the backing OS source of truth, is not comparable to these. As far as I am aware, Elastic's approach is industry best practice.

Or is the concern here simply the presentation of the data? And that you would prefer Elastic to hide the actual telemetry source from the user - and to instead send fake "scheduled task" and "service" events instead?

[tsale]

I don't agree with you and I provide most of the answers to your questions related to this issue above. I'm afraid we're running in circles here. You are free to disagree with this approach, but this issue will remain closed for the time being. Thank you for your efforts on improving this project 🙏

[jdu2600]

@tsale Nothing wrong with some healthy disagreement. That's how we learn. 😄

I've summarised the facts as I understand them below - even though we draw different conclusions from them.

1. This project defines Service Creation telemetry as Event Log id 4697/7045.
2. A service is a set of registry keys that are maintained by the Service Control Manager. These keys are also referred to as the Service Control Manager database.
3. A service created using the MS-SCMR RPC interface, either via sc.exe or otherwise, will generate both an event log and registry write activity.
4. A service created by writing directly to the registry will not generate an event log.
5. MITRE recommends monitoring for changes to the %HKLM\System\CurrentControlSet\Services\% registry keys.
6. EDRs that only monitor service creation event logs do not produce telemetry for all service creations.
7. Elastic EDR monitors the Service Control Manager database for changes.
8. Every service creation that generates an event log will generate a registry event in Elastic EDR.

[jdu2600]

https://ipurple.team/2024/01/03/scheduled-task-tampering/

Microsoft recommendation in the original article is to enable and centralize Scheduled Task logs in order to capture Event ID’s related to scheduled task creation (4698) and modification (4702). However, it is confirmed that these events are only generated when a scheduled task is created or updated from the task scheduler directly and not when registry keys are utilized. Therefore, this could lead to an excessive number of logs especially in corporate domains with high volume of assets and without giving a reliable detection opportunity. It is recommended threat hunting efforts to focus on registry events.