코드가 실행되기도 전에 26개의 PyPI 패키지가 클라우드 인증 정보를 탈취하고 있었다

주요 내용

• Hades는 .pth 시작 후크를 포함시켰기 때문에, 페이로드는 설치 시 한 번만 실행되는 것이 아니라 파이썬이 시작될 때마다 실행되었습니다.
• 이 같은 기법은 이미 11주 전에 LiteLLM에 적용된 바 있어, 새로운 기술은 아니었다.
• Wheels는 소스 빌드 단계를 건너뛰지만, 인터프리터가 시작될 때마다 코드를 실행하는 파일을 생성할 수는 있습니다.
• 자신의 환경을 점검하는 데는 몇 가지 명령어만 있으면 되며, 발견되는 .pth 파일 대부분은 정상적인 파일일 것입니다.

개발자가 `pip install`을 실행하면 명령어가 정상적으로 종료되고, CI 작업도 성공(녹색)으로 표시됩니다. 패키지가 휠(wheel) 형식으로 제공되었기 때문에 실제로는 아무것도 빌드되지 않았고 소스 빌드 단계도 실행되지 않았는데, 휠은 더 안전한 선택으로 여겨졌기 때문입니다.

그러면 다음 파이썬 프로세스가 시작됩니다. 어떤 것이 ~/.aws/credentials 파일을 읽습니다.

이는 2026년 6월 8일 Orca Security가 공개한 하데스(Hades) 캠페인의 대략적인 양상으로, 26개의 PyPI 패키지에 걸쳐에 걸쳐 진행된 것입니다. 소켓(Socket)은 동일한 37개의 악성 휠(wheel) 파일을 분석한 결과 19개의 패키지를 확인했으므로, 표면상의 숫자는 어떤 목록을 참조하느냐에 따라 달라집니다. 어느 쪽이든 이 공격은 설치 시 코드 실행을 줄이기 위해 특별히 구축된 여러 제어 장치를 우회하는데, 버그를 악용하는 것이 아니라 대부분의 제어 장치가 존재하기 전부터 표준 라이브러리에 포함되어 있던 기능을 이용함으로써 이루어집니다.

‘하데스’ 캠페인의 구조

이 사례가 일반적인 타이포스쿼팅 과 차별화되는 점은 어떤 단일한 기법이 아니라, 여러 기법의 조합에 있습니다.

이것들은 누군가가 실수로 설치 버튼을 누르기를 기다리는 가짜 유사 이름들이 아니었습니다. 배포 양상을 살펴보면, 유지보수자 계정이 해킹당한 뒤 해당 유지보수자가 관리하는 패키지 포트폴리오 전반에 걸쳐 과학용 파이썬, 생물정보학, 머신러닝 도구 분야에 집중된 패치 릴리스가 연달아 쏟아져 나온 것으로 보입니다. 패키지 팀들이 이미 신뢰하고 있던 패키지들에서 악성 코드가 포함된 새 릴리스가 배포되기 시작했습니다.

해킹된 각 릴리스는 *-setup.pth와 일치하는 파일을 site-packages 폴더에 직접 삽입했습니다. 많은 정보 탈취형 악성코드가 암호화폐 지갑이나 브라우저 쿠키를 노리는 것과는 달리, 이 페이로드는 클라우드 인증 정보, 개발자 비밀 정보, 그리고 CI/CD 토큰을 노렸습니다. 스타트업 훅은 단지 첫 단계에 불과합니다. 이 훅은 GitHub에서 Bun 자바스크립트 런타임을 다운로드한 뒤, _index.js라는 난독화된 자바스크립트 페이로드를 실행합니다. AWS 키를 훔치기 위해 자바스크립트 런타임을 부트스트랩하는 파이썬 스타트업 훅이라는 문장은 쓰기에는 이상하지만, 실제로 일어난 일을 정확히 묘사한 것입니다.

일부 샘플에는 ‘gh-token-monitor’라는 상주 데몬이 포함되어 있었는데, 이 데몬은 도난당한 토큰이 무효화될 경우 파괴적인 조치를 취하겠다고 위협합니다. 올바른 사고 대응 조치를 취했다는 이유로 사용자에게 보복을 가하도록 설계된 악성코드는 꽤나 참신한 발상이라 잠시 곰곰이 생각해 볼 만합니다.

하데스는 갑자기 나타난 것이 아닙니다. 이는 2026년 3월의 LiteLLM 타협안 와 2026년 5월에 보고된 durabletask 패키지 침해 사건에 이어 발생한 것으로, 이로써 3개월도 채 되지 않는 기간 내에 주목할 만한 PyPI 공급망 공격 세 건이 발생했습니다. 이 세 건 모두 TeamPCP, Mini Shai-Hulud, Miasma 등의 이름으로 추적되는 동일한 광범위한 캠페인 계보와 연관되어 있습니다.

LiteLLM 관련 부분이 가장 골치 아픈 대목입니다. 스타트업 후크 기법은 6월 당시 이미 새로운 것이 아니었습니다. 이 기법은 지난 3월, 하루 수백만 건의 다운로드를 기록하던 패키지에 ‘litellm_init.pth’라는 파일 형태로 포함되어 배포되었으며, 11주가 지난 후에도 여전히 설치 시 실행을 차단하기 위해 구축된 제어 장치를 우회해 악성 코드를 유포하는 데 활용되고 있었습니다.

.pth 파일이 코드보다 먼저 실행되는 이유

다음은 그 작동 원리인데, 못생긴 것들이 가끔 그렇듯 꽤 인상적입니다.

일반적인 시작 과정에서 Python의 site 모듈은 구성된 사이트 디렉터리에서 발견된 .pth 파일을 처리합니다. 공식적으로는 이 기능이 sys.path에 디렉터리를 추가하기 위한 것으로, 한 줄에 하나의 디렉터리를 지정합니다. 하지만 같은 모듈에는 두 번째로, 훨씬 덜 알려진 동작이 하나 더 있습니다. import로 시작하고 그 뒤에 공백이나 탭이 오는 모든 줄은 Python 코드로 실행됩니다.

그러니 한 줄이면 충분합니다.

import os, base64; exec(base64.b64decode('…'))

이 파일을 site-packages 폴더 내에 .pth 확장자로 저장하기만 하면, 별도로 가져오거나 호출할 필요가 없습니다. 해당 환경에서 파이썬 프로세스가 시작될 때마다 자동으로 실행됩니다. 사용량이 많은 CI 러너나 개발자 노트북에서는 하루에 수십 번씩 실행되며, pip를 실행할 때, python -c를 실행할 때, 그리고 편집기의 언어 서버가 백그라운드에서 수행하는 모든 작업 시에도 실행됩니다.

알고 계셨나요? 이는 버그도 아니고 교묘한 악용 기법도 아닙니다. 이는 파이썬의 `site` 모듈에 문서화된 동작으로, 현대의 패키징 도구가 등장하기 수년 전부터 존재해 왔으며, 현재 MITRE에서는 이를 ‘Python Startup Hooks’라는 명명된 공격 기법으로 분류하고, ‘Event Triggered Execution’ 하위 기법인 T1546.018로 추적하고 있습니다.

Setuptools는 일부 편집 가능한 설치 과정에서 .pth 파일을 사용하며, coverage.py도 동일한 메커니즘을 활용해 하위 프로세스 내에서 coverage를 자동으로 실행할 수 있습니다. 바로 이 점이 coverage.py를 훌륭한 공격 경로로 만드는 이유입니다. 악성 .pth 파일을 탐지하려는 스캐너는 setuptools에 포함되어 있으며, 완전히 정당한 이유로 구조적으로 동일한 기능을 수행하는 distutils-precedence.pth 파일과 이를 어떻게든 구별해내야 합니다.

바퀴가 왜 안전한 형태라고 여겨졌는지

수년 동안 소스 배포판보다는 휠을 선호하라는 것이 일반적인 조언이었으며, 그 근거는 여전히 타당합니다. sdist를 설치한다는 것은 대개 먼저 빌드해야 한다는 것을 의미하는데, 이 빌드 과정에서는 PEP 517 백엔드를 통해 패키지 관리 시스템이 제어하는 코드가 실행되며, 이는 어떻게 포장하든 간에 임의의 코드 실행에 해당합니다. 반면 휠은 이미 빌드된 상태이므로, 휠을 설치하는 것은 대부분 압축을 풀고 파일을 배치하는 작업에 불과합니다.

그 조언은 여전히 타당하며, 어쨌든 이 방법은 효과가 있었습니다. 휠 파일에는 .pth 파일이 포함될 수 있으며, 휠 파일을 압축 해제하면 최상위 .pth 파일이 site-packages 디렉터리에 바로 배치됩니다.

실행은 단지 지연된 상태로 이루어질 뿐입니다.

휠 행을 살펴보세요. 설치 시점에 환경을 검사했지만 아무것도 발견하지 못한 것은 오작동이 아닙니다. 설치 시점에는 아직 악의적인 코드가 실행된 적이 없기 때문입니다. 페이로드는 대기하다가 다음 파이썬 호출 시 실행되는데, 컨테이너 빌드 환경에서는 이미지가 이미 푸시되어 트래픽을 처리하기 시작할 때까지 이 호출이 발생하지 않을 수도 있습니다.

주의: 설치 시 샌드박싱과 ‘휠 전용’ 정책은 모두 유용한 제어 수단이지만, 이 중 어느 하나만으로는 나중에 파이썬이 해당 샌드박스 외부에서 실행될 때 악성 .pth 후크가 실행되는 것을 막을 수 없습니다. 위협 모델에서 이 두 가지가 임의 코드 실행을 충분히 방어한다고 가정했다면, 그 가정을 다시 검토해야 합니다.

가장 강력한 통제 지점 중 하나는 유물이 환경에 도달하기 훨씬 이전 단계에 위치해 있는데, 이는 설치 시 동작이 보고하는 내용을 신뢰하기보다는 패키지에 실제로 무엇이 포함되어 있는지 직접 검사하고 확인해야 함을 의미합니다. 소스 코드에서 패키지를 재컴파일하고 그 결과물을 확인하는 것이 이를 달성하는 한 가지 방법입니다.

페이로드가 추적하던 대상은 무엇이었을까

주로 클라우드 인증 정보입니다. 그리고 검색 범위는 대부분의 팀이 생각하는 것보다 훨씬 좁고 예측 가능합니다. 개발자 머신이나 CI 러너는 잘 알려진 몇 가지 위치에 귀중한 비밀 정보를 노출하는 경향이 있기 때문입니다. ~/.aws 아래의 인증 정보 및 구성 파일, ~/.config/gcloud 아래의 애플리케이션 기본 인증 정보, ~/.kube/config에 있는 kubeconfig, ~/.docker/config.json에 있는 레지스트리 인증 정보 등이 있습니다. CI 플랫폼이 주입하는 모든 환경 변수도 포함됩니다. 또한 클라우드 호스트의 경우, 169.254.169.254에 위치한 인스턴스 메타데이터 서비스도 해당됩니다. Hades 보고서에 따르면 GitHub, npm, PyPI, RubyGems 토큰 및 SSH 키도 주요 표적 상위에 위치하는데, 이것이 바로 자격 증명 탈취 도구가 스스로 확산되는 방식으로 변모하는 이유입니다.

접근이 가능한 경우, 메타데이터 서비스가 진정한 핵심 목표입니다. 이것이 바로 고장 난 노트북 하나를 통해 주변 클라우드 환경의 훨씬 더 광범위한 영역을 침해로 이끌 수 있는 요소입니다. IAM 역할이 할당된 빌드 에이전트에서, 단순한 SSRF가 아닌 실제 코드 실행이 가능한 페이로드는 해당 역할이 수행할 수 있는 모든 작업에 대한 임시 자격 증명을 획득할 수 있습니다. 구형 IMDSv1 환경에서는 간단한 GET 요청으로, IMDSv2가 적용된 환경에서는 PUT 요청 후 GET을 통한 토큰 교환 방식으로 이루어집니다. 어느 경우든 디스크에 아무것도 남아 있을 필요가 없습니다.

이것이 바로 이 모든 일의 전략적 논리입니다. 빌드 환경에서 추출한 인증 정보는 누군가의 노트북에서 빼낸 인증 정보보다 가치가 더 높으며, CI 실행기는 워크스테이션에 비해 사람의 직접적인 관심을 덜 받는 경향이 있으면서도 유난히 귀중한 기밀 정보를 보유하고 있습니다.

AI 스캐너를 대상으로 한 부분

하데스에 대한 여러 보고서에 따르면, 패키지 내부에서 간접 프롬프트 주입이 확인되었으며, 이는 AI 지원 보안 검토를 조작하기 위해 풀 리퀘스트를 검토하는 사람을 속이기 위한 것이 아니라, AI 지원 보안 검토를 조작하기 위해 작성된 텍스트가 포함되어 있다는 점을 지적하고 있습니다.

이는 주목할 만한 새로운 변화이며, 공격자들이 이제 패키지와 엔지니어 사이에 대규모 언어 모델(LLM)이 존재한다고 가정할 때만 이 전술이 타당해집니다. 2026년 중반 시점에서 이는 결코 터무니없는 가정이 아닙니다. 일부 팀은 이미 사람이 직접 확인하기 전에 의존성 차이점을 요약해 주는 모델을 도입하고 있습니다.

이로 인해 불편한 문제가 발생합니다. 신뢰할 수 없는 패키지 내용을 읽는 모델은, 정의상 공격자가 제어하는 입력을 처리하는 것입니다. 따라서 다른 신뢰할 수 없는 입력 경로와 마찬가지로 처리되어야 합니다. 이 모델이 절대 맡아서는 안 되는 역할은, 방금 읽은 내용이 안전한지 여부에 대해 독립적인 판단자 역할을 하는 것입니다. 그러한 판단을 권위 있는 것으로 간주하는 것은, 통제 수단인 척 위장한 순환 의존성에 불과합니다.

전문가 팁: 파이프라인의 어느 단계에서든 모델이 종속성 내용을 검토하는 경우, 해당 패키지를 신뢰할 수 없는 입력으로 간주하고 그 내용을 검토자의 지시 컨텍스트에서 제외하십시오. 이를 결정론적 정적 검사와 함께 사용하며, 모델의 판정 결과만을 유일한 통과 기준으로 삼지 마십시오.

지금 당장 환경을 점검하는 방법

자신이 영향을 받았다고 생각하든 그렇지 않든 해볼 만한 일이며, 대규모 프로젝트라기보다는 몇 가지 명령어만 실행하면 되는 간단한 작업입니다. 노출 여부에 대한 빠른 답변을 원하신다면, Orca 및 Socket 관련 문서에 영향을 받은 패키지 목록이 공개되어 있으니, 이를 자신의 lockfile과 비교해 보는 것이 추측하는 것보다 훨씬 낫습니다.

먼저, 실제로 처리되는 사이트 디렉터리를 찾아야 합니다. 사용자별 site-packages 디렉터리도 포함되기 때문에 이 점이 중요하며, 시스템 전용 목록만으로는 이를 간과하게 될 수 있습니다.

python -m site

그런 다음, 리눅스나 macOS에서는 실행 가능 명령어가 포함된 .pth 파일을 찾아보세요. 윈도우의 경우, Python 설치 디렉터리와 가상 환경 내의 site-packages 디렉터리를 동일한 방식으로 일일이 확인해야 합니다.

find / -path “*site-packages*” -name “*.pth” \

  -exec grep -lE “^import[[:space:]]” {} \; 2>/dev/null

이 공백 처리 방식이 중요한 이유는, site가 import 뒤에 공백이나 탭이 따라오는 줄만 실행하기 때문이며, 단순히 ^import만 있는 경우 importlib로 시작하는 전혀 문제가 없는 줄과도 일치해 버리기 때문입니다. 이 작업을 진행하는 김에, Hades 전용 패스는 *-setup.pth와 일치하는 모든 항목을 검색하는 것이며, sitecustomize.py와 usercustomize.py도 동일한 시작 후크 계열에 속하므로 함께 살펴볼 필요가 있습니다. 일부 Hades 샘플은 .pth 파일을 아예 제공하지 않고 대신 __init__.py에 코드를 삽입한 것으로 알려져 있으므로, .pth 파일만 검사하는 것만으로는 문제가 없다고 단정할 수 없습니다.

일부 항목이 검색될 텐데, 이는 정상적인 현상입니다. setuptools의 distutils-precedence.pth, 편집 가능한 설치 환경에서 나오는 __editable__*.pth, 그리고 과학 라이브러리에서 한두 개 정도가 검색될 것으로 예상됩니다. 어쨌든 이 파일들을 꼼꼼히 살펴보세요. 정상적인 .pth 파일은 대개 특정 도구에 의해 생성된 경로 항목이나 작은 임포트 후크를 포함하고 있습니다. 하지만 인코딩된 블롭, exec() 호출, 서브프로세스 생성, 또는 네트워크에 접근하는 모든 내용은 훨씬 더 면밀히 살펴봐야 합니다. 물론, 어떤 단일 패턴만으로는 파일이 유해하다고 단정할 수는 없습니다.

추적 중인 특정 동작의 원인이 사이트 처리 과정에 있는지 확인하려면, 해당 기능을 비활성화한 상태로 인터프리터를 실행해 보세요.

python -S -c “print(‘사이트 처리 건너뜀’)”

-S 옵션을 적용했을 때 해당 현상이 사라진다면, 사이트 초기화가 원인일 가능성이 높으며, 이 경우 .pth 후크를 조사해 볼 필요가 있습니다. 이렇게 하면 조사 범위를 좁힐 수 있습니다. 다만 -S 옵션은 .pth 실행 외에도 상당히 많은 기능을 비활성시키기 때문에, 어떤 시작 메커니즘이 원인이었는지를 증명해 주지는 않습니다.

바퀴가 지면에 닿기 전에 상태를 확인하는 데는 두 개의 명령어가 필요합니다.

pip download –no-deps somepackage

unzip -l somepackage-*.whl | grep ‘\.pth’

.pth 파일을 포함하는 휠이 반드시 악성인 것은 아니며, .pth 파일 자체만으로는 아무것도 자동으로 실행되지 않습니다. ‘import’로 시작하고 공백이 뒤따르는 줄만 실행되기 때문입니다. 하지만 해당 파일을 포함하는 휠은 그 파일의 내용을 꼼꼼히 살펴볼 필요가 있으며, 만약 실행 가능한 import 줄이 포함되어 있다면, 이를 lockfile에 추가하기 전에 미리 논의하는 것이, 추가한 후에 논의하는 것보다 낫습니다.

만약 문제가 되는 패키지를 발견했다면, 해당 패키지를 제거한 후 휠 캐시를 완전히 지워야 합니다. pip나 uv의 캐시에 남아 있는 손상된 휠은 다음에 해당 버전을 참조할 때 아무 문제 없이 다시 설치될 수 있기 때문입니다. 그런 다음 환경이 접근할 수 있는 모든 항목을 교체하십시오. 클라우드 키, GitHub, PyPI 및 npm 토큰, SSH 키, kubeconfig 등이 포함됩니다. Orca의 Hades 관련 지침에서는 패키지 제거와 자격 증명 갱신을 선택 사항이 아닌 필수 사항으로 다루고 있으며, 이것이 올바른 접근 방식입니다.

왜 ‘pip install’이 신뢰를 시작하기에 부적절한 곳인가

LiteLLM, durabletask, Hades는 세부 사항에서 차이가 있지만, 그 밑바탕에 깔린 패턴은 동일합니다. 이들 중 어느 것도 해당 패키지를 사용하는 애플리케이션에 취약점이 있을 필요가 없었습니다. LiteLLM의 경우 훼손된 릴리스 프로세스, durabletask의 경우 도난당한 게시 토큰, Hades의 경우 탈취된 게시자 신원 정보와 문서화된 시작 후크를 악용하는 등, 각 사례는 시스템이 설계상 신뢰할 수 있는 것으로 간주하는 패키징 파이프라인의 일부를 악용했습니다.

이 패턴이 배제하는 한 가지는 해시 고정(hash pinning)입니다. 악성 코드인 litellm_init.pth는 휠(wheel) 자체의 RECORD에 일치하는 해시와 함께 올바르게 선언되어 있었기 때문에, `pip install –require-hashes` 명령은 아무런 문제 없이 정상적으로 실행되었을 것입니다. 해시는 다운로드한 아티팩트가 승인한 아티팩트와 일치함을 증명할 뿐입니다. 해시는 승인된 아티팩트가 무해했다는 사실이나, 해당 아티팩트의 게시자가 해킹당하지 않았다는 사실을 증명하지는 않습니다.

실제로는, 실행 중인 파이썬의 양에 따라 응답이 달라집니다.

몇 가지 서비스만이라도? .pth 파일을 철저히 점검하고, 최신 버전을 도입하기 전에 짧은 격리 기간을 두십시오. 이러한 공격 캠페인은 방어 측이 대응할 시간을 갖기 전에 새로 공개된 악성 버전을 통해 초기 확산의 상당 부분을 확보했기 때문입니다.

대규모 시스템 환경에서 파이썬을 운영하고 계신가요? 보안 감사는 좋은 출발점이지만, 더 효과적인 아키텍처적 접근 방식은 패키지 검증을 설치 단계보다 앞선 단계로 옮겨, 악성 아티팩트가 애초에 site-packages에 도달할 가능성을 줄이는 것입니다.

또한 CI 실행기가 클라우드 역할 자격 증명을 보유하고 있다면, 그 부분부터 점검해 보세요. 해당 역할의 권한 범위를 최대한 좁게 설정하고, 유효 기간이 긴 정적 자격 증명은 제거하며, 플랫폼에서 허용하는 곳이라면 어디에서든 유효 기간이 짧은 자격 증명을 사용하세요. 잘못된 설치가 사고로 이어질 경우, 피해 범위가 가장 크게 확산되는 곳이 바로 그곳이기 때문입니다.

파이썬 공급망 보안 강화

이러한 선별 과정을 상류 단계로 앞당기는 것이 바로 SecureChain for Python의 핵심 전제입니다. 패키지는 인터프리터가 시작될 때마다 이미 실행 중인 상태에서 스캔되는 방식이 아니라, 사용자의 환경에 도달하기 전에 소스 코드부터 재컴파일되어 검사됩니다. 또한 이러한 검사는 설치 당일에 그치지 않습니다.

새로운 CVE 이미 실행 중인 패키지에 대한 새로운 CVE가 공개되고, 결국 유지보수 담당자가 완전히 손을 떼는 경우가 있습니다. SecureChain은 사용자의 스택에 실제로 포함된 구성 요소에 대해 지속적으로 패치를 적용하며, 카탈로그에 등재된 패키지의 경우 지원 종료 후에도 지원 종료 이후에도 지속되므로, 패치가 적용되지 않은 종속성을 그대로 둘지 아니면 강제로 코드를 재작성해야 할지 고민하는 상황에 처하지 않게 됩니다. 현재 ‘휠 전용’ 정책이나 설치 후 스캔이 방어선 역할을 하고 있다면, Hades는 설치 시점과 그 이후 매일 그 방어선이 실제로 어디에 위치하는지 확인해 볼 만한 적절한 계기가 될 것입니다.

자주 묻는 질문

PyPI 악성코드란 무엇인가요?

다음에 게시된 악성 코드 Python Package Index에 게시되며, 대개 합법적인 패키지를 사칭하는 패키지 내부나, 게시자 계정이 해킹당한 합법적인 패키지 내에 숨어 있습니다. 이 코드는 애플리케이션 코드가 호출할 때까지 기다리기보다는 설치 중이나 인터프리터 시작 시에 실행되는 경우가 많습니다.

.pth 파일이란 무엇이며, 왜 위험한가요?

파이썬의 사이트 디렉토리 중 하나에 위치한 .pth 파일은 시작 시 site 모듈에 의해 처리됩니다. import로 시작하고 그 뒤에 공백이나 탭이 따라오는 줄은 실행되는데, 이는 .pth 파일이 파이썬 프로세스가 시작될 때마다 임의의 코드를 실행할 수 있음을 의미합니다. 이는 문서화되어 있는 의도된 동작이며, setuptools와 편집 가능한 설치 방식 모두 이를 적법하게 활용하고 있습니다. 바로 이 점 때문에 악의적인 파일을 발견하기가 까다로운 것입니다.

Wheels는 악성 파이썬 패키지에 대한 보호 기능을 제공하나요?

부분적으로만 그렇습니다. Wheels는 sdist를 설치할 때 필요한 소스 빌드 단계를 거치지 않으며, 해당 빌드 단계에서는 패키지 제어 코드가 실행될 수 있습니다. 또한 Wheels는 패키지가 인터프리터가 시작될 때마다 실행되는 import 문이 포함된 .pth 파일을 함께 배포하는 것을 막지는 못합니다.

패키지가 시작 후크를 설치했는지 어떻게 확인할 수 있나요?

Python이 실제로 사용하는 사이트 디렉터리를 검색하여, ‘import’로 시작하고 그 뒤에 공백이 오는 줄이 포함된 .pth 파일을 찾아낸 다음, 이를 올바르게 읽어들이십시오. -S 옵션을 사용하여 인터프리터를 실행하면 .pth 파일 처리를 포함한 사이트의 자동 초기화가 비활성화되므로, 어떤 메커니즘이 문제를 일으켰는지는 확인하지 못하더라도 시작 시 동작이 관련되어 있는지 여부를 파악하는 데 도움이 됩니다.

pip-audit나 스캐너가 이 문제를 감지하나요?

도구에 따라 다릅니다. 자문 기반 스캐너는 기본이 되는 취약점 및 악성 패키지 피드에 의존하기 때문에, 새로 공개된 악성 버전이 즉시 탐지되지 않을 수도 있습니다. 행동 기반 및 아티팩트 기반 도구는 때때로 더 빠르게 위협을 포착하기도 하며, 탐지 범위는 공급업체마다 큰 차이를 보입니다.

요약

기사 이름

PyPI 악성코드와 ‘Hades’ 스타트업 후크 캠페인의 작동 방식

설명

Hades는 .pth 시작 후크를 이용해 26개의 패키지에 PyPI 악성코드를 숨겼습니다. 페이로드가 사용자의 코드보다 먼저 실행된 경위와, 자신의 환경을 점검하는 방법을 확인해 보세요.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고