서명된 권한 승인 50건, Binance 지갑 탈취로 이어지다

지갑이 탈취되면 최초 도난 이후에도 오랫동안 새로 입금되는 자금이 위험에 노출될 수 있습니다. 핵심은 공격자가 어떤 권한을 확보했으며, 그 권한이 여전히 유효한지입니다 (source: AnChain.AI).

서명된 권한 승인 50건이 어떻게 바이낸스 지갑 탈취로 이어졌을까요?

앤체인에이아이(AnChain.AI)의 재구성에 따르면, 서로 다른 계정 논스를 담은 서명된 권한 승인 50건이 바이낸스 14(Binance 14)로 표시된 지갑에 공격자가 제어하는 위임 코드를 설정하는 데 사용됐습니다. 논스가 일치하는 승인 항목을 통해 위임 코드가 설정됐으며, 이 과정이 이더리움(Ethereum)의 서명 검증 우회를 입증하는 것은 아닙니다. 유효한 서명 권한이 악의적인 계정 장악으로 이어질 수 있음을 보여줍니다 .

핵심 답변: 앤체인에이아이에 따르면, 서명된 권한 승인 50건을 담은 트랜잭션에서 승인 항목 하나가 바이낸스 지갑의 논스와 일치하면서 공격자가 제어하는 코드가 해당 지갑에 설정됐습니다. 여러 승인 항목을 묶은 것은 계정의 트랜잭션 카운터 값이 불확실한 상황에 대응하기 위한 것이었으며, 서명 검증을 우회한 것은 아닙니다. 이렇게 설정된 위임을 통해 이후 자금을 쓸어가는 스위퍼 호출이 가능해졌습니다 .

이더리움 개선 제안 7702(EIP-7702)의 위임은 서명 키로 제어하는 외부 소유 계정이 기존 주소를 유지하면서 지정된 스마트 계약 코드를 실행할 수 있도록 하는 기능입니다. 정상적인 활용 사례로는 여러 트랜잭션의 일괄 처리와 가스비 대납이 있습니다. 보안상 영향도 큽니다. 위임된 코드가 해당 계정의 실행 맥락에서 작동하므로, 이는 특정 토큰의 사용만 허용하는 권한이 아니라 계정 수준의 권한 승인에 해당합니다 (source: 이더리움 명세).

앤체인에이아이는 이더리움에서 일어난 과정을 다음과 같이 재구성했습니다.

• 위임 설정: 협정 세계시 기준 2026년 10월 29일 20시 20분 59초, 권한 승인 항목이 포함된 트랜잭션이 공격자의 스위퍼 계약을 바이낸스 14의 위임 대상으로 설정했습니다 .
• 스위퍼 호출: 협정 세계시 기준 20시 24분 23초, 후속 호출로 약 167,464.25 이더(ETH)와 16억 1,500만 테더(USDT)를 포함한 자금 이체가 실행됐습니다. 이 금액은 해당 과정에서 발생한 이체 규모이며, 사건 전체의 규모를 뜻하지 않습니다 .
• 단계 사이의 시간: 보고된 시각을 기준으로 보면, 위임이 설정된 지 3분 24초 뒤에 스위퍼가 호출됐습니다 .

논스는 트랜잭션과 권한 승인의 순서를 검증하는 데 쓰이는 계정 카운터입니다. 거래가 빈번한 지갑에서는 공격자가 트랜잭션 제출을 준비하는 동안에도 이 값이 바뀔 수 있습니다. 서로 다른 카운터 값으로 권한 승인에 서명하면 이러한 불확실성에 대응할 수 있습니다. 그중 값이 일치하는 항목이 논스 검사를 통과할 수 있기 때문입니다. 따라서 권한 승인 50건을 한꺼번에 담았다는 사실이 지갑 50개가 탈취됐거나 위임이 50번 성공했다는 뜻은 아닙니다 . 서명 검증은 여전히 적용됐으며, 논스를 달리한다고 해서 유효한 서명이 필요 없어지는 것은 아닙니다.

트랜잭션 증거로 위임이 이뤄진 순서는 확인할 수 있지만, 앤체인에이아이는 개인 키 도난과 서명 시스템 침해 중 어느 쪽이 원인이었는지는 구분할 수 없다고 밝혔습니다. 공격자가 어떻게 접근 권한을 얻었는지 밝혀지지 않았다는 점은 중요합니다. 공격자가 서명 권한을 유지하는 한, 악성 위임을 제거하더라도 정당한 소유자만 계정을 제어하는 상태를 되찾을 수 없기 때문입니다. 이더리움의 구현 지침은 위임 후에도 원래 계정 키가 최우선 권한을 유지한다고 설명합니다.

거래자는 계정 위임의 편의가 부여하는 권한에 비추어 타당한지, 승인할 때 어떤 통제 조치를 함께 적용해야 하는지, 위임 대상이나 서명 주체가 침해되면 어떻게 대응할지를 판단해야 합니다. 코드에 부여된 권한과 서명 시스템의 무결성은 각각 평가해야 합니다. 위임된 코드를 제거하는 일과 노출된 키의 보안을 확보하는 일은 서로 다른 문제를 해결하기 때문입니다.

바이낸스 사건에서 확인된 사실과 아직 풀리지 않은 의문은 무엇인가?

바이낸스(Binance) 사건의 증거는 여러 블록체인에 걸쳐 서명 권한이 침해됐으며, 이더리움(Ethereum) 공격에는 계정 위임도 사용됐음을 뒷받침한다. 하지만 최종적인 근본 원인이나 이더리움의 서명 검증 실패까지 입증하지는 않는다. 티알엠 랩스(TRM Labs)는 10개 블록체인의 지갑에서 약 63억 6,000만 달러가 유출됐다고 추산한다. 이는 조사 기관의 추정치이며, 최종 감사를 거친 손실액은 아니다 . 거래자에게는 이 구분이 중요하다. 관측된 자금 이체 내역, 접근 권한을 확보한 경위에 대한 분석, 최종 회수액은 각각 서로 다른 질문에 답하기 때문이다.

• 관측 범위와 집계 시점: 티알엠 랩스에 따르면 자금 유출 대부분은 협정 세계시 기준 2026년 10월 29일 20시 05분부터 약 20분 동안 발생했다. 관측은 협정 세계시 기준 10월 30일 00시 30분까지 이어졌으므로, 이 추정치는 해당 마감 시점까지 파악한 사건의 현황을 나타낸다 .
• 서명 접근 권한에 대한 분석: 티알엠 랩스는 바이낸스의 핫월렛 서명 인프라가 침해됐다고 판단한다. 별도로 해켄(Hacken)이 정리한 바이낸스의 조사 내용에는 개발·운영용 노트북의 침해 가능성, 서비스 컨테이너 접근, 이후 추가로 확인된 침입 지점이 언급돼 있다. 지갑 개인 키가 유출됐다는 증거는 발견하지 못했다는 바이낸스의 입장도 전한다. 그러나 이러한 설명만으로는 공격자가 키를 탈취했는지, 서명 시스템을 악용했는지, 여러 접근 경로를 조합했는지 확정할 수 없다.
• 계정 위임으로 설명할 수 있는 범위: 티알엠 랩스는 다른 9개 체인에서 일반적인 서명 이체가 발생했으며, 이더리움에서도 위임을 사용하지 않은 활동이 있었다고 보고한다 . 따라서 이더리움 개선 제안 7702만으로 침해 사건 전체를 설명할 수는 없다. 앤체인에이아이(AnChain.AI)의 사건 재구성 역시 거래 증거만으로는 개인 키 탈취와 서명 시스템 침해를 구별할 수 없다고 설명한다.
• 자산 동결과 회수의 차이: 티알엠 랩스는 집계 마감 시점까지 발행사와 네트워크의 개입으로 약 27억 달러가 동결됐다고 보고한다 . 동결은 자산의 이동을 제한하는 조치이며, 해당 자산이 사용자에게 반환됐음을 의미하지는 않는다. 동결액을 상환이 완료된 금액으로 취급하면 증거로 확인되는 회수 성과를 부풀리게 된다.

제목에 제시된 금액이 다를 때도 주의가 필요하다. 히든 이코노미(Hidden Economy)의 영상 제목에는 57억 달러라는 금액이 사용됐다 (영상: 히든 이코노미). 이 제목의 금액을 관측 범위가 명시된 티알엠 랩스의 추정치 대신 사용해서는 안 된다. 관측 기간을 고려하지 않고 금액만 비교하면, 서로 다른 시점의 현황을 담은 보고가 마치 같은 대상을 측정하고도 서로 다른 결과를 낸 것처럼 보일 수 있다.

공격 주체를 판단할 때도 같은 구분이 필요하다. 티알엠 랩스는 높은 확신을 바탕으로 바이낸스 공격의 배후를 북한의 트레이더트레이터(TraderTraitor)로 지목하지만, 이는 여전히 조사 기관의 판단이다. 미국 연방수사국(FBI)의 2025년 2월 26일 발표는 2월 21일경 바이비트(Bybit)에서 발생한 약 15억 달러 규모의 도난을 북한 트레이더트레이터의 소행으로 지목한다 . 해당 발표는 바이비트 사건에 관한 것으로, 미국 연방수사국이 바이낸스 공격의 배후를 확인해 준 것은 아니다.

실무적으로는 서명 접근 권한과 위임된 권한을 각각 따로 평가해야 한다. 키 유출의 증거가 없다고 해서 서명 시스템이 안전하게 유지됐다고 볼 수는 없다. 마찬가지로 악성 위임 코드를 발견했더라도 공격자가 유효한 승인을 어떻게 확보했는지는 설명되지 않는다. 어느 쪽의 조사 결과도 위임 해제만으로 서명 권한 침해에 대한 대응이 완료됐다고 판단할 근거가 되지는 않는다.

위임은 토큰 사용 승인이나 일반 전송과 어떻게 다를까요?

이아이피-7702(EIP-7702) 위임은 지갑 계정의 실행 환경에서 컨트랙트 코드를 실행할 권한을 부여합니다. 토큰 사용 승인은 특정 토큰을 옮길 권한을 사용 주체에게 부여하며, 일반 전송은 지속적인 접근 권한을 부여하지 않고 자산만 옮깁니다. 따라서 위임을 평가할 때는 위임된 코드가 이후의 명령을 어떻게 인증하는지 등 계정 차원의 동작을 살펴봐야 합니다. 외부 소유 계정(EOA)은 개인 키로 제어하는 계정입니다. 이더리움(Ethereum)의 펙트라(Pectra) 업그레이드는 2025년 5월 7일 협정 세계시 기준 10시 5분에 활성화되었습니다. 이 업그레이드로 외부 소유 계정이 기존 주소를 유지하면서도 트랜잭션 일괄 처리와 가스비 대납 같은 기능을 사용할 수 있는 위임 방식이 도입되었습니다 . 이는 편의성을 높이는 정상적인 기능입니다. 애플리케이션은 여러 작업을 한꺼번에 처리할 수 있고, 다른 계정이 거래 수수료를 대신 낼 수도 있습니다. 보안 측면에서 중요한 것은 어떤 구현체에 권한이 부여되며 그 구현체가 어떤 제한을 적용하느냐입니다. (source: 이더리움의 펙트라 개요 및 위임 명세.)

아래 표는 이미 완료된 자산 이동과 계속 유효한 권한을 구분합니다. 단순 전송에서는 수신 주소를 확인하는 것이 적절하지만, 위임 대상을 검토할 때는 실행 가능한 동작과 접근 제어 방식을 이해해야 합니다.

이러한 계정 차원의 차이와 위임 해제 방식은 명세에 규정되어 있습니다. 앤체인에이아이(AnChain.AI)의 사고 분석은 이 차이가 자산 보호에 왜 중요한지 설명합니다. 권한을 철회할 때는 실제로 부여된 권한을 대상으로 해야 합니다. 토큰 사용 승인 관리와 위임 관리는 서로 다른 권한을 다룹니다.

악성 위임 코드는 계정 자체의 권한으로 실행되므로, 별도의 토큰 사용 승인을 받지 않고도 계정의 자산을 옮길 수 있습니다. 토큰을 전송할 때 해당 계정은 승인 한도를 이용하는 외부 사용 주체가 아니라 토큰 보유자로서 동작할 수 있습니다. 그렇다고 모든 정상적인 위임 대상이 무제한 실행을 허용한다는 뜻은 아닙니다. 제대로 설계된 구현체는 명령을 인증하고 허용되는 동작을 제한합니다. 권한 부여 서명은 위임 대상을 설정하는 역할을 합니다. 이를 이후에 누구나 임의의 동작을 실행해도 된다는 허가로 취급해서는 안 됩니다. (source: 위임 보안 고려 사항 및 앤체인에이아이.)

위임이 지속된다는 점은 첫 도난 이후의 위험에도 영향을 줍니다. 악성 위임 설정이 남아 있으면 이후 입금되는 자산에도 같은 코드가 접근할 수 있습니다. 토큰 사용 승인을 철회하는 것만으로는 해당 코드가 제거되지 않으므로, 사용 승인 내역만 검토해서는 그 계정에 안전하게 자산을 입금할 수 있다고 판단할 수 없습니다. 위임을 해제하거나 교체하면 설정된 권한을 처리할 수 있지만, 서명 주체를 여전히 신뢰할 수 있는지는 별개의 문제입니다. (source: 앤체인에이아이의 위임 분석.)

원래 개인 키에는 여전히 위임된 코드보다 우선하는 권한이 있습니다. 이더리움의 구현 지침에 따르면, 다중 서명 방식의 정책을 적용한 코드에 위임하더라도 원래 개인 키로 그 정책을 우회할 수 있는 능력은 사라지지 않습니다. 개인 키와 위임 대상을 함께 평가해야 합니다. 안전한 코드도 이미 탈취된 원래 서명 주체의 위험을 없앨 수 없으며, 개인 키를 철저히 보관하더라도 악성 위임 코드의 동작까지 안전해지는 것은 아닙니다. 실행 규칙과 원래 개인 키의 보관 방식이 모두 보유하려는 자산에 적합할 때만 위임을 선택하세요.

어떤 사항을 확인한 뒤 EIP-7702 권한 부여에 서명해야 할까요?

요청한 애플리케이션, 위임받을 코드의 구현 방식, 적용되는 체인의 범위, 계정 수준의 권한이 필요한 이유를 이해한 경우에만 EIP-7702 권한 부여에 서명하세요. 예상하지 못했거나 설명이 없는 요청을 받으면 진행을 멈추고, 공식 채널에 직접 접속해 확인하세요. 티알엠 랩스(TRM Labs)는 예상하지 못한 서명 요청을 거부할 것을 권고합니다. 이더리움(Ethereum)의 구현 지침도 악의적인 위임으로 계정의 자산이 위험에 노출될 수 있다고 경고합니다. 익숙한 화면이라는 이유만으로 승인해서는 안 됩니다.

1. 애플리케이션과 수행하려는 작업을 확인하세요. 수수료 대납 활성화, 여러 작업의 일괄 처리, 지갑 기능 설정 등 지갑에서 무엇을 하려는지 적어 보세요. 해당 작업에 위임이 필요한 이유를 확인하세요. 요청이 갑자기 나타나거나 설명이 의도한 작업과 맞지 않으면, 우선 거부한 뒤 확인하세요. 급박한 거래 기회 때문에 어떤 권한을 부여하는지 파악하는 과정을 건너뛰지 마세요.
2. 위임 대상 주소와 구현 코드를 살펴보세요. 선택한 네트워크에 대한 지갑 제공업체의 공식 문서와 전체 주소를 대조하세요. 실제 배포된 구현 코드와 실행 통제 장치를 검토한 보안 검토 자료를 찾아보세요. 주소가 일치한다는 것은 대상이 맞다는 뜻일 뿐, 안전하다는 뜻은 아닙니다. 익숙한 브랜드라고 해서 코드가 접근을 올바르게 제한한다고 볼 수는 없습니다. 이더리움의 위임 위험 관련 지침도 구현 품질을 계정 보안의 핵심으로 다룹니다.
3. 체인 식별자와 논스를 확인하세요. 권한 부여 서명에는 체인 식별자, 위임 대상 주소, 논스(nonce)가 포함됩니다. 체인 식별자가 0이면 검증 조건이 맞는 다른 지원 체인에서도 권한 부여가 받아들여질 수 있습니다. 특정 체인의 식별자를 지정하면 적용 범위가 해당 체인으로 제한됩니다. 처리 시점에는 논스가 권한을 부여하는 계정의 논스와 일치해야 합니다 . 예상하지 못한 논스 묶음이 제시되면 설명을 요청하세요. 명세에 따르면 권한 부여가 포함된 트랜잭션은 다른 계정이 제출할 수도 있으므로, 제출자의 주소만으로 안전성을 판단할 수 없습니다.
4. 해당 권한이 꼭 필요한지 판단하세요. 계정의 실행 방식을 바꿀 만한 명확한 이점이 있어야 합니다. 애플리케이션이 그 이점과 이후 사용을 제한하는 통제 장치를 설명하지 못한다면, 위임 없이 진행할 수 있는 방식을 선택하세요. 편리함은 기능을 검토할 이유이지, 검토를 생략할 이유가 아닙니다.

코드를 선택하는 것과 그 코드가 나중에 수행할 작업을 허용하는 것은 구분해서 살펴봐야 합니다. 명세 작성자들은 보안 고려사항에서 다음과 같이 설명합니다.

“위임받는 코드는 재실행 방지 장치(예: 논스)를 구현해야 하며, 해당 장치의 값도 서명 대상에 포함해야 합니다.” — EIP-7702 명세 작성자, 이더리움 개선 제안.

명세의 보안 요구사항을 바탕으로 지갑 제공업체에 다음 통제 장치가 구현되어 있다는 근거를 요청하세요.

• 이후 실행의 권한 인증: 위임 설정 후 누가 호출을 승인할 수 있는지 확인하세요.
• 실행 매개변수 보호: 의도한 대상 주소, 호출 데이터, 전송 금액, 가스가 다른 값으로 바뀌지 않도록 보호해야 합니다.
• 초기화 보호: 설정 지시를 인증해, 이를 지켜보는 제삼자가 먼저 실행하여 공격자가 통제하는 설정을 적용하지 못하게 해야 합니다.
• 재실행 방지: 실행 서명을 재사용해 같은 효과를 반복해서 발생시킬 수 없는지 확인하세요.
• 저장소 호환성 확인: 위임 대상을 바꾸기 전에 새 코드가 기존 계정 저장소를 어떻게 해석하는지 검토하세요.

이는 구현 코드의 유지관리자와 검토자에게 물어볼 사항이지, 모든 거래자에게 계약 코드를 직접 감사하라는 뜻이 아닙니다. 지갑 측에서 이해하고 검증할 수 있는 답변을 제공하지 못한다면 서명을 미루세요. 위임의 목적과 범위, 실행 보호 장치가 명확하고, 위험에 노출되는 자산 규모를 고려해도 충분히 납득할 수 있을 때만 위임을 승인하세요.

거래 방식과 보안 요구에 맞는 지갑 구성은 무엇일까요?

적합한 지갑 구성은 서명 권한을 직접 통제하는지, 위임 기능이 필요한지, 위험에 노출되는 자산을 제한할 수 있는지에 따라 달라집니다. 자기 수탁 지갑을 가끔 쓰는 사용자는 위임을 승인하기 전에 이점이 분명한지 확인해야 합니다. 자주 거래하는 사용자는 위임 대상의 통제 장치, 잔액, 서명 권한 분리를 함께 검토해야 합니다. 거래소만 이용하는 고객은 수탁 방식에 맞는 점검이 필요하고, 자금 운용 담당자는 기반 시스템의 통제 장치를 살펴야 합니다. 아래 권고는 이더리움 개선 제안 7702(EIP-7702) 명세, 이더리움(Ethereum) 구현 지침, 티알엠 랩스(TRM Labs)의 사고 분석에 제시된 보안 지침을 실제 상황에 적용한 것입니다.

지갑을 가끔 쓰는 사용자라면 권한을 허용할 만큼 편의성이 큰지 따져야 합니다. 불필요한 위임 요청을 거절하면 해당 승인 경로는 차단할 수 있지만, 피싱이나 악의적인 일반 거래, 서명 권한 침해까지 막을 수는 없습니다. 위임 후에도 원래 계정 키에는 위임된 권한보다 우선하는 권한이 남습니다. 공격자가 이 키로 위임 대상의 지출 정책을 우회할 수 있다면 그 정책은 보호 수단이 되지 못합니다. 이더리움 구현 지침은 보안 기능을 선택할 때 이러한 차이를 고려해야 한다고 설명합니다.

활발하게 거래하는 사용자에게 거래 전용 지갑은 위험에 노출되는 자산을 제한하는 실용적인 방법입니다. 다만 예비 자금에 대한 서명 권한이 실제로 분리되어 있어야 합니다. 악성 위임 코드가 있는 계정에 가치 있는 자산이 계속 입금된다면 현재 잔액이 적다는 것만으로는 충분히 보호받을 수 없습니다. 위임 대상의 실행 보호 장치, 예상 유입 자산, 서명 권한에 대한 접근을 함께 검토해야 합니다. 지속되는 위임 권한과 실행 인증은 명세에서도 핵심 보안 고려 사항으로 다뤄집니다.

거래소 고객은 일반적으로 자신의 거래소 계정을 통해 자금 관리 지갑의 권한을 확인하거나 철회할 수 없습니다. 공개 블록체인을 조회할 수 있다고 해서 서명 권한까지 주어지는 것은 아닙니다. 고객이 직접 확인할 수 있는 것은 진위가 확인된 입금 안내와 사고 공지입니다. 개인 지갑에 연결한 토큰 승인 관리 도구로는 거래소가 통제하는 서명 주체를 변경할 수 없습니다. 앤체인 에이아이(AnChain.AI)의 사고 재구성이 다루는 것은 거래소 블록체인 계정의 권한이며, 이는 고객 로그인과는 통제 범위가 다릅니다.

자금 운용 담당자에게 티알엠 랩스는 체인과 지갑 등급별 격리, 예상치 못한 위임 변경 알림, 여러 논스에 걸친 승인 묶음 탐지, 검증된 권한 철회 절차를 권고합니다. 위임 모니터링은 지속되는 실행 권한의 위험을 관리하고, 서명 주체 격리는 수탁 시스템 전반으로 침해가 확산되는 것을 제한합니다. 두 가지를 모두 적용할 수 있는 구성을 선택해야 합니다. 공격자가 여전히 서명 권한에 접근할 수 있다면 위임 코드를 제거해도 독점적인 통제권을 되찾을 수 없기 때문입니다.

지갑에서 예상치 못한 위임이 발견되면 어떻게 해야 할까요?

예상치 못한 위임이 발견되면 복구에 앞서 피해 확산을 막고 서명 권한이 누구에게 있는지 확인해야 합니다. 낯선 서명 요청에 응하지 말고, 입금을 중단한 뒤 신뢰할 수 있는 도구로 계정에 위임된 코드를 점검하세요. 원치 않는 코드를 제거하면 위임된 코드의 실행은 막을 수 있지만, 계정 통제권을 온전히 되찾을 수 있는지는 다른 사람이 여전히 해당 계정으로 서명할 수 있는지에 달려 있습니다. 이더리움(Ethereum)의 위임 안내에 따르면 원래 계정 키에는 다른 권한보다 우선하는 권한이 유지됩니다 .

1. 낯선 요청을 더 이상 승인하지 마세요. 복구나 확인 절차를 명목으로 제시된 예상치 못한 권한 부여 요청에는 서명하지 마세요. 신뢰할 수 있는 경로로 지갑의 지원 문서에 접속하세요. 티알엠 랩스(TRM Labs)는 예상치 못한 위임 요청을 거절하고, 미리 시험해 둔 위임 철회 절차를 마련해 둘 것을 권고합니다.
2. 영향을 받은 주소에 추가로 입금하지 마세요. 계정 통제권이 불확실한 동안에는 예정된 입금의 수신 주소를 다른 주소로 변경하세요. 티알엠 랩스는 2026년 10월 29일 사건 이후 바이낸스(Binance)에 새로 입금된 자금도 잇따라 탈취됐다고 보고했습니다 . 이를 추가 입금을 중단해야 할 근거로 받아들이고, 복구 방법을 먼저 검토하지 않은 채 가스비를 충전하려는 시도도 삼가세요.
3. 현재 위임 상태를 점검하세요. 신뢰할 수 있는 도구로 위임이 존재하는지 확인하고, 위임 대상 구현체를 식별한 뒤 영향을 받은 체인을 살펴보세요. 애플리케이션 연결이 끊어졌다고 해서 위임된 코드까지 제거됐다는 뜻은 아닙니다. 앤체인에이아이(AnChain.AI)의 사건 재구성에서 설명하듯 위임은 교체하거나 해제할 때까지 유지됩니다.
4. 원래 키와 서명 환경을 점검하세요. 오해를 유도하는 요청 때문에 권한을 부여한 것인지, 기기나 키 또는 서명 서비스 자체가 침해됐을 가능성이 있는지 검토하세요. 앤체인에이아이는 거래 내역만으로는 개인 키 탈취와 서명 시스템 침해를 구분할 수 없다고 설명합니다. 낯선 위임이 있다는 사실은 조사가 필요한 문제가 있음을 보여 주지만, 공격자가 어떤 경로로 접근했는지까지 알려 주지는 않습니다.

적절한 권한 부여 방식으로 위임을 해제하세요. 이더리움 개선 제안 7702(EIP-7702)에 따르면 영 주소를 가리키는 유효한 권한 부여로 위임을 해제할 수 있습니다 . 이는 토큰 사용 승인을 철회하거나 애플리케이션 연결을 끊는 것과는 별개입니다. 프로토콜은 해제 방식만 규정하며, 모든 지갑에서 공통으로 쓸 수 있는 복구 화면을 제공하지는 않습니다. 필요한 작업을 지원하는 구현체의 신뢰할 수 있는 문서를 따르고, 작업 후 계정 상태를 확인하세요.

서명 권한의 통제 여부에 따라 복구 방법을 선택하세요. 서명 권한을 여전히 본인만 통제한다면 악성 위임을 해제하거나 교체해 해당 위임 코드를 통한 공격 경로를 차단할 수 있습니다. 공격자가 키나 서명 접근 권한을 계속 보유하고 있다면 위임 해제만으로는 독점적인 통제권을 되찾을 수 없습니다. 공격자가 다른 위임을 승인하거나 자금 이체에 서명할 수 있기 때문입니다. 원래 키의 권한을 유지하는 이더리움의 구조를 고려하면, 대체 계정에는 기존 환경과 독립적으로 보호되는 서명 수단을 사용해야 합니다.

남아 있는 권한과 계정 상태를 확인하세요. 위임을 변경해도 기존 계정 저장소는 지워지지 않으며, 이전에 부여한 토큰 사용 승인도 별도로 검토해야 합니다. 명세의 보안 고려 사항에서는 위임 변경 시 저장소 충돌이 발생할 수 있다는 점도 지적합니다. 공격자의 접근 가능성이 남아 있는 동안에는 복구 과정에도 공격자가 개입할 수 있다고 보고 대응하세요. 위임 해제 거래가 성공했다는 사실만으로는 서명 수단이 안전하다거나 원치 않는 권한이 다시 설정될 수 없다고 판단하기에 충분하지 않습니다.

설정 후 EIP-7702 보안 점검표에는 무엇을 포함해야 할까요?

EIP-7702 보안 점검표에는 계정을 대신해 작업하도록 승인된 코드와 그 승인을 변경할 수 있는 서명 주체를 기록하고 추적해야 합니다. 권한을 위임한 뒤에도 보안 관리는 계속 필요합니다. 원래 계정 키가 최우선 권한을 유지하므로, 신뢰할 수 있는 위임 대상이라도 서명 주체의 보안 취약성을 보완할 수는 없습니다 (source: 이더리움(Ethereum) 구현 지침).

개인 지갑을 사용한다면 다음 항목을 정기적인 계정 관리에 포함하세요.

• 설정 기준을 기록하세요. 위임 대상 주소, 사용 목적, 승인한 체인 범위를 지갑 기록과 함께 보관하세요. 이후 요청은 이 기준과 비교하세요.
• 위임 변경을 모니터링하세요. 낯선 위임 대상이 나타나거나 이유를 알 수 없는 교체가 발생하면 계정을 계속 사용하기 전에 원인을 조사하세요.
• 새로운 서명 요청을 모두 검토하세요. 요청의 대상과 범위가 자신이 시작한 작업과 일치하는지 확인하세요. 익숙한 애플리케이션의 이름이나 로고만으로는 승인이 안전하다고 판단할 수 없습니다.
• 검증된 위임 해제 절차를 준비하세요. 영 주소를 대상으로 하는 승인을 통해 지갑에서 위임을 해제하는 방법을 알아두세요 (source: EIP-7702 명세).
• 계정 동작이 달라지면 서명 주체도 다시 점검하세요. 예상하지 못한 계정 활동이 발생하면 위임 대상뿐 아니라 서명 장치, 연결된 소프트웨어, 접근 경로도 함께 검토해야 합니다.

인프라 운영자는 서명 시스템에 추가 통제를 적용해야 합니다. 티알엠 랩스(TRM Labs)는 체인과 지갑 등급별로 서명 인프라를 분리하고, 자금 관리 계정의 위임 변경을 모니터링하며, 검증된 권한 철회 절차를 유지할 것을 권고합니다. 이러한 통제를 실제 대응으로 이어지는 경보로 구체화하세요.

• 예상하지 못한 승인 요청: 누가 요청을 시작했는지, 그 목적이 승인되었는지 조사하세요.
• 많은 논스 값을 포함한 일괄 요청: 요청의 출처와 의도한 실행 내용을 살펴보세요. 범위가 이례적으로 넓다면 검토가 필요합니다.
• 자금 관리 계정의 위임 변경: 각 변경이 승인된 운영 작업과 일치하는지 확인하세요.
• 사고 후 새 입금액의 일괄 이체: 원치 않는 실행 권한이나 서명 주체에 대한 접근 권한이 여전히 활성화되어 있는지 조사하세요.

각 경보는 조사할 필요가 있지만, 어느 하나만으로 도난이 입증되지는 않습니다. 결론을 내리기 전에 서명 기록, 트랜잭션 동작, 승인된 업무 절차와 대조하세요.

보고된 일련의 서명된 승인 50건은 이미 탈취된 서명 권한이 어떻게 지속적인 위임 실행 권한으로 이어질 수 있는지 보여줍니다 . 앤체인에이아이(AnChain.AI)의 사건 재구성만으로는 공격자가 개인 키를 확보했는지, 서명 시스템에 대한 접근 권한을 얻었는지 확인할 수 없습니다. 따라서 위임된 코드가 무엇을 할 수 있는지와 누가 여전히 변경을 승인할 수 있는지를 함께 평가해야 합니다.

근거 확인 기준일: 2026년 11월 2일. 감사를 거친 손실액, 확인된 최초 침입 방식, 수정된 공격 주체 판단, 동결 자산이 반환되었다는 증거 등이 나오면 내용을 갱신해야 합니다. 티알엠 랩스, 앤체인에이아이, 해켄(Hacken)의 설명에서는 이러한 사항이 아직 확정되지 않았습니다.

위임 설정 기준과 해제 지침은 쉽게 확인할 수 있는 곳에 보관하세요. 계정 동작이 그 기준에서 벗어나면 새로운 서명을 중단하고, 위임 대상과 서명 주체를 모두 조사한 뒤 정상적인 사용을 재개하세요.

자주 묻는 질문

바이낸스 사건은 EIP-7702가 서명 검증을 우회한다는 사실을 입증했나요?

아닙니다. 앤체인에이아이의 사건 재구성에 따르면 서로 다른 계정 논스를 가진 서명된 승인 50건이 사용되었으며, 그중 조건에 맞는 승인이 공격자의 위임 대상을 설정했습니다 . 여러 논스 값을 사용한 것은 지갑의 트랜잭션 카운터를 정확히 알 수 없는 상황에 대비하기 위해서였습니다. 서명 검증을 우회한 것은 아니며, 트랜잭션 증거만으로는 개인 키 도난과 서명 시스템 침해를 구분할 수 없습니다.

바이낸스의 보고된 손실액은 57억 달러인가요, 63억 6천만 달러인가요?

히든 이코노미(Hidden Economy) 영상 제목에는 57억 달러라고 나옵니다 . 티알엠 랩스는 협정 세계시 기준 2026년 10월 30일 00시 30분까지 관측한 내용을 바탕으로 유출액을 약 63억 6천만 달러로 추산했습니다 . 어느 수치도 감사를 거친 최종 손실액으로 보아서는 안 됩니다. 동결 자산은 별도 항목이며, 사용자에게 반환된 자금으로 계산해서는 안 됩니다.

토큰 사용 승인을 철회하면 EIP-7702 위임도 해제되나요?

아닙니다. 토큰 사용 허용량과 계정 위임은 별개의 권한입니다. 사용 승인을 철회해도 위임된 코드는 제거되지 않습니다. EIP-7702 명세에서는 영 주소를 가리키는 유효한 승인으로 위임을 해제합니다. 기반이 되는 키나 서명 시스템이 여전히 침해된 상태라면 위임 해제만으로 독점적인 통제권을 되찾을 수 없습니다. 공격자가 여전히 트랜잭션을 승인하거나 다른 위임 대상을 설정할 수 있기 때문입니다.

EIP-7702 승인은 여러 체인에 적용될 수 있나요?

네, 체인 식별자에 따라 가능합니다. EIP-7702 명세에 따르면 체인 식별자가 0인 승인은 나머지 검증 조건이 충족될 경우 이를 지원하는 다른 체인에서도 수락될 수 있습니다 . 그렇다고 모든 체인에서 자동으로 실행되는 것은 아닙니다. 해당 승인은 관련된 각 체인에 제출되어 검증을 받아야 합니다.

다중 서명 방식의 코드에 위임하면 외부 소유 계정 키가 도난당해도 보호받을 수 있나요?

위임된 다중 서명 방식의 통제가 원래 외부 소유 계정(EOA) 키의 권한을 없애지는 않습니다. 이더리움 구현 지침에 따르면 원래 키는 최우선 권한을 유지하며 위임된 정책을 우회할 수 있습니다. 위임된 코드가 구현하는 승인 규칙과 별개로, 기반이 되는 서명 주체의 보호 수준을 평가하세요.