{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/audit-logs/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Kubernetes"],"_cs_severities":["low"],"_cs_tags":["kubernetes","audit-logs","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Kubernetes"],"content_html":"\u003cp\u003eThis detection rule identifies unusual request responses within Kubernetes environments by analyzing audit logs for anomalies in user agents and response annotations. The rule leverages the \u0026quot;new_terms\u0026quot; rule type, focusing on deviations from expected API request patterns typically made by system components or trusted users. By monitoring discrepancies in the \u003ccode\u003euser_agent.original\u003c/code\u003e, \u003ccode\u003ekubernetes.audit.user.username\u003c/code\u003e, and \u003ccode\u003ekubernetes.audit.annotations.authorization_k8s_io/decision\u003c/code\u003e fields, the rule aims to uncover potential unauthorized access attempts, misconfigured permissions, or malicious activities exploiting atypical user agent strings. This approach enhances the security posture of Kubernetes clusters by detecting subtle indicators of compromise that might otherwise go unnoticed. The rule is intended to be deployed in production environments where consistent user agent behavior is expected from trusted sources.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains initial access to the Kubernetes cluster through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker attempts to escalate privileges within the cluster, potentially using a service account with excessive permissions.\u003c/li\u003e\n\u003cli\u003eDiscovery: The attacker performs reconnaissance activities to map out the cluster's resources, including pods, services, and secrets. They use \u003ccode\u003ekubectl\u003c/code\u003e or similar tools to query the API server.\u003c/li\u003e\n\u003cli\u003eLateral Movement: Using the compromised credentials, the attacker moves laterally within the cluster, accessing different namespaces or nodes.\u003c/li\u003e\n\u003cli\u003eExecution: The attacker executes malicious code within a pod or container, potentially deploying a reverse shell or a cryptominer. This is achieved by sending API requests to create or modify resources.\u003c/li\u003e\n\u003cli\u003ePersistence: The attacker establishes persistence by creating a new service account with elevated privileges or by modifying existing deployments to include backdoors.\u003c/li\u003e\n\u003cli\u003eExfiltration (Potential): The attacker attempts to exfiltrate sensitive data from the cluster, such as secrets or configuration files.\u003c/li\u003e\n\u003cli\u003eImpact: The attacker achieves their objectives, which could include data theft, denial of service, or complete control of the Kubernetes cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack could lead to unauthorized access to sensitive data, disruption of services, or complete compromise of the Kubernetes cluster. While the rule itself has a low severity, the underlying activities it detects can have severe consequences. The number of potential victims depends on the scope and criticality of the affected Kubernetes deployments. If exploited, attackers can gain control of containerized applications and infrastructure, leading to data breaches, financial losses, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unusual Kubernetes API requests based on user agent (see the rule section).\u003c/li\u003e\n\u003cli\u003eRegularly review Kubernetes audit logs for unusual \u003ccode\u003euser_agent.original\u003c/code\u003e values, and correlate them with other security events.\u003c/li\u003e\n\u003cli\u003eImplement strict role-based access control (RBAC) policies to minimize the attack surface.\u003c/li\u003e\n\u003cli\u003eConfigure monitoring and alerting for suspicious activity within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eTune the Sigma rule exceptions to account for legitimate but infrequent user agents (see the rule's false positive analysis section).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-31T12:00:00Z","date_published":"2024-01-31T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-unusual-user-agent/","summary":"This rule detects unusual request responses in Kubernetes audit logs by monitoring for anomalies in username and response annotations, potentially identifying unauthorized access or misconfigurations.","title":"Kubernetes Unusual Decision by User Agent","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-unusual-user-agent/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["GitHub Enterprise"],"_cs_severities":["high"],"_cs_tags":["github","audit-logs","defense-evasion","cloud"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis threat brief focuses on the disabling of audit log event streaming within GitHub Enterprise environments. The disabling of audit logs is a common technique used by attackers to evade detection by security monitoring platforms. While the exact initial access vector is unknown, once an attacker gains sufficient privileges within the GitHub Enterprise environment, they may attempt to disable audit logging to mask their subsequent actions. This activity is significant for defenders because it represents a deliberate attempt to blind security monitoring and incident response teams, potentially allowing attackers to perform malicious activities without detection. The impact could be severe as organizations lose visibility into user actions, configuration changes, and security events within their GitHub Enterprise environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains unauthorized access to a GitHub Enterprise account with administrative privileges.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (If Necessary):\u003c/strong\u003e If the initial access does not grant sufficient privileges, the attacker attempts to escalate their privileges within the GitHub Enterprise environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIdentify Audit Log Configuration:\u003c/strong\u003e The attacker identifies the audit log event streaming configuration settings within GitHub Enterprise.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDisable Audit Log Streaming:\u003c/strong\u003e The attacker disables the audit log event streaming functionality, preventing audit events from being sent to security monitoring platforms. This is achieved by using the \u003ccode\u003eaudit_log_streaming.destroy\u003c/code\u003e action.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCarry out Malicious Actions:\u003c/strong\u003e With audit logging disabled, the attacker performs unauthorized activities within the GitHub Enterprise environment, such as modifying code, creating new user accounts, or exfiltrating sensitive data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMaintain Persistence:\u003c/strong\u003e The attacker establishes persistence mechanisms to maintain access to the compromised GitHub Enterprise environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCover Tracks:\u003c/strong\u003e The attacker attempts to further cover their tracks by deleting logs or modifying system configurations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling audit log streaming in GitHub Enterprise can have significant consequences. Organizations lose visibility into critical security events, configuration changes, and user actions within their GitHub Enterprise environment. This can enable attackers to perform malicious activities undetected, leading to data breaches, intellectual property theft, or disruption of services. The inability to monitor audit logs hinders incident response efforts and prolongs the time it takes to detect and remediate security incidents.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGitHub Audit Log Streaming Disabled\u003c/code\u003e to your SIEM to detect when a user disables audit log event streaming in GitHub Enterprise.\u003c/li\u003e\n\u003cli\u003eEnable and actively monitor GitHub Enterprise audit logs using Audit log streaming as described in the documentation (\u003ca href=\"https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise#setting-up-streaming-to-splunk\"\u003ehttps://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise#setting-up-streaming-to-splunk\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of \u003ccode\u003eaudit_log_streaming.destroy\u003c/code\u003e events identified in the logs to determine if they are authorized or malicious activity.\u003c/li\u003e\n\u003cli\u003eReview user access controls and permissions within GitHub Enterprise to prevent unauthorized users from disabling audit log streaming.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-github-audit-disable/","summary":"A user disabling audit log event streaming in GitHub Enterprise could indicate an attacker attempting to prevent their malicious activities from being logged and detected.","title":"GitHub Enterprise Audit Log Streaming Disabled","url":"https://feed.craftedsignal.io/briefs/2024-01-github-audit-disable/"}],"language":"en","title":"CraftedSignal Threat Feed - Audit-Logs","version":"https://jsonfeed.org/version/1.1"}