<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Audit-Logs - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/audit-logs/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 31 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/audit-logs/feed.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes Unusual Decision by User Agent</title><link>https://feed.craftedsignal.io/briefs/2024-01-kubernetes-unusual-user-agent/</link><pubDate>Wed, 31 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-kubernetes-unusual-user-agent/</guid><description>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.</description><content:encoded><![CDATA[<p>This 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 &quot;new_terms&quot; rule type, focusing on deviations from expected API request patterns typically made by system components or trusted users. By monitoring discrepancies in the <code>user_agent.original</code>, <code>kubernetes.audit.user.username</code>, and <code>kubernetes.audit.annotations.authorization_k8s_io/decision</code> 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Initial Access: An attacker gains initial access to the Kubernetes cluster through compromised credentials or a vulnerable application.</li>
<li>Privilege Escalation: The attacker attempts to escalate privileges within the cluster, potentially using a service account with excessive permissions.</li>
<li>Discovery: The attacker performs reconnaissance activities to map out the cluster's resources, including pods, services, and secrets. They use <code>kubectl</code> or similar tools to query the API server.</li>
<li>Lateral Movement: Using the compromised credentials, the attacker moves laterally within the cluster, accessing different namespaces or nodes.</li>
<li>Execution: 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.</li>
<li>Persistence: The attacker establishes persistence by creating a new service account with elevated privileges or by modifying existing deployments to include backdoors.</li>
<li>Exfiltration (Potential): The attacker attempts to exfiltrate sensitive data from the cluster, such as secrets or configuration files.</li>
<li>Impact: The attacker achieves their objectives, which could include data theft, denial of service, or complete control of the Kubernetes cluster.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the provided Sigma rule to your SIEM to detect unusual Kubernetes API requests based on user agent (see the rule section).</li>
<li>Regularly review Kubernetes audit logs for unusual <code>user_agent.original</code> values, and correlate them with other security events.</li>
<li>Implement strict role-based access control (RBAC) policies to minimize the attack surface.</li>
<li>Configure monitoring and alerting for suspicious activity within the Kubernetes cluster.</li>
<li>Tune the Sigma rule exceptions to account for legitimate but infrequent user agents (see the rule's false positive analysis section).</li>
</ul>
]]></content:encoded><category domain="severity">low</category><category domain="type">advisory</category><category>kubernetes</category><category>audit-logs</category><category>threat-detection</category></item><item><title>GitHub Enterprise Audit Log Streaming Disabled</title><link>https://feed.craftedsignal.io/briefs/2024-01-github-audit-disable/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-github-audit-disable/</guid><description>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.</description><content:encoded><![CDATA[<p>This 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li><strong>Initial Access:</strong> An attacker gains unauthorized access to a GitHub Enterprise account with administrative privileges.</li>
<li><strong>Privilege Escalation (If Necessary):</strong> If the initial access does not grant sufficient privileges, the attacker attempts to escalate their privileges within the GitHub Enterprise environment.</li>
<li><strong>Identify Audit Log Configuration:</strong> The attacker identifies the audit log event streaming configuration settings within GitHub Enterprise.</li>
<li><strong>Disable Audit Log Streaming:</strong> 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 <code>audit_log_streaming.destroy</code> action.</li>
<li><strong>Carry out Malicious Actions:</strong> 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.</li>
<li><strong>Maintain Persistence:</strong> The attacker establishes persistence mechanisms to maintain access to the compromised GitHub Enterprise environment.</li>
<li><strong>Cover Tracks:</strong> The attacker attempts to further cover their tracks by deleting logs or modifying system configurations.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Disabling 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule <code>GitHub Audit Log Streaming Disabled</code> to your SIEM to detect when a user disables audit log event streaming in GitHub Enterprise.</li>
<li>Enable and actively monitor GitHub Enterprise audit logs using Audit log streaming as described in the documentation (<a 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">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</a>).</li>
<li>Investigate any instances of <code>audit_log_streaming.destroy</code> events identified in the logs to determine if they are authorized or malicious activity.</li>
<li>Review user access controls and permissions within GitHub Enterprise to prevent unauthorized users from disabling audit log streaming.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>github</category><category>audit-logs</category><category>defense-evasion</category><category>cloud</category></item></channel></rss>