个人电脑中挖矿病毒程序 一把梭直接定位到人

阅读须知

文章仅供参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。利用此文所提供的信息而造成的直接或间接后果和损失，均由使用者本人负责。本文所提供的工具仅用于学习，禁止用于其他！！！

前言

朋友抱怨自己的服务器非常卡，因为存储了很多项目资料和集成了众多环境。作为好友，我自然义无反顾地帮他检查。原本以为仅需进行简单的杀毒和文件整理便足够，但最终这个过程花费了不少时间。正好借此机会记录下整个过程，并写成这篇文章。

清除病毒

询问朋友是否下载了什么或在电脑上搭建了些什么，他回答说不知道，让我自己检查。当时我真想通过远程桌面（3389端口）过去给他一个响亮的耳光。但最终还是决定亲自处理。打开任务管理器，立刻注意到几个可疑的powershell进程。

PowerShell进程的占用率高居榜首，但具体执行的命令尚不明确。此时，利用WMIC工具可以查看进程在执行时的命令行参数，帮助进一步诊断问题。通过以下参数获取相关信息：

• Caption: 显示进程名称
• CommandLine: 展示具体的命令行参数
• ParentProcessId: 显示父进程的PID
• Process: 表示进程的PID

PowerShell中执行了一段被混淆的代码，这不是正常程序的典型行为。市面上有多种工具可以用来分析这类情况。可以使用火绒剑、ProcExp（Process Explorer）、或者ProcessHacker这些工具来查看命令行参数，进而帮助识别和解析这些可疑的操作。

使用火绒剑终止了PowerShell进程后，如果该进程再次出现，这表明存在一个守护进程，刚才终止的很可能只是一个子进程。此时，应该终止整个进程树以彻底根除问题。需要定位到PowerShell的父进程，并结束整个进程树，以防止潜在的挖矿程序重新启动。

使用wmic命令，找到相关进程

已确定进程ID为3616的进程。

已定位到进程ID为3604的进程。

已经找到了进程ID为3500的相关联进程。

以火绒剑工具为例，检查进程时发现，在列表的最下方，有5个以PID 3652运行的PowerShell进程，这些都是子进程。同时，PID为1972的scvhost.exe则是所有挖矿程序的父进程。

为彻底解决问题，可以直接结束整个进程树，这将同时终止父进程和所有相关的子进程。这一操作可以阻止挖矿程序的再次启动，并清除所有相关的恶意活动。

清理工作完成。

审计日志

关键在于找出是如何被侵入的。我特别检查了RDP日志，并查阅了安全日志，包括4624（登录成功）和4625（登录失败）事件。结果确实显示出有成功的登录记录。

接着我检查了注册表，看是否有新建的账户。果然，发现了一个隐藏的影子账户。

立即删除了该账户，并检查了启动项，这样一来便清楚了整个情况。

删除启动项

查看计划任务

为了验证进程和启动项的一致性，我计算了相关文件的MD5值。这样可以确保它们是匹配的。

certrutil -hashfile file MD5

我同样删除了所有相关项，认为处理已经完成。然而，在进程列表中，我意外地发现了phpstudy运行的痕迹。确实，由于桌面上没有图标，我之前未加以注意，这是我的疏忽。

随即，我使用了WebShellKiller工具对系统中的全局文件进行了彻底扫描，以确保没有遗漏任何潜在的威胁。

我用WebShellKiller进行了全面扫描，但没有发现任何异常。随后，我又使用了火绒病毒查杀工具进行检查，结果同样没有发现任何问题。

尽管扫描工具未发现任何问题，我依然不相信系统中没有后门。于是我决定亲自查看www目录下的每个文件，这个过程非常耗时且让人疲惫。经过长时间的搜索，我最终在news.php文件中发现了异常，如果不亲自打开查看，根本无法知晓。这个后门的免杀处理做得相当精巧。

在清除了潜藏的免杀马之后，我继续查看了web服务器的日志文件。在Apache的access.log和error.log中，我发现了一些特定的访问记录。这些记录显示某个IP在以下时间访问了phpMyAdmin：

• [14/Dec/2020:14:26:37 +0800] 发送POST请求到 /phpMyAdmin-4.8.1-all-languages/version_check.php，响应状态码200，返回了28字节。
• [14/Dec/2020:14:26:46 +0800] 发送POST请求到 /phpMyAdmin-4.8.1-all-languages/logout.php，响应状态码302，返回了8637字节。
• [14/Dec/2020:14:26:51 +0800] 发送GET请求到 /phpMyAdmin-4.8.1-all-languages/index.php，响应状态码200，返回了3497字节。

这些记录揭示了使用的是phpMyAdmin的4.8.1版本。

最初我怀疑是通过暴力破解方式侵入的，但现在一切都清晰了。使用root/root这样简单的用户名和密码组合，几乎没有人会拒绝，尤其是考虑到我的朋友不太可能设置复杂的密码。这种情况下，即使是最基本的尝试也能轻易猜到密码。

反查追踪

确认了入侵点之后，我已经完成了清理工作，并获取了攻击者的IP地址。接下来，我打算进行溯源分析，于是启动了微步在线安全平台，以深入调查此次入侵的背景和攻击者的可能身份。

在确认攻击源后，我发现攻击IP自2018年以来就被标记为僵尸网络中的一员，且服务器位于日本，这使得溯源攻击者变得更加困难，很可能这台机器只是被利用作为肉鸡。这时，我回想到手头还有挖矿病毒的样本，决定先对这些样本进行分析。

我将主要的挖矿程序Systems.exe放入沙箱环境中运行，以隔离和观察其行为。此外，还有一个批处理文件Cmd1.bat和一个Windows命令脚本start.cmd，以及其他几个作为混淆用的无效文件。

下面是挖矿程序的详细信息：

• 样本名称： systems.exe
• 样本大小： 3662336字节
• MD5： 4d8a76f89b0a68a6d5fc5b1b95257ec0
• SHA1： d25a722636f2c1de313d481733b9c397925675eb
• SHA256： eb1d6f905efcb27544c43e9107735a2160c3fa7180eff121a701dc6655ae0242

Cmd1.bat文件的作用是安装名为Networkss的恶意服务，设置start.cmd脚本自启动，并将nat目录下所有文件设置为只读的隐藏系统文件。而start.cmd则用于启动挖矿主程序并连接到矿池地址。svchost.exe文件则用来将自定义服务伪装成系统服务。

继续追踪被攻击的机器，我使用了一款插件简单检查了开放的端口，并发现6379端口（通常用于Redis服务）是开放的。为了进一步了解此端口的配置和潜在的安全风险，我决定使用nmap进行详细探测。

执行的nmap命令如下：

nmap -A -p 6379 --script redis-info [IP地址]

这条命令将对目标IP地址的6379端口进行详细扫描，使用redis-info脚本来获取Redis服务器的配置和状态信息，以帮助评估安全性和任何可能的配置错误。

在详细探测后，我尝试直接远程登录到开放的6379端口。令人惊讶的是，我竟然能够直接登录，这表明该服务缺乏必要的安全措施，如密码保护，暴露了严重的安全风险。这种状况通常是因为默认配置没有更改或安全设置被忽略。

在确认存在未授权访问的漏洞后，决定利用这一漏洞进行进一步的探测和测试。由于Redis服务允许未授权访问，且SSH服务也开启，选择了通过写入SSH公钥来远程登录的方式进行利用。这种方法相对直接且有效，下面是操作的详细步骤：

1. 生成SSH公私钥：在本地计算机上使用ssh-keygen -t rsa命令生成一对公私钥。

2. 将公钥上传至目标主机的Redis：首先，将公钥内容保存到一个文本文件（例如test.txt），然后使用以下Redis命令将公钥内容上传：

   cat test.txt | redis-cli -h xx.xx.xx.xx -x set crackitredis-cli -h xx.xx.xx.xxconfig set dir /root/.ssh/config get dir/

3. 设置公钥为authorized_keys：将上传的公钥文件设置为SSH认证所需的authorized_keys：

   config set dbfilename "authorized_keys"save

4. 使用SSH公钥登录：使用上传的私钥文件进行SSH登录：

   ssh -i id_rsa [email protected]

这种方式不仅显示了目标机器的安全弱点，也突显了未授权访问的严重后果。在实际操作中，应该确保所有服务都进行了适当的安全配置，以防止此类风险。

在研究了系统的网络连接后，他立即注意到一个明显的外部IP连接。

纯粹的IP地址被他定位到相关的PID进程，让他发现了外部连接。

在/var/log/wtmp日志中，他继续查看了谁登录过这台主机，并根据Windows被入侵的时间段筛选了一遍。最终，在这个时间段内找到了相符的IP地址，而且用户是root，很有可能这个外连地址就是攻击者的真实服务器。Whois查询了一下ip

一种幸运之情涌上心头，他成功地关联到了QQ邮箱。

他直接搜索并添加了一个SVIP9级别的大佬的QQ，而且地点信息竟然精确到了某个省市区。

没有手机号，空间动态也无法查看，邮箱放在reg007中查了一遍，结果什么都没有。

至此就收工了。他不确定找的目标人物是否准确，之后顺手给朋友装了360，并且保留了火绒，提醒他别随意开启服务。

总结

1. 首先，确定问题的根源，确认系统中了木马。
2. 清除系统中的所有可疑进程、启动项、计划任务、后门以及异常账户。
3. 使用审计主机和Web日志，定位入侵的具体入口。
4. 通过反追踪技术获取到肉鸡权限，并发现外部连接的地址。
5. 尽力溯源，确定具体人员身份（虽然不一定能百分百确认）。