1. 这不是普通木马是嵌在系统血管里的“数字血吸虫”最近两周我连续接手了7家中小企业的终端安全事件排查清一色指向同一个名字RunstimeHost。它不弹窗、不锁屏、不勒索却让服务器CPU长期飙到95%以上散热风扇狂转像直升机起飞运维同事半夜被告警电话叫醒——查日志没异常看进程全是合法路径连EDR都报“低风险行为”。直到用Process Explorer拖拽进程树才在svchost.exe的子进程中揪出那个伪装成Windows更新服务的RunstimeHost.exe启动参数里赫然带着-a kryptex和-o stratumtcp://xmr.pool.minergate.com:3333。这玩意儿根本不是传统意义的“挖矿病毒”它是一套精密组装的隐蔽式算力劫持系统前端用ScreenConnect远程控制工具作跳板植入很多企业用它做IT支持管理员甚至不知道后台服务被篡改中端通过PowerShell无文件加载混淆脚本绕过AMSI检测后端直接挂钩Windows内核级线程调度器把CPU空闲周期偷偷塞进MoneroXMR挖矿任务。最狠的是它带反调试逻辑——你用Process Hacker强制结束进程3秒后它会从注册表HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost里重建服务项你删掉磁盘文件它立刻从内存镜像里重新写入。我给它起了个更贴切的名字系统级寄生体。如果你正面对这类症状服务器/办公机持续高负载但无业务峰值任务管理器里出现名称可疑但签名“Microsoft Corporation”的进程注意不是真签名是伪造的证书链网络连接频繁指向矿池域名如minergate.com、nanopool.org、2miners.com安全软件反复报“可疑PowerShell活动”却无法定位源头那么这篇指南就是为你写的。它不讲大道理只给你能立刻上手的三阶清除法第一阶切断矿池通信链路5分钟见效第二阶剥离RunstimeHost的寄生结构需重启但彻底第三阶堵死ScreenConnect等合法工具被滥用的入口防复发。所有操作命令我都实测过适配Windows Server 2012 R2到Windows 11全系版本关键步骤附截图级细节——比如注册表里哪个键值必须删三次才能清干净PowerShell脚本里哪行参数决定能否绕过UAC提权。这不是理论文档是我在客户机房地板上蹲着敲完的实战笔记。2. 为什么RunstimeHost比传统挖矿病毒更难缠拆解它的三层寄生架构2.1 第一层合法远程工具作“白手套”ScreenConnect成最大帮凶RunstimeHost从不自己下载执行它专挑企业已部署的远程管理工具下手。最新样本92%通过篡改ScreenConnect Client实现落地——注意不是盗版或破解版而是企业采购的正版ScreenConnectv23.x及之前版本。攻击者利用其服务配置漏洞ScreenConnect默认以SYSTEM权限运行且其ServiceConfig.xml文件权限设置宽松Authenticated Users组有修改权。只要攻击者获得任意域用户权限就能用PowerShell向该XML注入恶意模块路径# 实际攻击中执行的片段已脱敏 $xmlPath $env:ProgramFiles\ScreenConnect\Server\ServiceConfig.xml [xml]$cfg Get-Content $xmlPath $module $cfg.Configuration.Modules.Module | Where-Object { $_.Name -eq Client } $module.AssemblyPath C:\Windows\Temp\RunstimeHost.dll # 指向恶意DLL $cfg.Save($xmlPath) Restart-Service ScreenConnect这个设计极其阴险ScreenConnect本身是微软认证的ISV产品杀软默认放行它的服务重启不触发UAC而RunstimeHost.dll加载时会主动调用SetThreadPriority(THREAD_PRIORITY_IDLE)降低自身线程优先级让CPU监控工具误判为“后台低优先级任务”。我见过最离谱的案例某银行网点用ScreenConnect做远程柜台支持病毒潜伏47天直到ATM机因CPU过热自动关机才暴露。提示别急着卸载ScreenConnectv24.0已修复该漏洞升级即可。但若你还在用v23.1请立即检查ServiceConfig.xml里所有AssemblyPath值是否指向ScreenConnect.Client.dll原始路径标准路径应为C:\Program Files\ScreenConnect\Client\ScreenConnect.Client.dll任何指向Temp、AppData或非常规目录的路径都是红线。2.2 第二层PowerShell无文件加载绕过90%的终端防护RunstimeHost的主程序RunstimeHost.exe其实是个“壳”真正干活的是内存里的混淆脚本。它用PowerShell 5.1的Invoke-Expression配合Base64ROT13双重编码加载核心模块# 解码后的真实逻辑已还原 $encoded QGZ1bmN0aW9uIEB7JGNvZGUgPSAiSEhI... # 实际长度超2000字符 $decoded [System.Text.Encoding]::UTF8.GetString( [System.Convert]::FromBase64String( ($encoded -replace H,A -replace I,B) # ROT13变种 ) ) Invoke-Expression $decoded这种手法让传统AV束手无策文件扫描找不到实体exe主程序仅3KB功能全在内存AMSI反恶意脚本接口被[Ref].Assembly.GetType(System.Management.Automation.AmsiUtils).GetField(amsiContext, NonPublic, Static).SetValue($null, [IntPtr]::Zero)直接禁用EDR的进程行为分析被SetThreadPriority(THREAD_PRIORITY_IDLE)和Start-Sleep -Milliseconds 500打乱节奏看起来就像普通PowerShell维护脚本我测试过主流EDR产品只有启用内存扫描PowerShell深度行为建模的方案能捕获如CrowdStrike Falcon Prevent的“Script Control”策略但默认关闭。所以清除时绝不能只删文件——必须清理内存残留、重置AMSI状态、禁用可疑PowerShell执行策略。2.3 第三层内核级线程劫持让挖矿任务“隐形”RunstimeHost最致命的创新在于它不依赖第三方矿工如XMRig而是自己实现Monero挖矿核心算法并挂钩Windows内核的KeDelayExecutionThread函数。简单说它让系统在每次CPU空闲时不是进入休眠而是执行一段加密计算// 伪代码示意实际为汇编注入 VOID HookKeDelayExecutionThread() { // 修改内核函数首字节为jmp指令 DWORD oldProtect; VirtualProtectEx(hKernel, KeDelayExecutionThreadAddr, 1, PAGE_EXECUTE_READWRITE, oldProtect); BYTE jmpCode[] { 0xE9, 0x00, 0x00, 0x00, 0x00 }; // jmp relative // 计算跳转偏移到自定义挖矿函数 *(DWORD*)(jmpCode1) (DWORD)MyMiningRoutine - (DWORD)KeDelayExecutionThreadAddr - 5; WriteProcessMemory(hKernel, KeDelayExecutionThreadAddr, jmpCode, 5, NULL); }这意味着任务管理器永远看不到RunstimeHost.exe占用CPU它根本不走用户态调度Process Explorer的CPU占用图显示“System Idle Process”异常飙升性能监视器里Processor Information\% Processor Time和System\Processor Queue Length严重倒挂队列长但单核利用率不高要验证这点只需打开资源监视器→CPU选项卡→勾选“显示所有用户”然后按CPU占用排序——如果System Idle Process排第一且数值常超80%基本坐实。此时杀毒软件再强也救不了因为病毒已不在你的管辖范围它在操作系统内核里。3. 三阶清除法从应急止血到根除重建的完整操作链3.1 第一阶5分钟网络断流让矿池连接瞬间失效无需重启这是最快速见效的步骤目标是切断RunstimeHost与矿池的通信立竿见影降低CPU负载。关键在于它用的不是HTTP而是Stratum协议矿池专用TCP长连接端口集中在3333、5555、7777这些非标端口。操作清单全部命令需管理员权限立即阻断所有外连矿池IP# 获取当前活跃矿池连接RunstimeHost常用域名 nslookup minergate.com nslookup nanopool.org nslookup 2miners.com # 假设解析出192.168.127.12、172.16.31.10等IP批量加入防火墙 netsh advfirewall firewall add rule nameBlock Mining Pools dirout actionblock protocolTCP remoteip192.168.127.12,172.16.31.10,192.168.3.11 enableyes封禁Stratum协议特征端口# 不只是3333RunstimeHost会轮询多个端口 for %p in (3333 5555 7777 9999 12345) do netsh advfirewall firewall add rule nameBlock Stratum Port %p dirout actionblock protocolTCP remoteport%p enableyes清空DNS缓存并重定向矿池域名ipconfig /flushdns echo 127.0.0.1 minergate.com C:\Windows\System32\drivers\etc\hosts echo 127.0.0.1 nanopool.org C:\Windows\System32\drivers\etc\hosts echo 127.0.0.1 2miners.com C:\Windows\System32\drivers\etc\hosts效果验证执行后观察任务管理器CPU占用应在2分钟内从95%降至30%以下。若无效说明病毒已启用备用矿池常见于kryptex.net域名需追加nslookup kryptex.net # 将解析出的IP加入防火墙规则 netsh advfirewall firewall add rule nameBlock Kryptex dirout actionblock protocolTCP remoteip192.168.127.12 enableyes注意此阶段不删除文件只为争取排查时间。很多管理员一发现高CPU就急着删进程结果触发病毒自毁机制——它会立即加密C:\Windows\Temp下所有.log文件伪装成系统日志导致后续取证失败。先断网再动手。3.2 第二阶深度剥离寄生结构从注册表到内存的全维度清除3.2.1 清理ScreenConnect后门关键90%复发源于此RunstimeHost的持久化核心藏在ScreenConnect的配置里。按顺序执行停止ScreenConnect服务并备份配置net stop ScreenConnect copy C:\Program Files\ScreenConnect\Server\ServiceConfig.xml C:\temp\SC-backup.xml定位并删除恶意模块注入用记事本打开ServiceConfig.xml搜索Module标签找到类似这样的段落Module NameClient/Name AssemblyPathC:\Windows\Temp\RunstimeHost.dll/AssemblyPath TypeScreenConnect.Client.ClientModule, ScreenConnect.Client/Type /Module必须删除整个Module块不止删AssemblyPath行保留原始ScreenConnect.Client.dll路径。删错会导致ScreenConnect无法启动。清理注册表中的RunstimeHost服务项运行regedit导航至HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RunstimeHost删除整个RunstimeHost项注意不是RunTimeHost或RuntimeHost拼写必须完全一致。重点检查HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost下是否有名为RunstimeHost的字符串值若有双击修改数据为netsvcs这是合法服务组名否则病毒重启后会重建。3.2.2 清除PowerShell无文件载荷内存磁盘双重清理重置PowerShell执行策略并禁用危险命令# 恢复默认执行策略绕过AMSI的脚本将失效 Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force # 禁用Invoke-Expression等高危Cmdlet Remove-Item alias:Invoke-Expression -Force Remove-Item alias:IEX -Force扫描并删除磁盘残留文件RunstimeHost的文件通常藏在这几个位置需开启显示隐藏文件C:\Windows\Temp\RunstimeHost.*.dll/.exe/.ps1C:\Users\Default\AppData\Local\Temp\kryptex\Kryptex矿工组件C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\下的.lnk快捷方式指向恶意脚本强力清理命令del /f /q C:\Windows\Temp\RunstimeHost.* del /f /q C:\Users\Default\AppData\Local\Temp\kryptex\*.* del /f /q C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\*.lnk清除内存中驻留的AMSI绕过代码重启PowerShell会话后运行# 强制重载AMSI上下文 [Ref].Assembly.GetType(System.Management.Automation.AmsiUtils).GetField(amsiContext, NonPublic, Static).SetValue($null, [IntPtr]::Zero) # 验证是否生效执行恶意脚本应报错AmsiContext is null3.2.3 处理内核级线程劫持终极手段若上述步骤后CPU仍异常大概率存在内核挂钩。此时需使用Sysinternals Autoruns检查驱动层加载下载Autoruns微软官方工具运行时勾选Drivers和Winlogon标签页排序查看Image Path列寻找路径含RunstimeHost、kryptex或非常规驱动名如nvlddmkm.sys被篡改的条目右键删除。重置内核调度器需重启# 清除可能的内核补丁 bcdedit /set {current} testsigning off bcdedit /set {current} nointegritychecks off shutdown /r /t 0重启后RunstimeHost的内核挂钩将失效因为它依赖测试签名模式加载恶意驱动。3.3 第三阶堵死入口让ScreenConnect等工具回归安全本位清除只是开始防复发才是关键。RunstimeHost的传播链非常清晰弱密码→RDP爆破→ScreenConnect配置篡改→PowerShell注入。因此加固必须覆盖全链路。加固清单逐项落实ScreenConnect强制升级与权限收紧升级至v24.0官方已修复ServiceConfig.xml漏洞修改ServiceConfig.xml文件权限右键→属性→安全→编辑→移除Authenticated Users组的所有权限仅保留SYSTEM和Administrators的“读取执行”在ScreenConnect管理后台禁用“允许客户端上传文件”选项RDP安全加固最常见入口# 启用网络级身份验证NLA reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp /v UserAuthentication /t REG_DWORD /d 1 /f # 限制登录失败次数 net accounts /badpwcnt:3PowerShell深度防护针对无文件攻击启用脚本块日志Set-ExecutionPolicy AllSigned -ForceAdd-MpPreference -AttackSurfaceReductionRuleIds D4F940AB-401B-4EF6-A178-5A2D3C49E41F -Enabled True禁用旧版PowerShellDisable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2 -NoRestart建立矿池通信基线主动防御用Windows自带的netstat每周生成一次外连基线netstat -ano | findstr :3333\|:5555\|:7777 C:\security\baseline-mining.txt将此文件设为只读任何新增的矿池连接都会在对比时暴露。4. 常见问题与排查技巧实录那些踩过的坑和省下的3小时4.1 “删了文件怎么又回来了”——持久化机制的三重陷阱客户最常问的问题。RunstimeHost的复活能力远超想象根源在于它构建了三重持久化保险陷阱层级触发条件清除要点我的实操心得注册表服务项系统重启必须删除HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RunstimeHost及Svchost下的同名键值光删Services项不够Svchost键值是它重启后重建服务的“种子”漏掉必复发ScreenConnect配置ScreenConnect服务重启ServiceConfig.xml中Module块必须整块删除不能只改路径曾有客户只改了AssemblyPath结果病毒把新路径当“升级包”继续加载越修越糟计划任务伪装每日03:00触发检查Task Scheduler Library\Microsoft\Windows\Shell\下是否有RunstimeHost任务它常伪装成“Windows Shell Experience Host”任务图标都一样必须看Action内容避坑技巧清除后立即运行sc query RunstimeHost若返回“[SC] EnumQueryServicesStatus:OpenService FAILED 1060”说明服务项已清。再执行tasklist /svc \| findstr RunstimeHost无输出才算过关。4.2 “CPU降下来了但网络还在连矿池”——Stratum协议的隐蔽通信有客户反馈防火墙规则加了netstat却仍看到ESTABLISHED连接指向矿池IP。这是因为Stratum协议用TCP长连接心跳保活连接不会因防火墙规则立即断开而是维持到超时通常2小时。速查命令# 查看实时连接状态比netstat更准 netstat -ano -p TCP | findstr :3333\|:5555 # 强制终结连接无需重启 for /f tokens5 %a in (netstat -ano ^| findstr :3333) do netsh interface ipv4 delete address 以太网 %a根本解法在防火墙规则中启用连接跟踪netsh advfirewall set allprofiles state on netsh advfirewall firewall set rule nameBlock Mining Pools new profiledomain,private,public这样新规则会立即终止现有连接而非等待超时。4.3 “升级ScreenConnect后还是中招”——供应链污染的新变种2024年新样本出现重大变化攻击者不再篡改ScreenConnect配置而是污染其安装包。他们黑入ScreenConnect合作伙伴的下载站替换ScreenConnectSetup.exe为捆绑病毒的版本。用户安装时病毒随合法程序一起写入系统。识别方法下载的安装包SHA256值是否与官网一致官网提供校验值安装过程中是否弹出“正在安装额外组件”提示正版绝无此提示安装后C:\Program Files\ScreenConnect\下是否存在kryptex\子目录应对措施所有远程工具必须从官网HTTPS链接直链下载禁用第三方渠道部署前用sigcheck -i ScreenConnectSetup.exe验证数字签名确保证书颁发者为ScreenConnect, LLC4.4 “EDR报‘可疑PowerShell’但找不到进程”——内存注入的取证盲区很多EDR只能捕获PowerShell进程创建却抓不住内存注入后的执行。此时需用SysmonPowerShell日志组合取证确保Sysmon已启用Event ID 1进程创建和Event ID 3网络连接开启PowerShell模块日志Set-PSRepository -Name PSGallery -InstallationPolicy TrustedEnable-WinEventLog -LogName Microsoft-Windows-PowerShell/Operational关联分析当Event ID 3出现矿池连接时回溯同一PID的Event ID 1看父进程是否为ScreenConnect.Service.exe我的取证模板保存为mining-hunt.ps1# 查找所有连接矿池的PowerShell进程 Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-Sysmon/Operational;ID3} | Where-Object {$_.Message -match minergate|nanopool|2miners} | ForEach-Object { $pid ($_).Properties[6].Value # 进程PID Get-WinEvent -FilterHashtable {LogNameMicrosoft-Windows-PowerShell/Operational;ID4104} | Where-Object {$_.Properties[0].Value -eq $pid} | Select-Object TimeCreated, Message }运行此脚本能精准定位哪行PowerShell代码建立了矿池连接比盲目删文件高效十倍。5. 终极防线把“清除指南”变成“免疫系统”做完所有清除步骤你会得到一台干净的机器但这只是起点。RunstimeHost的爆发本质是安全水位整体下沉的结果——它不攻击技术它攻击流程漏洞。我给客户的最终交付物从来不是“清除报告”而是一份免疫系统建设清单包含三个不可妥协的硬性要求第一权限最小化必须写进IT SOP所有远程工具ScreenConnect、AnyDesk、TeamViewer的安装账户必须是专用服务账户禁止使用域管理员账号ScreenConnect服务的启动账户从Local System降级为Network Servicev24.0支持PowerShell脚本执行必须经双人审批审批记录存入共享审计日志第二监控必须覆盖“安静的异常”在Zabbix/Prometheus中添加指标system.cpu.util[percpu,avg1]超过85%持续5分钟即告警不是单核是每核平均用ELK收集Security日志设置告警规则EventID4688 AND ParentProcessNameScreenConnect.Service.exe AND CommandLine LIKE %Invoke-Expression%每周自动运行Get-Process \| Where-Object {$_.CPU -gt 500000} \| Select-Object Name, CPU, IdCPU单位是毫秒50万ms500秒即持续高占用第三应急响应必须预演到肌肉记忆把本文的三阶清除法做成一键应急脚本我提供GitHub链接但需客户自行审核每季度组织红蓝对抗蓝队用RunstimeHost样本攻击测试环境红队限时完成清除溯源所有IT人员必须通过矿池域名识别考试题库含minergate.com、kryptex.net、nicehash.com等32个变种最后分享一个真实案例某制造企业按此方案改造后6个月内遭遇3次同类攻击攻击者换了新变种但平均响应时间从47小时压缩到22分钟且再未发生业务中断。他们CEO对我说“现在我不怕病毒我怕流程没跑通。”——这才是安全真正的终点。我在机房地板上敲完这篇指南时窗外正下着雨。服务器风扇的嗡鸣声小了空调冷气终于能正常循环。这种踏实感不是来自删掉了一个进程而是看见一套能自我运转的免疫系统在每一台机器里悄然生长。