老师傅：“什么进程？”
练习生：“好像是叫 svchost.exe，让客户直接结束这个进程是不是就可以了？”老师傅：“手下留情，千万别结束，万一客户系统崩了咱可担不起啊！”对于很多同学来说，svchost.exe 进程简直就像蒙娜丽莎的微笑一样神秘，说不清道不明，今天，师傅我就带你们揭一揭它的神秘面纱，看看它到底是个什么玩意。
服务
首先，我们来了解下什么是服务。在系统启动后，会有一个 services.exe 进程被启动，这个进程就是系统的服务控制管理器（SCM），由它启动的进程就是我们所说的服务。我们可以通过 ProcessExplorer 发现，所有的 svchost.exe 的父进程都是 Services.exe。也就是说，服务其实就是一组特殊的进程，这类进程的启动和运行完全不需要用户干预，会随着系统的启动而自动开始工作，为系统运行提供基础功能，比如网络服务、磁盘、键盘、鼠标等硬件管理服务。
svchost.exe
微软官方解释：svchost.exe 是从动态链接库 (DLL) 中运行的服务的通用主机进程名称。svchost.exe 是一个系统共享进程，我们可以把他理解为一个宿主或者容器，本身没有任何服务功能，Windows 操作系统将大部分的服务封装在了一个个 DLL 动态链接库中，想要启动哪个服务，就把服务所需的 dll 交给 svchost.exe，让 svchost 统一去加载启动就可以，这就是我们在查看进程时，会发现密密麻麻一大堆 svchost.exe 进程的原因。打开 Windows 任务管理器，我们看到的一堆名称为“服务主机”的进程，大部分都是 svchost.exe 启动的服务进程。当然，凡事都有例外，个别服务是通过直接注册可执行文件来实现，并不会通过 svchost.exe 这类进程调用。
这里也需要注意下不同版本的系统 svchost.exe 进程的数量也是有区别的：
问：为什么要启动一大堆的 svchost.exe 进程，在一个 svchost.exe 进程中运行服务岂不是很清爽？？答：你买基金会把所有的钱投在同一个行业上么？同理，微软为了保持系统的稳定性，将不同的服务注入到多个 svchost.exe 进程中，就是为了防止单个服务进程奔溃而导致所有的服务都挂掉。那 svchost.exe 作为一个共享进程，是怎么实现在系统启动时将各个服务启动的呢？与 svchost.exe 相关的注册表主要有两个：一个记录服务组的包含关系，另一个记录具体服务的细节信息。
# 服务组HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost# 服务HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service
svchost 注册表项对服务进行分组管理，只要是需要 svchost.exe 去启动的服务，都要放在这里。
系统启动后 svchost.exe 首先根据这里的键值来管理 DLL 的加载，这里的每一个键值同时也对应着一个 svchost.exe 进程，也就是同组服务共用一个 svchost.exe 进程。（注意这里的服务组不会一次性全部加载，而是根据需要加载）。
当加载组中具体的某个服务时，svchost.exe 则会根据 Service注册表项中对应的服务项读取服务的详细信息。
我们前面说过，系统服务是以动态链接库（dll）的形式实现的，因此，在“服务”注册表项中，以“RpcSs”服务为例，我们可以看到在“ImagePath”键中指定了此服务通过 svchost.exe 启动，那 svchost.exe 在执行时具体去哪里找实现这个服务的 dll 文件呢？答案就在该服务的子项“Parameters”的“ServiceDll”键值中记录。
至此，svchost.exe 找到了要加载的服务的 DLL 文件位置，然后加载运行，一个服务的启动就完成了。注意：在启动一个 svchost.exe 负责的服务时，服务管理器如果遇到可执行程序内容 ImagePath 已经存在于服务管理器的映象库中，就不在启动第2个 svchost.exe 进程，而是直接启动服务。这样就实现了多个服务共享一个 svchost 进程。
svchost.exe 参数
在分析 svchost.exe 进程时，由于进程名都一样，直观看起来并没有什么大的区别，这时候我们可以选择显示命令行 “Commandline” 字段（也就是上面 services 注册表项中的 “ImagePath” ），通过它的执行参数来进行区分，在查看命令行参数时，我们最常见的主要有以下三个参数：-k // 指定服务组，在指定注册表中寻找该服务组，并加载该组中引用的每个服务-s // 指定服务，从指定的服务组中启动该服务-p // Windows10 新增的 ACG（任意代码防护）安全机制，强制执行以下策略来保护进程： // BinarySignaturePolicy：签名校验策略，阻止未（经过微软）签名的模块加载 // DynamicCodePolicy：进程动态代码策略，阻止进程生成动态代码或修改现有的可执行代码 // ExtensionPointDisablePolicy：扩展点禁用策略，阻止使用某些内置的第三方扩展点
用户视角：svchost.exe 作为一个系统进程，伴随着系统的运行而运行，托管着众多的功能服务为系统正常运转提供支撑，普通用户自然也不敢对这个进程怎么滴！黑客视角：能把自己伪装成系统进程，还能伴随着系统启动而自动运行，还不容易被发现，发现了也轻易不敢把我怎么滴，这不就是我想要的么～～～
1.青铜选手
假装自己就是 svchost
这类手法比较低级，很容易被分析人员识破，算是上古时期的利用手法了，现在偶尔也能碰到。主要通过名称或者路径混淆来伪装自己：一种是将与 “svchost.exe” 相似名称的木马文件放置在系统路径下；另一种是在其他系统路径下放置恶意的 “svchost.exe” 文件。
务必要牢记 svchost.exe 在系统磁盘上的两个路径，如果出现在其他地方就要注意了。
# 环境变量 %systemroot% 为系统根目录，一般为 “C:\Windows”，可以通过 set 命令查看%systemroot%\System32\svchost.exe%systemroot%\Syswow64\svchost.exe（32位）
⚠️ 利用名称混淆伪装，假装自己是 svchost.exe 进程，像这样的：
svch0st.exesvchsot.exescvhost.exescvh0st.exesvhost.exesvchosl.exe...
⚠️ 利用系统路径以外的目录存放恶意 svchost.exe 执行文件，假装自己是系统文件，像这样的：C:\SysDayN6\svchost.exeC:\Syswm1i\svchost.exeC:\SysAd5D\svchost.exeC:\SysWsj7\svchost.exeC:\windows\system32wins\svchost.exe...
我们了解了服务和 svchost.exe 的原理，那怎么去创建一个 svchost.exe 启动服务也就简单了，这也是很多木马作者常用的一种权限维持手段：创建自启动服务。
- 在 Service 注册表项中注册服务的基本信息，如：Description、Displayname、ImagePath、Type、Start 等，以及设置 Servicedll 项指定后门 DLL 文件的位置；
- 在 svchost 注册表项中将要启动的后门服务放置到现有服务组中或者新建一个服务组；
- 编写实现恶意功能的 dll 文件，封装服务所需的 ServiceMain 导出函数；
- 将上述过程封装在一个 .exe 的可执行文件中，即完成了一个通过服务驻留的木马。
当然，每个能制作木马的作者都有一颗聪慧的头脑，怎么会如此按部就班呢？他们还可以这样：- 利用已经在系统中，但没有被安装使用的服务，修改其 DLL 指向与启动方式；
我们前面也有提到，并不是所有的服务都会通过 svchost.exe 调用实现，以 Metasploit 为例：在获取到目标主机的 Meterpreter 之后，可以使用“run metsvc”命令在目标主机上注册一个名为 metsvc 的服务，注册的方式则是直接将恶意的可执行文件直接注册为服务。
3.钻石选手
对于 dll 劫持和注入，算是属于比较高端一点的技术了，区别就是一个主动一个被动：- dll 劫持：程序在启动时主动加载事先放置好的恶意 dll（圈里常说的“白+黑”技术其实就是 dll 劫持技术，让一个正常的应用程序在启动过程中加载事先放置的恶意 dll）。
- dll 注入：将一个恶意 dll 放进正在运行的进程的内存空间中，让这个 dll 成为他的一部分，创建定时的线程被动运行 dll 。
综上，dll 劫持和注入都是让进程运行一个不属于它的 dll。而进程实际是一个容器，任何时候一个进程加载或卸载库，会创建一个新线程，执行具体的任务都是由线程来完成。我们不难得出，一个被 dll 劫持/注入的进程，肯定会增加一个子线程来去执行这个恶意的 dll。那同样，作为系统进程的 svchost.exe，也是被黑客注入的目标之一。其实微软在 Windows Vista 开始就对系统进行了会话分离，将系统服务运行在 session 0 会话中，应用程序则使用单独的会话，甚至在 Win10 开始加入了 ACG 策略，一定程度上保证了系统进程的安全，不那么容易被注入恶意 dll，但这同样难不倒聪明的黑客！4.星耀选手
通过安装服务或劫持 dll 的方式来执行木马，由于没有签名，很容易被发现。于是，聪明的黑客又想到了可以将恶意代码直接拷贝到正常进程的内存中，让进程去执行。广义上来讲，傀儡进程是一种进程伪装手法，通过进程替换（Process replacement）技术来实现，即攻击者在系统上挂起一个正常的进程，然后重写该进程内存空间，填充 shellcode 或其他可移植 PE，实现正常进程执行恶意代码的目的。但是要让这个进程去运行被写入的恶意代码，就要修改进程的执行流程，将入口点指向恶意代码。所以，傀儡进程的本质就是替换进程的主线程，进程原有的功能会被抹去，只用于执行恶意代码，（有的同学可能会认为 DLL 注入也属于傀儡进程的实现，但其实这两种技术本质上是存在区别的，DLL 注入技术一般不会影响目标进程的执行流程和原有功能）。因此，对于傀儡进程而言，看起来和正常的进程没什么区别，但是它的内在早已经不是原来的他了，其真实要完成的任务已经被替换了。关于如何利用 svchost.exe 创建傀儡进程的技术细节，可以参考下看雪大佬的文章《另类注入傀儡进程测试》。针对 DLL 劫持/注入和傀儡进程的技术细节本文不做深入探讨，后续会针对性发表相关技术文章。
5.王者选手
太 Low 了，不会真的有人不会 Rootkit 吧～～～
魔高一尺，道高一丈，面对不同的利用手段，分析人员也得有自己的一套战技法or技战法！1、定位进程
要排查一个运行中的恶意程序，首先得定位到恶意进程，一般的方法都是通过网络行为来定位是哪个程序在发起恶意请求，比如监控域名请求和TCP会话，有很多工具去实现，这里就不详细解释。- netstat：通过查看已经建立连接的 TCP 会话定位
- ProcessMonitor：通过捕获网络日志定位
- DNSQuerySniffer：通过捕获 DNS 请求源端口，结合 Monitor 定位
通过火绒剑进程监控发现 svchost.exe 进程请求恶意域名其次，还可以使用一些内存字符串搜索工具，来定位存在恶意域名/IP字符的可疑进程。（此类工具可能会定位到其他无关进程，需要对进程有一定的辨别能力）;
通过微步在线威胁检索工具发现两个可疑的 svchost 进程存在恶意 IOC 字符串在日常分析中，我们经常会通过抓取恶意域名请求来定位恶意进程，如果定位最终指向 svchost.exe 进程，而我们在查看进程命令行时，可以看到svchost -k NetworkService -p -s Dnscache 这样的参数，其实这是系统的 DNS 缓存机制：大部分应用程序进程进行域名解析时，会通过 RPC 传递到 Dnscache 服务进行 DNS 缓存（ipconfig /displaydns的结果就是他的功劳），而这两个服务都是通过 svchost.exe 启动的，因此并不代表该进程就是恶意进程。
2、火眼金睛
对付一些仿冒 svchost.exe 的恶意程序，我们可以通过 tasklist 命令来查看每个 svchost.exe 启动的服务，如果某个 svchost.exe 对应的服务显示“暂缺”，就说明该进程所提供服务对应的 dll 存在缺失，这种情况说明该进程大概率就不是给我们系统提供服务的进程，只需根据 PID 对应具体的进程信息，查看可执行文件路径，然后通过沙箱等方式判断是否为恶意程序。
tasklist /svc | findstr "svchost"
根据进程 ID 发现非 Syswow64 目录下的 32 位 svchost.exe 程序面对这类最基本的伪装技术，能做的就是擦亮眼睛，牢记正版 svchost.exe 的名称及路径，对其他一切“易容者”都保持怀疑态度。通过任务管理器、ProcessExplorer 等进程管理工具，对名称、路径、描述信息、启动时间、签名等字段进行简单分析：定位到可疑的执行程序后，最简单的判断方法就是直接上传微步云沙箱或者 Virustotal 一把梭，自会见分晓～3、服务分析
对付一些利用服务自启动的恶意程序，我们可以使用系统自带的服务管理器或第三方工具对服务进行分析：- 启动文件不在系统目录下的服务（如：Temp、Desktop等目录）
- 没有数字签名的服务（Power Tool 等工具可以直接过滤非微软服并校验签名）
- 通过火绒剑等工具查看服务的导入模块，是否存在没有描述信息或签名的 dll 文件
- 查看 svchosts 注册表项，是否存在未知的服务组，或已有服务组中是否存在可疑的服务
- 查看 services 注册表项，是否存在随机命名的服务
通过 Power Tool 发现无签名、无描述信息、启动目录可疑的 Metasploit 后门服务
4、进程分析
针对 dll 注入这类攻击手法，我们要了解 dll 注入的本质：在目标进程中增加一个线程，通过 LoadLlibrary 等方式来载入目标 dll。所以，我们可以着重从可疑进程的线程入手，查看是否存在没有描述及模块信息的可疑的线程。
根据可疑线程的内存地址，可以进一步查看其内存片段，在火绒剑中，如果内存片段存在异常，会直接标红显示，针对异常的内存片段可继续查看其内存字符串或者转储分析，有可能就会发现惊喜！
异常的内存片段中发现可疑的 powershell 代码
除此之外，我们还可以通过 PEView 等工具查看可疑进程磁盘镜像文件的导入表，记录其导入的 DLL 文件，然后使用进程分析工具查看该进程已装载的模块信息，与导入表 DLL 比较，如果存在多余的 DLL 文件，就需要注意了！5、内存分析
对于确认存在问题的恶意 svchost.exe 进程，如果没有发现加载可疑的 DLL 及可疑服务驻留，那么它可能就是一个傀儡进程，我们可以使用 ProcessExplorer 来对比查看其可执行文件字符串和内存字符串是否存在巨大差异，一般两者的内容是相同的，如果这两个字符串列表有很大差异，那么就很大概率说明发生了进程替换。
同一个 svchost.exe 进程，磁盘镜像字符串和内存镜像字符串存在差异
确认了异常，我们可以检查其内存字符串，是否存在可疑的域名、IP 或其他可疑字符串，如：文件路径、注册表等。
查看 svchost.exe 进程内存，发现 IOC 字符串其次，我们可以进一步对该进程进行内存转储 dump 然后进行分析，常用的任务管理器、火绒剑和 Prodump 等工具都可以执行内存转储操作，这类 Dump 可以将目标进程的数据区、堆栈信息以及线程等信息保存到 .dmp 文件，针对转储的 .dmp 文件，最直观的方法就是使用 windbg 等工具直接查看其线程、句柄以及字符串等信息。更进一步，还可以使用 PEDump 等工具将目标进程加载的文件进行转储，这类 Dump 的结果是 PE 文件，可以使用 IDA 或 OD 等工具深入分析，尝试提取其注入的 PE 文件或 shellcode。dump 出 svchost.exe 内存分析发现可疑 Wechatweb.exe 程序进程替换技术实现的傀儡进程为恶意代码提供了和其他进程一样的特权，恶意进程看起来就是一个合法进程，但是它在内存中的镜像会和磁盘上的不一样，而我们使用的ProcessExplorer等工具来验证签名是对磁盘上的文件进行验证，所以一个傀儡 svchost.exe 进程可以通过微软的验证，但他实际上是个恶意程序。特别鸣谢微步应急扛把子“乔峰扛着音响来了”对笔者的技术指导，本篇文章旨在带大部分入门应急响应的小伙伴了解 svchost.exe 进程及背后的机制，以及在应急响应实战中如何分析的一些小技巧，希望能对大家带来帮助。
在真实的应急场景中，我们不能将眼光只局限于 svchost.exe 这个进程，面对其他进程的 dll 注入、dll 劫持、白加黑等利用手法，我们同样可以使用这些技巧进行分析，后续我们会根据真实的病毒样本或应急案例带大家进行实际的分析运用，敬请期待～～～
各位看官朋友们，今天的内容就到这里了，如果觉得不错还请动动小手点赞收藏关注+转发～
注：部分图片来自网络，如有侵权，联系删除。
400 186 1886
