Back to Blog

개인 키를 탈취하지 않고 암호화폐 자금이 도난당하는 방법

2026년 11월 10일
6 min read
Key Insights
  • 신원 확인, 승인, 서명이 유효하더라도 결제의 전 과정에서 자금의 안전이 보장되지는 않습니다.

  • 공격자는 서명 전, 서명 중 또는 거래 실행 후에 권한 부여 및 결제 처리의 허점을 악용해 결제를 가로챌 수 있습니다.

  • 기관에는 전 과정에 걸친 검증, 직무 분리, 지속적인 모니터링, 서명된 거래를 무효화할 수 있는 수단이 필요합니다.

결제를 요청한 사람은 신원 확인을 통과했습니다. 결제는 승인되었고 거래 서명도 유효합니다. 그렇다면 자금은 안전할까요?

반드시 그렇지는 않습니다.

2025년에 BigONE은 약 2,700만 USD의 손실을 입었고, Bybit은 15억 USD 규모의 공격을 당했습니다. 2026년 10월에는 Binance가 약 63.4억 USD 상당의 디지털 자산에 영향을 미친 보안 사고를 보고했습니다. 이러한 사고는 개인 키를 안전하게 보관하는 것만으로는 자금의 안전을 보장할 수 없는 이유를 보여줍니다.

따라서 기관은 개인 키의 안전한 보관을 넘어 살펴봐야 합니다. 무엇을 근거로 결제가 정당화됩니까? 정확히 무엇에 서명합니까? 거래에 서명할 수 있는지 누가 결정합니까? 거래가 실행된 후에는 결제가 완료되었는지 시스템이 어떻게 판단합니까?

이 글에서 BlockSec은 공개적으로 보고된 사고를 통해 결제 개시부터 정산까지 전 과정에서 간과되기 쉬운 승인 위험을 살펴봅니다.

곧 공개할 기술 시리즈 안전한 보관을 넘어서에서는 두 가지 공격 경로를 자세히 살펴봅니다.

  • 개인 키를 확보하지 않고 시스템의 서명 기능을 악용하는 경로.

  • 암호화 구현의 결함을 악용해 개인 키를 복구하는 경로.

암호화폐 결제는 어디에서 가로채질 수 있을까요?

지갑을 통한 결제는 일반적으로 네 단계를 거칩니다.

  1. 결제 근거와 승인.

  2. 거래 구성과 검증.

  3. 서명 권한 부여와 키 사용.

  4. 실행과 정산.

1. 결제 근거와 승인

거래에 서명하기 전에 기관은 해당 결제가 정당한지 확인해야 합니다.

• 고객 출금의 경우, 플랫폼은 고객의 신원을 확인하고 자금이 충분한지 확인하며 요청이 업무 규칙에 부합하는지 점검해야 합니다.

• 내부 이체에도 적절한 자금 관리 승인이 필요합니다.

그러나 공격자가 계정 기록이나 위험 통제 로직을 변경할 수 있습니다. 그러면 시스템이 정상적인 절차를 따르면서도 결코 이루어져서는 안 될 결제를 승인할 수 있습니다.

예를 들어 2025년 7월 16일에 BigONE은 핫월렛 보안 사고를 공개했으며, 추정 손실액은 2,700만 USD였습니다. BigONE은 개인 키가 안전하게 유지되었다고 밝혔습니다. SlowMist의 조사에 따르면 공격자는 계정과 위험 통제에 관련된 서버 로직을 변경해 무단 이체를 가능하게 했습니다.

핵심은 결제를 승인하는 데 사용되는 정보와 규칙이 서명 전에 이미 변경되었다는 점입니다.

따라서 결제 기관은 요청이 내부 서비스에서 왔는지 확인하는 것만으로는 부족합니다. 각 결제는 독립적으로 검증할 수 있는 고객 지시나 자금 관리 결정까지 추적할 수 있어야 합니다. 또한 권한을 탈취당한 단일 계정으로 요청을 위조하고 기록을 변경하며 승인 규칙까지 바꿀 수 있는지 점검해야 합니다.

2. 거래 구성과 검증

화면에 보이는 내용이 정말 서명하려는 내용과 같습니까?

결제가 승인되면 시스템은 수신 주소와 금액 같은 업무 정보를 지갑이 서명할 수 있는 거래 데이터로 변환해야 합니다.

이 과정이 침해되면 화면에는 이체가 표시되지만, 실제로 서명을 위해 전달되는 거래는 지갑의 통제권을 가진 주체를 변경할 수 있습니다.

이 경우 이체를 승인한다고 생각하며 한 서명으로 공격자의 지갑 장악을 승인하게 될 수 있습니다.

2025년에 발생한 약 15억 USD 규모의 Bybit 공격은 이러한 위험을 보여줍니다. Bybit은 콜드월렛에서 웜월렛으로 ETH를 이체하려 했습니다. 공격자는 Safe 인터페이스를 침해해 악의적인 거래가 일상적인 이체처럼 보이게 했습니다. 서명자들은 지갑의 통제 로직 변경을 승인한다는 사실을 모른 채 거래를 승인했습니다.

공격자는 유효한 서명을 이용해 지갑의 통제 로직을 교체한 다음, 새 로직을 이용해 이후 출금 건마다 원래 소유자의 새 승인을 받지 않고 자산을 이동했습니다. 자세한 온체인 분석은 Bybit의 15억 USD 해킹에 대한 BlockSec의 분석을 참고하세요.

교훈은 분명합니다.

서명 전 검증은 서명 대상인 거래 전체와 그 실행 결과를 포괄해야 합니다. 인터페이스에 표시되는 내용에만 의존해서는 안 됩니다. 서명자가 여러 명이어도 모두 동일하게 침해된 화면에 의존한다면 문제를 발견하지 못할 수 있습니다.

이체, 지갑 업그레이드, 출금 권한 변경에는 각각 별도의 승인 요건도 적용해야 합니다. 일반 이체에 대한 승인을 지갑의 통제권을 변경하는 데 사용할 수 있어서는 안 됩니다.

3. 서명 권한 부여와 키 사용

누가 서명할 수 있고, 누가 서명 규칙을 변경할 수 있습니까?

공격자가 거래에 직접 서명할 수 없더라도 규칙을 변경하거나 시스템에서 실행되는 코드를 교체해 그에 준하는 통제권을 얻을 수 있습니다.

따라서 서명 키 접근을 관리하는 관리자 권한도 서명 권한 자체만큼 면밀히 검토해야 합니다.

Resolv이 공개한 2026년 3월 보안 사고 사후 분석에 따르면, 공격자가 처음에 시도한 서명 접근 권한 확보는 실패했습니다. 이후 공격자는 특권 역할을 이용해 키 접근 정책을 변경하고 자신에게 서명 권한을 부여했습니다. 공격자는 이 권한으로 두 건의 무단 거래를 통해 80 million USR를 발행했습니다.

또 다른 사고에 관한 Binance의 초기 사고 보고서는 서명 접근 권한을 얻는 다른 경로를 설명합니다. 공격자는 침해된 직원 기기와 내부 AI 도구를 이용해 지갑 엔지니어의 기기에 접근했습니다. 탈취한 컨테이너 배포 토큰을 사용해 컨테이너를 배포하고 악성 스크립트를 실행했습니다. 이후 내부 지갑 서명 서비스에 대한 무단 접근으로 거래가 정상적인 출금 절차를 우회할 수 있었습니다.

진입점은 달랐지만, 두 사고는 동일한 근본적인 문제를 드러냅니다.

키를 보호하려면 키 접근 정책을 변경하거나 서명 환경을 수정하거나 서명 권한을 부여할 수 있는 주체도 통제해야 합니다.

따라서 결제 기관은 다음 세 가지를 모두 살펴봐야 합니다.

  • 누가 서명 API를 호출할 수 있습니까?

  • 누가 해당 API를 호출할 권한을 부여할 수 있습니까?

  • 누가 서명 서비스를 배포하거나 수정할 수 있습니까?

업무 승인, 키 사용, 관리자 변경에 걸친 직무 분리도 특권 계정이 침해되었을 때 계속 효과적으로 작동해야 합니다.

4. 실행과 정산

거래에 서명하면 위험이 끝날까요?

반드시 그렇지는 않습니다. 기관은 서명된 거래가 언제 실행될 수 있고 어떻게 무효화할 수 있는지도 고려해야 합니다.

위험 1: 서명된 거래가 계속 실행 가능할 수 있습니다

거래에 서명했지만 아직 실행되지는 않았습니다. 나중에 제출해도 실행될 수 있을까요?

일부 메커니즘에서는 가능합니다. 근거가 된 업무 요청을 취소해도 서명된 거래가 자동으로 무효화되지는 않습니다.

2026년 4월 1일에 발생한 Drift Protocol 사고에서 공격자는 Solana의 durable nonce 메커니즘을 이용해 미리 서명된 거래를 일반 거래의 짧은 유효 기간 이후에도 유효하게 유지했습니다. 관련 nonce가 사용되거나 갱신되지 않은 한, 해당 거래는 나중에도 실행을 위해 제출될 수 있었습니다.

업무 요청이 취소되거나 의심스러운 활동이 탐지되면 기관은 서명되었지만 실행되지 않은 거래를 무효화하는 정해진 방법을 갖춰야 합니다. 누가 이를 수행할 권한이 있는지도 명시해야 합니다.

위험 2: 내부 이체를 잘못 해석해 추가 환불이 발생할 수 있습니다

2026년 9월 12일에 Chainflip은 Tron USDT를 이용한 공격을 당했습니다. 공격자는 검증자들이 이미 서명한 거래에 조작된 메모를 첨부했습니다. Chainflip 시스템은 이 메모를 별도의 스왑으로 잘못 해석하고, 해당 스왑이 실패한 것으로 처리해 환불을 지급했습니다. Chainflip은 총액이 약 73.64만 USDT에 달하는 무단 지급 6건을 보고했습니다.

온체인 이체가 반드시 새로운 고객 결제를 의미하거나 환불의 근거가 되는 것은 아닙니다. 결제를 하거나 환불을 지급하기 전에 시스템은 자금의 출처, 업무 작업의 유형, 해당 결제 의무가 이미 이행되었는지도 확인해야 합니다.

결제 시스템은 얼마나 견고합니까?

이 사례들은 서명 전에도, 서명 후에도 자금을 잃을 수 있음을 보여줍니다. 유효한 서명만으로는 다음을 입증할 수 없습니다.

• 결제에 정당한 업무상 근거가 있다는 것.

• 서명된 작업이 승인된 내용과 일치한다는 것.

• 결제 의무가 아직 이행되지 않았다는 것.

따라서 결제 기관에 의미 있는 보안 평가는 구체적인 질문에 답해야 합니다.

• 각 결제를 독립적으로 검증할 수 있는 업무상 근거까지 추적할 수 있습니까?

• 권한 변경이나 추가 거래를 포함해 서명 대상인 전체 작업이 승인된 내용과 일치합니까?

• 운영 또는 관리자 계정이 침해되더라도 무단 자금 이체를 차단하거나 제한하는 독립적인 통제 장치가 유지됩니까?

• 출금을 중단한 뒤에도 기존 서명과 온체인 승인 권한을 사용해 자금을 이동할 수 있습니까? 기관은 피해 확산 방지 조치가 효과적인지 어떻게 확인할 수 있습니까?

그러나 일회성 설정 검토만으로는 이러한 질문에 지속적으로 답할 수 없습니다.

소프트웨어 업데이트, 권한 변경, 업무 운영의 변화는 기존 보안 경계를 바꿀 수 있습니다. 기관은 이러한 변경 후에도 통제 장치가 계속 효과적인지 재평가해야 합니다.

AI 도구 역시 새로운 공격 표면을 만들 수 있습니다. 지속적인 모니터링은 팀이 의심스러운 활동을 탐지하는 데 도움이 됩니다. 사고 대응 훈련은 핵심 계정이나 운영 환경이 침해된 뒤 추가 자금 유출을 제한할 수 있는지 점검합니다.

이러한 위험의 평가에 관해 더 알아보려면 BlockSec의 Payment Security Solution이 AI 시대에 기관의 보안 유지에 어떻게 도움이 되는지 살펴보세요.

웨비나에 참여하세요: AI 시대의 자금 보호

이러한 질문을 살펴보기 위해 BlockSec은 온라인 웨비나인 "AI 시대의 자금 보호"를 개최합니다. 거래소와 결제 회사에서 최근 발생한 보안 사고를 바탕으로, 이번 세션에서는 공격자가 사람, 도구, 운영 환경을 통해 자금을 취급하는 시스템에 어떻게 접근하는지, 그리고 기관이 위협 탐지, 승인 확인, 사고 대응을 어떻게 개선할 수 있는지 살펴봅니다.

주요 연사:

• Yajin Zhou: 홍콩중문대학교 부교수; BlockSec 공동 창업자 겸 CEO

• Lei Wu: 저장대학교 부교수; BlockSec 공동 창업자 겸 CTO

• Muhui Jiang: BlockSec CSO

일시: 2026년 11월 11일 수요일, 오후 7:00 싱가포르 시간(SGT, UTC+8)

형식: 온라인 웨비나

참석 혜택: 세션 중 참여 기관 두 곳을 선정해 무료 예비 보안 평가를 제공합니다.

모든 결제를 보호하려면 위험을 조기에 파악하는 것이 필수적입니다.

결제 기관의 경영진, 보안 책임자, 기술팀을 초대해 결제 전 과정의 보안 사각지대를 함께 살펴보고자 합니다.

웨비나에 대해 더 알아보려면 영업팀에 문의하세요.


BlockSec 공식 웹사이트 방문>>>

X(Twitter)에서 팔로우하기>>>

Telegram에서 함께하기>>>

LinkedIn에서 팔로우하기>>>

YouTube 채널 구독하기>>>

제품 살펴보기>>>