기술 상세 분석: 체인상에서의 신규 프로젝트 투자 속임수, 대규모 러그풀(rug pull) 수법 해부

2024.03.18

기술 상세 분석: 체인상에서의 신규 프로젝트 투자 속임수, 대규모 러그풀(rug pull) 수법 해부

이 글에서는 그 중 한 사례를 들어 해당 탈퇴 사기의 세부 내용을 자세히 설명한다.

2024.03.18 - 15:56:40

Web3 심층 보도에 집중하고 흐름을 통찰

이 글에서는 그 중 한 사례를 들어 해당 탈퇴 사기의 세부 내용을 자세히 설명한다.

글: CertiK

최근 CertiK 보안 전문 팀은 동일한 수법의 '이탈 사기(Rug Pull)'를 반복적으로 포착했습니다.

심층 조사를 통해 이와 유사한 여러 건의 사건들이 모두 동일한 범죄 조직과 연결되어 있으며, 최종적으로 200개 이상의 토큰 이탈 사기와 연관된다는 사실을 확인했습니다. 이는 대규모 자동화 시스템을 통해 '이탈 사기' 방식으로 자산을 수확하는 해커 그룹의 존재를 시사합니다.

이러한 이탈 사기에서 공격자는 새로운 ERC20 토큰을 생성하고, 미리 채굴해 둔 토큰과 일정량의 WETH로 Uniswap V2 유동성 풀을 구성합니다.

체인 상의 신규 상장 매수 로봇이나 사용자가 해당 유동성 풀에서 일정 횟수 이상 신규 토큰을 구매하면, 공격자는 공중에서 생성된 토큰을 이용해 유동성 풀 내의 WETH를 완전히 소진시킵니다.

공격자가 무작위로 생성한 토큰은 총 공급량(totalSupply)에 반영되지 않으며 Transfer 이벤트도 발생시키지 않기 때문에 Etherscan에서는 이를 확인할 수 없어 외부에서 감지하기 어렵습니다.

공격자들은 은폐성뿐만 아니라 숨겨진 함정도 설계하여, 기초적인 기술력을 갖추고 Etherscan을 확인할 줄 아는 사용자들을 안심시키며 진짜 목적을 가립니다...

사기 수법 심층 분석

하나의 사례를 통해 이 이탈 사기의 세부 내용을 자세히 살펴보겠습니다.

우리가 포착한 것은 공격자가 거액의 토큰(비밀리에 민팅된 것)을 이용해 유동성 풀을 고갈시키고 수익을 얻은 트랜잭션입니다. 이 트랜잭션에서 프로젝트팀은 약 416조 개의 MUMI 토큰을 사용해 약 9.736개의 WETH를 교환하며 유동성 풀을 완전히 고갈시켰습니다.

하지만 이 거래는 전체 사기의 마지막 단계일 뿐이며, 전체 과정을 이해하려면 더 이전으로 거슬러 올라가야 합니다.

토큰 배포

3월 6일 오전 7시 52분(UTC 기준, 아래 동일), 공격자 주소(0x8AF8)는 Rug Pull로 MUMI(MultiMixer AI)라는 이름의 ERC20 토큰(주소: 0x4894)을 배포했으며, 4.2억 개의 토큰을 미리 채굴해 모두 계약 배포자에게 할당했습니다.

미리 채굴된 토큰 수량은 스마트 계약 소스 코드와 일치합니다.

유동성 추가

오전 8시(토큰 생성 후 8분 후), 공격자 주소(0x8AF8)가 유동성 추가를 시작했습니다.

공격자 주소(0x8AF8)는 토큰 계약 내 openTrading 함수를 호출하여 Uniswap v2 팩토리를 통해 MUMI-WETH 유동성 풀을 생성하고, 미리 채굴한 모든 토큰과 3개의 ETH를 유동성 풀에 추가한 후 약 1.036개의 LP 토큰을 받았습니다.

거래 세부 정보를 보면, 원래 유동성 제공용으로 사용된 4.2억 개의 토큰 중 약 6300만 개가 다시 토큰 계약 주소(0x4894)로 전송되었습니다. 계약 소스 코드를 확인한 결과, 이 토큰 계약은 모든 전송에 대해 일정 수수료를 부과하며, 수수료 수취 주소는 토큰 계약 자체입니다(구현은 '_transfer 함수'에 있음).

이상하게도 계약 내에는 이미 수수료 수취 주소 0x7ffb이 설정되어 있지만, 실제로는 수수료가 토큰 계약 자체로 전달됩니다.

따라서 유동성 풀에 추가된 MUMI 토큰 수량은 수수료 공제 후 약 3.5억 개이며, 처음의 4.2억 개가 아닙니다.

유동성 잠금

오전 8시 1분(유동성 풀 생성 후 1분 후), 공격자 주소(0x8AF8)는 유동성 추가로 획득한 1.036개의 LP 토큰 전체를 잠금 처리했습니다.

LP가 잠긴 후, 이론적으로 공격자 주소(0x8AF8)가 보유한 모든 MUMI 토큰은 유동성 풀 내에 잠겨 있게 되며(수수료 제외), 따라서 공격자 주소(0x8AF8)는 유동성 제거를 통한 Rug Pull 능력도 상실됩니다.

신규 출시 토큰 구매를 유도하기 위해 많은 프로젝트팀이 LP를 잠그는 것을 일반적입니다. 즉 "저는 도망가지 않을 것입니다. 마음 놓고 구매하세요!"라는 의미지만, 실제 상황은 그렇지 않습니다. 이 사례가 바로 그런 경우이며, 계속 분석해 보겠습니다.

Rug Pull

오전 8시 10분, 새로운 공격자 주소②(0x9DF4)가 등장하여 토큰 계약에 명시된 수수료 수취 주소 0x7ffb을 배포했습니다.

여기서 주목할 점은 세 가지입니다:

1. 수수료 수취 주소 배포 주소와 토큰 배포 주소가 동일하지 않아, 프로젝트팀이 각 작업 간 주소 연관성을 의도적으로 줄이고 추적 난이도를 높이고 있다는 것을 시사합니다.

2. 수수료 수취 주소 계약은 오픈소스가 아니므로 노출하고 싶지 않은 작업이 숨겨져 있을 가능성이 있습니다.

3. 수수료 수취 계약이 토큰 계약보다 늦게 배포되었지만, 토큰 계약 내 수수료 수취 주소는 이미 하드코딩되어 있습니다. 이는 프로젝트팀이 수수료 수취 계약 주소를 미리 알고 있었음을 의미하며, CREATE 명령은 배포자 주소와 nonce가 결정되면 계약 주소도 결정되므로, 프로젝트팀은 배포자 주소를 사용해 미리 계약 주소를 계산한 것입니다.

사실 많은 이탈 사기들이 수수료 수취 주소를 통해 이루어지며, 그 배포 패턴은 위의 1, 2번 특징과 일치합니다.

오전 11시(토큰 생성 후 3시간 후), 공격자 주소②(0x9DF4)가 Rug Pull을 실행했습니다. 그는 수수료 수취 계약(0x77fb)의 'swapExactETHForTokens' 메서드를 호출하여, 수수료 수취 주소 내 약 416조 개의 MUMI 토큰을 약 9.736개의 ETH로 교환하며 유동성 풀을 고갈시켰습니다.

수수료 수취 계약(0x77fb)이 비공개이므로 바이트코드를 역컴파일하였으며, 결과는 다음과 같습니다:

https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c

수수료 수취 계약(0x77fb)의 'swapExactETHForTokens' 메서드 역컴파일 코드를 검토한 결과, 이 함수는 기본적으로 uniswapV2 router를 통해 호출자가 지정한 수량 'xt'만큼의 수수료 수취 계약(0x77fb) 소유 MUMI 토큰을 ETH로 교환하고, 그 ETH를 수수료 수취 계약 내 '_manualSwap' 주소로 전송하는 기능을 수행합니다.

'_manualSwap' 주소는 스토리지 주소 0x0에 위치하며, JSON-RPC의 getStorageAt 명령어로 조회한 결과 '_manualSwap' 주소는 바로 수수료 수취 계약(0x77fb)의 배포자인 공격자②(0x9DF4)임을 확인했습니다.

이 Rug Pull 거래의 입력 파라미터 xt는 420,690,000,000,000,000,000,000이며, 이는 MUMI 토큰의 decimal이 9이므로 약 420조 개의 MUMI 토큰에 해당합니다.

즉, 결국 프로젝트팀은 약 420조 개의 MUMI 토큰을 사용해 유동성 풀 내 WETH를 모두 소진시키며 전체 이탈 사기를 완료한 것입니다.

하지만 여기서 매우 중요한 질문이 생깁니다. 수수료 수취 계약(0x77fb)은 어떻게 이렇게 많은 MUMI 토큰을 확보했을까요?

앞서 설명한 바에 따르면 MUMI 토큰의 총 공급량은 배포 당시 4.2억 개였으며, 이탈 사기 종료 후에도 여전히 MUMI 토큰 계약에서 조회되는 총 공급량은 4.2억 개입니다(아래 그림에서 420,690,000,000,000,000으로 표시되나 decimal이 9이므로 뒤의 0을 제거해야 함). 수수료 수취 계약(0x77fb) 내의 총 공급량을 훨씬 초과하는 토큰(약 420조 개)은 마치 공중에서 나타난 것처럼 보입니다. 앞서 언급했듯이 0x77fb는 수수료 수취 주소이지만, MUMI 토큰 전송 과정에서 발생한 수수료조차도 토큰 계약 자체가 수령했으므로 실제로 수수료 수취 주소로 사용되지 않았습니다.

수법 밝혀내기

수수료 수취 계약의 토큰 출처

수수료 수취 계약(0x7ffb)의 토큰 출처를 알아보기 위해 ERC20 전송 이벤트 기록을 확인했습니다.

총 6건의 0x77fb 관련 전송 이벤트 중에서 오직 수수료 수취 계약(0x7ffb)에서 나가는 전송만 있고, MUMI 토큰이 들어오는 기록은 전혀 없습니다. 일견, 수수료 수취 계약(0x7ffb)의 토큰은 정말 공중에서 생겨난 것처럼 보입니다.

따라서 수수료 수취 계약(0x7ffb) 주소에 공중에서 나타난 거액의 MUMI 토큰은 두 가지 특징을 가집니다:

1. MUMI 계약의 totalSupply에 영향을 주지 않음

2. 토큰 증가가 Transfer 이벤트를 발생시키지 않음

따라서 결론은 명확합니다. MUMI 토큰 계약 내에는 반드시 백도어가 존재하며, 이 백도어는 balance 변수를 직접 수정하면서 totalSupply는 수정하지 않고 Transfer 이벤트도 발생시키지 않습니다.

즉, 이는 표준이 아닌 혹은 악의적인 ERC20 토큰 구현이며, 사용자는 총 공급량 변화나 이벤트를 통해 프로젝트팀이 몰래 토큰을 민팅하는 것을 인지할 수 없습니다.

이제 위 가설을 검증하기 위해 MUMI 토큰 계약 소스 코드에서 'balance' 키워드를 검색했습니다.

결과적으로 계약 내 private 타입의 'swapTokensForEth' 함수를 발견했습니다. 이 함수는 uint256 타입의 tokenAmount를 입력받으며, 함수 5행에서 프로젝트팀은 _taxWallet, 즉 수수료 수취 계약(0x7ffb)의 MUMI 잔액을 tokenAmount * 10**_decimals, 즉 tokenAmount의 약 10억 배로 수정한 후, 유동성 풀에서 tokenAmount 만큼의 MUMI를 ETH로 교환하여 토큰 계약(0x4894) 내에 보관합니다.

다음으로 'swapTokenForEth' 키워드를 검색했습니다.

'swapTokenForEth' 함수는 '_transfer' 함수 내에서 호출되며, 호출 조건을 자세히 살펴보면 다음과 같습니다:

1. 전송 수신 주소(to)가 MUMI-WETH 유동성 풀일 때

2. 다른 주소가 유동성 풀에서 MUMI 토큰을 5회(_preventSwapBefore) 이상 구매한 후에야 'swapTokenForEth' 함수가 호출됨

3. 입력되는 tokenAmount는 토큰 주소가 보유한 MUMI 토큰 잔액과 _maxTaxSwap 중 작은 값

즉, 계약이 유동성 풀에서 사용자가 WETH로 MUMI 토큰을 5회 이상 교환한 것을 감지하면, 수수료 수취 주소에 엄청난 양의 토큰을 몰래 민팅하고 일부 토큰을 ETH로 교환하여 토큰 계약 내에 저장합니다.

한편, 프로젝트팀은 표면적으로 수수료를 징수하고 정기적으로 소량의 ETH로 자동 교환하여 토큰 계약에 두는 행위를 하며, 이는 사용자들에게 프로젝트팀의 수익원이라고 착각하게 만듭니다.

다른 한편으로, 프로젝트팀이 진짜 하고 있는 일은 사용자 거래 횟수가 5회에 도달하면 계정 잔액을 직접 수정하여 유동성 풀을 완전히 비우는 것입니다.

이익 실현 방법

'swapTokenForEth' 함수 실행 후, '_transfer' 함수는 sendETHToFee를 실행하여 토큰 주소 내 수수료로 얻은 ETH를 수수료 수취 계약(0x77fb)으로 전송합니다.

수수료 수취 계약(0x77fb) 내 ETH는 계약 내 구현된 'rescue' 함수를 통해 인출할 수 있습니다.

이제 전체 이탈 사기의 마지막 수익 거래 교환 기록을 다시 살펴보겠습니다.

수익 거래에서는 두 차례 교환이 이루어졌습니다. 첫 번째는 약 416만 개의 MUMI 토큰으로 0.349개의 ETH를 교환한 것이고, 두 번째는 약 416조 개의 MUMI 토큰으로 9.368개의 ETH를 교환한 것입니다. 두 번째 교환은 수수료 수취 계약(0x7ffb)의 'swapExactETHForTokens' 함수 내에서 발생한 교환이며, 입력 파라미터의 420조 개와 수량이 다른 이유는 일부 토큰이 수수료로 토큰 계약(0x4894)에 전달되었기 때문입니다(아래 그림 참조):

첫 번째 교환은 두 번째 교환 과정에서 토큰이 수수료 수취 계약(0x7ffb)에서 라우터 계약으로 전송될 때, 토큰 계약 내 백도어 함수 트리거 조건을 만족하여 'swapTokensForEth' 함수가 실행된 것으로, 핵심 조작은 아닙니다.

배후의 대형 삽살개

앞서 설명한 바와 같이, MUMI 토큰은 배포부터 유동성 풀 생성, 그리고 Rug Pull까지 전체 이탈 사기 주기가 약 3시간에 불과했지만, 총 약 6.5개의 ETH 비용(3개 ETH는 유동성 제공, 3개 ETH는 유동성 풀에서 MUMI를 유인 구매용, 0.5개 미만 ETH는 계약 배포 및 거래 수수료)으로 9.7개의 ETH를 얻어 50% 이상의 수익을 달성했습니다.

공격자가 ETH로 MUMI를 교환한 거래는 5건이 있으며, 앞서 언급하지 않았던 정보입니다. 거래 정보는 다음과 같습니다:

https://etherscan.io/tx/0x62a59ba219e9b2b6ac14a1c35cb99a5683538379235a68b3a607182d7c814817
https://etherscan.io/tx/0x0c9af78f983aba6fef85bf2ecccd6cd68a5a5d4e5ef3a4b1e94fb10898fa597e
https://etherscan.io/tx/0xc0a048e993409d0d68450db6ff3fdc1f13474314c49b734bac3f1b3e0ef39525
https://etherscan.io/tx/0x9874c19cedafec351939a570ef392140c46a7f7da89b8d125cabc14dc54e7306
https://etherscan.io/tx/0x9ee3928dc782e54eb99f907fcdddc9fe6232b969a080bc79caa53ca143736f75

유동성 풀 내 거래를 수행한 EOA 주소를 분석한 결과, 상당수의 주소가 체인 상의 '신규 상장 매수 로봇'임을 알 수 있었으며, 이 사기의 신속한 진행 특징과 함께 볼 때, 이 사기의 대상이 바로 활발하게 활동하는 신규 상장 매수 로봇 및 스크립트임을 유추할 수 있습니다.

따라서 토큰의 불필요해 보이지만 복잡한 계약 설계, 계약 배포, 유동성 잠금 절차, 또는 중간에 공격자 관련 주소가 ETH로 MUMI를 구매하는 의문의 행동까지, 모두 체인 상 다양한 신규 상장 매수 로봇의 사기 탐지 시스템을 속이기 위한 위장 행위로 이해할 수 있습니다.

자금 흐름을 추적한 결과, 공격으로 얻은 수익은 모두 공격 주소②(0x9dF4)에서 자금 집결 주소(0xDF1a)로 전송되었습니다.