TeamPCP PyPI 공급망 캠페인
[ 인시던트 개요 ]
- 발생 기간 - 2026년 3월 19일 - 3월 27일
- 공격자 - TeamPCP ( 귀속 확정, Vect 랜섬웨어 그룹과 파트너십 확인됨 )
- 피해 대상 - Aqua Security Trivy, npm 생태계 46개 이상 패키지, Checkmarx, LiteLLM, Telnyx Python SDK
- 공격 유형 - 공급망 공격 ( CI/CD 자격증명 연쇄 탈취 + 스테가노그래피 기반 페이로드 전달 )
- 공개 경로 - Aikido, Socket, Endor Labs, JFrog, SafeDep, Datadog Security Labs 등 다수 보안 기업이 독립적으로 발견 및 공개
- 핵심 CVE - CVE-2026-33634 ( Trivy, CVSS 9.4 )
- 현재 상태 - 악성 패키지 PyPI 격리 완료, Telnyx 4.87.0으로 다운그레이드 권고
[ 기술적 세부 사항 ]
[ 공격 타임라인 - 자격증명 체이닝 구조 ]
TeamPCP의 캠페인은 단일 침해가 아닌, 탈취한 자격증명을 다음 목표의 초기 접근에 재사용하는 연쇄 구조로 설계되었다.
[ 3월 19일 - Trivy 침해 ( CVE-2026-33634 ) ]
Aqua Security의 오픈소스 취약점 스캐너 Trivy의 GitHub Actions 워크플로우가 백도어 처리되었다. 공격자는 Trivy의 공식 GitHub 태그 75개 ( 77개 중 ) 와 setup-trivy 태그 7개에 악성 바이너리를 강제 푸시 ( force-push ) 하였다. Trivy는 CI/CD 파이프라인에서 광범위하게 실행되므로, 해당 파이프라인이 보유하는 npm 토큰, Docker Hub 자격증명, PyPI 게시 토큰 등이 대규모로 수집되었다. 결과적으로 Aqua Security GitHub 저장소 44개가 tpcp-docs- 접두사로 이름이 변경되었다.
[ 3월 20일 - npm 생태계 CanisterWorm 배포 ]
Trivy 피해자들로부터 탈취한 npm 토큰을 사용하여, CanisterWorm이라는 자동화된 백도어 배포 웜을 46개 이상의 npm 패키지에 주입하였다. CanisterWorm은 하나의 npm 토큰이 주어지면 60초 이내에 해당 토큰으로 게시 가능한 모든 패키지를 열거하고 악성 버전을 자동으로 배포하는 자가 복제 메커니즘을 갖추고 있다.
[ 3월 22일 - WAV 스테가노그래피 기법 최초 관측 ]
Kubernetes 환경을 대상으로 한 와이퍼 ( wiper ) 공격 변종에서, 악성 페이로드를 WAV 오디오 파일의 데이터 프레임에 숨기는 스테가노그래피 기법이 처음 관측되었다. 이 기법은 5일 후 Telnyx 공격에 그대로 재사용된다.
[ 3월 24일 - LiteLLM 침해 ( PyPI ) ]
LiteLLM은 OpenAI, Anthropic, AWS Bedrock, GCP Vertex AI 등 주요 LLM 제공자를 단일 게이트웨이로 통합하는 Python 라이브러리로, 월간 다운로드 수가 약 9,500만 건에 달한다. LiteLLM의 CI/CD 파이프라인이 버전 고정 ( version pinning ) 없이 Trivy를 실행하고 있었으므로, 이미 감염된 Trivy를 통해 LiteLLM의 PyPI 게시 자격증명이 탈취되었다. 공격자는 이를 사용해 악성 버전 1.82.7과 1.82.8을 PyPI에 게시하였다.
페이로드는 환경 변수, SSH 키, 클라우드 자격증명, Kubernetes 데이터, Docker 설정, 셸 히스토리, 데이터베이스 자격증명, 지갑 파일 등을 수집한 후 AES-256 세션 키로 암호화하고 RSA-4096으로 세션 키를 추가 암호화하여 C2 서버로 전송하였다.
[ 3월 27일 - Telnyx 침해 ( PyPI ) ]
LiteLLM 침해에서 탈취된 자격증명을 통해 Telnyx Python SDK의 PyPI 게시 계정이 추가로 탈취되었다. 악성 버전 4.87.1이 03:51 UTC에 게시되었으나 페이로드에 오타가 존재하여 비작동 상태였다. 공격자는 약 16분 후인 04:07 UTC에 수정된 버전 4.87.2를 재게시하였다. 두 버전 모두 동일 날짜 10:13 UTC까지 PyPI에 의해 격리되었다.
[ Telnyx 악성 페이로드의 기술적 구조 ]
악성 코드는 telnyx/_client.py 의 단 74줄에 주입되었으며, import telnyx 명령 실행 시점에 즉시 작동한다. 별도의 설치 훅 ( post-install script ) 이 없어 차단이 어렵다.
Windows 경로
- C2 서버 ( 83.142.209.203:8080 ) 로부터 hangup.wav 를 다운로드
- WAV 오디오 프레임에서 XOR 기반 복호화 루틴으로 실행 파일 추출
- %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe 로 드롭
- 매 로그인 시 자동 재실행되는 영속성 ( persistence ) 확보
Linux 및 macOS 경로
- _client.py 의 459번째 줄에 하드코딩된 base64 blob이 제2단계 Python 스크립트로 실행
- 동일 C2에서 ringtone.wav 를 다운로드하고 스테가노그래피로 숨겨진 제3단계 수집기 스크립트를 XOR 복호화 후 메모리 상에서 실행
- 수집된 데이터는 AES-256-CBC로 암호화 후 즉시 외부로 전송
- 이후 임시 디렉터리를 재귀적으로 삭제하여 흔적 제거 ( 영속성 메커니즘 없음 )
수집 대상 데이터
- SSH 키 및 설정, 클라우드 자격증명 ( AWS, GCP, Azure )
- Docker 설정, npm/Git/Vault 인증 데이터
- 데이터베이스 자격증명, .env 파일 내 API 키 및 토큰
- 셸 및 데이터베이스 히스토리, 암호화폐 지갑 파일
[ 공격 목표 선택 패턴 ]
캠페인 전반에 걸쳐 표적이 된 도구들의 공통점은 자동화 파이프라인 내에서 광범위한 읽기 접근 권한을 갖는다는 점이다.
- Trivy - 컨테이너 스캐너로서 인프라 자격증명에 접근
- LiteLLM - AI 모델 라우팅 게이트웨이로서 다수 클라우드 API 키 보유
- Telnyx SDK - 통신 플랫폼 자격증명에 접근
직접적인 타입스쿼팅 ( typosquatting ) 대신 정상적이고 신뢰받는 합법적 패키지를 대상으로 삼는 전략을 취하고 있으며, GitHub 소스 저장소는 변조되지 않은 상태로 유지되어 비교를 통한 탐지를 어렵게 만든다.
[ 근본 원인 분석 ]
[ 기술적 요인 ]
LiteLLM CI/CD 파이프라인이 Trivy를 버전 고정 없이 실행하고 있었던 것이 이번 캠페인에서 핵심적인 연쇄 고리가 되었다. 버전이 고정되지 않은 외부 도구를 CI/CD 파이프라인에서 실행한다는 것은, 해당 도구의 게시 채널이 감염되는 즉시 자신의 파이프라인도 자동으로 감염됨을 의미한다.
Telnyx의 경우 PyPI 게시 자격증명이 GitHub Actions 워크플로우와 완전히 분리되지 않았고, 게시 계정에 적용되는 독립적인 MFA 또는 게시 토큰 범위 제한이 충분하지 않았던 것으로 분석된다.
스테가노그래피 기반 페이로드 전달은 정적 분석 도구와 바이너리 기반 탐지 우회를 목적으로 한다. 악성 코드가 합법적인 WAV 오디오 파일의 프레임 데이터에 XOR 방식으로 숨겨져 있으므로, 파일 자체는 정상 오디오로 재생 가능하다.
[ 관리적 요인 ]
오픈소스 소프트웨어 공급망에 대한 보안 검토 절차가 부재하거나 형식적으로 운영되고 있는 조직이 광범위하게 존재한다. 대부분의 개발 조직은 외부 패키지를 신뢰받은 소스로 간주하고 별도의 런타임 동작 모니터링을 수행하지 않는다. 또한 버전 고정을 개발 생산성 저하의 원인으로 인식하여 보안 우선순위에서 후순위로 취급하는 문화적 요인도 존재한다.
[ 인적 요인 ]
공급망 공격의 핵심적 특성은 피해 조직의 개발자가 직접 악성 코드를 실행한다는 점이다. 정상적인 업무 절차 ( 패키지 업그레이드, CI 파이프라인 실행 ) 를 수행하는 과정에서 감염이 발생하므로, 전통적인 사용자 교육 기반의 방어는 효과적이지 않다.
[ 피해 영향 평가 ]
Telnyx 패키지 단독으로도 월간 다운로드 수가 약 100만 건이며, 감염 버전이 활성화된 시간대 ( 03:51 - 10:13 UTC, 약 6시간 22분 ) 에 설치한 개발자는 자신의 개발 환경과 CI/CD 파이프라인에서 보유하던 모든 자격증명을 탈취당했을 가능성이 높다. LiteLLM의 경우 월간 9,500만 건의 다운로드 기반을 고려하면 피해 범위는 훨씬 광범위하다.
직접적인 금전 피해보다 더 중요한 2차 피해 요소는 탈취된 자격증명을 통한 추가적 침해 연쇄다. 클라우드 자격증명, API 키, SSH 키가 유출된 환경은 후속 랜섬웨어 작전 ( Vect 그룹과의 파트너십이 보고됨 ) 의 대상이 될 수 있다.
[ 예방 및 대응 조치 ]
[ 즉각적 조치 ]
- telnyx==4.87.1 또는 4.87.2 가 설치된 환경은 즉시 완전 침해 상태로 간주하고 모든 API 키, 데이터베이스 자격증명, SSH 키, 클라우드 토큰을 교체
- Windows 시스템의 경우 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe 및 관련 .lock 파일의 존재 확인
- 83.142.209.203:8080 으로의 아웃바운드 HTTP 트래픽 차단 및 모니터링
[ 단기 조치 ]
- 모든 CI/CD 파이프라인에서 외부 의존성을 정확한 버전 해시 ( digest 또는 commit SHA ) 로 고정
- PyPI, npm 등 패키지 레지스트리에 대한 게시 토큰을 별도로 관리하고 최소 권한 원칙 적용
- 소프트웨어 구성 분석 ( SCA ) 도구를 파이프라인에 통합하여 악성 패키지를 실시간으로 탐지
[ 장기 조치 ]
- SLSA ( Supply-chain Levels for Software Artifacts ) 프레임워크를 참조하여 빌드 공급망 보안 성숙도를 체계적으로 평가하고 개선
- 서드파티 도구의 CI/CD 파이프라인 내 실행을 격리된 환경 ( 샌드박스 또는 에어갭 환경 ) 에서 수행하는 아키텍처 검토
[ 컨설팅 커뮤니케이션 전략 ]
[ 비기술 직원 대상 ]
소프트웨어 개발에서 사용하는 외부 라이브러리가 내부 공격 경로가 되는 사례다. 이번 공격자는 개발팀이 매일 사용하는 신뢰받은 도구를 먼저 감염시킨 뒤, 그 도구를 통해 자동으로 다음 조직으로 이동하는 방식을 사용하였다. 직원이 악의적인 행동을 하거나 실수를 한 것이 아니라, 정상적인 업무를 수행하는 과정에서 감염이 발생하였다는 점을 이해하는 것이 중요하다.
[ 기술팀 대상 ]
이번 캠페인의 핵심 학습 포인트는 세 가지다. 첫째, CI/CD 파이프라인에서 실행되는 모든 외부 도구는 다이제스트 ( SHA ) 기반으로 버전을 고정해야 한다. 유의미한 태그나 latest 참조는 공급망 공격에 직접적으로 취약하다. 둘째, PyPI 게시 자격증명은 별도의 시크릿 관리 시스템에 보관하고, 게시 작업에만 사용되는 범위 제한된 토큰을 사용해야 한다. 셋째, 런타임 동작 모니터링이 없다면 import 단계에서 실행되는 악성 코드는 탐지가 불가능하다.
[ 경영진 대상 ]
이번 사건은 단일 보안 도구 ( Trivy ) 의 침해가 연쇄적으로 전 산업에 걸친 개발자 환경을 감염시킬 수 있음을 보여주는 사례다. 조직의 내부 보안이 강력하더라도, CI/CD 파이프라인에 사용되는 외부 도구가 감염되면 동일한 피해를 입을 수 있다. 소프트웨어 공급망 보안에 대한 투자는 개발 생산성 향상 투자만큼 우선순위가 높아야 한다.
[ 법무/컴플라이언스 대상 ]
이번 유형의 공격으로 클라우드 자격증명이 탈취된 경우, 해당 자격증명으로 접근 가능한 데이터가 개인정보보호법 상의 유출 대상에 해당하는지 즉시 평가해야 한다. 특히 CI/CD 환경에서 고객 데이터를 처리하는 파이프라인이 있다면 규제 당국에 대한 신고 의무 발생 여부를 검토해야 한다.
[ 예상 Q&A ]
Q. 우리 조직이 해당 패키지를 사용하지 않으면 안전한가?
A. Telnyx, LiteLLM을 직접 사용하지 않더라도, 이들 패키지를 의존성으로 포함하는 다른 라이브러리를 통해 간접적으로 영향을 받을 수 있다. 의존성 트리 전체를 스캔하여 간접 의존성을 포함한 검토가 필요하다.
Q. 이미 감염됐는지 어떻게 확인하나?
A. 환경 내 telnyx 버전이 4.87.1 또는 4.87.2 인지 pip show telnyx 로 확인한다. Windows에서는 지정된 Startup 경로에 msbuild.exe 가 존재하는지 확인하고, 네트워크 로그에서 83.142.209.203:8080 으로의 아웃바운드 연결 기록을 조사한다. Linux/macOS에서는 흔적 삭제 메커니즘으로 인해 사후 탐지가 어려우므로, 해당 시간대에 설치 이력이 있다면 완전 침해로 간주하고 자격증명 전체를 교체하는 것이 안전하다.
Q. 이 공격자를 앞으로도 추적해야 하나?
A. TeamPCP는 이번 캠페인 이후 Vect 랜섬웨어 그룹과의 협력 관계가 확인되었다. 공급망 침해로 탈취한 자격증명을 랜섬웨어 운영에 전환하는 모델이 성립되었으므로, 향후 동일 공격자의 후속 캠페인 가능성이 높다. TeamPCP 관련 IOC를 보안 모니터링 시스템에 등록하여 지속적으로 추적해야 한다.
[ 핵심 학습 포인트 ]
- 자격증명 체이닝 ( credential chaining ) 이 공급망 공격의 핵심 증폭 메커니즘이다. 단일 보안 도구의 침해가 이를 CI/CD에서 실행하는 모든 조직의 파이프라인 자격증명을 노출시켰고, 그 자격증명이 다시 다음 정상 패키지의 게시 채널 접근에 사용되었다.
- WAV 스테가노그래피를 페이로드 전달에 사용한 점은 탐지 우회 기법이 점점 정교해지고 있음을 보여준다. 바이너리 스캔, 정적 분석, 파일 확장자 기반 필터링은 이 기법에 효과적이지 않다.
- 버전 고정 ( version pinning ) 은 개발 편의성 저하 요인이 아니라 공급망 보안의 기본 통제 수단으로 재정의되어야 한다. 특히 CI/CD 파이프라인에서 실행되는 보안 도구일수록 이 원칙이 더욱 엄격하게 적용되어야 한다.
- CanisterWorm의 60초 내 자동 확산 메커니즘은 토큰 단위 차단의 효용성에 의문을 제기한다. 하나의 토큰이 탈취되면 해당 토큰으로 배포 가능한 모든 패키지가 순식간에 감염될 수 있다.