A changed payTo address is not a honeypot: 272 payTo changes, 13 lookalikes, zero proof

개요

x402 프로토콜에서 동적 payTo 주소 변경 탐지 시스템이 272건의 주소 변경을 기록했지만, 실제로는 13건의 의심스러운 패턴만 식별되었으며, 이마저도 공격 증거가 아닌 설정 오류로 추정되었다.

주요 내용

- 탐지 시스템의 오류: x402에서 결제 요청마다 destination address가 변경될 수 있는 동적 payTo 스왑을 탐지하기 위해 Frisk의 호스팅 API를 통해 매일 공개 디렉토리를 크롤링하여 payTo 주소 변경을 기록하고 'honeypot:payto_swap' 레이블을 부여했다.
- 오탐의 범위: 약 한 달간 272건의 payTo 변경이 246개 엔드포인트에서 발생했으며, 이는 57건의 honeypot 레이블로 이어졌다. 그러나 탐지된 상위 엔드포인트인 x402.browserbase.com과 x402.tavily.com은 실제 운영 회사임에도 불구하고 'honeypot'으로 잘못 분류되었다.
- 오탐의 다섯 가지 이유:
1. 크롤링 주기 문제: 하루에 한 번 수행되는 크롤링이 엔드포인트의 실제 변경 빈도를 제대로 반영하지 못했다.
2. 주소 변경이 곧 공격 증거는 아님: 주소 변경 자체는 정상적인 지갑 교체, 자금 이체, 또는 공격일 수 있으므로, 이만으로는 악의적인 행위로 단정할 수 없다.
3. 단일 이벤트의 과대 해석: 109건의 주소 변경이 단일 업체의 대규모 자금 이체로 인한 것이었으나, 개별 엔드포인트 변경으로 과대 집계되었다.
4. 의심스러운 패턴의 오해: 13건의 변경은 매우 유사한 두 주소 간의 전환이었는데, 이는 공격보다는 설정 오류(오타)일 가능성이 높았다.
5. 파서의 오류: 여러 체인에서 동일한 리소스를 인용하는 경우, accept[0]에 해당하는 payTo 주소를 무작위로 선택하여 배열 순서 변경 시 주소 변경으로 오인했다.
- 실제 공격 탐지 가능성: 실제 동적 payTo 공격은 단일 요청 묶음 내에서 동일 레일에 대해 여러 주소를 제공하는 경우에 발생하며, 이를 탐지하기 위한 수정된 로직은 더 엄격한 시간 및 레일 조건을 적용한다.
- 수정된 탐지 로직:
- 주간(Intra-burst) 변경만 레이블로 승격시킨다.
- 스냅샷 간의 변경은 'promote: false'로 기록만 한다.
- 대규모 마이그레이션은 단일 관찰로 집계한다.
- 유사 주소(lookalike)는 별도 클래스로 관리한다.
- 기록되는 payTo는 결정론적으로 선택하여 배열 순서 변경으로 인한 오탐을 방지한다.
- 주간 탐지는 레일 인지 및 시간 제한을 두어 오탐을 줄인다.
- 데이터 삭제 및 교훈: 잘못 생성된 57건의 레이블을 삭제했으며, 관찰 결과가 그 자체로 주장을 뒷받침할 때만 평판 클레임을 승격시켜야 한다는 교훈을 얻었다.

시사점

주소 변경과 같은 단순한 관찰만으로는 평판 클레임을 생성해서는 안 되며, 특히 실제 공격으로 이어질 수 있는 복잡하고 맥락이 있는 증거를 기반으로 신중한 평가가 필요함을 보여준다.