* [New Rule] Kubernetes Container Created with Excessive Linux Capabilites
This rule detects a container deployed with one or more dangerously permissive Linux capabilities. Using the Linux capabilities feature you can grant certain privileges to a process without granting all the privileges of the root user. Added capabilities entitle containers in a pod with additional privileges that can be used to change core processes and networking settings of a cluster. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster or the host machine. This rule detects the following capabilities and leaves space for the exception of trusted permissive containers specific to your environment:
BPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more.
DAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks.
NET_ADMIN - Perform various network-related operations.
SYS_ADMIN - Perform a range of system administration operations.
SYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution.
SYS_MODULE - Load and unload kernel modules.
SYS_PTRACE - Trace arbitrary processes using ptrace(2).
SYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)).
SYSLOG - Perform privileged syslog(2) operations.
* Update privilege_escalation_container_created_with_excessive_linux_capabilities.toml
Edited description, false positives, and elaborated with a partial investigation guide.
* Update privilege_escalation_container_created_with_excessive_linux_capabilities.toml
added exception to rule query
* Update privilege_escalation_container_created_with_excessive_linux_capabilities.toml
add Execution.Deploy Container Tactic.Technique
* [New Rule] Kubernetes Suspicious Assignment of Controller Service Account
Issues
--
#2034
Summary
--
This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control.
* Update privilege_escalation_suspicious_assignment_of_controller_service_account.toml
updated query after testing
* Update non-ecs-schema.json
added new field used in query update
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* [New Rule] Kubernetes Denied Service Account Request
## Issue
#2040
## Summary
This rule detects when a service account makes an unauthorized request for resources from the API server. Service accounts follow a very predictable pattern of behavior. A service account should never send an unauthorized request to the API server. This behavior is likely an indicator of compromise or of a problem within the cluster. An adversary may have gained access to credentials/tokens and this could be an attempt to access or create resources to facilitate further movement or execution within the cluster.
* Update discovery_denied_service_account_request.toml
updated the query after testing to reduce false positives
* Update rules/integrations/kubernetes/discovery_denied_service_account_request.toml
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rule] Kubernetes Anonymous Request Authorized
## Issue
#2038
## Summary
This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use
anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster.
This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously.
* [New Rule] Kubernetes Suspicious Change to Privileges of Running Security Context
## Issue
https://github.com/elastic/detection-rules/issues/2032
## Summary
* Delete non-ecs-schema.json
* Delete privilege_escalation_suspicious_change_to_privileges_of_running_security_context.toml
* Create non-ecs-schema.json
* Update detection_rules/etc/non-ecs-schema.json
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* adding new rule
* adjusted query format
* adjusted file and rule name to include google workspace
* Update collection_google_drive_ownership_transferred_via_google_workspace.toml
Fixed a couple minor typos
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* adding new rule
* adjusting rule name, file name and description
* adjusted att&ck technique
* adjusted file and rule name to include google workspace
* adjusted references
* Update persistence_google_workspace_user_group_access_modified_to_allow_external_access.toml
Fixed minor typo
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Create discovery_suspicious_self_subject_review.toml
Adding new rule
* non-ecs-schema fields added and query change to specify fields
added non ecs-schema fields for all coming k8s rules and added specific fields to the query instead of using regex
* Update discovery_suspicious_self_subject_review.toml
* Update rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rule] Kubernetes Pod Created With HostPID
new rule toml for pod created with hostPID and updated non-ecs-schema with all k8s fields
* Update privilege_escalation_pod_created_with_hostpid.toml
* Update rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rule] Kubernetes Pod Created With HostNetwork
new rule toml for pod created with hostNetwork and added all k8s fields to non-ecs-schema json
* Update privilege_escalation_pod_created_with_hostnetwork.toml
* Update rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rule] Kubernetes Pod Created With HostIPC
new rule toml file for pod created with hostIPC and k8s fields added to non-ecs-schema json
* Rename privilege_escalation_pod_created_with_hostIPC.toml to privilege_escalation_pod_created_with_hostipc.toml
* Update rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rule] Kubernetes Exposed Service Created With Type NodePort
new rule toml for exposed service created with type nodeport and added all k8s fields to non-ecs-schema
* Update rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
I'm removing the event.dataset query portion of the rule because this field has been removed from the current mapping so this rule is not triggering with the most updated K8s Integrations.
* initial commit with eggshell mitre mapping added
* adding updated rules
* [Rule Tuning] MITRE for GCP rules
I've added Mitre references for the 4 GCP rules missing. Changed 3 of the rules from "Impact" to "Defense Evasion" based on the technique used and it's matched tactic.
* [Rule Tuning] Endgame Rule name updates for Mitre
Updated Endgame rule names for those with Mitre tactics to match the tactics.
* Update rules/integrations/aws/persistence_redshift_instance_creation.toml
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
* Update rules/integrations/aws/exfiltration_rds_snapshot_restored.toml
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
* adding 10 updated rules for google_workspace, ml and o365
* adding 22 rule updates for mitre att&ck mappings
* adding 24 rule updates related mainly to ML rules
* adding 3 rules related to detection via ML
* adding adjustments
* adding adjustments with solutions to recent pytest errors
* removed tabs from tags
* adjusted mappings and added techniques
* adjusted endgame rule mappings per review
* adjusted names to match different tactics
* added execution and defense evasion tag
* adjustments to address errors from merging with main
* added newlines to rules missing them at the end of the file
Co-authored-by: imays11 <59296946+imays11@users.noreply.github.com>
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
* Convert config header to setup in note field
* Parse note field into separate setup and note field with marko gfm
* only validate and parse note on elastic authored rules and add CLI description for new DR_BYPASS_NOTE_VALIDATION_AND_PARSE environment variable
Co-authored-by: brokensound77 <brokensound77@users.noreply.github.com>
* Create execution_user_exec_to_pod.toml
* Update execution_user_exec_to_pod.toml
* Update rules/integrations/kubernetes/execution_user_exec_to_pod.toml
* Update non-ecs-schema.json
* Update execution_user_exec_to_pod.toml
* Update rules/integrations/kubernetes/execution_user_exec_to_pod.toml
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Update execution_user_exec_to_pod.toml
* Update execution_user_exec_to_pod.toml
* Update execution_user_exec_to_pod.toml
* toml-linted file and add to false positive
toml-linted the file and added to the false positive description
* Create notepad.sct
Added this back into the repo, deleted by mistake.
* added min_stack_version based on integration
min stack version determined by integration support of necessary fields
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* add RDS instance deletion to aws rule
I've added to this rule to improve coverage. Currently we detect creation and stopping of RDS clusters and instances. But, we only detect for the deletion of clusters, not instances. This adds the deletion of RDS instances to the detection.
* Update rules/integrations/aws/impact_rds_instance_cluster_deletion.toml
Co-authored-by: Justin Ibarra <brokensound77@users.noreply.github.com>
Co-authored-by: Justin Ibarra <brokensound77@users.noreply.github.com>
* Update persistence_ec2_security_group_configuration_change_detection
Rule does not trigger as expected due to 'iam' provider. I changed the specified provider to 'ec2'.
* update to improve rule coverage
I edited this rule to include the deletion of an RDS Instance. This fills a current gap in coverage as we are able to detect the creation and stopping of RDS instances and clusters, but only detect deletion of RDS clusters.
* Revert "update to improve rule coverage"
This reverts commit b3b094274fe13c56908aa6781c8236de6e3b5380.
* Expand timestamp_override tests
* removed timestamp_override from eql sequence rules
* add config entry for eql rules with beats index and t_o
* add timestamp_override to missing fields
* [Rule tuning] Update rule verbiage based on docs review
* fix typos
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
* revert TI rule changes since it was deprecated
Co-authored-by: Jonhnathan <jonhnathancesar@gmail.com>
Isai