{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/github/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["pelicanplatform/pelican","github.com"],"_cs_severities":["critical"],"_cs_tags":["privilege-escalation","webui","pelican"],"_cs_type":"advisory","_cs_vendors":["Pelican","GitHub"],"content_html":"\u003cp\u003eOn 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 \u003ccode\u003eServer.UIAdminUsers\u003c/code\u003e where listed users haven\u0026rsquo;t logged in or \u003ccode\u003eServer.AdminGroups\u003c/code\u003e with \u003ccode\u003eIssuer.GroupSource\u003c/code\u003e set to \u003ccode\u003einternal\u003c/code\u003e where an admin hasn\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the Pelican WebUI by authenticating via OIDC.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a valid \u003ccode\u003eServer.UIAdminUsers\u003c/code\u003e username or \u003ccode\u003eServer.AdminGroups\u003c/code\u003e group name for an admin who has not yet logged into the WebUI.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts malicious database records designed to grant admin privileges upon subsequent login.\u003c/li\u003e\n\u003cli\u003eThe attacker injects these records into the Pelican server\u0026rsquo;s SQLite database, potentially using API endpoints or other methods to interact with the database.\u003c/li\u003e\n\u003cli\u003eThe attacker logs out of the WebUI.\u003c/li\u003e\n\u003cli\u003eThe attacker logs back into the WebUI.\u003c/li\u003e\n\u003cli\u003eThe server grants the attacker admin privileges based on the manipulated database records.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies server configurations, creates persistent API tokens, or changes admin passwords.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eRun the provided mitigation script (\u003ccode\u003emitigate-user-escalation.sh\u003c/code\u003e from \u003ca href=\"https://gist.github.com/jhiemstrawisc/8c4b2b3ec5cb2ca06537d9439dc16cc9\"\u003ehttps://gist.github.com/jhiemstrawisc/8c4b2b3ec5cb2ca06537d9439dc16cc9\u003c/a\u003e) to audit the database for signs of exploitation and block further exploitation.\u003c/li\u003e\n\u003cli\u003eUpgrade Pelican servers to a patched release (\u0026gt;=v7.21.5, \u0026gt;=v7.22.3, \u0026gt;=v7.23.3, \u0026gt;=v7.24.2).\u003c/li\u003e\n\u003cli\u003eIf unable to upgrade immediately, disable the vulnerable configuration by commenting out \u003ccode\u003eUIAdminUsers\u003c/code\u003e and \u003ccode\u003eAdminGroups\u003c/code\u003e settings in the \u003ccode\u003epelican.yaml\u003c/code\u003e configuration file.\u003c/li\u003e\n\u003cli\u003eMonitor process executions for the \u003ccode\u003emitigate-user-escalation.sh\u003c/code\u003e script and review associated user and API token changes. Deploy the provided Sigma rule to detect potential malicious activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T21:24:50Z","date_published":"2026-05-04T21:24:50Z","id":"/briefs/2026-05-pelican-privesc/","summary":"A privilege escalation vulnerability in Pelican WebUI versions v7.21 to v7.24 allows authenticated users to gain admin privileges by manipulating database records, potentially leading to configuration modification, API token creation, and password changes.","title":"Pelican Web UI Privilege Escalation Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-05-pelican-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["gotenberg/gotenberg/v8"],"_cs_severities":["medium"],"_cs_tags":["exiftool","file-manipulation","cve-2026-40893"],"_cs_type":"advisory","_cs_vendors":["github"],"content_html":"\u003cp\u003eGotenberg, 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 \u003ccode\u003eSystem:FileName\u003c/code\u003e. 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a Gotenberg instance (version 8.30.1 or earlier) exposed via HTTP.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a POST request to any Gotenberg endpoint that accepts the \u003ccode\u003emetadata\u003c/code\u003e field, such as \u003ccode\u003e/forms/pdfengines/metadata/write\u003c/code\u003e, \u003ccode\u003e/forms/chromium/convert/html\u003c/code\u003e, or \u003ccode\u003e/forms/libreoffice/convert\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe request includes a \u003ccode\u003efiles\u003c/code\u003e parameter with a PDF file (or any other supported file type).\u003c/li\u003e\n\u003cli\u003eThe request includes a \u003ccode\u003emetadata\u003c/code\u003e parameter, a JSON object containing malicious ExifTool tag names such as \u003ccode\u003eSystem:FileName\u003c/code\u003e and \u003ccode\u003eSystem:Directory\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eGotenberg\u0026rsquo;s \u003ccode\u003eexiftool.go\u003c/code\u003e validates the tag names against a blocklist but fails to normalize group prefixes, allowing \u003ccode\u003eSystem:FileName\u003c/code\u003e to bypass the check that would block \u003ccode\u003eFileName\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eExifTool receives the \u003ccode\u003eSystem:FileName\u003c/code\u003e and \u003ccode\u003eSystem:Directory\u003c/code\u003e tags and interprets them as \u003ccode\u003eFileName\u003c/code\u003e and \u003ccode\u003eDirectory\u003c/code\u003e, respectively.\u003c/li\u003e\n\u003cli\u003eExifTool renames and moves the uploaded file to the attacker-specified location within the container\u0026rsquo;s file system.\u003c/li\u003e\n\u003cli\u003eIf Gotenberg attempts to access the file after it has been moved, the server returns a 404 error, potentially disrupting service for other users.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch or upgrade to a version of Gotenberg greater than 8.30.1 to remediate CVE-2026-40893.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Gotenberg ExifTool Tag Blocklist Bypass\u003c/code\u003e to identify exploitation attempts based on the use of \u003ccode\u003eSystem:\u003c/code\u003e prefixed ExifTool tags.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Gotenberg FilePermissions Tag Abuse\u003c/code\u003e to detect abuse of the \u003ccode\u003eFilePermissions\u003c/code\u003e tag.\u003c/li\u003e\n\u003cli\u003eMonitor webserver logs for POST requests to the affected Gotenberg endpoints (\u003ccode\u003e/forms/pdfengines/metadata/write\u003c/code\u003e, \u003ccode\u003e/forms/chromium/convert/html\u003c/code\u003e, \u003ccode\u003e/forms/libreoffice/convert\u003c/code\u003e) containing the string \u003ccode\u003eSystem:FileName\u003c/code\u003e or \u003ccode\u003eFilePermissions\u003c/code\u003e in the request body.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T19:21:19Z","date_published":"2026-05-04T19:21:19Z","id":"/briefs/2026-05-gotenberg-exiftool-bypass/","summary":"Gotenberg is vulnerable to an ExifTool tag blocklist bypass, allowing unauthenticated attackers to rename, move, and modify permissions of files within the container by using group-prefixed tag names like 'System:FileName' or the 'FilePermissions' tag in HTTP requests.","title":"Gotenberg ExifTool Tag Blocklist Bypass via Group-Prefixed Tag Names","url":"https://feed.craftedsignal.io/briefs/2026-05-gotenberg-exiftool-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Defender XDR","Elastic Defend","Sysmon","Visual Studio Code"],"_cs_severities":["medium"],"_cs_tags":["command-and-control","vscode","remote-access-tools","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","GitHub","Elastic"],"content_html":"\u003cp\u003eThis detection focuses on identifying the misuse of Visual Studio Code\u0026rsquo;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 \u0026ldquo;tunnel\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the target system through unspecified means.\u003c/li\u003e\n\u003cli\u003eThe attacker downloads a portable version of Visual Studio Code (VScode) onto the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the VScode binary with the \u003ccode\u003etunnel\u003c/code\u003e command-line argument to initiate a remote tunnel session.\u003c/li\u003e\n\u003cli\u003eThe attacker specifies additional arguments such as \u003ccode\u003e--accept-server-license-terms\u003c/code\u003e to bypass license agreement prompts.\u003c/li\u003e\n\u003cli\u003eThe VScode tunnel attempts to establish a connection to a remote server, potentially a GitHub repository or a remote VScode instance controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eIf successful, the tunnel creates a persistent connection, allowing the attacker to execute commands and transfer files.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the established tunnel to remotely access the compromised system, enabling them to perform malicious activities such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access through the established tunnel, allowing for long-term command and control of the compromised system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Attempt to Establish VScode Remote Tunnel\u0026rdquo; rule to detect suspicious VScode tunnel activity in your environment.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process-creation logging to capture the necessary process execution data.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the rule, focusing on the command-line arguments and process behaviors to confirm malicious intent.\u003c/li\u003e\n\u003cli\u003eMonitor network connections originating from VScode processes for unusual or unauthorized connections to external servers.\u003c/li\u003e\n\u003cli\u003eReview and whitelist legitimate uses of VScode\u0026rsquo;s tunnel feature by authorized developers to reduce false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-09-vscode-tunnel/","summary":"The rule detects the execution of the VScode portable binary with the tunnel command line option, potentially indicating an attempt to establish a remote tunnel session to Github or a remote VScode instance for unauthorized access and command and control.","title":"Detection of VScode Remote Tunneling for Command and Control","url":"https://feed.craftedsignal.io/briefs/2024-09-vscode-tunnel/"},{"_cs_actors":["TeamPCP"],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["@bitwarden/cli (2026.4.0)","@cap-js/sqlite (2.2.2)","@cap-js/postgres (2.2.2)","@cap-js/db-service (2.10.1)","mbt (1.2.48)","SAP Cloud Application Programming (CAP) Model","checkmarx/kics"],"_cs_severities":["high"],"_cs_tags":["npm","supply-chain","credential-theft","github"],"_cs_type":"threat","_cs_vendors":["npm","GitHub","SAP","Bitwarden","Checkmarx","Microsoft"],"content_html":"\u003cp\u003eThe 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 \u0026ldquo;Shai-Hulud: The Third Coming,\u0026rdquo; and the other, dubbed \u0026ldquo;Mini Shai-Hulud,\u0026rdquo; targeted the SAP developer ecosystem. The compromised packages are often part of SAP\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Compromise: Attackers compromise legitimate npm packages, such as @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt, by injecting malicious code.\u003c/li\u003e\n\u003cli\u003eMalicious Code Injection: Compromised packages receive two new files: setup.mjs and execution.js, along with a modified package.json containing a \u0026ldquo;preinstall\u0026rdquo; hook.\u003c/li\u003e\n\u003cli\u003eExecution of setup.mjs: During the \u003ccode\u003enpm install\u003c/code\u003e process, the preinstall hook executes setup.mjs, which detects the host OS and architecture.\u003c/li\u003e\n\u003cli\u003eBun Runtime Download and Execution: setup.mjs downloads the Bun JavaScript runtime (v1.3.13) from GitHub releases and extracts it to a temporary directory.\u003c/li\u003e\n\u003cli\u003eExecution of execution.js: The Bun runtime executes execution.js, a large (11.7 MB) obfuscated credential stealer and propagation framework.\u003c/li\u003e\n\u003cli\u003eCredential 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.\u003c/li\u003e\n\u003cli\u003eData Exfiltration: The collected data is compressed, encrypted, and exfiltrated to freshly created public GitHub repositories with randomized names and descriptions.\u003c/li\u003e\n\u003cli\u003ePropagation: The malware searches for commits containing the keyword \u0026ldquo;OhNoWhatsGoingOnWithGitHub,\u0026rdquo; decodes matching commit messages as a token dead-drop, recovers stolen GitHub tokens, and uses them to spread the malware to other packages.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eRotate 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).\u003c/li\u003e\n\u003cli\u003eMonitor npm install processes for unexpected execution of \u003ccode\u003enode setup.mjs\u003c/code\u003e (see Attack Chain).\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Detect Suspicious Bun Process Execution\u0026rdquo; to identify potential execution of the Bun runtime from temporary directories.\u003c/li\u003e\n\u003cli\u003eMonitor network connections for unusual processes connecting to \u003ccode\u003eapi.github[.]com/search/commits?q=OhNoWhatsGoingOnWithGitHub\u003c/code\u003e (see IOCs) to detect potential C2 activity.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Github Commit By Claude Email\u0026rdquo; to identify commits authored with the email \u003ccode\u003eclaude@users.noreply.github.com\u003c/code\u003e to detect malicious commits.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-02T00:10:33Z","date_published":"2026-05-02T00:10:33Z","id":"/briefs/2026-05-npm-supply-chain/","summary":"Threat actors are compromising npm packages, including those targeting SAP developers, to steal credentials, embed themselves in CI/CD pipelines, and deploy multi-stage payloads using techniques like wormable propagation and covert C2 channels on GitHub.","title":"Increased npm Supply Chain Attacks Targeting SAP Developers","url":"https://feed.craftedsignal.io/briefs/2026-05-npm-supply-chain/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["pytorch-lightning"],"_cs_severities":["critical"],"_cs_tags":["supply-chain","pypi","credential-theft","malware"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eOn April 30, 2026, two malicious versions (2.6.2 and 2.6.3) of the widely used \u003ccode\u003epytorch-lightning\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker compromises the publisher account for the \u003ccode\u003epytorch-lightning\u003c/code\u003e package on PyPI.\u003c/li\u003e\n\u003cli\u003eAttacker publishes malicious versions 2.6.2 and 2.6.3 to PyPI.\u003c/li\u003e\n\u003cli\u003eA modified \u003ccode\u003e__init__.py\u003c/code\u003e file within the package initiates a background process upon import.\u003c/li\u003e\n\u003cli\u003eThe background process executes silently, without any visible output or indication of compromise to the user.\u003c/li\u003e\n\u003cli\u003eThe malicious package downloads a runtime (Bun) from GitHub.\u003c/li\u003e\n\u003cli\u003eThe package executes a large, obfuscated JavaScript file, targeting AWS, Azure, Google Cloud, GitHub, and local credential stores.\u003c/li\u003e\n\u003cli\u003eStolen credentials, including cloud provider keys, API tokens, and secrets, are exfiltrated to attacker-controlled infrastructure.\u003c/li\u003e\n\u003cli\u003eThe malware attempts to download and execute a second-stage payload from attacker-controlled infrastructure, expanding the scope of the attack.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eOrganizations that downloaded and used versions 2.6.2 or 2.6.3 of the \u003ccode\u003epytorch-lightning\u003c/code\u003e 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\u0026rsquo;s ability to download and execute secondary payloads further increases the potential impact.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately remove versions 2.6.2 and 2.6.3 of the \u003ccode\u003elightning\u003c/code\u003e package from all systems where they are installed (see overview).\u003c/li\u003e\n\u003cli\u003eAudit systems for unauthorized processes and review outbound network connections to detect potential compromises (see overview).\u003c/li\u003e\n\u003cli\u003eRotate 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).\u003c/li\u003e\n\u003cli\u003eImplement the \u003ccode\u003eDetect Suspicious PyPI Package Installation\u003c/code\u003e Sigma rule to identify potential malicious packages being installed in the future (see rules).\u003c/li\u003e\n\u003cli\u003eImplement the \u003ccode\u003eDetect Credential Harvesting via Bun\u003c/code\u003e Sigma rule to catch execution of the malicious JavaScript payload (see rules).\u003c/li\u003e\n\u003cli\u003ePin dependencies to known-good versions and verify package integrity before use to prevent future supply chain attacks (see references).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T00:45:31Z","date_published":"2026-05-01T00:45:31Z","id":"/briefs/2026-05-pytorch-lightning-compromise/","summary":"Compromised PyTorch Lightning packages versions 2.6.2 and 2.6.3 on PyPI contain malicious code to steal developer credentials from cloud and developer environments, and republish infected packages.","title":"Compromised PyTorch Lightning Packages on PyPI Steal Developer Credentials","url":"https://feed.craftedsignal.io/briefs/2026-05-pytorch-lightning-compromise/"},{"_cs_actors":["TeamPCP"],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Cloud Application Programming (CAP)","Cloud MTA Build Tool","@cap-js/db-service","@cap-js/postgres","@cap-js/sqlite","github.com"],"_cs_severities":["critical"],"_cs_tags":["supply-chain","npm","sap","credential-theft"],"_cs_type":"threat","_cs_vendors":["SAP","GitHub"],"content_html":"\u003cp\u003eThe 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: \u003ccode\u003embt 1.2.48\u003c/code\u003e, \u003ccode\u003e@cap-js/db-service 2.10.1\u003c/code\u003e, \u003ccode\u003e@cap-js/postgres 2.2.2\u003c/code\u003e, and \u003ccode\u003e@cap-js/sqlite 2.2.2\u003c/code\u003e. These packages, with over 500,000 combined weekly downloads, are essential for SAP\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises an NPM token, possibly exposed through CircleCI.\u003c/li\u003e\n\u003cli\u003eThe attacker injects a malicious \u003ccode\u003epreinstall\u003c/code\u003e script into the targeted SAP NPM packages (\u003ccode\u003embt\u003c/code\u003e, \u003ccode\u003e@cap-js/db-service\u003c/code\u003e, \u003ccode\u003e@cap-js/postgres\u003c/code\u003e, \u003ccode\u003e@cap-js/sqlite\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eWhen a user installs the compromised package, the \u003ccode\u003epreinstall\u003c/code\u003e script executes.\u003c/li\u003e\n\u003cli\u003eThe script fetches a Bun ZIP archive from a GitHub repository.\u003c/li\u003e\n\u003cli\u003eThe script extracts the Bun archive and executes the included Bun binary.\u003c/li\u003e\n\u003cli\u003eThe Bun binary steals local credentials, GitHub and NPM tokens, AWS, Azure, GCP, GitHub Action, and Kubernetes secrets.\u003c/li\u003e\n\u003cli\u003eThe stolen data is exfiltrated to public GitHub repositories with the description \u0026ldquo;A Mini Shai-Hulud has Appeared\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe malware propagates by modifying package tarballs, updating versions, repackaging them, and publishing them using stolen GitHub Actions tokens.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eOrganizations using SAP Business Technology Platform workflows, SAP CAP, or MTA-based deployment pipelines should immediately check if they installed the malicious package versions (\u003ccode\u003embt 1.2.48\u003c/code\u003e, \u003ccode\u003e@cap-js/db-service 2.10.1\u003c/code\u003e, \u003ccode\u003e@cap-js/postgres 2.2.2\u003c/code\u003e, \u003ccode\u003e@cap-js/sqlite 2.2.2\u003c/code\u003e) during the exposure window.\u003c/li\u003e\n\u003cli\u003eImplement network monitoring rules to detect connections to unusual GitHub repositories created to host stolen data. Monitor for repositories with the description \u0026ldquo;A Mini Shai-Hulud has Appeared\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eMonitor process execution for the execution of \u003ccode\u003ebun\u003c/code\u003e binaries in unusual or unexpected locations to identify systems where compromised packages were installed. Deploy the Sigma rule \u003ccode\u003eDetect Bun Execution From NPM Package\u003c/code\u003e to detect this behavior.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-30T14:27:36Z","date_published":"2026-04-30T14:27:36Z","id":"/briefs/2026-04-mini-shai-hulud/","summary":"The Mini Shai-Hulud campaign injected malicious code into SAP NPM packages, targeting credentials and cloud secrets related to SAP Cloud Application Programming (CAP) and SAP cloud deployment workflows, exfiltrating data through public GitHub repositories.","title":"Mini Shai-Hulud Supply Chain Attack Targets SAP NPM Packages","url":"https://feed.craftedsignal.io/briefs/2026-04-mini-shai-hulud/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defender","FortiGate","komari-agent"],"_cs_severities":["high"],"_cs_tags":["komari","backdoor","nssm","github","rat","reverse shell"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Fortinet","GitHub"],"content_html":"\u003cp\u003eHuntress 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 \u0026ldquo;Windows Update Service\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker establishes an SSLVPN session on a FortiGate device from IP address 45.153.34[.]132, authenticating as a legitimate user, [User 1].\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInternal Reconnaissance:\u003c/strong\u003e After establishing the VPN connection, the attacker\u0026rsquo;s workstation, identified as VM8514, begins enumerating the internal network from the tunnel IP 10.212.134[.]200.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e Using Impacket\u0026rsquo;s smbexec.py, the attacker enables Remote Desktop Protocol (RDP) on the target workstation, [REDACTED-WRKSTN].\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRDP Access:\u003c/strong\u003e The attacker establishes an interactive RDP session to [REDACTED-WRKSTN].\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence - Service Creation:\u003c/strong\u003e The attacker uses the Non-Sucking Service Manager (NSSM) to install the Komari agent as a persistent Windows service named \u0026ldquo;Windows Update Service\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAgent Download:\u003c/strong\u003e The Komari agent is downloaded from raw.githubusercontent[.]com/komari-monitor/komari-agent using a PowerShell one-liner executed directly on the system.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCommand and Control:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMaintain Access \u0026amp; Execute:\u003c/strong\u003e The attacker maintains SYSTEM-level access via the persistent Komari agent, enabling ongoing remote command execution and control over the compromised workstation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor FortiGate logs for SSLVPN sessions originating from suspicious IP addresses (45.153.34[.]132) and unusual ASN\u0026rsquo;s (ASN 51396) to detect potentially compromised credentials.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Detect Komari Agent Installation via PowerShell\u0026rdquo; to identify installations of the Komari agent.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for the execution of \u003ccode\u003enssm.exe\u003c/code\u003e installing a service named \u0026ldquo;Windows Update Service\u0026rdquo; to detect suspicious service installations.\u003c/li\u003e\n\u003cli\u003eBlock the domain raw.githubusercontent[.]com at the DNS resolver or web proxy to prevent the downloading of malicious tools and payloads.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-30T00:00:00Z","date_published":"2026-04-30T00:00:00Z","id":"/briefs/2026-04-komari-red/","summary":"Threat actors are abusing the Komari monitoring agent, a project hosted on GitHub, as a SYSTEM-level backdoor following initial access through compromised VPN credentials and lateral movement via Impacket.","title":"Komari Agent Abused as SYSTEM-Level Backdoor","url":"https://feed.craftedsignal.io/briefs/2026-04-komari-red/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["medium"],"_cs_tags":["github","audit","data-loss","impact"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eThis 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 (\u003ccode\u003ecodespaces.destroy\u003c/code\u003e), deleting environments (\u003ccode\u003eenvironment.delete\u003c/code\u003e), deleting projects (\u003ccode\u003eproject.delete\u003c/code\u003e), and destroying repositories (\u003ccode\u003erepo.destroy\u003c/code\u003e). 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains unauthorized access to a GitHub account with sufficient privileges. This could be achieved through compromised credentials or insider access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e The attacker escalates privileges within the GitHub organization to gain the necessary permissions to delete resources if they don\u0026rsquo;t already have them.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReconnaissance:\u003c/strong\u003e The attacker identifies valuable codespaces, environments, projects, or repositories within the GitHub organization that they intend to delete.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDeletion of Codespaces:\u003c/strong\u003e The attacker executes the \u003ccode\u003ecodespaces.destroy\u003c/code\u003e action, deleting a specific codespace instance, potentially disrupting development workflows.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDeletion of Environments:\u003c/strong\u003e The attacker executes the \u003ccode\u003eenvironment.delete\u003c/code\u003e action, removing a specific environment configuration, potentially affecting deployment processes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDeletion of Projects:\u003c/strong\u003e The attacker executes the \u003ccode\u003eproject.delete\u003c/code\u003e action, deleting a project board and its associated tasks, impacting project management.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDeletion of Repositories:\u003c/strong\u003e The attacker executes the \u003ccode\u003erepo.destroy\u003c/code\u003e action, permanently deleting a repository, leading to code loss and potential service disruption.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The deletion of critical resources disrupts development workflows, causes data loss, and potentially compromises the software development lifecycle.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s access and the criticality of the deleted resources.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable GitHub audit log streaming to capture the necessary events for detection (reference: logsource definition).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect \u003ccode\u003ecodespaces.destroy\u003c/code\u003e, \u003ccode\u003eenvironment.delete\u003c/code\u003e, \u003ccode\u003eproject.delete\u003c/code\u003e, and \u003ccode\u003erepo.destroy\u003c/code\u003e actions in the GitHub audit logs, and tune for your environment (reference: rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule to determine the legitimacy of the deletion activity and the actor involved (reference: rules, falsepositives).\u003c/li\u003e\n\u003cli\u003eValidate the \u0026ldquo;actor\u0026rdquo; field in the audit logs to ensure the deletion activity is performed by an authorized user (reference: falsepositives).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-28T10:00:00Z","date_published":"2026-04-28T10:00:00Z","id":"/briefs/2026-04-github-delete-action/","summary":"This brief focuses on detecting deletion actions within GitHub audit logs, specifically targeting the deletion of codespaces, environments, projects, and repositories, potentially indicating malicious activity or insider threats.","title":"Detection of Github Delete Actions in Audit Logs","url":"https://feed.craftedsignal.io/briefs/2026-04-github-delete-action/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["medium"],"_cs_tags":["github","ssh","certificate","initial-access","persistence","privilege-escalation","stealth","t1078.004"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eAttackers 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 \u003ccode\u003essh_certificate_authority.create\u003c/code\u003e or \u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e 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\u0026rsquo;s resources. The GitHub audit log streaming feature must be enabled to detect this activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to a GitHub organization, potentially through compromised credentials or social engineering.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker escalates their privileges to an organizational role capable of managing SSH certificate authorities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSSH Certificate Authority Creation:\u003c/strong\u003e The attacker creates a new SSH certificate authority within the GitHub organization (\u003ccode\u003essh_certificate_authority.create\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDisable SSH Certificate Requirement:\u003c/strong\u003e Alternatively, the attacker disables the requirement for members to use SSH certificates to access organization resources (\u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e). This action allows attackers to bypass security controls that enforce SSH certificate usage.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnauthorized Access:\u003c/strong\u003e The attacker utilizes the newly created SSH certificate authority or the disabled requirement to access repositories without proper authorization.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally within the GitHub organization, accessing additional repositories and resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Malicious Code Injection:\u003c/strong\u003e The attacker exfiltrates sensitive data or injects malicious code into the organization\u0026rsquo;s repositories.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker maintains persistent access by using the created SSH certificate authority or the disabled requirement for future unauthorized activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s access and the sensitivity of the compromised data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable the GitHub audit log streaming feature to capture SSH certificate configuration changes (logsource: github, service: audit, definition).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect \u003ccode\u003essh_certificate_authority.create\u003c/code\u003e or \u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e events in the GitHub audit logs (rule: Github SSH Certificate Configuration Changed).\u003c/li\u003e\n\u003cli\u003eRegularly review GitHub audit logs for any unauthorized modifications to SSH certificate configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T14:00:00Z","date_published":"2024-11-02T14:00:00Z","id":"/briefs/2024-11-github-ssh-cert-config-changed/","summary":"Attackers can modify SSH certificate configurations in GitHub organizations to gain unauthorized access, persist in the environment, escalate privileges, and operate stealthily.","title":"GitHub SSH Certificate Configuration Changed","url":"https://feed.craftedsignal.io/briefs/2024-11-github-ssh-cert-config-changed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub"],"_cs_severities":["high"],"_cs_tags":["github","security-configuration","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub account with organization owner or administrator privileges through compromised credentials or insider access.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GitHub organization or repository using the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the organization settings or repository settings, depending on the scope of the targeted security feature.\u003c/li\u003e\n\u003cli\u003eThe attacker disables advanced security features (e.g., \u003ccode\u003ebusiness_advanced_security.disabled_for_new_repos\u003c/code\u003e, \u003ccode\u003erepo.advanced_security_disabled\u003c/code\u003e) through the GitHub web interface or API.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker disables OAuth application restrictions (\u003ccode\u003eorg.disable_oauth_app_restrictions\u003c/code\u003e) to allow potentially malicious applications to access organizational data.\u003c/li\u003e\n\u003cli\u003eOr, the attacker disables the two-factor authentication requirement (\u003ccode\u003eorg.disable_two_factor_requirement\u003c/code\u003e) for the organization, weakening account security.\u003c/li\u003e\n\u003cli\u003eThe attacker may then proceed to exploit the weakened security posture to access sensitive repositories, modify code, or exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistent access by creating rogue OAuth applications or adding unauthorized users to the organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGithub High Risk Configuration Disabled\u003c/code\u003e to detect the disabling of critical security features by monitoring GitHub audit logs.\u003c/li\u003e\n\u003cli\u003eEnable audit log streaming as documented in the rule definition to ensure that the necessary logs are captured for detection.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of security feature disabling to determine if they are legitimate administrator actions or malicious activity.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all users, especially those with administrative privileges, and monitor for attempts to disable MFA.\u003c/li\u003e\n\u003cli\u003eRegularly review and validate GitHub organization and repository settings to ensure that security features are enabled and configured correctly.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-10-31T18:22:00Z","date_published":"2024-10-31T18:22:00Z","id":"/briefs/2024-11-github-security-disabled/","summary":"An administrator or privileged user disables critical security features within a GitHub organization or repository, potentially leading to increased risk of unauthorized access, data breaches, and persistent compromise.","title":"GitHub Security Feature Disablement","url":"https://feed.craftedsignal.io/briefs/2024-11-github-security-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["high"],"_cs_tags":["attack.defense-impairment","attack.t1685"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eThe disabling of GitHub\u0026rsquo;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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub account with administrative privileges for either an organization or a specific repository.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the security settings within the organization or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the \u0026ldquo;Secret scanning\u0026rdquo; feature or related settings (e.g., \u0026ldquo;Secret scanning for new repositories\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe attacker disables the secret scanning feature using the GitHub UI or API. This generates an audit log event.\u003c/li\u003e\n\u003cli\u003eThe attacker commits code containing secrets to the repository.\u003c/li\u003e\n\u003cli\u003eBecause secret scanning is disabled, the secrets are not detected or flagged by GitHub.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the committed secrets to gain unauthorized access to other systems or data.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, which could include data exfiltration, lateral movement, or service disruption.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Github Secret Scanning Feature Disabled\u0026rdquo; Sigma rule to your SIEM to detect unauthorized disabling of the feature (logsource: github, service: audit).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of secret scanning being disabled to determine if they were authorized administrative actions.\u003c/li\u003e\n\u003cli\u003eEnable audit log streaming to ensure the required logs are available (see logsource definition).\u003c/li\u003e\n\u003cli\u003eReview GitHub access controls to ensure that only authorized personnel have the ability to modify secret scanning settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-19T00:00:00Z","date_published":"2024-07-19T00:00:00Z","id":"/briefs/2024-07-github-secret-scanning-disabled/","summary":"Detection of the disabling of GitHub secret scanning at the business or repository level, potentially increasing the risk of exposed credentials and secrets.","title":"GitHub Secret Scanning Feature Disabled","url":"https://feed.craftedsignal.io/briefs/2024-07-github-secret-scanning-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub Enterprise Cloud"],"_cs_severities":["high"],"_cs_tags":["attack.defense-impairment","attack.t1685"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub account with administrative privileges, or a legitimate administrator performs the action.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the organization, enterprise, or repository settings in GitHub.\u003c/li\u003e\n\u003cli\u003eThe attacker locates the \u0026ldquo;Secret scanning\u0026rdquo; or \u0026ldquo;Push protection\u0026rdquo; configuration section.\u003c/li\u003e\n\u003cli\u003eThe attacker disables the push protection feature for the organization, enterprise, or specific repositories. This can be done via the GitHub UI or API.\u003c/li\u003e\n\u003cli\u003eGitHub audit logs record the event with the actions \u003ccode\u003ebusiness_secret_scanning_custom_pattern_push_protection.disabled\u003c/code\u003e, \u003ccode\u003ebusiness_secret_scanning_push_protection.disable\u003c/code\u003e, \u003ccode\u003eorg.secret_scanning_custom_pattern_push_protection_disabled\u003c/code\u003e, etc..\u003c/li\u003e\n\u003cli\u003eDevelopers unknowingly or intentionally commit code containing secrets or sensitive data to the affected repositories.\u003c/li\u003e\n\u003cli\u003eThe secrets are pushed to the remote repository without being blocked by push protection.\u003c/li\u003e\n\u003cli\u003eThe exposed secrets can be discovered by malicious actors, leading to account compromise, data breaches, or other security incidents.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Github Push Protection Disabled\u0026rdquo; to your SIEM and tune for your environment to detect when push protection is disabled.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of push protection being disabled in the GitHub audit logs (logsource: github, service: audit) to verify the legitimacy of the action.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all GitHub accounts, especially those with administrative privileges, to prevent unauthorized access.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit GitHub organization and repository settings to ensure that push protection is enabled and properly configured.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-03T12:00:00Z","date_published":"2024-05-03T12:00:00Z","id":"/briefs/2024-05-github-push-protection-disabled/","summary":"An administrator has disabled the GitHub push protection feature, potentially allowing secrets and other sensitive information to be pushed to repositories.","title":"GitHub Push Protection Disabled","url":"https://feed.craftedsignal.io/briefs/2024-05-github-push-protection-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Copilot","Cursor","GPT4All","Jan","LM Studio","Ollama","Windsurf","bunx","codex","claude","deno","gemini-cli","genaiscript","grok","koboldcpp","llama-cli","llama-server","npx","pnpm","qwen","textgen","yarn","Confluence Data Center"],"_cs_severities":["medium"],"_cs_tags":["genai","command and control","macos","network connection"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","Atlassian","GitHub"],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003e9050506c-df6d-4bdf-bc82-fcad0ef1e8c1\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAdversary compromises a GenAI tool on a macOS system through prompt injection, malicious MCP servers, or poisoned plugins.\u003c/li\u003e\n\u003cli\u003eThe compromised GenAI tool is configured to connect to an attacker-controlled domain for C2.\u003c/li\u003e\n\u003cli\u003eThe GenAI process initiates a network connection attempt to the unusual domain using standard web protocols (HTTP/HTTPS).\u003c/li\u003e\n\u003cli\u003eThe macOS system\u0026rsquo;s network stack resolves the attacker\u0026rsquo;s domain to its corresponding IP address.\u003c/li\u003e\n\u003cli\u003eThe GenAI process sends data to the attacker-controlled domain, potentially including sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the C2 channel to send commands to the compromised GenAI tool.\u003c/li\u003e\n\u003cli\u003eThe GenAI tool executes the commands, potentially leading to further compromise or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised GenAI tools can lead to data exfiltration, unauthorized access to sensitive information, and the establishment of persistent C2 channels within an organization\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;GenAI Process Connecting to Unusual Domain\u0026rdquo; to your SIEM and tune for your environment (see rule below).\u003c/li\u003e\n\u003cli\u003eEnable process creation and network connection logging on macOS endpoints to collect the data required for the Sigma rule.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the domain and the GenAI process\u0026rsquo;s behavior.\u003c/li\u003e\n\u003cli\u003eBlock any identified malicious domains at the network level (see query in the provided source).\u003c/li\u003e\n\u003cli\u003eReview the GenAI tool\u0026rsquo;s configuration for unauthorized MCP servers, plugins, or extensions that initiated the connection.\u003c/li\u003e\n\u003cli\u003eRegularly update the list of allowed domains in the Sigma rule\u0026rsquo;s filter to account for legitimate updates to GenAI tool infrastructure.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T14:22:30Z","date_published":"2024-05-02T14:22:30Z","id":"/briefs/2024-05-genai-unusual-domain/","summary":"This rule detects GenAI tools on macOS connecting to unusual domains, potentially indicating command and control activity, data exfiltration, or malicious payload retrieval following compromise via prompt injection, malicious MCP servers, or poisoned plugins.","title":"GenAI Process Connection to Unusual Domain on macOS","url":"https://feed.craftedsignal.io/briefs/2024-05-genai-unusual-domain/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["low"],"_cs_tags":["defense-impairment","t1685","github"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eThis alert detects when a GitHub user bypasses the push protection mechanism designed to prevent secrets from being committed to a repository. GitHub\u0026rsquo;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\u0026rsquo;s audit logs, provided that the audit log streaming feature is enabled.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eDeveloper attempts to commit code containing a secret to a GitHub repository.\u003c/li\u003e\n\u003cli\u003eGitHub\u0026rsquo;s push protection mechanism detects the secret and blocks the push.\u003c/li\u003e\n\u003cli\u003eThe developer intentionally bypasses the push protection, potentially using allowed administrative activities to circumvent the block.\u003c/li\u003e\n\u003cli\u003eThe code, including the secret, is successfully pushed to the repository.\u003c/li\u003e\n\u003cli\u003eThe secret becomes exposed within the repository\u0026rsquo;s history.\u003c/li\u003e\n\u003cli\u003eUnauthorized actors may discover the exposed secret by scanning the repository.\u003c/li\u003e\n\u003cli\u003eUnauthorized actors may use the exposed secret to gain unauthorized access to systems or data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable audit log streaming in GitHub to ensure relevant events are captured.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Github Push Protection Bypass Detected\u0026rdquo; to your SIEM and tune for your environment using GitHub audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected bypass events to determine the context and impact of the bypassed secret.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T12:00:00Z","date_published":"2024-04-29T12:00:00Z","id":"/briefs/2024-04-github-push-protection-bypass/","summary":"Detection of a GitHub user bypassing push protection, potentially leading to the exposure of secrets.","title":"GitHub Push Protection Bypass Detection","url":"https://feed.craftedsignal.io/briefs/2024-04-github-push-protection-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub Actions"],"_cs_severities":["low"],"_cs_tags":["github","persistence","privilege-escalation","initial-access"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a GitHub account, potentially through compromised credentials or phishing (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GitHub organization or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the settings for the organization, environment, codespaces, or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.\u003c/li\u003e\n\u003cli\u003eThe secret is stored within GitHub\u0026rsquo;s infrastructure, accessible to GitHub Actions workflows.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.\u003c/li\u003e\n\u003cli\u003eThe workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable GitHub audit log streaming to capture the events necessary for this detection (see \u003ccode\u003elogsource\u003c/code\u003e definition).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGithub New Secret Created\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the \u0026ldquo;actor\u0026rdquo; involved in creating the secret.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-github-secret-creation/","summary":"This analytic detects the creation of new GitHub Actions secrets at the organization, environment, codespaces, or repository level, potentially indicating malicious persistence or privilege escalation.","title":"Detection of New GitHub Actions Secrets Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-github-secret-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub"],"_cs_severities":["low"],"_cs_tags":["github","repository","archive","unarchive","persistence","impact","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub account with repository administration privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GitHub platform using the compromised credentials or a stolen session token.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the settings page of a target repository.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the repository\u0026rsquo;s archive status, either archiving or unarchiving it depending on their objective.\u003c/li\u003e\n\u003cli\u003eGitHub logs the \u0026lsquo;repo.archived\u0026rsquo; or \u0026lsquo;repo.unarchived\u0026rsquo; action in the organization\u0026rsquo;s audit logs.\u003c/li\u003e\n\u003cli\u003e(If archiving) Legitimate users may lose access to the repository and its code, causing disruption.\u003c/li\u003e\n\u003cli\u003e(If unarchiving) The attacker might reintroduce vulnerable code or malicious content into an active repository.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to exploit the unarchived repository for further malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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\u0026rsquo;s access and objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;GitHub Repository Archive Status Changed\u0026rdquo; to your SIEM and tune for your environment. This rule detects the \u003ccode\u003erepo.archived\u003c/code\u003e and \u003ccode\u003erepo.unarchived\u003c/code\u003e actions in GitHub audit logs (logsource: github, service: audit).\u003c/li\u003e\n\u003cli\u003eReview GitHub audit logs regularly for unexpected repository archiving or unarchiving events.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected events to determine if the actions were authorized.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T15:00:00Z","date_published":"2024-01-04T15:00:00Z","id":"/briefs/2024-01-github-repo-archive-status-changed/","summary":"Detection of GitHub repository archiving or unarchiving events, which could indicate malicious activity such as persistence, impact, or defense impairment.","title":"GitHub Repository Archive Status Changed","url":"https://feed.craftedsignal.io/briefs/2024-01-github-repo-archive-status-changed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","SentinelOne Cloud Funnel","OneDrive","Chrome","Opera","Fiddler","PowerToys","Vivaldi","Zen Browser","WaveBrowser","MicrosoftEdgeCP"],"_cs_severities":["low"],"_cs_tags":["command-and-control","webservice","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Microsoft","Google","BraveSoftware","Opera","Vivaldi","Wavesor Software","Discord","Telegram","Facebook","Trello","GitHub","Supabase"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user on a Windows host unknowingly executes a malicious file (e.g., via phishing or drive-by download).\u003c/li\u003e\n\u003cli\u003eThe malicious file executes a process outside of typical program directories (e.g., \u003ccode\u003eC:\\Windows\\Temp\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThis process initiates a DNS query to a domain associated with a commonly abused web service (e.g., \u003ccode\u003epastebin.com\u003c/code\u003e, \u003ccode\u003egithubusercontent.com\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe DNS query resolves to an IP address, and a network connection is established to the web service.\u003c/li\u003e\n\u003cli\u003eThe malicious process uploads or downloads data from the web service, potentially containing commands for the compromised host or exfiltrated data.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the C2 channel to perform further actions on the compromised host, such as lateral movement or data theft.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Connection to Commonly Abused Web Services\u0026rdquo; to your SIEM and tune it for your environment to minimize false positives.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon DNS query logging to accurately capture DNS requests for improved detection capabilities, activating the \u0026ldquo;DNS Query to Commonly Abused Web Services\u0026rdquo; rule.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eReview and update the list of excluded processes in the Sigma rule to reflect your organization\u0026rsquo;s approved software and reduce false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-common-web-services-c2/","summary":"This rule detects command and control (C2) communications that use common web services to hide malicious activity on Windows hosts by identifying network connections to commonly abused web services from processes outside of known legitimate program locations, indicating potential exfiltration or C2 activity blended with legitimate traffic.","title":"Detection of Command and Control Activity via Common Web Services","url":"https://feed.craftedsignal.io/briefs/2024-01-common-web-services-c2/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["gcloud","azd","gh","aws","kubectl","doctl","oci"],"_cs_severities":["high"],"_cs_tags":["credential-access","cloud","cli","token-harvesting"],"_cs_type":"advisory","_cs_vendors":["Elastic","Google","Microsoft","GitHub","DigitalOcean","Oracle"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system, possibly via compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a shell (cmd.exe, PowerShell, bash, etc.) to execute cloud CLI commands.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to list available credentials or tokens (e.g., \u003ccode\u003eaws configure list\u003c/code\u003e, \u003ccode\u003eaz account list\u003c/code\u003e, \u003ccode\u003ekubectl config view\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to print access tokens for various cloud providers (e.g., \u003ccode\u003egcloud auth print-access-token\u003c/code\u003e, \u003ccode\u003eaz account get-access-token\u003c/code\u003e, \u003ccode\u003egh auth token\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker uses credential harvesting commands across multiple cloud platforms within a short timeframe.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the harvested credentials to a remote location.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to access sensitive cloud resources and data.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement within the cloud environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;s ability to exploit them.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Multi-Cloud CLI Token and Credential Access Commands\u0026rdquo; to your SIEM to detect suspicious command-line activity related to cloud credential harvesting.\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eEsql.process_command_line_values\u003c/code\u003e in the rule output to identify the exact commands executed and determine if the activity was legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eCorrelate the detected activity with authentication, Kubernetes audit, and cloud API logs to confirm unauthorized access and misuse of printed tokens.\u003c/li\u003e\n\u003cli\u003eImplement monitoring and alerting for unusual CLI activity originating from user workstations or build servers, focusing on the CLIs mentioned in the Overview section.\u003c/li\u003e\n\u003cli\u003eFollow vendor-specific guidance to revoke compromised credentials, such as revoking tokens and rotating secrets, as outlined in the rule\u0026rsquo;s \u0026ldquo;Response and remediation\u0026rdquo; section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-multi-cloud-cli-token-harvesting/","summary":"This rule detects command-line activity indicative of credential access across multiple cloud platforms (GCP, Azure, AWS, GitHub, DigitalOcean, Oracle, Kubernetes), looking for specific commands used to print or access tokens and credentials, flagging hosts where multiple cloud targets are accessed within a five-minute window, suggesting potential credential harvesting activity.","title":"Multi-Cloud CLI Token and Credential Access via Command-Line Harvesting","url":"https://feed.craftedsignal.io/briefs/2024-01-multi-cloud-cli-token-harvesting/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub Actions"],"_cs_severities":["low"],"_cs_tags":["github","self-hosted-runner","audit-log","devops","supply-chain"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn 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.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the configuration of an existing self-hosted runner group or creates a new runner group (org.runner_group_created).\u003c/li\u003e\n\u003cli\u003eThe attacker adds or removes runners from a runner group (org.runner_group_runners_added, org.runner_group_runner_removed, org.runner_group_updated).\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker registers a new self-hosted runner within the environment (repo.register_self_hosted_runner).\u003c/li\u003e\n\u003cli\u003eThe attacker removes an existing self-hosted runner from the environment (repo.remove_self_hosted_runner, org.remove_self_hosted_runner).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised runner or runner group to execute malicious code within the GitHub Actions workflow, potentially collecting sensitive data or escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised runner to establish persistence within the GitHub environment, ensuring continued access.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the compromised runner to gain initial access to other systems or networks connected to the GitHub environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable the audit log streaming feature in GitHub to capture events related to self-hosted runner modifications, as required by the logsource definition.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Github Self Hosted Runner Changes Detected\u0026rdquo; to your SIEM and tune for your specific environment to detect suspicious configuration changes.\u003c/li\u003e\n\u003cli\u003eRegularly review the audit logs in the GitHub UI to validate any detected changes to self-hosted runners and runner groups to ensure legitimate modifications.\u003c/li\u003e\n\u003cli\u003eImplement strict access control policies for managing self-hosted runners, limiting permissions to only authorized personnel.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-github-runner-changes/","summary":"Detection of changes to self-hosted runner configurations in GitHub environments can indicate potential impact, discovery, collection, persistence, privilege escalation, initial access, or stealth activities.","title":"GitHub Self-Hosted Runner Configuration Changes Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-github-runner-changes/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["auth","auth/v2"],"_cs_severities":["critical"],"_cs_tags":["authentication","oauth","id_collision","vulnerability"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eA critical vulnerability exists in the Patreon OAuth provider within the \u003ccode\u003ego-pkgz/auth\u003c/code\u003e and \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e libraries. Specifically, the \u003ccode\u003emapUser\u003c/code\u003e function incorrectly maps all authenticated Patreon accounts to the same local \u003ccode\u003euser.ID\u003c/code\u003e, instead of generating unique IDs based on the Patreon account data. This flaw, present in versions 1.18.0 through 1.25.1 of \u003ccode\u003ego-pkgz/auth\u003c/code\u003e and 2.0.0 through 2.1.1 of \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e, 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 \u003ccode\u003etoken.User.ID\u003c/code\u003e for authentication and authorization decisions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user attempts to authenticate with an application using the affected \u003ccode\u003ego-pkgz/auth\u003c/code\u003e library and the Patreon OAuth provider.\u003c/li\u003e\n\u003cli\u003eThe application redirects the user to Patreon for authentication.\u003c/li\u003e\n\u003cli\u003eThe user authenticates with Patreon and is redirected back to the application with an authorization code.\u003c/li\u003e\n\u003cli\u003eThe application exchanges the authorization code for an access token.\u003c/li\u003e\n\u003cli\u003eThe application uses the access token to retrieve the user\u0026rsquo;s Patreon profile data.\u003c/li\u003e\n\u003cli\u003eThe application calls the vulnerable \u003ccode\u003emapUser\u003c/code\u003e function within the \u003ccode\u003ego-pkgz/auth\u003c/code\u003e library to map the Patreon user to a local user. Due to the vulnerability, all users are mapped to the same local user ID: \u003ccode\u003epatreon_da39a3ee5e6b4b0d3255bfef95601890afd80709\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application stores the mapped user object in JWT claims.\u003c/li\u003e\n\u003cli\u003eSubsequent requests from different Patreon users are treated as coming from the same user, potentially leading to data leakage, privilege escalation, or account takeover.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade \u003ccode\u003ego-pkgz/auth\u003c/code\u003e to a version higher than 1.25.1 or \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e to a version higher than 2.1.1 to patch CVE-2026-42560.\u003c/li\u003e\n\u003cli\u003eReview and update any existing applications using the vulnerable Patreon provider to ensure proper user ID mapping after patching CVE-2026-42560.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Patreon Auth ID Collision Attempt\u0026rdquo; to detect potential exploitation by monitoring for the specific user ID pattern \u003ccode\u003epatreon_da39a3ee5e6b4b0d3255bfef95601890afd80709\u003c/code\u003e in authentication logs.\u003c/li\u003e\n\u003cli\u003eImplement additional logging and monitoring to track user authentication events and identify any anomalies in user ID assignments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-patreon-auth-id-collision/","summary":"The Patreon OAuth provider in go-pkgz/auth and go-pkgz/auth/v2 maps every authenticated Patreon account to the same local user ID, leading to cross-account access, privilege confusion, and subscription-state leakage.","title":"Patreon OAuth Provider ID Collision Vulnerability in go-pkgz/auth","url":"https://feed.craftedsignal.io/briefs/2024-01-patreon-auth-id-collision/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Arcane (before 1.18.0)"],"_cs_severities":["high"],"_cs_tags":["information-disclosure","vulnerability","arcane"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eArcane versions prior to 1.18.0 are susceptible to an unauthenticated information disclosure vulnerability. The vulnerability stems from four \u003ccode\u003eGET\u003c/code\u003e endpoints under the \u003ccode\u003e/api/templates*\u003c/code\u003e path in Arcane\u0026rsquo;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 \u003ccode\u003e.env\u003c/code\u003e 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\u0026rsquo;s environment variables due to the \u0026ldquo;Save as Template\u0026rdquo; workflow on project creation pages. This vulnerability poses a significant risk of exposing critical infrastructure secrets and internal service details.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies an Arcane instance running a version prior to 1.18.0.\u003c/li\u003e\n\u003cli\u003eThe attacker sends an unauthenticated \u003ccode\u003eGET\u003c/code\u003e request to \u003ccode\u003e/api/templates\u003c/code\u003e to enumerate available templates, revealing names, descriptions, and tags.\u003c/li\u003e\n\u003cli\u003eThe attacker sends an unauthenticated \u003ccode\u003eGET\u003c/code\u003e request to \u003ccode\u003e/api/templates/{id}/content\u003c/code\u003e to retrieve the content of a specific template.\u003c/li\u003e\n\u003cli\u003eThe Arcane backend processes the request without authentication, due to missing security requirements on these endpoints.\u003c/li\u003e\n\u003cli\u003eThe backend retrieves the requested template content, including the \u003ccode\u003eContent\u003c/code\u003e and \u003ccode\u003eEnvContent\u003c/code\u003e fields from the database.\u003c/li\u003e\n\u003cli\u003eThe backend returns the template content to the attacker, including sensitive environment variables stored in plain text within the \u003ccode\u003eEnvContent\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts sensitive information, such as database passwords, API keys, and registry tokens, from the \u003ccode\u003eEnvContent\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the exposed credentials to gain unauthorized access to internal systems and services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Arcane to version 1.18.0 or later to patch the vulnerability (CVE-2026-42461).\u003c/li\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect suspicious access to the template content endpoints.\u003c/li\u003e\n\u003cli\u003eReview existing templates for sensitive information and rotate any exposed credentials immediately.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit access to the Arcane instance.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-arcane-template-disclosure/","summary":"Arcane versions before 1.18.0 are vulnerable to an unauthenticated information disclosure on four GET endpoints under `/api/templates*`, allowing unauthorized access to Compose YAML and `.env` content including sensitive secrets.","title":"Arcane Unauthenticated Compose Template Content Disclosure","url":"https://feed.craftedsignal.io/briefs/2024-01-arcane-template-disclosure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Slack","WebEx","Teams","Discord","WhatsApp","Zoom","Outlook","Thunderbird","Grammarly","Dropbox","Tableau","Google Drive","MSOffice","Okta","OneDrive","Chrome","Firefox","Edge","Brave","GoogleCloud Related Tools","Github Related Tools","Notion"],"_cs_severities":["medium"],"_cs_tags":["masquerading","defense-evasion","initial-access","malware","windows"],"_cs_type":"advisory","_cs_vendors":["Elastic","Slack","Cisco","Microsoft","Discord","Zoom","Mozilla","Grammarly","Dropbox","Tableau","Google","Okta","Brave","GitHub","Notion"],"content_html":"\u003cp\u003eAttackers 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe user visits a compromised website or clicks on a malicious advertisement.\u003c/li\u003e\n\u003cli\u003eThe user is prompted to download an installer file masquerading as a legitimate business application (e.g., Slack, Zoom, Teams) from a download directory.\u003c/li\u003e\n\u003cli\u003eThe downloaded executable is placed in the user\u0026rsquo;s Downloads folder (e.g., C:\\Users*\\Downloads*).\u003c/li\u003e\n\u003cli\u003eThe user executes the downloaded file.\u003c/li\u003e\n\u003cli\u003eThe executable, lacking a valid code signature, begins execution.\u003c/li\u003e\n\u003cli\u003eThe malicious installer may drop and execute additional malware components.\u003c/li\u003e\n\u003cli\u003eThe malware establishes persistence, potentially using techniques such as registry key modification.\u003c/li\u003e\n\u003cli\u003eThe malware performs malicious activities, such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u003ccode\u003ePotential Masquerading as Business App Installer\u003c/code\u003e to detect unsigned executables resembling legitimate business applications in download directories.\u003c/li\u003e\n\u003cli\u003eEnable process creation logging to capture the execution of unsigned executables.\u003c/li\u003e\n\u003cli\u003eEducate users on the risks of downloading and executing files from untrusted sources.\u003c/li\u003e\n\u003cli\u003eImplement application whitelisting to restrict the execution of unauthorized applications.\u003c/li\u003e\n\u003cli\u003eRegularly update endpoint detection and response (EDR) tools to detect and prevent the execution of known malware.\u003c/li\u003e\n\u003cli\u003eMonitor process execution events for processes originating from the Downloads folder that lack valid code signatures.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-masquerading-business-apps/","summary":"Attackers masquerade malicious executables as legitimate business application installers to trick users into downloading and executing malware, leveraging defense evasion and initial access techniques.","title":"Masquerading Business Application Installers","url":"https://feed.craftedsignal.io/briefs/2024-01-masquerading-business-apps/"}],"language":"en","title":"CraftedSignal Threat Feed — Github","version":"https://jsonfeed.org/version/1.1"}