샤이-훌루드 2 사건의 여파와 다르게 할 수 있는 일

Shai-Hulud 2.0 npm 웜은 AppSec 팀이 수년간 사후 분석에서 참조하게 될 사건 중 하나입니다.

무슨 일이 일어났는지, 누가 영향을 받았는지, SSCS 플랫폼이 어떻게 영향을 미쳤는지 분석해 보겠습니다. 스크라이브허브 조직이 폭발 반경을 막거나 적어도 대폭 제한하는 데 도움이 될 수 있었습니다.

1. Shai-Hulud 2.0이란 무엇인가요?

Shai-Hulud는 2025년 9월에 처음 등장했습니다. npm 생태계를 표적으로 삼는 자체 복제 웜수백 개의 JavaScript 패키지를 손상시키고 도난당한 자격 증명과 자동 재발행을 통해 확산되었습니다. 

불과 몇 달 후, 연구자들은 다음과 같은 사실을 알게 되었습니다. 훨씬 더 공격적이고 자동화된 후속 조치, 지금은 일반적으로 ~로 불립니다. “샤이-훌루드 2.0”, “샤1-훌루드 2.0” 또는 “재림.” 

Shai-Hulud 2.0의 주요 특징:

• 공급망에 초점을 맞추다. 한 회사를 공격하는 대신, 신뢰할 수 있는 npm 패키지 그리고 이후의 변형에서는 수천 개의 프로젝트에서 사용되는 구성 요소를 오염시키는 Java 생태계(Maven)까지 등장했습니다.
• 자기 증식하는 벌레. 유지 관리자가 손상되면 자동으로 백도어가 발생합니다. 모든 해당 유지 관리자의 패키지를 다시 게시하여 종속성 그래프 전반에 걸쳐 기하급수적으로 확산되도록 합니다.
• 비밀을 훔치는 정보 도둑. 페이로드는 개발자 머신과 빌드 파이프라인에서 환경 변수, GitHub 및 npm 토큰, 클라우드 자격 증명, CI/CD 비밀을 적극적으로 수집합니다. 
• 파괴적인 "데드맨 스위치" 맬웨어가 C2에 도달하지 못하거나 확산에 실패하면 일부 변종은 사용자의 홈 디렉토리를 삭제하려고 시도하여 공급망 침해를 잠재적으로 파괴적인 사건으로 전환합니다.

2. 공격 작동 방식 – 단계별

공급업체마다 약간씩 다른 툴과 스크립트를 사용했지만, 전체적인 킬 체인은 대략 다음과 같습니다.

2.1 초기 발판: 손상된 유지 관리자 계정

공격자 :

1. 손상된 npm / GitHub 유지 관리자 계정 이전에 도난당한 토큰을 사용하거나, 피싱, 비밀번호 재사용 또는 취약한 MFA를 사용하는 경우.
2. 해당 계정을 사용하여 게시했습니다. 합법적인 패키지의 트로이 목마 버전 – 패치 수준 버전만 적용되어 일반적인 업데이트 패턴에 맞춰 적용되었습니다.

해당 패키지는 합법적인 유지 관리자가 서명/게시했기 때문에 하위 소비자에게 신뢰할 수 있는 것으로 보였습니다.

2.2 npm install / CI 파이프라인을 통한 감염

조직에서는 다음 패키지를 꺼냈습니다.

• 정상을 통해 npm 설치 로컬 개발에서
• 또는 간접적으로 CI / CD 파이프 라인 자동화된 빌드의 일부로.

일반적으로 활용되는 악성 패키지 npm 라이프사이클 스크립트 (사전 설치, 설치, 설치 후) 실행 벡터로서 2단계 페이로드를 다운로드하고 실행합니다. 번들.js, setup_bun.js또는 이와 유사한 대용량 난독화된 파일. 

2.3 자격 증명 도용 및 환경 정찰

실행되면 페이로드는 다음과 같습니다.

• 열거된 환경 변수와 로컬 구성 파일.
• 수확 클라우드 자격 증명, GitHub/GitLab 토큰, npm 액세스 토큰, SSH 키 및 기타 비밀.
• 가끔씩 사용되는 도구 TruffleHog 스타일 스캐닝 비밀을 찾기 위해 저장소를 검색합니다.

이러한 자격 증명은 다음과 같습니다. 공격자가 제어하는 ​​GitHub 저장소로 유출됨 또는 종종 섞이도록 이름이 지정된 다른 C2 인프라(예: 도난당한 환경 덤프로 채워진 "Shai-Hulud" 저장소). 

2.4 개발자 생태계 전반의 측면 이동

도난당한 토큰을 사용하여 맬웨어는 다음을 수행합니다.

• 모든 npm 패키지를 백도어로 처리했습니다. 손상된 유지 관리자가 소유하고 동일한 악성 스크립트를 주입하여 다시 게시합니다.
• 심은 악성 GitHub Actions 워크플로 CI 실행 중에도 지속성과 지속적인 유출을 위해 피해자 저장소에 백도어를 설치합니다.
• 일부 2.0 변형에서는 npm을 넘어 확장되었습니다. Maven 저장소진정한 교차 생태계 공급망 도달 범위를 보여줍니다. 

많은 인기 있는 라이브러리가 종속성 트리에서 높은 위치에 있기 때문에 유지 관리자 몇 명만으로 타협하면 다음과 같은 결과가 발생합니다. 수만 개의 영향을 받은 저장소 하류.

3. 규모와 피해자에게 미치는 영향

보안 공급업체마다 약간씩 다른 수치를 보고하지만 모두 한 가지에 대해서는 동의합니다. 샤이-훌루드 2.0은 거대합니다.

• 보안 연구원들은 다음과 같이 추정합니다. 25,000개 이상의 GitHub 저장소 및 수백 개에서 ~700개까지의 패키지 이후 파도에 영향을 받았으며 그 중 일부는 다음과 같습니다. 클라우드/코드 환경의 4분의 1 이상 그들은 스캔했다.
• 분석가들은 그것을 이렇게 부른다 지금까지 본 것 중 가장 빠르게 확산된 npm 공급망 공격 중 하나자동화로 인해 손상됨 단 몇 시간 만에 수백 개의 패키지를 배송합니다.
• 유명 피해자에는 프로젝트와 패키지가 포함되었습니다. Zapier, ENS 도메인, PostHog, Postman, 그리고 다른 것들도 있습니다. 즉, SaaS 공급업체와 수천 명의 고객 모두가 잠재적으로 노출될 수 있다는 뜻입니다.

3.1 직접적인 기술적 영향

트로이 목마 패키지를 추출한 조직의 경우 일반적인 결과는 다음과 같습니다.

• CI/CD 비밀 노출 (클라우드 공급자 키, 배포 토큰, 코드 서명 인증서 등).
• 은밀한 백도어 GitHub 저장소와 CI 작업에서 공격자가 향후 빌드에서 임의의 명령을 실행할 수 있습니다.
• 변조된 유물: 공격자가 개발자가 알아차리지 못하는 사이에 악성 논리를 내장된 애플리케이션에 삽입할 가능성이 있습니다.
• 불운한 개발자 중 일부는 파괴적인 닦아내기 $ HOME 예배 규칙서 악성코드의 대체 수단이 작동했을 때.

3.2 비즈니스 영향

사업 관점에서 보면 이는 다음과 같습니다.

• 대규모 사고 대응 이벤트: IR 팀은 영향을 받은 패키지를 사용하여 모든 프로젝트를 감사하고, 토큰을 순환시키고, 때로는 배포를 동결해야 했습니다.
• 규제 및 계약 노출: 규제 산업(금융, 의료, 정부 공급업체)은 이제 제3자 패키지를 통해 규제 데이터나 중요 시스템 액세스 키가 유출될 가능성에 직면해 있습니다.
• 오픈 소스의 신뢰 침식: 보안 및 엔지니어링 리더들은 공개 레지스트리에 대한 신뢰 모델을 재검토하고 종속성 관리에 대한 더 엄격한 통제를 고려해야 합니다.

4. 기존 방어수단이 어려움을 겪는 곳

샤이-훌루드 2.0이 왜 그렇게 많은 방어선을 돌파했을까?

1. 그것은 단순한 취약성이 아니라 신뢰를 남용한 것입니다. 패키지는 "합법적"이었습니다. 실제 관리자 이름으로 게시되었으며, 종종 기존 저장소에서 배포되었습니다.
2. 정적 SCA/SAST만으로는 충분하지 않았습니다. 팀에 SBOM과 취약성 스캐너가 있더라도 많은 팀이 이를 찾지 않았습니다. 행동 적 의심스러운 라이프사이클 스크립트나 빌드 중의 아웃바운드 유출과 같은 지표.
3. 진짜 목표는 비밀과 CI/CD였습니다. 많은 조직에서는 CI/CD 환경에 대한 제어 및 모니터링이 프로덕션 환경보다 약하기 때문에 완벽한 타겟이 됩니다.
4. 종단 간 출처가 부족합니다. 대부분의 팀은 쉽게 대답할 수 없었습니다. "어떤 빌드, 아티팩트, 배포에 트로이 목마 패키지가 포함되었고, 어떤 것이 안전한가요?"

이것이 바로 그 격차입니다. 소프트웨어 공급망 보안(SSCS) 같은 플랫폼 스크라이브허브 해결하기 위해 설계되었습니다.

 

5. ScribeHub SSCS가 Shai-Hulud 스타일 공격을 예방하고 완화하는 데 어떻게 도움이 될 수 있습니까?

Shai-Hulud 2.0의 기술을 일반적으로 Scribe Security의 ScribeHub 플랫폼과 관련 툴(예: Valint 정책 코드)로 구현하는 기능에 매핑하겠습니다.

5.1 종속성 수집에 대한 가드레일

Shai-Hulud 2.0의 문제:
조직은 업데이트된 npm 패키지를 자동으로 사용했습니다( ^/~ 버전 범위, Renovate/Dependabot 또는 CI 스크립트)에 대한 동작 검토가 거의 없습니다.

ScribeHub를 사용하면:

• 정책 기반 종속성 제어. Valint 정책을 사용하여 "신뢰할 수 있는" 레지스트리와 범위를 제한하고, 중요 패키지에 대한 허용 목록을 적용하고, 다음과 같은 경우 알림을 보냅니다.
  • 새로운 유지 관리자가 버전을 게시합니다.
  • 예상치 못한 라이프사이클 스크립트가 나타납니다.
  • 또는 패키지가 갑자기 새로운 네트워크/실행 동작을 얻게 됩니다.
• 타사 구성 요소에 대한 증명. ScribeHub는 수집하고 검증할 수 있습니다. 출처 및 빌드 증명 사용 가능한 패키지의 경우(예: SLSA 스타일 메타데이터, Sigstore, in-toto) 다음과 같은 규칙을 활성화합니다. "신뢰할 수 있는 빌드 출처의 종속성만 사용합니다."

이것은 npm 생태계를 마술처럼 고치지는 않지만 상당히 기준을 높인다 새로운 버전이 빌드에 허용되기 전에.

5.2 CI/CD 파이프라인을 "일류 자산"으로 강화

Shai-Hulud의 주요 가치는 착취에서 나왔습니다. 개발자용 노트북과 CI/CD 노드를 비밀 금고로 활용합니다.

ScribeHub 사용:

• 모든 실행에 대한 파이프라인 증명.
  각 CI 작업은 다음을 설명하는 서명된 증명을 생성합니다.
  • 어떤 저장소와 브랜치가 빌드되었는지,
  • 어떤 종속성과 컨테이너 이미지가 사용되었는지,
  • 실행된 스크립트(라이프사이클 후크 포함)
  • 그리고 어떤 비밀이 유출되었는지.
• 해당 데이터가 입력됩니다 ScribeHub의 증거 호수"누가, 어디서, 어떤 입력으로 무엇을 만들었는지"에 대한 변조 방지 기록을 제공합니다.
• 정책 코드 런타임 검사.
  빌드 아티팩트를 스테이징/프로덕션으로 승격시키기 전에 정책 엔진은 다음을 검증합니다.
  • 승인된 npm 레지스트리만 사용됨
  • 금지된 라이프사이클 스크립트가 없습니다(컬 | 배시, 난독화된 번들.js등)이 실행됩니다.
  • 러너가 루트로 실행되지 않았고 민감한 호스트 경로를 마운트하지 않았습니다.

Shai-Hulud가 추가적으로 주입하면 설치 후 비밀을 빼내는 스크립트, 실행 정책에 실패하다 그리고 결코 생산에 이르지 못했습니다.

5.3 신속한 폭발 반경 분석

이와 같은 캠페인에서 가장 어려운 작업 중 하나는 다음 질문에 답하는 것입니다.

"우리는 패키지 X의 트로이 목마 버전을 정확히 어디에서 사용했고, 그들은 무엇을 건드렸나요?"

ScribeHub를 사용하면:

• 모든 빌드, 배포 및 아티팩트는 다음과 연관됩니다. 암호학적으로 연결된 증명: 종속성, 환경 세부 정보, 커밋 SHA, 컨테이너 다이제스트 등
• 새로운 권고사항에서 "버전 4.8.1~4.8.5"라고 언급하는 경우 일부 라이브러리 Shai-Hulud 2.0의 일부입니다." ScribeHub에 문의하세요.
  
  
  "지난 90일 동안 해당 버전을 포함한 모든 빌드와 해당 빌드에서 생성된 배포 또는 이미지를 보여주세요."
  
• 그런 다음 수 타겟 비밀 회전 그리고 모든 것을 맹목적으로 바꾸는 것보다(운영상 비현실적일 수 있음) 중요한 부분에서만 정확하게 수정하는 것이 좋습니다.

즉, ScribeHub는 생태계 전체의 공황을 다음과 같이 전환합니다. 제한적이고 감사 가능한 사건.

5.4 귀하의 보호 자신의 무기화되는 패키지

많은 조직은 오픈 소스를 소비할 뿐만 아니라 게시 고객, 파트너 또는 내부 팀에서 사용하는 패키지. 조직의 유지 관리자 계정이 침해당하면 Shai-Hulud 유지 관리자처럼 의도치 않게 악성 코드 확산 경로가 될 수 있습니다.

ScribeHub는 다음과 같은 방법으로 도움을 드릴 수 있습니다.

• CI에서 서명된 증명을 요구합니다. 패키지를 npm이나 내부 레지스트리에 게시하기 전에:
  • 예상되는 증명이 포함되지 않은 패키지 버전은 거부되거나 플래그가 지정됩니다.
• 자체 레지스트리와 저장소에 대한 지속적인 모니터링:
  • 알 수 없는 빌드 환경이나 승인된 CI 파이프라인 외부에서 패키지가 게시되면 알림을 받습니다.
  • 마지막 "신뢰할 수 있는" 릴리스에 없었던 새로운 GitHub Actions 또는 npm 스크립트가 감지되었습니다.

이것은 그것을 만든다 도난당한 토큰을 가진 공격자에게는 훨씬 더 어렵습니다. 악의적인 버전을 네임스페이스에 조용히 밀어넣는 것입니다.

5.5 규제 기관, 고객 및 내부 이해 관계자를 위한 증거

Shai-Hulud 2.0과 같은 사건은 특히 다음과 같은 프레임워크와 일치하는 부문에서 규제 기관과 대규모 고객에 의해 점점 더 면밀히 조사되고 있습니다. NIST SSDF, PCI DSS 4또는 정부 소프트웨어 인증 요구 사항.

ScribeHub는 다음을 유지합니다. SDLC 활동에 대한 타임스탬프가 찍힌 서명된 기록당신이 할 수 :

• 트로이 목마에 감염된 종속성의 영향을 받지 않은 빌드와 릴리스를 보여줍니다.
• 감사인에게 다음에 대한 구체적인 증거를 제공하십시오.
  • 종속성 정책,
  • CI에서 최소 권한 적용
  • 그리고 사건 이후의 비밀 로테이션 타임라인.

이를 통해 대화가 "우리는 괜찮다고 생각합니다"에서 "여기에 우리 소프트웨어에 대한 입증된 소유권 체계가 있습니다"로 바뀌게 됩니다.

6. 보안 리더를 위한 실용적인 정보

이 모든 것을 종합해 보면, Shai-Hulud 2.0과 ScribeHub와 같은 플랫폼이 수행할 수 있는 역할을 요약할 수 있습니다.

1. 생태계가 손상되었다고 가정해 보자. 공개 레지스트리는 단일 실패 지점으로 사용하기에 너무 매력적입니다. 보안 모델은 그렇지 않다는 것이 입증될 때까지 외부 종속성을 신뢰할 수 없는 것으로 처리해야 합니다.
2. "스캔하고 기도하기"에서 "증명하고 시행하기"로 업그레이드하세요. 클래식 SCA와 린팅은 여전히 ​​중요하지만 Shai-Hulud 2.0은 다음 사항도 필요하다는 것을 보여줍니다.
   • 강력한 출처,
   • 검증된 빌드,
   • 그리고 정책에 따라 유물을 홍보합니다.
3. CI/CD를 프로덕션처럼 취급하세요. 웜은 보안과 파이프라인을 노렸는데, 이는 강화된 런타임 환경보다 공격 대상이 덜 취약하기 때문입니다.
4. 추적성에 투자하세요. 다음에 생태계 전체에 영향을 미칠 위협이 발생하면(실제로 발생할 것입니다) 몇 주가 아닌 몇 시간 안에 "이 문제가 우리에게 어떤 영향을 미쳤는가?"라는 질문에 답할 수 있는 능력에 따라 통제된 사고와 본격적인 위기가 갈릴 것입니다.

ScribeHub SSCS는 npm이나 오픈 소스를 마법처럼 안전하게 만들어주지는 않지만, 훨씬 덜 혼란스럽게 Shai-Hulud 스타일의 공격을 견뎌낼 수 있는 가시성, 제어 및 증거 기반 백본을 제공합니다.

SDLC를 지속적인 서명 증명, 증거 기반 정책, 강력한 CI/CD 위생을 기반으로 설계한다면 역사상 가장 큰 npm 공급망 공격이 발생할 경우, 이는 비즈니스에 대한 실존적 위협이 아니라 처리해야 할 또 다른 사건이 됩니다.