사상 리더
바이낸스 탈취 사건은 채용 면접에서 시작됐다: 접근 권한이 피해 규모를 결정했다

9월, 바이낸스의 한 소프트웨어 엔지니어는 실재하지 않는 회사와 두 차례 채용 면접을 했다. 첫 번째는 인사 담당자와의 실시간 화상 통화였다. 인사 담당자는 자신이 실제 인물임을 증명하기 위해 사진과 동영상이 포함된 개인 소셜 미디어 계정을 공유했다. 두 번째 면접은 채팅 앱에서 진행됐으며, 대화 상대는 자신을 최고경영자라고 소개했다. 면접이 끝나갈 무렵, 엔지니어는 업무용 컴퓨터에 코딩 과제를 내려받으라는 요청을 받았다.
10월 29일, 공격자들은 바이낸스 지갑에서 약 63억 4천만 달러를 빼냈으며, 대부분은 약 20분 만에 빠져나갔다. FBI는 이번 탈취 사건의 배후로 TraderTraitor를 지목했다. 이 북한 해커 조직은 2025년 2월 Bybit에서 발생한 15억 달러 규모의 탈취 사건의 배후로도 지목됐다. 이번 사건은 기록상 최대 규모의 암호화폐 탈취 사건이다.
바이낸스는 책임을 인정하고 손실을 부담하겠다고 밝혔다. 11월 3일 기준으로, 영향을 받은 토큰 자산의 98%를 보충했으며 약 28억 5천만 달러를 동결하거나 탈취를 차단했다고 보고했다.
물어볼 만한 질문은 이것이다. 침해된 노트북 한 대가 어디까지 접근할 수 있었을까? 그리고 오늘날 각 팀은 자체 환경에서 이를 모두 테스트할 수 있을까?
두 가지 침투 경로와 6월부터 10월까지 이어진 공격
바이낸스가 11월 3일 발표한 업데이트에는 딥페이크나 다른 AI 활용 기법을 사용했다는 내용이 없다. 두 침투 경로 모두 사람을 통해 이뤄졌다. 검색 결과를 믿은 엔지니어 한 명과 채용 담당자를 믿은 또 다른 엔지니어였다.
공격은 최소 5개월 동안 이어졌다. 6월, 지갑 운영을 담당하는 DevOps 엔지니어가 AI 코딩 도구를 찾다가 변조된 Homebrew 설치 프로그램을 내려받았다. 바이낸스 보안팀은 이상 징후를 발견해 기기를 교체하고 인증 정보를 변경했다. 하지만 그때쯤 공격자들은 이미 지갑 인프라팀에 누가 소속되어 있는지 알아낸 뒤였다.
3개월 뒤, 공격자들은 다른 경로로 다시 침투했다. 9월에 접근을 받은 엔지니어는 바이낸스에서의 경력을 기재한 프로필을 정식 구직 플랫폼에 올려 두고 있었다. 코딩 과제에는 설정 과정에서 실행되는 악성 코드가 들어 있었다. 이 코드는 정상적인 pyenv 구성 요소를 악성 구성 요소로 바꾸고, 공격자가 제어하는 서버에 연결한 뒤 흔적을 지웠다. 바이낸스는 자사 엔드포인트 보호 시스템이 이를 탐지하지 못했다고 밝혔다.
10월 20일, 공격자들은 해당 노트북과 내부 AI 도구를 이용해 엔지니어 두 명의 기기를 추가로 장악했다. 그중 한 대는 6월에 침해된 DevOps 엔지니어의 기기였다. 공격자들은 그 기기에서 컨테이너 배포 권한이 있는 토큰을 찾아냈다. 10월 29일에는 다른 엔지니어의 컴퓨터에 로그인해 탈취한 인증 정보로 컨테이너를 배포하고, 탈취를 시작한 스크립트를 실행했다.
채용 담당자를 가장한 접근이 여전히 통하는 이유
가짜 채용 담당자와 악성 코드를 심은 코딩 테스트는 오래된 수법이다. 북한 측 공격자들은 수년간 개발자를 상대로 이 수법을 써 왔으며, 그중 가장 잘 알려진 사례가 Contagious Interview로 알려진 공격 캠페인이다. 바이낸스는 2026년에만 북한과 연계된 것으로 의심되는 공격 시도 57건을 저지했다고 밝혔다.
이 수법이 통하는 이유는 엔지니어가 매일 하는 일을 하도록 유도하기 때문이다. 익숙하지 않은 저장소를 실행하는 것은 기술 면접에서 흔히 있는 일이다. 의심스러운 발신자 주소도, 마우스를 올려 확인할 링크도 없다. 그럴듯한 고용주와 화상 통화에 등장하는 사람, 그리고 업무처럼 보이는 과제만 있을 뿐이다.
채용 담당자의 연락은 사람들이 반기는 몇 안 되는 원치 않은 접근이기도 하다. 모든 엔지니어가 그럴듯한 접근을 매번 알아차리도록 보안 인식 교육으로 보장할 수는 없다. 따라서 보안 통제는 어떤 접근 하나쯤은 통과할 수 있다고 가정해야 한다.
노트북 한 대가 지갑에 접근한 경로
우선 그 엔지니어의 업무 환경에 어떤 보안 통제가 적용되어 있었는지 궁금하다. 외부 코딩 평가에 업무용 컴퓨터를 사용하는 것은 검토가 필요하다. 더 큰 문제는 이 단 한 번의 침해로 어떻게 다른 시스템에 접근할 수 있었고, 결국 민감한 금융 인프라에까지 도달했는가 하는 점이다.
최초 감염 이후의 각 단계는 바이낸스 내부에 이미 존재하던 신뢰를 이용했다. 내부 AI 도구는 침해된 기기의 지시를 받아 이를 동료들의 기기로 전달했다. 배포 토큰은 엔지니어의 노트북에 있었다. 유효한 인증 정보로 컨테이너를 배포해 수십억 달러를 옮겼다. 이 과정에는 추가로 누군가를 유인할 필요가 없었다.
내부 AI 도구에는 특히 주의를 기울여야 한다. 이런 도구는 저장소, 엔드포인트, 서비스 전반에 걸쳐 광범위한 권한으로 실행되는 경우가 많다. 따라서 내부 AI 도구에 지시할 수 있는 기기를 장악한 자는 그 도구가 접근할 수 있는 모든 범위에 접근할 수 있게 된다.
개발을 지연시키지 않으면서 개발자 보호하기
개발자는 패키지를 내려받고, 익숙하지 않은 코드를 실행하고, 소프트웨어를 테스트해야 한다. 노트북을 금융 부서의 업무용 컴퓨터처럼 엄격하게 잠그면 개발 속도가 크게 떨어지고 엔지니어들이 우회 방법을 찾게 될 것이다. 구직 활동을 회사 기기에서 하지 못하게 하는 정책은 합리적이지만, 누구도 언제나 정책을 따르는 것은 아니다. 현실적인 목표는 개발자 기기가 침해되더라도 다음에 할 수 있는 일을 제한하는 것이다.
몇 가지 통제 조치가 가장 큰 차이를 만든다. 신뢰할 수 없는 코드는 기업 자격 증명에 접근할 수 없는 일회용 가상 머신에서 실행해야 한다. 배포 자격 증명은 유효 기간을 짧게 설정하고 권한 범위를 엄격히 제한해야 하며, 가능한 경우 통제된 배포 워크플로에 발급해야 한다. 지갑 서명 키나 키 조각은 개발자 워크스테이션과 분리해 보호하고, 어떤 거래와 승인 요청을 승인할 수 있는지 제한하는 서명 정책을 적용해야 한다. 지갑, 결제 또는 프로덕션 시스템에 영향을 주는 작업은 별도의 기기를 사용하는 다른 사람의 승인을 받아야 한다. 내부 AI 도구는 최소한의 권한으로 실행하고 수행한 작업을 기록해야 한다.
자격 증명이 유효한 경우에도 탐지가 작동해야 한다. 예상치 못한 기기나 시간대에 이뤄진 배포를 표시하는 행위 기반 모니터링을 적용하면 모든 자격 증명이 유효한 상황에서도 팀이 개입할 기회를 얻을 수 있다. Binance는 사건 이후 이러한 유형의 탐지 기능을 확대했다고 밝혔다.
위협 인텔리전스가 맡는 역할
도난 사건이 발생하기 6주 전, 경고 내용이 공개됐다. Contagious Interview에 관한 공동 권고문은 AI, 암호화폐, NFT 기업의 채용 담당자를 사칭해 IT 전문가를 표적으로 삼고 암호화폐를 훔치는 공격자들의 수법을 설명했다. Binance 사건도 같은 수법을 따랐다.
이와 같은 공격에서 위협 인텔리전스는 구체적인 역할을 한다. 공격자들은 바뀔 수 있지만, 이들의 전술은 이미 알려져 있다. 공격자를 추적하는 팀은 알려진 공격 인프라를 차단하고 현재 사용되는 접근 구실에 대해 엔지니어들에게 경고할 수 있다.
위협 인텔리전스는 누구를 추가로 보호해야 하는지도 알려준다. Binance의 6월 침해 사고처럼 사건을 통해 민감한 접근 권한을 보유한 사람이 드러나면, 이들을 수개월 동안 공격 표적이 될 가능성이 높은 사람으로 보고 기기와 이들에게 접촉해 오는 수법을 더욱 면밀히 모니터링해야 한다.
암호화폐 업계 밖에서의 의미
도난당한 자금은 빠르게 이동하고 회수하기 어렵기 때문에 암호화폐 거래소는 당연히 표적이 되기 쉽다. 개발자 워크스테이션에서 몇 단계만 거치면 핵심 시스템에 도달할 수 있는 곳이라면 어디서든 같은 양상이 나타난다. 은행의 결제 처리 과정이든 소프트웨어 공급업체의 빌드 및 릴리스 프로세스든 마찬가지다. 채용을 가장한 접근은 이 모든 곳의 엔지니어들에게도 이어진다.
이번 주 자체 환경을 점검하는 보안 책임자라면 두 가지를 우선 확인해야 한다. 첫째, 저장된 토큰, SSH 키, 클라우드 자격 증명, 내부 AI 도구를 포함해 개발자 노트북 한 대가 침해될 경우 현재 어디까지 접근할 수 있는지 파악해야 한다. 둘째, 프로덕션 배포와 고액 거래에 독립적인 승인이 필요한지 확인해야 한다. 침해된 계정 하나만으로는 그 승인을 내릴 수 없어야 한다.
Binance는 영향을 받은 시스템을 재구축하고 독립적인 검토자를 참여시켰지만, 결정은 손실이 발생한 뒤에야 내려졌다. 같은 점검을 지금 수행하는 조직은 자체 일정에 맞춰 결정을 내릴 수 있다.












