[New Rule] Elastic Agent status not validated

peasead commented 1 month ago

Description

If you have local admin permissions on a machine, you can change the agent ID in the local agent configuration, restart the service, and the results will show up in Elasticsearch as the new agent ID.

This would allow an adversary to create a rogue host, where alerts would not be attributable to the right system. TAs would then have additional dwell time as responders looked for intrusions on the wrong system.

Required Info

Target indexes

logs-*

Additional requirements

Target Operating Systems

Windows, Linux, macOS

Tested ECS Version

8.10.0 <- telemetry

Optional Info

Query

FROM logs-*
| WHERE event.agent_id_status IS NOT NULL and event.agent_id_status != "verified"
| STATS hosts = count_distinct(agent.id)
| WHERE hosts >= 1

New fields required in ECS/data sources for this rule?

NA

Related issues or PRs

References

https://www.elastic.co/guide/en/ecs/current/ecs-event.html#field-event-agent-id-status

Example Data

H/T @gabriellandau @joe-desimone

gabriellandau commented 1 month ago

cc @joe-desimone

Aegrah commented 1 month ago

Looking at the current rule to detect this together with @DennisHaug, we noticed that the event.agent_id_status:agent_id_mismatch query does not match the attack during LS24, because the field value is changed to just mismatch. event.agent_id_status:mismatch does show these entries.

I will get a tuning in for that specific rule as a starter.

edit: https://github.com/elastic/detection-rules/pull/3729

peasead commented 1 month ago

I think that rule might be best to be anything BUT verified?

There are several options.

Aegrah commented 1 month ago

@peasead I did a recommendation in the PR to make the change. My concern is that we might end up FP'ing to much; but I don't have a good place to check. Will ask around to see what others think.

elastic / detection-rules