Stealing Secrets with n8n: A 48-Hour Red Team Supply-Chain Attack Playbook

In this playbook, I walk you through a 48-hour supply-chain attack that leveraged n8n to steal credentials from a corporate CI pipeline. I’ll explain the setup, the attack path, how I resolved the breach, and the lessons I learned from real case studies.

Setup: Target & n8n Overview

The target was a mid-size fintech company with a heavily automated CI/CD workflow. They used n8n, an open-source workflow automation tool, to trigger builds, run tests, and deploy code. My first step was to map their dependency graph and identify the external packages that n8n would consume.

I discovered that the company relied on a custom node library that pulled data from a third-party analytics service. That library was the weak link. I cloned the repository, examined the code, and identified an unsanitized endpoint that could be hijacked.

n8n’s flexibility made it a perfect target: it allows users to write custom JavaScript, load external modules, and connect to any API. By exploiting these features, I could embed malicious logic that would run inside the CI pipeline without triggering any alarms.

• Identify the automation tool and its extensions.
• Map the external dependencies of the workflow.
• Pinpoint unsanitized inputs and exposed endpoints.
• Plan for stealthy code injection.
• Prepare a backup for immediate remediation.

A 2023 Accenture study found that 70% of data breaches involved supply-chain compromise.

Conflict: The Attack Path

Once I had the entry point, I introduced a malicious node that executed during the build phase. The node silently captured environment variables, logged them to a remote server, and then forwarded them to me. Because the node was executed within the same context as the CI job, the credentials were already available and unencrypted.

To avoid detection, I used n8n’s built-in logging suppression. I also added a time delay so that the malicious payload would only fire after the pipeline had finished executing, thereby bypassing real-time monitoring.

Over the next 24 hours, I monitored the pipeline, tweaked the payload, and refined the data exfiltration process. By the 36th hour, the credentials were securely on my side, and the pipeline was back to normal, with no obvious signs of tampering.

Resolution: Credentials Stolen

The final act was a clean extraction of the stolen secrets. I leveraged a simple HTTP request to pull the captured credentials from the remote server. The data was structured in a JSON format, making it easy to parse and use for lateral movement.

After securing the data, I performed a quick audit of the company’s environment. I discovered that the same malicious node could be reused to elevate privileges or pivot into other services. I reported the findings to the security team, who patched the vulnerable library and revoked the stolen tokens.

From a tactical standpoint, the attack demonstrated how automation abuse can become a potent weapon in a supply-chain scenario. By using n8n’s extensibility, I turned a legitimate workflow into a covert data exfiltration tool.

Mini Case Studies

Case Study 1: A health-tech firm used n8n to sync patient data. An attacker inserted a custom node that logged API keys to an external server. Within 24 hours, the firm had lost access to its internal data lake.

Case Study 2: A SaaS provider employed n8n for automated billing. The attacker compromised the billing node, stealing customer payment tokens. The breach resulted in a $3M settlement.

Both examples underscore the need for strict code reviews and dependency checks when using automation platforms.

Real Examples from the Field

During my tenure as a founder, I worked with a startup that relied on n8n for deployment. We discovered a vulnerability where the platform would automatically load third-party modules from an untrusted source. The flaw allowed an attacker to inject malicious code that ran with elevated privileges.

We patched the issue by moving to a signed module registry and implementing a policy that required code signing before execution. The incident taught us that even open-source tools can become attack vectors if not properly governed.

These real examples show that the attack surface is larger than the surface of the code itself. It’s the automation layer that often becomes the gateway for attackers.

What I’d Do Differently

If I were to conduct this exercise again, I would start with a formal risk assessment of the automation platform. Instead of injecting malicious code directly, I would leverage a more sophisticated threat model that uses credential stuffing and lateral movement techniques.

Moreover, I would implement a continuous monitoring system that flags any unexpected changes to node configurations. That would help detect stealthy attacks in real time.

Finally, I would collaborate more closely with the DevSecOps team to create a policy that requires code signing for all custom nodes, ensuring that only vetted code can run in the CI environment.

What is n8n?

n8n is an open-source workflow automation tool that lets users create complex data pipelines using a visual interface and custom JavaScript nodes.

Why is a supply-chain attack dangerous?

Supply-chain attacks compromise trusted components, allowing attackers to infiltrate multiple targets with a single vulnerability, often bypassing traditional security controls.

How can I protect n8n pipelines?

Implement strict code reviews, use signed modules, enforce least privilege, and monitor node changes for suspicious activity.

What is credential theft?

Credential theft is the unauthorized acquisition of login information, such as usernames and passwords, often used to gain illicit access to systems.

How does automation abuse facilitate attacks?

Automation tools can be leveraged to execute malicious code at scale, bypass human oversight, and exfiltrate data quietly within legitimate processes.