/
← Voltar ao feed
high

Shai Hulud persistence on Jenkins host leads to AWS IAM escalation and Redshift data warehouse breach

1 fonte(s) · 1 atualização(ões) · publicado 26/06/2026 10:00 · coletado há 4 dias

FortiGuard Labs describes an intrusion in which a compromised Jenkins EC2 build host, tied to Shai Hulud persistence, was used to steal instance role credentials via IMDS and pivot into the victim's AWS environment. The actor used the credentials from external IPs, created an admin IAM user named cloudops-monitor, opened network paths to Aurora and Redshift, harvested warehouse secrets, and ran sustained Redshift Data API queries. Leadership reported a confirmed warehouse breach. FortiCNAPP detected the activity through a "Potentially Compromised Keys" incident with 1,095 observations. The article is a partial excerpt, so the initial compromise of the Jenkins host is not detailed here.

Detalhes técnicos

  • Credential theft: curl requests to the IMDS (169[.]254[.]169[.]254/latest/meta-data/iam/security-credentials/jenkins) on the Jenkins host. The role was then used from non-instance IPs (GetCallerIdentity, ListBuckets).
  • Operator infrastructure: unusual outbound connection from the build environment to 89[.]22[.]231[.]63:8080. The same IP later acted as source of the cloudops-monitor identity and privileged activity (bulk of activity after 06:35 UTC). User-agents suggest two groups (Fedora/Qubes AWS CLI and Ubuntu 26 AWS CLI), indicating multiple operators or a toolchain change.
  • Privilege escalation: CreateUser, AttachUserPolicy (AdministratorAccess) and CreateAccessKey for cloudops-monitor (T1078, T1098).
  • Infrastructure manipulation: security groups described as "CloudOps monitoring" allowing SSH from 0.0.0.0/0; staging EC2 instances; DescribeSubnets/DescribeRouteTables mapping of the production VPC; ModifyDBCluster (applyImmediately, attempted master password rotation) on Aurora PostgreSQL; ModifyCluster and AuthorizeSecurityGroupIngress on tcp/5439 for Redshift.
  • Credential access: hundreds of paginated ListSecrets calls, then GetSecretValue for names such as datawarehouse_redshift_* and truedata_reporting_redshift_*.
  • Collection/exfiltration: repeated GetClusterCredentials and about 90 ExecuteStatement cycles via Redshift Data API (SQL redacted in CloudTrail); inline policies exfil-s3-write and exfil-s3-full attached via PutRolePolicy to an analytics role; AssumeRole into a break-glass role with session names exfil, exfil10, exfil12; SSM SendCommand with AWS-RunShellScript on a managed EC2 instance.
  • SES staging: GetSendQuota, VerifyEmailIdentity, ListIdentities with corporate addresses, some from an in-account EC2, possibly preceding phishing, extortion or reputation damage.

Remediação

  • Immediately restrict or disable the Jenkins instance profile and isolate the runner when instance credentials are used from non-instance IPs.
  • Enforce IMDSv2 and limit role permissions on CI/CD hosts.
  • Hunt for IAM users like cloudops-monitor, exfil-* policies and exfil* session names, and inspect policy content rather than relying on naming.
  • Review security group changes (0.0.0.0/0 SSH, tcp/5439 rules), ModifyDBCluster/ModifyCluster calls, bulk ListSecrets/GetSecretValue, SSM SendCommand and SES identity verification.
  • Block 89[.]22[.]231[.]63 and rotate exposed secrets and warehouse credentials.

Linha do tempo

  1. feeds.fortinet.com ↗ · pub. 26/06/2026 10:00 · coletado 19/10 18:02 primeiro registro

    Shai Hulud persistence on Jenkins host leads to AWS IAM escalation and Redshift data warehouse breach

    ler a análise desta fonte

    FortiGuard Labs describes an intrusion in which a compromised Jenkins EC2 build host, tied to Shai Hulud persistence, was used to steal instance role credentials via IMDS and pivot into the victim's AWS environment. The actor used the credentials from external IPs, created an admin IAM user named cloudops-monitor, opened network paths to Aurora and Redshift, harvested warehouse secrets, and ran sustained Redshift Data API queries. Leadership reported a confirmed warehouse breach. FortiCNAPP detected the activity through a "Potentially Compromised Keys" incident with 1,095 observations. The article is a partial excerpt, so the initial compromise of the Jenkins host is not detailed here.

    Technical Details

    • Credential theft: curl requests to the IMDS (169[.]254[.]169[.]254/latest/meta-data/iam/security-credentials/jenkins) on the Jenkins host. The role was then used from non-instance IPs (GetCallerIdentity, ListBuckets).
    • Operator infrastructure: unusual outbound connection from the build environment to 89[.]22[.]231[.]63:8080. The same IP later acted as source of the cloudops-monitor identity and privileged activity (bulk of activity after 06:35 UTC). User-agents suggest two groups (Fedora/Qubes AWS CLI and Ubuntu 26 AWS CLI), indicating multiple operators or a toolchain change.
    • Privilege escalation: CreateUser, AttachUserPolicy (AdministratorAccess) and CreateAccessKey for cloudops-monitor (T1078, T1098).
    • Infrastructure manipulation: security groups described as "CloudOps monitoring" allowing SSH from 0.0.0.0/0; staging EC2 instances; DescribeSubnets/DescribeRouteTables mapping of the production VPC; ModifyDBCluster (applyImmediately, attempted master password rotation) on Aurora PostgreSQL; ModifyCluster and AuthorizeSecurityGroupIngress on tcp/5439 for Redshift.
    • Credential access: hundreds of paginated ListSecrets calls, then GetSecretValue for names such as datawarehouse_redshift_* and truedata_reporting_redshift_*.
    • Collection/exfiltration: repeated GetClusterCredentials and about 90 ExecuteStatement cycles via Redshift Data API (SQL redacted in CloudTrail); inline policies exfil-s3-write and exfil-s3-full attached via PutRolePolicy to an analytics role; AssumeRole into a break-glass role with session names exfil, exfil10, exfil12; SSM SendCommand with AWS-RunShellScript on a managed EC2 instance.
    • SES staging: GetSendQuota, VerifyEmailIdentity, ListIdentities with corporate addresses, some from an in-account EC2, possibly preceding phishing, extortion or reputation damage.

    Remediation

    • Immediately restrict or disable the Jenkins instance profile and isolate the runner when instance credentials are used from non-instance IPs.
    • Enforce IMDSv2 and limit role permissions on CI/CD hosts.
    • Hunt for IAM users like cloudops-monitor, exfil-* policies and exfil* session names, and inspect policy content rather than relying on naming.
    • Review security group changes (0.0.0.0/0 SSH, tcp/5439 rules), ModifyDBCluster/ModifyCluster calls, bulk ListSecrets/GetSecretValue, SSM SendCommand and SES identity verification.
    • Block 89[.]22[.]231[.]63 and rotate exposed secrets and warehouse credentials.