长推：分析Claim钓鱼攻击

注：本文来自@gooo_robin 推特，MarsBit整理如下：

起因:

早上看到一个消息，一个地址遭遇”Claim钓鱼攻击”损失150 ETH，忙了一天终于有时间写一下了?这种攻击看看代码识别起来很简单，但具体情况到底是怎样呢？为什么这个地址会去调用这个钓鱼合约？更有趣的是我扒出来的几个地址，以及他们在Twitter上的一些关联???

表象:

地址为0xB9c1F6426fA5b3760ff08E83e066Bb9929ac7A3F，从Coinbase取出150 ETH之后不到两小时就和钓鱼地址交互，tx为0x3aa52586c6941da08d49693a2a83f9570c2dd6491dcd71a565081d3217a12577，被转走了所有ETH。可以看到7A3F地址调用了Claim函数，那为什么调用Claim函数就被转走所有ETH呢？

合约解析1:

直接跳到合约代码部分，首先constructor里调用 transferOwnership 将所有权转移到硬编码的地址 0x0000553F880fFA3728b290e04E819053A3590000。这里就挺奇怪的，而这个地址记录下来，后面才发现原来和Phishing早有渊源

合约解析2:

再看Claim函数，这里Claim里啥也没有，那是怎么做到能调用一下就能转走所有ETH呢？可以思考一下再往下看?

合约解析3:

虽然Claim是一个空函数，但被标记为payable。所以当函数被调用时，如果有ETH与交易一起发送 (作为msg.value)，那么这些ETH将被转移到合约中。

如果一个函数被标记payable，无论函数内是否有任何命令或逻辑，它都可以在函数调用时接收ETH，无需在函数里显式包含transfer或send命令

初步推理:

那么欺诈者可能在前端给用户一个模糊的界面，如”Claim Max ETH”，而后台可以设置交易的msg.value为钱包的所有ETH。这样一来如果用户没有注意查看交易详情，可能会无意中将ETH发送到该合约。以上就是利用payable Claim钓鱼的流程。

地址和Etherscan缺陷:

我查看了创建这个钓鱼合约的地址，为0x12ddBd16175953a8035A009393482DD64849959A，比较离谱的是这个地址在etherscan上竟然没有被标记为钓鱼地址，和这个钓鱼合约bytecode相同的合约也没打上标签，只有被report的钓鱼地址被标记了，alert这一点etherscan做的实在是有点敷衍

地址探索1:

这个地址基本没什么操作，几笔操作也只是和其他一些钓鱼合约交互而已，接着我将这个地址贴到Twitter搜索，竟然出现了 @CryptoCost65856

地址探索2:

进入这个账号主页，没有任何Tweets，但Replies里倒是很丰富?他会在各种假的airdrop推文下面留地址，最近留的地址都是0x815b0AC9FABEAF40226656766D23B4Ea302DcFDF，甚至三个小时之前还在留。开始我还想了一下，这是什么迷惑操作？

地址探索3:

点开Followers恍然大悟，里面全都是他留言的这些假Airdrop号，留言也只是给这条推文造势。所以从始至终都是同一个人，或者说同一个组织。

而他们钓鱼的流程其实就这么简单，在Twitter和Discord里疯狂发这些”送钱airdrop”信息，当你”Claim”并签名的时候，钱包余额就归零了。。

推断+地址探索4:

很难想象一次性转出150 ETH的账户会犯这种低级错误，但从这些迹象来看被虚假Airdrop钓鱼的可能性比较大。再倒回最开始那个奇怪的硬编码地址，原来就是上个月通过Blur Root盲签钓鱼Azuki的地址。。所以这完全是一波人研究出了不同的钓鱼手法而已，”十八般武艺样样精通”。。

总结:

1. 永远别信天上掉馅饼，所有打着送钱旗号的airdrop都是假的。

2. 签名一定要看清楚这个request是来自哪里，究竟是不是来自官方。

3. 不要掉以轻心，被claim airdrop盗取只是我的分析猜测而已，整个流程被设计得一定比想象更有迷惑性。