Terrance DeJesus
4312d8c958
* 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>
67 lines
2.5 KiB
TOML
67 lines
2.5 KiB
TOML
[metadata]
|
|
creation_date = "2022/05/17"
|
|
integration = ["kubernetes"]
|
|
maturity = "production"
|
|
min_stack_comments = "New fields added to Kubernetes Integration"
|
|
min_stack_version = "8.4.0"
|
|
updated_date = "2022/12/14"
|
|
|
|
[rule]
|
|
author = ["Elastic"]
|
|
description = """
|
|
This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec'
|
|
command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An
|
|
adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has
|
|
permissions to, including secrets.
|
|
"""
|
|
false_positives = [
|
|
"""
|
|
An administrator may need to exec into a pod for a legitimate reason like debugging purposes. Containers built from
|
|
Linux and Windows OS images, tend to include debugging utilities. In this case, an admin may choose to run commands
|
|
inside a specific container with kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ...
|
|
${ARGN}. For example, the following command can be used to look at logs from a running Cassandra pod: kubectl exec
|
|
cassandra --cat /var/log/cassandra/system.log . Additionally, the -i and -t arguments might be used to run a shell
|
|
connected to the terminal: kubectl exec -i -t cassandra -- sh
|
|
""",
|
|
]
|
|
index = ["logs-kubernetes.*"]
|
|
language = "kuery"
|
|
license = "Elastic License v2"
|
|
name = "Kubernetes User Exec into Pod"
|
|
note = """## Setup
|
|
|
|
The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
|
|
references = [
|
|
"https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/",
|
|
"https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/",
|
|
]
|
|
risk_score = 47
|
|
rule_id = "14de811c-d60f-11ec-9fd7-f661ea17fbce"
|
|
severity = "medium"
|
|
tags = ["Elastic", "Kubernetes", "Continuous Monitoring", "Execution"]
|
|
timestamp_override = "event.ingested"
|
|
type = "query"
|
|
|
|
query = '''
|
|
event.dataset : "kubernetes.audit_logs"
|
|
and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
|
|
and kubernetes.audit.verb:"create"
|
|
and kubernetes.audit.objectRef.resource:"pods"
|
|
and kubernetes.audit.objectRef.subresource:"exec"
|
|
'''
|
|
|
|
|
|
[[rule.threat]]
|
|
framework = "MITRE ATT&CK"
|
|
[[rule.threat.technique]]
|
|
id = "T1609"
|
|
name = "Container Administration Command"
|
|
reference = "https://attack.mitre.org/techniques/T1609/"
|
|
|
|
|
|
[rule.threat.tactic]
|
|
id = "TA0002"
|
|
name = "Execution"
|
|
reference = "https://attack.mitre.org/tactics/TA0002/"
|
|
|