Stealth — CraftedSignal Threat Feed

GitHub SSH Certificate Configuration Changed

hello@craftedsignal.io — Sat, 02 Nov 2024 14:00:00 +0000

Attackers can abuse SSH certificate authorities in GitHub to gain unauthorized access to repositories. By creating or disabling SSH certificate requirements, attackers can bypass existing security controls and establish persistent access. This activity is logged in the GitHub audit logs, specifically when ssh_certificate_authority.create or ssh_certificate_requirement.disable actions are performed. Successful exploitation allows attackers to commit malicious code, steal sensitive data, or disrupt development workflows, impacting the integrity and confidentiality of the organization’s resources. The GitHub audit log streaming feature must be enabled to detect this activity.

Attack Chain

Initial Compromise: An attacker gains initial access to a GitHub organization, potentially through compromised credentials or social engineering.
Privilege Escalation: The attacker escalates their privileges to an organizational role capable of managing SSH certificate authorities.
SSH Certificate Authority Creation: The attacker creates a new SSH certificate authority within the GitHub organization (ssh_certificate_authority.create).
Disable SSH Certificate Requirement: Alternatively, the attacker disables the requirement for members to use SSH certificates to access organization resources (ssh_certificate_requirement.disable). This action allows attackers to bypass security controls that enforce SSH certificate usage.
Unauthorized Access: The attacker utilizes the newly created SSH certificate authority or the disabled requirement to access repositories without proper authorization.
Lateral Movement: The attacker moves laterally within the GitHub organization, accessing additional repositories and resources.
Data Exfiltration/Malicious Code Injection: The attacker exfiltrates sensitive data or injects malicious code into the organization’s repositories.
Persistence: The attacker maintains persistent access by using the created SSH certificate authority or the disabled requirement for future unauthorized activities.

Impact

Successful modification of SSH certificate configurations in GitHub can lead to unauthorized code commits, data breaches, and supply chain attacks. This could result in financial losses, reputational damage, and legal repercussions for the affected organization. The number of affected repositories and the severity of the impact depend on the scope of the attacker’s access and the sensitivity of the compromised data.

Recommendation

Enable the GitHub audit log streaming feature to capture SSH certificate configuration changes (logsource: github, service: audit, definition).
Deploy the provided Sigma rule to detect ssh_certificate_authority.create or ssh_certificate_requirement.disable events in the GitHub audit logs (rule: Github SSH Certificate Configuration Changed).
Regularly review GitHub audit logs for any unauthorized modifications to SSH certificate configurations.

Kubernetes Event Deletion for Defense Evasion

hello@craftedsignal.io — Thu, 02 May 2024 12:00:00 +0000

Attackers targeting Kubernetes environments may attempt to delete Kubernetes events as a means of covering their tracks. This technique, often employed after successful exploitation or lateral movement, aims to eliminate audit logs and other traces of malicious activity. By removing these logs, attackers can significantly hinder incident response efforts and prolong the duration of their access. While the specifics of initial access will vary, this action will typically be performed using kubectl or similar tools with sufficient privileges within the Kubernetes cluster. Defenders need to monitor for unexpected deletion of event logs to identify potentially compromised systems.

Attack Chain

Initial compromise of a container or node within the Kubernetes cluster using an exploit (e.g., exploiting a vulnerability in a containerized application).
Establish persistence by creating a malicious pod or modifying existing deployments to include backdoors.
Escalate privileges within the cluster, potentially by exploiting misconfigured RBAC policies or vulnerable service accounts.
Identify Kubernetes event logs that contain evidence of the attacker’s activities, such as pod deployments, privilege escalation attempts, or network connections.
Use kubectl delete events command with appropriate privileges to remove targeted event logs from the Kubernetes audit logs.
Verify that the targeted event logs have been successfully removed from the cluster’s audit trail.
Continue lateral movement and data exfiltration, now with reduced risk of detection due to the deleted event logs.

Impact

Successful deletion of Kubernetes events allows attackers to operate within the cluster undetected for extended periods. This can lead to significant data breaches, system compromise, and disruption of services. The absence of event logs makes forensic investigation and incident response extremely challenging, potentially leading to inaccurate assessments of the scope and impact of the attack. While the exact number of victims is unknown, this technique, if successful, significantly amplifies the damage caused by any initial intrusion.

Recommendation

Deploy the Sigma rule “Kubernetes Events Deleted” to your SIEM to detect event deletion attempts in your Kubernetes environment (logsource: application, product: kubernetes, service: audit).
Review and harden RBAC policies to minimize the risk of unauthorized event deletion.
Implement strong audit logging practices and ensure that audit logs are securely stored and protected from tampering.

Suspicious AWS SAML Activity Detection

hello@craftedsignal.io — Wed, 03 Jan 2024 18:22:30 +0000

This detection identifies potentially malicious Security Assertion Markup Language (SAML) activity within Amazon Web Services (AWS). The activity includes monitoring for AssumeRoleWithSAML and UpdateSAMLProvider events. An adversary might exploit SAML to gain unauthorized access, escalate privileges, move laterally within the AWS environment, or establish persistent backdoor access. The focus is on detecting unusual or unauthorized modifications to SAML configurations and role assumptions, which could indicate a compromised identity provider or malicious actor leveraging SAML for illicit purposes. Defenders should prioritize monitoring SAML-related API calls to identify and mitigate potential threats early in the attack chain.

Attack Chain

The attacker compromises or creates a malicious SAML identity provider.
The attacker configures the AWS environment to trust the malicious SAML provider using UpdateSAMLProvider.
The attacker crafts a SAML assertion to assume a specific role within the AWS environment.
The attacker uses the AssumeRoleWithSAML API call to authenticate with AWS using the crafted SAML assertion.
AWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.
The attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.
The attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.
The attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.

Impact

Successful exploitation via SAML manipulation can lead to a complete compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious infrastructure. The impact includes potential data breaches, financial losses, and reputational damage. The number of affected resources depends on the permissions associated with the roles assumed by the attacker.

Recommendation

Deploy the Sigma rule for AssumeRoleWithSAML events to detect suspicious role assumptions (see “AssumeRoleWithSAML Detection Rule”).
Deploy the Sigma rule for UpdateSAMLProvider events to detect unauthorized SAML provider modifications (see “UpdateSAMLProvider Detection Rule”).
Investigate any AssumeRoleWithSAML events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.
Monitor UpdateSAMLProvider events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.
Tune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.

Azure AD User Password Reset Detection

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

This threat brief focuses on detecting user-initiated password resets within Azure Active Directory (Azure AD). While legitimate password resets are common, monitoring this activity can help identify potentially malicious behavior, such as an attacker attempting to gain unauthorized access to an account or an insider threat actor escalating privileges. Attackers may leverage compromised credentials or social engineering to initiate password resets, bypassing multi-factor authentication (MFA) if it is not properly configured or enforced. This detection is important for defenders because successful password resets can lead to a complete account takeover, allowing attackers to access sensitive data, resources, and systems.

Attack Chain

An attacker gains initial access to a user’s credentials through phishing, credential stuffing, or malware.
The attacker attempts to log in to an Azure AD-protected resource using the compromised credentials.
The attacker fails to authenticate, either because they do not have the correct password or MFA is enabled.
The attacker initiates a password reset request using the “Forgot password” feature or a similar mechanism.
Azure AD sends a password reset verification code or link to the user’s registered email address or phone number.
If the attacker controls the registered email address or phone number (due to prior compromise), they can access the verification code or link.
The attacker uses the verification code or link to set a new password for the user’s Azure AD account.
The attacker logs in to the Azure AD account with the new password, gaining unauthorized access.

Impact

Successful password resets by attackers can lead to complete account takeover, allowing them to access sensitive data, resources, and systems protected by Azure AD. This can result in data breaches, financial loss, reputational damage, and disruption of business operations. The impact depends on the privileges and permissions assigned to the compromised account.

Recommendation

Deploy the Sigma rule Password Reset By User Account to your SIEM to detect user-initiated password resets in Azure AD audit logs.
Investigate any detected password resets, especially those initiated by users who have not recently requested a password change.
Review and enforce multi-factor authentication (MFA) policies to prevent attackers from bypassing password-based authentication.
Monitor Azure AD audit logs for suspicious activity related to password resets, such as multiple failed login attempts followed by a successful reset.

Azure Service Principal Removal Detection

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

The removal of a service principal within an Azure environment can be indicative of various activities, ranging from legitimate administrative tasks to malicious actions undertaken by threat actors attempting to cover their tracks. While service principals are routinely removed as part of lifecycle management, unauthorized or unexpected removals should be investigated promptly. This detection focuses on identifying such removals through Azure Activity Logs, allowing security teams to quickly respond to potentially suspicious events.

Attack Chain

The attacker gains unauthorized access to an Azure account through compromised credentials or other means.
The attacker identifies a service principal used for malicious purposes or to maintain persistence.
The attacker attempts to remove the service principal to evade detection or disrupt incident response efforts.
The attacker executes the necessary commands or uses the Azure portal to initiate the service principal removal. This action is logged in the Azure Activity Logs.
The Azure Activity Logs record an event with the message “Remove service principal”.
The detection rule triggers based on the “Remove service principal” message in the Azure Activity Logs.
Security analysts investigate the event, examining the user identity, user agent, and hostname associated with the removal.
If the removal is deemed unauthorized or suspicious, further incident response procedures are initiated.

Impact

Successful removal of a service principal by a malicious actor can disrupt legitimate applications relying on that principal for authentication and authorization. It can also hinder incident response efforts by eliminating a potential avenue for investigation or remediation. The impact can range from service disruptions to prolonged breaches if the attacker successfully covers their tracks. The number of affected applications and the severity of the disruption depend on the role and permissions associated with the removed service principal.

Recommendation

Deploy the Sigma rule “Azure Service Principal Removed” to your SIEM and tune for your environment, focusing on identifying legitimate administrator activity to reduce false positives.
Investigate any detected instance of service principal removal, focusing on the user identity, user agent, and hostname from the Azure Activity Logs to determine legitimacy.
Review Azure AD audit logs for related activities occurring before and after the service principal removal.

Unauthorized Guest User Invitation Attempt in Azure

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

This alert detects instances where a user attempts to invite an external guest user to an Azure environment but fails due to insufficient permissions. This activity can signify several potential security risks, including unauthorized privilege escalation attempts by internal users or malicious insiders attempting to expand access without proper authorization. While legitimate failed attempts may occur, repeated or targeted failures should be investigated. The activity is logged within the Azure Audit Logs. Detecting this activity is crucial for maintaining control over user access and preventing potential data breaches. The relevant log data resides within Azure’s audit logs.

Attack Chain

An internal user (either compromised or malicious) attempts to invite an external guest user via the Azure portal or API.
The Azure Active Directory service checks the inviter’s permissions against the organization’s guest invitation policies.
The system determines the user lacks the necessary permissions to invite guest users.
Azure Audit Logs record the “Invite external user” event with a “failure” status.
The failed invitation attempt is blocked, preventing the external user from gaining access.
The attacker may retry the invitation with different accounts or methods, attempting to bypass access controls.
If successful through other means (not detected by this rule), the guest user could be used for lateral movement or data exfiltration.

Impact

A successful privilege escalation could grant unauthorized access to sensitive data and resources within the Azure environment. While this specific detection focuses on failed attempts, repeated failures may indicate a concerted effort to bypass security controls. If successful, unauthorized guest users could be used for lateral movement, data exfiltration, or other malicious activities. The number of affected resources depends on the permissions granted to the guest user if the invitation had been successful.

Recommendation

Deploy the Sigma rule “Guest User Invited By Non Approved Inviters” to your SIEM to detect unauthorized invitation attempts within Azure Audit Logs.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the invitation attempt and the intent of the user.
Review and enforce the principle of least privilege for user roles and permissions within Azure Active Directory.
Monitor for repeated failed invitation attempts from the same user account (correlate with the Azure Audit Logs data).

Azure Subscription Permission Elevation via Activity Logs

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

This threat involves the elevation of user permissions within an Azure environment to manage all Azure subscriptions. While legitimate administrators may perform this action, unauthorized elevation of permissions can grant an attacker significant control over the entire Azure environment. This could be an insider threat or a compromised account being used to broaden access. The activity is logged within Azure Activity Logs, providing an opportunity for detection. Defenders should be aware of this potential escalation path and monitor for unexpected or unauthorized permission changes.

Attack Chain

The attacker gains initial access to an Azure account, potentially through compromised credentials (T1078.004).
The attacker authenticates to the Azure portal or uses Azure CLI/PowerShell with the compromised account.
The attacker attempts to elevate their permissions using the MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION operation.
Azure Activity Logs record the attempt to elevate permissions.
If successful, the attacker gains management access to all Azure subscriptions within the tenant.
The attacker can then provision resources, modify configurations, and access data within those subscriptions.
The attacker might establish persistence by creating new user accounts with elevated privileges or modifying existing roles.
The attacker can then exfiltrate sensitive data or disrupt services within the Azure environment.

Impact

Successful elevation of permissions to manage all Azure subscriptions allows an attacker to control all resources, data, and configurations within the Azure environment. This can lead to data breaches, service disruptions, financial loss, and reputational damage. The scope of impact depends on the sensitivity of the data stored within Azure and the criticality of the services hosted there.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION operations in Azure Activity Logs.
Investigate any detected instances of MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION immediately, as outlined in the rule description.
Implement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.
Review and enforce the principle of least privilege for Azure role assignments.
Monitor Azure Activity Logs for other suspicious activities, such as unusual resource creation or modification.

Azure AD Account Created and Deleted Within a Close Time Frame

hello@craftedsignal.io — Tue, 02 Jan 2024 15:30:00 +0000

The creation and immediate deletion of user accounts within Azure Active Directory can be indicative of various malicious activities. Attackers may create accounts to escalate privileges, establish persistence, or gain initial access to a system. The short lifespan of these accounts suggests an attempt to evade detection. This behavior is particularly concerning as it can be used to perform actions and then quickly remove the evidence of the account’s existence from standard audit logs. Monitoring for this activity helps defenders identify and respond to potential security breaches within their Azure environment. This technique is relevant for any organization utilizing Azure Active Directory for user management.

Attack Chain

An attacker gains initial access to an Azure AD environment, potentially through compromised credentials or a phishing attack.
The attacker creates a new user account within the Azure AD. This can be achieved through the Azure portal, PowerShell, or the Azure CLI.
The attacker assigns elevated privileges to the newly created account. This might involve adding the account to privileged roles such as Global Administrator or assigning specific permissions to access sensitive resources.
The attacker uses the newly created account to perform malicious activities, such as accessing confidential data, modifying system configurations, or deploying malicious applications.
After completing the malicious tasks, the attacker removes the elevated privileges from the account to reduce the chances of detection during privilege reviews.
The attacker deletes the created account from Azure AD. This step is performed to remove the traces of the account’s existence and hinder forensic investigations.
The actions performed by the short-lived account may leave other traces in logs, such as access logs or activity logs related to the resources the account interacted with.
The attacker aims to maintain stealth and evade detection while gaining unauthorized access to resources or establishing persistence within the Azure AD environment.

Impact

Successful exploitation can lead to unauthorized access to sensitive resources, data breaches, and system compromise. The creation and deletion of short-lived accounts can mask malicious activities, making it difficult to trace the attacker’s actions. Organizations using Azure AD could experience data exfiltration, financial loss, and reputational damage. Detecting such activity early is critical to preventing further damage and mitigating the impact of the attack.

Recommendation

Deploy the Sigma rule “Account Created And Deleted Within A Close Time Frame” to your SIEM and tune for your environment to detect suspicious account creation/deletion events in Azure AD audit logs.
Investigate any alerts generated by the Sigma rule “Account Created And Deleted Within A Close Time Frame” to determine the scope and impact of the potential compromise.
Implement multi-factor authentication (MFA) for all user accounts, especially those with elevated privileges, to reduce the risk of credential compromise (reference: attack.initial-access).
Regularly review Azure AD audit logs for unusual account activity, focusing on accounts created and deleted within a short timeframe (logsource: azure, service: auditlogs).

AWS Root Account Usage Detected

hello@craftedsignal.io — Tue, 02 Jan 2024 14:30:00 +0000

The use of the AWS root account should be strictly limited to specific tasks that cannot be performed with IAM users or roles. This alert indicates that the root account was used, which could signify various security concerns. An attacker with access to the root account can perform any action within the AWS environment, including creating new users, modifying security policies, accessing sensitive data, and deleting resources. Defenders should investigate each instance of root account usage to determine legitimacy. This activity may also indicate a misconfiguration where IAM roles should be used.

Attack Chain

An attacker gains access to the AWS root account credentials through credential theft or other means.
The attacker authenticates to the AWS Management Console or uses the AWS CLI with the root account credentials.
The attacker enumerates AWS resources to identify potential targets for privilege escalation.
The attacker creates or modifies IAM policies to grant themselves additional permissions.
The attacker may create new IAM users or roles with elevated privileges.
The attacker uses the elevated privileges to access sensitive data stored in S3 buckets or other AWS services.
The attacker modifies security configurations, such as network access control lists or security groups, to facilitate lateral movement or data exfiltration.
The attacker could disable logging features to cover tracks.

Impact

Compromise of the AWS root account can lead to a complete breach of the AWS environment, resulting in unauthorized access to sensitive data, data loss, service disruption, and potential financial losses. Attackers can leverage root privileges to perform nearly any action within the AWS account, affecting all services and resources. The number of affected victims depends on the scope and criticality of the AWS environment.

Recommendation

Deploy the Sigma rule “AWS Root Credentials” to your SIEM to detect root account usage based on CloudTrail logs.
Investigate all instances of root account usage identified by the “AWS Root Credentials” Sigma rule to determine legitimacy.
Enforce multi-factor authentication (MFA) on all AWS accounts, including the root account, as documented in AWS documentation.
Implement the principle of least privilege by granting IAM users and roles only the permissions they need to perform their tasks.
Regularly audit IAM policies and user permissions to identify and remove unnecessary privileges.
Disable or restrict root account access wherever possible, delegating tasks to IAM users/roles.