* Locked versions for releases: 7.16,8.0,8.1,8.2,8.3,8.4,8.5,8.6
* added newline in version lock file to trigger checks
* removed trailing newline from version lock file
Co-authored-by: terrancedejesus <terrancedejesus@users.noreply.github.com>
Co-authored-by: terrancedejesus <terrance.dejesus@elastic.co>
* initial commit
* addressing flake errors
* added apm to _get_packagted_integrations logic
* addressed flake errors
* adjusted integration schema and updated rules to be a list
* updated several rules and removed a unit test
* updated rules with logs-* only index patterns
* Update tests/test_all_rules.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* addressed flake errors
* integration is none is windows, endpoint or apm
* adding rules with accepted incoming changes from main
* fixed tag and tactic alignment errors from unit testing
* adjusted unit testing logic for integration tags; added more exclusion rules
* adjusted test_integration logic to be rule resistent and skip if -8.3
* adjusted comments for unit test skip
* fixed merge conflicts from main
* changing test_integration_tag to remove logic for rule version comparisons
* added integration tag to new rule
* adjusted rules updated_date value
* ignore guided onboarding rule in unit tests
* added integration tag to new rule
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* initial commit with rule changes
* removed rule from version lock file to pass unit testing; adjusted rule file name
* adjusted maturity to development
* initial commit with changes to new terms validation
* adjusted validation to call KQLValidator for flattened ECS variable
* changed call to KQLValidator instead of super; validate from same variable
* removed testing rules
* removed commented line
* Version() called on all string versions prior to comparison logic
* adjusted assert error punctuation
* [Rule Tuning] Multiple Alerts in Different ATT&CK Tactics on a Single Host
* Update non-ecs-schema.json
* Remove duplicated value on non-ecs-schema.json
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* adding support new_terms_fields and window_start_history
* adjusted rule.py to address flake errors
* added assertion error if history_window_start does not exist
* removed sample rule
* removed self.rule_id from DataValidator
* added new_terms to RuleType
* changed new terms to its own class in rule.py
* removed nonexisting function call in DataValidator class
* adjusted new_terms field value in dataclass
* changed literal type for history_window_start; view-rule working
* removing test TOML rule
* addressed flake errors for missing newlines
* added validation option and adjusted object referencing
* adjusted validation method call in post_validation
* addressed flake errors for multiple spaces
* added transform method to NewTermsRuleData class
* added validation for min stack version and new terms array length restraints
* added validation for unique new terms array
* Update detection_rules/rule.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* removed historywindowstart definition and adjusted subclass
* removed test rule from commit
* adjusted if/else for data transform method check
* adjusted stack-schema-map; validation method name
* Update detection_rules/rule.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* added assertion for history_window_start field value
* added variables for feature min stack and extended field min stack
* Update detection_rules/rule.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* Update detection_rules/rule.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* addressed flake errors for continuation line with same indent
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* [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
* addresses version comparison bug for related_integrations field during build
* Update detection_rules/misc.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* Update detection_rules/misc.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* Update detection_rules/integrations.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* addressed package version loading bug
* addressed flake errors
* adjusted find_least_compatible_version function to address sorting and semantic version comparison
* adjusted major version comparison in compare_versions sub function
* removed compare_versions sub function and included logic in iteration
* Update detection_rules/integrations.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* Update detection_rules/integrations.py
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* added OrderedDict to version and manifest iteration to enforce sorted dict object
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* added unit test for duplicate rule names
* adjusted macos file name and updated date values
* removed unit test and added assertion error in rule loader
* addressed flake errors
* addressed flake errors
* Update rules/linux/credential_access_potential_linux_ssh_bruteforce.toml
* [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>
* Add test command to verify version collisions do not occur
* add max_allowable_version to schema and lock flow
* add max_allowable_version to all entries in version.lock
* add test-version-lock command
* use min supported stack if > locked min stack
* share lock conversion code with rule and lock to fix M.m bug
* Cleanup rule survey code
* default to only unique-ing on process name for lucene rules
* fix bug in kibana url parsing by removing redundant port from domain
* update search-alerts columns and nest fields
* fix rule.contents.data.index
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* add test that newly introduced build-time fields for a min_stack for applicable rules.
* account for rules without min_stack_version
* limit test to >= stack ver
Samirbous