S1 Local Account Creation

[bobcrusader]

SentinelOne does record local account creation. See screenshot.

[tsale]

Thanks for reaching out @bobcrusader. To me this looks like a signal and not part of the searchable telemetry. Can you confirm that there is a dedicated field that you can search for this activity? If so, what is the name of the field to search for?

[bobcrusader]

Hi Kostas,

Thanks for your follow up.

Something as simple as a query like IndicatorName = "UserAdd" turns up all new local users being created. Basically every field in the screenshot is a searchable field.

I’m just doing some additional QA on the rest of the behaviours – happy for me to continue to log them as single issues?

Regards

Rob Collins

From: Kostas @.> Reply to: tsale/EDR-Telemetry @.> Date: Thursday, 20 April 2023 at 5:57 pm To: tsale/EDR-Telemetry @.> Cc: Robert Collins @.>, Mention @.***> Subject: Re: [tsale/EDR-Telemetry] S1 Local Account Creation (Issue #8)

Thanks for reaching out @bobcrusader. To me this looks like a signal and not part of the searchable telemetry. Can you confirm that there is a dedicated field that you can search for this activity? If so, what is the name of the field to search for?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/tsale/EDR-Telemetry/issues/8#issuecomment-1515887465", "url": "https://github.com/tsale/EDR-Telemetry/issues/8#issuecomment-1515887465", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[mthcht]

@tsale @bobcrusader i can confirm it is part of the telemetry of Sentinelone deepvisibility (enrichment of the alerts) and i collected the data on a SIEM with the SentinelOne API

[tsale]

This is part of the behavioural indicators a.k.a signals. We do not cover signals as part of this project. However, I'd let @inodee to chime in and add his two cents on this as a second opinion.

[mthcht]

It is necessary to collect deep visibility logs for each alert received from SentinelOne in order to effectively investigate them within a SIEM (these are the logs used to present the process tree and actions visible on the console, the alert log is just a resume of the detection)

This principle applies to all existing EDR solutions that provide alerts logs. imo it is crucial to consider the detailed telemetry available for each alert. Otherwise, it is more beneficial to use the EDR console directly.

[tsale]

Visibility is important but it is multi faceted. The question we are trying to answer is, assuming the alert is not triggered, what is the available telemetry customers have for creating their own detections and conduct threat hunting? I dive into this topic in the introductory blog.

[mthcht]

@tsale deepvisibility is always generating logs with or without alerts (it is like Sysmon), it can be collected all the time and used to create your own detection. My use case is to automatically collect the deepvisibility logs of the impacted machine for each alert triggered to be able to investigate on the SIEM but it can be collected continuously for threathunting or custom detection rules.

[tsale]

At this point, it is not clear what deep visibility is and the main issue is generated based on a behavioural indicator. I am tempted to close this issue but I’d like @inodee to have a say on it too.

In the meantime, please reach out to me providing more information on the deep visibility logs you’re referring to and I would be happy to revisit this.

[inodee]

Hey @mthcht, @bobcrusader

Just to clarify. If I understood @mthcht correctly, users can write a SIEM detection/indicator for those events as long as they set DV to always stream that telemetry?

Is that enabled by default? Here's a definition I found:

"SentinelOne Deep Visibility (DV) extends the SentinelOne Endpoint Protection Platform (EPP) to provide full visibility into endpoint data. Its patented kernel-based monitoring allows a near real-time search across endpoints for all indicators of compromise (IOC) to empower security teams to augment real-time threat detection capabilities with a powerful tool that enables threat hunting."

@bobcrusader's example indeed seems like an indicator. Just wondering, if the user is added via another API (ex.: C# custom program), will that trigger as well?

It is necessary to collect deep visibility logs for each alert received from SentinelOne in order to effectively investigate them within a SIEM (these are the logs used to present the process tree and actions visible on the console, the alert log is just a resume of the detection)

This principle applies to all existing EDR solutions that provide alerts logs. imo it is crucial to consider the detailed telemetry available for each alert. Otherwise, it is more beneficial to use the EDR console directly.

[mthcht]

Hey @mthcht, @bobcrusader

Just to clarify. If I understood @mthcht correctly, users can write a SIEM detection/indicator for those events as long as they set DV to always stream that telemetry?

Is that enabled by default? Here's a definition I found:

"SentinelOne Deep Visibility (DV) extends the SentinelOne Endpoint Protection Platform (EPP) to provide full visibility into endpoint data. Its patented kernel-based monitoring allows a near real-time search across endpoints for all indicators of compromise (IOC) to empower security teams to augment real-time threat detection capabilities with a powerful tool that enables threat hunting."

@bobcrusader's example indeed seems like an indicator. Just wondering, if the user is added via another API (ex.: C# custom program), will that trigger as well?

It is necessary to collect deep visibility logs for each alert received from SentinelOne in order to effectively investigate them within a SIEM (these are the logs used to present the process tree and actions visible on the console, the alert log is just a resume of the detection) This principle applies to all existing EDR solutions that provide alerts logs. imo it is crucial to consider the detailed telemetry available for each alert. Otherwise, it is more beneficial to use the EDR console directly.

Deep visibility is enabled by default with the full license of SentinelOne, and the recommended default collection method is to use a SentinelOne Kafka server. There is a massive amount of data available for continuous collection, and I didn't want to collect everything all the time. Instead, I use a custom collection framework with the API to only collect the deep visibility logs automatically for machines affected by an alert. This allows me to conduct all my investigations on the SIEM, collecting both alerts and deep visibility logs. Additionally, I can implement some detection rules and threat hunting sessions based on these logs, even if I only collect some of them. However, the standard practice is to collect all logs using a Kafka server, which is also what the well-known XDR products do.

for SentinelOne i did see the UserAdd detection with softwares not using net user commandline like this example but better make sure every possible way of adding a local user is logged (i did not test)

[tsale]

After speaking with @inodee, we are both agreeing that regardless of the deep visibility logs, the main topic of this issue is based on a behavioural indicator. Therefore, it will not be counted raw telemetry which is what this project is trying to highlight.

Thank you very much @bobcrusader and @mthcht for the discussion. We are looking into updating the documentation to define telemetry more accurately going forward.