서문
지난 월요일 밤 늦게까지 일하고 있었는데 3일 전에 구축한 모니터링 도구에서 Slack 알림이 들어왔습니다. 세계에서 가장 인기 있는 npm 패키지 중 하나인 Axios가 손상되었습니다.
심장이 뛰기 시작했고, 매 순간 대응하고 피해를 최소화하는 것이 중요하다는 것을 알았습니다. 하지만 솔직히 너무 황당해서 오탐이 틀림없다고 생각했습니다. 명백히 악의적인 것처럼 보였음에도 불구하고 몇 번이나 확인하고 또 확인했습니다.
오탐이 아니었습니다. 이는 북한 국가 행위자의 소행으로 추정되는 역대 최대 규모의 공급망 침해 사건 중 하나였습니다. 저희는 금요일 오후에 노트북에서 AI 판독 차이점을 기반으로 함께 해킹한 개념 증명으로 이 문제를 발견했습니다.
전체 이야기를 공유하고 싶습니다. 우리가 어떻게 여기까지 왔는지, 내가 무엇을 만들었는지, 왜 그것을 공개적으로 공유하면 모두가 조금 더 안전해질 수 있다고 생각하는지 설명합니다.
한동안 공급망에 대한 걱정이 많았습니다.
최근 몇 가지 공급망 사고로 인해 정말 밤잠을 설치기도 했습니다. 공급망 타협은 어려운 문제입니다. Elastic에는 수많은 개발자가 있으며, 보안 고객들은 우리를 믿고 자신을 보호해주고 있습니다. 현상 유지에 문제가 있는 것은 분명하며, 새로운 기술이나 절차가 필요합니다. 저는 비용과 마찰을 줄이면서 앱 제어 원칙을 기반으로 보다 신뢰할 수 있고 AI가 검증한 에코시스템에 대한 몇 가지 아이디어를 생각해냈습니다.
하지만 제가 주목한 부분은 바로 트리비와의 타협이었습니다. 3월 19일, TeamPCP라는 그룹이 아쿠아시큐리티/트리비 액션 (인기 보안 도구인 트리비 보안 스캐너를 위한 GitHub 액션)을 침해했습니다. 이들은 CI/CD 파이프라인에서 기밀을 수집하는 크리덴셜 스틸러를 주입했습니다. 엄청난 양의 자격 증명이 도난당했습니다.
이는 빠르게 확산되었습니다. 3월 24일, LiteLLM이 공격을 받았습니다. TeamPCP는 독이 든 트리비 파이프라인을 통해 LiteLLM의 PyPI 게시 자격 증명을 훔쳐 공격적인 자격 증명 도용자인 악성 버전을 푸시하는 데 사용했습니다. SSH 키, 클라우드 크레딧, API 키, 지갑 데이터 등 모든 것이 있습니다.
LiteLLM은 제가 직접 사용했던 패키지입니다. 그래서 그 당시 저는 밤에 완전히 "깨어 있었다고 할 수 있습니다."
트리비 침해로 인해 유출된 인증정보가 많았기 때문에 더 많은 정보가 유출될 것이 분명했습니다. 우리는 앞서 나가기 위해 무언가를 해야 했습니다. 고객과 Elastic을 보호하기 위해서입니다.
금요일, 적목 현상 이후
저는 샌프란시스코에서 열린 RSAC 2026에서 막 비행기를 타고 돌아왔습니다. 목요일 밤 늦은 시간 비행. 나흘간의 회의 후 적목현상을 겪어보셨다면 제가 어떤 상태였는지 아실 겁니다. 하지만 새로운 프로젝트에 대한 기대가 그 어느 때보다 컸던 저는 앉아서 0.0.1 버전을 만들었습니다.
패키지 리포지토리에 푸시되는 변경 사항을 모니터링하세요. diff를 실행하여 변경된 사항을 확인합니다. AI/LLM을 사용하여 변경 사항이 악의적인지 확인합니다. 기본적으로 그게 다입니다.
파이프라인은 다음과 같습니다:
- PyPI의 변경 로그 API와 npm의 CouchDB
_changes피드에서 새 릴리스에 대해 투표하세요. - 다운로드 수에 따라 상위 15,000개 패키지의 관심 목록으로 필터링하세요.
- 레지스트리에서 직접 이전 버전과 새 버전을 다운로드합니다(pip 설치, npm 설치, 코드 실행 없음).
- 마크다운 보고서로 차별화
- 차이점을 LLM으로 보내기: "악의적인가요?"
- 그렇다면 Slack에 알립니다.
어차피 공격자들이 가장 많이 공격할 가능성이 높고 토큰과 컴퓨팅 비용이 훨씬 적게 들기 때문에 주로 상위 패키지에 집중하고 싶었습니다. 제 노트북에서 실행하는 데 전혀 문제가 없었습니다.
커서가 필요한 이유
시중에는 수많은 상담원 하네스가 있습니다. 저는 AI 멀웨어 리버스 엔지니어링과 같은 프로젝트를 위해 직접 작성한 적이 있습니다. 하지만 시간이 촉박했기 때문에 제가 주로 사용하는 개발 도구 중 하나인 커서를 활용하기로 결정했습니다. 에이전트 CLI를 사용하면 워크스페이스, 명령어, 모델을 전달하는 등 프로그래밍 방식으로 호출할 수 있습니다. ask 모드(읽기 전용)로 실행하여 차이점만 읽을 수 있고 아무것도 수정할 수 없도록 했습니다. 전체 분석 단계는 하나의 하위 프로세스 호출로 이루어집니다.
프롬프트는 간단합니다. 무엇을 찾아야 하는지(난독화된 코드, base64, 실행/평가, 예기치 않은 네트워크 호출, 스테가노그래피, 지속성 메커니즘, 수명 주기 스크립트 남용) 알려주고 Verdict: malicious 또는 Verdict: benign 으로 응답해 달라고 요청합니다. 판결을 분석하고 그에 따라 행동하세요.
모델 선택 시
저는 보통 대부분의 작업에 Opus 4.6 또는 GPT 5.4를 사용합니다. 특히 사이버 보안에 중점을 둔 작업에 적합합니다. 하지만 시간당 수십 개의 릴리스를 분석해야 하는 작업의 경우 비용을 낮추고 싶었습니다.
최근 커서 팀에서 에이전트 도구의 빠른 정규식 검색에 대한 블로그 게시물과 실제 프로덕션 추론 토큰을 트레이닝 신호로 사용하고 약 5시간마다 개선된 체크포인트를 배포하는 실시간 RL 접근 방식에 대한 블로그 게시물 등 정말 좋은 블로그 게시물이 몇 개 올라와 있습니다. 진정으로 인상적인 엔지니어링.
그래서 작곡가( 2 )를 사용해보고 싶었습니다. 저는 빠른 모드를 사용했는데 정말 빠릅니다. 실시간 사용 사례에 적합합니다. 저렴한 비용으로 빠르고 효과적입니다(테스트 결과).
Telnyx에서 테스트
실제로 작동하는지 확인하려면 이러한 기능을 테스트해야 합니다. 일반적으로 프롬프트를 많이 조정해야 한다는 뜻입니다.
타이밍이 운이 좋았거나 운이 나빴습니다. 제가 빌드하던 바로 그 금요일, TeamPCP에 의해 텔닉스 PyPI 패키지가 침해당했습니다. 이들은 _client.py 에 74 줄의 악성 코드를 주입했습니다: WAV 오디오 파일 안에 숨겨진 페이로드(스테가노그래피), base64 난독화, msbuild.exe 로 위장한 Windows 지속성 임플란트, 하드코딩된 C2 로의 유출.
정상 패키지와 악성 패키지의 차이점( telnyx )을 이용해 초기 프롬프트를 만들었습니다. 이 모델은 이와 같은 악의적인 변경 사항을 식별하는 데 매우 능숙했습니다. 또한 침해가 감지되면 즉시 알고 싶었기 때문에 Slack 알림을 추가했습니다.
월요일 밤
주말에 실행해 보았습니다. 릴리스가 거듭될수록 모든 것이 정상으로 돌아왔습니다.
사이버 보안 분야에서 탐지 작업을 해본 사람이라면 솔직히 이상할 정도로 오탐이 단 한 번도 발생하지 않았습니다. 우리는 보통 FP에 빠져 있습니다. 일반적으로 즉시 트리거가 발생하기 때문에 의도적으로 LLM에 "신뢰도가 높은" 공급망 침해에 대해서만 경고하도록 지시했습니다. 아직 FP 없이 Telnyx 테스트 케이스를 포착 중입니다. 표본 크기가 너무 작아서 과적합할 수 있지만, 더 강력한 것을 구축할 시간이 없습니다.
그러던 월요일 밤, 늦게까지 일하고 있는데 Slack 알림이 왔습니다.
🚨 Supply Chain Alert: axios 0.30.4
Verdict: MALICIOUS
npm: https://www.npmjs.com/package/axios/v/0.30.4최근 기억에 남는 가장 큰 공급망 침해 사건 중 하나를 발견한 것일까요?
분석 결과를 확인했습니다. 다시 확인했습니다. 다시 확인했습니다. 공격자는 관리자의 npm 계정을 침해하고 이메일을 자신들이 제어하는 ProtonMail 계정으로 변경한 후 두 개의 악성 버전(1.14.1 및 0.30.4)을 게시했습니다. Axios에 직접 코드를 삽입하지 않았습니다. 대신 크로스 플랫폼 멀웨어를 배포하는 설치 후크를 실행하는 plain-crypto-js 이라는 팬텀 종속성을 추가했습니다. 명백히 악의적이었습니다.
응답
저는 즉시 Elastic의 인포섹 팀과 연구팀에 연락하여 가동을 시작하도록 했습니다. 매 순간이 중요하다는 것을 알았습니다. 제가 연락했을 때 이미 악성 패키지를 설치한 호스트에 대해 Elastic Defend 경보를 수신하고 적극적으로 대응하고 있는 것으로 밝혀졌습니다. 하지만 그 당시에는 아무도 문제의 규모를 파악하거나 컴퓨터가 어떻게 감염되었는지에 대한 근본 원인을 파악하지 못했습니다. 모니터링 도구는 누락된 컨텍스트를 제공했습니다.
security@npmjs 으로 이메일을 보냈지만 반송을 받았습니다. 보안 포털에 제출하려고 했는데 오류가 발생했습니다. 사람을 만나고 싶다는 절박한 심정으로 트윗을 올렸습니다. 또한 axios 리포지토리 자체의 보안 문제도 신속하게 해결했습니다.
나중에 침해 사고를 목격한 다른 연구원의 트윗을 보고 제가 이 문제를 공급망 사고라기보다는 취약점으로 취급하고 있다는 사실을 깨달았습니다. 취약점이 있으면 조용히 조율합니다. 현재 사람들의 컴퓨터에 멀웨어를 설치하는 공격이 활발하게 일어나고 있는 상황에서, 광범위하고 개방적으로 대응하는 것이 올바른 선택입니다. 그래서 저는 즉시 제가 수집한 모든 세부 정보를 X에 공유했습니다.
심지어 원격 분석을 통해 야생에서 영향을 받은 조직을 보여주는 알림을 받기 시작했습니다. 활발하게 실행 중이었습니다.
다행히도 Axios 팀은 이 문제에 뛰어들어 매우 빠르게 패키지를 가져왔습니다. 또한 공격자의 C2 서버는 너무 많은 요청을 받아 쓰러질 지경이었습니다. 훨씬 더 나쁠 수도 있었습니다.
Elastic 보안 연구소의 우리 팀은 이 침해에 대한 전체 기술 문서를 발표했습니다. 첫 번째는 엔드투엔드 공격 체인, 크로스 플랫폼 멀웨어, C2 프로토콜을 다룹니다: Axios 공급망 침해 내부 - 하나의 RAT가 모든 것을 지배합니다. 두 번째는 Linux, Windows, macOS에서 헌팅 및 탐지 규칙을 다루며, Elastic은 Axios 공급망 침해에 대한 탐지 기능을 출시합니다.
앞으로 나아갈 방향
현재 상황은 좋지 않으며 보안 업계는 물론 전체 소프트웨어 생태계가 더 잘해야 합니다.
3월 2주 동안
- 트리비(보안 스캐너)가 CI/CD 비밀을 훔치기 위해 손상되었습니다.
- 탈취한 비밀을 사용하여 LiteLLM이 손상되었습니다.
- 같은 캠페인에서 Telnyx가 침해당했습니다.
- npm에서 가장 많이 의존하는 패키지 중 하나인 Axios가 북한으로 의심되는 공격자에 의해 손상되었습니다.
- 그 외 여러 가지
패키지 레지스트리는 중요한 인프라입니다. PyPI와 npm을 운영하는 팀은 훌륭한 일을 하고 있지만, 위협은 현재의 신뢰 모델이 처리할 수 있는 수준을 넘어섰습니다. 패키지 변경에 대한 더 나은 자동화된 모니터링이 필요합니다. 서명 스캔뿐만 아니라 코드가 실제로 어떤 기능을 하는지 이해하는 것도 중요합니다. 이 프로젝트에서 알 수 있듯이 LLM은 이 분야에 정말 능숙합니다. 또한 침해가 발생한 후 자격 증명을 더 빨리 교체해야 합니다. 트리비에서 리텔름, 텔닉스로 이어지는 캐스케이드는 도난당한 크레딧이 충분히 빨리 회전되지 않아서 발생했습니다.
지금 당장 할 수 있는 한 가지 실용적인 방법은 패키지 업데이트를 즉시 가져오지 않는 것입니다. 담금 시간을 추가합니다. 새 버전이 빌드에 적용되기 전에 일정 기간 동안 그대로 두세요. 우리는 샤이훌루드에 대응하기 위해 Elastic의 CI/CD 시스템으로 이를 수행합니다. 모든 것을 막지는 못하지만, 커뮤니티가 CI/CD 파이프라인과 개발자 머신을 공격하기 전에 취약점을 발견할 수 있는 시간을 확보할 수 있습니다. 좋은 소식은 많은 패키지 관리자가 이에 대한 기본 지원을 추가했다는 것입니다. 예를 들어 7일 지연을 적용하는 경우입니다:
npm config set min-release-age 7
pnpm config set minimum-release-age 10080
yarn config set npmMinimumReleaseAge 10080
uv --exclude-newer "7 days ago"오픈소스로 제공 중입니다.
공급망 모니터링도구를 출시합니다.
솔직하게 말씀드리고 싶습니다. 개념 증명입니다. 잠도 못 자고 오후에 만들었습니다. 프로덕션 수준에서 이를 실행하는 사람은 없을 것으로 예상합니다. LLM 분석을 위해서는 Cursor 구독이 필요하며, 릴리스를 순차적으로 처리하고, 감시 목록은 정적입니다.
하지만 이 접근 방식은 효과가 있습니다. 실시간으로 패키지 릴리스를 확인하고 AI를 사용하여 변경 사항을 분류하는 과정에서 npm에서 가장 인기 있는 패키지 중 하나에 대한 공급망 공격을 포착했습니다.
커뮤니티가 우리의 경험을 통해 배우는 것이 최선이기 때문에 이 정보를 공유하는 것입니다. 누군가 이 아이디어를 가지고 더 나은 무언가를 만들어낸다면 더할 나위 없이 좋겠죠. 패키지 레지스트리 팀이 이를 파이프라인에 구축하면 더욱 좋습니다. 다음 번에 다른 사람이 큰 세이브를 할 수 있다면 그만한 가치가 있습니다.
작동 방식 (궁금한 분들을 위해)
모니터링: 두 개의 스레드가 PyPI( changelog_since_serial() XML-RPC를 통해)와 npm(CouchDB _changes 피드를 통해)을 폴링합니다. 상위 N개의 관심 목록과 일치하는 새 릴리스가 대기열에 추가됩니다. State는 last_serial.yaml 로 유지되므로 중단된 부분부터 다시 시작합니다.
Diffing: 레지스트리 API에서 직접 다운로드한 이전 버전과 새 버전. pip/npm 설치, 코드 실행이 필요 없습니다. 아카이브 추출, 파일 해시, 마크다운에서 생성된 통합 차이점 보고서.
분석: 차이점 보고서가 읽기 전용 모드에서 커서 에이전트 CLI로 이동합니다. 프롬프트는 공급망 지표를 찾도록 요청합니다. 평결에 대해 구문 분석된 출력입니다.
경고: 악성 평결은 패키지 이름, 순위, 레지스트리 링크 및 분석 요약이 포함된 Slack 메시지를 실행합니다.
보안 분야의 AI, 이 프로젝트를 넘어
공급망 보안은 큰 문제이지만 우리는 무력하지 않습니다. AI는 기계의 속도로 대규모로 방어할 수 있는 새로운 도구를 제공합니다. 이 프로젝트는 보안 문제를 해결하기 위해 AI를 사용한 한 가지 예이지만, 우리는 더 광범위하게 Elastic Security 전반에 걸쳐 AI를 사용한 흥미로운 작업을 많이 해왔습니다. 한 가지 강조하고 싶은 것은 최근 저희 팀이 공격 검색, 워크플로, 에이전트 빌더를 사용하여 APT 수준의 공격을 자동으로 탐지하고 확인하는 방법에 대한 포스팅을 게시했다는 점입니다. 이는 공격이 총체적으로 쏟아지는 시기에 SOC의 효율성과 효과를 의미 있게 개선하기 위해 에이전트 보안을 제공하는 Elastic 플랫폼의 힘을 보여줍니다.
공급망 모니터 프로젝트는 github.com/elastic/supply-chain-monitor에서 확인할 수 있습니다.
신속한 사고 대응을 해준 Elastic Infosec 팀, 신속한 조치를 취해준 axios 유지 관리자들, 폭발 반경을 제한하기 위해 함께 노력해준 보안 커뮤니티에 감사드립니다.