기록을 찾기 쉽게, 생각을 다시 움직이게.

혁신을 이룹니다, 오딘박스(OdinBOX)

누적 방문

무엇을 기록하나요

추천 글

직접 고른 글

최신 글

더 보기

IT

게임 런처 CDN 변조 사건으로 본 원격 스크립트 무결성 검증 (SRI/해시 검증)

간지뽕빨리턴님 2026. 11. 7. 00:40 댓글 0
반응형
SECURITY · 공급망 공격 분석

게임 런처 CDN 변조 사건으로 본
원격 스크립트 무결성 검증 (SRI/해시 검증)

'승리의 여신' 시리즈로 알려진 서브컬처 슈팅 RPG(이하 N게임)의 Windows PC 런처가 불러오는 CDN JavaScript 파일이 변조돼 원격제어 악성코드(RAT)가 퍼졌습니다. 공격 구조와 개발자 입장에서 본 원인, k2f_chan 감염 확인 방법, SRI·CSP·해시 검증으로 막는 방법까지 순서대로 정리했습니다.

무슨 일?런처가 실행될 때 불러오는 CDN의 JS 파일 4개가 변조돼 RAT가 설치됨
누가 위험?9월 27일 15:41 이후 Windows PC 런처를 한 번이라도 실행한 이용자 (모바일은 해당 없음)
지금은?파일 교체와 자동 검사 기능 배포는 끝났지만, 감염 규모와 침투 경로는 아직 미공개
표기 기준 이 글에서는 게임명과 회사명을 직접 쓰지 않고 아래처럼 줄여서 표기합니다.
  • N게임 : 해당 서브컬처 슈팅 RPG
  • S사 : 국내 개발사 / L사 : 글로벌 퍼블리셔(T사 계열 게임 퍼블리싱 브랜드)
  • 공식 운영사 공지 기준  연구자 독립 보안 연구자 보고서 기준  추론 필자 개인의 기술적 해석

01사건의 발단: 처음 어떻게 알려졌나

이상 징후를 처음 잡아낸 건 운영사가 아니라 이용자 커뮤니티였습니다. 중국 게임 커뮤니티 NGA에서 이용자들이 하나둘 단서를 모았고, 11월 3일 독립 보안 연구자 MotherSphere가 GitHub에 상세한 기술 보고서를 올리면서 일이 커졌습니다.

보고서 내용을 한 줄로 줄이면 이렇습니다. 수상한 파일을 따로 받은 적이 없어도 공식 PC 런처를 켜기만 하면 원격제어 악성코드가 깔릴 수 있었다는 겁니다. 런처가 실행될 때 자동으로 읽어 오는 L사 공식 CDN의 JavaScript 파일이 이미 변조된 상태였기 때문입니다.

시기도 좋지 않았습니다. N게임 4주년 업데이트(10월 29일 글로벌 적용) 직후라 접속자가 한창 몰리던 때였거든요. 하필 사람이 가장 많을 때 공식 배포 경로가 오염된 겁니다.

흔히 말하는 '게임 해킹'과 다른 점 계정 탈취나 핵 프로그램 이야기가 아닙니다. 정상 소프트웨어의 배포 경로 자체가 뚫린 공급망 공격(Supply-chain Attack)입니다. 이용자가 백신 경고를 무시했거나 불법 프로그램을 깐 것도 아니니, 개인이 알아서 피할 방법은 사실상 없었다고 봐야 합니다.

02전체 타임라인 (KST)

운영사 공식 발표와 연구자 보고서의 시각이 조금씩 다릅니다. 헷갈리지 않도록 출처를 나눠 적었고, 연구자 보고서의 UTC 시각은 KST(+9)로 바꿔 넣었습니다.

일시 (KST) 출처 내용
9/27 10:59 공식 일부 게임 서비스에 쓰던 도메인이 제3자에게 탈취됨
9/27 15:41~15:42 공식 PC 런처가 내려받는 CDN의 JavaScript 파일 4개 변조. 외부 도메인으로 연결되는 비정상 코드 삽입
9/30 연구자 로더 도메인에 대한 DNS 조회가 처음 관측됨
10/23~24 연구자 일부 이용자 PC에서 원격제어 에이전트가 실행된 가장 이른 사례 (초기 버전으로, 지갑 탈취 모듈은 없었음)
10/28 연구자 변조 파일 1개(FeedList)가 원본 서버에서 정리됨. 그러나 일부 CDN 엣지 서버는 변조본을 계속 내보냄
10/30 03:52 공식 변조 스크립트를 통한 악성 프로그램 유포 시작
11/3 연구자 NGA 커뮤니티 제보에 이어 GitHub 기술 보고서 공개
11/4 00:00경 공식 운영사가 파일 이상을 확인하고 조사 착수
11/4 02:04~02:23 공식 변조 파일 3개를 정상 파일로 교체
11/4 02:30경 공식 클라이언트 수정 및 업데이트 진행, 공식 SNS로 1차 안내
11/4 03:31 연구자 공격자 서버 응답 중단
11/4 07:26 연구자 파일을 교체한 뒤에도 CDN 서버 2곳이 변조된 FeedList 파일을 계속 제공
11/4 12:09 공식 마지막 파일의 CDN 캐시 갱신 완료, 정상 파일 순차 전파
11/4 20:20 연구자 확인한 서버 4곳 모두에서 파일 4개 정상화 확인
11/5 08:00 공식 공식 PC 클라이언트에 악성 프로그램 자동 검사·제거 기능 적용
11/5 공식 공식 사과문 게시, 피해 접수 창구 운영, 전 이용자 대상 보상 지급
타임라인을 보면서 걸렸던 부분
  • 변조에서 탐지까지 약 38일 : 9월 27일에 변조됐고 11월 4일에야 발견됐습니다. 그사이 운영사 내부 모니터링은 아무것도 잡아내지 못했습니다.
  • 유포 시작일이 서로 다름 : 공식 발표는 10월 30일인데, 연구자는 늦어도 10월 23~24일에는 시작됐다고 봅니다. 그 사이 페이로드도 최소 7차례 바뀌었다고 분석했습니다.
  • 원본을 고쳤다고 끝난 게 아님 : 원본 서버를 수정한 뒤에도 CDN 엣지 캐시가 변조본을 계속 뿌린 구간이 있었습니다.
  • 파일 개수 정정 : 초기 보도에는 '3개'로 나왔지만, 이후 공식 발표와 연구자 보고서 모두 4개로 바로잡았습니다.

03공격 체인 기술 분석

연구자 보고서와 보안 매체 보도를 맞춰 보면, 공격은 대략 아래 순서로 진행됐습니다.

① 도메인 탈취
게임 서비스에 쓰던 외부 도메인 insightjs[.]com을 제3자가 장악 공식
▼
② CDN 정적 파일 변조
런처가 실행될 때 불러오는 JS 파일 4개에 난독화된 로더 코드가 삽입됨
aegis-fix.min.js vue-bucket.min.js images.7fec4c32.js FeedList.feb647c9.js 연구자
▼
③ 2차 스크립트 로드
로더가 공격자 도메인에서 추가 스크립트를 받아 옴. 공격자 URL은 정수 배열로 바꿔 숨겨 둔 상태였음 연구자
▼
④ 런처 자체 다운로드 기능 악용
런처에 원래 있던 다운로드 기능으로 LuaJIT 페이로드 insight.bundle을 받아 실행 연구자
▼
⑤ 원격제어 에이전트 'K2F' 설치
명령 실행, 파일 탐색·다운로드, 화면 캡처, 계정 정보 수집 연구자
▼
⑥ 지속성 확보 (선택적)
추가 명령이 내려오면 platform_experience_helper.dll을 Chrome 사용자 데이터 경로에 설치. 이렇게 되면 런처를 꺼도 계속 동작할 수 있음 연구자

악성코드로 할 수 있었던 일

  • 임의 명령 실행(exec): 사실상 PC 전체를 제어할 수 있는 수준
  • 로컬 파일 탐색·다운로드·업로드, 런처 실행 중 화면 캡처
  • 브라우저에 저장된 비밀번호·쿠키·로그인 토큰, Windows 자격 증명 탈취
  • SSH 키, 개발용·클라우드 API 토큰 탈취
  • 브라우저 암호화폐 지갑 확장 프로그램 데이터 수집(대상 28종, MetaMask·Phantom·Coinbase Wallet 문자열 확인). 다만 실제로 빼 갔는지는 확인되지 않았습니다
  • 게임 계정 정보 수집

Linux, Steam Deck(Proton)도 안심할 수 없었다

Proton(Wine)으로 런처를 돌렸다면 안심하기 어렵습니다. Wine이 Linux 홈 폴더를 드라이브 문자로 연결해 두기 때문에 ~/.ssh, 브라우저 프로필, 셸 설정 파일에 들어 있는 비밀값까지 읽혔을 수 있다는 게 연구자의 경고입니다. 다만 Windows용 DLL을 이용한 지속성 기법은 여기서는 통하지 않습니다.

04개발자 입장에서 본 '왜 못 막았나'

운영사는 CDN 쓰기 권한이 어떻게 넘어갔는지 아직 밝히지 않았습니다. 그래서 아래 내용은 공개된 사실을 바탕으로 제가 해석한 추론이고, 확정된 원인은 아니라는 점을 먼저 말씀드립니다.

① 런처가 사실상 '브라우저'인 구조

요즘 게임 런처는 공지, 배너, 이벤트 화면을 웹 기술로 그리는 경우가 많습니다. 이 런처도 내장 브라우저 프로세스(tbs_browser.exe)로 통신했다고 알려졌습니다. 다시 말해 원격 서버의 JS가 바뀌면 런처의 동작도 같이 바뀝니다. 여기에 그 JS가 다운로드 기능 같은 네이티브 기능까지 건드릴 수 있었다면, 웹 쪽 변조 한 번이 곧바로 PC 장악으로 이어지는 구조가 됩니다.

② 원격 스크립트 무결성 검증이 없었던 것으로 보임 (추정)

변조된 JS가 아무 제지 없이 실행됐다는 건, 런처가 받아 온 스크립트의 해시나 서명을 확인하지 않았을 가능성이 크다는 얘기입니다. 웹이라면 SRI(Subresource Integrity), 네이티브라면 코드 서명이나 해시 고정(pinning)으로 충분히 막을 수 있는 유형입니다.

③ 서드파티 도메인에 기대는 위험

공식 발표를 보면 출발점은 서비스에 쓰던 도메인이 탈취된 것이었습니다. 분석·통계 SDK처럼 외부 도메인을 코드에 박아 두면, 그 도메인 소유권이 남에게 넘어가는 순간 공격자가 내 서비스 안에서 코드를 돌릴 수 있게 됩니다. 2024년 polyfill.io 사건도 같은 구조였습니다.

④ 탐지가 어려웠던 이유

  • 삽입 위치 : FeedList 파일은 모듈의 마지막 export 문 바로 앞에 708바이트가 끼어 있었습니다. 파일 끝부분만 비교하는 방식으로는 놓치기 쉽습니다.
  • 간헐적 실행 : 런처를 켤 때마다 동작한 게 아니라 일부 실행에서만 동작했습니다.
  • 흔적 최소화 : 새 프로세스를 띄우는 건 exec 명령 하나뿐이라 Prefetch나 프로세스 생성 로그에 잘 남지 않습니다. 임시로 만든 스크린샷과 자격 증명 사본도 읽고 나서 바로 지웠습니다.
  • 관리자 권한 요구 의혹 : 런처 매니페스트가 관리자 권한을 요청한다는 보고도 있습니다(미확정). 사실이라면 에이전트 역시 상승된 권한으로 돌았을 수 있습니다.

⑤ CDN 캐시는 되돌리는 데도 시간이 걸린다

원본(origin)을 고쳐도 엣지 서버에 캐시가 남아 있으면 변조본이 계속 나갑니다. 이번에도 원본을 수정한 뒤 몇 시간 동안 일부 서버가 변조 파일을 내보냈습니다. 사고 대응 계획에 강제 캐시 퍼지(purge)와 엣지별 확인 절차가 꼭 들어가야 하는 이유입니다.

05운영사와 업계의 대응

운영사(L사) 대응

구분 내용
1차 공지 (11/4) 공식 SNS를 통해 "스크립트 파일이 제3자에 의해 변조됐을 가능성이 있는 이상 현상"을 확인했다고 알림. 클라이언트 수정·업데이트를 진행 중이며 후속 공지를 하겠다고 안내
파일 정리 변조 파일 3개는 교체, 나머지 1개는 CDN 캐시 갱신으로 추가 유포를 막음
자동 검사 (11/5~) 공식 PC 클라이언트를 실행하면 내장 보안 기능(ACE)이 악성 프로그램을 자동으로 검사·제거. 웹 브라우저를 모두 닫고 실행해야 하며, 제거는 이용자가 동의한 뒤 진행
공식 사과 (11/5) 공식 사이트에 운영팀 명의 사과문 게시. 감염 확인 부담을 이용자에게 지운 점, 보상만으로는 불안을 해소할 수 없다는 점을 인정
피해 접수 고객센터에서 게임 내 피해, 외부 서비스 계정 이상, 금전 피해 신고를 받아 검토
보상 전 이용자 대상 우편 지급 (보석 3,000개, 고급 모집 티켓 10장 등)
재발 방지 약속 PC 런처와 관련 시스템의 보안 모니터링 강화, 외부 파일 변조 여부를 검증하는 체계 구축

국내 게임 업계 반응

보도에 따르면 국내 대형 게임사 한 곳은 11월 4일 계열사를 포함한 전 임직원에게 긴급 보안 공지를 보냈습니다. 업무 PC에 이 런처가 깔려 있으면 바로 지우고 보안팀에 알리라는 내용이었습니다. 게임 때문에 설치된 악성코드가 회사 내부망까지 위협할 수 있다고 본 것 같습니다. 개발자나 IT 업계에 있는 분이라면, 회사 PC에 개인 게임 런처를 까는 습관은 한 번쯤 다시 생각해 볼 만합니다.

아쉬웠던 부분
  • 공식 안내보다 커뮤니티와 연구자의 경고가 이용자에게 먼저 닿았습니다.
  • 공식 사과문이 1차 공지 다음 날에야 올라와 '늑장 사과'라는 말이 나왔습니다.
  • 검사 대상 기준 시각(9월 27일 15:41)에 시간대가 적혀 있지 않다는 지적도 있었습니다.
  • 감염 이용자 수, 유출된 데이터 종류, 침투 경로는 지금까지도 공개되지 않았습니다.

06내 PC 감염 여부 확인 방법

점검 전에 꼭 알아 둘 것 점검은 반드시 런처를 실행하지 않은 상태에서 하세요. 그리고 아래 흔적이 없다고 해서 안전하다는 뜻은 아닙니다. 재설치를 했거나 로그를 지웠다면 흔적이 남지 않고, 운영사 역시 흔적이 없더라도 위험을 완전히 배제할 수는 없다고 밝혔습니다.
  1. debug.log에서 k2f_chan 검색 (가장 확실한 지표)
    바탕화면 런처 아이콘을 우클릭해 '파일 위치 열기'로 게임 설치 폴더에 들어간 다음, 아래 파일을 메모장으로 열고 Ctrl+F로 k2f_chan을 찾아보세요.
    [게임 설치 폴더]\Launcher\intl_service\debug.log 검색어: k2f_chan (예: "k2f_chan registered"가 보이면 에이전트가 실행된 흔적)
  2. Chrome 사용자 데이터 경로 확인
    Win + R을 누르고 아래 경로를 입력한 뒤 Enter
    %LOCALAPPDATA%\Google\Chrome\User Data\PlatformExperienceHelper
    '폴더가 없다'는 메시지가 뜨면 적어도 이 위치에는 알려진 흔적이 없다는 뜻입니다. 폴더가 열린다고 해서 바로 감염은 아닙니다(Chrome이 정상적으로 쓰는 경우도 있습니다). 하지만 안에 0-9, a-f로 이뤄진 64자리 이름의 하위 폴더가 있고, 그 안에 platform_experience_helper.dll이 들어 있다면 감염을 의심해야 합니다.
  3. 런처 캐시의 Local Storage 검색 (고급)
    런처 AppData 폴더 안 tbs_cache\Local Storage\leveldb\에서 k2f.agent 문자열을 검색합니다. 압축된 .ldb 파일 속에 들어 있어 일반 검색으로는 안 보일 수 있습니다.
  4. tinyget 다운로드 로그 확인 (고급)
    Launcher\log\tinyget\에서 insight.bundle 요청 기록과 그 뒤의 다운로드 성공 기록이 있는지 봅니다(result=2, total=0은 실패). 받은 파일의 첫 바이트가 1B 4C 4A 01(LuaJIT 헤더)이면 에이전트입니다.
  5. DNS·공유기 로그 확인 (고급)
    insightjs[.]com, analytics.insightjs[.]com 조회 기록이 있는지 확인합니다. 특히 analytics 서브도메인을 조회한 기록이 있다면 에이전트 단계까지 갔을 가능성이 높습니다. 공유기의 IPv6 보조 DNS도 같이 확인하세요.
  6. 최신 런처로 공식 자동 검사 실행
    웹 브라우저를 모두 닫고 업데이트된 공식 PC 클라이언트를 실행하면 자동 검사·제거가 진행됩니다. 백신 전체 검사와 Microsoft Defender 오프라인 검사도 같이 돌려 두는 게 좋습니다.
PowerShell로 한 번에 확인하기 (참고용) 위 1번, 2번 항목을 한 번에 확인하는 읽기 전용 스크립트입니다. 파일을 지우거나 고치는 동작은 없습니다. $nikke_gameDir에 본인의 게임 설치 경로를 넣고 실행하면 됩니다.
# 읽기 전용 점검 스크립트 (삭제/수정 동작 없음) $nikke_gameDir = "C:\Program Files\[게임 설치 폴더]" # 본인 경로로 변경 # 1) debug.log 에서 k2f_chan 검색 $nikke_log = Join-Path $nikke_gameDir "Launcher\intl_service\debug.log" if (Test-Path -LiteralPath $nikke_log) { $nikke_hit = Select-String -LiteralPath $nikke_log -Pattern "k2f_chan" -SimpleMatch if ($nikke_hit) { Write-Host "[위험] k2f_chan 발견: $($nikke_hit.Count)건" -ForegroundColor Red } else { Write-Host "[정보] debug.log 에서 k2f_chan 미발견" -ForegroundColor Green } } else { Write-Host "[확인 필요] debug.log 없음 (경로 확인 또는 로그 삭제됨)" -ForegroundColor Yellow } # 2) PlatformExperienceHelper 하위 64자리 폴더 + DLL 확인 $nikke_peh = Join-Path $env:LOCALAPPDATA "Google\Chrome\User Data\PlatformExperienceHelper" if (Test-Path -LiteralPath $nikke_peh) { $nikke_dll = Get-ChildItem -LiteralPath $nikke_peh -Directory -ErrorAction SilentlyContinue | Where-Object { $_.Name -match '^[0-9a-fA-F]{64}$' } | ForEach-Object { Get-ChildItem -LiteralPath $_.FullName -Filter "platform_experience_helper.dll" -ErrorAction SilentlyContinue } if ($nikke_dll) { $nikke_dll | ForEach-Object { Write-Host "[위험] 의심 DLL: $($_.FullName)" -ForegroundColor Red } } else { Write-Host "[정보] 폴더는 있으나 의심 DLL 미발견" -ForegroundColor Green } } else { Write-Host "[정보] PlatformExperienceHelper 폴더 없음" -ForegroundColor Green }

※ 공개된 지표를 기준으로 만든 스크립트이고, 실제 감염 PC에서 돌려 보지는 않았습니다. '미발견'이 나와도 안전하다는 보장은 아닙니다.

07감염이 의심될 때 조치 순서

  1. 런처 종료 후 해당 PC 인터넷 차단
    추가 명령을 받거나 데이터가 빠져나가는 것부터 막습니다.
  2. 증거 백업 후 캐시 삭제
    런처 AppData의 tbs_cache 폴더를 따로 복사해 둔 뒤(피해 접수용) 삭제합니다. 그래야 변조 파일이 다시 로드되지 않습니다.
  3. 깨끗한 다른 기기에서 비밀번호 변경
    게임 계정, 이메일, 금융, 게임 스토어 등 그 PC에서 쓰던 계정은 전부 바꿉니다. 감염된 PC에서 바꾸면 소용이 없습니다.
  4. 모든 로그인 세션 강제 로그아웃
    쿠키가 털렸다면 비밀번호를 바꿔도 기존 세션은 살아 있을 수 있습니다.
  5. 개발자라면 키와 토큰 전부 교체
    SSH 키, GitHub/GitLab 토큰, AWS·GCP·Azure 키, .env에 있던 API 키, DB 접속 정보까지 모두 바꿉니다. Proton 사용자는 홈 폴더의 비밀값과 환경변수가 이미 노출됐다고 보고 대응하는 편이 안전합니다.
  6. 암호화폐 지갑 자산 옮기기
    그 브라우저에 지갑 확장 프로그램이 있었다면 새 지갑(새 시드)으로 자산을 옮깁니다.
  7. 운영체제 재설치
    임의 명령을 실행할 수 있었던 만큼 다른 악성코드가 추가로 깔렸을 수도 있습니다. 연구자도 감염이 확인된 PC라면 OS 재설치가 가장 안전하다고 권고했습니다.
  8. 도메인 차단 유지 및 피해 신고
    방화벽이나 공유기에서 insightjs[.]com, insightjs[.]org 차단을 유지합니다. 피해가 있다면 게임 고객센터와 KISA(118)에 신고하세요.

08현재 상황과 남은 의문점 (11/7 기준)

항목 상태
CDN 변조 파일 공식 4개 모두 정상화, 현재 배포 중인 런처는 보안 조치 완료
공격자 서버 연구자 11/4 새벽 응답 중단. 백업 도메인(insightjs[.]org)에는 현재 런처를 종료하라는 다국어 경고 페이지가 떠 있지만, 누가 운영하는지는 확실하지 않음
자동 검사·제거 공식 11/5 08:00부터 적용
모바일 버전 공식 영향 없음
감염 이용자 수 미공개
실제 유출 데이터 미공개 (지갑 탈취 등 실제 피해는 확인되지 않음)
CDN·도메인 침투 경로 미공개
이미 감염된 PC 서버 파일이 정상화돼도 자동으로 치료되지 않음. 개별 점검과 조치가 필요
비슷한 사례: 2025년 9월, 다른 서브컬처 게임의 CDN 설정 변조 2025년 9월에도 국내 대형 게임사가 서비스하는 다른 서브컬처 게임에서 비슷한 일이 있었습니다. 클라이언트가 실행할 때 확인하는 CDN 환경설정이 외부에서 무단으로 바뀌어 게임 안에 비정상 배너가 뜬 사고였습니다. 운영사는 설정을 원래대로 돌리고 외부 접근 경로를 막은 뒤, 설정 권한을 인가된 곳으로 제한하고 이중 통제를 추가했습니다. 그때는 화면 장난 수준에서 끝났지만, 이번 사건으로 같은 'CDN을 믿는' 구조가 실제 악성코드 배포로까지 이어질 수 있다는 게 드러났습니다.

09개발자로서 챙겨야 할 교훈

이 사건을 게임 업계만의 일로 볼 건 아닙니다. 사내 ERP 웹 화면, Electron/WebView 기반 데스크톱 앱, 하이브리드 모바일 앱처럼 원격 리소스를 받아서 실행하는 프로그램이라면 전부 해당됩니다.

① 외부 스크립트에는 SRI 적용

해시가 맞지 않으면 브라우저가 스크립트 실행을 거부합니다. CDN 파일이 1바이트만 바뀌어도 막힙니다.

<script src="https://cdn.example.com/app.min.js" integrity="sha384-(빌드 시 생성한 해시값)" crossorigin="anonymous"></script> # 해시 생성 (빌드 파이프라인에서) openssl dgst -sha384 -binary app.min.js | openssl base64 -A

② CSP로 스크립트 출처 제한

허용 목록에 없는 도메인(예: 탈취된 분석 도메인)에서는 스크립트를 불러오지 못하게 합니다.

Content-Security-Policy: script-src 'self' https://cdn.example.com; connect-src 'self' https://api.example.com; object-src 'none'; base-uri 'self'

③ 네이티브 앱은 원격 파일 해시 검증 후 로드

런처나 업데이터처럼 원격 리소스를 받아 쓰는 프로그램이라면, 빌드할 때 만든 해시 목록(manifest)을 서명해서 앱에 넣어 두고 받은 파일과 대조한 다음에만 써야 합니다. 아래는 Node.js로 작성한 예시입니다.

const nikke_crypto = require('crypto'); // 빌드 시 생성해 앱에 내장한 허용 해시 목록 (서명 검증된 manifest에서 로드 권장) const nikke_allowHash = { 'app.min.js': 'sha384-(빌드 시 생성한 해시값)' }; function nikke_verifyRemote(nikke_name, nikke_buf) { const nikke_expected = nikke_allowHash[nikke_name]; if (!nikke_expected) return false; // 목록에 없는 파일은 거부 const nikke_actual = 'sha384-' + nikke_crypto.createHash('sha384').update(nikke_buf).digest('base64'); // 길이가 다르면 timingSafeEqual 이 예외를 던지므로 먼저 비교 if (nikke_actual.length !== nikke_expected.length) return false; return nikke_crypto.timingSafeEqual(Buffer.from(nikke_actual), Buffer.from(nikke_expected)); } // 사용: 검증 실패 시 실행하지 않고 로컬 번들로 대체 // if (!nikke_verifyRemote('app.min.js', nikke_downloadedBuffer)) { /* 차단 + 로그 */ }

④ 웹 영역과 네이티브 기능 사이에 벽 세우기

  • WebView나 내장 브라우저에 열어 주는 브리지 API는 최소한으로 두고, '파일 다운로드 후 실행' 같은 위험한 기능은 원격 JS에서 절대 호출할 수 없게 막습니다.
  • Electron이라면 contextIsolation: true, nodeIntegration: false, sandbox: true를 기본값으로 둡니다.
  • 런처가 관리자 권한을 요구하지 않도록 만듭니다(최소 권한 원칙).

⑤ 운영 쪽 체크리스트

  • 도메인 자산 관리 : 코드에서 참조하는 외부 도메인 목록을 따로 관리하고, 만료·소유권 변경·DNS 레코드 변경을 모니터링합니다.
  • CDN 파일 변경 감시 : 배포 파이프라인이 아닌 경로로 파일이 바뀌면 바로 알림이 오도록 주기적으로 해시를 대조합니다. 원본만 보지 말고 엣지 서버 응답도 샘플링해서 확인해야 합니다.
  • CDN 쓰기 권한 최소화 : 배포 계정 분리, MFA, 이중 승인, 접근 IP 제한.
  • 사고 대응 매뉴얼 : 캐시 강제 퍼지, 엣지별 정상화 확인 절차, 이용자 공지 템플릿을 미리 준비해 둡니다. 이번에 연구자 경고가 공식 공지보다 빨랐던 게 결국 신뢰 문제로 번졌다는 점을 생각하면 더 그렇습니다.
마치며 결국 이번 사건은 '공식 경로니까 안전하다'는 믿음이 깨진 사례입니다. 이용자라면 업무용 PC와 게임용 PC를 나누고, 중요한 키나 토큰을 브라우저나 홈 폴더에 평문으로 두지 않는 습관이 필요합니다. 개발자라면 내가 불러오는 원격 코드는 전부 '언젠가 변조될 수 있는 입력값'으로 보고 설계해야 한다는 점을 다시 한번 생각하게 됩니다.

10자주 묻는 질문

Q. 어떤 이용자가 위험한가요?

9월 27일 15:41 이후 Windows PC 런처를 한 번이라도 실행했다면 점검 대상입니다. 운영사 발표 기준으로 모바일 버전은 영향이 없습니다.

Q. 감염 여부는 어떻게 확인하나요?

런처를 끈 상태에서 게임 설치 폴더의 Launcher\intl_service\debug.log에 k2f_chan 문자열이 있는지 먼저 확인하세요. 그다음 %LOCALAPPDATA%\Google\Chrome\User Data\PlatformExperienceHelper 아래에 64자리 이름의 폴더와 platform_experience_helper.dll이 있는지 봅니다. 흔적이 없다고 안전이 보장되지는 않습니다.

Q. 서버 파일이 정상화됐으면 이미 감염된 PC도 괜찮나요?

아닙니다. 서버 쪽 파일이 정상화돼도 이미 설치된 악성코드는 자동으로 치료되지 않습니다. 웹 브라우저를 모두 닫고 최신 공식 클라이언트의 자동 검사를 실행하고, 감염이 의심되면 비밀번호·토큰 교체와 OS 재설치까지 고려해야 합니다.

Q. 개발자는 이런 공격을 어떻게 막을 수 있나요?

외부 스크립트에는 SRI를 적용하고, CSP로 스크립트를 불러올 수 있는 출처를 제한합니다. 네이티브 앱이라면 서명된 해시 목록(manifest)과 대조한 뒤에만 원격 파일을 실행하고, WebView에 열어 주는 브리지 API는 최소한으로 둡니다.

REF참고 자료

※ 이 글은 2026년 11월 7일까지 공개된 공식 공지, 언론 보도, 독립 연구자 보고서를 바탕으로 작성했습니다. 연구자 보고서 중 운영사가 확인하지 않은 내용은 따로 표시했고, 이후 공식 발표에 따라 내용이 바뀔 수 있습니다. 감염 여부 판단과 피해 대응은 운영사 공식 안내를 먼저 따르세요.