Open .ETL Files with NetworkMiner and CapLoader

Windows event tracing .etl files can now be read by NetworkMiner and CapLoader without having to first convert them to .pcap or .pcapng. The ETL support is included in NetworkMiner 2.7.2 and CapLoader 1.9.3, which were both released this morning.

What is an ETL Trace File?

ETL is short for Event Trace Log, which is ETW session data that has been logged to a file. You can, for example, extract EVTX logs from ETL files. But in this blog post we're gonna focus on network traffic that has been captured to an ETL file with a command like:

Pro-tip: You can specify a capture NIC explicitly with "CaptureInterface=<GUID>"

NetworkMiner and CapLoader can also read packets in Pktmon ETL files, which actually are different from those created with netsh. Capturing packets to an ETL file with Pktmon is very simple:

Pro-tip: You can specify capture filters with "pktmon filter add"

You can also capture packets to ETL files with PowerShell:

Pro-tip: You capture packets on a remote PC by specifying a CimSession

Advantages

The built-in support for ETL files in NetworkMiner and CapLoader makes it easy to work with ETL files. Not only will you no longer need to go through the extra step of converting the ETL file to PCAP using etl2pcapng or Microsoft Message Analyzer (which was retired in 2019), the analysis will also be faster because both CapLoader and NetworkMiner read ETL files faster compared to etl2pcapng and MMA.

Limitations

The primary limitation with NetworkMiner and CapLoader's ETL support is that it only works in Windows. This means that you will not be able to open ETL files when running NetworkMiner in Linux or macOS.

Another limitation is that both NetworkMiner and CapLoader might fail to parse logged packets if the event trace was created on an OS version with an event manifest that is incompatible with the OS version on which the ETL file is opened.

Under the Hood

Both NetworkMiner and CapLoader leverage Windows specific API calls to read packets from ETL files. An ETL file opened in CapLoader first get converted to PcapNG, then CapLoader parses that PcapNG file. NetworkMiner, on the other hand, parses the packets in the ETL file directly to extract artifacts like files, images and parameters. NetworkMiner's approach is both simpler and quicker, but by converting the ETL file to PcapNG CapLoader can utilize its packet indexing feature to rapidly extract any subset of the captured traffic upon request by the user.

CapLoader's approach is also useful for users who are wondering how to open ETL files in Wireshark, since the packets from an ETL file can be opened in Wireshark by dragging the PcapNG file from the CapLoader GUI onto Wireshark.

Additional Updates in NetworkMiner

The ETL support is not the only new feature in NetworkMiner 2.7.2 though. We have also added support for the ERSPAN protocol. The FTP parser has also been improved to support additional commands, such as AUTH (RFC2228).

We've also added a useful little feature to the context menu of the Parameter's tab, which allows users to send extracted parameters to CyberChef (on gchq.github.io) for decoding.

Additional Updates in CapLoader

The only major improvement in CapLoader 1.9.3, apart from the built-in ETL-to-PcapNG converter, is that the protocol identification speed and precision has been improved. We've also separated the identification of SSL (version 2.0 to 3.0) and TLS (SSL 3.1 and later) as two separate protocols in this version, whereas they previously both were fingerprinted as "SSL".

Credits

We'd like to thank Dick Svensson and Glenn Larsson for their input on reading ETL files. We also want to thank Markus Schewe for recommending us to add ERSPAN support to NetworkMiner!

Posted by Erik Hjelmvik on Tuesday, 02 November 2021 07:15:00 (UTC/GMT)

Tags: #PowerShell​ #CapLoader​ #NetworkMiner​ #PcapNG​ #Windows​ #Wireshark​ #PCAP​ #CyberChef​

Carving Packets from Memory

Someone who says "We're gonna pull the packet captures out of the router" probably has no clue how to capture network traffic. In the Lindell case, statements like these were results of an elaborate hoax.

Nevertheless, such a statement doesn't have to be nonsense — if it comes from someone who knows how to dump the physical memory from the router. There are actually more packets available in the RAM of a router, or computer for that matter, than you might think.

The Forensic Challenge from DFRWS 2016 contains a memory dump from an SDN switch. If you drag-and-drop SDN.ram.raw from that challenge to CapLoader then you'll be asked if you wanna carve packets from the memory dump.

This packet carving feature is also available in the free trial version of CapLoader.

Clicking "Yes" in the dialogue brings up a configuration window. The default settings are okay in most cases.

After pressing "Start" CapLoader will start identifying packets in the memory dump from the SDN switch. The packets will be saved to a Pcap-NG file located in the %TEMP% directory, unless you specified a different output location in the config window.

You can download a copy of the Pcap-NG file that I generated with CapLoader 1.9.2 here:
https://media.netresec.com/pcap/SDN.ram.raw.pcapng (661 kB, 2959 packets)

Here's what it looks like when the carved packets have been loaded into NetworkMiner Professional.

As you can see, a great deal of information can be extracted about the hosts on this network just by examining the dumped memory from the SDN switch.

What about Bulk Extractor?

Simson Garfinkel's bulk_extractor can also extract packets from memory dumps. It was actually a research paper by Simson that inspired me to implement a packet carver in the first place.

There are a few significant differences between bulk_extractor and CapLoader with regards to packet carving though. One difference is that bulk_extractor identifies network packets by looking for Ethernet frames containing IPv4 packets, while CapLoader looks for IPv4 or IPv6 packets containing TCP or UDP packets. The output from bulk_extractor is usually quite similar to that of CapLoader, and so is the parsing speed. CapLoader was just slightly faster in our tests and carved about 3% more packets compared to bulk_extractor, these additional packets were primarily IPv6 packets and packets that weren't encapsulated by an Ethernet frame.

Where can I download memory dumps?

I posted a question on Twitter, asking the #DFIR community for their favorite publicly available memory dumps prior to writing this blog post, and I received lots of great answers. Thank you all for contributing! I have now compiled the following list of places from where you can download memory dumps:

• Memory Images from the Stolen Szechuan Sauce case by James Smith
• Digital Corpora 2018 Lone Wolf Scenario by Thomas Moore
• Digital Corpora 2009 M57 Patents Scenario by Naval Postgraduate School
• DFRWS 2005 Challenge
• DFRWS 2008 Challenge
• DFRWS 2016 Challenge (SDN switch)
• CTF-styled memory forensic challenges by Abhiram Kumar
• Mini Memory CTF contest from 2020 by 13Cubed
• Web Server Case by Ali Hadi
• Locky Ransomware infection by Jiří Vinopal
• Memory images from the Art of Memory Forensics (book) by the Volatility Team
• Memory Forensic challenges on CyberDefenders
• GrrCON 2015 CTF by Wyatt Roersma
• GrrCON 2017 Memory Dumps by Wyatt Roersma
• GrrCON 2019 CTF by Wyatt Roersma

For a more detailed blog post on CapLoader's packet carving functionality, please see our Carving Network Packets from Memory Dump Files blog post from 2014.

Posted by Erik Hjelmvik on Tuesday, 31 August 2021 15:10:00 (UTC/GMT)

Tags: #Forensics​ #RAM​ #PCAP​ #Pcap-NG​ #PcapNG​ #DFIR​ #carve​ #carver​ #packets​ #dump​ #CapLoader​ #memory forensics​ #DFRWS​

Chinese MITM attack on outlook.com

We were contacted by GreatFire.org earlier today regarding a new Chinese man-in-the-middle (MITM) attack. This time the perpetrators decrypted traffic between Chinese users and Microsoft's IMAP mail server for outlook.com. As evidence GreatFire.org provided us with a packet capture file, which we have analyzed.

Our conclusion is that this was a real attack on Microsoft's email service. Additionally, the attack is very similar to previous nationwide Chinese attacks on SSL encrypted traffic, such as the attack on Google a few months ago. Details such as email address, email password, email contents, email attachments and contacts may have been compromised in this attack. We do not know the scale of the attack, it could be anything from a fairly targeted attack to a nation wide attack in China. What we do know is that there are several users who have been subjected to the MITM attack and posted screenshots online.

Technical Analysis

In our technical analysis we first extracted the x509 certificates from the SSL traffic by loading the capture file into NetworkMinerCLI. We then parsed the extracted certificates with OpenSSL.

$ mono /opt/NetworkMinerProfessional_1-6-1/NetworkMinerCLI.exe -r Outlook_MITM_2015-01-18.pcapng
Closing file handles...
84 frames parsed in 0.888754 seconds.
$ ls AssembledFiles/157.56.195.250/TLS_Cert\ -\ TCP\ 993/*.cer
AssembledFiles/157.56.195.250/TLS_Cert - TCP 993/hotmail.com[1].cer
AssembledFiles/157.56.195.250/TLS_Cert - TCP 993/hotmail.com[2].cer
AssembledFiles/157.56.195.250/TLS_Cert - TCP 993/hotmail.com.cer
$ openssl x509 -inform DER -in AssembledFiles/157.56.195.250/TLS_Cert\ -\ TCP\ 993/hotmail.com.cer -noout -issuer -subject -startdate -fingerprint
issuer= /CN=*.hotmail.com
subject= /CN=*.hotmail.com
notBefore=Jan 15 16:00:00 2015 GMT
SHA1 Fingerprint=75:F4:11:59:5F:E9:A2:1A:17:A4:96:7C:7B:66:6E:51:52:79:1A:32

When looking at the timestamps in the capture file we noticed that the SSL server's reply to the 'Client Hello' was very slow; response times varied between 14 and 20 seconds. Under normal circumstances the 'Server Hello' arrives within 0.3 seconds after the 'Client Hello' has been sent.

$ tshark -nr ./Outlook_MITM_2015-01-18.pcapng -Y 'ssl.handshake.type lt 3'
8 9.023876000 10.0.2.15 -> 157.56.195.250 SSL 265 Client Hello
17 26.885504000 157.56.195.250 -> 10.0.2.15 TLSv1 576 Server Hello, Certificate, Server Hello Done
45 101.747755000 10.0.2.15 -> 157.56.195.250 SSL 265 Client Hello
49 116.258483000 157.56.195.250 -> 10.0.2.15 TLSv1 576 Server Hello, Certificate, Server Hello Done
63 116.338420000 10.0.2.15 -> 157.56.195.250 SSL 265 Client Hello
65 136.119127000 157.56.195.250 -> 10.0.2.15 TLSv1 576 Server Hello, Certificate, Server Hello Done
[...]

This is slow SSL response is consistent with previous SSL MITM attacks conducted with support of the Great Firewall of China (GFW).

For more details on this attack, please see the Reuters story "After Gmail blocked in China, Microsoft's Outlook hacked" and GreatFire's own blog post "Outlook grim - Chinese authorities attack Microsoft".

Posted by Erik Hjelmvik on Monday, 19 January 2015 22:55:00 (UTC/GMT)

Tags: #Netresec​ #PCAP​ #PCAPNG​ #GFW​ #MITM​ #China​ #Hotmail​ #IMAP​ #IMAPS​ #SSL​

Chinese MITM Attack on iCloud

Users in China are reporting a MITM attacks on SSL connections to iCloud.

GreatFire.org, who monitor the Great Firewall of China (GFW), also published a blog post on their website earlier today saying:

This is clearly a malicious attack on Apple in an effort to gain access to usernames and passwords and consequently all data stored on iCloud such as iMessages, photos, contacts, etc.

Fake SSL Certificate

In their blog post GreatFire also linked a packet capture file, which we have analyzed in order to verify the MITM attack. We loaded the PcapNG file into NetworkMiner Professional and extracted the X.509 SSL certificate.

The extracted certificate can be downloaded from here. Also, here are a few details from this X.509 certificate:

$ openssl x509 -inform DER -in www.icloud.com.cer -noout -issuer -subject -startdate -enddate -fingerprint
issuer= /C=cn/O=www.icloud.com/CN=www.icloud.com
subject= /C=cn/O=www.icloud.com/CN=www.icloud.com
notBefore=Oct 4 10:35:47 2014 GMT
notAfter=Oct 4 10:35:47 2015 GMT
SHA1 Fingerprint=F4:68:B5:F3:FE:D8:07:97:44:76:A2:2B:32:EA:31:37:D9:24:F7:BA

As reported elsewhere, the certificate was self signed, which means that browsers and most iPhone apps will either inform the user about the connection being unsafe or simply close the connection (see update at the bottom of this blog post regarding the missing certificate verification in Apple iOS). This use of self signed certificates is consistent with previous SSL MITM attacks performed in China against GitHub, Google, Yahoo and live.com.

Location of the MITM Attack

By looking at host the information provided by NetworkMiner for the fake iCloud SSL server we can see that it is just six router hops away from the client (having an IP TTL value of 58). This indicates that the MITM attack is being performed within China, since we'd expect to see at least three more router hops if the packets were coming from outside China.

The same PCAP file also contains packets from the same IP address on TCP port 80, which have traveled 11 hops (IP TTL 53). We therefore assume that only traffic to TCP port 443 is being MITM'ed.

This TTL analysis also matches various TCP traceroutes we've seen to the MITM'ed iCloud SSL service on 23.59.94.46:443.

                        My traceroute [v0.85]
siyanmao-k29 (0.0.0.0)                        Sat Oct 18 19:26:07 2014

Host                          Loss% Snt  Last   Avg  Best  Wrst StDev
1. 192.168.1.1                0.0%   17   0.6   0.7   0.6   0.8   0.0
2. -------------              0.0%   16   2.8   2.6   1.7   3.3   0.3
3. -------------              0.0%   16   2.0   2.2   1.4   4.0   0.4
4. ???
5. 119.145.47.78              0.0%   16   6.4   7.7   4.3  27.0   5.2
   183.56.65.54
   183.56.65.50
   119.145.47.74
   121.34.242.250
   121.34.242.138
6. 23.59.94.46               25.0%   16 168.5 171.4 166.8 201.3   9.4

The mtr TCP traceroute above indicates that MITM attacks are performed in AS4134 (China Telecom).

bearice@Bearice-Mac-Air-Haswell ~
%tcptraceroute 23.59.94.46 443
Selected device en0, address 192.168.100.16, port 52406 for outgoing packets
Tracing the path to 23.59.94.46 on TCP port 443 (https), 30 hops max
1 192.168.100.254 1.737 ms 0.793 ms 0.798 ms
2 111.192.144.1 2.893 ms 2.967 ms 2.422 ms
3 61.51.246.25 2.913 ms 2.893 ms 3.968 ms
4 124.65.61.157 4.824 ms 2.658 ms 3.902 ms
5 202.96.12.9 3.626 ms 6.532 ms 3.794 ms
6 219.158.96.54 27.539 ms 26.821 ms 27.661 ms
7 a23-59-94-46.deploy.static.akamaitechnologies.com (23.59.94.46) [open] 30.064 ms 29.899 ms 30.126 ms

The tcptraceroute above indicates that MITM attacks are also performed in AS4837 (China Unicom).

Tcproute traceroute to 23.59.94.46 on TCP 443 (source: @chenshaoju)

The Tcproute screenshot above shows that also CHINANET backbone network (China Telecom) seems to be used to carry out the MITM attacks.

Judging from these TCP traceroutes the MITM attacks seem to be taking place at several different locations rather centrally in the Chinese Internet infrastructure. To be more specific, it appears as if the MITM attacks are being performed on backbone networks belonging to China Telecom (CHINANET) as well as China Unicom.

UPDATE (October 22)

A vulnerability notice (CVE-2014-4449) has now been published, where Apple confirm that fake SSL certificates (like the Chinese fake one) were not verified by Apple iOS before 8.1. Apple released the first details about this vulnerability just a few hours after this blog post was published. Here's the text from the CVE description:

iCloud Data Access in Apple iOS before 8.1 does not verify X.509 certificates from TLS servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Posted by Erik Hjelmvik on Monday, 20 October 2014 13:35:00 (UTC/GMT)

Tags: #Netresec​ #PCAP​ #GFW​ #China​ #PcapNG​ #MITM​ #NetworkMiner​ #AS4837​ #AS4134​

Verifying Chinese MITM of Yahoo

GreatFire.org sent out a tweet yesterday saying that “Yahoo appears to under Man-in-the-middle attack in China. 3rd case of country-wide MITM, after Google, Github”.

Mashable later ran a story called “China Appears to Attack Yahoo in Latest Censorship of Hong Kong Protests”, where Lorenzo Franceschi-Bicchierai write:

In what's almost unprecedented, China appears to be targeting Yahoo with what's called a "man-in-the-middle attack." With such an attack, connections to Yahoo.com, which are normally encrypted, would be vulnerable to snooping, and Chinese censors could also block search terms or specific Yahoo links with the goal of preventing Chinese netizens from accessing information about the protests in Hong Kong.

In this blog post we verify that there is an ongoing Man-in-the-Middle (MITM) attack by analyzing two different packet capture files.

Time-To-Live (TTL) Analysis

We estimate the distance between the end users and the Yahoo server in Hong Kong to be at least 10 router hops. However, the IP packets coming back to the users have IP TTL values of 58 (Wuxi) and 57 (Zhengzhou). This implies that the MITM is performed somewhere in China, just 6 or 7 router hops away from the users. This is consistent with what we've observed in previous MITM attacks performed by China against GitHub and Google.

IMAGE: Hosts tab in CapLoader showing TTL 57 for hk.yahoo.com:443

X.509 Certificate Analysis

We have extracted a X.509 certificate from one of the PcapNG files to a .cer file using NetworkMiner. This SSL certificate is available for download here.

$ openssl x509 -inform DER -in yahoo.com.cer -noout -issuer -subject -startdate -enddate -fingerprint
issuer= /C=cn/O=yahoo.com/CN=yahoo.com
subject= /C=cn/O=yahoo.com/CN=yahoo.com
notBefore=Sep 23 11:30:17 2014 GMT
notAfter=Sep 23 11:30:17 2015 GMT
SHA1 Fingerprint=22:90:C3:11:EA:0F:3F:57:E0:6D:F4:5B:69:8E:18:E8:28:E5:9B:C3

The certificate is a self signed certificate for “yahoo.com”. The fact that the MITM uses a self signed certificate makes the attack easily detectable even for the non-technical user, since the web browser will typically display a warning about the site not being trusted.

Some may think it's odd that China can't forge a properly signed certificate for their SSL MITM attack. However, they've used very similar self signed certificates also in their previous MITM attacks against GitHub and Google. The purpose of GFW (a.k.a. “Golden Shield”) is to censor the Internet, so the primary goal with this MITM attack isn't to covertly spy on Chinese Yahoo searches. Regardless if the end users notice the MITM or not, a self signed X.509 cert is enough in order to see what they are searching for and “kill” their connection to Yahoo when queries like “Umbrella Revolution” and “Tiananmen Square Protests” are observed.

Posted by Erik Hjelmvik on Wednesday, 01 October 2014 21:55:00 (UTC/GMT)

Tags: #MITM​ #GFW​ #PCAP​ #PCAPNG​ #SSL​ #TLS​ #China​

Analysis of Chinese MITM on Google

The Chinese are running a MITM attack on SSL encrypted traffic between Chinese universities and Google. We've performed technical analysis of the attack, on request from GreatFire.org, and can confirm that it is a real SSL MITM against www.google.com and that it is being performed from within China.

We were contacted by GreatFire.org yesterday (September 3) with a request to analyze two packet captures from suspected MITM-attacks before they finalized their blog post. The conclusions from our analysis is now published as part of GreatFire.org's great blog post titled “Authorities launch man-in-the-middle attack on Google”.

In their blog post GreatFire.org write:

From August 28, 2014 reports appeared on Weibo and Google Plus that users in China trying to access google.com and google.com.hk via CERNET, the country’s education network, were receiving warning messages about invalid SSL certificates. The evidence, which we include later in this post, indicates that this was caused by a man-in-the-middle attack.

While the authorities have been blocking access to most things Google since June 4th, they have kept their hands off of CERNET, China’s nationwide education and research network. However, in the lead up to the new school year, the Chinese authorities launched a man-in-the-middle (MITM) attack against Google.

Our network forensic analysis was performed by investigating the following to packet capture files:

Client and Server IP adresses

The analyzed capture files contain pure IPv6 traffic (CERNET is a IPv6 network) which made the analysis a bit different then usual. We do not disclose the client IP addresses for privacy reasons, but they both seem legit; one from Peking University (netname PKU6-CERNET2) and the other from Chongqing University (CQU6-CERNET2). Both IP addresses belong to AS23910, named "China Next Generation Internet CERNET2".

Peking University entrance, by galaygobi (Creative Commons Attribution 2.0)

Chongqing University gate, by Brooktse (Creative Commons Attribution-Share Alike 3.0)

The IP addresses received for www.google.com were in both cases also legit, so the MITM wasn't carried out through DNS spoofing. The Peking University client connected to 2607:f8b0:4007:804::1013 (GOOGLE-IPV6 in United States) and the connection from Chongqing University went to 2404:6800:4005:805::1010 (GOOGLE_IPV6_AP-20080930 in Australia).

Time-To-Live (TTL) Analysis

The Time-To-Live (TTL) values received in the IP packets from www.google.com were in both cases 248 or 249 (note: TTL is actually called ”Hop Limit” in IPv6 nomenclature, but we prefer to use the well established term ”TTL” anyway). The highest possible TTL value is 255, this means that the received packets haven't made more than 6 or 7 router hops before ending up at the client. However, the expected number of router hops between a server on GOOGLE-IPV6 and the client at Peking University is around 14. The low number of router hops is is a clear indication of an IP MITM taking place.

Image: CapLoader with both capture files loaded, showing TTL values

Here is an IPv6 traceroute from AS25795 in Los Angeles towards the IP address at Peking University (generated with ARP Networks' 4or6.com tool):

#traceroute -6 2001:da8:201:[REDACTED]
 1  2607:f2f8:1600::1 (2607:f2f8:1600::1) 1.636 ms 1.573 ms 1.557 ms
 2  2001:504:13::1a (2001:504:13::1a) 40.381 ms 40.481 ms 40.565 ms
 3  * * *
 4  2001:252:0:302::1 (2001:252:0:302::1) 148.409 ms 148.501 ms 148.595 ms
 5  * * *
 6  2001:252:0:1::1 (2001:252:0:1::1) 148.273 ms 147.620 ms 147.596 ms
 7  pku-bj-v6.cernet2.net (2001:da8:1:1b::2) 147.574 ms 147.619 ms 147.420 ms
 8  2001:da8:1:50d::2 (2001:da8:1:50d::2) 148.582 ms 148.670 ms 148.979 ms
 9  cernet2.net (2001:da8:ac:ffff::2) 147.963 ms 147.956 ms 147.988 ms
10  2001:da8:201:[REDACTED] 147.964 ms 148.035 ms 147.895 ms
11  2001:da8:201:[REDACTED] 147.832 ms 147.881 ms 147.836 ms
12  2001:da8:201:[REDACTED] 147.809 ms 147.707 ms 147.899 ms

Response Time Analysis

The round-trip time between the client and server can be estimated by measuring the time from when the client sends it initial TCP SYN packet to when it receives a TCP SYN+ACK from the server. The expected round-trip time for connecting from CERNET to a Google server overseas would be around 150ms or more. However, in the captures we've analyzed the TCP SYN+ACK package was received in just 8ms (Peking) and 52ms (Chongqing) respectively. Again, this is a clear indication of an IP MITM taking place, since Google cannot possibly send a response from the US to CERNET within 8ms regardless of how fast they are. The fast response times also indicate that the machine performing the MITM is located fairly close to the network at Peking University.

Even though the machine performing the MITM was very quick at performing the TCP tree-way handshake we noticed that the application layer communication was terribly slow. The specification for the TLS handshake (RFC 2246) defines that a ClientHello message should be responded to with a ServerHello. Google typically send their ServerHello response almost instantly, i.e. the response is received after one round-trip time (150ms in this case). However, in the analyzed captures we noticed ServerHello response times of around 500ms.

X.509 Certificate Analysis

The X.509 certificates were extracted from the two PCAP files to .cer files using NetworkMiner. We noticed that both users received identical certificates, which were both self signed for “google.com”. The fact that the MITM used a self signed certificate makes the attack easily detectable even for the non-technical user, since the web browser will typically display a warning about the site not being trusted. Additionally the X.509 certificate was created for ”google.com” rather than ”*.google.com”. This is an obvious miss from the MITM'ers side since they were attempting to MITM traffic to ”www.google.com” but not to ”google.com”.

Image: NetworkMiner showing list of X.509 certificates extracted from the two PCAP files

Certificate SHA1 fingerprint: f6beadb9bc02e0a152d71c318739cdecfc1c085d
Certificate MD5 fingerprint: 66:D5:D5:6A:E9:28:51:7C:03:53:C5:E1:33:14:A8:3B

A copy of the fake certificate is available on Google drive thanks to GreatFire.org.

Conclusions

All evidence indicates that a MITM attack is being conducted against traffic between China’s nationwide education and research network CERNET and www.google.com. It looks as if the MITM is carried out on a network belonging to AS23911, which is the outer part of CERNET that peers with all external networks. This network is located in China, so we can conclude that the MITM was being done within the country.

It's difficult to say exactly how the MITM attack was carried out, but we can dismiss DNS spoofing as the used method. The evidence we've observed instead indicate that the MITM attack is performed either by performing IP hijacking or by simply reconfiguring a router to forward the HTTPS traffic to a transparent SSL proxy. An alternative to changing the router config would also be to add an in-line device that redirects the desired traffic to the SSL proxy. However, regardless of how they did it the attacker would be able to decrypt and inspect the traffic going to Google.

We can also conclude that the method used to perform the MITM attack was similar to the Chinese MITM on GitHub, but not identical.

Posted by Erik Hjelmvik on Thursday, 04 September 2014 23:55:00 (UTC/GMT)

Tags: #MITM​ #GFW​ #PCAP​ #PCAPNG​ #Google​ #SSL​ #TLS​ #China​