Name.com, 최소 12개 DeFi 프런트엔드 공격 후 탈취된 도메인 복구

이 사건은 DeFi가 전통적인 인터넷 인프라에 의존하는 데 따른 취약성을 부각시키며, 도메인 관리에 대한 보안 강화를 촉구한다.

사진: Rostislav Uzunov / Pexels
등록기관은 영향을 받은 모든 도메인이 복구되었다고 밝혔지만, 보고에 따르면 지갑 탈취 캠페인이 먼저 사용자들로부터 약 $138,000을 빼앗았다
2026년 10월 31일 토요일 · 15:54 EDT · 3분 읽기
금융 부문에서
공유
Name.com은 해커들이 Vercel과 연관된 10개를 포함해 15개의 고객 도메인을 탈취했다고 밝혔다. 영향을 받은 도메인은 모두 현재 복구되었다.
좋은 소식입니다. 덜 좋은 소식은 탈취된 주소가 암호화폐 사용자들을 지갑을 비우도록 만들어진 악성 페이지로 유도했다고 보도되었다는 점입니다.
해당 캠페인은 2026년 10월 30일부터 31일 사이에 진행되었다. 이는 최소 12개의 탈중앙화 금융 프로젝트 웹사이트를 공격했으며, 온체인 손실은 약 $138,000으로 추정된다.
공격은 어떻게 작동했는가
도메인 이름을 상점 간판에 적힌 주소라고 생각해 보세요. DNS은 해당 간판이 실제로 가리키는 건물이 어디인지 브라우저에 알려주는 시스템입니다.
등록기관, 즉 그 기록을 관리하는 회사에 누군가가 침입하면, 그들은 조용히 건물을 바꿔치기할 수 있다. 간판은 똑같아 보인다. 당신은 그냥 걸어 들어간다.
여기서 일어난 일이 대략 그렇습니다. 방문자들은 익숙한 DeFi URL을 입력했지만 공격자가 통제하는 유사 페이지로 연결되었습니다.
해당 페이지들은 Step Drainer라는 도구를 실행했습니다. 이 도구는 사용자들이 승인할 의도가 없었던 거래에 서명하도록 속였고, 그 결과 지갑이 탈취되었습니다.
그 구분은 중요하다. 표적이 된 프로젝트 배후의 스마트 계약은 사건 전 과정에서 온전하게 유지되었으며 훼손되지 않았다.
모든 표적 도메인은 Name.com을 통해 등록되었다. 등록 기록에 따르면 10개의 도메인은 복구되기 전 'client hold' 상태에 놓였으며, 이 상태는 도메인이 일시적으로 전혀 확인되지 않도록 한다.
누가 무엇을 확인했는가
Name.com은 도메인이 부적절하게 리디렉션되었다는 사실을 공개적으로 인정했습니다. 등록기관은 도메인을 복원하는 한편, 고객들에게 DNS 설정을 검토하고 2단계 인증을 활성화할 것을 당부했습니다.
DeFi 프로젝트 Flap과 Kintsu는 공격이 등록기관 수준에서 발생했다고 확인했습니다. 보안 업체 Blockaid도 같은 입장을 밝혔습니다.
일부 팀은 네임서버를 Vercel이나 Cloudflare 같은 호스팅 서비스로 이전하여 피해를 제한하는 데 성공했습니다.
공격자들이 정확히 어떻게 등록기관 계층에 침입했는지는 여전히 알려지지 않았다. 조사관들은 침입 경로를 규명하기 위해 계속 노력하고 있다.
왜 프런트엔드는 계속 취약한 지점으로 남는가
DeFi는 무신뢰 시스템에 대해 이야기하는 것을 좋아합니다. 코드는 법이고, 계약은 불변이며, 어떤 중개자도 당신의 자금을 동결할 수 없습니다.
하지만 해당 코드에 접근하는 데 사용하는 웹사이트는 여전히 확실히 구식 인터넷 기반 시설 위에서 운영됩니다. 도메인 등록업체, DNS 레코드, 계정 로그인이 바로 그 중심에 있습니다.
이번 사건은 그 간극을 명확히 보여주는 사례다. 계약은 제 역할을 완벽히 수행했지만, 사용자들은 여전히 돈을 잃었다.
보안 전문가들은 이를 공급망 공격이라고 부른다. 공격자들은 표적을 직접 공격하는 대신, 많은 표적이 의존하는 공유 벤더를 침해한다.
DeFi 팀과 사용자에게 이것이 의미하는 바
사용자 입장에서 보면, 이 달러 금액은 암호화폐 해킹 기준으로 볼 때 크지 않다. 약 $138,000은 9자리 수 브리지 익스플로잇이 아니다.
더 불편한 점은 신중한 사용자가 할 수 있었던 일이 얼마나 적었는가이다. URL은 올바른 것이었고, 페이지도 제대로 보였다. 유일한 실질적 방어책은 서명하기 전에 거래 프롬프트를 꼼꼼히 읽는 것뿐이었다.
이는 지갑 수준의 경고와 트랜잭션 시뮬레이션에 다시금 무게를 실어 줍니다. 블록에이드가 이번 공격 확인에 참여했다는 점은 이러한 도구가 점점 더 사용자와 악의적인 서명 사이에 자리하고 있음을 상기시켜 줍니다.
프로젝트 팀에게 주는 교훈은 코드 감사보다 운영 위생에 더 가깝다. Name.com 자체의 조언인 DNS 설정 확인과 2단계 인증 활성화는 기본적인 것이지만, 이 사슬의 어딘가에서 실패한 것은 바로 그 기본이었다.
네임서버를 신속하게 이전한 팀들이 더 나은 결과를 얻은 것으로 보인다. 이는 사고 대응 계획에 스마트 계약 일시정지 버튼뿐만 아니라 등록기관 대응 매뉴얼도 포함해야 함을 시사한다.
미해결된 문제는 근본 원인이다. 이것이 내부 시스템 침해였는지, 고객 자격 증명 도난이었는지, 아니면 다른 무언가였는지에 따라 다른 등록기관과 그들의 암호화폐 고객이 얼마나 심각하게 대응해야 할지가 결정될 것이다.
조사관들이 그 답을 내놓기 전까지, 단일 등록기관에 의존하는 DeFi 팀들은 자신들의 도메인 계정을 배포자 키에 쏟는 것과 같은 수준의 편집증적 경계심으로 대해야 할 것이다.
공개: 이 기사는 John Chen이 편집했습니다. 콘텐츠 제작 및 검토 방식에 대한 자세한 내용은 편집 정책을 참조하세요.