传统的安全应急响应相信大家都见过，在之前的博文中也有过介绍。上周末我们的一个客户发生的虚拟货币丢失事件，我们安全组介入排查，当时很久都没有头绪，经过某同事的灵光一闪，我们发现了转机。一句话而言，云计算安全我们要考虑云计算和虚拟化的一些特性，避免被我们常见的应急响应思路所限制住。下面来说说详情，由于部分信息敏感，请原谅马赛克处理：
- 原因：
核心支付代码逻辑被插入了一个陌生的区块链交易地址，每调用这个函数就转走特定的虚拟货币到特定地址。
这块涉及一个小的应急知识点，感谢sfish分享，在~/.ssh下存在vim的编辑历史，我们可以通过这个小黑科技去分析一下对方篡改的文件。
cat ~/.viminfo
- 最百思不得其解也最显而易见的事儿
最费解的来自于这段日志。系统发生了一次down机（New seat seat0），说明系统重启过。然后黑客就登录到了root权限，因为事先的机器sshd文件都只允许公钥登录，且所有账户都是强口令。一些都很匪夷所思，为啥重启了一次系统的配置文件都改变了非常的奇怪，难道黑客手里有什么大狠狠的0day我们不知情？
这次应急卡在了这里相当久时间，大约有3个小时，我们始终难以理解。直到我们同事说了句不经意的话，我一般攻击阿里云都通过ak接口还原镜像！
对关键就在这里，镜像！！平时我们用虚拟机的时候觉得没事做个快照是很顺手的事儿，然而面临生产环境的时候，我们还以传统的IDC思维去思考问题，造成了卡壳。因为还原镜像一定会造成一次down机，所以在考虑云计算安全事件的时候镜像本身也是一个不能忽略的点，我们只考虑到了溢出，弱口令等传统攻击方式，却没有想到黑客可以通过还原镜像进行相应的攻击。最后我们在客户非自己打包的镜像中，发现了黑客的history记录。
剩下的事儿，大家看看也就明白了。
- 总结：
这篇文章非常短，但我们踩过的坑却是无数的。主要是云计算条件下，镜像是一个非常重要的黑客攻击点。基于ak接口的攻击思路，我会在下片博文中详细赘述。由于事件敏感，本文打了大量的马赛克，希望大家再云安全应急响应的过程中能够多学习到一种思路。