2026년 7월, 보안 매체 Bleeping Computer는 7,600개 이상의 GitHub 리포지토리를 악용해 SmartLoader 및 StealC 악성코드를 유포한 FakeGit 캠페인을 상세히 공개했다. 신뢰받는 코드 호스팅 플랫폼을 무기로 활용한 이번 사건은 개발자 단말과 기업 빌드 파이프라인 모두를 위협하는 대규모 공급망 공격이라는 점에서 업계의 이목을 집중시키고 있다. 본문은 캠페인의 구조, 위장 기법, 기술적 침투 흐름, 그리고 기업과 개발자가 즉시 도입해야 할 대응책까지 한 번에 정리한다.
핵심 요약
- FakeGit 캠페인은 7,600개 이상의 GitHub 리포지토리를 통해 SmartLoader와 StealC를 유포하며 누적 다운로드 1,400만 회를 돌파했다.
- 공격자는 그중 약 800개 이상의 리포지토리를 AI 스킬, MCP 서버 등 트렌디한 정상 프로젝트로 위장해 탐지를 회피했다.
- 본 사건은 개발자 PC, CI/CD 파이프라인, 다운스트림 사용 기업까지 오염이 연쇄될 수 있는 전형적인 소프트웨어 공급망 위협으로 평가된다.
신뢰받는 코드 플랫폼이 악성코드 인프라로 둔갑한 사례로, GitHub·기업·개발자 각자가 공급망 보안의 책임 지점임을 보여준다.
FakeGit 캠페인 개요: GitHub를 노린 대규모 악성코드 유포 사건
캠페인 규모와 누적 영향: 7,600개 리포, 1,400만 회 다운로드
FakeGit 캠페인은 GitHub라는 익숙한 협업 공간을 실질적 악성코드 배포망으로 전환한 사례로 기록된다. Bleeping Computer는 7,600개 이상의 악성 GitHub 리포지토리가 식별되었고, 누적 다운로드 수가 1,400만 회를 넘어섰다고 보도했다. 단일 위협 행위자가 이 규모의 인프라를 장기간 유지했다는 점에서, 단순히 일회성 스팸이 아니라 상시 운영형 공급망 공격으로 해석된다.
특히 다운로드 수치는 표면적인 조회수가 아니라 실행까지 이어진 실제 유포량을 의미한다는 점에서 심각하다. 사용자가 리포지토리를 발견해 클론(clone) 또는 패키지 설치 형태로 가져간 경우까지 포함된 수치로, 실제 감염 단말은 그보다 적을 수 있더라도 잠재적 노출 범위는 매우 넓다.
주요 악성코드 SmartLoader와 StealC의 역할 분담
이번 캠페인은 단일 악성코드가 아니라 2단계 구조로 설계된 점이 특징이다. 먼저 사용자에게 노출되는 것은 SmartLoader로, 최소한의 코드만 포함해 탐지 회피와 빠른 실행을 노리는 로더형 페이로드다. SmartLoader는 감염 단말에서 안정적인 통신 채널을 확보한 뒤, 본 격적인 정보 탈취용 StealC 인포스틸러를 다운로드해 실행하는 2차 페이로드를 호출하는 것으로 분석되었다.
SmartLoader가 침투와 우회를, StealC가 데이터 탈취를 담당하는 이 구조는 랜섬웨어 진영에서도 자주 보이는 모듈러(modular) 전략과 유사하다. 행위자는 초기 침투 도구와 수익화 도구를 분리해 한쪽이 차단되어도 다른 쪽이 살아남도록 설계한 것으로 판단된다.
공격 메커니즘: 7,600개 리포지토리는 어떻게 위장되었나
AI 스킬·MCP 서버로 둔갑한 800개 이상의 핵심 노드
공격의 핵심은 리포지토리 수 자체보다 위장의 정교함에 있다. 팩트에 따르면 800개 이상의 리포지토리가 AI 스킬 또는 MCP(Model Context Protocol) 서버를 사칭하며, 마치 신생 오픈소스 프로젝트처럼 꾸몄다. 2024~2026년 사이 AI 에이전트와 MCP 서버는 개발자 사이에서 가장 뜨거운 키워드였기 때문에, 단순한 검색만으로 사용자가 접근할 확률이 매우 높았다.
문제는 이러한 위장 리포지토리가 정상 검색 결과 위로 자연스럽게 노출된다는 점이다. GitHub의 추천 알고리즘과 스타, 포크 등의 사회적 신호(social signal)를 인위적으로 부풀려 신뢰도를 확보한 것으로 보인다. 결과적으로 일반 개발자는 외형만으로 악성 여부를 판별하기가 사실상 불가능한 환경이 만들어졌다.
정상 프로젝트로 보이게 만든 명명·문서화 전략
위장 리포지토리들은 단순히 이름만 빌려온 것이 아니다. README.md, 라이선스, 이슈 트래커, 릴리스 노트까지 실제 정상 프로젝트와 구분이 어려운 수준의 문서화가 동반되었다. 일부 리포지토리는 합법적인 오픈소스 코드를 일부 포함해 정적 분석을 우회한 것으로 추정된다.
| 위장 요소 | 설명 | 우회 목적 |
|---|---|---|
| AI 스킬/MCP 서버 명명 | 트렌드 키워드를 리포지토리명에 사용 | 개발자 검색 결과 상위 노출 |
| README 및 문서 세트 | 정상 프로젝트 수준의 사용법·라이선스 제공 | 육안 점검 및 1차 신뢰 확보 |
| 유효 코드 혼합 | 실제 동작 가능한 정상 코드를 일부 포함 | 정적 분석 및 코드 리뷰 우회 |
| 사회적 신호 조작 | 스타, 포크, 워처 인위적 증가 | GitHub 추천 알고리즘 노출 확보 |
이러한 명명·문서화 전략은 결국 단일 위협이 아니라 체계적인 위장 캠페인이라는 인상을 강화한다. 단순한 코드 배포가 아니라 검색 엔진 최적화(SEO)와 개발자 행동 패턴을 동시에 공략한 점에서, FakeGit은 공급망 공격의 새로운 기준으로 자리 잡을 가능성이 높다.
기술적 분석: SmartLoader 감염 흐름과 StealC 연계 가능성
초기 침투부터 추가 페이로드 다운로드까지
SmartLoader는 일반적으로 실행 가능한 스크립트 또는 경량 바이너리 형태로 배포된다. GitHub 리포지토리에서 사용자가 클론 후 빌드 또는 설치 명령을 실행하면 SmartLoader가 동작해 외부 C2(Command and Control) 서버와 통신한다. 이후 추가 페이로드를 다운로드해 메모리 내(in-memory)에서 실행하거나 임시 폴더에 드롭하는 흐름이 확인된 것으로 보인다.
이 과정에서 인코딩, 난독화, 난수화 변수명 등이 적극 활용된 것으로 분석된다. 이는 시그니처 기반 안티바이러스 탐지를 우회하기 어렵게 만들기 위한 조치이며, 동시에 보안 연구자가 샘플을 분석할 때도 추가 시간을 소모하게 만든다.
인포스틸러 StealC와 결합된 정보 탈취 시나리오
StealC는 이미 여러 공급망 공격에서 등장한 검증된 인포스틸러 계열이다. 브라우저 저장 자격증명, 쿠키, 암호화폐 지갑 정보, 시스템 환경 정보 등을 수집해 외부로 유출하는 기능을 갖는다. FakeGit 캠페인에서는 SmartLoader가 만든 초기 거점을 활용해 StealC를 호출하고, 이 조합이 최종 데이터 유출까지 이어지는 1차 수익화 루프를 형성한 것으로 판단된다.
랜섬웨어 가용화(ransomware-as-a-service) 확산 흐름과 맞물려, StealC로 확보한 접근 권한이 이후 랜섬웨어 침투의 사전 정찰 단계로 활용될 가능성도 제기된다. Dark Reading의 최근 보도에 따르면 랜섬웨어는 AI 자체보다 접근 권한 거래 시장 활성화로 인해 가속화한다는 분석이 제기된 바 있으며, FakeGit이 만들어낸 감염 단말 풀은 이러한 2차 거래의 공급원이 될 수 있다.
공급망 위협 확대: 개발자 PC와 CI/CD 파이프라인을 노린다
개발자 단말 감염과 빌드 파이프라인 오염 리스크
개발자 PC가 감염되면 단순 개인정보 유출에 그치지 않는다. 해당 단말에서 운영하는 사내 패키지 캐시, 사설 라이브러리 미러, 컨테이너 레지스트리, CI/CD 빌드 스크립트 등이 모두 오염 후보가 된다. 한 번 빌드 파이프라인에 악성 코드가 끼어들면, 이후 산출되는 산출물(아티팩트) 자체가 악성으로 변질될 수 있다.
특히 빌드 캐시와 의존성 잠금(lock) 파일은 변경 이력이 추적되더라도, 정상 의존성 업데이트로 둔갑해 쉽게 식별되지 않는다. 결과적으로 감염된 패키지가 그대로 배포 채널을 타고 다운스트림 사용자·기업으로 전파되는 2차 파급효과가 우려된다.
다운스트림 사용 기업으로 확산되는 2차 피해 시나리오
공급망 공격의 무서움은 피해 범위가 기하급수적으로 커진다는 점이다. 한 명의 개발자가 감염된 라이브러리를 사내 표준으로 채택하면, 이를 사용하는 모든 제품과 서비스가 동시에 위협받는다. 가용성 침해뿐 아니라, 기업 고객의 데이터 유출로까지 이어질 수 있어 신뢰 회복 비용이 천문학적으로 치솟는다.
특히 클라우드 네이티브 환경에서는 컨테이너 이미지와 내부 패키지 레지스트리가 핵심 유통 경로이므로, 이미지 서명, SBOM(Software Bill of Materials), 의존성 검증 절차가 갖춰져 있지 않은 조직일수록 피해가 집중될 가능성이 높다.
대응 가이드: GitHub·기업·개발자가 동시에 잡아야 할 지점
플랫폼 차원의 악성 리포지토리 탐지와 정책 강화
GitHub 측에서는 신규 리포지토리의 생성 패턴, 외부 다운로드 추적, 사용자 신고와의 연계를 보다 적극적으로 강화할 필요가 있다. 단순히 사후 삭제만으로는 1,400만 회라는 누적 다운로드 수치를 만회할 수 없다. 사전에 의심 패턴을 탐지하고, 자동 스캔을 의무화하며, 의심스러운 다운로드 경로에는 경고 배너를 표시하는 정책적 조치가 요구된다.
또한 커뮤니티 신고와 보안 연구자 파트너십 프로그램을 확대해, FakeGit처럼 정교한 위장 캠페인을 조기에 식별하는 생태계를 만들어야 한다. 플랫폼 신뢰는 무료로 주어지는 것이 아니라 운영 정책의 결과물이라는 인식을 공식화할 필요가 있다.
기업과 개발자가 즉시 적용 가능한 점검 체크리스트
- 출처 불명확한 리포지토리는 클론 전에 작성자 이력, 커밋 패턴, 외부 평판을 반드시 교차 검증한다.
- 의존성 설치 후 빌드 스크립트가 외부 네트워크에 통신을 시도하는지 네트워크 모니터링 도구로 확인한다.
- 사내 표준 라이브러리 목록(allowlist)을 운영해 임의 GitHub 리포지토리의 직접 차용을 통제한다.
- SBOM을 발급하고 의존성 트리에 대한 정기 감사 및 디지털 서명 검증을 자동화한다.
- 개발자 PC에 EDR과 애플리케이션 허용 목록을 적용해 SmartLoader류의 비인가 실행을 차단한다.
- CI/CD 파이프라인에서 빌드 산출물에 대한 무결성 검증과 배포 단계 서명 체계를 도입한다.
기업과 개발자가 동시에 점검 항목을 운영할 때, 단일 침투 지점이 전체 공급망으로 확산될 가능성을 가장 효과적으로 낮출 수 있다.
결론: 신뢰 가능한 코드 플랫폼의 조건을 다시 세우다
FakeGit 캠페인은 GitHub라는 단일 플랫폼을 둘러싼 책임을 다시 묻고 있다. 플랫폼 제공자는 탐지와 정책 강화 책임을, 기업은 의존성 관리와 빌드 파이프라인 통제 책임을, 개발자는 일상적인 코드 차용 습관에 대한 책임을 져야 한다. 어느 한쪽이 빠지더라도 7,600개 리포지토리, 1,400만 회 다운로드 규모와 같은 위협은 다시 발생할 가능성이 높다.
공급망 보안의 본질은 기술 도구의 나열이 아니라, 신뢰의 사슬(chain of trust)을 누가 끊지 않고 유지할 것인가에 대한 합의다. 이번 사건은 그 합의의 비용을 명확히 보여주었으며, 플랫폼·기업·개발자 모두에게 행동 변화의 기준선을 제시한 것으로 평가된다.
핵심 포인트 정리
- FakeGit은 7,600개 리포, 1,400만 회 다운로드를 기록한 GitHub 기반 대규모 공급망 공격이다.
- 800개 이상의 리포가 AI 스킬·MCP 서버 등 정상 프로젝트로 위장되어 탐지를 우회했다.
- SmartLoader(침투/우회)와 StealC(정보 탈취)의 2단계 모듈러 구조로 수익화 루프를 형성했다.
- 개발자 PC와 CI/CD 파이프라인 감염은 다운스트림 기업까지 2차 피해를 확산시키는 핵심 경로다.
- 플랫폼 정책 강화, 의존성 통제, 빌드 산출물 검증 등 다층적 대응이 동시에 필요하다.
참고 자료: Bleeping Computer – FakeGit campaign uses 7,600 GitHub repos to push SmartLoader malware, Dark Reading – Ransomware Is Accelerating, But It’s Not Because of AI