[Rule Tuning] Account Password Reset Remotely Wildcard Usage

[terrancedejesus]

Related

• https://github.com/elastic/sdh-elasticsearch/issues/7922

Link to rule

https://github.com/elastic/detection-rules/blob/main/rules/windows/persistence_remote_password_reset.toml

Description

This rule has poor performance due to wildcard usage and terms in winlog.event_data.TargetUserName. The query should be reviewed overall for wildcard usage and adjust accordingly.

[terrancedejesus]

Feb 12, 2024

• Had a conversation with @Samirbous about the intention of this rule, the query logic, data source, tuning and more
• Regarding intention, it is looking for a network-based login, followed by a password reset
• Regarding logic, there are a couple of key factors to consider
  • There is currently no way to determine if a user is remotely logged in or not, hence why this rule is sequenced by the computer name and the first sequence is a network login
  • not winlog.event_data.TargetUserName : ("svc*", "PIM_*", "_*_", "*-*-*", "*$")] - This is an attempt to exclude any Windows or custom service accounts, which have varying differences. As shown in the query logic note, we expected this rule to be noisy as a result of custom service account naming conventions.

Potential Solutions:

• Disable the rule - If the rule is too inherently performance heavy and tuning with exceptions does not help, ultimately disable the rule
• Clone the rule and adjust logic - While rule mutability is not yet available, customers have the option to copy the rule, disable the old, and adjust the copy's logic. Alternatively, as stated in the query note, specific service accounts can be expliclity ignored to replace the global logic of when we are attempting to ignore winlog.event_data.TargetUserName

While tuning is possible, we have thoroughly reviewed this query and the telemetry and determined that not many further adjustments can be made for the wildcard usage, nor the generic capturing of remote logins for the first sequence. Therefore, what we are attempting to filter on must remain, however, how we filter is up for discussion. We are unsure of the trade-offs in performance with regex vs wildcards or wildcards vs endswith (startswith), etc. If we could have a clear understanding on these differences in performance and their impact, it will help influence not only this tuning issue but how we approach rules, new and old, in general.

We have also noted that several other customers have this rule enabled and are receiving alerts as expected from telemetry without rule failure alerts. Thus we are choosing not to deprecate for a single customer and effect those currently with no issues.

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[botelastic]

This has been closed due to inactivity. If you feel this is an error, please re-open and include a justifying comment.