CISA 악용 목록에 오른 TeamCity 원격코드실행, 이제는 흔적을 찾을 차례

이미지 출처: The Hacker News

취약점이 공개되는 것과 "지금 이 순간 공격에 쓰이고 있다"는 판정이 붙는 것은 전혀 다른 이야기다. CISA가 JetBrains TeamCity의 원격코드실행 결함 CVE-2026-63077을 알려진 악용 취약점(KEV) 목록에 올렸다는 건, 어딘가에서 이미 누군가의 빌드 서버가 넘어갔다는 뜻이기도 하다. 그래서 이 글은 "패치하세요"에서 끝내지 않고, 이미 당했다면 무엇이 남아 있을까를 같이 따라가보려 한다.

핵심 요약

• TeamCity의 인증 우회·원격코드실행 계열 결함(CVE-2026-63077)이 실제 공격에 사용된 것으로 확인돼 KEV에 등재됨
• 빌드 서버는 소스코드·배포키·서명키가 모두 모이는 지점이라, 침해되면 피해가 CI를 넘어 배포 산출물까지 번짐
• 패치와 외부 노출 차단이 1순위, 그다음이 관리자 계정·빌드 구성 변경 이력 점검과 시크릿 전면 교체

1. 왜 하필 빌드 서버인가

공격자 입장에서 CI 서버는 가성비가 참 좋은 표적입니다. 한 곳만 뚫으면 여러 저장소의 소스가 통째로 보이고, 배포용 SSH 키·클라우드 자격증명·코드 서명키까지 한 바구니에 담겨 있으니 말입니다.

• TeamCity 서버는 빌드 에이전트에 임의의 명령을 정상적으로 내리는 구조임. 서버 권한을 얻으면 별도 익스플로잇 없이 에이전트 전체가 실행 환경이 됨
• 빌드 산출물에 손을 대면 그 결과물을 받는 고객사까지 영향권에 들어감. 공급망 사고로 번지는 경로가 짧음
• 과거 TeamCity 인증 우회 결함들도 랜섬웨어·국가 지원 그룹 양쪽에서 빠르게 채택된 전례가 있음. 이번 건도 같은 흐름으로 보는 게 안전함

2. 결함의 성격은 개념 수준으로만

• 핵심은 인증 검사를 거치지 않고 도달 가능한 엔드포인트가 존재하고, 그 지점에서 서버 측 코드 실행으로 이어진다는 점임
• 즉 공격자에게 계정도, 사전 권한도 필요 없음. 인터넷에 서버 포트가 열려 있다는 사실 자체가 전제 조건의 전부임
• 구체적인 요청 형태나 페이로드는 여기서 다루지 않음. 방어 관점에서 알아야 할 건 "비정상 경로로 들어온 요청이 관리자급 동작을 만들어낸다"는 결과뿐임

3. 지금 당장 할 일 세 가지

• 패치: JetBrains가 배포한 수정 버전으로 올리는 게 유일한 근본 대응임. 자체 호스팅(On-Premises) 환경이 대상이며, 클라우드형은 벤더가 처리함
• 노출 차단: 관리 인터페이스를 공개 인터넷에 두지 않기. VPN 뒤로 넣거나, 최소한 협력사·사무실 IP 대역으로 접근을 좁히는 것만으로도 스캐너 무차별 시도는 상당수 걷어냄
• 기한 인식: KEV 등재는 미국 연방기관에 기한부 조치 의무를 지우는 절차지만, 민간에서도 "이 취약점은 실전용으로 검증됐다"는 신호로 읽는 게 맞음

4. 침해 여부를 가르는 흔적들

패치를 올렸다고 끝이 아니에요. 패치 전에 이미 들어왔다면, 공격자는 정식 기능으로 발판을 만들어두고 나갔을 가능성이 큽니다.

• 계정: 낯선 관리자 계정, 기존 계정의 권한 승격, 새로 발급된 액세스 토큰. 특히 사람 이름 같지 않은 계정명과 발급 시각이 새벽대인 토큰을 우선 확인
• 빌드 구성: 아무도 요청하지 않은 빌드 스텝 추가, 낯선 스크립트 실행 단계, 갑자기 켜진 외부 네트워크 접근 옵션. 감사 로그의 변경 이력을 담당자 배정과 대조
• 플러그인·파일시스템: 최근 업로드된 플러그인, 서버 데이터 디렉터리에 생긴 정체불명 파일, 웹 루트에 놓인 스크립트
• 네트워크: 빌드 서버와 에이전트에서 나가는 외부 연결. CI 장비가 평소 접속하지 않던 대역으로 지속 연결을 유지한다면 그 자체로 이상 신호임
• 로그 보존: 조사 전에 로그가 회전돼 사라지는 사고가 의외로 많음. 점검 시작 전 서버 로그와 감사 기록을 먼저 복사해두는 습관을 권함

5. 침해 정황이 보인다면

• 서버에 저장돼 있던 모든 시크릿을 만료된 것으로 간주하고 교체. 배포 키, 레지스트리 토큰, 클라우드 자격증명, 서명키 순으로 우선순위를 둠
• 에이전트는 정리보다 재구축이 빠르고 확실함. 빌드 캐시와 워크스페이스도 함께 버리는 편이 낫음
• 침해 의심 기간에 만들어진 산출물은 재빌드 후 해시를 비교. 소스가 아니라 결과물이 조작된 사례가 실제로 있었음

개인적으로는 이런 사고를 겪고 나면 CI 서버를 "개발 편의 도구"가 아니라 도메인 컨트롤러급 자산으로 분류해 관리하시길 추천드려요. 접근 통제도, 로그 보존 기간도, 패치 우선순위도 그 등급에 맞춰 다시 잡아야 하다보니 처음엔 번거롭지만 차차 몸에 붙습니다. 여러분 조직의 빌드 서버는 지금 어느 등급으로 관리되고 있나요? 점검하다가 애매한 지점이 나오면 댓글로 남겨주세요. 같이 풀어보아요!