You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: rules/integrations/kubernetes/execution_unusual_request_response_by_user_agent.toml
+38-2Lines changed: 38 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
creation_date = "2025/06/18"
3
3
integration = ["kubernetes"]
4
4
maturity = "production"
5
-
updated_date = "2025/06/18"
5
+
updated_date = "2025/07/21"
6
6
7
7
[rule]
8
8
author = ["Elastic"]
@@ -18,6 +18,41 @@ index = ["logs-kubernetes.audit_logs-*"]
18
18
language = "kuery"
19
19
license = "Elastic License v2"
20
20
name = "Kubernetes Unusual Decision by User Agent"
21
+
note = """## Triage and analysis
22
+
23
+
> **Disclaimer**:
24
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
25
+
26
+
### Investigating Kubernetes Unusual Decision by User Agent
27
+
28
+
Kubernetes orchestrates containerized applications, relying on API requests for operations. Typically, these requests originate from system components or trusted users with consistent user agents. Adversaries might exploit this by using atypical user agents to mask unauthorized access or misconfigurations. The detection rule identifies anomalies in user agents and response annotations, signaling potential threats in the Kubernetes environment.
29
+
30
+
### Possible investigation steps
31
+
32
+
- Review the Kubernetes audit logs for entries where the user_agent.original field is present to identify any unusual or unexpected user agents.
33
+
- Cross-reference the identified user agents with known system components and trusted users to determine if the user agent is legitimate or potentially malicious.
34
+
- Examine the kubernetes.audit.stage field for "ResponseComplete" entries to understand the context and outcome of the requests associated with the unusual user agent.
35
+
- Investigate the source IP addresses and associated usernames in the audit logs to identify any patterns or anomalies that could indicate unauthorized access.
36
+
- Check for any recent changes or deployments in the Kubernetes environment that might explain the presence of unusual user agents or unexpected behavior.
37
+
- Assess the risk and impact of the detected anomaly by considering the sensitivity of the accessed resources and the permissions associated with the user account involved.
38
+
39
+
### False positive analysis
40
+
41
+
- System components or trusted users with legitimate but infrequent user agents may trigger the rule. To manage this, identify these user agents and add them to an exception list to prevent unnecessary alerts.
42
+
- Automated scripts or tools used for maintenance or monitoring might use unique user agents. Regularly review these tools and update the exception list to include their user agents if they are verified as non-threatening.
43
+
- New deployments or updates to Kubernetes components can introduce new user agents temporarily. Monitor these changes and adjust the rule exceptions accordingly to accommodate expected behavior during these periods.
44
+
- Third-party integrations or plugins may use distinct user agents. Validate these integrations and, if deemed safe, include their user agents in the exception list to reduce false positives.
45
+
46
+
### Response and remediation
47
+
48
+
- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary.
49
+
- Review and terminate any suspicious or unauthorized sessions identified in the audit logs to cut off any active malicious activity.
50
+
- Revoke and rotate credentials associated with the compromised user agent to prevent further unauthorized access using the same credentials.
51
+
- Conduct a thorough review of the affected system's configurations and permissions to identify and rectify any misconfigurations or overly permissive access controls.
52
+
- Implement additional monitoring and logging for the affected systems to detect any further anomalies or unauthorized activities promptly.
53
+
- Escalate the incident to the security operations team for a comprehensive investigation and to determine if any data exfiltration or further compromise has occurred.
54
+
- Update and enhance detection rules and alerts to better identify similar anomalies in user agents and response annotations in the future, ensuring quicker response times.
name = "Potential Impersonation Attempt via Kubectl"
28
+
note = """## Triage and analysis
29
+
30
+
> **Disclaimer**:
31
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
32
+
33
+
### Investigating Potential Impersonation Attempt via Kubectl
34
+
35
+
Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit kubectl by using specific arguments to impersonate users, gaining unauthorized access or escalating privileges. The detection rule identifies suspicious kubectl executions, focusing on arguments that suggest impersonation, such as those related to user identity and authentication, to flag potential misuse.
36
+
37
+
### Possible investigation steps
38
+
39
+
- Review the process arguments to confirm the presence of impersonation-related flags such as "--kubeconfig", "--token", "--as", "--as-group", or "--as-uid" to understand the scope of the impersonation attempt.
40
+
- Examine the parent process name and executable path to determine if the kubectl command was initiated from a suspicious location or script, such as "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", or "/home/*".
41
+
- Check the user account associated with the kubectl execution to assess whether it aligns with expected usage patterns or if it indicates potential unauthorized access.
42
+
- Investigate related alerts or logs for secret access or kubeconfig file discovery to identify if there is a broader pattern of suspicious activity that could indicate a coordinated impersonation attempt.
43
+
- Analyze the network activity associated with the kubectl execution to identify any unusual connections or data transfers that may suggest unauthorized access or data exfiltration.
44
+
45
+
### False positive analysis
46
+
47
+
- Legitimate administrative tasks: System administrators may use kubectl with impersonation arguments for legitimate purposes such as testing permissions or managing resources on behalf of other users. To handle this, create exceptions for known administrative accounts or specific IP addresses.
48
+
- Automation scripts: Automated scripts or CI/CD pipelines might use impersonation arguments to perform tasks across different environments. Review and whitelist these scripts by identifying their unique execution patterns or specific user accounts.
49
+
- Development and testing environments: Developers might use impersonation features in non-production environments for testing purposes. Exclude these environments by filtering based on environment-specific identifiers or network segments.
50
+
- Security tools: Some security tools or monitoring solutions may use impersonation arguments to audit or verify access controls. Identify these tools and exclude their processes by recognizing their signatures or execution paths.
51
+
- Frequent legitimate use cases: If certain teams or departments regularly use impersonation for valid reasons, consider creating role-based exceptions to reduce noise while maintaining security oversight.
52
+
53
+
### Response and remediation
54
+
55
+
- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or privilege escalation.
56
+
- Revoke any potentially compromised credentials, such as tokens or kubeconfig files, and issue new ones with updated security policies.
57
+
- Review and audit the Kubernetes RBAC (Role-Based Access Control) settings to ensure that only authorized users have the necessary permissions, and adjust roles and permissions as needed to minimize privilege escalation risks.
58
+
- Conduct a thorough investigation of the affected systems to identify any unauthorized changes or deployments made by the adversary, and roll back any malicious or suspicious configurations.
59
+
- Monitor for any further suspicious kubectl activity, especially those involving impersonation arguments, and set up alerts for any similar future attempts.
60
+
- Escalate the incident to the security operations team for a comprehensive review and to determine if additional security measures or incident response actions are required.
61
+
- Implement additional logging and monitoring for kubectl commands and Kubernetes API interactions to enhance detection capabilities for similar threats in the future.
Copy file name to clipboardExpand all lines: rules/linux/defense_evasion_unsual_kill_signal.toml
+38-2Lines changed: 38 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
creation_date = "2025/07/16"
3
3
integration = ["auditd_manager"]
4
4
maturity = "production"
5
-
updated_date = "2025/07/16"
5
+
updated_date = "2025/07/21"
6
6
7
7
[rule]
8
8
author = ["Elastic"]
@@ -16,6 +16,41 @@ index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
16
16
language = "eql"
17
17
license = "Elastic License v2"
18
18
name = "Unusual Kill Signal"
19
+
note = """## Triage and analysis
20
+
21
+
> **Disclaimer**:
22
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
23
+
24
+
### Investigating Unusual Kill Signal
25
+
26
+
In Linux environments, kill signals are used to manage process lifecycles. Signals in the range of 32-64 are less common and can be exploited by adversaries, such as rootkits, to manipulate processes stealthily, potentially leading to privilege escalation or evasion of security measures. The 'Unusual Kill Signal' detection rule identifies these rare signals, flagging potential misuse by monitoring specific syscall activities, thus aiding in early threat detection.
27
+
28
+
### Possible investigation steps
29
+
30
+
- Review the process details associated with the alert, focusing on the process name, PID, and parent process to understand the context of the kill signal usage.
31
+
- Examine the user account under which the process was executed to determine if it aligns with expected behavior or if it indicates potential unauthorized access.
32
+
- Investigate the command line arguments and environment variables of the process to identify any suspicious or unusual commands that may suggest malicious activity.
33
+
- Check the system logs around the time of the alert for any related events or anomalies that could provide additional context or indicate a broader attack pattern.
34
+
- Correlate the alert with other security events or alerts from the same host to identify if this is part of a larger attack or if there are other indicators of compromise.
35
+
- Assess the network activity of the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.
36
+
37
+
### False positive analysis
38
+
39
+
- Legitimate applications or services may use signals in the 32-64 range for custom inter-process communication, leading to false positives. Identify these applications and create exceptions for their specific processes.
40
+
- Some system monitoring or management tools might utilize these signals for legitimate process management tasks. Review the tools in use and whitelist their activities if they are verified as non-threatening.
41
+
- Development environments or testing frameworks might employ unusual signals for debugging or testing purposes. Ensure these environments are properly isolated and exclude their activities from triggering alerts.
42
+
- Custom scripts or automation tasks could be configured to use these signals for specific operations. Audit these scripts and, if deemed safe, add them to an exception list to prevent unnecessary alerts.
43
+
44
+
### Response and remediation
45
+
46
+
- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
47
+
- Terminate any suspicious processes identified with unusual kill signals in the range of 32-64 to halt any ongoing malicious activity.
48
+
- Conduct a thorough forensic analysis of the affected system to identify any rootkits or malicious software that may have been installed, focusing on the processes and files associated with the unusual kill signals.
49
+
- Restore the system from a known good backup if rootkit presence is confirmed, ensuring that the backup is free from any compromise.
50
+
- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
51
+
- Implement enhanced monitoring and logging for unusual kill signals and related activities to detect any future attempts at similar attacks.
52
+
- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to assess the need for broader organizational response measures.
0 commit comments