[New Rule] Elastic Agent status not validated

[peasead]

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]

cc @joe-desimone

[Aegrah]

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: #3729

[peasead]

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

There are several options.

[Aegrah]

@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.