malware-detection

2 개의 포스트

datadog

단일 풀 리퀘스트부터 전체 소프트웨어 패키지까지: 대규모 악성 코드 탐지 (새 탭에서 열림)

BewAIre는 LLM을 활용한 악성 코드 탐지 시스템으로, 기존의 풀 리퀘스트 분석에서 전체 의존성 패키지와 패키지 레지스트리 스캔으로 범위를 확장했다. 저비용 필터 단계와 고성능 에이전트 조사 단계를 결합해 비용과 지연 시간을 줄이면서도 정확도를 97.4%에서 99.86%로 높였고, 오탐을 17건에서 0건으로 낮췄다. 또한 LLM만으로 판단하지 않고 도메인·의존성 검증 같은 정적 검사를 함께 사용해 공급망 공격 탐지의 안정성을 강화했다. ## 풀 리퀘스트 분석만으로는 부족한 이유 - 공격자는 axios, LiteLLM, Mistral 같은 널리 사용되는 의존성 패키지를 침해해 악성 코드를 downstream 사용자에게 확산시킬 수 있다. - 기존 BewAIre는 풀 리퀘스트의 diff를 분석해 침투 테스트, 버그 바운티 활동, 실제 공격을 식별했다. - 그러나 공격 표면은 풀 리퀘스트에 한정되지 않으므로, 전체 패키지와 upstream 레지스트리까지 검사할 필요가 생겼다. - 단순히 더 강력한 추론 모델을 사용하면 정확도는 높아지지만 비용이 증가하고, 대규모 diff는 컨텍스트 윈도우 제한에 부딪힌다. ## 2단계 LLM 평가 구조 - **필터 단계** - 모든 변경 사항을 저렴하고 빠른 모델로 1차 검사한다. - 대규모 diff에는 diff 청크 분할 전략을 적용한다. - 판단은 “의심스러움” 또는 “정상”의 이진 결과다. - 정상으로 판정되면 즉시 종료해 고비용 분석을 피한다. - **조사 단계** - 필터가 의심 신호를 감지한 경우에만 고성능 추론 모델을 호출한다. - 단순히 diff를 읽는 것이 아니라 도구를 사용해 추가 정보를 수집한다. - GitHub API로 커밋 목록, 파일 내용, 기여자 이력, 의존성 메타데이터, 커밋 범위를 조사할 수 있다. - 의심스러운 커밋이 최종 diff에서 사라지도록 되돌려졌는지, 의존성이 typosquatting인지, 작성자의 계정과 소속이 정상적인지 확인한다. - 의존성은 osv.dev와 Datadog SCA 같은 외부 리소스로 검증한다. ## 스택형 LLM 호출이 오탐을 줄인 방식 - 대표 테스트 데이터 690개 diff에서 정확도가 **97.4%에서 99.86%**로 향상됐다. - 오탐은 **17건에서 0건**으로 감소했다. - 대부분의 정상 변경은 필터 단계에서 빠르게 종료되므로 전체 지연 시간도 줄었다. - 의심스러운 변경에 대해서는 더 많은 문맥과 도구를 활용해 정밀한 분석을 수행한다. - 필터 단계와 조사 단계의 역할을 분리함으로써 비용, 속도, 탐지 품질을 동시에 관리했다. ## 에이전트 기반 조사 사례: 파일명에 숨은 명령어 주입 - 공격자는 다음과 같은 형태의 파일명을 사용했다. ```text m$(echo${IFS}...|base64 -d|bash).md ``` - 파일명에 셸 명령 치환을 삽입하고, Base64로 인코딩한 명령을 디코딩해 실행하도록 구성했다. - 실제 페이로드는 외부 서버에서 코드를 내려받아 `bash`로 실행하는 `curl ... | bash` 형태였다. - `${IFS}`를 사용해 공백을 우회하고 보안 필터를 피하려 했다. - 조사 에이전트는 다음과 같은 추가 정황도 확인했다. - 작성자 계정이 생성된 지 7일밖에 되지 않음 - 프로필 정보와 팔로워가 없음 - 리뷰나 승인이 없음 - diff 자체의 악성 명령뿐 아니라 계정 이력과 PR 상태까지 결합해 공격 가능성을 판정했다. ## LLM과 정적 검사의 결합 - 필터 단계는 빠르고 저렴하지만 외부 정보를 직접 탐색하지 못해 일부 공격을 정상으로 판단할 수 있다. - 대표적인 사례가 Datadog과 유사한 도메인을 사용하는 typosquatting 공격이다. - 이를 보완하기 위해 전처리 파이프라인에서 입력에 포함된 모든 도메인을 추출한다. - 정상적인 Datadog 도메인 목록을 바탕으로 생성한 typosquatting 변형 목록과 비교한다. - 이 정적 검사는 LLM에게 의심스러운 Datadog 인접 도메인이라는 명확한 신호를 제공한다. - 비결정적이고 비용이 높은 LLM 판단과 결정적이고 저렴한 정적 검사를 조합해 정확도와 비용 효율을 함께 확보했다. ## 실용적인 결론 대규모 공급망 보안에서는 모든 변경을 고성능 LLM으로 분석하기보다, 저비용 필터와 선택적 심층 조사를 결합하는 방식이 효과적이다. 특히 계정 이력·커밋 상태·도메인·의존성 데이터 같은 외부 문맥과 정적 규칙을 함께 사용해야 LLM의 오탐과 누락을 줄일 수 있다.

gitlab

Contagious Interview IDE 공격을 탐지하고 방지하는 방법 (새 탭에서 열림)

Contagious Interview 캠페인은 가짜 채용 과제로 피해자가 악성 저장소를 VS Code에서 열고, `tasks.json`을 통해 악성 명령을 실행하도록 유도한다. 글은 VS Code 자체보다 운영체제에 가까운 `node-pty`의 `spawn-helper` 실행을 탐지하는 EDR 규칙과, IDE 작업 자동 실행을 비활성화하는 하드닝을 함께 적용해야 한다고 주장한다. 이를 통해 인포스틸러 설치와 기업 네트워크 접근 권한 탈취를 실행 전에 차단할 수 있다. ## Contagious Interview 공격의 진입 방식 - 공격자는 가짜 면접·코드 리뷰를 미끼로 피해자에게 악성 코드 저장소를 다운로드하고 VS Code에서 열도록 유도한다. - 저장소의 `.vscode/tasks.json`에는 프로젝트를 열 때 자동 실행되는 작업이 정의될 수 있다. - VS Code는 해당 저장소를 신뢰하도록 승인해야 작업을 실행하지만, 피해자는 면접 과정이라고 믿어 무심코 신뢰를 부여할 가능성이 높다. - 악성 작업은 `runOn: "folderOpen"`을 사용해 폴더를 열 때 자동 실행되며, 화면에 거의 표시되지 않도록 설정할 수 있다. - 예시 명령은 운영체제별로 다음 단계 악성코드를 내려받아 실행한다. - macOS: `curl ... | bash` - Linux: `wget ... | sh` - Windows: `curl ... | cmd` - 이후 인포스틸러가 비밀번호와 암호화폐 정보를 탈취하고, 지속성을 확보해 피해자의 기업 네트워크 접근 권한을 악용할 수 있다. ## IDE보다 낮은 계층을 겨냥한 탐지 - 특정 VS Code 기능만 탐지하면 VS Code 포크나 유사한 Node/Electron 기반 IDE를 우회 경로로 사용할 수 있다. - GitLab은 운영체제에 더 가까운 프로세스 생성 계층을 조사했다. - VS Code는 하위 프로세스를 실행할 때 널리 사용되는 `node-pty` 라이브러리를 활용한다. - `node-pty.spawn()` 호출은 자체 바이너리인 `spawn-helper`를 실행하며, 이 프로세스는 Node 애플리케이션의 자식 프로세스로 생성된다. - `node-pty`는 주당 다운로드 수가 100만 회 이상인 널리 사용되는 라이브러리이므로, 이 계층을 이용하면 특정 IDE에 종속되지 않는 탐지가 가능하다. ## 백그라운드 실행과 사용자 실행의 구분 - GitLab은 Purple Team 훈련으로 공격 경로를 재현한 뒤 EDR 텔레메트리를 분석했다. - VS Code에서 백그라운드 작업을 실행할 때는 주로 `spawn-helper`가 호출된다. - 사용자가 통합 터미널을 열거나 직접 프로세스를 실행하는 등 전면적인 상호작용이 있을 때는 `Code Helper` 바이너리가 사용된다. - 따라서 `spawn-helper`를 기반으로 탐지하면 사용자가 인지하지 못한 상태에서 실행되는 IDE 작업에 집중할 수 있다. - 일반적인 개발 활동에서 발생하는 의도적 프로세스 실행을 제외해 오탐을 줄일 수 있다. ## `curl | shell` 패턴과 행위 기반 튜닝 - `curl | bash`는 Homebrew 설치처럼 정상적인 용도로도 사용될 수 있으므로 단순 문자열 탐지는 오탐 가능성이 있다. - 하지만 사용자가 인지하지 못하는 백그라운드 작업에서 해당 명령이 실행되는 것은 조직 환경에서 비정상적일 수 있다. - GitLab은 다음과 같은 조건을 결합해 탐지 규칙을 조정했다. - 부모 프로세스가 IDE의 `spawn-helper`인지 - 작업이 백그라운드에서 실행됐는지 - 외부 URL에서 데이터를 내려받는지 - 다운로드한 내용을 셸로 직접 파이프하는지 - 이 방식은 모든 백그라운드 작업을 차단하지 않고, 드물고 위험한 실행 조합만 경고하도록 설계됐다. - 조직 내 많은 개발자가 매일 VS Code를 사용했음에도 구현 후 오탐이 발생하지 않았다고 설명한다. ## 다층 방어와 IDE 설정 강화 - EDR을 이용한 런타임 탐지는 악성 작업이 실제로 실행되는 순간을 포착하는 방어선이다. - 동시에 조직 전체 설정을 배포해 VS Code의 작업 자동 실행 자체를 비활성화하면 공격 표면을 줄일 수 있다. - 특히 저장소를 열 때 자동으로 실행되는 작업을 제한하면 `runOn: "folderOpen"` 기반 공격을 예방하는 데 효과적이다. - VS Code뿐 아니라 동일한 Node 기반 구조와 백그라운드 작업 기능을 가진 IDE 포크에도 같은 원칙을 적용해야 한다. 실무적으로는 IDE 작업 자동 실행을 기본 비활성화하고, EDR에서 `spawn-helper`의 백그라운드 프로세스 생성과 `curl/wget | shell` 패턴을 함께 모니터링하는 방식을 권장한다. Gmail·채용 플랫폼 등 초기 유입 경로에 대한 보안 교육과 저장소 신뢰 승인 절차도 병행해야 한다.