Github — CraftedSignal Threat Feed

Pelican Web UI Privilege Escalation Vulnerability

hello@craftedsignal.io — Mon, 04 May 2026 21:24:50 +0000

On April 2nd, 2026, a privilege escalation vulnerability was identified in the Pelican Web User Interface (WebUI) affecting versions v7.21 to v7.24. This vulnerability allows any authenticated user via OAuth to gain admin privileges under specific configurations, including servers with Server.UIAdminUsers where listed users haven’t logged in or Server.AdminGroups with Issuer.GroupSource set to internal where an admin hasn’t logged in. Successful exploitation permits attackers to modify server configurations, create API tokens, and change admin passwords. The OSDF operations team mitigated this vulnerability for core services, but mitigation may be required for other caches and origins. There is currently no evidence this attack has been exploited in services managed by OSDF operators.

Attack Chain

An attacker gains initial access to the Pelican WebUI by authenticating via OIDC.
The attacker identifies a valid Server.UIAdminUsers username or Server.AdminGroups group name for an admin who has not yet logged into the WebUI.
The attacker crafts malicious database records designed to grant admin privileges upon subsequent login.
The attacker injects these records into the Pelican server’s SQLite database, potentially using API endpoints or other methods to interact with the database.
The attacker logs out of the WebUI.
The attacker logs back into the WebUI.
The server grants the attacker admin privileges based on the manipulated database records.
The attacker modifies server configurations, creates persistent API tokens, or changes admin passwords.

Impact

The successful exploitation of this vulnerability poses a significant risk to Pelican servers and the wider federation they support. A compromised Director service could have high federation-wide impact, enabling denial of service and redirection to malicious registries. Registry services also have high federation-wide impact, with attackers potentially poisoning namespaces. Compromised Origins could lead to high data exposure and tampering risks by enabling unauthorized writes and changing export paths. Caches present a medium data exposure risk, as attackers could expose cached protected data.

Recommendation

Run the provided mitigation script (mitigate-user-escalation.sh from https://gist.github.com/jhiemstrawisc/8c4b2b3ec5cb2ca06537d9439dc16cc9) to audit the database for signs of exploitation and block further exploitation.
Upgrade Pelican servers to a patched release (>=v7.21.5, >=v7.22.3, >=v7.23.3, >=v7.24.2).
If unable to upgrade immediately, disable the vulnerable configuration by commenting out UIAdminUsers and AdminGroups settings in the pelican.yaml configuration file.
Monitor process executions for the mitigate-user-escalation.sh script and review associated user and API token changes. Deploy the provided Sigma rule to detect potential malicious activity.

Gotenberg ExifTool Tag Blocklist Bypass via Group-Prefixed Tag Names

hello@craftedsignal.io — Mon, 04 May 2026 19:21:19 +0000

Gotenberg, a Docker-based server for document conversion, is susceptible to a critical vulnerability (CVE-2026-40893) that bypasses its intended security measures. Specifically, a blocklist designed to prevent arbitrary file renaming and moving via ExifTool is circumvented by using group-prefixed tag names such as System:FileName. This vulnerability, affecting Gotenberg version 8.30.1 and earlier, allows unauthenticated attackers to manipulate files within the container by sending crafted HTTP requests. The bypass allows for renaming files, moving files to arbitrary directories, and changing file permissions, potentially leading to service disruption or, in shared-volume deployments, impacting other services utilizing the same volumes. This vulnerability effectively negates the patch provided in GHSA-qmwh-9m9c-h36m.

Attack Chain

The attacker identifies a Gotenberg instance (version 8.30.1 or earlier) exposed via HTTP.
The attacker crafts a POST request to any Gotenberg endpoint that accepts the metadata field, such as /forms/pdfengines/metadata/write, /forms/chromium/convert/html, or /forms/libreoffice/convert.
The request includes a files parameter with a PDF file (or any other supported file type).
The request includes a metadata parameter, a JSON object containing malicious ExifTool tag names such as System:FileName and System:Directory.
Gotenberg’s exiftool.go validates the tag names against a blocklist but fails to normalize group prefixes, allowing System:FileName to bypass the check that would block FileName.
ExifTool receives the System:FileName and System:Directory tags and interprets them as FileName and Directory, respectively.
ExifTool renames and moves the uploaded file to the attacker-specified location within the container’s file system.
If Gotenberg attempts to access the file after it has been moved, the server returns a 404 error, potentially disrupting service for other users.

Impact

Successful exploitation of this vulnerability (CVE-2026-40893) allows an unauthenticated attacker to manipulate files within the Gotenberg container. This includes the ability to rename files, move them to arbitrary directories, and change their permissions. This can lead to denial-of-service conditions due to missing files, or in scenarios where Gotenberg shares a Docker volume with other services, it allows for planting malicious files in those shared directories. Since no authentication is required by default, any system capable of sending HTTP requests to the Gotenberg instance can exploit this vulnerability, widening the attack surface.

Recommendation

Apply the patch or upgrade to a version of Gotenberg greater than 8.30.1 to remediate CVE-2026-40893.
Deploy the Sigma rule Detect Gotenberg ExifTool Tag Blocklist Bypass to identify exploitation attempts based on the use of System: prefixed ExifTool tags.
Deploy the Sigma rule Detect Gotenberg FilePermissions Tag Abuse to detect abuse of the FilePermissions tag.
Monitor webserver logs for POST requests to the affected Gotenberg endpoints (/forms/pdfengines/metadata/write, /forms/chromium/convert/html, /forms/libreoffice/convert) containing the string System:FileName or FilePermissions in the request body.

Detection of VScode Remote Tunneling for Command and Control

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This detection focuses on identifying the misuse of Visual Studio Code’s (VScode) remote tunnel feature to establish unauthorized access or control over systems. While the VScode remote tunnel feature is designed to allow developers to connect to remote environments seamlessly, attackers can abuse this functionality for malicious purposes. The rule specifically looks for the execution of the VScode portable binary with the “tunnel” command-line option, which is indicative of an attempt to establish a remote tunnel session to either GitHub or a remote VScode instance. Successful exploitation can lead to command and control capabilities, allowing attackers to remotely manage and compromise the affected system. The rule aims to detect this suspicious behavior by monitoring process execution and command-line arguments.

Attack Chain

The attacker gains initial access to the target system through unspecified means.
The attacker downloads a portable version of Visual Studio Code (VScode) onto the compromised system.
The attacker executes the VScode binary with the tunnel command-line argument to initiate a remote tunnel session.
The attacker specifies additional arguments such as --accept-server-license-terms to bypass license agreement prompts.
The VScode tunnel attempts to establish a connection to a remote server, potentially a GitHub repository or a remote VScode instance controlled by the attacker.
If successful, the tunnel creates a persistent connection, allowing the attacker to execute commands and transfer files.
The attacker uses the established tunnel to remotely access the compromised system, enabling them to perform malicious activities such as data exfiltration or lateral movement.
The attacker maintains persistent access through the established tunnel, allowing for long-term command and control of the compromised system.

Impact

Successful exploitation allows attackers to establish a persistent command and control channel, enabling them to remotely manage the compromised system. This can lead to data theft, deployment of ransomware, or further lateral movement within the network. While the number of potential victims and specific sectors targeted are not explicitly stated, the widespread use of VScode makes a wide range of organizations vulnerable.

Recommendation

Deploy the “Attempt to Establish VScode Remote Tunnel” rule to detect suspicious VScode tunnel activity in your environment.
Enable Sysmon process-creation logging to capture the necessary process execution data.
Investigate any alerts triggered by the rule, focusing on the command-line arguments and process behaviors to confirm malicious intent.
Monitor network connections originating from VScode processes for unusual or unauthorized connections to external servers.
Review and whitelist legitimate uses of VScode’s tunnel feature by authorized developers to reduce false positives.

Increased npm Supply Chain Attacks Targeting SAP Developers

hello@craftedsignal.io — Sat, 02 May 2026 00:10:33 +0000

The npm ecosystem is experiencing a surge in sophisticated supply chain attacks following the Shai-Hulud worm in September 2025. Attackers, including TeamPCP, are actively compromising npm packages to gain access to sensitive information and establish persistence within CI/CD pipelines. The attacks have evolved to include wormable propagation, infrastructure-level persistence, and multi-stage payloads designed to evade detection. In April 2026, two campaigns were observed: one included the string “Shai-Hulud: The Third Coming,” and the other, dubbed “Mini Shai-Hulud,” targeted the SAP developer ecosystem. The compromised packages are often part of SAP’s Cloud Application Programming (CAP) Model and multitarget application (MTA) build toolchain, increasing the likelihood of impacting enterprise developers and CI/CD pipelines with access to cloud credentials and GitHub tokens.

Attack Chain

Initial Compromise: Attackers compromise legitimate npm packages, such as @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt, by injecting malicious code.
Malicious Code Injection: Compromised packages receive two new files: setup.mjs and execution.js, along with a modified package.json containing a “preinstall” hook.
Execution of setup.mjs: During the npm install process, the preinstall hook executes setup.mjs, which detects the host OS and architecture.
Bun Runtime Download and Execution: setup.mjs downloads the Bun JavaScript runtime (v1.3.13) from GitHub releases and extracts it to a temporary directory.
Execution of execution.js: The Bun runtime executes execution.js, a large (11.7 MB) obfuscated credential stealer and propagation framework.
Credential Harvesting: execution.js harvests GitHub tokens, npm tokens, environment variables, GitHub Actions secrets, AWS STS identity, Azure Key Vault secrets, GCP Secret Manager values, and Kubernetes service account tokens. It also targets Claude and MCP configuration files and Electrum wallets.
Data Exfiltration: The collected data is compressed, encrypted, and exfiltrated to freshly created public GitHub repositories with randomized names and descriptions.
Propagation: The malware searches for commits containing the keyword “OhNoWhatsGoingOnWithGitHub,” decodes matching commit messages as a token dead-drop, recovers stolen GitHub tokens, and uses them to spread the malware to other packages.

Impact

Compromised npm packages can lead to the theft of sensitive credentials, including cloud provider credentials, GitHub tokens, and CI/CD secrets. Successful attacks can result in unauthorized access to cloud infrastructure, code repositories, and deployment pipelines. The Mini Shai-Hulud campaign targeted packages with approximately 570,000 weekly downloads, potentially impacting a large number of SAP developers and enterprise environments. The attackers use stolen credentials to further propagate the malware, increasing the scale and scope of the compromise.

Recommendation

Rotate npm tokens and GitHub Personal Access Tokens (PATs) immediately if any affected packages were installed (refer to the list of affected packages in the IOC table).
Monitor npm install processes for unexpected execution of node setup.mjs (see Attack Chain).
Implement the Sigma rule “Detect Suspicious Bun Process Execution” to identify potential execution of the Bun runtime from temporary directories.
Monitor network connections for unusual processes connecting to api.github[.]com/search/commits?q=OhNoWhatsGoingOnWithGitHub (see IOCs) to detect potential C2 activity.
Deploy the Sigma rule “Detect Github Commit By Claude Email” to identify commits authored with the email claude@users.noreply.github.com to detect malicious commits.

Compromised PyTorch Lightning Packages on PyPI Steal Developer Credentials

hello@craftedsignal.io — Fri, 01 May 2026 00:45:31 +0000

On April 30, 2026, two malicious versions (2.6.2 and 2.6.3) of the widely used pytorch-lightning package were published to the PyPI registry after the publisher account was compromised. These versions contain embedded malicious code designed to steal developer credentials and republish infected versions of repositories to which the stolen tokens have access. The attack is triggered upon importing the package, initiating a background process that silently harvests credentials from a wide array of services, including AWS, Azure, Google Cloud, and GitHub, as well as local environment variables and credential files. Version 2.6.3 was published just 13 minutes after 2.6.2, and was intended to evade detection.

Attack Chain

Attacker compromises the publisher account for the pytorch-lightning package on PyPI.
Attacker publishes malicious versions 2.6.2 and 2.6.3 to PyPI.
A modified __init__.py file within the package initiates a background process upon import.
The background process executes silently, without any visible output or indication of compromise to the user.
The malicious package downloads a runtime (Bun) from GitHub.
The package executes a large, obfuscated JavaScript file, targeting AWS, Azure, Google Cloud, GitHub, and local credential stores.
Stolen credentials, including cloud provider keys, API tokens, and secrets, are exfiltrated to attacker-controlled infrastructure.
The malware attempts to download and execute a second-stage payload from attacker-controlled infrastructure, expanding the scope of the attack.

Impact

Organizations that downloaded and used versions 2.6.2 or 2.6.3 of the pytorch-lightning package are at high risk of compromise. The malicious package is designed to steal a wide range of credentials, including cloud provider keys, API tokens, and secrets stored in environment variables. This can lead to unauthorized access to sensitive data and systems, potentially resulting in data breaches, financial losses, and reputational damage. The malware’s ability to download and execute secondary payloads further increases the potential impact.

Recommendation

Immediately remove versions 2.6.2 and 2.6.3 of the lightning package from all systems where they are installed (see overview).
Audit systems for unauthorized processes and review outbound network connections to detect potential compromises (see overview).
Rotate all cloud provider keys (AWS, Azure, GCP), API tokens (GitHub, CI/CD systems), and secrets stored in environment variables to prevent further unauthorized access (see Attack Chain).
Implement the Detect Suspicious PyPI Package Installation Sigma rule to identify potential malicious packages being installed in the future (see rules).
Implement the Detect Credential Harvesting via Bun Sigma rule to catch execution of the malicious JavaScript payload (see rules).
Pin dependencies to known-good versions and verify package integrity before use to prevent future supply chain attacks (see references).

Mini Shai-Hulud Supply Chain Attack Targets SAP NPM Packages

hello@craftedsignal.io — Thu, 30 Apr 2026 14:27:36 +0000

The Mini Shai-Hulud campaign, active as of April 2026, targets SAP NPM packages used in the SAP Cloud Application Programming (CAP) ecosystem and SAP cloud deployment workflows. Four package versions were compromised: mbt 1.2.48, @cap-js/db-service 2.10.1, @cap-js/postgres 2.2.2, and @cap-js/sqlite 2.2.2. These packages, with over 500,000 combined weekly downloads, are essential for SAP’s Cloud MTA Build Tool and database services for CAP software. The attackers injected a preinstall script that fetches and executes a Bun binary, bypassing security monitoring. The malicious versions were available for a short window of 2-4 hours before being unpublished and superseded by clean versions. Wiz attributes this activity to TeamPCP due to a shared RSA public key used to encrypt the exfiltrated secrets.

Attack Chain

The attacker compromises an NPM token, possibly exposed through CircleCI.
The attacker injects a malicious preinstall script into the targeted SAP NPM packages (mbt, @cap-js/db-service, @cap-js/postgres, @cap-js/sqlite).
When a user installs the compromised package, the preinstall script executes.
The script fetches a Bun ZIP archive from a GitHub repository.
The script extracts the Bun archive and executes the included Bun binary.
The Bun binary steals local credentials, GitHub and NPM tokens, AWS, Azure, GCP, GitHub Action, and Kubernetes secrets.
The stolen data is exfiltrated to public GitHub repositories with the description “A Mini Shai-Hulud has Appeared”.
The malware propagates by modifying package tarballs, updating versions, repackaging them, and publishing them using stolen GitHub Actions tokens.

Impact

The Mini Shai-Hulud attack poses a significant threat to developers and organizations using SAP CAP, a framework for S/4HANA extensions, Fiori app backends, MTAs, and integration flows. With over 500,000 weekly downloads of the affected packages, a large number of systems could have been affected. Successful exploitation allows attackers to steal sensitive credentials and cloud secrets, potentially leading to unauthorized access to critical SAP systems, cloud infrastructure, and source code repositories. This access could be used for further malicious activities, including data breaches, financial fraud, and supply chain compromise.

Recommendation

Organizations using SAP Business Technology Platform workflows, SAP CAP, or MTA-based deployment pipelines should immediately check if they installed the malicious package versions (mbt 1.2.48, @cap-js/db-service 2.10.1, @cap-js/postgres 2.2.2, @cap-js/sqlite 2.2.2) during the exposure window.
Implement network monitoring rules to detect connections to unusual GitHub repositories created to host stolen data. Monitor for repositories with the description “A Mini Shai-Hulud has Appeared”.
Monitor process execution for the execution of bun binaries in unusual or unexpected locations to identify systems where compromised packages were installed. Deploy the Sigma rule Detect Bun Execution From NPM Package to detect this behavior.

Komari Agent Abused as SYSTEM-Level Backdoor

hello@craftedsignal.io — Thu, 30 Apr 2026 00:00:00 +0000

Huntress discovered threat actors leveraging the Komari monitoring agent as a SYSTEM-level backdoor within a partner environment. Komari, a Go-based project on GitHub with over 4,000 stars, is designed as a remote-control and monitoring tool. This incident marks a publicly documented case of Komari being abused in a real-world intrusion. The attackers compromised VPN credentials to gain initial access before deploying the Komari agent as a persistent backdoor. Komari inherently functions as a command-and-control (C2) channel, with features enabled by default. The threat actor installed Komari as a Windows service named “Windows Update Service” using NSSM, directly from the official GitHub repository, which avoided the need for attacker-controlled staging infrastructure. The initial discovery occurred on April 16, 2026.

Attack Chain

Initial Access: The attacker establishes an SSLVPN session on a FortiGate device from IP address 45.153.34[.]132, authenticating as a legitimate user, [User 1].
Internal Reconnaissance: After establishing the VPN connection, the attacker’s workstation, identified as VM8514, begins enumerating the internal network from the tunnel IP 10.212.134[.]200.
Lateral Movement: Using Impacket’s smbexec.py, the attacker enables Remote Desktop Protocol (RDP) on the target workstation, [REDACTED-WRKSTN].
RDP Access: The attacker establishes an interactive RDP session to [REDACTED-WRKSTN].
Persistence - Service Creation: The attacker uses the Non-Sucking Service Manager (NSSM) to install the Komari agent as a persistent Windows service named “Windows Update Service”.
Agent Download: The Komari agent is downloaded from raw.githubusercontent[.]com/komari-monitor/komari-agent using a PowerShell one-liner executed directly on the system.
Command and Control: The Komari agent establishes a persistent WebSocket connection to its server, allowing the attacker to execute arbitrary commands (PowerShell/sh) and initiate interactive PTY reverse shell sessions.
Maintain Access & Execute: The attacker maintains SYSTEM-level access via the persistent Komari agent, enabling ongoing remote command execution and control over the compromised workstation.

Impact

This attack demonstrates how readily available monitoring tools can be weaponized for malicious purposes. A single compromised account led to the establishment of a SYSTEM-level backdoor on a critical workstation. This could result in data exfiltration, further lateral movement within the network, and potentially ransomware deployment. Microsoft Defender quarantined an earlier registry hive dumping attempt, preventing further data compromise. The number of affected organizations is currently unknown, but any organization using the Komari agent without proper security controls is potentially at risk.

Recommendation

Monitor FortiGate logs for SSLVPN sessions originating from suspicious IP addresses (45.153.34[.]132) and unusual ASN’s (ASN 51396) to detect potentially compromised credentials.
Implement the Sigma rule “Detect Komari Agent Installation via PowerShell” to identify installations of the Komari agent.
Monitor process creation events for the execution of nssm.exe installing a service named “Windows Update Service” to detect suspicious service installations.
Block the domain raw.githubusercontent[.]com at the DNS resolver or web proxy to prevent the downloading of malicious tools and payloads.

Detection of Github Delete Actions in Audit Logs

hello@craftedsignal.io — Tue, 28 Apr 2026 10:00:00 +0000

This detection strategy focuses on identifying potentially malicious or unauthorized deletion activities within a GitHub organization. The detections hinge on monitoring GitHub audit logs for specific actions related to the deletion of critical resources. This includes actions such as deleting codespaces (codespaces.destroy), deleting environments (environment.delete), deleting projects (project.delete), and destroying repositories (repo.destroy). This activity is important for defenders because these actions can lead to data loss, service disruption, or compromise of the software development lifecycle. The detections are triggered by events recorded within the GitHub audit log, requiring audit log streaming to be enabled.

Attack Chain

Initial Access: An attacker gains unauthorized access to a GitHub account with sufficient privileges. This could be achieved through compromised credentials or insider access.
Privilege Escalation (Optional): The attacker escalates privileges within the GitHub organization to gain the necessary permissions to delete resources if they don’t already have them.
Reconnaissance: The attacker identifies valuable codespaces, environments, projects, or repositories within the GitHub organization that they intend to delete.
Deletion of Codespaces: The attacker executes the codespaces.destroy action, deleting a specific codespace instance, potentially disrupting development workflows.
Deletion of Environments: The attacker executes the environment.delete action, removing a specific environment configuration, potentially affecting deployment processes.
Deletion of Projects: The attacker executes the project.delete action, deleting a project board and its associated tasks, impacting project management.
Deletion of Repositories: The attacker executes the repo.destroy action, permanently deleting a repository, leading to code loss and potential service disruption.
Impact: The deletion of critical resources disrupts development workflows, causes data loss, and potentially compromises the software development lifecycle.

Impact

Successful execution of these actions can lead to significant disruption of software development workflows, data loss, and potential compromise of the software supply chain. The number of affected resources and the severity of the impact depend on the scope of the attacker’s access and the criticality of the deleted resources.

Recommendation

Enable GitHub audit log streaming to capture the necessary events for detection (reference: logsource definition).
Deploy the provided Sigma rule to detect codespaces.destroy, environment.delete, project.delete, and repo.destroy actions in the GitHub audit logs, and tune for your environment (reference: rules).
Investigate any alerts triggered by the Sigma rule to determine the legitimacy of the deletion activity and the actor involved (reference: rules, falsepositives).
Validate the “actor” field in the audit logs to ensure the deletion activity is performed by an authorized user (reference: falsepositives).

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.

GitHub Security Feature Disablement

hello@craftedsignal.io — Thu, 31 Oct 2024 18:22:00 +0000

This brief addresses the threat of unauthorized or malicious disabling of security features within GitHub organizations and repositories. Attackers or malicious insiders might disable features like Advanced Security, OAuth application restrictions, or two-factor authentication to weaken the security posture, gain unauthorized access, and establish persistence. The affected features span across advanced security, OAuth application management, and two-factor authentication enforcement. These actions can be performed by users with administrative or owner privileges within the GitHub organization. Defenders need to monitor for these configuration changes to ensure security best practices are maintained and to quickly identify potential malicious activity.

Attack Chain

An attacker gains unauthorized access to a GitHub account with organization owner or administrator privileges through compromised credentials or insider access.
The attacker authenticates to the GitHub organization or repository using the compromised account.
The attacker navigates to the organization settings or repository settings, depending on the scope of the targeted security feature.
The attacker disables advanced security features (e.g., business_advanced_security.disabled_for_new_repos, repo.advanced_security_disabled) through the GitHub web interface or API.
Alternatively, the attacker disables OAuth application restrictions (org.disable_oauth_app_restrictions) to allow potentially malicious applications to access organizational data.
Or, the attacker disables the two-factor authentication requirement (org.disable_two_factor_requirement) for the organization, weakening account security.
The attacker may then proceed to exploit the weakened security posture to access sensitive repositories, modify code, or exfiltrate data.
The attacker establishes persistent access by creating rogue OAuth applications or adding unauthorized users to the organization.

Impact

Disabling security features in GitHub can lead to severe consequences. A successful attack can result in unauthorized access to sensitive code repositories, intellectual property theft, and data breaches. Disabling two-factor authentication makes accounts more vulnerable to credential stuffing and phishing attacks. The scope can range from a single repository to an entire organization, impacting hundreds or thousands of users and projects. The financial and reputational damage to the organization can be significant.

Recommendation

Deploy the Sigma rule Github High Risk Configuration Disabled to detect the disabling of critical security features by monitoring GitHub audit logs.
Enable audit log streaming as documented in the rule definition to ensure that the necessary logs are captured for detection.
Investigate any detected instances of security feature disabling to determine if they are legitimate administrator actions or malicious activity.
Enforce multi-factor authentication (MFA) for all users, especially those with administrative privileges, and monitor for attempts to disable MFA.
Regularly review and validate GitHub organization and repository settings to ensure that security features are enabled and configured correctly.

GitHub Secret Scanning Feature Disabled

hello@craftedsignal.io — Fri, 19 Jul 2024 00:00:00 +0000

The disabling of GitHub’s secret scanning feature represents a significant security risk. Secret scanning is a critical control that prevents sensitive information, such as API keys, credentials, and tokens, from being committed to repositories. An attacker who gains administrative access to a GitHub organization or repository could disable this feature to facilitate the undetected introduction of secrets into the codebase. This action undermines the organization’s security posture, creating opportunities for unauthorized access and data breaches. The activity is logged via GitHub audit logs, providing an opportunity for detection. This brief focuses on detecting the actions that disable the secret scanning feature within GitHub.

Attack Chain

An attacker gains unauthorized access to a GitHub account with administrative privileges for either an organization or a specific repository.
The attacker navigates to the security settings within the organization or repository.
The attacker identifies the “Secret scanning” feature or related settings (e.g., “Secret scanning for new repositories”).
The attacker disables the secret scanning feature using the GitHub UI or API. This generates an audit log event.
The attacker commits code containing secrets to the repository.
Because secret scanning is disabled, the secrets are not detected or flagged by GitHub.
The attacker leverages the committed secrets to gain unauthorized access to other systems or data.
The attacker achieves their final objective, which could include data exfiltration, lateral movement, or service disruption.

Impact

Disabling secret scanning can lead to the exposure of sensitive credentials within a codebase. If successful, attackers can leverage these exposed secrets to compromise systems, access sensitive data, and potentially cause significant financial and reputational damage. The number of affected repositories and the extent of the damage depend on the scope of the access the attacker gains and the criticality of the exposed secrets. This can affect any organization that uses Github for source code management.

Recommendation

Deploy the “Github Secret Scanning Feature Disabled” Sigma rule to your SIEM to detect unauthorized disabling of the feature (logsource: github, service: audit).
Investigate any detected instances of secret scanning being disabled to determine if they were authorized administrative actions.
Enable audit log streaming to ensure the required logs are available (see logsource definition).
Review GitHub access controls to ensure that only authorized personnel have the ability to modify secret scanning settings.

GitHub Push Protection Disabled

hello@craftedsignal.io — Fri, 03 May 2024 12:00:00 +0000

The GitHub push protection feature is designed to prevent secrets and sensitive information from being committed to repositories. Disabling this feature, whether at the organization, enterprise, or repository level, significantly increases the risk of accidental or intentional exposure of credentials, API keys, and other sensitive data. This can lead to unauthorized access, data breaches, and other security incidents. The actions detected can originate from administrative accounts or potentially compromised accounts with administrative privileges. This brief focuses on detecting the disabling of push protection, allowing security teams to respond and remediate the configuration.

Attack Chain

An attacker gains unauthorized access to a GitHub account with administrative privileges, or a legitimate administrator performs the action.
The attacker navigates to the organization, enterprise, or repository settings in GitHub.
The attacker locates the “Secret scanning” or “Push protection” configuration section.
The attacker disables the push protection feature for the organization, enterprise, or specific repositories. This can be done via the GitHub UI or API.
GitHub audit logs record the event with the actions business_secret_scanning_custom_pattern_push_protection.disabled, business_secret_scanning_push_protection.disable, org.secret_scanning_custom_pattern_push_protection_disabled, etc..
Developers unknowingly or intentionally commit code containing secrets or sensitive data to the affected repositories.
The secrets are pushed to the remote repository without being blocked by push protection.
The exposed secrets can be discovered by malicious actors, leading to account compromise, data breaches, or other security incidents.

Impact

Disabling push protection can lead to the exposure of sensitive information such as API keys, passwords, and other credentials within GitHub repositories. This exposure can lead to account compromise, unauthorized access to systems and data, and potentially significant financial and reputational damage. The number of affected repositories and the severity of the impact depends on the scope of the push protection disabling and the types of secrets committed to the repositories.

Recommendation

Deploy the Sigma rule “Github Push Protection Disabled” to your SIEM and tune for your environment to detect when push protection is disabled.
Investigate any detected instances of push protection being disabled in the GitHub audit logs (logsource: github, service: audit) to verify the legitimacy of the action.
Enforce multi-factor authentication (MFA) for all GitHub accounts, especially those with administrative privileges, to prevent unauthorized access.
Regularly review and audit GitHub organization and repository settings to ensure that push protection is enabled and properly configured.

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.

GitHub Push Protection Bypass Detection

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

This alert detects when a GitHub user bypasses the push protection mechanism designed to prevent secrets from being committed to a repository. GitHub’s push protection, part of its secret scanning feature, is intended to block commits containing sensitive information like API keys or credentials. A bypass indicates a deliberate attempt to circumvent this security measure. Successful bypass can lead to exposure of secrets, increasing the risk of unauthorized access and data breaches. The activity is logged within GitHub’s audit logs, provided that the audit log streaming feature is enabled.

Attack Chain

Developer attempts to commit code containing a secret to a GitHub repository.
GitHub’s push protection mechanism detects the secret and blocks the push.
The developer intentionally bypasses the push protection, potentially using allowed administrative activities to circumvent the block.
The code, including the secret, is successfully pushed to the repository.
The secret becomes exposed within the repository’s history.
Unauthorized actors may discover the exposed secret by scanning the repository.
Unauthorized actors may use the exposed secret to gain unauthorized access to systems or data.

Impact

A successful bypass of GitHub push protection can lead to secrets being exposed in a repository. This exposure can lead to unauthorized access to sensitive systems or data. The severity of the impact depends on the scope of access granted by the exposed secret, and the visibility of the repository.

Recommendation

Enable audit log streaming in GitHub to ensure relevant events are captured.
Deploy the Sigma rule “Github Push Protection Bypass Detected” to your SIEM and tune for your environment using GitHub audit logs.
Investigate any detected bypass events to determine the context and impact of the bypassed secret.

Detection of New GitHub Actions Secrets Creation

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

This detection identifies the creation of new secrets within GitHub Actions. Threat actors may create or modify secrets to gain unauthorized access, establish persistence, or escalate privileges within the GitHub environment. The activity is captured via GitHub’s audit logs. The scope of this detection encompasses the creation of secrets at the organization, environment, codespaces, or repository level. Successful detection of this activity allows security teams to investigate potentially malicious modifications to GitHub Actions secrets, which could lead to supply chain compromise or data exfiltration.

Attack Chain

An attacker gains initial access to a GitHub account, potentially through compromised credentials or phishing (T1078.004).
The attacker authenticates to the GitHub organization or repository.
The attacker navigates to the settings for the organization, environment, codespaces, or repository.
The attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.
The secret is stored within GitHub’s infrastructure, accessible to GitHub Actions workflows.
The attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.
The workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.
The attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, code injection, and supply chain compromise. The impact ranges from low, in cases where the secret is used for benign purposes, to critical if the secret is used to deploy malicious code into production environments. While the number of affected organizations is unknown, the potential for widespread impact across the software supply chain makes this a critical area for monitoring.

Recommendation

Enable GitHub audit log streaming to capture the events necessary for this detection (see logsource definition).
Deploy the Sigma rule Github New Secret Created to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule, focusing on the “actor” involved in creating the secret.

GitHub Repository Archive Status Changed

hello@craftedsignal.io — Thu, 04 Jan 2024 15:00:00 +0000

This threat brief focuses on the detection of unauthorized changes to GitHub repository archive status. Attackers may archive or unarchive repositories as a means of persistence, to impact the availability of resources, or to impair defenses by hiding malicious code. The activity is logged within GitHub’s audit logs and can be monitored to identify potentially malicious actions. Monitoring these events can help organizations identify and respond to unauthorized modifications of their GitHub repositories. This is especially relevant for organizations relying heavily on GitHub for code management and collaboration.

Attack Chain

An attacker gains unauthorized access to a GitHub account with repository administration privileges.
The attacker authenticates to the GitHub platform using the compromised credentials or a stolen session token.
The attacker navigates to the settings page of a target repository.
The attacker modifies the repository’s archive status, either archiving or unarchiving it depending on their objective.
GitHub logs the ‘repo.archived’ or ‘repo.unarchived’ action in the organization’s audit logs.
(If archiving) Legitimate users may lose access to the repository and its code, causing disruption.
(If unarchiving) The attacker might reintroduce vulnerable code or malicious content into an active repository.
The attacker may then attempt to exploit the unarchived repository for further malicious activities.

Impact

The impact of unauthorized repository archiving or unarchiving can range from temporary disruption of services to the reintroduction of vulnerable code. A successful attack could lead to data breaches, code compromise, or supply chain attacks. The number of affected repositories depends on the scope of the attacker’s access and objectives.

Recommendation

Deploy the Sigma rule “GitHub Repository Archive Status Changed” to your SIEM and tune for your environment. This rule detects the repo.archived and repo.unarchived actions in GitHub audit logs (logsource: github, service: audit).
Review GitHub audit logs regularly for unexpected repository archiving or unarchiving events.
Investigate any detected events to determine if the actions were authorized.

Detection of Command and Control Activity via Common Web Services

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

This detection rule, sourced from Elastic, identifies potential command and control (C2) activity by detecting connections to commonly abused web services. Adversaries often leverage popular web services like pastebin, GitHub, Dropbox, and Discord to mask malicious communications within legitimate network traffic. This technique makes it challenging for defenders to distinguish between normal user activity and malicious C2 traffic. The rule focuses on Windows systems and monitors DNS queries to identify processes communicating with a predefined list of services known to be abused by attackers. The rule was last updated on 2026-05-04 and is designed to work with data from Elastic Defend and SentinelOne Cloud Funnel. The goal is to identify anomalous network connections originating from unusual processes.

Attack Chain

A user on a Windows host unknowingly executes a malicious file (e.g., via phishing or drive-by download).
The malicious file executes a process outside of typical program directories (e.g., C:\Windows\Temp).
This process initiates a DNS query to a domain associated with a commonly abused web service (e.g., pastebin.com, githubusercontent.com).
The DNS query resolves to an IP address, and a network connection is established to the web service.
The malicious process uploads or downloads data from the web service, potentially containing commands for the compromised host or exfiltrated data.
The web service acts as an intermediary, relaying commands from the attacker to the compromised host or exfiltrated data from the compromised host to the attacker.
The attacker uses the C2 channel to perform further actions on the compromised host, such as lateral movement or data theft.

Impact

A successful attack using common web services for C2 can lead to data exfiltration, system compromise, and further propagation within the network. The low severity suggests a focus on detecting early-stage C2 activity, which if left unchecked, could escalate into a significant incident. The usage of popular web services makes detection difficult, requiring careful analysis and tuning to avoid false positives.

Recommendation

Deploy the Sigma rule “Connection to Commonly Abused Web Services” to your SIEM and tune it for your environment to minimize false positives.
Enable Sysmon DNS query logging to accurately capture DNS requests for improved detection capabilities, activating the “DNS Query to Commonly Abused Web Services” rule.
Investigate any alerts generated by this rule, focusing on the process execution chain and network connections to determine the legitimacy of the activity, referencing the investigation steps described in the rule documentation.
Review and update the list of excluded processes in the Sigma rule to reflect your organization’s approved software and reduce false positives.

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.

GitHub Self-Hosted Runner Configuration Changes Detected

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

This threat brief focuses on detecting changes to self-hosted runner configurations within GitHub environments. Self-hosted runners are systems deployed and managed by users to execute jobs from GitHub Actions, providing flexibility and control over the execution environment. Monitoring these runners is crucial because unauthorized modifications can lead to various malicious activities, including data collection, persistence, privilege escalation, or even initial access. The rule provided detects such changes based on audit logs, requiring administrators to validate the changes through the GitHub UI for complete context. Detecting these modifications early can help prevent or mitigate potential security breaches.

Attack Chain

An attacker gains unauthorized access to a GitHub organization or repository with permissions to manage self-hosted runners. This could be achieved through compromised credentials (T1078.004) or exploiting a vulnerability.
The attacker modifies the configuration of an existing self-hosted runner group or creates a new runner group (org.runner_group_created).
The attacker adds or removes runners from a runner group (org.runner_group_runners_added, org.runner_group_runner_removed, org.runner_group_updated).
Alternatively, the attacker registers a new self-hosted runner within the environment (repo.register_self_hosted_runner).
The attacker removes an existing self-hosted runner from the environment (repo.remove_self_hosted_runner, org.remove_self_hosted_runner).
The attacker uses the compromised runner or runner group to execute malicious code within the GitHub Actions workflow, potentially collecting sensitive data or escalating privileges.
The attacker leverages the compromised runner to establish persistence within the GitHub environment, ensuring continued access.
The attacker exploits the compromised runner to gain initial access to other systems or networks connected to the GitHub environment.

Impact

Compromised self-hosted runners can lead to a range of impacts, including data exfiltration, code injection, and privilege escalation within the targeted GitHub environment. Successful attacks could result in unauthorized access to sensitive repositories, modification of code, or deployment of malicious software. The impact can vary depending on the scope of the compromised runner and the permissions associated with it. The effects could extend beyond the GitHub environment if the compromised runner has access to other systems or networks.

Recommendation

Enable the audit log streaming feature in GitHub to capture events related to self-hosted runner modifications, as required by the logsource definition.
Deploy the Sigma rule “Github Self Hosted Runner Changes Detected” to your SIEM and tune for your specific environment to detect suspicious configuration changes.
Regularly review the audit logs in the GitHub UI to validate any detected changes to self-hosted runners and runner groups to ensure legitimate modifications.
Implement strict access control policies for managing self-hosted runners, limiting permissions to only authorized personnel.

Patreon OAuth Provider ID Collision Vulnerability in go-pkgz/auth

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

A critical vulnerability exists in the Patreon OAuth provider within the go-pkgz/auth and go-pkgz/auth/v2 libraries. Specifically, the mapUser function incorrectly maps all authenticated Patreon accounts to the same local user.ID, instead of generating unique IDs based on the Patreon account data. This flaw, present in versions 1.18.0 through 1.25.1 of go-pkgz/auth and 2.0.0 through 2.1.1 of go-pkgz/auth/v2, arises because the code hashes an uninitialized field instead of the Patreon user ID. This means that all Patreon users are effectively treated as a single identity within applications using these libraries. The vulnerability poses a significant risk to applications relying on token.User.ID for authentication and authorization decisions.

Attack Chain

A user attempts to authenticate with an application using the affected go-pkgz/auth library and the Patreon OAuth provider.
The application redirects the user to Patreon for authentication.
The user authenticates with Patreon and is redirected back to the application with an authorization code.
The application exchanges the authorization code for an access token.
The application uses the access token to retrieve the user’s Patreon profile data.
The application calls the vulnerable mapUser function within the go-pkgz/auth library to map the Patreon user to a local user. Due to the vulnerability, all users are mapped to the same local user ID: patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709.
The application stores the mapped user object in JWT claims.
Subsequent requests from different Patreon users are treated as coming from the same user, potentially leading to data leakage, privilege escalation, or account takeover.

Impact

This vulnerability can lead to severe consequences for applications using the affected libraries. If successful, all Patreon-authenticated users may be collapsed into a single local account. This can result in data associated with one Patreon user being exposed to or overwritten by another. Additionally, Patreon-specific attributes like subscription status can leak across unrelated users. If the application grants elevated privileges to the local account associated with the shared Patreon ID, those privileges can effectively apply to every Patreon login.

Recommendation

Upgrade go-pkgz/auth to a version higher than 1.25.1 or go-pkgz/auth/v2 to a version higher than 2.1.1 to patch CVE-2026-42560.
Review and update any existing applications using the vulnerable Patreon provider to ensure proper user ID mapping after patching CVE-2026-42560.
Deploy the Sigma rule “Patreon Auth ID Collision Attempt” to detect potential exploitation by monitoring for the specific user ID pattern patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709 in authentication logs.
Implement additional logging and monitoring to track user authentication events and identify any anomalies in user ID assignments.

Arcane Unauthenticated Compose Template Content Disclosure

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

Arcane versions prior to 1.18.0 are susceptible to an unauthenticated information disclosure vulnerability. The vulnerability stems from four GET endpoints under the /api/templates* path in Arcane’s Huma backend that lack any security requirements. This design flaw allows any unauthenticated network client to list and read the full Compose YAML and .env content of every custom template stored in the instance. This includes sensitive information such as database passwords, API keys, and other secrets stored verbatim from the operator’s environment variables due to the “Save as Template” workflow on project creation pages. This vulnerability poses a significant risk of exposing critical infrastructure secrets and internal service details.

Attack Chain

An attacker identifies an Arcane instance running a version prior to 1.18.0.
The attacker sends an unauthenticated GET request to /api/templates to enumerate available templates, revealing names, descriptions, and tags.
The attacker sends an unauthenticated GET request to /api/templates/{id}/content to retrieve the content of a specific template.
The Arcane backend processes the request without authentication, due to missing security requirements on these endpoints.
The backend retrieves the requested template content, including the Content and EnvContent fields from the database.
The backend returns the template content to the attacker, including sensitive environment variables stored in plain text within the EnvContent.
The attacker extracts sensitive information, such as database passwords, API keys, and registry tokens, from the EnvContent.
The attacker uses the exposed credentials to gain unauthorized access to internal systems and services.

Impact

Successful exploitation of this vulnerability allows an unauthenticated attacker to access sensitive information stored within Arcane templates. This includes database passwords, API keys, and other secrets, potentially leading to unauthorized access to critical systems and data. The enumeration of templates also reveals internal services and infrastructure details, aiding further reconnaissance. This vulnerability affects any Arcane instance running a version prior to 1.18.0 where operators have stored sensitive information in custom Compose templates.

Recommendation

Upgrade Arcane to version 1.18.0 or later to patch the vulnerability (CVE-2026-42461).
Deploy the following Sigma rule to detect suspicious access to the template content endpoints.
Review existing templates for sensitive information and rotate any exposed credentials immediately.
Implement network segmentation to limit access to the Arcane instance.

Masquerading Business Application Installers

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

Attackers often attempt to trick users into downloading and executing malicious executables by disguising them as legitimate business applications. This tactic is used to bypass security measures and gain initial access to a system. These malicious executables, often distributed via malicious ads, forum posts, and tutorials, mimic the names of commonly used applications such as Slack, WebEx, Teams, Discord, and Zoom. The executables are typically unsigned or signed with invalid certificates to further evade detection. This allows the attacker to execute arbitrary code on the victim’s machine, potentially leading to further compromise. This campaign aims to target end-users who are less security-aware, and this makes social engineering attacks like this very effective.

Attack Chain

The user visits a compromised website or clicks on a malicious advertisement.
The user is prompted to download an installer file masquerading as a legitimate business application (e.g., Slack, Zoom, Teams) from a download directory.
The downloaded executable is placed in the user’s Downloads folder (e.g., C:\Users*\Downloads*).
The user executes the downloaded file.
The executable, lacking a valid code signature, begins execution.
The malicious installer may drop and execute additional malware components.
The malware establishes persistence, potentially using techniques such as registry key modification.
The malware performs malicious activities, such as data exfiltration or lateral movement.

Impact

Successful execution of a masqueraded business application installer can lead to a complete system compromise. The attacker gains initial access and can deploy various malware payloads, including ransomware, keyloggers, and data stealers. This can result in data breaches, financial loss, and reputational damage. Although the specific number of victims and sectors targeted are not detailed, the widespread use of the applications being spoofed (Slack, Zoom, etc.) suggests a broad potential impact.

Recommendation

Implement the Sigma rule Potential Masquerading as Business App Installer to detect unsigned executables resembling legitimate business applications in download directories.
Enable process creation logging to capture the execution of unsigned executables.
Educate users on the risks of downloading and executing files from untrusted sources.
Implement application whitelisting to restrict the execution of unauthorized applications.
Regularly update endpoint detection and response (EDR) tools to detect and prevent the execution of known malware.
Monitor process execution events for processes originating from the Downloads folder that lack valid code signatures.