精华内容
下载资源
问答
  • webshell检测
    2022-04-27 06:10:26

    1、D盾_Web查杀

    使用自行研发不分扩展名的代码分析引擎,能分析更为隐藏的WebShell后门行为。
    兼容性:只提供Windows版本。
    工具下载地址:http://www.d99net.net/down/WebShellKill_V2.0.9.zip

    2、百度WEBDIR+

    下一代WebShell检测引擎,采用先进的动态监测技术,结合多种引擎零规则查杀。
    兼容性:提供在线查杀木马,免费开放API支持批量检测。
    在线查杀地址:https://scanner.baidu.com/

    3.河马

    专注webshell查杀研究,拥有海量webshell样本和自主查杀技术,采用传统特征+云端大数据双引擎的查杀技术。查杀速度快、精度高、误报低。
    兼容性:支持Windows、linux,支持在线查杀。
    官方网站:https://www.shellpub.com/

    4、Web Shell Detector

    Webshell Detector具有“ Webshell”签名数据库,可帮助识别高达99%的“ Webshell”。
    兼容性:提供php/python脚本,可跨平台,在线检测。
    官方网站:http://www.shelldetector.com/
    github项目地址:https://github.com/emposha/PHP-Shell-Detector

    5.CloudWalker(牧云)

    一个可执行的命令行版本 Webshell 检测工具。目前,项目已停止更新。
    兼容性,提供linux版本,Windows 暂不支持。
    在线查杀demo:https://webshellchop.chaitin.cn/
    github项目地址:https://github.com/chaitin/cloudwalker

    6、Sangfor WebShellKill

    Sangfor WebShellKill(网站后门检测工具)是一款web后门专杀工具,不仅支持webshell的扫描,同时还支持暗链的扫描。是一款融合了多重检测引擎的查杀工具。能更精准地检测出WEB网站已知和未知的后门文件。
    兼容性:支持Windows、linux
    工具下载地址:http://edr.sangfor.com.cn/backdoor_detection.html(已停止访问)

    7.深度学习模型检测PHP Webshell

    一个深度学习PHP webshell查杀引擎demo,提供在线样本检测。
    在线查杀地址:http://webshell.cdxy.me/

    8.PHP Malware Finder

    PHP-malware-finder 是一款优秀的检测webshell和恶意软件混淆代码的工具
    兼容性:提供linux版本,Windows 暂不支持。
    github项目地址:https://github.com/jvoisin/php-malware-finder

    9、findWebshell

    这个项目是一款基于python开发的webshell检查工具,可以根据特征码匹配检查任意类型的webshell后门。
    github项目地址:https://github.com/he1m4n6a/findWebshell

    10、在线webshell查杀工具

    在线查杀地址:http://tools.bugscaner.com/killwebshell/

    相关文章:https://www.cnblogs.com/xiaozi/p/12679777.html

    更多相关内容
  • 基于卷积神经网络的Webshell检测方法研究.pdf
  • 基于多通道卷积神经网络的Webshell检测模型研究,于泓凯,李文敏,本文提出了一种新的Webshell通信流量精细化检测模型,该模型根据Webshell在HTTP流量中针对Webshell攻击的payload大小、形式多变的特点,使用�
  • 为解决WebShell检测特征覆盖不全、检测算法有待完善的问题,提出一种基于随机森林改进算法的WebShell检测方法。首先对三种类型的WeSshell进行深入特征分析,构建多维特征,较全面地覆盖静态属性和动态行为,改进随机...
  • webshell检测领域,有标记样本少、形式灵活多变、易混淆,基于特征匹配的方式很难进行准确检测。针对标记样本较少的现状,提出一种基于深度学习和半监督学习的webshell检测方法,先使用卡方检验和深度学习方法获取...
  • 基于语法特征的webshell检测方法的研究与实现 万字论文,非常具体 基于语法特征的webshell检测方法的研究与实现 万字论文,非常具体 基于语法特征的webshell检测方法的研究与实现 万字论文,非常具体 基于语法特征的...
  • 前段时间由于项目的需要也因为正在负责一个后门检测小工具的项目开发所以恶补了一下Webshell检测技术内容,一路天马行空写下此文和大家分享。小弟才疏学浅如有内容上的问题还请不吝指正。近年来网站被植入后门等隐蔽...
  • WebShell根据其功能和大小可以分为多种类型,各种类型的WebShell在基本特征上又有其独有的特征,而现有的WebShell检测大多从单一层面提取特征,无法较全面的覆盖各种类型WebShell全部特征,具有种类偏向性,无差别的...
  • webshell检测方法归纳

    千次阅读 2021-08-17 16:08:14
    背景 webshell就是以asp、php、jsp或者cgi等网页文件形式存在的一种命令执行环境,也可以将其... webshell检测模型 Webshell的运行流程:hacker -> HTTP Protocol -> Web Server -> CGI。简单来看就是这样一个

    一、背景

    webshell就是以asp、php、jsp或者cgi等网页文件形式存在的一种命令执行环境,也可以将其称做为一种网页后门。黑客在入侵了一个网站后,通常会将asp或php后门文件与网站服务器WEB目录下正常的网页文件混在一起,然后就可以使用浏览器来访问asp或者php后门,得到一个命令执行环境,以达到控制网站服务器的目的。

    二、webshell检测模型

    Webshell的运行流程:hacker -> HTTP Protocol -> Web Server -> CGI。简单来看就是这样一个顺序:黑客通过浏览器以HTTP协议访问Web Server上的一个CGI文件。棘手的是,webshell就是一个合法的TCP连接,在TCP/IP的应用层之下没有任何特征(当然不是绝对的),只有在应用层进行检测。黑客入侵服务器,使用webshell,不管是传文件还是改文件,必然有一个文件会包含webshell代码,很容易想到从文件代码入手,这是静态特征检测;webshell运行后,B/S数据通过HTTP交互,HTTP请求/响应中可以找到蛛丝马迹,这是动态特征检测。

    1.静态检测

    静态检测通过匹配特征码,特征值,危险函数函数来查找webshell的方法,只能查找已知的webshell,并且误报率漏报率会比较高,但是如果规则完善,可以减低误报率,但是漏报率必定会有所提高。优点是快速方便,对已知的webshell查找准确率高,部署方便,一个脚本就能搞定。缺点漏报率、误报率高,无法查找0day型webshell,而且容易被绕过。对于单站点的网站,用静态检测还是有很大好处,配合人工,能快速定位webshell,但是如果是一个成千上万站点的大型企业呢,这个时候再人肉那工作量可就大了。所以用这样一种思路:强弱特征。即把特征码分为强弱两种特征,强特征命中则必是webshell;弱特征由人工去判断。加入一种强特征,即把流行webshell用到的特征作为强特征重点监控,一旦出现这样的特征即可确认为webshell立即进行响应。要解决误报和漏报,就不能拘泥于代码级别了。可以换个角度考虑问题:文件系统。我们可以结合文件的属性来判断,比如apache是noboy启动的,webshell的属主必然也是nobody,如果我的Web目录无缘无故多了个nobody属主的文件,这里就有问题了。最理想的办法是需要制度和流程来建设一个web目录唯一发布入口,控制住这个入口,非法进来的Web文件自然可以发现。

    2.动态检测

    webshell传到服务器了,黑客总要去执行它吧,webshell执行时刻表现出来的特征,我们称为动态特征。先前我们说到过webshell通信是HTTP协议。只要我们把webshell特有的HTTP请求/响应做成特征库,加到IDS里面去检测所有的HTTP请求就好了。webshell起来如果执行系统命令的话,会有进程。Linux下就是nobody用户起了bash,Win下就是IIS User启动cmd,这些都是动态特征。再者如果黑客反向连接的话,那很更容易检测了,Agent和IDS都可以抓现行。Webshell总有一个HTTP请求,如果我在网络层监控HTTP,并且检测到有人访问了一个从没反问过得文件,而且返回了200,则很容易定位到webshell,这便是http异常模型检测,就和检测文件变化一样,如果非管理员新增文件,则说明被人入侵了。缺点也很明显,黑客只要利用原文件就很轻易绕过了,并且部署代价高,网站时常更新的话规则也要不断添加。还有一个思路利用函数劫持。回忆一下,我们调试网马的时候,怎么还原它各种稀奇古怪的加密算法呢,简单,把eval改成alert就好了。类似的,所以我们可以在CGI全局重载一些函数(比如ASP.Net的global.asax文件),当有webshell调用的时候就可以发现异常。已js为例(php,asp等语言思路一样的,都是保存原函数,然后从新定义原函数,最后在调用保存的原函数),比如下面就是把eval重载,还可以弹出个危险提示等,吓退一些没经验黑客。

    <script type="text/javascript">
    	var _eval = eval;
    	eval = function(s) {
    	    if (confirm("eval被调用\n\n调用函数\n" + eval.caller + "\n\n调用参数\n" + s)) {
    	        _eval(s);
    	    }
    	}
    </script>
    

    3.日志检测

    使用Webshell一般不会在系统日志中留下记录,但是会在网站的web日志中留下Webshell页面的访问数据和数据提交记录。日志分析检测技术通过大量的日志文件建立请求模型从而检测出异常文件,称之为:HTTP异常请求模型检测。例如:一个平时是GET的请求突然有了POST请求并且返回代码为200、某个页面的访问者IP、访问时间具有规律性等。

    webshell的访问特征(主要特征)

    • 少量ip对其发起访问
    • 总的访问次数少
    • 该页面属于孤立页面

    当然不是所有的孤立页面都是webshell,以下情况也会造成孤立页面
    (1)隐藏管理后台等正常孤立页面的访问
    (2)扫描器行为,常见漏洞扫描,PoC扫描,Webshell扫描(日志中经常可以看到常见webshell路径加一句话payload的扫描)——这是最主要的干扰数据,需要剔除对于情况(1)采用白名单的方式,对于情况(2)扫描器识别(p.s. 爬虫技术、指纹识别技术、扫描器识别(广义的可衍生到人机识别)可以称为web安全技术的三驾马车,总也绕不过去)

    优点: 采用了一定数据分析的方式,网站的访问量达到一定量级时这种检测方法的结果具有较大参考价值。

    缺点: 存在一定误报,对于大量的访问日志,检测工具的处理能力和效率会比较低。

    4.语法检测

    语法语义分析形式,是根据php语言扫描编译的实现方式,进行剥离代码、注释,分析变量、函数、字符串、语言结构的分析方式,来实现关键危险函数的捕捉方式。这样可以完美解决漏报的情况。但误报上,仍存在问题。

    public function startLexing($code)
    {
        if (preg_match('/<\?(php)?\s*@Zend;[\r\n|\n]+\d+;/', $code)) {
            $this->errMsg = 'Encrypt with Zend optimizer.';
            return false;
        }
        $this->resetErrors();
        $this->tokens = token_get_all($code);
        $this->code = $code;
        $this->pos  = -1;
        $this->line =  1;
        return $this->checkError();
    }
    

    误报问题所在,一是被检测文件是否为合法php语法文件,token_get_all函数的实现,是不验证是否问合法php语法文件的,只是对其进行扫描,分析。服务器云判断是一种根据恶意代码串的指纹,根据大量后门数据,做语法、语义分析,做业务逻辑分析,理解这段代码的用途,给出其是否为恶意代码的定位,而其他使用者,直接可以得到该代码片段是否为恶意代码的结果反馈。Pecker Scanner首先是基于语法分析,剥离token、注释、字符串、变量、语言结构,再进行php语法检测,提取恶意代码的扫描工具,来解决漏报问题。同时支持服务器云判断,尽量避免误报问题。基于语法的pecker检测工具

    5.统计学检测

    webshell由于往往经过了编码和加密,会表现出一些特别的统计特征,根据这些特征统计学习。
    典型的代表: NeoPI – https://github.com/Neohapsis/NeoPI

    NeoPi使用以下五种检测方法:

    • 信息熵(Entropy):通过使用ASCII码表来衡量文件的不确定性;
    • 最长单词(LongestWord):最长的字符串也许潜在的被编码或被混淆;
    • 重合指数(Indexof Coincidence):低重合指数预示文件代码潜在的被加密或被混效过;
    • 特征(Signature):在文件中搜索已知的恶意代码字符串片段;
    • 压缩(Compression):对比文件的压缩比

    采用这种检测方法也存在明显的弱点,NeoPi的检测重心在于识别混淆代码,它常常在识别模糊代码或者混淆编排的木马方面表现良好。未经模糊处理的代码对于NeoPi的检测机制较为透明。如果代码整合于系统中的其它脚本之上,这种“正常”的文件极可能无法被NeoPi识别出来。

    6.变形、窃密型webshell检测

    变形webshell可以由上面所说的统计学NeoPI工具检测,也可以动态检测。比如,一个正常的程序员如果使用eval、system是不会刻意的转换隐藏的,如果发现某个函数执行了,代码中却找不到这个函数名,我们认为这是一个异常行为。所以变形加密也可以用这种方式查找,在日志中找到某个文件执行system等命令,但在原文件中没找到这个文件代码,说明文件是后门文件。

    针对窃密型Webshell必须具有操作数据库的能力,可以引申出一种新的检测方法,通过分析正常WEB脚本文件和窃密型Webshell对数据库操作的差异进行分析是本检测方法所重点研究的方向。正常情况下WEB站点进行数据操作的过程应该是重复性且较为复杂的查询过程,这种查询通常精确度非常高,查询过程不会出现类似于“select * from”这种查询语句。正常的WEB脚本在进行数据库操作的过程中也不会出现跨越数据库查询的情况,一旦出现这种现象基本可以判断为非正常的WEB脚本操作过程。

    就以上思路设计如下的检测方案:

    审计数据操作记录。通过审计数据库操作记录可以单独的为每一个WEB站点甚至WEB站点中的每一个脚步文件建立查询请求模型,通过几天甚至数月的自我学习过程来学习并维护一份查询请求数据库。该数据库的内容包含了每次查询操作的详细信息、请求归类和分析结果。并且建立动态查询请求规则,Agent一旦检测到违反该规则的查询请求后会向Server端传递相关信息,Server端再结合其它的扫描过程综合判断发起请求的文件是否为Webshell,并最终决定是否向管理员报警。

    三、总结

    没有最好的检测方法,应该根据实际情况和公司业务合理应用。

    展开全文
  • Linux下基于SVM分类器的WebShell检测方法研究.pdf
  • webshell检测.zip

    2021-07-07 14:19:12
    webshell多功能检测, 功能1:多线程检测webshell存活,以及可写的目录权限。 功能2:多线程检测webshell的根目录权限。 功能3:多线程检测webshell的首页修改权限。 功能4:多线程检测webshell是否被劫持。 ...
  • 行业内对webshell检测的实践方案

    概述

    关于webshell检测我们已经讲了很多理论的东西,最近在网络上搜到了一篇阿里的主机层入侵检测团队在XCON(安全焦点安全信息技术峰会)上的一篇演讲PPT,名字为《云安全环境下恶意脚本检测的最佳实践》,反复阅读了几遍之后,发现他们的一些检测方式非常有创新性,于是决定专门写篇文章来解读下这篇PPT。

    当然,没有一种检测方式是万能的,甚至很多时候我们对某种威胁姿势做了很多努力,最终发现按下葫芦浮起瓢,所以除了单纯的解读方案之外,我也会给出他们的检测方式存在的局限性。

    最后,想阅读原文的小伙伴可以去文末的链接去下载原版PPT。

    阿里的方案

    阿里的方案本质上是采用的动态检测的方式来发现恶意特征。动态检测的核心是代码执行,即通过某种手段对待检测代码进行模拟或者真实的执行,通过执行过程中表现出来的动态特征来判断是否存在恶意行为,比如我们上期讲的taint扩展就是在脚本解释器中注入检测逻辑,通过组合危险函数和外部输入来判断恶意。

    在真实的执行环境上去抓取动态特征往往存在很大的风险,比如代码bug导致程序崩溃而影响正常业务,过多的检测逻辑拖慢了业务的性能。所以为了不影响正常业务的运行,通常的做法是在一个独立且隔离的环境中去执行动态检测,而阿里就是采用了脚本沙箱的检测和部署架构。

    阿里脚本沙箱的物理架构如下:
    在这里插入图片描述

    最底层的运行环境可以是虚拟机也可以是物理机,上层是docker容器,该容器内部部署了经过深度定制化的各种语言的脚本解释器,每个脚本解释器都作为容器内的默认解释器加入到环境变量PATH中。每检测一个恶意样本需要启动这样一个docker容器,检测完成后关闭该容器,释放资源。

    下面我们先来看看定制化的脚本解释器。

    定制化的脚本解释器

    为了达到动态检测的效果,那么就必须对脚本的执行过程进行干预,所以修改脚本的解释器就自然而然地成为了一个不错地选择。

    我们知道,脚本语言的执行都依赖于对应的解释器,解释器以对应脚本作为输入,内部进行语法分析、词法分析生成opcode序列,按照opcode序列调用每个opcdoe的处理函数来达到无需编译便可执行的效果。
    在这里插入图片描述

    所以理论上我们可以在脚本执行的每一个步骤加入我们自己定制化的逻辑来影响脚本的执行过程,不过通常情况下我们使用函数hook和opcode hook来实现执行过程的干预和执行信息记录。

    阿里针对常用脚本语言的解释器进行了定制化,根据ppt中的描述,其只对opcode的处理函数做了定制。通过定制opcode的处理函数,可以控制脚本的执行流程,其中最重要的就是可以实现对脚本中各类分支的展平,下面我们就来看看分支展平是什么,它解决了什么问题?

    分支展平

    我们先来看一个样本,代码如下:

    import os
    import datetime
    import time
    
    user = os.popen("whoami").read().strip('\n')
    if user == 'root':
        exit()
    else:
        data = '''/bin/bash -i >& '''
        data1 = '''/dev/tcp/222.25.1.123/8888 0>&1'''
        def logfile():
            with open('a.log', 'w') as f:
                f.write(data+data1)
            os.system('bash a.log')
        logfile()
    

    这是一个典型的反弹shell恶意python脚本,注意看第六行有个if判断,如果是我们正常去执行它得话,很可能导致if的条件被满足而执行了exit函数退出了,else分支的内的内容无法被执行到。而且复杂的样本不止有if-else分支,还包括elif、while/for、try-except等等。

    一个比较直观的解决方法就是我们强制让if语句块和else语句块或者其他分支的语句块中的内容都执行到就可以了,那如何让它们都被执行到呢,阿里给出了两种方案,一个是栈回溯,一个是分支展平,我们一个一个来看。

    首先来看栈回溯,虚拟机把源代码编译成opcode序列后,可以根据跳转指令把opcode序列划分为一个一个的block,跳转指令对应的就是分支语句的条件,所以我们可以根据跳转指令把opcode序列切分成一个个的对应源代码中分支的block。然后再根据这些划分好的block画出CFG(控制流程图),有了CFG,就可以通过遍历CFG图来解决所有分支中的语句都执行到的问题。以下面的例子举例,只需要遍历CFG中的每个节点,不管是采用深度优先遍历,还是广度优先遍历,只要执行每个节点中的block就可以了。
    在这里插入图片描述
    不过这个方案看上去很美好,但却几乎无法实现,其中的复杂度主要来源于两方面。一个就是如何保证在遍历完CFG的某个分支后,回到父节点时,能够还原全局遍历和程序状态到执行这个分支之前的状态,是不是想想头都大了。第二个,也是最致命的问题就是分支爆炸,遍历CFG图的每一条路径的时间复杂度是指数级的,你可以想象下有64个分支的时候,2的64次方是个多大的数字,宇宙中沙子的总和都没有这么多。

    栈回溯的解法被否定之后,我们再来看下分支展平的解法。
    在这里插入图片描述
    如上图所示,只需要将之前二选一或多选一的分支判断去掉,把跳转执行改为顺序执行,来达到执行所有语句块的目的。跳过所有分支语句在实现上对比栈回溯要简单许多,理论上只需要把opcode中所有的跳转指令不执行即可达到目的。

    当然分支展平虽然也能达到执行所有语句块的目的,但是强制拉平分支却会改变原有的代码行为,比如在两个互斥的if-else分支中都存在同一个变量的赋值,因为else分支在if分支之后,分支展平的话则是取了else语句块中的赋值,if语句块中的赋值被覆盖掉了。如果if中的赋值才是恶意脚本生效的值,那么就会产生漏报。

    反时间对抗

    接下来我们来看阿里ppt中提到的另两个反对抗的方法,先来看下反时间对抗。所谓反时间对抗,是指脚本中使用了一些时间控制函数,比如sleep睡眠函数等等,通过控制时间的值来阻止动态检测时获取正确的值。先来看一个时间对抗的样本:

    import os
    import datetime
    import time
    
    starttime = datetime.datetime.now()
    time.sleep(12)
    endtime = datetime.datetime.now()
    ttl = (endtime-starttime).seconds
    
    data = {}
    data['10'] = '''/bin/bash -i >& '''
    data['11'] = '''/dev/tcp/222.25.1.123/8888 0>&1'''
    
    def is_sandbox(n):
        return n > 5
    newlist = filter(is_sandbox, range(10, ttl))
    payload = data[str(newlist[0])] + data[str(newlist[1])]
    
    def logfile():
        with open('a.log', 'w') as f:
            f.write(payload)
        os.system('bash a.log')
    logfile()
    

    动态检测肯定不能真的去执行sleep函数,这会导致检测程序挂在那什么也做不了,白白浪费检测时间。那怎么才能获取上个样本中ttl的值呢?阿里是这么做的:
    在这里插入图片描述
    当脚本执行sleep函数时,将对面时间记录到外部存储中,然后在后面调用获取时间的系统函数时再在当前时间的基础上加上外部存储中保存的睡眠时间。

    之所以将睡眠时间保持在外部存储中,是因为sleep的睡眠效果是全局跨进程的,比如在python脚本中进行了睡眠,后续调用了shell脚本来获取时间,如果只在python进程中在内存中记录的那么在shell脚本进程中就无法获得睡眠后的时间了。

    阿里解决时间对抗的方法也比较直观,但是说实话只对那种傻白甜的样本有效,即睡眠时间是写死在样本里的,如果睡眠时间是外部传入的,比如从一个socket中获取的,那么睡眠时间是没有一个具体的值的,那再去记录的话只能是记录脚本曾经睡眠过,具体的睡眠时间未知。如果睡眠时间未知的话,那上面那个脚本的例子也就无法被正常执行了,只能去粗劣的判断一个文件被写过,且文件的内容与睡眠时间有关,然后又执行了这个文件,通过这三个条件去判断这个脚本有问题。

    进程链跟踪

    所谓进程链跟踪指的是记录脚本执行过程中整个父子进程的树状结构,这个特性主要用于多语言脚本互相调用的情况下。
    在这里插入图片描述
    上图的例子中python脚本中调用了shell脚本来执行反弹shell,通过进程链可以很清楚的看到整个调用过程是怎么发生的。在进程链的基础上,可以应用很多其他其他的核心技术来精准获取进程行为。

    比如基于管道获得父子进程间的输入输出关系:
    在这里插入图片描述
    上面的例子中,结合进程链和管道的关系,可以得知bash进程的输入最终来自于curl进程的外部输入。

    容器

    容器在阿里的整个检测框架中起到了一个至关重要的整合者角色。想想看,这么多语言的脚本解释器如何处理它们之间的互相调用,如何处理它们与操作系统之间的交互,比如读写文件,无疑容器是一个非常好的虚拟环境。

    先简单介绍下他们的容器部署方案:

    • 多种脚本解释器全部部署在同一个容器镜像内;
    • 每检测一个样本需要启动一个容器,这个容器作为沙箱模拟了真实的运行环境,检测结束后销毁容器;
    • 每种脚本解释都作为容器内的默认脚本执行解释器;
    • 解决了多脚本解释器互相调用的问题,比如python脚本调用了shell脚本,自动调用,无需自己写调用逻辑代码;

    这个方案的优势在于:

    1. 与操作系统相关的功能直接放开执行,比如执行系统命令、读写文件、设置环境变量等等。以读写一个文件为例,脚本中该怎么写那实际中就怎么写,后续在读这个文件时读到的内容就是之前写的内容,而不用管脚本是怎么变着花样写的。
    2. 更容易整合多脚本解释器,并且可以通过旁路的机制可以得知两个脚本间的输入输出关系,以及系统内执行了何种命令,方便做关联分析。比如python脚本中调用了经过混淆的bash命令,只通过python脚本引擎本身没办法做解混淆,但通过启动的bash引擎则可以完整拿到解混淆后的命令;

    关于第一个优势,也有一些需要注意的点,当恶意样本执行的命令、写文件的内容等等不依赖外部输入时效果会很好,但是一旦与外部输入相关了就需要单脚本解释器自身的定制能力来做判断了,所以单解释器本身的能力是至关重要的。

    此外,如果无限制的执行命令或者读写文件,可能会产生沙箱逃逸行为,这个也需要注意。

    总结

    阿里的这篇ppt我反复阅读了几遍,其中几个点非常有启发性,比如分支展平和容器的使用,而且据说他们在整个检测中采用了200+的特性,主流的脚本语言也都覆盖到了,感觉还是很了不起的。

    不过,也正如他们所说,对抗与反对抗是个永恒的话题,没有完美的检测手段,只能在对抗的过程中不断完善自己。

    ppt下载链接

    http://yundunpr.oss-cn-hangzhou.aliyuncs.com/2020/xcon2020.pdf

    展开全文
  • 目录一、论文题目二、作者信息三、论文地址四、论文内容1.webshell检测的分类2.基于静态文本的检测3.基于动态行为的检测4.基于日志分析的监测5.future works 一、论文题目 Webshell 检测方法研究综述 二、作者信息 ...

    一、论文题目

    Webshell 检测方法研究综述

    二、作者信息

    南京林业大学,端木怡婷

    三、论文地址

    https://kns.cnki.net/kcms/detail/detail.aspx?dbcode=CJFD&dbname=CJFDLAST2021&filename=RJZZ202011020

    四、论文内容

    1.webshell检测的分类

    ①基于静态文本的检测
    ②基于动态行为的检测
    ③基于日志分析的检测

    2.基于静态文本的检测

    介绍: 通过对Webshell文本进行分析,总结特征从而实现检测目的的方法。静态方法中,又有基于特征匹配和基于机器学习等方法。

    分类:

    • 基于特征匹配的检测
    • 基于机器学习的检测

    优点: 检测率高,检测特征明显,研究多集中于此。

    相关论文:

    • Behrens S,Hagen B.Web shell detection using NeoPI [EB/OL].(2012-04-13)[2017-11-6]

      备注:Ben Hagen于2011年涉及实现了NeoPI检测器,用于对文件而易行进行定量检测。该工具对文本的最长字符长度、信息熵、重合指数、已知恶意代码字符串以及文件压缩比等分析待测文件,但该工具只对文件做定量结论,而不做定性评价。

    • (待整理)

    3.基于动态行为的检测

    介绍: 对Webshell执行时的行为特征进行分析,从而对webshell进行检测。目前,基于动态行为的检测大致分为流量检测、敏感函数检测两种方法。

    理解: webshell通常带有系统调用、配置、数据库操作等动作,这些行为会导致通信流量中出现明显具有特征的参数,通过匹配这些特征,可以实现对webshell的检测。

    分类:

    • 基于流量的检测
    • 基于敏感函数的检测

    相关论文:

    • 关洪超.基于HTTP流量的Webshell检测研究[D].北京:北 京邮电大学,2019.

      关洪超在前人基础上,提出了基于HTTP流量的webshell攻击检测技术框架,在其检测框架中,也应用了卷积神经网络和循环神经网络等机器学习算法。但是作者指出,其检测框架只对行为结果做出判断,而对攻击过程中各个阶段的检测与判断尚未实现,另外对于攻击目标和源头的追踪也待进一步研究。基于流量检测的方法,鉴于流量数据庞大、复杂等特性,在数据清洗、特征提取、实时效用等方面还存在制约,需要结合机器学习深度学习等技术,实现突破性发展。

      即:作者只能判断是否是webshell攻击,但webshell攻击分为了各个阶段,无法进一步拆分进行判断。【思路:能不能进一步拆分,如果webshell分为多步,在进行第1步时或者前几步时就可以进行一遍过滤和判断。虽然webshell可能进行多步攻击,但其实每步攻击时已经会暴露部分恶意行为了】

    4.基于日志分析的监测

    介绍:通过对web日志中记录的页面请求进行分析,看是否存在恶意行为。(比如一个get请求的接口,日志中发现又有过POST进行请求的,或者说某个IP/某个时间会有规律的进行访问)

    5.future works

    应用场景: 高校各类网站(作者是高校网络安全部分的工作者,Webshell攻击已成为影响学校网络安全的重要因素)

    未来工作:
    ①加大机器学习的研究,算法跨领域的适用、不同算法的选择、参数的设置以及样本数据结构化处理等。
    ②主动防御,利用蜜罐技术、社会工程学,加强对攻击的追根溯源、及时响应。
    ③资源使用与检测效率之间的平衡,包括大数据处理能力提升、检测模型的构建、在可承受的资源占用范围内达到更好的检测效果等。

    展开全文
  • 现有Webshell检测方法存在诸多不足,如单一的网络流量行为、简易被绕过的签名比对、单一的正则匹配等。针对上述不足之处,基于PHP语言的Webshell,提出了一种基于多视角特征融合的Webshell检测方法,首先,提取包括...
  • 本小节通过机器学习算法来识别webshell ,较新的知识点是opcode。 一、webshell WebShell就是以ASP、PHP、JSP或者CGI等网页文件形式存在的一种命令执行环境,也可以将其称为一种网页后门。黑客在入侵了一个网站后...
  • 浅谈webshell检测方法

    2021-02-26 13:54:41
    webshell中由于需要完成一些特殊的功能就不可避免的用到一些特殊的函数,我们也就可以对着特征值做检查来定位webshell,同样的webshell本身也会进行加密来躲避这种检测。下图就是一张phpwebshell的截图,它的功能...
  • 2017年10月我们上线了一版机器学习https://ml.shellpub.com, 之后...河马在线旧版机器学习查杀在样本这块白样本和黑样本的比例大约是15:10,在实际对抗中深度学习检测模块展现出了强大的能力。深度学习模块不依赖正...
  • 准确的说这篇文章是基于bert模型的webshell检测,项目地址见github。 背景知识:NLP与深度学习 NLP(Natural Language Processing,自然语言处理)是一门融语言学、计算机科学、数学于一体的科学,主要应用于机器翻译...
  • webshell检测方式深度剖析---开篇

    千次阅读 2020-06-29 15:35:37
    从本篇文章开始,笔者计划做一个关于webshell检测方式的小专题。 目的在于深入分析当前常见且流行的几类检测方式,介绍其检测原理,展现各种检测方式在检出率和误报率上的优劣势。 同时在每类检测方式中,选取一款...
  • 目录 1 问题&一些检测方法Why 2 把问题抽象出来 3 页面相似度算法 4 效果&还能做什么Result & Other
  • webshell攻击检测工具集合,包含大部分webshell检测工具
  • Webshell检测

    2020-04-14 14:52:05
    即使是一款拥有99.9%的Webshell检出率的检测引擎,依然可能存在Webshell绕过的情况。 最好的方式就是做文件完整性验证。 1、文件MD5校验,将所有网站文件计算一次hash值保存,当出现应急情况时,重新计算一次hash值...
  • 又到了周末,大好时间不能浪费,翻看之前下载的论文,发现有一篇讲述的webshell检测。通读一遍后发现作者的检测思路很新颖,但是看到后边也有些地方看的云里雾里,特写篇文章整理一下作者的思路和我的疑问,作为...
  • Linux下基于SVM分类器的WebShell检测方法研究
  • 机器学习-检测webshell

    2018-07-18 17:13:11
    基于决策树的webshell检测,k-近邻算法是基于实例的学习,使用算法时我们必须有接近实际数据 的训练样本数据,k-近邻算法必须报错全部数据集,如果训练数据集的很大 必须使用大量的存储空间,此外,由于必须对数据...
  • 基于关联分析的Webshell检测方法研究 安全建设
  • 基于BPTT算法的webshell检测研究.pdf
  • 该篇文章讲述了NeoPI如何利用统计学特征来检测webshell,笔者认为NeoPI选择的这些统计学方法在webshell检测上有些鸡肋,没有太大的实用效果。 反而其中的各种统计学方法值得学习一下,因此文章会重点讲解这些统计学...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,595
精华内容 3,438
关键字:

webshell检测