[New Rule] Kubernetes Activity by system:anonymous

christophercutajar commented 3 years ago

Description

Kubernetes is an attacking vector that current there is no detection rules for. During my initial analysis I was able to create a KQL queries that can detect the following activity:

The purpose of this rule to detect activity by unauthenticated system:anonymous service account

Required Info

Target indexes

filebeat-* with gcp module having audit configured.

Additional requirements

Target Operating Systems

Kubernetes

Platforms

Google Kubernetes Engine

Tested ECS Version

1.8.0

Optional Info

Query

readyz and livez are being excluded as these endpoints are used by kube-probe for monitoring of the cluster.

Query

``` "query": { "bool": { "must": [], "filter": [ { "bool": { "should": [ { "match_phrase": { "gcp.audit.authentication_info.principal_email": "system:anonymous" } } ], "minimum_should_match": 1 } }, { "range": { "@timestamp": { "gte": "2021-05-04T09:44:51.541Z", "lte": "2021-05-05T09:44:51.541Z", "format": "strict_date_optional_time" } } }, { "match_phrase": { "event.module": "gcp" } }, { "match_phrase": { "gcp.audit.type": "type.googleapis.com/google.cloud.audit.AuditLog" } }, { "match_phrase": { "log.logger": "projects/elastic-infosec/logs/cloudaudit.googleapis.com%2Fdata_access" } } ], "should": [], "must_not": [ { "match_phrase": { "gcp.audit.resource_name": "readyz" } }, { "match_phrase": { "gcp.audit.resource_name": "livez" } } ] } } ```

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

Related issues or PRs

Ready to create the necessary detection rule toml files

References

https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging

Example Data

austinsonger commented 3 years ago

My first go around on it.

event.dataset:(googlecloud.audit or gcp.audit) and 
googlecloud.audit.authentication_info.principal_email:"system:anonymous"

christophercutajar commented 3 years ago

My first go around on it.

event.dataset:(googlecloud.audit or gcp.audit) and 
googlecloud.audit.authentication_info.principal_email:"system:anonymous"

More awesome feedback, thank you @austinsonger! My take would be to also include event.outcome: success to reduce the noise. event.outcome: success has a log.logger: projects/elastic-infosec/logs/cloudaudit.googleapis.com%2Fdata_access meaning data has been accessed. On the other hand, having log:logger: projects/elastic-infosec/logs/cloudaudit.googleapis.com%2Factivitydoesn't mean that data was accessed.

Having a lot of event.outcome: failure, this could be due to a DDos which might be another separate detection rule.

In addition, readyz and livez in my opinion has to be included in the exception list. From our production data, I'm seeing about 23,644 hits in total over the past 24hrs. These are all coming within the cluster.

botelastic[bot] commented 3 years ago

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.

christophercutajar commented 3 years ago

I'll dedicate some time to open a PR for this one

austinsonger commented 3 years ago

@christophercutajar

What about this?

event.dataset:(googlecloud.audit or gcp.audit) and 
(googlecloud.audit.authentication_info.principal_email:"system:anonymous" and not
gcp.audit.resource_name:(readyz or livez)) and event.outcome: success

christophercutajar commented 3 years ago

@christophercutajar

What about this?

event.dataset:(googlecloud.audit or gcp.audit) and 
(googlecloud.audit.authentication_info.principal_email:"system:anonymous" and not
gcp.audit.resource_name:(readyz or livez)) and event.outcome: success

@austinsonger my apologies for the late reply! This logic looks good to me.

elastic / detection-rules