Using CI/CD pipelines to infiltrate without dropping a shell
Learn how CI/CD pipelines can be used to gain access to a target network without dropping any payloads.
In modern tech environments, especially in organizations that build software, there’s a much effective attack surface hiding in plain sight — the CI/CD pipeline. Instead of trying to break into systems with noisy payloads, red team operators can hijack the developer workflow to silently manipulate software and infrastructure, all without ever needing to drop a traditional shell.
CI/CD (Continuous Integration and Continuous Deployment) pipelines often have high privileges, secret keys, and direct access to production systems. They’re designed to run trusted code — but if you can manipulate what that code is or how it runs, you can take control of the environment without raising alarms.
Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.
A common entry point for this kind of attack is through a developer’s machine. If you can phish a developer, compromise a GitHub token, or get access to a personal access token for GitLab, you’re often just one step away from inserting code into the build pipeline. And the best part? You don’t need to execute any shellcode or spawn a beacon. You simply commit a few lines of code that get picked up by the next build.
For example, imagine a red team operator silently modifies a shared library used by multiple internal apps. The code might look harmless — maybe a minor version bump or a performance fix. But buried inside could be logic that exfiltrates secrets, logs user credentials, or disables security checks. Because the pipeline trusts the repository, the code is automatically built, tested, and deployed — turning your small change into a persistent, trusted backdoor.
Another tactic is to inject malicious logic into the build scripts themselves. Many teams use YAML files, Bash scripts, or Dockerfiles in their pipeline. A small tweak in a Dockerfile could cause the container to reach out to an attacker-controlled server during build time. Or you could add a step that silently uploads built artifacts to a third-party storage service. Since no shell was dropped, most endpoint detection tools won’t even blink.
One of the most interesting aspect of this attack style is how invisible it can be. The red team operator never needs to establish a network beacon, never needs to touch an endpoint after the initial compromise, and never needs to write malware in the traditional sense. They simply live off the land, leveraging the tools and automation the developers already use every day.
Defending against this type of attack is difficult because pipelines are complex and often not well-audited. Code reviews can help, but they’re not foolproof — especially when reviewing minor-looking changes in a large code-base.
Here’s a simple lab you can use to see this attack in action. Do try it out.
Red Team Notes
CI/CD pipelines provide an effective means to quietly hijack trusted systems like. These pipelines, often full of secrets and access to production, can be compromised via small code changes or script tweaks after phishing a developer or stealing access tokens. Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.