가짜 재택 코딩 과제에 Git hook 악성코드가 숨어 있었음

평범한 채용 과제처럼 시작한 공격

• 글쓴이는 링크드인에서 파이썬 개발자 역할 제안을 받음. 조건은 월 1만~1만5천 달러짜리 원격 우선 계약직이었음

  • 인도 기준으로는 꽤 큰 금액이라 바로 의심 신호가 켜졌다고 함
  • 회사 이름은 와이콤비네이터 스타트업처럼 보였고, 그래서 완전히 말이 안 되는 제안은 아닌 것처럼 포장돼 있었음
  • 리크루터는 이력서를 빠르게 통과시킨 뒤 구글 드라이브 링크로 과제 zip과 PDF를 보냄

• 과제 PDF와 프로젝트 첫인상은 꽤 그럴듯했음

  • 코드베이스 개선, 아키텍처 제안, Git 작업 같은 평범한 과제 내용이 들어 있었음
  • 압축을 풀어보니 FastAPI 백엔드와 SQLAlchemy를 쓰는 보일러플레이트 프로젝트처럼 보였음
  • requirements.txt에도 눈에 띄는 타이포스쿼팅 패키지나 수상한 의존성은 없었음

진짜 폭탄은 숨겨진 .git 디렉터리에 있었음

• 글쓴이는 습관적으로 tree -a를 실행해서 숨김 디렉터리까지 확인했고, 여기서 판이 뒤집힘

  • 프로젝트 안에 .git/hooks가 통째로 들어 있었고, 수많은 Git hook 파일이 미리 구성돼 있었음
  • 특히 pre-commit 파일을 열어보니 운영체제별로 외부 서버에서 스크립트를 내려받아 실행하는 코드가 들어 있었음

• pre-commit hook은 macOS, Linux, Windows를 감지해서 서로 다른 페이로드를 실행함

  • macOS는 curl로 http://45.61.164.38:5777/task/mac?id=402를 받아 sh로 실행함
  • Linux는 wget으로 http://45.61.164.38:5777/task/linux?id=402를 받아 sh로 실행함
  • Windows 계열은 curl로 Windows용 엔드포인트를 받아 cmd로 실행함
  • 출력은 /dev/null로 버리고 백그라운드에서 조용히 실행되게 만들어놨음

Linux 페이로드는 2단계로 더 깊게 들어감

• Linux용 첫 페이로드는 사용자의 ~/Documents 아래에 파일을 숨기고 실행함

  • tokenlinux.npl이라는 이름으로 2차 파일을 내려받은 뒤 tokenlinux.sh로 이름을 바꿈
  • 실행 권한을 주고 nohup bash로 백그라운드 실행함
  • nohup을 쓰면 터미널을 닫거나 세션이 끊겨도 프로세스가 계속 살아 있을 수 있음

• 2차 스크립트는 Node.js 기반 실행 환경까지 몰래 준비함

  • Node.js를 설치하거나 경로를 잡고, parser.js와 package.json을 내려받음
  • 필요한 npm 의존성을 조용히 설치한 뒤, 난독화된 parser.js를 백그라운드에서 실행함
  • 글쓴이가 id=402 값을 바꿔 요청해보니 다른 스크립트가 내려왔고, 공격자가 후보자별 추적 ID를 붙였을 가능성이 보였음

• package.json도 냄새가 심했음

  • clipboardy는 클립보드 접근, basic-ftp는 파일 전송, jsonwebtoken은 토큰 처리, ps-node는 프로세스 확인에 쓰일 수 있음
  • hardhat도 포함돼 있었는데, 이건 이더리움 개발 환경이라 암호화폐 지갑이나 웹3 관련 로컬 정보를 노렸을 가능성을 떠올리게 함
  • parser.js는 심하게 난독화돼 있어서 수동 분석이 쉽지 않았고, 일부 LLM은 악성코드 분석 요청으로 보고 거부했다고 함

변종도 있었고, 회사 이름도 미끼였음

• 글쓴이가 더 찾아보니 이 공격은 단발성이 아니라 여러 변종이 있었음

  • 어떤 사람들은 .vscode 폴더가 들어 있는 zip을 받았고, 그 안에는 디렉터리를 VSCode로 여는 순간 실행될 수 있는 명령이 숨어 있었다고 함
  • 이 경우엔 Git 명령을 실행하지 않아도, 폴더를 에디터로 여는 것만으로 감염될 수 있음

• 공격자는 실제 회사와 무관한 이름을 빌려 신뢰도를 만든 것으로 보임

  • 글쓴이가 Git 로그를 확인해보니 프로젝트는 어느 공개 FastAPI 개인 금융 서비스 저장소를 가져온 흔적이 있었음
  • 원본 저장소 위에 악성 숨김 디렉터리만 덧붙인 구조였음
  • 리크루터 계정은 글쓴이가 정체를 지적한 뒤 삭제된 것으로 보였다고 함

서버 쪽 흔적은 많지 않았지만, 공격 설계는 꽤 현실적임

• 글쓴이는 공격자 IP를 더 조사했고, Nmap에서 열린 포트 3개를 확인함

  • 포트 22는 Ubuntu의 OpenSSH 9.6p1이었고, 당시 기준으로 알려진 CVE를 바로 활용할 만한 상태는 아니었다고 함
  • 악성코드 배포는 노골적이었지만 서버 운영은 아주 허술하지만은 않았던 셈임

• 이 사건의 핵심 교훈은 명확함. 남이 준 프로젝트는 코드보다 실행 지점부터 봐야 함

  • requirements.txt, package.json만 보는 것으로는 부족함
  • .git/hooks, .vscode, 숨김 스크립트, 자동 실행 설정을 먼저 확인해야 함
  • 특히 채용 과제처럼 ‘일단 받아서 열고 커밋해보세요’ 흐름은 공격자가 개발자를 낚기에 너무 좋은 표면임

---

기술 맥락

• 이 공격의 핵심 선택은 악성코드를 애플리케이션 코드가 아니라 Git hook에 숨긴 거예요. 왜냐하면 개발자는 과제 코드는 의심해도 .git/hooks/pre-commit까지 매번 열어보는 경우가 훨씬 적거든요.

• pre-commit을 고른 이유도 현실적이에요. 과제 PDF에 Git 작업을 넣어두면 지원자는 자연스럽게 커밋을 하게 되고, 그 순간 hook이 실행돼요. 공격자는 별도의 실행 버튼 없이 개발자의 정상 워크플로를 트리거로 바꾼 셈이에요.

• 2단계 페이로드 구조도 흔한 악성코드 패턴이에요. 첫 스크립트는 작게 유지하고, 실제 기능은 서버에서 내려받은 다음 단계에 넣으면 탐지와 분석을 어렵게 만들 수 있거든요. 후보자별 id를 붙이면 누가 실행했는지도 추적할 수 있고요.

• .vscode 변종이 더 위험한 이유는 실행 조건이 더 낮아서예요. Git 명령을 치지 않아도 폴더를 에디터로 여는 행동만으로 명령이 실행될 수 있다면, 개발자가 평소처럼 프로젝트를 확인하는 순간 공격 표면에 올라가요.

• 그래서 방어 포인트는 패키지 의존성 검사만이 아니에요. 낯선 저장소를 받을 때는 숨김 디렉터리, Git hook, 에디터 설정, 자동 실행 스크립트를 먼저 확인해야 해요. 개발 도구의 편의 기능이 그대로 공격자의 실행 경로가 될 수 있거든요.