Docker — CraftedSignal Threat Feed

Kerberos Traffic from Unusual Process

hello@craftedsignal.io — Wed, 03 Jan 2024 14:00:00 +0000

This detection identifies unusual processes initiating network connections to the standard Kerberos port (88) on Windows systems. Typically, the lsass.exe process handles Kerberos traffic on domain-joined hosts. The rule aims to detect processes other than lsass.exe communicating with the Kerberos port, which could indicate malicious activity such as Kerberoasting (T1558.003) or Pass-the-Ticket (T1550.003). The detection is designed to work with data from Elastic Defend and SentinelOne Cloud Funnel. This can help security teams identify potential credential access attempts and lateral movement within the network.

Attack Chain

An attacker compromises a user account or system within the domain.
The attacker executes a malicious binary or script (e.g., PowerShell) on the compromised system.
The malicious process attempts to request Kerberos service tickets (TGS) for various services within the domain. This is done by connecting to the Kerberos port (88) on a domain controller.
The attacker uses tools like Rubeus or Kerberoast.ps1 to enumerate and request TGS tickets.
The unusual process (not lsass.exe) sends Kerberos traffic to the domain controller.
The attacker extracts the Kerberos tickets from memory or network traffic.
The attacker cracks the offline TGS tickets to obtain service account passwords (Kerberoasting).
The attacker uses the compromised service account credentials to move laterally within the network or access sensitive data.

Impact

A successful Kerberoasting or Pass-the-Ticket attack can lead to unauthorized access to sensitive resources and lateral movement within the network. Attackers can compromise service accounts with elevated privileges, potentially leading to domain-wide compromise. Detection of this behavior can prevent attackers from gaining access to critical assets. While the exact number of victims and sectors targeted are unknown, this technique is widely used by various threat actors in targeted attacks.

Recommendation

Deploy the “Kerberos Traffic from Unusual Process” Sigma rule to your SIEM and tune for your environment. Enable network connection logging to capture the necessary traffic.
Investigate any alerts triggered by the Sigma rule, focusing on the process execution chain and potential malicious binaries.
Review event ID 4769 for suspicious ticket requests as mentioned in the rule’s documentation.
Examine host services for suspicious entries as outlined in the original Elastic detection rule using Osquery.
Monitor for processes connecting to port 88, filtering out legitimate Kerberos clients like lsass.exe, using the “Detect Kerberos Traffic from Non-Standard Process” Sigma rule.
Investigate processes identified by the rule and compare them to the list of legitimate processes to identify unauthorized connections to the Kerberos port.

Unusual Process Connecting to Docker or Containerd Socket

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This threat involves unauthorized processes connecting directly to container runtime sockets (Docker or Containerd) on Linux systems. This bypasses Kubernetes API server restrictions, potentially allowing attackers to create, execute, or manipulate containers without proper authorization or logging. The risk lies in attackers circumventing RBAC, admission webhooks, and pod security standards. The attack can start when a compromised process attempts to connect to the Docker or Containerd socket, potentially leading to privilege escalation and lateral movement within the containerized environment. This attack is significant because it undermines core security controls within container orchestration platforms.

Attack Chain

A malicious or compromised process gains initial access to the host system.
The process attempts to connect to the container runtime socket (e.g., /var/run/docker.sock or /run/containerd/containerd.sock).
The process bypasses the Kubernetes API server and associated security controls.
The attacker exploits the direct socket connection to create a new container.
The attacker gains access to sensitive data or resources within the container.
The attacker escalates privileges within the compromised container.
The attacker uses the compromised container to move laterally to other containers or hosts within the environment.
The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation allows attackers to bypass Kubernetes security measures, create unauthorized containers, and potentially gain control over the entire cluster. The observed impact includes privilege escalation, lateral movement, and data exfiltration. The severity of this attack depends on the level of access granted to the compromised container and the sensitivity of the data and resources within the cluster.

Recommendation

Enable Auditd Manager to capture network and socket events, specifically monitoring for connect calls to Unix sockets as described in the Auditd Manager documentation.
Deploy the Sigma rule “Unusual Process Connecting to Docker or Containerd Socket” to detect suspicious processes connecting to container runtime sockets, tuning process.executable and user.name for known legitimate processes.
Monitor file permissions on the socket paths (/var/run/docker.sock, /run/docker.sock, /var/run/containerd/containerd.sock, /run/containerd/containerd.sock) and restrict access to trusted groups only.

Suspicious Process Accessing Sensitive Identity Files via Auditd

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This detection focuses on identifying unauthorized access to sensitive identity files on Linux systems. It leverages Auditd to monitor file access events and flags processes that are commonly used for copying, scripting, or staging files from temporary directories. The targeted files include Kubernetes service account tokens, kubelet configurations, cloud CLI configurations for AWS, Azure, and Google Cloud, root SSH keys, and Docker configurations. These files are critical for authentication and authorization within the system, and unauthorized access could lead to credential theft, privilege escalation, or lateral movement. This is especially important in cloud environments and containerized deployments where these files are commonly used for managing access to resources. The rule is designed to exclude user home paths to avoid false positives and focus on system-level access.

Attack Chain

An attacker gains initial access to a Linux system through various means, such as exploiting a vulnerability or compromising credentials.
The attacker uses a utility like cp, cat, or curl to access sensitive files such as /var/run/secrets/kubernetes.io/serviceaccount/token or /root/.ssh/id_rsa.
Auditd logs the file access event, capturing details about the process, user, and file path.
The detection rule identifies the suspicious process based on its name, executable path (e.g., /tmp/*), or command-line arguments.
The rule checks if the accessed file is in the list of sensitive identity files.
If both conditions are met, the rule triggers an alert, indicating potential unauthorized access to sensitive credentials.
The attacker exfiltrates the stolen credentials or uses them to move laterally within the network.
The attacker uses the stolen credentials to access cloud resources or other sensitive systems.

Impact

Successful exploitation can lead to the compromise of sensitive credentials, allowing attackers to gain unauthorized access to critical systems and data. This can result in data breaches, service disruptions, and financial losses. The targeted files contain credentials for Kubernetes clusters, cloud environments (AWS, Azure, Google Cloud), and SSH keys, potentially impacting a wide range of resources. The impact is particularly severe in environments where these credentials are used for managing critical infrastructure or accessing sensitive data.

Recommendation

Deploy the Auditd Manager integration with the specified audit rules in the provided setup steps to monitor access to sensitive identity files on Linux systems. Ensure auditd is properly configured and running (auditctl -l) to generate the necessary logs.
Deploy the Sigma rules provided to detect suspicious processes accessing sensitive identity files and tune them for your environment by excluding legitimate processes or users as needed.
Investigate alerts generated by the Sigma rules, focusing on the process name, executable, parent command line, and the accessed file path to determine the legitimacy of the access.
Review and harden file permissions on shared credential stores to prevent unauthorized access. Rotate exposed keys and tokens and invalidate cloud sessions if a compromise is suspected, as suggested in the rule’s documentation.

Ingress Transfer via Windows BITS

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The Windows Background Intelligent Transfer Service (BITS) is a legitimate Windows service that allows for prioritized, asynchronous, and throttled transfer of files between a client and a server. Adversaries abuse BITS to download malicious payloads while evading typical security protections, as file transfers occur in the context of the svchost.exe process. This activity can obscure the origin of the download and bypass application whitelisting rules. This detection focuses on identifying file rename events where svchost.exe renames temporary BITS files (BIT*.tmp) to executable or archive file types, indicating a potential malicious download via BITS. This technique is commonly employed to deliver malware, exfiltrate data, or download additional tools.

Attack Chain

An attacker gains initial access to a system (e.g., through phishing or exploiting a vulnerability).
The attacker uses a script or command-line interface (e.g., PowerShell) to create a BITS job.
The BITS job is configured to download a malicious executable or archive from a remote server using the bitsadmin.exe utility.
BITS downloads the file to a temporary location on the system with a BIT*.tmp extension.
The svchost.exe process renames the temporary file to its final name and extension (e.g., .exe, .zip).
The attacker executes the downloaded file, initiating further malicious activities.
The malware establishes persistence through registry keys or scheduled tasks.
The malware communicates with a command and control (C2) server to receive instructions and exfiltrate data.

Impact

Successful exploitation enables attackers to download and execute arbitrary code on compromised systems. The use of BITS can bypass traditional security measures, leading to malware infections, data theft, and potentially full system compromise. This technique can be used in conjunction with other attack vectors to establish a persistent foothold within the network. While the rule itself triggers at low severity, the identified activity can be an early warning of more severe attack stages.

Recommendation

Deploy the “Ingress Transfer via Windows BITS” Sigma rule to your SIEM and tune for your environment.
Enable Sysmon file creation and process creation logging to enhance visibility into BITS-related activities.
Monitor network connections initiated by svchost.exe to identify potentially malicious downloads.
Investigate any instances of bitsadmin.exe being executed, especially with command-line arguments indicative of suspicious downloads.
Review Microsoft-Windows-Bits-Client/Operational Windows logs (event ID 59) for unusual BITS events.
Block known malicious domains or IP addresses associated with BITS-related attacks at the firewall or DNS resolver.