Storm-3068 exploited a single leaked credential to move from source code repositories to full Azure AD control, demonstrating how identity gaps in CI/CD pipelines can become kingdom keys. The attack began with credential theft, progressed through token replay and privilege escalation in Azure DevOps, and ended with persistent access via forged SAML tokens and shadow admin roles. Organizations must treat pipeline identities as privileged assets and enforce strict conditional access, token protection, and least-privilege principles across development and cloud environments.
How the attack started with a leaked developer credential
Storm-3068 obtained a developer’s credential through phishing or credential dumping, gaining initial access to Azure DevOps repositories. The identity had broad permissions to read and modify code but was not treated as a privileged account despite its proximity to production pipelines. Once inside, the attackers searched for secrets embedded in source code, including connection strings, API keys, and service principal credentials hardcoded in configuration files.
They extracted a service principal credential used by an automated build pipeline to deploy resources to Azure. This service principal had Contributor rights on multiple subscriptions and was trusted by the pipeline to authenticate without interactive login. The attackers replayed this credential to authenticate as the service principal, bypassing MFA because the pipeline identity was excluded from conditional access policies.
With the service principal token, they created new Azure AD applications and assigned them the Application Administrator role, granting the ability to register and configure enterprise applications across the tenant. This step was critical because it allowed them to manipulate trust boundaries without triggering typical privileged role alerts.
How they escalated to identity infrastructure control
Using the Application Administrator role, Storm-3068 registered a malicious SAML-based enterprise application in Azure AD and configured it to issue tokens for any user in the tenant. They then forged a SAML token for a global administrator by exploiting the trust relationship between Azure AD and the application’s signing key, which they now controlled.
The forged token allowed them to authenticate as a global admin without needing the legitimate user’s password or triggering sign-in risk alerts, because the token appeared to come from a trusted application. They used this access to create shadow admin accounts, disable audit logging, and configure persistent backdoors via conditional access policies that excluded their malicious IPs.
Finally, they modified the default user consent settings to allow users to grant permissions to malicious applications, ensuring long-term persistence even if the initial foothold was detected. This chain turned a single developer credential leak into irreversible tenant-wide compromise.
Defensive steps to break the attack chain
Treat all pipeline and service identities as privileged: enforce MFA, conditional access, and just-in-time access for service principals and managed identities used in CI/CD. Remove broad permissions from development identities and enforce least privilege via role-based access control in Azure DevOps and GitHub.
Implement token protection policies to prevent token replay and theft, and enable identity threat detection to flag anomalous token usage, such as sign-ins from unusual locations or impossible travel. Scan repositories regularly for hardcoded secrets using automated tools like GitHub Advanced Security or Azure Purview.
Enforce strict application registration controls: require approval for new enterprise applications, disable user consent to risky permissions, and monitor for changes to application roles or SAML signing keys. Audit Azure AD for shadow administrators and review conditional access policies for exclusions that weaken security.
What to do next
Start by identifying all service principals and managed identities with Contributor or higher rights in your Azure subscriptions. Rotate their credentials immediately, apply conditional access policies that require MFA and compliant devices, and enforce least privilege by scoping permissions to specific resources. Treat your pipelines as privileged workloads — because attackers already do.
FAQ
Why are pipeline identities often overlooked in identity security strategies?
Pipeline identities are frequently excluded from MFA and conditional access policies to avoid disrupting automated workflows, creating a trusted bypass that attackers exploit. They are treated as service accounts rather than privileged assets despite their ability to deploy and modify cloud resources.
How can organizations detect forged SAML tokens in Azure AD?
Monitor for sign-ins from unfamiliar applications or locations, especially when using legacy authentication protocols. Enable Identity Protection risk detections for anomalous token issuance and review sign-in logs for applications issuing tokens for high-privilege users without corresponding user activity.
Source: Beyond source code: A path to the keys to the kingdom (Azure).
