* [New Rule] AWS GetCallerIdentity API Called for the First Time
issue
* Apply suggestions from code review
name change, false positive additions, remove Setup, change new_terms window from 15d to 10d
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Update rules/integrations/aws/discovery_new_terms_sts_getcalleridentity.toml
fixed missing closing quotes
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rules] UEBA GItHub BBRs and Rules
A new set of BBRs and rules that will be used to trigger new UEBA GitHub threshold Rules.
* Update rules/integrations/github/impact_github_member_removed_from_organization.toml
* Apply suggestions from code review
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* edited BBR rules
-removed newly added member rule
* updated integration manifests and schemas
* Updated min_stack for some rules based on newest GitHub integration schema manifest
* testing min_stack bump to 8.8 for new fields
* removing offending rule to troubleshoot seperately
* added UEBA tags and created UEBA threshold rule
* updated non-ecs-schema to add signal.rule.tags
* updated non-ecs-schema with kibana.alert.workflow_status
* updated rule.threat.tactic
* added user.name to non-ecs-schema
* added quotes to kibana.alert.workflow_status value
* removed trailing space from rule name
* update tags and optimize query for UEBA threshold rule
* removed integration field from Higher-Order rule
* Apply suggestions from code review
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* adjusted new_terms order and rule types based on review feedback
* Apply suggestions from code review
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* remove user.name from detection_rules/etc/non-ecs-schema.json
* fix json formatting
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@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>
Co-authored-by: Justin Ibarra <16747370+brokensound77@users.noreply.github.com>
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* [New Rule] File System Debugger ‘debugfs’ Launched Inside a Privileged Container
This rule detects the use of the built-in Linux DebugFS utility from inside a privileged container. DebugFS is a special
file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside
a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access
sensitive host level files which could be used for further privilege escalation and container escapes to the host
machine.
* added references
* Apply suggestions from code review
* Update rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Apply suggestions from code review
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* [New Rule] Mount Launched Inside a Privileged Container
This rule detects the use of the mount utility from inside a privileged container. The mount command is used to make a
device or file system accessible to the system, and then to connect its root directory to a specified mount point on the
local file system. When launched inside a privileged container--a container deployed with all the capabilities of the
host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation
and container escapes to the host machine. Any usage of mount inside a running privileged container should be further
investigated.
* Apply suggestions from code review
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* [New Rule] Potential Container Escape via Modified notify_on_release File
This rule detects modification of the cgroup notify_on_release file from inside a container. When the notify_on_release
flag is enabled (1) in a cgroup, then whenever the last task in the cgroup exits or attaches to another cgroup, the
command specified in the release_agent file is run and invoked from the host. A privileged container with SYS_ADMIN
capabilities, enables a threat actor to mount a cgroup directory and modify the notify_on_release flag in order to take
advantage of this feature, which could be used for further privilege escalation and container escapes to the host
machine.
* Apply suggestions from code review
* suggestions from code review
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [New Rule] Potential Container Escape via Modified release_agent File
This rule detects modification of the CGroup release_agent file from inside a privileged container. The release_agent is a script that is executed at the termination of any process on that CGroup and is invoked from the host. A privileged container with SYS_ADMIN capabilities, enables a threat actor to mount a CGroup directory and modify the release_agent which could be used for further privilege escalation and container escapes to the host machine.
* Apply suggestions from code review
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* added new rule 'Multiple Okta Users with the Same Device Token Hash'
* moved rule to okta integration folder
* adjusted query to be optimized
* added false positive comment
* Update rules/integrations/okta/initial_access_multiple_active_users_from_single_device.toml