PyPI의 LiteLLM이 TeamPCP의 공격을 받았습니다: 자격 증명 탈취 악성코드 캠페인에 대한 심층 분석

홈 » Python » PyPI의 LiteLLM이 TeamPCP의 공격을 받았습니다: 자격 증명 탈취 악성코드 캠페인에 대한 심층 분석

2026년 3월 24일, 몇 시간 동안 엄청난 인기를 누리던 파이썬 패키지가 조용히 강력한 자격 증명 탈취 도구로 변모했습니다. 널리 사용되는 라이브러리인 LiteLLM의 두 가지 악성 버전이 이러한 사태를 초래했습니다. 대규모 언어 모델(LLM)을 위한 통합 인터페이스해당 파일들이 PyPI에 업로드되면서, 수많은 시스템이 정교한 공급망 공격에 일시적으로 노출되었습니다.

악성 버전, 1.82.7 및 1.82.8이 공격은 개발자 컴퓨터, CI/CD 실행기, 클라우드 인프라 및 Kubernetes 클러스터에서 비밀 정보를 빼내어 공격자가 제어하는 ​​서버로 유출할 수 있는 다단계 페이로드를 포함하고 있습니다. TeamPCP 위협 그룹과 연관되어 있음이 악성코드는 몇 달 동안 Trivy, Checkmarx 툴, Docker 이미지 등을 공격해 왔습니다. npm 공급망에 대한 공격 그리고 이제 PyPI 생태계가 등장했습니다.

LiteLLM은 무엇이며, 왜 그토록 주요한 공격 대상이 되었을까요?

LiteLLM은 오픈소스 파이썬 라이브러리 및 프록시 서버 이는 LLM API를 위한 일종의 범용 어댑터 역할을 합니다. 이를 통해 애플리케이션은 OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI 등 100개가 넘는 다양한 모델 제공업체의 모델과 단일 OpenAI 스타일 API를 통해 통신할 수 있습니다.

그러한 역할 덕분에 이 프로젝트는 AI 생태계 전반에 깊숙이 자리 잡게 되었습니다. 여러 보안 업체 보고서에 따르면 LiteLLM은 대략적인 사용량이 상당합니다. 하루 3만~3.4만 다운로드일부 원격 측정 데이터에 따르면 약 100% 정도 존재하는 것으로 나타났습니다. 모니터링 대상 클라우드 환경의 36%공격자에게 있어 그러한 크기의 패키지를 해킹하는 것은 단 한 번의 공격으로 엄청난 양의 민감한 데이터와 자격 증명에 접근할 수 있는 드문 기회를 의미합니다.

LiteLLM은 설계상 종종 바로 중간에 위치합니다. 애플리케이션 및 다양한 AI 서비스 제공업체이러한 위치는 외부 LLM 엔드포인트에 접근하는 데 필요한 API 키, 환경 변수, 구성 파일 및 기타 비밀 정보를 일상적으로 처리한다는 것을 의미합니다. 이러한 종속성에 백도어가 존재하면 상위 플랫폼 자체를 직접 침해하지 않고도 이러한 값을 조용히 가로채 유출할 수 있습니다.

이번 사건은 현대 개발 환경이 얼마나 복잡하게 얽혀 있는지를 여실히 보여줍니다. 로컬 워크스테이션, CI/CD 파이프라인, 쿠버네티스 클러스터, 클라우드 계정 모두 공유 비밀 키와 자동화를 통해 서로 연결되어 있습니다. 단 하나의 해당 그래프에서 손상된 종속성 조직 스택의 여러 계층에 걸쳐 자격 증명이 노출될 수 있으며, 그 영향은 단일 호스트를 훨씬 넘어 증폭될 수 있습니다.

악성 LiteLLM 버전이 유입된 방법

독극물이 방출됩니다 LiteLLM 1.82.7 및 1.82.8 해당 코드는 2026년 3월 24일 아침, 대략적인 시간에 PyPI에 업로드되었습니다. 08 : 30 UTC해당 파일들은 PyPI 보안팀에 의해 격리되고 제3자 방어 시스템에 의해 차단되기 전까지 약 두 시간 동안 접속 가능했으며, 삭제는 약 2시간 전에 보고되었습니다. 11 : 25 UTC.

이 사건이 주목할 만한 이유는 다음과 같습니다. 해당 GitHub 소스 코드에는 백도어가 나타나지 않았습니다.Endor Labs와 다른 연구원들은 악성 로직이 공개 저장소가 아닌 PyPI에 배포된 빌드된 휠에 삽입된 것을 발견했습니다. 이는 공격이 가시적인 코드 커밋을 통해 발생한 것이 아니라 빌드/게시 프로세스 중 또는 후에 발생했음을 시사합니다.

구체적으로 분석가들은 해당 파일이 다음과 같다는 점을 관찰했습니다. litellm/proxy/proxy_server.py 내장된 base64 인코딩 페이로드는 다음과 같았습니다. GitHub 커밋의 동일 파일에는 없음약 12줄 정도의 코드가 정상적인 코드 블록 사이에 삽입되었습니다(예: 정의 근처). REALTIME_REQUEST_SCOPE_TEMPLATE 그리고 showwarning 함수). 이러한 추가 줄은 모듈이 임포트될 때마다 숨겨진 스크립트를 조용히 디코딩하고 실행했습니다.

버전에서 1.82.8공격자들은 한 걸음 더 나아가 폭탄을 투하했습니다. .pth 이름이 지정된 파일 litellm_init.pth 파이썬 환경으로. 파이썬은 모든 것을 처리하기 때문이다. .pth 인터프리터 시작 시 파일이 생성되므로 페이로드가 실행될 수 있었습니다. 모든 파이썬 호출 시LiteLLM 자체가 애플리케이션에 의해 임포트되지 않았더라도 마찬가지입니다.

이러한 사태 악화는 1.82.8 훨씬 더 위험함손상된 패키지가 설치된 환경에서 실행되는 모든 Python 스크립트, 테스트 실행기, 빌드 도구 또는 자동화 도구는 백그라운드에서 자격 증명 탈취 로직을 조용히 실행합니다.

더 넓은 범위의 TeamPCP 캠페인과의 연계

LiteLLM 해킹 사건은 단독으로 발생한 것이 아닙니다. Sonatype, Wiz, Endor Labs 등의 조사에 따르면 이 사건은 특정 조직과 연관되어 있습니다. TeamPCP가 진행 중인 공급망 캠페인2025년 말에 주목을 받기 시작한 이 그룹은 그 이후로 여러 오픈 소스 프로젝트와 개발자 생태계를 표적으로 삼아 왔습니다.

지난 3월 초, 동일한 인물들이 백도어 설치 사건에 연루된 것으로 드러났습니다. 아쿠아 시큐리티의 퀴즈 취약점 스캐너 및 관련 GitHub Actions, 그리고 Checkmarx 도구의 악성 변종(다음 포함)에 대한 공격이 포함됩니다. KICSGitHub Actions 및 OpenVSX 확장 프로그램도 포함됩니다. 이 캠페인은 npm 패키지, Docker Hub 이미지 및 Kubernetes 환경에도 영향을 미쳤으며, 인프라, 암호화 체계 및 영구 저장 아티팩트를 자주 재사용했습니다.

LiteLLM 사건을 추적해 본 결과, 관리자들은 다음과 같은 사실을 밝혔습니다. PyPI 게시 토큰 LiteLLM의 GitHub 저장소에 환경 변수로 저장된 토큰이 손상된 Trivy 워크플로를 통해 유출되었습니다. 그 토큰은 악용되어 다음과 같은 용도로 사용되었습니다. 오염된 PyPI 릴리스를 게시합니다이를 통해 공격자는 공개 소스 코드를 변경하지 않고도 사용자 계정의 2단계 인증을 우회하고 악성 휠을 삽입할 수 있습니다.

연구원들은 또한 3월 23일경 LiteLLM 관련 저장소에서 생성된 의심스러운 커밋과 워크플로를 지적했는데, 여기에는 수명이 짧은 브랜치와 다른 TeamPCP 페이로드에서 발견된 것과 유사한 RSA 공개 키를 포함하는 GitHub Actions 워크플로가 포함됩니다. 워크플로 실행에 대한 원격 측정 데이터는 해당 CI 실행기가 접근할 수 있는 비밀 정보에 접근하여 유출했을 가능성을 시사합니다.

이 집단은 여러 사건에서 일관된 패턴을 보여왔습니다. 한 환경에서 자격 증명을 탈취한 다음, 다른 생태계로 전환하세요.이 경우, Trivy의 GitHub Actions 설정 오류로 인해 권한 토큰이 탈취되었고, 이 토큰을 이용해 악성 Trivy 릴리스와 Docker 이미지가 배포되었습니다. 결과적으로 Checkmarx 툴링이 손상되었고, 최종적으로 LiteLLM PyPI 패키지까지 감염되었습니다.

LiteLLM 멀웨어의 작동 방식

여러 업체에서 제공한 분석 자료에 따르면 LiteLLM 백도어는 다음과 같은 특징을 가지고 있습니다. 다단계, base64로 난독화된 Python 페이로드 은밀하고 유연하며 복원력이 뛰어나도록 설계되었습니다. 논리는 대략 세 계층으로 구성되어 있으며, 각 계층은 공격의 서로 다른 단계를 처리합니다.

첫 번째 계층에서, 삽입된 코드는 proxy_server.py 또는 litellm_init.pth 파일 숨겨진 오케스트레이터를 해독하고 실행합니다.쉽게 플래그를 지정할 수 있는 함수를 사용하는 대신에 exec()이 스크립트는 서브프로세스 호출과 표준 라이브러리 기능을 활용하여 디코딩된 페이로드를 실행하고 출력을 캡처함으로써 일반적인 애플리케이션 동작에 자연스럽게 녹아들도록 설계되었습니다.

실행이 완료되면 이 오케스트레이터는 다음 단계의 출력을 수집합니다. 수집된 데이터를 AES-256-CBC로 암호화합니다. 그런 다음 코드에 내장된 하드코딩된 RSA 공개 키를 사용하여 AES 세션 키 자체를 암호화합니다. 암호화된 데이터 덩어리와 키는 라는 이름의 아카이브에 묶입니다. tpcp.tar.gz다른 TeamPCP 작전과 마찬가지로, 탈출을 위한 준비를 마쳤습니다.

두 번째 계층은 다음을 담당합니다. 공격적인 시스템 정찰 및 자격 증명 수집이 프로그램은 호스트 이름, 사용자 및 네트워크 정보, 환경 변수를 열거한 다음, 민감한 자료를 찾기 위해 긴 경로 및 구성 파일 목록을 검사합니다. 대상은 다음과 같습니다.

• SSH 키 및 설정 파일 (클라이언트와 서버)
• 클라우드 자격 증명 AWS, GCP 및 Azure의 경우 메타데이터에서 파생된 토큰을 포함합니다.
• Kubernetes kubeconfig 파일서비스 계정 토큰 및 클러스터 비밀 키
• 환경 파일 등 .env API 키를 저장하는 데 자주 사용되는 변형
• CI/CD 구성비밀 키 및 액세스 토큰
• Terraform, Helm 및 기타 IaC 또는 배포 관련 산출물
• 데이터베이스 연결 문자열 및 설정 파일
• TLS/SSL 개인 키 및 인증 자료
• 암호 화 지갑 및 관련 데이터

일부 환경에서는 도둑이 단순히 수집에 그치지 않고 더 나아가 다른 시도를 합니다. 발견된 자격 증명을 적극적으로 사용합니다.예를 들어 클라우드 공급자 API를 쿼리하거나, Kubernetes 비밀 정보를 가져오거나, 접근 가능한 리소스를 탐색하는 등의 행위를 통해 측면 이동 및 후속 침해 가능성을 높일 수 있습니다.

세 번째 레이어는 다음과 같은 기능을 제공합니다. 지속성 및 원격 제어이 기능은 파이썬 스크립트를 디스크에 저장합니다(일반적으로 다음과 같이 관찰됩니다). sysmon.py) 그리고 이를 장기 실행 서비스로 등록하는데, 종종 "시스템 원격 측정 서비스"와 같이 무해한 것으로 위장합니다. 이 서비스는 일반적으로 50분마다 공격자 인프라에 주기적으로 접속하여 추가 명령이나 페이로드를 가져옵니다.

연구원들은 여기서 몇 가지 특이한 동작을 발견했습니다. 특정 보안 업체들이 명령 및 제어 엔드포인트에서 페이로드를 얻으려고 시도했을 때, 서버는 마치 의도적으로 "Bad Apple!!"이라는 노래의 리마스터 버전 링크를 응답으로 보냈습니다. 자동 분석에 대한 주의 분산 전술하지만 감염된 시스템에서는 동일한 메커니즘이 시간이 지남에 따라 조용히 새로운 기능을 제공할 수 있습니다.

데이터 유출 경로 및 공격자 인프라

LiteLLM 사건 전반에 걸쳐 분석가들은 공격자가 장악한 최소 두 개의 주요 도메인과의 통신을 관찰했습니다. 모델리텔름클라우드 체크마르크스존이러한 요소들은 이전 TeamPCP 활동에서 사용된 인프라와 일치하며 각각 고유한 역할을 수행합니다.

암호화된 아카이브 tpcp.tar.gz 일반적으로 models.litellmcloud에 업로드됨이를 통해 운영자는 수천 개의 하위 환경에서 도난당한 자격 증명을 검색할 수 있습니다. 일부 변형에서는 다른 하위 경로가 사용됩니다. checkmarxzone (예 : checkmarxzone/raw or .../vsx)는 지속성 스크립트 또는 추가 단계를 전달하는 데 사용됩니다.

침해당한 시스템에서 방어자들은 반복적으로 발생하는 일련의 현상을 보고했습니다. 침해 지표(IoC) LiteLLM 멀웨어와 관련된 사항:

• 아카이브의 존재 tpcp.tar.gz 임시 또는 작업 디렉터리에
• 임시 파일(예: ...) /tmp/pglog /tmp/.pg_state
• 파이썬 스크립트 및 구성 경로 관련 sysmon.py 그리고 일치하는 서비스 파일(일반적으로 사용자 또는 systemd 구성 디렉터리 아래에 있음)이 있습니다.
• 예기치 않은 litellm_init.pth 버전 1.82.8용 Python 사이트 패키지의 파일
• 아웃바운드 트래픽 또는 DNS 조회가 가리키는 대상 모델리텔름클라우드 or 체크마르크스존

악성 로직은 다음 파일들에서 발견되었습니다. proxy_server.py (LiteLLM 1.82.7 및 1.82.8) 및 litellm_init.pth (1.82.8). 보안 공급업체는 해시와 추가 IoC를 목록화했으며 추가 포렌식 세부 정보가 나타남에 따라 권고 사항을 계속 업데이트하고 있습니다.

AI, 클라우드 및 CI/CD 환경에 미치는 영향

LiteLLM은 많이 사용되기 때문에 AI 기반 애플리케이션 및 서비스이러한 타협의 실질적인 파급 효과는 단순한 패키지 소비자를 넘어섭니다. LiteLLM이 LLM 제공업체에 대한 게이트웨이 역할을 했던 클라우드 환경에서는 동일한 런타임 또는 구성 공간에 비밀 키가 함께 위치할 가능성이 높습니다.

Wiz와 다른 관찰자들은 LiteLLM이 대략 에서 나타난다고 추정합니다. 관측된 구름 환경의 3분의 1이는 잠재적 파급 효과를 강조합니다. BleepingComputer가 인용한 일부 소식통에 따르면 데이터 유출 사건의 수가 수십만 건에 달할 수 있다고 하지만, 정확한 수치는 아직 독립적인 확인을 거치지 않았습니다.

특히, 해당 악성 소프트웨어는 다음을 강조합니다. Kubernetes 인식 동작많은 분석에서, 해당 페이로드는 클러스터의 모든 노드에 권한 있는 파드를 배포한 다음, 이러한 파드를 사용하여 비밀 정보와 구성 객체에 접근하려고 시도합니다. 별개이지만 관련된 TeamPCP 작전에서, 연구원들은 환경이 이란에 있는 것처럼 위장하여 노드를 완전히 삭제하는 스크립트를 사용하여 Kubernetes 클러스터를 공격하는 것을 확인했으며, 동시에 다른 위치에 백도어(소위 CanisterWorm과 같은)를 설치하는 것을 관찰했습니다.

CI/CD 툴에 대한 공격 집중도 역시 분명합니다. Trivy GitHub Actions, Checkmarx VS Code 확장 프로그램, GitHub Actions, 그리고 이제는 LiteLLM까지 공격 대상이 되면서, 공격자들은 다음과 같은 진입점을 확보하게 됩니다. 자동화는 이미 광범위한 권한을 가지고 있습니다. 저장소, 빌드 아티팩트 및 배포 자격 증명을 통해 이루어집니다. 이러한 접근 방식은 원래 보안에 중점을 둔 도구를 더 광범위한 침해를 위한 발판으로 만듭니다.

FBI 관계자와 업계 연구원들은 다음과 같은 점에 대해 경고해 왔습니다. 대량의 도난당한 자격 증명을 손에 넣었습니다.따라서 최초 LiteLLM 유출 사건 이후 몇 주 또는 몇 달 동안 더 많은 정보 유출 알림, 2차 침입 및 협박 시도가 발생할 것으로 예상하는 것이 합리적입니다.

탐지, 차단 및 복구 단계

LiteLLM 버전을 다운로드하거나 실행한 조직의 경우 1.82.7 또는 1.82.8 PyPI에서 보안 공급업체와 PyPI 관리자가 제공하는 지침은 매우 직설적입니다. 영향을 받은 시스템을 손상된 시스템으로 간주하십시오.패키지를 단순히 제거하는 것만으로는 지속성 메커니즘이 제거되거나 이미 발생했을 수 있는 자격 증명 도용을 되돌릴 수 없습니다.

권장되는 즉각적인 조치 사항은 다음과 같습니다.

• 설치된 설비를 식별하십시오. 개발자 컴퓨터, CI/CD 실행기, 컨테이너 및 프로덕션 환경 전반에 걸쳐 LiteLLM 1.82.7 또는 1.82.8 버전을 사용하십시오.
• 악성 버전을 제거하세요 그리고 LiteLLM을 안정적인 릴리스(보고 시점 기준으로 1.82.6이 마지막으로 안정적인 버전으로 널리 알려져 있음)에 고정하십시오.
• 모든 자격 증명을 순환시키세요 영향을 받는 환경에서 접근 가능한 정보: SSH 키, 클라우드 공급자 키 및 토큰, Kubernetes 시크릿, CI/CD 시크릿, 데이터베이스 자격 증명, TLS 키 및 모든 지갑 또는 결제 관련 시크릿.
• 지속성 아티팩트 검색같은 sysmon.py의심스러운 systemd 서비스 정의 및 비정상적인 파일들이 발견되었습니다. ~/.config 또는 임시 디렉터리와 같은 것 /tmp/pglog /tmp/.pg_state.
• 쿠버네티스 클러스터를 검사합니다 특히 다음과 같은 네임스페이스에서 예상치 못한 권한 있는 파드가 발생하는 경우 kube-system또한 특이한 서비스 계정이나 역할 바인딩의 경우에도 마찬가지입니다.
• 아웃바운드 연결을 모니터링합니다. 그리고 알려진 공격자 도메인에 대한 DNS 쿼리 등 models.litellmcloud checkmarxzone.

백도어가 상당한 기간 동안 실행되었을 가능성이 있는 환경에서는 많은 전문가들이 다음과 같은 조치를 제안합니다. 신뢰할 수 있는 기준선으로부터의 완전한 재구축 특히 중요 기반 시설의 경우 가장 안전한 방법일 수 있습니다. 하지만 악성코드의 특성을 고려할 때, LiteLLM 패키지를 제거하는 것만으로는 미묘한 변조나 추가 페이로드를 완전히 배제할 수는 없습니다.

또한 조직들이 더욱 강력한 방식을 채택하도록 장려되고 있습니다. 의존성 관리 및 공급망 방어특정 검증된 버전으로 고정하고, 수집 시점에 알려진 악성 패키지를 차단하거나 표시하는 도구를 활성화하며, 빌드 및 테스트 중에 예기치 않은 네트워크 또는 파일 시스템 활동을 감지할 수 있는 자동화된 동작 분석을 통합합니다.

LiteLLM 사례는 AI 소프트웨어 공급망에 대해 무엇을 시사하는가?

LiteLLM 사건은 지난 몇 년간 누적되어 온 더 광범위한 추세를 보여줍니다. AI 및 클라우드 스택의 핵심 구성 요소들이 주요 공격 대상이 되고 있습니다. 공급망 공격자들에게 있어 이러한 경향은 더욱 두드러집니다. 위협 행위자들은 최종 사용자 애플리케이션을 직접 공격하기보다는, 단일 라이브러리나 플러그인을 손상시켜 하위 조직 여러 곳에 접근할 수 있는 툴체인의 지점을 노리는 경우가 점점 더 많아지고 있습니다.

LiteLLM과 같은 패키지는 사실상 다음과 같은 위치에 있습니다. 비밀의 병목 현상이러한 구성 요소들은 AI 제공업체와의 호출을 중개하고, CI/CD 및 인프라 자동화 시스템에 접근하며, 종종 높은 권한으로 실행됩니다. 더 많은 기업들이 오픈 소스 도구를 사용하여 LLM 기능을 통합하려고 서두르면서, 이러한 구성 요소의 가치와 백도어를 심으려는 유인은 더욱 커지고 있습니다.

동시에 이번 공격은 빌드 및 퍼블리싱 파이프라인을 방어하는 데 따르는 어려움을 보여줍니다. 공격자들은 Trivy 워크플로의 잘못된 구성 설정을 악용하여 토큰을 탈취한 후, 해당 토큰을 사용하여 오염된 패키지를 PyPI에 푸시하는 동안 공개 소스 트리는 겉보기에는 깨끗한 상태로 남겨둔 것으로 알려졌습니다. 버전 태그와 빌드 단계는 공격 표면의 일부가 되었습니다.이는 많은 파이프라인이 고정된 커밋 대신 태그에 의존하고, 익숙한 관리자가 제공하는 결과물을 암묵적으로 신뢰한다는 사실을 악용한 것입니다.

Sonatype, Wiz, Endor Labs와 같은 공급업체들은 그 중요성을 강조합니다. 자동화된 실시간 안전장치 패키지 메타데이터와 저장소 기록이 정상적으로 보이더라도 이전에 발견되지 않았던 네트워크 목적지나 암호화된 데이터 유출과 같은 비정상적인 동작을 감지할 수 있습니다. 저장소 방화벽, 위협 인텔리전스 기반 스캐너, 그리고 종속성에 대한 컨텍스트 분석은 이제 선택 사항이 아닌 필수적인 보안 계층으로 여겨지고 있습니다.

유지보수 담당자와 관련 기관 모두에게 LiteLLM 해킹 사건은 다음 사항을 상기시켜 줍니다. 비밀 정보 관리, CI/CD 보안 강화 및 자격 증명 순환 이는 공급망 보안의 근간입니다. 이전 사고에서 불완전하거나 비원자적인 자격 증명 순환으로 인해 TeamPCP가 몇 주 후에 재사용할 수 있는 취약점이 발생했으며, 이는 사고 대응에서의 단 하나의 실수가 생태계 전반에 걸쳐 연쇄적인 영향을 미칠 수 있음을 보여줍니다.

LiteLLM을 휩쓴 캠페인은 처음에는 제한적인 워크플로 문제처럼 보였지만, 이후 GitHub Actions, Docker Hub 등으로 확산되었습니다. 샤이훌루드 npm 사건OpenVSX와 PyPI를 비롯한 여러 곳에서 백도어가 발견되었습니다. 널리 신뢰받는 도구와 AI 커넥터에 백도어가 숨어 있고, 탈취된 자격 증명이 공격자 인프라로 흘러들어가는 이번 사건은 소프트웨어 공급망이 얼마나 빠르게 매력적이고 효과적인 공격 표면이 될 수 있는지를 여실히 보여줍니다.