记一次隐蔽的恶意攻击事件追踪分析

2023年7月24日，安全团队发现此攻击事件可能为内部所为，并告知社区用户；
2023年7月25日上午，社区用户反馈IEGT项目团队已确认此次攻击事件为内部行为，并已进行排查。

0x8D07f605926837Ea0F9E1e24DbA0Fb348cb3E97D，
合约部署者地址：

0xf5c1ce9afae4e58a8a4504485caf9fdd19ec363a，
攻击者地址：

0x00002b9b0748d575cb21de3cae868ed19a7b5b56，
其攻击交易为：

0x9cea0bd314181f42a359c26b68f8790add4daf83e2bfd2d349268538e4e1e2ca。

通过链上的交易记录可以发现，攻击者在PancakeSwap上进行了两笔1,000,000,000token的卖出，获利114万美金，然后又把剩余的token转入黑洞地址。

我们还是从攻击者交易开始入手，看看攻击交易的堆栈调用情况，堆栈调用详情如下链接：

https://dashboard.tenderly.co/tx/binance/0x9cea0bd314181f42a359c26b68f8790add4daf83e2bfd2d349268538e4e1e2ca?trace=0.3.5.0

通过对攻击交易堆栈数据进行分析，攻击者将大量 IGET 资金兑换为 usdt，确实未发现增发资金来源，不过对其合约转账等函数进行源码分析，发现攻击者执行的代码分支为不收取手续费直接转出资金。

进一步对链上状态数据进行分析，定位攻击者的特权角色以及大量token来源，发现攻击地址在合约创建时所在的区块高度就已经存在大量token余额，并且也已经设置了特权角色，如下图所示：

这里我们要补充一下，在智能合约中，攻击者的特权角色设置和大量token余额设置等任何数据，本质上都只是修改了合约在链上存储的数据状态，比如这里的攻击者token余额，我们只需要修改攻击者地址的余额在合约中对应存储的插槽数据即可。

根据合约源码我们得到，攻击者大量token余额这个值的存储插槽位置在0，攻击者的特权角色这个值的存储插槽位置在10，如下图所示：

0x9d1f25384689385576b577f0f3bf1fa04b6829457a3e65965ad8e59bd165a716 为攻击者在合约中 _balances 变量的具体存储key，用于存储攻击者具体资金余额，

0x70b9a82f1bc61b8dbca8540493592b90be59b6dac9a91986bcbc8eb7d2fc74d0 为攻击者在合约中 _Excludes 变量的具体存储key，用于存储该地址是否用于特权角色。

算出具体存储键后，我们通过对该合约创建交易的链上状态变更对比，确认攻击者地址所拥有的权限以及token余额都是通过在合约创建时进行设置。

这里我们想到，由于修改存储键可以通过变量直接修改，也可以通过汇编代码直接对存储键直接修改，所以我们再次回过头对合约源码进行分析。

随后通过使用汇编指令 mstore 将内存 0～64 字节的位置填充为如下内容:

# 执行两次 mstore 后 拼接了两个数据 一个是 攻击者地址，一个是 0x0 （_balances变量的存储插槽）

并在接下来又一次拼接 y 将内存 0～64 字节的位置填充为如下内容:

# 一个是 攻击者地址，一个是 0xa （_Excludes变量的存储插槽）

到此为止，可以看出，攻击者在合约创建时就将攻击地址的余额和特权角色等数据硬编码到合约，并且通过一系列的数学运算对地址进行混淆，从而隐式的大量增发代币，并在项目上线后适当时机砸盘跑路。

0x00002b9b0748d575cb21de3cae868ed19a7b5b56的手续费来源如下：

建议所有合约在上线前都尽量做到全面审计，减少合约漏洞缺陷，避免被恶意攻击者利用。