JetBrains TeamCity On-Premises — CVE-2026-63077

CVE-2026-63077 is a critical, unauthenticated remote code execution flaw in JetBrains TeamCity On-Premises. An attacker who can reach the server over HTTP(S) sends a crafted request to the agent polling protocol — the channel distributed build agents use to check in with the central server for job assignments — and the server deserializes attacker-controlled objects (CWE-502), bypassing authentication entirely and executing arbitrary operating system commands as the TeamCity server process. No credentials, no session, no user interaction.

Attacker objective. A TeamCity server is not just another web app: it holds the stored credentials, signing material, source access and deployment connections for everything the organisation builds. JetBrains states that successful exploitation "could expose TeamCity data, configurations, and stored credentials, modify server state, and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines." The realistic goal is therefore not the box — it is the secrets store and the build definitions, which convert one server compromise into a supply-chain foothold in every downstream artifact.

Highest-value defensive angle. Because the exploit runs commands as the server JVM, the most reliable, IOC-independent signal is the TeamCity server Java process becoming a parent of something it has no business parenting — a shell, an interpreter, a downloader, a discovery binary. On a correctly configured server (dedicated host, no co-located build agent, per vendor guidance) that parent-child edge should be effectively empty in a healthy environment, which makes Q1 and Q2 in this pack the two queries to run first.

Timeline. Reported privately to JetBrains on 2026-07-10 by researcher Antoni Tremblay. Vendor advisory published 2026-07-27 stating no known exploitation. CISA added the CVE to the Known Exploited Vulnerabilities catalog on 2026-08-05 with a federal remediation due date of 2026-08-08 under BOD 26-04, moving its exploitation assessment from "none" to "active" and rating the flaw both automatable and capable of total technical impact. Censys observed roughly 4,500 internet-reachable TeamCity web properties shortly after disclosure.

Honest scoping — read before you tune anything. As of 2026-08-06 there is no public attribution, no published exploitation scale, and no published atomic indicator of any kind — no C2 domains, no IP addresses, no file hashes, no actor name. The Hacker News states plainly that it is "currently not known how the vulnerability is being exploited in the wild, the identity of the threat actors behind the attacks, and the scale of such efforts," and JetBrains had not updated its advisory to confirm exploitation at the time of writing. This pack is therefore behavioral-first by necessity, not by preference. Every detection below keys on attacker behavior on the TeamCity host. The IOC table and the Falcon import CSV contain no atomic indicators, only clearly labelled REPLACE_WITH_ placeholders, because inventing them would be worse than having none.

Defender priority: patch to 2025.11.7 or 2026.1.3 (or apply the JetBrains security patch plugin) and assume pre-patch compromise on any instance that was internet-reachable between 2026-07-27 and the patch. Rotate every credential stored in the TeamCity secrets store and every token the server could reach — patching closes the door but does not evict an attacker who already read the vault.

Web-hunter decisions

• KEV date discrepancy resolved in favour of CISA. Several outlets refer to the KEV addition as "August 6". The CISA catalog itself records Date Added: 2026-08-05; that is the value used throughout this pack. 2026-08-06 is this pack's build date.
• No IOC extraction was possible. All twelve sources were searched for hashes, domains, IPs, URIs, user-agents, and file names attributable to exploitation. None publish any. No indicator has been synthesised to fill the gap.
• Historical TeamCity targeting is context, not attribution. Help Net Security and BleepingComputer both note that state-backed actors and ransomware affiliates have exploited earlier TeamCity flaws. That establishes the threat model and justifies urgency; it does not name an actor for this CVE and is not treated as attribution anywhere in this pack.
• Exploit mechanics are deliberately absent. No source publishes a PoC or wire-level detail of the polling-protocol request, and none is reconstructed here. Detection is built on post-exploitation host behavior, which is both available and more durable than a request signature.
• Single-source claims are labelled. The Censys ~4,500 exposure count and the fixed build numbers appear in one aggregator only and are marked Partial above.

Provenance note. The verbatim fetched text of every source cited in this pack is archived alongside it in TeamCity-CVE-2026-63077-Hunt-sources/, one file per source, so that any indicator or claim can be traced back to the page it came from.

Hunt hypotheses (ordered by fidelity)

Attack chain

There are no public atomic indicators for CVE-2026-63077 as of 2026-08-06. No vendor, government or press source consulted publishes a hash, domain, IP, URI or user-agent tied to exploitation of this CVE. The rows below are therefore version and behavioral indicators — the things that are actually knowable today. No hash, domain or IP has been invented to pad this table.

These cover the chain steps Falcon cannot see. Several are the only coverage for their step — treat them as required, not optional.

N1 · External exposure inventory

Enumerate every TeamCity HTTP(S) endpoint reachable from outside the trusted network — from your external attack-surface tooling, perimeter firewall rules, and reverse-proxy vhosts. JetBrains warns that even exposing the login screen or REST API gives attackers an entry point. Cross-check the result against Q7 and Q8 to find servers the patching programme does not know about.

N2 · Reverse-proxy / Tomcat access-log review for the exploitation window

No public request signature exists, so this is a retrospective anomaly review rather than a signature search. On every TeamCity server, pull access logs for 2026-07-27 through the patch date and look for: requests to agent-polling paths from source addresses that are not registered build agents; unauthenticated requests that returned 200 where 401/403 was expected; bursts from a single source across many endpoints; and any request immediately preceding one of the Q1/Q2 process events by timestamp.

# Correlate: for each Q1/Q2 hit, pull proxy log lines within +/- 60s on that host.
# Adjust the log path to your deployment (nginx / Apache / Tomcat localhost_access_log).
awk -v t1="27/Jul/2026" '$0 ~ t1' /var/log/nginx/teamcity-access.log \
  | grep -viE ' (401|403) ' \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -50
# Then diff the top source IPs against your registered build-agent inventory.

N3 · TeamCity audit log review

In the TeamCity UI, Administration | Audit. For the window from 2026-07-27 to now, review: new or modified user accounts, especially system administrators; access-token creation; role assignments; changes to authentication settings; and any action attributed to the super user. The vendor documents that the super-user token is printed to logs/teamcity-server.log — an attacker with file read on the host has an administrator login without touching a password.

N4 · Data-directory file integrity (covers the webshell gap)

Falcon's file-write events cover PE, ELF, JAR and ZIP writes but not .jsp, .jspx, .xml or .properties. That is precisely the webshell case, so it must be covered at the OS level.

# Linux — files modified in the data directory and web app tree since the advisory date
find "${TEAMCITY_DATA_PATH:-$HOME/.BuildServer}" /opt/TeamCity/webapps \
     -newermt "2026-07-27" -type f \
     \( -name '*.jsp' -o -name '*.jspx' -o -name '*.war' -o -name '*.jar' -o -name '*.zip' -o -name '*.sh' \) \
     -printf '%TY-%Tm-%Td %TH:%TM  %u  %p\n' 2>/dev/null | sort

# Windows (PowerShell) — same idea
$dd = $env:TEAMCITY_DATA_PATH; if (-not $dd) { $dd = "$env:USERPROFILE\.BuildServer" }
Get-ChildItem -Path $dd,'C:\TeamCity\webapps' -Recurse -File -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -ge '2026-07-27' -and $_.Extension -match '^\.(jsp|jspx|war|jar|zip|ps1|bat)$' } |
  Select-Object LastWriteTime, Length, FullName | Sort-Object LastWriteTime

N5 · Build configuration tamper review (supply-chain step — no EDR coverage)

Build definitions live as XML under .BuildServer/config/<projectID>/buildTypes/. If the vendor's Administration | Configs Repository feature is enabled, every settings change is already a git commit — diff it. If it is not enabled, enable it now (hardening N-2) and compare the current config tree against your most recent backup in the meantime.

# If the configs repository is enabled, review every settings commit since the advisory:
git -C /path/to/teamcity-config-repo log --since=2026-07-27 --stat

# Otherwise diff config against the last known-good backup:
diff -ruN /backups/teamcity/last-known-good/config "${TEAMCITY_DATA_PATH}/config" | head -200
# Focus on: new build steps, changed command-line runners, new parameters
# holding URLs or credentials, and edits to project-config.xml / *.xml under buildTypes/.

N6 · Downstream credential and artifact review

Every credential the TeamCity server could reach must be treated as disclosed on any instance assessed as compromised. Review the audit logs of each downstream system for use of those credentials from unfamiliar sources since 2026-07-27: VCS hosting (new deploy keys, force pushes, tag rewrites), artifact registries (unexpected publishes or re-publishes), cloud providers (new access keys, role assumptions), and container registries (image pushes outside pipeline windows). Compare published artifact digests against build records.

Run order: Q7 and Q8 first to scope which hosts are even in play, then Q1 and Q2 for the primary compromise signal, then Q6, Q3, Q4, Q5 for post-exploitation. Q9 is a blast-radius question, not a detection. None of these queries carries an in-query time filter — set the window with the console time picker (7 days minimum; 2026-07-27 onward for a retrospective sweep).

// HUNT: TeamCity server JVM spawns an OS command shell (CVE-2026-63077 post-exploitation)
// MITRE: T1190, T1059.001, T1059.003, T1059.004
// CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2 (Windows and Linux sensors)
// FALSE POSITIVES: server-side TeamCity plugins that legitimately invoke a shell; a
//   maintenance script started by an admin from inside the server JVM tree.
// TUNING: baseline 30 days, then exclude the specific ParentCommandLine + FileName +
//   CommandLine triples that recur daily; exclude hosts confirmed to run a build agent
//   under the SERVER jvm (unsupported config) by ComputerName.
// LOOKBACK: set the window in the console time picker; use 2026-07-27 onward to sweep retrospectively
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| ParentBaseFileName=/^java(\.exe)?$/i
| ParentCommandLine=/(teamcity-server|teamcity\.server|catalina|BuildServer|bootstrap\.jar|TeamCity)/i
| FileName=/^(cmd(\.exe)?|powershell(\.exe)?|pwsh(\.exe)?|wscript\.exe|cscript\.exe|mshta\.exe|sh|bash|dash|zsh|ksh|python3?(\.exe)?|perl)$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, ParentCommandLine, TargetProcessId])
| sort(@timestamp, order=desc, limit=500)

// HUNT: TeamCity server JVM spawns discovery or ingress-transfer tooling
// MITRE: T1082, T1016, T1105
// CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2
// FALSE POSITIVES: TeamCity server health reports and VCS plugins invoking hostname or
//   nslookup; curl used by an admin-authored server-side maintenance job.
// TUNING: run over 30 days and drop any (ComputerName, FileName, CommandLine) triple that
//   appears on more than 5 distinct days at a regular cadence -- that is automation, not an
//   operator. Alert only on first-seen combinations.
// LOOKBACK: set the window in the console time picker
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| ParentBaseFileName=/^java(\.exe)?$/i
| ParentCommandLine=/(teamcity-server|teamcity\.server|catalina|BuildServer|bootstrap\.jar|TeamCity)/i
| FileName=/^(whoami(\.exe)?|hostname(\.exe)?|id|uname|w|systeminfo\.exe|ipconfig\.exe|ifconfig|ip|nltest\.exe|net(\.exe)?|net1\.exe|arp(\.exe)?|route(\.exe)?|tasklist\.exe|ps|curl(\.exe)?|wget|certutil\.exe|bitsadmin\.exe|nslookup(\.exe)?|dig|ssh|scp|nc|ncat)$/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentCommandLine, TargetProcessId])
| sort(@timestamp, order=desc, limit=500)

// HUNT: executable / JAR / archive written into the TeamCity data or webapp tree
// MITRE: T1505, T1505.003, T1554
// CONF: medium  FP: medium  COST: low
// REQUIRES: NewExecutableWritten, PeFileWritten, JarFileWritten, ZipFileWritten
// FALSE POSITIVES: TeamCity in-product upgrades, legitimate plugin installation, and
//   normal build-artifact publication under system/artifacts.
// TUNING: exclude TargetFileName matching system[\\/]+artifacts (routine artifact
//   publication) and correlate the remainder against your change calendar; a write during
//   an approved upgrade window with ContextBaseFileName=java is the expected benign case.
// LOOKBACK: set the window in the console time picker
#event_simpleName=/NewExecutableWritten|PeFileWritten|JarFileWritten|ZipFileWritten/
| TargetFileName=/(\.BuildServer[\\\/]|[\\\/]TeamCity[\\\/](webapps|plugins|lib|conf)[\\\/]|[\\\/]teamcity[\\\/](webapps|plugins|lib|conf)[\\\/])/i
| TargetFileName!=/[\\\/]system[\\\/]+artifacts[\\\/]/i
| table([@timestamp, aid, ComputerName, UserName, TargetFileName, ContextBaseFileName, SHA256HashData])
| sort(@timestamp, order=desc, limit=500)

// HUNT: plugin archive written to the TeamCity plugins directory (auto-loaded at server start)
// MITRE: T1505, T1554
// CONF: medium  FP: high  COST: low
// REQUIRES: ZipFileWritten, JarFileWritten
// FALSE POSITIVES: the OFFICIAL JetBrains security patch plugin fix_CVE_2026_63077.zip lands
//   here as the sanctioned remediation, as does every legitimate plugin install and upgrade.
// TUNING: exclude FileName fix_CVE_2026_63077.zip when the write falls inside an approved
//   patch window on a host in the remediation scope; keep it in scope everywhere else, since
//   a plausible filename is exactly what an operator would choose. Maintain an allowlist of
//   your approved plugin archive names and alert on anything outside it.
// LOOKBACK: set the window in the console time picker
#event_simpleName=/ZipFileWritten|JarFileWritten/
| TargetFileName=/(\.BuildServer|TeamCity|teamcity)/i
| TargetFileName=/[\\\/]plugins[\\\/][^\\\/]+\.(zip|jar)$/i
| table([@timestamp, aid, ComputerName, UserName, TargetFileName, ContextBaseFileName, SHA256HashData])
| sort(@timestamp, order=desc, limit=500)

// HUNT: rare external destinations contacted by the TeamCity server JVM
// MITRE: T1071.001, T1105, T1213
// CONF: medium  FP: high  COST: medium
// REQUIRES: NetworkConnectIP4 with ContextBaseFileName populated
// FALSE POSITIVES: VCS hosts, Maven/NuGet/npm/PyPI mirrors, container registries, JetBrains
//   update and licensing endpoints, and cloud deployment APIs are all legitimate egress.
// TUNING: restrict the result to hosts identified as TeamCity SERVERS by Q7 first -- this
//   query matches any java process, so on a build-agent host it is pure noise. Then exclude
//   your VCS / artifact-repo / registry egress ranges by adding further !cidr stages, and
//   work the ascending tail: a destination seen once, from one host, is the interesting row.
// LOOKBACK: set the window in the console time picker
#event_simpleName=/NetworkConnectIP4/
| ContextBaseFileName=/^java(\.exe)?$/i
| !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","127.0.0.0/8","169.254.0.0/16"])
| groupBy([RemoteAddressIP4, RemotePort], function=[count(as=Connections), count(aid, distinct=true, as=Hosts), collect(ComputerName, limit=10)], limit=5000)
| sort(Connections, order=asc, limit=300)

// HUNT: process command line touching TeamCity credential, config or super-user-token files
// MITRE: T1552.001, T1552.004, T1078
// CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2
// FALSE POSITIVES: scheduled backup jobs archiving the data directory; admin troubleshooting
//   reading teamcity-server.log; log shippers tailing the server log.
// TUNING: exclude the backup service account by UserName and the log-shipper binary by
//   FileName, then treat anything remaining -- especially a hit whose parent chain reaches
//   the server JVM, or that lands within minutes of a Q1/Q2 hit on the same aid -- as
//   credential theft until proven otherwise.
// LOOKBACK: set the window in the console time picker
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| CommandLine=/(credentials\.json|database\.properties|auth-config\.xml|main-config\.xml|ldap-config\.properties|teamcity-server\.log|\.BuildServer)/i
| FileName=/^(cmd(\.exe)?|powershell(\.exe)?|pwsh(\.exe)?|sh|bash|zsh|cat|head|tail|more|less|type|findstr\.exe|grep|awk|sed|strings|tar(\.exe)?|zip|7z(\.exe)?|gzip|xcopy\.exe|robocopy\.exe|copy|cp|scp|curl(\.exe)?|wget|certutil\.exe|base64|openssl)$/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine, ParentBaseFileName, ParentCommandLine])
| sort(@timestamp, order=desc, limit=500)

// HUNT: inventory of hosts running a TeamCity server JVM (patch-scoping query)
// MITRE: n/a -- asset discovery for remediation scoping
// CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2
// FALSE POSITIVES: build agents whose command line happens to contain the string TeamCity;
//   check the collected CommandLine for agent.jar and treat those rows as agents, not servers.
// TUNING: after the first run, keep a list of confirmed server ComputerName values and reuse
//   it to scope Q5 and Q8, which are otherwise noisy on agent hosts.
// LOOKBACK: set the window in the console time picker; 30d gives better coverage of
//   infrequently-restarted servers than 7d
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| FileName=/^java(\.exe)?$/i
| CommandLine=/(teamcity-server|teamcity\.server|BuildServer|TeamCity)/i
| groupBy([ComputerName, aid], function=[count(as=Starts), selectFromMax(field=@timestamp, include=[UserName, ImageFileName, CommandLine])], limit=1000)
| sort(ComputerName, order=asc, limit=1000)

// HUNT: TeamCity server JVM HTTP listeners and bind addresses (exposure triage)
// MITRE: T1190 (attack-surface reduction)
// CONF: high  FP: medium  COST: low
// REQUIRES: NetworkListenIP4
// FALSE POSITIVES: any java application listening on these ports -- build agents, other
//   Tomcat apps, and unrelated JVM services will all appear.
// TUNING: intersect the ComputerName list with the confirmed servers from Q7 before acting;
//   a listener on 8111 bound to 0.0.0.0 on a Q7-confirmed host is the row that matters.
// LOOKBACK: set the window in the console time picker
#event_simpleName=/NetworkListenIP4/
| ContextBaseFileName=/^java(\.exe)?$/i
| in(LocalPort, values=[8111, 8112, 8080, 8443, 80, 443])
| groupBy([ComputerName, aid, LocalAddressIP4, LocalPort], function=count(as=Observations), limit=1000)
| sort(LocalPort, order=asc, limit=1000)

// HUNT: TeamCity server JVM running under a highly privileged OS account
// MITRE: n/a -- blast-radius and hardening verification
// CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2 with UserName populated
// FALSE POSITIVES: a service wrapper that starts as SYSTEM and immediately drops privileges
//   will still be recorded here; confirm the effective account on the host before escalating.
// TUNING: none required -- every row is a hardening finding, not an alert. Feed the results
//   straight into the Immediate hardening tier in section 12.
// LOOKBACK: set the window in the console time picker; use 30d to catch rare restarts
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| FileName=/^java(\.exe)?$/i
| CommandLine=/(teamcity-server|teamcity\.server|BuildServer|TeamCity)/i
| UserName=/(^SYSTEM$|^LOCAL SYSTEM$|SYSTEM$|^root$|^Administrator$|^admin$)/i
| table([@timestamp, aid, ComputerName, UserName, FileName, CommandLine])
| sort(ComputerName, order=asc, limit=500)

Two of the nine queries are strong enough to promote to preventative Custom IOAs. The rest stay Investigate-only until baselined in your environment.

IOA-1 · CI server JVM spawning a command interpreter PROMOTE

Do not set this to Block on day one. If a legitimate server-side plugin shells out on your instance, blocking will break builds during the exact week you are trying to patch. Run Detect for a week, empty the benign set, then block.

IOA-2 · CI server JVM spawning a downloader PROMOTE (detect only)

Investigate-only (do not promote yet)

Scheduled search & alert package (Q1)

Triage checklist (L1)

1. Confirm the host is a TeamCity server (Q7), not a build agent — this changes everything about the response.
2. Record the TeamCity version and whether 2025.11.7 / 2026.1.3 or the patch plugin is applied. An unpatched host makes this a presumed intrusion.
3. Pull the full process tree for the TargetProcessId and capture every child command line.
4. Run Q6 scoped to the same aid for the surrounding 24 hours — credential access is the objective.
5. Run Q3 and Q4 scoped to the same aid for persistence drops.
6. Run Q5 scoped to the same ComputerName and look at the ascending tail for new destinations.
7. Pull reverse-proxy access logs for that host ±60 seconds around the process event (N2) and identify the source address.
8. Review the TeamCity audit log (N3) for new administrators, tokens, or build-step changes.
9. Escalate to containment (§14) — do not close on "the command looked benign"; the parent-child edge is the finding.

Pivot queries

• Host-scoped timeline: take Q1, replace the filter chain with | aid="<the aid>" plus #event_simpleName=/ProcessRollup2|NetworkConnectIP4|DnsRequest/, and sort ascending to build the minute-by-minute story.
• Environment-wide sweep: run Q1 and Q2 with no host scoping across the full window from 2026-07-27 to now — one compromised server usually means the scanner found several.
• Lateral movement from the CI zone: #event_simpleName=/UserLogon/ filtered to the TeamCity service account, grouped by ComputerName, to find where that identity has been used off the server.

The Falcon import CSV below contains no real indicators, and that is deliberate. No source publishes a hash, domain or IP for CVE-2026-63077 exploitation. Every atomic row is a REPLACE_WITH_ placeholder for you to fill from your own incident data. Importing this file as-is would create three useless IOC entries — it is a template, not a feed. The blocks that follow it are the ones with actual content.

type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_SHA256,detect,critical,2027-02-06,CVE-2026-63077 second-stage payload observed in YOUR incident,cve:CVE-2026-63077
domain,REPLACE_WITH_C2_DOMAIN,detect,high,2026-11-06,CVE-2026-63077 C2 observed in YOUR incident,cve:CVE-2026-63077
ipv4,REPLACE_WITH_C2_IPV4,detect,high,2026-11-06,CVE-2026-63077 C2 or exploit source from YOUR proxy logs,cve:CVE-2026-63077
# NO public atomic indicators existed for CVE-2026-63077 as of 2026-08-06.
# No hash, domain, IP or URI has been published by JetBrains, CISA, NVD, Rapid7,
# or any press source. Do NOT import these rows until you have replaced the
# REPLACE_WITH_ values with indicators from your own investigation.
# Detection for this CVE is behavioral -- see section 8.

BEHAVIOR-01  TeamCity server JVM (java + teamcity-server|catalina|bootstrap.jar in
             parent cmdline) is the PARENT of cmd|powershell|pwsh|sh|bash|dash|zsh
             -> primary CVE-2026-63077 post-exploitation signal            [Q1]
BEHAVIOR-02  Same parent -> whoami|id|hostname|uname|systeminfo|ipconfig|nltest
             -> post-RCE discovery                                          [Q2]
BEHAVIOR-03  Same parent -> curl|wget|certutil|bitsadmin -> ingress transfer [Q2]
BEHAVIOR-04  Executable / JAR / ZIP written under .BuildServer or the TeamCity
             webapps|plugins|lib|conf tree, outside a change window          [Q3]
BEHAVIOR-05  New .zip or .jar in .BuildServer/plugins -> auto-loaded at server
             start = durable in-process persistence                          [Q4]
BEHAVIOR-06  Command line referencing credentials.json | database.properties |
             auth-config.xml | teamcity-server.log -> credential access      [Q6]
BEHAVIOR-07  Rare external destination from the server JVM, one host / one hit  [Q5]
BEHAVIOR-08  TeamCity server JVM running as SYSTEM / root -> full-host blast
             radius on exploitation                                          [Q9]
BEHAVIOR-09  .jsp / .jspx appearing in the webapps tree -> webshell. NOT covered
             by Falcon file-write events; use native hunt N4.
BEHAVIOR-10  New or modified build step in .BuildServer/config/*/buildTypes/*.xml
             -> supply-chain tampering. Application layer only; use N5.

THREAT ACTOR ......... NONE PUBLISHED as of 2026-08-06
MALWARE FAMILY ....... NONE PUBLISHED
TOOLING .............. NONE PUBLISHED
EXPLOITATION SCALE ... NOT DISCLOSED
EXPLOIT MECHANICS .... NO PUBLIC PoC OR REQUEST SIGNATURE

The Hacker News, 2026-08-06: "It's currently not known how the vulnerability is
being exploited in the wild, the identity of the threat actors behind the attacks,
and the scale of such efforts."

CISA KEV: "Known To Be Used in Ransomware Campaigns? Unknown"

CONTEXT, NOT ATTRIBUTION: press reporting notes that state-sponsored groups and
ransomware affiliates have exploited EARLIER TeamCity vulnerabilities. That
justifies urgency. It does not name an actor for CVE-2026-63077 and must not be
written into a report as if it did.

KNOWN-BENIGN, do not mistake for a payload:
  fix_CVE_2026_63077.zip  = the official JetBrains security patch plugin

FIXED VERSIONS
  TeamCity On-Premises 2025.11.7   (build 208264, single-source -- verify)
  TeamCity On-Premises 2026.1.3    (build 222742, single-source -- verify)
AFFECTED
  ALL TeamCity On-Premises versions before the above. TeamCity Cloud: NOT affected.
PATCH PLUGIN (if you cannot upgrade)
  Supported on TeamCity 2017.1+ ; fixes ONLY CVE-2026-63077
  2017.1 - 2018.1 : server RESTART required after install
  2018.2+         : can be enabled without a restart
  2024.03+        : auto-downloads security patches; see Administration | Updates
KEV / COMPLIANCE
  CISA KEV Date Added : 2026-08-05
  FCEB Due Date       : 2026-08-08   (BOD 26-04)
  CWE                 : CWE-502 Deserialization of Untrusted Data
  CVSS v3.1           : 9.8 CRITICAL
AUDIT CHECKLIST
  [ ] Q7  every host running a TeamCity server JVM enumerated and matched to CMDB
  [ ] N1  every internet-reachable TeamCity endpoint identified
  [ ] Q8  every listener + bind address recorded (0.0.0.0:8111 = act now)
  [ ] ..  version recorded per server; patched or plugin applied
  [ ] Q9  no server JVM running as SYSTEM / root
  [ ] N2  proxy logs reviewed for 2026-07-27 -> patch date
  [ ] N3  TeamCity audit log reviewed for new admins / tokens / build-step edits
  [ ] ..  ALL stored credentials rotated on any server assessed as compromised

Cited-authority note: every control above carries a MITRE mitigation plus either the JetBrains advisory or JetBrains' own product security documentation. There is no CIS Benchmark or DISA STIG for TeamCity, so the vendor's Security Notes are the strongest available authority for the product-specific items — treat those as ⚠ vendor best-practice, no formal benchmark. The OS-level and network items (I-4, N-1, S-1) additionally map to standard CIS host and network benchmarks for the underlying platform.

Playbook 1 · Emergency patch and verify (Linux server)

Prerequisites: root or sudo on the TeamCity server host; a verified backup of the data directory and database; a maintenance window; the fixed distribution downloaded from the JetBrains site and its checksum verified.
Reboot required: No host reboot. A TeamCity service restart is required (builds will queue during the restart).
Rollback: Stop the service, restore the previous TeamCity home directory from the pre-upgrade copy taken in step 2, restore the data directory and database from the step-1 backup, and start the service. Note that TeamCity upgrades may migrate the database schema — a rollback across a major version requires the database restore, not just the binaries. Vendor guidance: bugfix upgrades within the same minor line (the case here) are backwards compatible and roll back cleanly.

#!/usr/bin/env bash
# Playbook 1 - CVE-2026-63077 emergency patch, Linux tar.gz install.
# Run as root/sudo on the TeamCity SERVER host. Do NOT run on build agents.
set -euo pipefail

TC_HOME="${TC_HOME:-/opt/TeamCity}"
TC_DATA="${TEAMCITY_DATA_PATH:-$HOME/.BuildServer}"
STAMP="$(date +%Y%m%d-%H%M%S)"
BACKUP_ROOT="/backups/teamcity/${STAMP}"

# 1. BACK UP FIRST. No backup, no upgrade.
mkdir -p "${BACKUP_ROOT}"
tar czf "${BACKUP_ROOT}/data-directory.tgz" -C "$(dirname "${TC_DATA}")" "$(basename "${TC_DATA}")"
echo "Database: take your DBA-approved dump into ${BACKUP_ROOT} NOW, then press enter."
read -r _

# 2. Record current state and preserve the binaries for rollback.
"${TC_HOME}/bin/teamcity-server.sh" stop || true
sleep 20
cp -a "${TC_HOME}" "${BACKUP_ROOT}/TeamCity-home-previous"
grep -i 'TeamCity Data Directory:' "${TC_HOME}/logs/teamcity-server.log" | tail -1 || true

# 3. Deploy the fixed distribution (2025.11.7 or 2026.1.3) already staged at
#    /tmp/TeamCity-fixed.tar.gz with its checksum verified against the vendor page.
rm -rf "${TC_HOME}.new" && mkdir -p "${TC_HOME}.new"
tar xzf /tmp/TeamCity-fixed.tar.gz -C "${TC_HOME}.new" --strip-components=1
mv "${TC_HOME}" "${TC_HOME}.old-${STAMP}" && mv "${TC_HOME}.new" "${TC_HOME}"
chown -R teamcity:teamcity "${TC_HOME}"          # dedicated low-priv account (I-4)

# 4. Start and verify the version actually changed.
sudo -u teamcity "${TC_HOME}/bin/teamcity-server.sh" start
sleep 60
grep -iE 'TeamCity (server )?version|Starting TeamCity' "${TC_HOME}/logs/teamcity-server.log" | tail -5

# 5. Confirm the service is NOT running as root (control I-4 / query Q9).
ps -o user= -p "$(pgrep -f 'teamcity-server|catalina' | head -1)"
# Expected: teamcity   -- if this prints root, STOP and fix the service account.

Playbook 2 · Apply the security patch plugin (cannot upgrade)

Prerequisites: TeamCity 2017.1 or newer; TeamCity system-administrator access; the plugin archive downloaded from JetBrains and checksum-verified; write access to the data directory's plugins folder.
Reboot required: No host reboot. TeamCity server restart IS required on 2017.1 through 2018.1; from 2018.2 onward the plugin can be enabled without a restart. On 2024.03+ the server can download the patch itself — check Administration | Updates → Available security updates before doing this manually.
Rollback: Remove the plugin archive from the plugins directory (or disable it under Administration | Plugins) and restart the server if your version requires it. This returns the server to its previous, vulnerable state — only roll back if the plugin causes a confirmed outage, and treat the server as exposed until it is patched again or upgraded.

# Playbook 2 - install the JetBrains security patch plugin for CVE-2026-63077.
# The plugin fixes ONLY this CVE. Upgrading is still the preferred path (I-1).

TC_DATA="${TEAMCITY_DATA_PATH:-$HOME/.BuildServer}"

# 1. Preserve the current plugins directory so rollback is a file move, not a guess.
cp -a "${TC_DATA}/plugins" "/backups/teamcity/plugins-pre-patch-$(date +%Y%m%d-%H%M%S)"

# 2. Stage the plugin. Verify the checksum against the JetBrains download page
#    BEFORE copying it in -- this directory is auto-loaded at server start, which
#    is exactly why it is also query Q4's persistence target.
sha256sum /tmp/fix_CVE_2026_63077.zip
cp /tmp/fix_CVE_2026_63077.zip "${TC_DATA}/plugins/"
chown teamcity:teamcity "${TC_DATA}/plugins/fix_CVE_2026_63077.zip"
chmod 640 "${TC_DATA}/plugins/fix_CVE_2026_63077.zip"

# 3. Enable it.
#    TeamCity 2018.2+ : Administration | Plugins -> enable, no restart needed.
#    TeamCity 2017.1 - 2018.1 : restart the server.
#      /opt/TeamCity/bin/teamcity-server.sh stop && sleep 20
#      sudo -u teamcity /opt/TeamCity/bin/teamcity-server.sh start

# 4. Verify: the plugin is listed and enabled under Administration | Plugins.
# 5. Tell the SOC the write happened, so Q4 does not open an incident on your own fix.

Playbook 3 · Restrict network exposure (control I-2)

Prerequisites: host firewall administration rights; the definitive list of build-agent source addresses and administrator networks; console or out-of-band access to the host in case you lock yourself out.
Reboot required: No. Rules apply immediately.
Rollback: firewall-cmd --reload discards un-persisted runtime rules; for persisted rules, remove the rich rules added below and reload. On Windows, Remove-NetFirewallRule -DisplayName "TeamCity-*". Take the out-of-band access path first — a mistake in the trusted-source list will lock administrators out of the web UI.

# Playbook 3 - restrict the TeamCity HTTP and agent-polling port to trusted sources.
# Adjust TC_PORT to your server's configured port (8111 is the default).

TC_PORT=8111
AGENT_NET="192.0.2.0/24"      # REPLACE: your build-agent network
ADMIN_NET="198.51.100.0/24"   # REPLACE: your administrator / proxy network

# --- Linux (firewalld) -------------------------------------------------------
firewall-cmd --permanent --new-zone=teamcity 2>/dev/null || true
firewall-cmd --permanent --zone=teamcity --add-source="${AGENT_NET}"
firewall-cmd --permanent --zone=teamcity --add-source="${ADMIN_NET}"
firewall-cmd --permanent --zone=teamcity --add-port="${TC_PORT}/tcp"
# Deny the port everywhere else.
firewall-cmd --permanent --zone=public --remove-port="${TC_PORT}/tcp" 2>/dev/null || true
firewall-cmd --reload
firewall-cmd --zone=teamcity --list-all

# --- Windows (PowerShell, run elevated) --------------------------------------
# New-NetFirewallRule -DisplayName "TeamCity-Allow-Trusted" -Direction Inbound `
#   -Protocol TCP -LocalPort 8111 -RemoteAddress @("192.0.2.0/24","198.51.100.0/24") `
#   -Action Allow
# New-NetFirewallRule -DisplayName "TeamCity-Block-Other" -Direction Inbound `
#   -Protocol TCP -LocalPort 8111 -Action Block

# VERIFY from an address outside both networks -- this must fail to connect:
#   curl -m 5 -sS "http://<teamcity-host>:8111/login.html" ; echo "exit=$?"

Playbook 4 · Harden the server account, super-user token and data directory

Prerequisites: root/Administrator on the host; TeamCity system-administrator access; a maintenance window (the property change needs a restart); confirmation of the account TeamCity currently runs as (from Q9).
Reboot required: No host reboot. A TeamCity server restart is required for teamcity.superUser.disable to take effect and for a service-account change.
Rollback: Remove or set teamcity.superUser.disable=false in internal.properties and restart to restore super-user login (do this only if you have lost administrator access by another route — the token in the log is a documented break-glass path). Restore the previous ACLs from the getfacl/icacls capture taken in step 1. Reverting the service account requires re-granting that account ownership of the data directory, so capture ownership before changing it.

# Playbook 4 - service account, super-user token, data-directory ACLs.

TC_DATA="${TEAMCITY_DATA_PATH:-$HOME/.BuildServer}"

# 1. CAPTURE CURRENT STATE FIRST (this is your rollback record).
getfacl -R "${TC_DATA}" > "/backups/teamcity/acl-before-$(date +%Y%m%d).txt"
stat -c '%U:%G %a %n' "${TC_DATA}"

# 2. Disable the super-user token path if logs leave the box (control I-5).
#    The super-user token is printed to logs/teamcity-server.log -- anyone who can
#    read your log platform is otherwise a TeamCity system administrator.
echo 'teamcity.superUser.disable=true' >> "${TC_DATA}/config/internal.properties"

# 3. Lock the data directory to the service account and administrators (N-1).
chown -R teamcity:teamcity "${TC_DATA}"
chmod -R o-rwx "${TC_DATA}"
chmod 700 "${TC_DATA}/config" "${TC_DATA}/plugins"
chmod 600 "${TC_DATA}/config/database.properties" 2>/dev/null || true
find "${TC_DATA}" -name 'credentials.json' -exec chmod 600 {} \;

# 4. Restart the server for the property to apply.
#    /opt/TeamCity/bin/teamcity-server.sh stop && sleep 20
#    sudo -u teamcity /opt/TeamCity/bin/teamcity-server.sh start

# 5. VERIFY
grep -c 'teamcity.superUser.disable=true' "${TC_DATA}/config/internal.properties"
ls -ld "${TC_DATA}" "${TC_DATA}/config" "${TC_DATA}/plugins"
# Then re-run Q9 in Falcon: it must return zero rows for this host.

Sequencing warning: on a CI/CD server, evidence lives in the data directory and the application logs, and credential exposure is the dominant risk. Preserve before you rebuild, and rotate before you restore. A rebuild that skips credential rotation hands the attacker persistent access through the keys they already took.

If you find atomic indicators during this response — a C2 address in proxy logs, a payload hash, a webshell — put them into the §10 CSV in place of the REPLACE_WITH_ rows, record which log or artifact they came from, and bump the pack to v0.2. They will be the first real IOCs for this CVE that your environment has, and possibly that anyone has.

Summary of gaps

• Exploitation itself is undetectable with what is public today. No PoC, no request signature, no IOCs. Everything in §8 fires on what happens after the exploit lands, which means an operator who exploits and does nothing else is invisible. Access-log review (N2) plus assumed-compromise credential rotation (I-3) is the compensating answer.
• Webshell and build-tamper detection live outside EDR. N4 and N5 are not optional extras; without them, two of the nine attack-chain steps have zero coverage.
• Containerised TeamCity degrades the file-drop hunts badly. If the server runs in a pod without a container-aware sensor, treat Q3 and Q4 as absent.
• The parent-command-line assumption is the single point of failure. Q1 and Q2 both depend on the server JVM's command line matching the pattern in validation gate 3. Verify it against a real host before you trust a zero result.

Validation gates. The eight gates in §11 must pass before any of this is treated as coverage. Gate 1 (telemetry present on every Q7 host), gate 3 (the parent pattern actually matches your installs) and gate 8 (named owners for N2/N4/N5) are the three that most commonly turn an apparently-green coverage map into a false sense of security.

MITRE ATT&CK & mitigations referenced

Techniques: T1190, T1059.001/.003/.004, T1082, T1016, T1105, T1071.001, T1505, T1505.003, T1554, T1552.001, T1552.004, T1078, T1213, T1195.002. Mitigations: M1051 (Update Software), M1035 (Limit Access to Resource Over Network), M1030 (Network Segmentation), M1037 (Filter Network Traffic), M1026 (Privileged Account Management), M1018 (User Account Management), M1022 (Restrict File and Directory Permissions), M1027 (Password Policies), M1041 (Encrypt Sensitive Information), M1047 (Audit).

Source snapshots. Verbatim fetched text for every source above is archived in TeamCity-CVE-2026-63077-Hunt-sources/ alongside this file, one plain-text file per source, so that every claim and indicator in this pack can be traced to the page it came from on 2026-08-06.

Generated 2026-08-06 · HuntPack v0.1 (Draft) · Defensive content only — hunt, detection and hardening guidance. No offensive tooling or exploit code is included, and none of the sources consulted published any.