위조 GitHub 저장소 위험 대응 가이드: 개발 환경 검증·탐지·복구 점검 포인트

서론

개발자는 검색 결과, README, 별표 수, 익숙한 프로젝트 이름을 단서로 도구를 선택하는 경우가 많다. 이 신뢰 경로를 악용하면 정상 프로젝트를 모방한 저장소나 외부 배포 파일로 사용자의 실행을 유도할 수 있다. 다만 현재 확인 가능한 캠페인 관련 자료는 단일 Medium 게시물이며, 원문에서 재현 가능한 저장소 URL·파일 해시·도메인·C2 같은 IOC를 제공하지 않는다. 따라서 이 글은 특정 캠페인의 규모나 악성코드 귀속을 사실로 단정하지 않고, 위조 저장소와 외부 배포 파일에 공통으로 적용할 수 있는 검증·대응 절차를 정리한다.

본론

확인 가능한 범위와 출처 한계

단일 게시물은 위조 GitHub 저장소를 통한 악성 파일 유포 가능성을 설명하지만, 별도의 GitHub 공지나 보안 벤더·분석기관의 원문 보고서로 독립 검증되지는 않았다. 이에 따라 게시물에 언급된 저장소 수, AI/MCP 관련 수치, 특정 로더 또는 정보탈취 악성코드 연결은 이 글의 판단 근거로 사용하지 않는다.

MITRE ATT&CK는 사칭(T1036), 사용자의 악성 파일 실행(T1204.002), 외부 도구 전송(T1105)을 일반적인 공격 기법으로 정의한다. 이는 특정 위조 저장소 사례의 귀속이나 발생 사실을 증명하는 자료가 아니다. 조직은 이 구분을 전제로 자체 로그와 파일 분석 결과를 결합해 판단해야 한다.

저장소 신뢰 검증

이름·로고·README의 유사성이나 별표 수만으로 저장소를 신뢰해서는 안 된다. 도입 전에는 다음을 역방향으로 확인한다.

1. 프로젝트의 공식 웹사이트, 공식 조직 계정, 공식 패키지 레지스트리가 같은 저장소를 가리키는지 확인한다.
2. 계정 생성 시점, 커밋·기여자 이력, 릴리스 작성자, 태그·커밋 서명, 이슈·PR 활동을 함께 살핀다.
3. 릴리스 파일이 공식 GitHub Release 또는 문서화된 배포 경로에 있는지 확인한다. 외부 파일 호스팅, 단축 URL, 암호화 ZIP은 격리 검토 대상으로 분류한다.
4. 가능한 경우 소스에서 재현 가능한 빌드를 수행하고, 배포물의 해시·서명·평판을 검증한다.

이 절차는 개인의 주의에만 맡기지 않는다. 승인된 미러와 레지스트리, 외부 저장소 도입 승인, 예외 기록 체계를 운영 정책으로 만든다. 긴급 PoC도 개발 단말에서 내려받은 ZIP을 바로 실행하지 않는다는 원칙을 적용한다.

탐지와 예방 통제

캠페인 전용 IOC가 없을 때는 행위와 맥락을 중심으로 탐지한다. EDR·프록시·DNS·SIEM에서 다음 조합을 우선 확인한다.

• 다운로드·임시 디렉터리에서 생성된 미서명 실행 파일의 즉시 실행
• 압축 해제 프로세스가 만든 자식 프로세스, 추가 실행 파일 생성, 외부 파일 내려받기
• 새롭거나 평판이 낮은 도메인으로의 비정상 아웃바운드 연결과 반복 비콘
• 브라우저 또는 자격증명 저장소 접근과 의심스러운 네트워크 연결의 시간적 결합
• 승인되지 않은 저장소나 외부 릴리스 링크에서 받은 파일의 실행

개발 환경에는 애플리케이션 제어, 다운로드 경로 실행 제한, 압축 파일 검사, EDR 행위 차단을 우선 적용한다. GitHub 전체를 일괄 차단하기보다 승인된 조직·미러·레지스트리를 기본 경로로 정하고 예외는 기록·승인한다.

의심 단말 대응

의심 ZIP을 실행했거나 탐지 신호가 확인되면 단말을 네트워크에서 격리하되, 증거 보존 전 전원을 끄거나 파일을 삭제하지 않는다. EDR로 프로세스 트리, 메모리, 내려받은 파일, 브라우저 기록, 외부 연결을 수집한다. 저장소 URL·소유자·clone 시각·commit/tag·원본 배포 URL·파일 해시·실행 경로도 함께 기록한다.

이후 해당 단말에서 사용된 GitHub PAT, SSH 키, 패키지 레지스트리 토큰, 클라우드 키, 이메일·브라우저 세션을 범위와 우선순위에 따라 폐기·재발급한다. 비밀번호 변경만으로 토큰과 세션이 무효화되었다고 가정하지 않는다. GitHub 조직 감사 로그와 CI/CD 로그에서 신규 키 사용, 비정상 clone·push, workflow·secret·deploy key 변경을 조사하고, 같은 저장소나 배포 파일에 접근한 단말로 헌팅 범위를 넓힌다.

대응 우선순위

결론

핵심은 오픈소스를 회피하는 데 있지 않다. 검색·문서·릴리스 파일을 신뢰의 증거로 오인하지 않고, 저장소 검증, 다운로드·실행 통제, 행위 탐지, 토큰·세션 회수를 하나의 운영 절차로 연결하는 데 있다. 단일 출처만으로는 특정 캠페인의 규모·귀속·IOC를 확정할 수 없다. 추가 원문 보고서와 검증 가능한 IOC가 확보되기 전에는 조직의 자체 로그와 파일 분석을 우선해 대응 결정을 내려야 한다.

참고자료

• Chandan, “Case Study: FakeGit Campaign — 7,600 Fake GitHub Repositories Used to Spread Malware,” Medium, 2026-07-23. https://medium.com/@chandan20516/case-study-fakegit-campaign-7-600-fake-github-repositories-used-to-spread-malware-35fdce2f933e (단일 2차 출처이며 독립 검증된 원문 보고서·IOC는 확인하지 못함)
• MITRE ATT&CK, T1036 Masquerading. https://attack.mitre.org/techniques/T1036/
• MITRE ATT&CK, T1204.002 User Execution: Malicious File. https://attack.mitre.org/techniques/T1204/002/
• MITRE ATT&CK, T1105 Ingress Tool Transfer. https://attack.mitre.org/techniques/T1105/

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.