Oracle — CraftedSignal Threat Feed

Multi-Cloud CLI Token and Credential Access via Command-Line Harvesting

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

This threat brief focuses on detecting command-line credential harvesting across multiple cloud platforms. Attackers may attempt to steal application access tokens or extract credentials from files by executing specific commands via command-line interfaces (CLIs) for GCP, Azure, AWS, GitHub, DigitalOcean, Oracle, and Kubernetes. This activity is particularly concerning when originating from the same host within a short time frame (e.g., five minutes), potentially indicating automated credential theft. This technique can lead to unauthorized access to cloud resources, data breaches, and lateral movement within cloud environments. Defenders should monitor for suspicious command-line activity involving cloud CLIs and credential access patterns.

Attack Chain

An attacker gains initial access to a system, possibly via compromised credentials or exploiting a vulnerability.
The attacker uses a shell (cmd.exe, PowerShell, bash, etc.) to execute cloud CLI commands.
The attacker executes commands to list available credentials or tokens (e.g., aws configure list, az account list, kubectl config view).
The attacker executes commands to print access tokens for various cloud providers (e.g., gcloud auth print-access-token, az account get-access-token, gh auth token).
The attacker uses credential harvesting commands across multiple cloud platforms within a short timeframe.
The attacker exfiltrates the harvested credentials to a remote location.
The attacker uses the stolen credentials to access sensitive cloud resources and data.
The attacker performs lateral movement within the cloud environment.

Impact

A successful attack can lead to unauthorized access to sensitive cloud resources, data breaches, and lateral movement within cloud environments. The impact includes potential data exfiltration, service disruption, and financial loss. The number of affected victims will depend on the scope of the compromised credentials and the attacker’s ability to exploit them.

Recommendation

Deploy the Sigma rule “Multi-Cloud CLI Token and Credential Access Commands” to your SIEM to detect suspicious command-line activity related to cloud credential harvesting.
Review Esql.process_command_line_values in the rule output to identify the exact commands executed and determine if the activity was legitimate or malicious.
Correlate the detected activity with authentication, Kubernetes audit, and cloud API logs to confirm unauthorized access and misuse of printed tokens.
Implement monitoring and alerting for unusual CLI activity originating from user workstations or build servers, focusing on the CLIs mentioned in the Overview section.
Follow vendor-specific guidance to revoke compromised credentials, such as revoking tokens and rotating secrets, as outlined in the rule’s “Response and remediation” section.

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.

Suspicious LSASS Process Access

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

The Local Security Authority Subsystem Service (LSASS) is a critical Windows component responsible for enforcing security policies and handling user authentication. Attackers often target LSASS to extract credentials, enabling unauthorized access and privilege escalation. This detection rule identifies suspicious access attempts to LSASS memory, which may indicate credential dumping activities. It filters out common legitimate processes and access patterns to highlight anomalous behaviors associated with credential theft. The rule is designed to detect unauthorized access attempts by monitoring process access events and filtering out known benign processes that interact with LSASS. It helps defenders identify potential credential access attempts before they lead to significant compromise.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploitation of a vulnerability.
The attacker executes a malicious process or script on the compromised system.
The malicious process attempts to gain a handle to the LSASS process.
The attacker’s tool requests specific access rights to LSASS, such as ReadProcessMemory (0x0010) or PROCESS_QUERY_INFORMATION (0x0400), which are necessary for memory dumping.
The attacker’s process bypasses or disables endpoint detection and response (EDR) solutions to avoid detection.
The tool dumps the LSASS memory, extracting sensitive information like usernames, passwords, and Kerberos tickets.
The attacker uses the extracted credentials to move laterally within the network, accessing other systems and resources.
The attacker achieves their objective, such as data exfiltration or deployment of ransomware.

Impact

A successful LSASS memory dump can lead to the compromise of domain credentials, allowing attackers to move laterally within the network and gain access to sensitive data and systems. This can result in data breaches, financial loss, and reputational damage. Organizations across all sectors are vulnerable, particularly those with weak credential management practices. A single compromised account can lead to widespread damage, potentially affecting thousands of systems.

Recommendation

Enable Sysmon process access event logging (Event ID 10) as described in the setup instructions linked in the rule to collect the necessary data.
Deploy the Sigma rule “Suspicious Lsass Process Access” to your SIEM and tune the exclusions based on your environment to reduce false positives.
Review and harden privileged account management practices to limit the impact of credential compromise.
Monitor systems for unusual process creation events, especially those spawning from unexpected locations, to identify potential initial access points.
Regularly scan systems for vulnerabilities and apply patches to prevent exploitation.