CI/CD under attack: how an exposed credential reaches your cloud data

A compromised CI/CD pipeline is rarely the final attack. It's the entry point. Recent research from FortiGuard Labs showed, in technical detail, how a compromise chain associated with the Shai Hulud malware started from credentials exposed on a Jenkins server, escalated privileges within AWS and ended in suspicious activity against a Redshift data warehouse. The case is an accurate portrait of a problem that is already a reality in Brazilian companies: the development pipeline has become one of the most critical and least monitored assets in the security infrastructure.

Why CI/CD became a priority target

Continuous integration and delivery tools like Jenkins, GitLab CI, GitHub Actions and Azure DevOps concentrate enormous power: cloud credentials, API keys, repository access tokens, database secrets and, often, broad administrative permissions to automate deploys. That power is exactly what makes CI/CD attractive to attackers.

Unlike an isolated production server, a compromised pipeline offers:

• Silent persistence. Automated jobs run frequently and go unnoticed in voluminous logs.
• High-value credentials. Tokens used for deployment often have permissions well beyond what's needed.
• A direct path to the cloud. A pipeline that deploys to AWS, Azure or GCP already has, by definition, access to production resources.
• Low security visibility. Many DevOps teams treat CI/CD secrets as configuration, not as an attack surface.

In the case analyzed by FortiGuard Labs, the initial compromise exploited a credential exposed on a misconfigured Jenkins server. From there, the attacker was able to locate AWS access keys stored in the environment, escalate privileges within the account and, finally, reach Redshift resources, indicating an attempt to exfiltrate sensitive analytical data.

The anatomy of a chained attack

What makes this kind of incident particularly dangerous is the speed with which it moves between layers that normally belong to different teams: development, cloud infrastructure and data. A simplified model of the path followed in this kind of campaign is usually:

1. Initial compromise, generally via an exposed credential, a malicious dependency or a compromised open-source package (a pattern seen in Shai Hulud-related campaigns, which historically spread via npm packages).
2. Reconnaissance in the CI/CD environment, looking for environment variables, configuration files and secrets stored in clear text or in poorly protected vaults.
3. Privilege escalation in the cloud, using the found credentials to assume roles with permissions broader than the pipeline needs.
4. Lateral movement between services, reaching databases, storage buckets or data warehouses.
5. Exfiltration or persistence, with the attacker seeking valuable data or maintaining long-term access.

This chain is rarely detected by a single tool. It requires correlation between source-code events, cloud identity activity and anomalous behavior in data services, exactly the kind of view that point, disconnected solutions don't deliver.

The structural mistake: treating CI/CD as internal infrastructure

Many organizations still apply the "internal network is trusted" mindset to CI/CD environments. In practice, that means:

• Long-lived tokens instead of temporary credentials.
• Broad deploy permissions, without segregation by environment or service.
• Secrets accidentally versioned into repositories, sometimes for years, without rotation.
• Absence of security tests specific to the build and deploy chain.

This connects directly to the practice of pentest and red team. Traditional intrusion tests, focused only on web applications or network perimeter, fail to simulate exactly the fastest-growing vector: the compromise of the development chain and its connection to the cloud. A well-designed Pentest and Red Team exercise today needs to include scenarios of credentials exposed in pipelines, privilege escalation in IAM and lateral movement to data services, replicating exactly the kind of chain documented by FortiGuard Labs.

Vulnerability management can't stop at the code

Another critical point is that the CI/CD risk surface isn't limited to software vulnerabilities. It includes IAM configurations, secret-access policies, service-account permissions and the overall cloud security posture. A vulnerability management program that only deals with application CVEs is blind to this kind of exposure.

This is where the importance of a VOC (Vulnerability Operations Center) comes in, able to correlate technical findings with business context and prioritize what truly matters. ISA Insight was designed exactly for this: to consolidate vulnerabilities from multiple sources, including cloud and pipeline configurations, and turn that volume into a prioritized remediation plan, instead of an endless list of alerts no one can handle.

Detection matters when the attack is already in motion

When prevention fails, detection needs to be fast and contextual. An attack that leaves CI/CD and reaches Redshift involves multiple weak signals scattered across different layers: anomalous authentication in AWS, use of credentials outside the norm, unusual queries against a data warehouse. In isolation, these signals look like noise. Correlated, they tell a clear story of compromise.

This is exactly the kind of scenario where a SOC and MDR operating 24/7, with AI to correlate events across identity, cloud and data, makes a real difference in response time. The ISA Cyber platform was built to act precisely in this kind of multi-layer analysis, reducing the time between initial compromise and containment.

Practical recommendations to reduce this risk

A few concrete measures help close this attack route:

• Migrate to temporary, short-lived credentials in pipelines, avoiding static keys.
• Apply the principle of least privilege to service accounts and deploy roles, segregating by environment and by service.
• Store secrets in dedicated vaults (such as AWS Secrets Manager, HashiCorp Vault or GitHub Actions Secrets), never in clear text in the repository, and rotate them periodically.
• Continuously monitor cloud identity activity and correlate it with pipeline events, to detect anomalous credential use.
• Include the build and deploy chain in the scope of pentests and vulnerability management, not just the final applications.

None of these measures, on its own, eliminates the risk. What truly protects is the combination of credential hygiene, least privilege, cloud identity visibility and correlated detection, sustained by an operation that sees from code to data. The Shai Hulud → Redshift case is a reminder that the attacker doesn't respect the boundaries between teams: your defense can't respect them either.

Want to assess the exposure of your CI/CD pipeline and your cloud? Reach out at /empresa#contato and get to know Intelliway's AI-Driven SOC and VOC.