가짜 폰트에 숨긴 계정 탈취 코드: 고스트액션이 버려진 오픈소스 저장소 94곳을 파고든 방식

오픈소스 생태계를 겨냥한 공급망 공격이 한 단계 더 교묘해졌다. 자동 빌드 파이프라인(CI/CD)을 악용하던 공격자가 클라우드 플랫폼의 차단벽에 부딪히자, 이번에는 글꼴(폰트) 파일로 위장한 악성코드를 심어 개발자의 개인 PC 내부로 직접 파고들기 시작했다.

보안 연구소 오픈소스멀웨어(OpenSourceMalware)가 추적한 ‘고스트액션(GhostAction)’ 공격 캠페인은 94개 오픈소스 저장소를 장악하며 개발자 인증 정보 탈취를 시도했다. 공격자는 관리자가 오랫동안 방치한 저장소를 주 표적으로 삼았으며, 보안 경고를 사칭한 정교한 피싱 사이트로 2차 인증(2FA)과 권한 승인 단계를 무력화했다.

이번 사건의 본질은 클라우드 보안 도구가 감시하는 영역과 개발자가 일상적으로 코드를 내려받아 작업하는 로컬 환경 사이의 빈틈을 파고들었다는 점이다. 깃허브가 클라우드 상에서 악성 자동화 실행을 막아서자, 공격자는 개발자가 에디터를 켜는 순간 로컬 기기에서 악성코드가 실행되도록 구조를 바꿨다.

방치된 저장소 94곳과 가짜 도메인: 숫자로 드러난 침투 규모

오픈소스멀웨어의 분석 자료에 따르면 이번 공격에 악용된 저장소는 총 66명의 계정에 속한 94개 프로젝트다. 이 중 15개는 사후 조치로 삭제되거나 비공개로 전환되었으나, 나머지 대다수는 수년 동안 업데이트가 멈춘 프로젝트였다.

공격자는 2026년 10월 9일 my-github[.]com 도메인을 등록하고, 훔친 데이터를 전송받을 서버 IP(193.32.204[.]199)에 연결했다. 이 도메인은 등록 당일부터 곧바로 특정 오픈소스 프로젝트 관리자를 노린 표적 피싱에 동원되었다.

구분 지표	1단계 공격 (초기 클라우드 방식)	2단계 공격 (우회 로컬 침투 방식)	비고 및 분석 의미
침투 표적	깃허브 액션 러너(CI 가상 머신)	개발자 로컬 PC (VS Code 작업 환경)	클라우드 차단망을 피해 개발자 기기 직접 겨냥
악성 파일 형태	.github/workflows/ 내 자동화 파일	글꼴 확장자 위장 파일 + 설정 파일 3종	정상 에디터 설정으로 둔갑시켜 탐지 회피
인증 탈취 기법	역방향 프록시 피싱 + 토큰 탈취	디바이스 플로우 기반 백그라운드 자동 승인	사용자가 인지하지 못하는 사이 OAuth 권한 부여
데이터 탈취 경로	TCP 8443 포트 직통 전송	HTTP 8080 포트 + 비공개 Gist 백업	통신 실패 시 깃허브 내부 저장소로 우회
상주 유지 방식	깃허브 플랫폼 내 워크플로 실행	운영체제 크론탭(Cron) 5분 주기 등록	저장소 코드가 삭제되어도 로컬 기기 잔존
저장소 방치 기간	평균 1년 이상 (최장 9년 방치)	동일 저장소 재활용	활성 프로젝트 대비 관리 감시가 느슨한 곳 집중

주목할 부분은 공격자가 인증 체계를 속인 방법이다. 피해자에게 전달된 메일은 “러시아 모스크바에서 새로운 로그인이 감지되었다”는 내용의 긴급 보안 경고였다. 메일에 포함된 링크는 역방향 프록시 형태로 작동하는 가짜 웹페이지로 연결되어, 관리자가 입력한 비밀번호와 2단계 인증 번호를 실시간으로 가로챘다.

더 나아가 이 페이지에는 자바스크립트 코드가 심어져 있어, 사용자가 화면에서 승인 버튼을 누르지 않아도 기기 인증 흐름(OAuth Device Flow)을 거쳐 저장소 읽기·쓰기(repo), 워크플로 수정(workflow), 조직 정보 열람(read:org) 권한을 자동으로 획득하도록 설계되었다.

개발팀과 공급망 운영 현장에 닥친 3대 현실적 타격

오픈소스 프로젝트나 외부 라이브러리를 가져와 쓰는 일반 기업 환경에서 이번 공격은 단순한 개인 계정 도난 이상의 실질적 피해를 유발한다.

사후 수습 인건비와 클라우드 운영 비용(OPEX) 급증

개발팀 내부의 한 개발자가 악성코드가 심긴 저장소를 무심코 내려받아(Git Clone) 코드를 열람하기만 해도 감염이 시작된다. VS Code 작업 영역 설정 파일이 동작하면서 백그라운드에서 크론 작업이 등록되고, 로컬 기기에 저장된 환경 변수, 데이터베이스 접속 비밀번호, 클라우드 접근 키가 외부로 빠져나간다.

이 경우 단순 계정 비밀번호 변경으로 끝나지 않는다. 해당 기기에서 다루던 사내 클라우드 인프라의 모든 API 키와 접근 권한을 전면 재발급해야 하며, 외부 감사와 코드 점검에 수백 시간의 엔지니어링 리소스가 낭비된다.

배포 파이프라인 지연(Lead Time)과 개발 생산성 마비

저장소 침해 징후가 발견되면 기업의 보안 정책에 따라 모든 배포 작업이 일시 중단된다. 오염된 커밋이 사내 제품군이나 다운스트림 고객사로 전파되었는지 추적하는 데 며칠에서 몇 주가 소모된다.

특히 이번 공격처럼 글꼴 파일 내부에 실행 코드를 숨기는 수법은 표준 정적 코드 분석기를 그대로 통과하기 때문에, 코드를 한 줄씩 수작업으로 검증하는 병목 현상이 발생하여 신규 기능 배포와 긴급 장애 대응 일정이 전면 지연된다.

사내 공급망 신뢰 붕괴와 고객사 데이터 유출 위협

오픈소스 라이브러리는 현대 소프트웨어의 조립식 레고 블록과 같다. 감염된 오픈소스 코드가 내부 서비스에 포함되면, 우리 회사가 만든 정식 소프트웨어를 통해 최종 고객사 내부로 악성 행위가 번져나간다.

2단계 공격에서 확인되었듯, 공격자는 감염된 기기에서 훔친 정보를 비공개 깃허브 Gist에 분산 업로드하는 예비 경로까지 마련해 두었다. 방화벽이 차단되어도 정상적인 개발 플랫폼 트래픽으로 위장해 빠져나가므로, 고객 데이터가 유출된 사실조차 뒤늦게 알아차릴 위험이 크다.

플랫폼의 감시망을 벗어난 공격 기술과 이를 막아내는 완충벽

공격자가 전술을 바꾼 배경을 짚어보면 플랫폼과 공격자 사이의 쫓고 쫓기는 역학 관계가 드러난다.

2026년 10월 9일 깃허브가 클라우드 상에서 악성 워크플로가 실행되지 않도록 차단 조치를 단행하자, 공격자는 불과 6일 만에 2단계 전술을 꺼내 들었다. 플랫폼 서버에서 코드를 돌리지 못하게 되자, 코드를 로컬 컴퓨터로 내려받는 개발자의 손끝을 노린 것이다.

다행스러운 점은 이번 공격자가 사용한 수법 곳곳에 미숙한 흔적이 남아 있다는 사실이다. 오픈소스멀웨어의 보안 연구진에 따르면, 공격자가 작성한 환경 변수 수집 필터는 정작 중요한 클라우드 서비스 API 키 대다수를 빠뜨렸으며, 사용자 홈 디렉터리 검색 스크립트는 작업 시간이 초과하면 수집 결과를 스스로 폐기하는 오류를 보였다.

또한 단 하나의 고정 IP 주소(193.32.204[.]199)를 피싱 페이지 운영, 데이터 수집, 무차별 인터넷 스캐닝에 한꺼번에 사용했다. 공격 인프라를 분리하지 않은 이 치명적인 실수 덕분에 보안 관제 시스템에서 해당 IP와 관련된 침해 흔적을 빠르게 식별할 수 있었다.

인프라 모니터링 환경에서는 네트워크 이상 징후를 감지하는 도구의 역할이 두드러진다. 사내 엔지니어링 네트워크에서 8080 포트나 비정상 TCP 8443 포트로 대량의 외부 통신이 시도될 때, Datadog 같은 관제 도구를 통해 비정상적인 프로세스 실행과 아웃바운드 트래픽 급증을 즉각 잡아내는 체계가 효과적인 완충벽으로 작동한다.

침해 위험을 줄이기 위한 현장 위기 대응 3단계 방어선

고스트액션과 같이 클라우드와 로컬을 넘나드는 공급망 공격에 맞서기 위해, 엔지니어링 조직이 즉시 실행해야 할 3단계 방어선은 다음과 같다.

1차 방어선: 즉각적인 법적 및 운영 위험 스크리닝

사내 개발자 중 침해 의심 저장소를 내려받았거나 피싱 메일을 열람한 인원이 있다면, 감염 의심 PC가 아닌 완전히 격리된 별도의 청정 기기에서 다음 조치를 즉시 수행해야 한다.

• 깃허브 승인 앱 및 토큰 취소: 깃허브 계정 설정의 인가된 애플리케이션(Authorized OAuth Apps) 목록에서 본인이 직접 등록하지 않은 외부 애플리케이션을 즉각 삭제한다.
• 개인 접근 토큰(PAT) 전면 폐기: 워크플로 수정 권한이나 저장소 쓰기 권한이 포함된 기존 토큰을 전량 폐기하고 재발급한다.
• 2단계 인증 수단 재등록: SMS나 단순 앱 알림 방식 대신 하드웨어 보안 키(FIDO2/WebAuthn) 방식을 적용하여 프록시 기반 중간자 피싱 공격을 원천 차단한다.

2차 방어선: 로컬 개발 장비 및 저장소 청정화

공격자가 남겨둔 2단계 상주 코드는 깃허브에서 악성 저장소를 삭제해도 개발자 개인 기기 안에 그대로 남아 작동한다. 로컬 운영체제 차원의 정밀 검사가 필수적이다.

• 스케줄러 및 크론탭 확인: 맥(macOS)이나 리눅스 환경에서는 터미널에서 crontab -l 명령을 실행하여 5분 주기로 외부 통신을 시도하는 등록 스케줄이 있는지 대조한다. 윈도우 환경에서는 작업 스케줄러(Task Scheduler)를 점검한다.
• 에디터 작업 영역 설정 점검: 사내 프로젝트 루트 디렉터리에 의심스러운 .vscode/tasks.json 파일이나 .vscode/settings.json 파일이 포함되어 있는지 확인한다. 저장소를 열 때 스크립트를 자동 실행하도록 허용하는 옵션을 전사적으로 끈다.
• 위장 파일 전수 검색: 저장소 내부에 등록된 파일 중 확장자만 폰트(TTF, WOFF, OTF)로 되어 있고 실제 파일 헤더가 실행 바이너리 형태인 파일이 있는지 정적 스크립트로 검사한다.

3차 방어선: 장기 방치 오픈소스 격리 및 CI/CD 권한 최소화

근본적인 공급망 안전을 확보하기 위해 외부 코드를 조직 내부로 들여오는 규칙을 재정비해야 한다.

• 1년 이상 업데이트가 중단된 패키지 차단: 최근 12개월 이상 메인테이너의 커밋이나 릴리스가 없는 프로젝트는 사내 승인 없이 직접 의존성에 추가하지 못하도록 정책을 세운다.
• 워크플로 기본 권한 읽기 전용 강제: 깃허브 조직 설정에서 GITHUB_TOKEN의 기본 권한을 ‘읽기 및 쓰기’에서 ‘읽기 전용(Read repository contents permission)‘으로 낮춘다. 워크플로가 멋대로 코드를 변조하거나 다른 저장소에 푸시하는 통로를 사전에 봉쇄해야 한다.
• 저장소 보관(Archive) 처리: 사내에서 더 이상 유지보수하지 않는 오래된 저장소는 즉시 비공개로 바꾸거나 공식 보관(Archive) 상태로 전환하여 공격자가 계정을 탈취하더라도 악성 코드를 주입할 표적 자체를 줄여야 한다.