NETRESEC Network Security Blog

rss Google News

Short URL: https://netresec.com/?b=24A65d3


Browsers tab in NetworkMiner Professional

The Browsers tab is a unique feature only available in NetworkMiner Professional. The PCAP files analyzed in this video are pwned-se_150312_outgoing.pcap and pwned-se_150312_incoming.pcap, which are snippets of the 4.4 GB Hands-on Network Forensics dataset from FIRST 2015 (slides).

More information about NetworkMiner Professional's Browsers tab can be found in our blog post Analyzing Web Browsing Activity.

See our NetworkMiner Professional tutorial videos for additional tips and hints.

Posted by Erik Hjelmvik on Thursday, 03 October 2024 09:10:00 (UTC/GMT)

Tags: #NetworkMiner Professional#Video#Tutorial

Short URL: https://netresec.com/?b=24Abf1c

Short URL: https://netresec.com/?b=24Ad5ad


Hosts tab in NetworkMiner Professional

The PCAP file analyzed in this video is MD_2015-07-22_112601.pcap, which is a snippet of the training data used in our network forensics classes from 2015 to 2019.

Techniques, tools and databases mentioned in the tutorial:

Check out our Passive OS Fingerprinting blog post for more details on how to identify operating systems using TCP/IP headers and browser user-agents.

See our NetworkMiner Professional tutorial videos for more tips and hints.

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

Tags: #NetworkMiner Professional#Video#Tutorial

Short URL: https://netresec.com/?b=24A71a9


Opening capture files with NetworkMiner Professional

This video tutorial demonstrates how to open capture files with NetworkMiner Professional

The analyzed pcap-ng file is github.pcapng from CloudShark. More info about this capture file can be found in our blog post Forensics of Chinese MITM on GitHub.

See our NetworkMiner Professional tutorial videos for more tips and hints.

Posted by Erik Hjelmvik on Monday, 30 September 2024 12:50:00 (UTC/GMT)

Tags: #NetworkMiner Professional#Video#Tutorial

Short URL: https://netresec.com/?b=249b790


Video Tutorial: Installing NetworkMiner Professional

This video tutorial covers how to install NetworkMiner Professional.

Use the official 7-zip tool to extract the password protected 7zip archive.

Recommended locations for NetworkMiner:

  • Desktop
  • My Documents
  • C:\Users\{user}\AppData\Local\Programs\
  • USB flash drive

See our NetworkMiner Professional tutorial videos for more tips and hints.

Posted by Erik Hjelmvik on Monday, 30 September 2024 08:45:00 (UTC/GMT)

Tags: #NetworkMiner Professional#Video#Tutorial

Short URL: https://netresec.com/?b=24904d2


CapLoader 1.9.7 Released

CapLoader 1.9.7

A new release of CapLoader has been published! Some of the changes can be seen directly in the user interface, such as Community ID values for flows and a few other new columns in the Flows and Services tabs. Other improvements are more subtle, like improved detection of remote management protocols and malicious C2 protocols.

User Interface Improvements

The most important user interface update is probably the addition of a Community_ID column in the Flows tab, which shows a unique Community ID string for each flow. The community ID is a common flow identifier that can be used to correlate traffic in CapLoader with alerts or events from tools like Zeek, Suricata, MISP or Arkime.

CapLoader 1.9.4 with Retransmissions and Community ID

CapLoader now has a column named Retransmissions in both Flows and Services tab, which shows an estimate of how many percent of the packets in each flow or service that are retransmissions. This value can be used to quickly diagnose a network issue without having to inspect network traffic on a packet-by-packet level.

We have also added a column named Client_IP_TTL to CapLoader’s Flows tab, which can be used to differentiate between NAT’ed clients that share a single public IP address – provided that they run operating systems with different IP TTL of course! There is also a new column in the Services tab called First_Seen, which shows when each service was first observed in the analyzed network traffic.

The Severity and Severity_Label columns in the Alerts tab are now colored according to severity level, where red means High, orange is Medium, yellow is Low and blue is Info (the exact color codes were borrowed from the US Homeland Security Advisory System scale).

Alerts in CapLoader 1.9.4

We have also included a handy little feature that allows you to append additional PCAP files to an existing analysis session simply by holding down Ctrl while drag-and-dropping another capture file onto CapLoader. The “Append File(s)” option is also available under CapLoader’s File menu.

Even More Protocols Identified

CapLoader’s unique ability to identify protocols regardless of port has been improved and we’ve also added detections for several new protocols. For this release we’ve focused adding detection for remote monitoring and management (RMM) protocols, such as ConnectWise (formerly ScreenConnect), AnyDesk, NetSupport (including NetSupport RAT), TeamViewer (including TVRAT) and RMS (Remote Utilities). This enables CapLoader to alert whenever an RMM protocol is detected.

We’ve also added detection of several new malware protocols, including Matanbuchus, Meduza Stealer, SectopRAT, STRRAT and zgRAT.

Even More Protocols Decapsulated

DECAPSULATE ALL THE THINGS

CapLoader already decapsulates flows inside of GRE, VXLAN and CapWap. With this release we add support for decapsulation of Teredo, GTP-U, TZSP as well as IP-in-IP traffic, so that tunneled traffic can be analyzed without any additional effort.

Credits

I would like to thank Jarmo Lahtiranta for the TZSP idea and Lenny Hansson for pointing out the need for improved protocol detection. I would also like to thank Christian Kreibich and his fellow Corelight devs for creating and open sourcing the Community ID project.

Updating to the Latest Release

Users who have already purchased a license for CapLoader can download a free update to version 1.9.7 from our customer portal or by clicking “Check for Updates” in CapLoader’s Help menu.

Posted by Erik Hjelmvik on Friday, 06 September 2024 09:45:00 (UTC/GMT)

Tags: #CapLoader#TZSP#TTL

Short URL: https://netresec.com/?b=2499359


How to Inspect TLS Encrypted Traffic

Do you want to analyze decrypted TLS traffic in Wireshark or let an IDS, like Suricata, Snort or Zeek, inspect the application layer data of potentially malicious TLS encrypted traffic? There are many different TLS inspection solutions to choose from, but not all of them might be suitable for the specific challenge you’re facing. In this blog post I describe three different methods for decrypting TLS and explain when to use one or the other.

RSA Private Key TLS Key Log TLS Inspection Proxy
Works for all ciphers No (DHE cipher suites not supported) Yes Yes
TLS 1.3 supported No Yes Yes
Zero client configuration required Yes No (pre-master secrets must be logged or extracted from TLS libraries) No (root CA certificate must be installed)
Decrypts traffic from any application No (most applications use modern ciphers with forward secrecy, which RSA doesn’t provide) No (each method for TLS key extraction typically only supports a specific set of applications or TLS libraries) No (apps that use certificate pinning or a custom certificate trust store cannot be intercepted without patching the app)
L7 traffic in PCAP files can be analyzed without decrypting TLS No No Yes
Allows decrypted traffic to be mirrored to a network interface No No Yes

RSA Private Key

TLS decryption with a private RSA key was for a long time the preferred method for inspecting SSL and TLS traffic. This approach allowed anyone with access to the server’s private RSA key to decrypt the traffic and inspect the application layer (L7) communication.

The primary drawback with RSA private key decryption is that a stolen or leaked private RSA key can be used by an attacker to decrypt all previously captured traffic from that server, if RSA key exchange is being used. Modern TLS stacks have therefore deprecated such ciphers in favor of ones that support forward secrecy, which typically perform an ephemeral Diffie–Hellman (DHE) key exchange instead of reusing the same private RSA key over and over. This means that the RSA private key decryption method cannot be used if the client and server are using a key exchange algorithm that supports forward secrecy.

RSA private key decryption can only be performed when all these conditions are met:

  • The protocol version is SSL 3.0, TLS 1.0, TLS 1.1 or TLS 1.2 (RSA was removed in TLS 1.3)
  • The server has selected a cipher suite that use RSA key exchange, such as TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA or TLS_RSA_WITH_AES_128_CBC_SHA
  • The private key matches the server certificate (traffic cannot be decrypted with a client certificate or an intermediate or root certificate)
  • The session has not been resumed (the handshake must include a Client Key Exchange message)

This Wireshark display filter can be used to check if the server has selected an RSA cipher:

tls.handshake.type == 2 and tls.handshake.ciphersuite in {10,47,53,60,61,156,157}

You can check for a client key exchange message with:

tls.handshake.type == 16

A private RSA key can be loaded into Wireshark by clicking Edit, Preferences and RSA Keys. Another alternative is to use the command line tool tshark’s -ouat:rsa_keys switch like this:

tshark -r tls.pcap -ouat:rsa_keys:'"/path/rsa.key",""'

TLS Key Log

Wireshark can decrypt the TLS layer in captured network traffic if the pre-master secrets used to establish the encrypted connection are provided. These secrets, or encryption key material, can be loaded into Wireshark from an SSLKEYLOGFILE by clicking Edit, Preferences, Protocols, TLS, and setting the (Pre)-Master-Secret log filename to the path of your SSLKEYLOGFILE.

Wireshark SSLKEYLOGFILE

Another alternative is to encode the key material as metadata in a pcap-ng file with editcap like this:

editcap --inject-secrets tls,SSLKEYLOG.txt tls.pcap tls-and-keys.pcapng

The primary drawback with the TLS key log decryption method is that only Wireshark and tshark can be used to analyze the decrypted TLS traffic. You also need to get hold of the keys or pre-master secrets in order to perform the decryption. Some applications, such as Firefox, Chrome and curl, can be configured to export a key log. Another alternative is to install an agent that extracts key material from specific TLS libraries.

The limitation of only being able to extract keys from a specific set of applications or TLS libraries makes the TLS key log method unsuitable for analyzing TLS encrypted C2 traffic from malware, which often use custom TLS libraries. It is also difficult to send decrypted TLS traffic to an IDS or a network security monitoring tool using a TLS key log. If you, on the other hand, want to analyze network traffic from your own Firefox or Chrome browser in Wireshark, then the TLS key log approach is probably the best solution.

TLS Inspection Proxy

A TLS inspection proxy acts as a man-in-the-middle that intercepts and decrypts TLS traffic for inspection, it then re-encrypts the traffic and forwards it to the intended destination.

TLS inspection proxy

A major advantage of using a TLS inspection proxy is that decrypted TLS traffic can be analyzed from applications even if they use modern ciphers with forward secrecy and don’t support logging of TLS keys. The drawback, however, is that clients have to trust the root CA certificate that the proxy is using.

TLS inspection proxies often differ in how they make the decrypted traffic available to external tools, if at all. In fact, many TLS inspection proxies and Next-Generation Firewalls (NGFW) only make the decrypted payload available to the internal application or appliance. Such an approach prevents analysis of the decrypted traffic with an external tool, like Wireshark, Snort, Suricata, Zeek or NetworkMiner.

Another approach, used by proxies like mitmproxy, is to save a TLS key log for all proxied traffic. That approach allows captured TLS traffic to or from the proxy to be decrypted and inspected with Wireshark, but the application layer traffic cannot be inspected with other tools that don’t support TLS decryption using a key log.

The third and most integration friendly approach is to save the decrypted traffic in clear text form, so that other applications can inspect the unencrypted traffic without having to decrypt TLS. Some TLS proxies, like PolarProxy and SSLsplit, can even save the decrypted traffic to a PCAP file. Decrypted TLS traffic in PCAP format can easily be ingested into other tools or be replayed to a network interface for inspection by an external security appliance.

Best Practices

The list below can be used to select the best suited TLS inspection method for the particular challenge you’re tasked with.

I want to...

  • Inspect traffic from my browser.

    Use TLS key log to inspect traffic from Firefox, Chrome and curl. Use a TLS inspection proxy for other browsers.

  • Inspect traffic to my HTTPS website.

    Use RSA private key inspection if it is acceptable to use an older TLS version and less secure ciphers. Use a TLS key log if your web server can be configured to export one or if you have an agent based key extraction solution that supports the TLS library used by the web server. Use a TLS inspection proxy if you want to inspect the traffic with something other than Wireshark.

  • Inspect potentially malicious TLS traffic with an IDS or security appliance.

    Use a TLS inspection proxy.

  • Inspect traffic from my operating system.

    Use a TLS inspection proxy.

  • Inspect traffic from my mobile phone, smart device or other embedded device.

    Use a TLS inspection proxy.

  • Inspect traffic from a proprietary game, app or service.

    Use a TLS inspection proxy.

Posted by Erik Hjelmvik on Wednesday, 07 August 2024 11:40:00 (UTC/GMT)

Tags: #TLS#TLS Inspection#PolarProxy#SSLKEYLOGFILE#Wireshark#PCAP

Short URL: https://netresec.com/?b=248b1db

X / twitter

NETRESEC on X / Twitter: @netresec

Mastodon

NETRESEC on Mastodon: @netresec@infosec.exchange