JetBrains Cadence Breach via Unpatched TeamCity: Credential Rotation, Detection, and Hardening Guide

A critical TeamCity vulnerability. An unpatched server. A breached vendor. Stolen AWS credentials. The JetBrains Cadence incident is a textbook supply-chain lesson in why build infrastructure is now a tier-one attack surface — and why patch lag on CI/CD systems is no longer acceptable.

Introduction

JetBrains has disclosed that unidentified threat actors exploited a recently disclosed critical vulnerability in TeamCity — its continuous integration and build server platform — to breach JetBrains' own internal environment, compromising the Cadence cloud workflow orchestration service in the process. The attackers extracted AWS credentials from the environment, and JetBrains is now urging all Cadence users to immediately revoke and rotate every credential and secret that may have been used in their Cadence executions.

This is not a drill and it is not theoretical. A vendor that builds security tooling and developer infrastructure was compromised through its own build pipeline. If your organization uses Cadence, or runs TeamCity on-premises, or stores cloud credentials anywhere near CI/CD infrastructure, you are in scope for the defensive actions in this post.

The severity here is twofold: direct impact (Cadence customers must assume any secret passed to a Cadence execution is compromised) and systemic risk (the same exploitation path — unpatched TeamCity leading to cloud credential theft — is available to any threat actor against any organization still running a vulnerable TeamCity server).

Technical Analysis

Affected Products and Services

• JetBrains Cadence (cloud workflow orchestration service) — breached via JetBrains' own compromised environment. All Cadence users who passed credentials or secrets into executions are affected.
• JetBrains TeamCity (on-premises CI/CD server) — the initial access vector. A recently disclosed critical vulnerability in TeamCity was exploited against an unpatched instance. Organizations running internet-exposed or internally reachable TeamCity servers that have not applied the latest security updates should treat themselves as potentially compromised.
• AWS environments — the attackers specifically extracted AWS credentials from the breached environment, indicating deliberate targeting of cloud control-plane access.

Attack Chain (Defender's View)

While JetBrains has not published full forensic details at the time of this writing, the disclosed pattern is consistent with well-documented TeamCity exploitation tradecraft:

1. Initial access: Exploitation of a critical TeamCity vulnerability against an unpatched server. Recent critical TeamCity flaws have typically allowed unauthenticated remote code execution or authentication bypass against the server component — the exact class of bug that gives an attacker code execution in the context of the TeamCity server process (typically a JVM running the Tomcat-based web application).
2. Post-exploitation on the server: Code execution in the TeamCity server context. Observable behavior includes the TeamCity JVM spawning unexpected child processes (shells, scripting engines, downloaders), webshells being written into the TeamCity web application directories, and the creation of rogue TeamCity administrator accounts or unauthorized access tokens.
3. Credential harvesting: TeamCity servers are credential goldmines. Build configurations, environment variables, parameter stores, agent configurations, and integrated secret stores routinely contain cloud keys, VCS tokens, signing keys, and deployment credentials. The attackers extracted AWS credentials — whether from TeamCity-stored parameters, environment variables on the host, instance metadata service (IMDS) queries if the server ran on EC2, or adjacent configuration files.
4. Pivot into the Cadence environment: The stolen credentials enabled access to the environment backing the Cadence service, exposing customer secrets used in Cadence executions.

Exploitation Status

• Confirmed active exploitation. This is not a proof-of-concept scenario — JetBrains has confirmed a real breach of its production environment attributable to exploitation of the vulnerability.
• TeamCity vulnerabilities have a well-established history of rapid weaponization by both criminal and state-aligned actors within days of disclosure. Defenders should assume scanning and exploitation of any internet-facing unpatched instance is ongoing.

Why CI/CD Servers Are Prime Targets

Build servers sit at the intersection of source code, secrets, and deployment pipelines. Compromising one yields: (a) every secret the pipeline touches, (b) the ability to inject malicious code into software builds (supply-chain payload delivery), and (c) lateral movement paths into production cloud environments. The Cadence incident demonstrates all three risk categories materializing from a single unpatched server.

Detection & Response

The detections below target the observable behaviors of TeamCity server compromise: suspicious child processes of the TeamCity JVM, webshell placement in TeamCity web directories, rogue administrative account creation, and AWS credential access patterns. Tune thresholds to your environment — build agents legitimately spawn processes, but the TeamCity server process spawning interactive shells is almost never legitimate.

Sigma Rules

---
title: TeamCity Server Process Spawning Shell or Scripting Interpreter
id: 3f8c1a92-7b4e-4d1a-9c55-2e6f8a1b3d47
status: experimental
description: Detects the TeamCity server JVM spawning command shells or scripting interpreters, a strong indicator of post-exploitation activity following RCE against the TeamCity web application.
references:
  - https://thehackernews.com/2026/09/attackers-breached-jetbrains-cadence.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.execution
  - attack.t1059
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
  selection_parent_cmdline:
    ParentCommandLine|contains:
      - 'TeamCity'
      - 'teamcity-server'
      - 'catalina'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\certutil.exe'
      - '\curl.exe'
      - '\bitsadmin.exe'
  condition: selection_parent and selection_parent_cmdline and selection_child
falsepositives:
  - TeamCity build steps configured to run on the server node itself rather than agents (rare and discouraged); verify build configuration before whitelisting
level: high
---
title: Linux TeamCity Server Spawning Shell or Downloader
id: 9a2e5d17-4c6b-48f2-b1a3-7d9c4e5f2a81
status: experimental
description: Detects a TeamCity server Java process on Linux spawning interactive shells, download utilities, or base64-decoding pipelines consistent with webshell/RCE post-exploitation.
references:
  - https://thehackernews.com/2026/09/attackers-breached-jetbrains-cadence.html
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.execution
  - attack.t1059.004
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith: '/java'
  selection_parent_cmdline:
    ParentCommandLine|contains:
      - 'TeamCity'
      - 'teamcity-server'
      - 'catalina'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_parent_cmdline and selection_child
falsepositives:
  - Server-side build steps or health-check scripts executed by the TeamCity server service account; validate against configured build jobs
level: high
---
title: Webshell Dropped in TeamCity Web Application Directory
id: 5c1b7e40-2f8a-4d93-a6e1-9b3c6d8f4a52
status: experimental
description: Detects creation of JSP or script files inside TeamCity web application deployment directories, a common persistence mechanism after exploitation of the Tomcat-based TeamCity server.
references:
  - https://thehackernews.com/2026/09/attackers-breached-jetbrains-cadence.html
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\TeamCity\webapps\'
      - '\teamcity\webapps\'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.war'
      - '.asp'
      - '.aspx'
      - '.php'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate TeamCity upgrades and plugin deployments; correlate with scheduled maintenance windows and change tickets
level: high

KQL — Microsoft Sentinel / Defender

This query hunts across both Windows endpoint telemetry and Linux syslog for TeamCity server processes spawning suspicious children, plus rogue TeamCity administrator account creation events ingested via application logs. Deploy against Sysmon, Defender for Endpoint, and Syslog-ingested TeamCity audit logs.

// Hunt: TeamCity server process spawning shells/downloaders, and suspicious TeamCity auth events
let SuspiciousChildren = dynamic(["cmd.exe","powershell.exe","pwsh.exe","mshta.exe","rundll32.exe","certutil.exe","curl.exe","bitsadmin.exe","sh","bash","dash","curl","wget","python3","nc","ncat"]);
union isfuzzy=true
(DeviceProcessEvents
 | where InitiatingProcessFileName =~ "java.exe" or InitiatingProcessFileName =~ "java"
 | where InitiatingProcessCommandLine has_any ("TeamCity","teamcity-server","catalina")
 | where FileName in~ (SuspiciousChildren)
 | project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256),
(Syslog
 | where ProcessName =~ "java"
 | where SyslogMessage has_any ("TeamCity","catalina")
 | where SyslogMessage has_any ("/bin/sh","/bin/bash","curl ","wget ","base64 -d")
 | project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage),
(CommonSecurityLog
 | where ApplicationProtocol has "teamcity" or DeviceProduct has "TeamCity"
 | where Message has_any ("user created","create user","administrator","token created","access token")
 | project TimeGenerated, SourceIP, SourceUserName, DestinationHostName, Message)
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact across your fleet to identify TeamCity server instances exhibiting post-exploitation behavior, and to enumerate candidate webshell files written into TeamCity web directories within the last 30 days.

-- Hunt for TeamCity server post-exploitation: suspicious child processes and webshell artifacts
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (Name =~ '(?i)java' AND CommandLine =~ '(?i)teamcity|catalina')
   OR (CommandLine =~ '(?i)cmd\.exe|powershell|/bin/(ba)?sh|curl |wget |base64 -d'
       AND Username =~ '(?i)teamcity|tcuser')

-- Follow-up artifact: enumerate recently written script/webshell files in TeamCity webapps
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['C:/TeamCity/webapps/**/*.jsp','C:/TeamCity/webapps/**/*.war','/opt/teamcity/webapps/**/*.jsp','/opt/TeamCity/webapps/**/*.jsp','/home/teamcity/**/webapps/**/*.jsp'])
WHERE Mtime > (now() - 2592000)
ORDER BY Mtime DESC

Remediation and Verification Script

Run on each TeamCity server (Linux) to verify patch level, surface suspicious artifacts, and gather evidence before remediation. Review output before taking any destructive action — preserve forensic evidence first if you suspect compromise.

#!/bin/bash
# TeamCity compromise triage and hardening verification — Security Arsenal
# Run as root or with sudo. Evidence-preserving: read-only checks only.

echo "=== TeamCity installed version ==="
find / -maxdepth 4 -name "version.txt" -path "*eamCity*" 2>/dev/null -exec cat {} \;
grep -r "build.number" /opt/teamcity/conf/ 2>/dev/null | head -5
systemctl status teamcity 2>/dev/null | head -5

echo "=== Compare against latest release: https://www.jetbrains.com/teamcity/download/ ==="

echo "=== Suspicious child processes of TeamCity JVM (last boot) ==="
TC_PID=$(pgrep -f "teamcity-server|catalina.*teamcity" | head -1)
if [ -n "$TC_PID" ]; then
  echo "TeamCity server PID: $TC_PID"
  ps --ppid "$TC_PID" -o pid,ppid,user,cmd 2>/dev/null
else
  echo "TeamCity server process not found running."
fi

echo "=== Webshell candidates in webapps (last 60 days) ==="
find /opt/teamcity /opt/TeamCity /home/teamcity -type d -name webapps 2>/dev/null | while read -r d; do
  find "$d" -type f \( -name "*.jsp" -o -name "*.war" -o -name "*.sh" \) -mtime -60 -ls
done

echo "=== TeamCity users with administrator privileges (check for rogue accounts) ==="
grep -ri "ROLE_ADMIN\|administrator" /opt/teamcity/system/ 2>/dev/null | head -20
ls -la /opt/teamcity/config/users.xml 2>/dev/null && grep -i "username" /opt/teamcity/config/users.xml 2>/dev/null | head -20

echo "=== Outbound connections from TeamCity process (unexpected egress?) ==="
ss -tnp 2>/dev/null | grep -i java

echo "=== Cloud credentials present on host (rotate ALL of these) ==="
ls -la /root/.aws/ /home/*/.aws/ 2>/dev/null
grep -rl "AWS_ACCESS_KEY\|aws_secret" /opt/teamcity/ 2>/dev/null | head -10

echo "=== IMDS exposure check (if running on EC2, ensure IMDSv2 is enforced) ==="
curl -s -m 2 http://169.254.169.254/latest/meta-data/ && echo "WARNING: IMDSv1 reachable" || echo "IMDS not reachable or v2 enforced"

echo "=== Triage complete. If any anomaly found: isolate host, capture memory, then patch + rotate all secrets. ==="

Remediation

For Cadence users (immediate — do this first):

1. Revoke and rotate every credential and secret ever passed to a Cadence execution. Per JetBrains' advisory: "Cadence users should immediately revoke or rotate all credentials and secrets that may have been used to run their Cadence executions." Treat this as a full compromise of your Cadence secret material: AWS keys, IAM role session policies, API tokens, database credentials, signing keys, VCS tokens — everything.
2. Audit AWS CloudTrail (and equivalent logs in other clouds) for any use of the rotated credentials from unrecognized principals, regions, or IP ranges — going back at least 30 days before the disclosure. Look for AssumeRole, GetCallerIdentity from unknown IPs, CreateAccessKey, and IAM policy modifications.
3. Review Cadence execution logs for unexpected workflow runs, modified workflow definitions, or executions you did not initiate.
4. Replace long-lived credentials with short-lived, role-based access (OIDC federation, IAM Roles Anywhere, instance profiles) wherever possible so a future credential leak has a bounded blast radius.

For TeamCity server operators:

1. Patch immediately. Update TeamCity to the latest available release. JetBrains publishes security updates and fixed-version details at https://www.jetbrains.com/teamcity/download/ and via its security bulletins at https://www.jetbrains.com/privacy-security/issues-fixed/. Verify your exact build number against the fixed versions in the current bulletin.
2. If you were running a vulnerable build and the server was network-reachable, assume compromise. Do not patch and move on. Triage using the script and detections above, review TeamCity audit logs for rogue admin users, unexpected access tokens, and modified build configurations, and rotate every secret stored in or accessible to the server.
3. Remove TeamCity from direct internet exposure. Place it behind a VPN or an authenticated reverse proxy with SSO. There is no defensible reason for a build server to be reachable from the open internet.
4. Enforce IMDSv2 on any EC2-hosted TeamCity server and scope instance role permissions to the minimum required — this directly blunts the AWS credential theft technique used in this incident.
5. Rotate all secrets stored in TeamCity: build parameters, environment variables, SSH keys, cloud credentials, VCS tokens, and any secrets in connected secret stores (Vault, AWS Secrets Manager) that TeamCity was authorized to read.
6. Hunt fleet-wide with the Sigma, KQL, and VQL content above. Exploitation attempts against TeamCity are frequently automated and indiscriminate; a server you forgot about is the one that gets hit.

Strategic actions for security leadership:

• Add CI/CD infrastructure to your critical-asset inventory with an explicit patch SLA measured in hours, not weeks, for critical CVEs. This incident happened because of patch lag at a security-mature vendor — your organization is not immune.
• Implement secret-scanning and egress alerting on build infrastructure. The TeamCity JVM should never initiate outbound connections to unknown destinations.
• Establish a vendor-compromise playbook: when a SaaS provider discloses a breach affecting customer secrets (as JetBrains has here), credential rotation and log review should be a same-day, pre-scripted operation — not an improvised one.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub