如何全面防御Webshell（下）？
导语：在进行调查时，最关键的部分之一是找到黑客的入口点，尤其是当运维团队将受攻击的服务器恢复正常后，我们意识到有很多的服务器已经被各种webshell、rootkits和密码导出工具感染时。
在进行调查时，最关键的部分之一是找到黑客的入口点，尤其是当运维团队将受攻击的服务器恢复正常后，我们意识到有很多的服务器已经被各种webshell、rootkits和密码导出工具感染时。
需要快速的通过时间轴法对恶意软件留下的文件以及横向的多台可能被感染的服务器进行分析，然后找出第一个被安装的恶意软件样本，现在唯一的问题是黑客是如何将恶意文件上传至内部网络的。恶意软件通常以当前的服务器权限进行各项操作，但是很不幸的是通常它所处的环境就是管理员权限。
那么我们应该从何下手？
一个成功的调查需要从不同的实体(上下文)获取到大量的信息来构建一个能更好的理解系统、基础设施、业务流程的画像。
就拿Tomcat来说，它在被安装后会将应用的日志保存到stdout.log中。如同大多数的标准输出日志一样，你在日志中会看到应用大量的堆栈跟踪活动记录，生产环境的服务器尤为如此。但是当看完所有的记录后，我发现了一条奇特的记录：
进一步的，我发现了更有趣的另一个文件：
如果第一条记录还不够明显，那么从第二条记录就看出有人试图将精简的webshell写入到文件中。接下来我们需要好好看看文件的内容了：
该webshell通过参数cmd进行命令的传参，然后在系统上执行该命令并回显执行结果。
至此，应用程序的日志表明了有人试图将webshell上传到服务器上，但是目前还不清楚这是如何实现的。日志关于该webshell被上传的记录已经部分丢失，但是庆幸的是我知道webshell存储的位置以及它的名称，接下来我们是不是应该去分析一些web日志了？
在web日志中我发现了如下的一条记录：
这条日志似乎说明有人试图通过执行系统命令来查看当前系统的网络配置。
在日志中搜寻包含关键字”redirectAction:”的记录：
这条日志显示有人试图将上面提到的webshell写入到系统的文件夹中。通过谷歌搜索以及测试后，我们发现这条日志显示了有人在测试服务器的Struts 2漏洞（CVE-2013-2135）。通过时间轴法进行分析，我们发现了黑客的入手点。
一图胜千言，将所有的讯息整合到一起后绘制了如下视图：
还谈webshell：查杀工具
接下来将要介绍的webshell查杀工具如下：
1、NeoPI
3、LOKI
接下来的是webshell查杀工具要查杀的病毒样本：
1、byroe.jpg—-将webshell代码隐藏在图片中
2、myluph.php—PHP webshell样本
3、webshell.php—一开始提到的那个webshell样本
4、vero.txt—包含混淆代码和原始代码的PHP webshell样本
5、myluphdecoded.php—解码后的myluph.php
6、China Chopper—中国菜刀
7、c99madshell.php—常用的webshell
8、unknownPHP.php—别人分享的一个webshell
外带一些常规的正常文件：
1、来自常用网站的index.html页面
2、ASPX文件
3、PHP文件
4、JavaScript文件
NeoPI
根据NeoPI在GitHub上的描述信息，该工具的代码由python编写，通过统计学的方法来检测混淆/编码的内容。使用该工具对上面提到的文件进行扫描：
该工具好的方面：
A 检出率：6/9 B 不管是原始的或者经过混淆的webshell，都能正确发现 C 越复杂的代码结构，被发现的可能性越高 D 多种检测webshell的方法：特征、符合指数（IC）、比例、熵值、最长关键字匹配
该工具不好的地方：
A 不能发现简单的“一句话”webshell（比如中国菜刀使用的一句话webshell） B 有一定的误报 C 对于某些方法，需要手动进行分类和对高亮文件进行附加分析（比如说熵值和关键字匹配） D 特征库不再更新了 E 不能在大量文件中检测出将代码隐藏在图片中的webshell
我注意到，将多个启发式检测到的文件进行信息汇总是非常有帮助的，举个例子，在检测byroe.jpg这个webshell文件时，可以看到它排在特征排行榜的前10，但是在最长关键字匹配排行榜和熵值排行榜中却没有排名。
就这款工具来说，它已经4年没有更新了，不能检测出所有类型的webshell，也会产生误报，但是对于新webshell的检出率还是不错的，我建议你们将该工具加入到你们的分析沙盒中，这里还有一篇关于它的文章，可以看一看。
Shell Detector
我测试使用后的截图如下：
当然它还有一个web版本：点我
该工具好的方面：
A 检出率：7/9（5个可以，2个webshell） B 不管是原始的或者经过混淆的webshell，都能正确发现 C 提供了清晰的检测结果的图表展示
该工具不好的地方：
A 有131个正常文件被误报为可疑 B 检测方法只有：特征匹配 C 特征库没有更新 D 该工具的web版如果数量过多会导致页面卡住 E 特征以PHP序列化的方式写入（不可扩展） F 不能检测出将代码隐藏在图片中的webshell---不支持检测JPG文件
尽管特征库已经比较过时了，但是它也几乎检测出了所有的可疑文件。当特征库比较足够新时，该工具能发挥出强大的功效。
LOKI
LOKI会根据严重程度来对文件进行颜色显示，它也会将扫描结果保存到指定的日志中。它的扫描规则是按YARA写的，而YARA因为它的易于使用以及能够有效的区分和分类病毒而深受安全行业的喜爱。根据该工具的项目主页的描述，它借鉴了大表哥“THOR APT Scanner”的扫描规则，接下来验证一下它检测webshell的能力到底如何。
我第一次检测时使用了简单的默认特征库，检出率为5/9。我在网上找到了一个教新的特征库，然后检出率得到了提升，为8/9。我对检测规则又进行了一些修改：
A 根据misc_php_exploits的内容，将规则中的$php修改为“<?” B 然后在misc_php_exploits中添加了“system($_REQUEST” C 将规则文件misc_shells中的$s6和$s8删除
之后的检测误差为0
该工具好的方面：
A 检出率：8/9 B 不管是原始的或者经过混淆的webshell，都能正确发现 C 提供了清晰的日志 D 误差为0（依赖于Yara规则） E 使用的Yara易于扩展 F 支持检测所有的文件类型
该工具不好的地方：只支持特征扫描
因为函数功能和编码的多样性，很难以制造一款工具来实现检测所有的webshell。比如说黑客可以不使用base64_decode函数，转而通过自己编写的函数实现编码，或者他们可以通过使用str_replace函数来躲过关键字检测，这里有一篇来自Imperva的文章阐述了这些东西。
这里唯一的没有被LOKI检测出来的webshell为unknownPHP.php，它使用的混淆技术十分先进，关于怎么对它进行解码，请看来自Kahu Security的Darryl的文章。对于这个webshell，使用常规的特征字符匹配规则是没办法检测出来的，NeoPI的熵值法检测可能会是个不错的选择。
最后，作者还针对市面上存在的其他扫描工具进行了评测，并给出了最终的报告，这里只简单的罗列一下评测结果（包含上面介绍的3种）。
待检测的超过1千个wenshell文件列表如下：
https://github.com/bartblaze/PHP-backdoors https://github.com/JohnTroony/php-webshells https://github.com/BDLeet/public-shell https://github.com/tennc/webshell http://www.irongeek.com/i.php?page=webshells-and-rfis https://github.com/epinna/weevely3 https://github.com/wireghoul/htshells
Shell Detector的结果：扫描时间（5分16秒）
LOKI的结果：扫描时间（39秒）
PHP-malware-finder的结果：扫描时间（1分41秒）
OMENS的结果：
关于如何更好的保护自己的服务器，作者也给出了自己的见解和建议，详情请看原文。
来源：
（1）https://dfir.it/blog/2015/08/12/webshell-every-time-the-same-purpose/
（2）https://dfir.it/blog/2016/01/18/webshells-every-time-the-same-story-dot-dot-dot-part2/
（3）https://dfir.it/blog/2016/07/06/webshells-every-time-the-same-story-dot-dot-dot-part-3/
（4）https://dfir.it/blog/2016/12/07/webshells-rise-of-the-defenders-part-4/
小结一下：对于应急人员来说，并不是每次要分析的日志都是健全的，可能日志会被重写。即使是这样，实际上黑客还是会有出错的时候的，可能也在其他的系统中留下了蛛丝马迹，而你要做的就是去找到这些弥足珍贵的日志！