Atlassian — CraftedSignal Threat Feed

Multiple Vulnerabilities in Atlassian Products

hello@craftedsignal.io — Tue, 28 Apr 2026 08:31:27 +0000

Multiple vulnerabilities exist in Atlassian’s Bamboo, Bitbucket, Confluence, and Jira products. While specific CVEs are not detailed in this advisory, the potential impact is significant. An attacker exploiting these vulnerabilities could achieve arbitrary code execution, allowing for complete system compromise. They could also bypass security measures, potentially disabling logging or other security controls. Data manipulation and disclosure could lead to sensitive information compromise and unauthorized modifications. Cross-site scripting (XSS) attacks could be leveraged to steal user credentials or perform actions on behalf of unsuspecting users. Defenders need to ensure the Atlassian suite is fully patched and monitored.

Attack Chain

Initial Access: An attacker identifies a vulnerable Atlassian product instance (Bamboo, Bitbucket, Confluence, or Jira) accessible over the network.
Vulnerability Exploitation: The attacker leverages an unknown vulnerability to inject malicious code into the application, possibly through a crafted HTTP request.
Code Execution: The injected code executes within the context of the Atlassian application, allowing the attacker to run arbitrary commands on the server.
Privilege Escalation: The attacker leverages the initial code execution to escalate privileges, potentially gaining root or administrator access.
Defense Evasion: The attacker attempts to disable security logging or other monitoring mechanisms to avoid detection.
Data Manipulation/Exfiltration: The attacker accesses sensitive data stored within the Atlassian application or connected databases, manipulating or exfiltrating it for malicious purposes.
Lateral Movement: Using compromised credentials or established footholds, the attacker moves laterally to other systems within the network.
Impact: The attacker achieves their final objective, such as deploying ransomware, stealing intellectual property, or disrupting business operations.

Impact

Successful exploitation of these vulnerabilities could result in significant damage, including complete compromise of Atlassian servers, data breaches, and disruption of critical business processes. The number of potential victims is substantial, as these Atlassian products are widely used across various industries. The impact ranges from data loss and financial damage to reputational harm and legal liabilities.

Recommendation

Deploy the Sigma rules provided in this brief to detect potential exploitation attempts targeting Atlassian products.
Monitor web server logs for suspicious activity, especially HTTP requests targeting Atlassian applications, to detect potential vulnerability exploitation.
Enable and review audit logs within Atlassian products (Bamboo, Bitbucket, Confluence, Jira) for suspicious activity.
Implement network segmentation to limit the potential impact of a successful breach originating from a compromised Atlassian server.

Bitbucket Secret Scanning Rule Deleted

hello@craftedsignal.io — Sun, 17 Nov 2024 14:22:00 +0000

Attackers with sufficient privileges within a Bitbucket project or repository may delete secret scanning rules. These rules are designed to automatically detect and prevent the committing of sensitive information like API keys, passwords, and tokens directly into the codebase. By removing these rules, adversaries can bypass security controls and introduce secrets into the repository undetected. This could be a precursor to a larger attack, where the leaked secrets are used to gain unauthorized access to systems, data, or other resources. This activity may occur as a part of a broader insider threat campaign or an external attacker who has gained control of a privileged account.

Attack Chain

The attacker compromises a Bitbucket account with project or repository administrator privileges.
The attacker authenticates to the Bitbucket web interface or uses the Bitbucket API with the compromised account.
The attacker navigates to the project or repository settings where secret scanning rules are configured.
The attacker identifies the secret scanning rules in place.
The attacker initiates the deletion of one or more secret scanning rules through the Bitbucket web interface or API.
Bitbucket processes the request and removes the specified secret scanning rules.
The attacker (or another compromised account) commits code containing secrets, which are no longer detected due to the deleted rules.
The committed secrets are then potentially used for lateral movement, data exfiltration, or other malicious activities.

Impact

The deletion of secret scanning rules in Bitbucket can lead to the undetected introduction of sensitive information into the codebase. This can result in unauthorized access to systems, data breaches, and other security incidents. The impact can range from minor data exposure to significant financial losses and reputational damage, depending on the scope and sensitivity of the leaked secrets. Organizations relying on Bitbucket for source code management are vulnerable.

Recommendation

Monitor Bitbucket audit logs for events related to secret scanning rule deletions, using the provided Sigma rule to detect suspicious activity (bitbucket_audit_secret_scanning_rule_deleted.yml).
Implement multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to reduce the risk of account compromise.
Enforce the principle of least privilege, ensuring that users only have the necessary permissions to perform their tasks.
Regularly review and audit Bitbucket user permissions and access controls.
Implement strong password policies and encourage users to use unique, complex passwords.

Bitbucket Global SSH Settings Changed

hello@craftedsignal.io — Fri, 01 Nov 2024 12:00:00 +0000

This brief focuses on the detection of unauthorized changes to Bitbucket’s global SSH settings. While the specific actor remains unknown, the modification of these settings is a significant security concern. The activity is detected via Bitbucket audit logs. Modification of global SSH settings can allow attackers to gain unauthorized access to repositories, potentially leading to code compromise, data breaches, or further lateral movement within the network. This activity is particularly important for organizations relying on Bitbucket for source code management and secure development workflows. The audit logs are the primary source of information, specifically focusing on events categorized as ‘Global administration’ with the action ‘SSH settings changed’.

Attack Chain

The attacker gains initial access to a Bitbucket account with administrative privileges, possibly through credential compromise or exploiting a vulnerability.
The attacker authenticates to the Bitbucket web interface.
The attacker navigates to the global SSH settings configuration page within the Bitbucket administration panel.
The attacker modifies global SSH settings, such as adding a new public key or changing authentication requirements.
Bitbucket logs the ‘SSH settings changed’ event in the audit logs under the ‘Global administration’ category.
The attacker leverages the modified SSH settings to clone repositories or push malicious code.
The attacker uses compromised code or data to move laterally within the organization’s network, targeting other systems and resources.

Impact

Successful modification of Bitbucket global SSH settings can allow unauthorized access to all repositories within the Bitbucket instance. This can lead to code theft, injection of malicious code, and data breaches. The impact may extend beyond the Bitbucket environment if the compromised code is deployed to production systems or used in other development processes. Organizations using Bitbucket for critical projects are at higher risk.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized changes to Bitbucket global SSH settings in the audit logs.
Investigate any detected instances of “SSH settings changed” in the Bitbucket audit logs to determine the legitimacy of the changes.
Enforce multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to mitigate credential compromise as an initial access vector.
Review Bitbucket’s audit log configuration to ensure the “Advance” log level is enabled to capture the necessary audit events.

Bitbucket Audit Log Configuration Modified

hello@craftedsignal.io — Sat, 26 Oct 2024 12:00:00 +0000

Attackers may target Bitbucket audit log configurations to reduce or eliminate logging, thereby hindering incident response and forensic investigations. Modifying audit settings is a defense evasion technique that allows malicious actors to operate with less visibility. This activity typically occurs post-compromise. This brief focuses on detecting such modifications. Visibility of audit events requires at least “Basic” log level configuration.

Attack Chain

An attacker gains unauthorized access to a Bitbucket instance, potentially through compromised credentials or exploiting a vulnerability.
The attacker authenticates to the Bitbucket web interface or uses the Bitbucket API.
The attacker navigates to the audit log configuration settings within the Bitbucket administration panel.
The attacker modifies the audit log settings, such as disabling logging for specific event categories or reducing the log retention period.
The Bitbucket server processes the configuration change request.
Audit events related to the configuration change are logged (if auditing is still enabled for such events).
The attacker performs malicious activities, such as creating unauthorized repositories or exfiltrating source code, with reduced risk of detection.

Impact

Successful modification of the Bitbucket audit log configuration allows attackers to operate with significantly reduced visibility. This can lead to delayed detection of breaches, prolonged dwell time, and increased data exfiltration. Without proper audit logging, organizations will struggle to identify the scope and impact of a compromise.

Recommendation

Deploy the “Bitbucket Audit Log Configuration Updated” Sigma rule to your SIEM to detect changes to audit log configurations (logsource: bitbucket, service: audit).
Ensure Bitbucket audit logging is enabled at the “Basic” level or higher, as lower levels may not capture configuration changes (logsource: bitbucket, service: audit).
Investigate any detected instances of audit log configuration changes to determine if they are authorized (Sigma rule: “Bitbucket Audit Log Configuration Updated”).

GenAI Process Connection to Unusual Domain on macOS

hello@craftedsignal.io — Thu, 02 May 2024 14:22:30 +0000

This threat brief addresses the risk of GenAI tools on macOS connecting to unusual domains, which may indicate a compromised state. Attackers can exploit GenAI tools through prompt injection, malicious MCP (Model Context Protocol) servers, or poisoned plugins to establish command-and-control (C2) channels or exfiltrate sensitive data. Given the network access capabilities of AI agents, adversaries may manipulate them to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. The Elastic detection rule 9050506c-df6d-4bdf-bc82-fcad0ef1e8c1 focuses on identifying such anomalous network connections originating from a predefined list of GenAI processes, excluding known legitimate domains. The rule has been actively maintained since its creation on December 4, 2025, with its latest update on April 29, 2026.

Attack Chain

Adversary compromises a GenAI tool on a macOS system through prompt injection, malicious MCP servers, or poisoned plugins.
The compromised GenAI tool is configured to connect to an attacker-controlled domain for C2.
The GenAI process initiates a network connection attempt to the unusual domain using standard web protocols (HTTP/HTTPS).
The macOS system’s network stack resolves the attacker’s domain to its corresponding IP address.
The GenAI process sends data to the attacker-controlled domain, potentially including sensitive information.
The attacker uses the C2 channel to send commands to the compromised GenAI tool.
The GenAI tool executes the commands, potentially leading to further compromise or data exfiltration.

Impact

Compromised GenAI tools can lead to data exfiltration, unauthorized access to sensitive information, and the establishment of persistent C2 channels within an organization’s network. The impact ranges from the loss of intellectual property and customer data to the potential disruption of business operations. The risk is amplified if the GenAI tool has access to internal systems or sensitive data stores, allowing attackers to pivot and escalate their attacks.

Recommendation

Deploy the Sigma rule “GenAI Process Connecting to Unusual Domain” to your SIEM and tune for your environment (see rule below).
Enable process creation and network connection logging on macOS endpoints to collect the data required for the Sigma rule.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the domain and the GenAI process’s behavior.
Block any identified malicious domains at the network level (see query in the provided source).
Review the GenAI tool’s configuration for unauthorized MCP servers, plugins, or extensions that initiated the connection.
Regularly update the list of allowed domains in the Sigma rule’s filter to account for legitimate updates to GenAI tool infrastructure.

Bitbucket Global Secret Scanning Rule Deletion

hello@craftedsignal.io — Mon, 29 Apr 2024 14:00:00 +0000

This threat brief addresses the deletion of global secret scanning rules within Bitbucket environments. Secret scanning is a crucial defense mechanism used to prevent sensitive information, such as API keys and passwords, from being committed to repositories. An attacker with global administration privileges could intentionally delete these rules to bypass security controls. This action could occur post-compromise, as part of an insider threat, or due to accidental misconfiguration. The impact of this activity centers around an increased risk of sensitive data exposure, which can lead to further compromise or data breaches. Defenders should monitor Bitbucket audit logs for such deletions.

Attack Chain

The attacker gains valid credentials with global administrator privileges within the Bitbucket environment, possibly through credential stuffing or phishing.
The attacker authenticates to the Bitbucket web interface or uses the Bitbucket API with their compromised credentials.
The attacker navigates to the global secret scanning rule configuration page.
The attacker identifies and selects one or more global secret scanning rules currently in effect.
The attacker initiates the deletion process for the selected rules, confirming the action when prompted.
Bitbucket processes the deletion request, removing the rules from the global configuration.
The system generates an audit log event indicating the deletion of the global secret scanning rule.
With secret scanning disabled, developers may inadvertently commit secrets into Bitbucket repositories, making them available to the attacker.

Impact

Successful deletion of global secret scanning rules can have significant impact. Without active secret scanning, developers may unintentionally commit sensitive information (API keys, passwords, tokens) into Bitbucket repositories. This could lead to account takeovers, data breaches, or lateral movement within the organization’s infrastructure. The number of affected repositories and exposed secrets will vary depending on the scope of the attacker’s access and the activity of developers during the period when the rules were disabled.

Recommendation

Deploy the provided Sigma rule to detect the deletion of global secret scanning rules in Bitbucket audit logs, focusing on auditType.category: 'Global administration' and auditType.action: 'Global secret scanning rule deleted' (Sigma rule).
Investigate any detected instances of global secret scanning rule deletion to determine if the action was authorized and performed by a legitimate user.
Implement multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to reduce the risk of credential compromise.
Regularly review Bitbucket user permissions and roles to ensure that users have only the necessary level of access.
Enable “Basic” logging level, as required, to ensure the necessary audit events are generated (logsource definition).

Bitbucket Repository Exempted from Secret Scanning

hello@craftedsignal.io — Mon, 29 Apr 2024 12:00:00 +0000

Attackers can weaken an organization’s security posture by disabling or bypassing security controls within Bitbucket. This allows sensitive information, such as API keys, passwords, and other credentials, to be committed to the repository without detection. By adding a repository to the secret scanning exemption list, attackers can effectively disable a key preventative measure, making it easier to introduce and maintain compromised credentials within the codebase. This can lead to unauthorized access, data breaches, and other serious security incidents. This technique allows attackers to impair defenses, avoiding detection of secrets being committed to the repository.

Attack Chain

An attacker gains unauthorized access to a Bitbucket account with repository administration privileges.
The attacker navigates to the repository settings within Bitbucket.
The attacker accesses the secret scanning configuration for the repository.
The attacker identifies the option to add the repository to the exemption list for secret scanning.
The attacker adds the repository to the exemption list, effectively disabling secret scanning for that repository.
The attacker commits sensitive information (secrets, credentials) to the now-exempt repository.
The secrets are committed without triggering secret scanning alerts.
The attacker uses the committed secrets to gain unauthorized access to other systems or data.

Impact

Compromising secrets within a Bitbucket repository can lead to a variety of negative consequences, including unauthorized access to sensitive data, compromised infrastructure, and data breaches. While the exact number of affected organizations is unknown, the potential impact is significant for any organization using Bitbucket to store code and manage secrets. Successful exploitation allows attackers to move laterally within the network and escalate privileges.

Recommendation

Deploy the Sigma rule “Bitbucket Secret Scanning Exempt Repository Added” to your SIEM to detect when a repository is added to the secret scanning exemption list (logsource: bitbucket).
Investigate any detected instances of repositories being added to the secret scanning exemption list to determine if the change was authorized.
Ensure that appropriate access controls are in place to prevent unauthorized users from modifying repository settings.
Review Bitbucket audit logs regularly to identify suspicious activity related to secret scanning configuration changes (logsource: bitbucket).

Bitbucket Project Secret Scanning Allowlist Added

hello@craftedsignal.io — Mon, 29 Apr 2024 12:00:00 +0000

The addition of a secret scanning allowlist rule to a Bitbucket project can be abused by malicious actors to bypass security controls. While not inherently malicious, this action can be exploited to weaken an organization’s security posture. Secret scanning tools are designed to prevent the accidental or intentional commit of sensitive information (API keys, passwords, etc.) into version control systems. By adding an allowlist rule, specific patterns or files can be excluded from these scans. This could be leveraged by an attacker who has gained access to a Bitbucket account or project to intentionally introduce secrets while avoiding detection. The activity is logged by Bitbucket’s audit logs, providing an opportunity for detection.

Attack Chain

The attacker gains unauthorized access to a Bitbucket account with sufficient privileges to modify project settings.
The attacker navigates to the project settings within Bitbucket.
The attacker accesses the secret scanning configuration for the project.
The attacker adds a new allowlist rule, specifying a pattern or file to be excluded from secret scanning.
The attacker commits code containing secrets that match the allowlist rule, effectively bypassing the secret scanning tool.
The changes are pushed to the Bitbucket repository.
The secrets remain undetected due to the allowlist rule.
The attacker leverages the exposed secrets for further malicious activities, such as gaining access to other systems or data.

Impact

Successful exploitation could lead to the exposure of sensitive information such as API keys, passwords, or other credentials. This can result in unauthorized access to internal systems, data breaches, and reputational damage. The number of affected projects depends on the scope of the attacker’s access and the configuration of the allowlist rule. The addition of the allowlist rule itself does not directly cause damage but creates a window of opportunity for the introduction and persistence of secrets within the codebase.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the addition of secret scanning allowlist rules (logsource: bitbucket, service: audit).
Investigate any detected instances of allowlist rule additions to verify their legitimacy and business justification.
Review and enforce strict access controls for Bitbucket projects to minimize the risk of unauthorized modifications.
Enable “Basic” log level in Bitbucket to ensure that the audit events required for detection are captured, as indicated in the rule definition.

Bitbucket User Login Failure Detection

hello@craftedsignal.io — Fri, 08 Mar 2024 15:00:00 +0000

This threat brief focuses on detecting user login failures within Bitbucket environments. Monitoring failed login attempts is crucial as it can indicate various malicious activities, including credential stuffing, brute-force attacks, or attempts to gain unauthorized initial access. The audit logs in Bitbucket record details of these authentication failures, providing valuable data for security monitoring. The rule provided detects these events and can be used for correlation with other security events based on the “author.name” field for enhanced accuracy and context. Requires “Advance” log level to receive audit events.

Attack Chain

Initial Access Attempt: An attacker attempts to gain initial access to a Bitbucket account using a compromised or guessed username.
Credential Guessing: The attacker attempts to guess the user’s password through manual attempts or automated tools.
Authentication Failure: Bitbucket records a “User login failed” event due to incorrect credentials. The auditType.category is Authentication, and auditType.action is User login failed.
Multiple Failed Attempts: The attacker repeats the login attempts with different password variations or using a list of compromised credentials.
Account Lockout (Optional): Depending on Bitbucket’s configuration, repeated failed login attempts may trigger an account lockout.
Successful Login (Potential): After multiple attempts, the attacker may eventually guess the correct password or use a valid compromised credential.
Privilege Escalation/Persistence (If Successful): If successful, the attacker could escalate privileges, establish persistence, or perform other malicious actions within the Bitbucket environment.

Impact

Successful exploitation can lead to unauthorized access to sensitive code repositories, intellectual property theft, and potential supply chain compromise. Attackers could inject malicious code, modify existing code, or exfiltrate sensitive data. Detecting these failed login attempts early can prevent significant damage. Although the number of victims cannot be determined with this specific detection, a successful attack can have far-reaching impacts.

Recommendation

Deploy the Sigma rule “Bitbucket User Login Failure” to your SIEM to detect suspicious authentication failures (logsource: bitbucket, service: audit). Tune for your environment by correlating on the author.name field.
Investigate the source IP addresses associated with the failed login attempts to identify potential malicious actors.
Implement multi-factor authentication (MFA) to significantly reduce the risk of successful credential-based attacks.
Monitor for unusual activity following any successful login after a series of failures.
Enforce strong password policies to reduce the effectiveness of brute-force attacks.