Pwn TeamCity in the Cloud

What this lab covers

You recover information from instance configuration, establish what your credentials permit, and use a build server's own functionality to obtain execution on it and reach the AWS environment behind it.

The theme matches the Jenkins lab, and it is worth seeing on a second platform because the underlying issue is architectural rather than product-specific. Build systems execute arbitrary code and hold deployment credentials.

It assumes no prior AWS or TeamCity experience.

How build server compromise works

EC2 user data is the script run at instance launch, retrievable from the instance metadata service. It is a frequent hiding place for bootstrap secrets, and anyone who can query the metadata endpoint, or who has credentials permitting the instance to be described, may be able to read it.

TeamCity, like every CI system, executes build steps that the project defines. This is the product working as intended, so the security boundary is not the build system's code but the access control on who may modify a build configuration.

Once execution is achieved on the build agent, the credentials available to it become the objective. Build agents in cloud environments typically hold an instance role or stored deployment credentials, which is what takes the compromise from one server into the cloud account.

How to detect this in your own environment

Alert on build configuration changes, particularly the addition of steps that make outbound network connections or run shell commands outside the normal build pattern. These are infrequent and reviewable.

Watch the build agent's cloud identity. Deployment activity is repetitive, so enumeration, secret access or unusual API calls from a build role are strong signals.

Monitor for user data access from unexpected processes and for describe calls against instances by identities that do not normally make them, which is the reconnaissance preceding this.

How to prevent it

Keep secrets out of user data. It is readable through the metadata service for the life of the instance and it is not a secret store, so bootstrap material belongs in a secrets manager with scoped access.

Require review for build configuration changes and restrict who may edit them, since that permission is equivalent to code execution with the agent's credentials.

Give build agents narrowly scoped, short-lived cloud credentials, ideally through workload identity federation, and separate agents by trust level so the least sensitive project does not run on an agent holding production access.

Real-world context

Build infrastructure has been a recurring target in supply chain incidents, because it holds both source code and deployment credentials while typically receiving less hardening than production.

TeamCity specifically has had significant vulnerabilities disclosed and exploited in recent years, including authentication bypass issues that led to widespread exploitation of internet-facing instances. That reinforces the general point: build servers should not be exposed, and they should be patched with production urgency.

The pattern maps to MITRE ATT&CK T1195 Supply Chain Compromise, T1552.001 Credentials In Files and T1078.004 Cloud Accounts.

Applying this at work

• Check whether your build servers are reachable from the internet and remove that exposure.
• Search your instance user data and launch templates for embedded secrets.
• Restrict and review who can modify build configurations.
• Replace stored deployment credentials on build agents with short-lived federated access.
• Patch build infrastructure on the same cadence as production, since it holds equivalent access.

Frequently asked questions

Why is build configuration access equivalent to code execution?

Because a build step runs whatever it is told to run, on the build agent, with the agent's credentials. Modifying a build configuration is therefore a supported way to execute arbitrary code in that context.

What is EC2 user data and why does it matter?

It is the script executed at instance launch, retrievable from instance metadata. It frequently contains bootstrap secrets and remains readable for the life of the instance, so it is a common early target.

How should build agents authenticate to the cloud?

With short-lived credentials from workload identity federation, scoped per pipeline. Long-lived credentials stored on a shared agent mean the least sensitive build has the same access as the most sensitive one.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.