NetworkMiner 2.7.3 Released

NetworkMiner now extracts meterpreter payloads from reverse shells and performs offline lookups of JA3 hashes and TLS certificates. Our commercial tool, NetworkMiner Professional, additionally comes with a packet carver that extracts network packets from memory dumps.

Extraction of Meterpreter Payloads

NetworkMiner 2.7.3 supports extraction of meterpreter DLL payloads from reverse shell TCP sessions deployed with Metasploit. The free version of NetworkMiner will try to extract the meterpreter DLL from TCP sessions going to "poker-hand ports" commonly used for meterpreter sessions, such as 3333, 4444, 5555, etc. The port-independent protocol detection feature available in NetworkMiner Professional additionally enables extraction of meterpreter DLLs regardless which LPORT the attacker specifies when deploying the reverse shell.

Image: Meterpreter DLL extracted from DFIR Madness' case001.pcap

Packet Carving in NetworkMiner Professional

If you try to open anything other than a PCAP, PcapNG or ETL file in NetworkMiner Professional, then you'll be presented with an option to carve packets from the opened file as of this release.

The packet carver can extract packets from any structured or unstructured data, such as memory dumps and proprietary packet capture formats. NetworkMiner Pro's carver is a simplified version of the packet carving feature in CapLoader.

Loading the 1GB "memdump.mem" from Ali Hadi's Challenge #1 - Web Server Case into NetworkMiner Professional takes roughly five seconds, during which 612 packets get extracted.

Image: Information about network hosts carved from memory dump

In this scenario the memory was dumped on the 192.168.56.101 host, which NetworkMiner identifies as "WIN-L0ZZQ76PMUF". The carved packets also indicate that this computer had an outgoing TCP connection to 192.168.56.102, which appears to be a Linux machine called "kali". As you can see in the screenshot, the packets carved from the memory dump also reveal a great deal about other hosts on the network, such as the 192.168.56.1 host, which seems to be a Windows 7 machine called "IT104-00".

Offline Matching of JA3 and X.509 hashes

NetworkMiner 2.7.3 comes with a local copy of the SSL Certificate and JA3 Fingerprint Blacklists from the awesome abuse.ch project. JA3 hashes and extracted X.509 certificates are matched against these lists in order to see if they are associated with any piece of malware or botnet.

Here's one example showing the default Cobalt Strike certificate being identified as "AKBuilder C&C", since that's how it is listed in abuse.ch's SSL certificate database.

Image: Cobalt Strike's default certificate identified as "AKBuilder C&C"
PCAP: Cobalt Strike PCAP from malware-traffic-analysis.net

The port-independent protocol detection feature in NetworkMiner Professional additionally enables X.509 certificates to be extracted even from non-standard TLS ports, such as this certificate, which is identified as "BitRAT" with help of the abuse.ch certificate block-list.

Image: Both X.509 certificate and JA3 hash identified as BitRAT
PCAP: BitRAT PCAP from Joe Sandbox

The client's JA3 hash 8515076cbbca9dce33151b798f782456 is also associated with BitRAT according to abuse.ch.

DBSBL Lookup Detection

DNSBL services are used by servers handling incoming email to verify that the sender's IP address isn't a known SPAM sender and that it isn't from a network that shouldn't be sending emails.

But DNSBL services can also be used by malware and botnets, such as TrickBot and Emotet, to verify that the public IP of a victim is allowed to send emails and that it hasn't already been blacklisted for sending SPAM. We have therefore decided to add DNSBL lookups to the Host Details section in NetworkMiner 2.7.3.

Image: TrickBot victim checks if its public IP is blocked by DNSBL services
PCAP: TrickBot PCAP from malware-traffic-analysis.net

DNSBL lookups are also logged to the "Parameters" tab of NetworkMiner.

Image: NetworkMiner's Parameters tab with "DNSBL" filter
PCAP: TrickBot PCAP from malware-traffic-analysis.net

Additional Features and Updates

We'd also like to mention some additional new features, bug fixes and improvements that have been included in this new release.

• Support for HTTP CONNECT request method to extract artifacts like X.509 certificates and JA3 hashes from HTTPS traffic passing through a web proxy.
• Traffic to TCP ports 3000 and 8000 are now configured to be parsed as HTTP by default in order to handle WEBrick traffic.
• Improved extraction of SMTP credentials.
• JA3 hashes were previously incorrect for clients that supported more than one EC point format (RFC 8422). This has now been fixed.
• Support for SLL2 (Linux cooked capture v2) frames.
• Improved handling of concurrent GUI events, for example when poking around in the "Hosts" tab while loading a PCAP file or doing live sniffing.
• NetworkMiner's GUI no longer reloads between each PCAP file when multiple files are loaded at once.

New Features in NetworkMiner Professional

We have also added a few new features exclusively to NetworkMiner Professional, which is the commercial version of NetworkMiner. Apart from the packet carver feature, mentioned earlier in this blog post, we've also updated the collection of OSINT lookup services available in the GUI. One of the newly added services is Ryan Benson's unfurl, which picks apart URLs to reveal data that might have been encoded into a complex URL. The unfurl lookup can be found by right-clicking an URL in NetworkMiner Professional's "Browsers" tab and selecting the "Lookup URL" sub menu.

Other OSINT services that we've added are FileScan.IO and JoeSandbox lookups of extracted files. These lookups can be performed by right clicking a file in the "Files" tab and opening the sub-menu called "Lookup Hash".

Image: OSINT lookup of an EXE file extracted from network traffic

The command-line version of NetworkMiner Professional, NetworkMinerCLI, has also been updated to allow extracted information to be printed directly on standard output instead of logging everything to files. Here is an example showing this feature while running NetworkMinerCLI in Linux (with help of Mono):

The command above extracts files from a PCAP file, which contains traffic from a Windows PC infected with Qbot. The "-w" switch specifies the output directory for the files extracted from network traffic, and the "-X FileInfos" specifies that metadata for these files should be sent to STDOUT instead of being written to log files. The cut utility was used to show only the filename (column 5) and MD5 hash (column 9) of the file info output.

The MD5 hashes of the extracted files confirm that this is indeed a Qbot infection:

• 124207bc9c64e20e114bcaeabde12a4e (VT)
• ca7ef367c935182a40a95b9ad8b95f42 (VT)
• a9a8366fa6be54b45ca04192ca217b75 (VT)

NetworkMinerCLI previously printed some information about the parsing process to STDOUT. That output has now been moved to STDERR in order to provide the "-X [type]" output with exclusive access to STDOUT.

Credits

We'd like to thank Michael Taggart for noticing that NetworkMiner previously failed to parse HTTP traffic to ports 3000 and 8000.

Upgrading to Version 2.7.3

Users who have purchased NetworkMiner Professional can download a free update to version 2.7.3 from our customer portal, or use the “Help > Check for Updates” feature. Those who instead prefer to use the free and open source version can grab the latest version of NetworkMiner from the official NetworkMiner page.

Posted by Erik Hjelmvik on Monday, 04 April 2022 06:52:00 (UTC/GMT)

Tags: #NetworkMiner​ #carve​ #JA3​ #X.509​ #CobaltStrike​ #Cobalt Strike​ #TrickBot​ #Emotet​ #PIPI​ #Protocol Detection​ #OSINT​ #NetworkMinerCLI​

Extracting Kerberos Credentials from PCAP

NetworkMiner is one of the best tools around for extracting credentials, such as usernames and passwords, from PCAP files. The credential extraction feature is primarily designed for defenders, in order to analyze credential theft and lateral movement by adversaries inside your networks. But the credential extraction feature is also popular among penetration testers. In this blog post I will demo how Kerberos hashes can be extracted from captured network traffic with NetworkMiner, and how these hashes can be cracked in order to retrieve the clear text passwords.

Installing NetworkMiner in Kali Linux

I’m using a clean install of Kali Linux 2019.3, on which I have installed NetworkMiner by following the step-by-step instructions in our guide for installing NetworkMiner in Ubuntu, Fedora and Arch Linux.

Extracting Kerberos Hashes from PCAP

There is a capture file in Wireshark’s sample captures called krb-816.cap. This capture file contains Kerberos traffic from a Windows XP machine, as two user accounts perform a domain logon. Let’s download that PCAP file and open it in NetworkMiner.

The “Credentials” tab contains the extracted Kerberos hashes. Right-click on the first $krb5pa$23$ hash and select “Copy Password” to put the password into the system clipboard.

Paste the password to a text file, either using a text editor or directly from a shell.

Note: You'll need to do press Ctrl+Shift+Insert in GNOME Terminal to paste from the system clipboard, which is where NetworkMiner has put the password.

You can now try to crack the hash, for example by running John the Ripper (JtR) or hashcat.

Yay! We now know that the password of user “des” was “123”. Let’s try to recover the password of the user “u5” as well, but this time we’ll use the $krb5asrep$23$ hash.

Apparently the password for user u5 was “123” as well.

If you wanna replace JtR with hashcat, then make sure to use the following hash modes:

• $krb5pa$23$: hashcat -m 7500
• $krb5tgs$23$: hashcat -m 13100
• $krb5asrep$23$: hashcat -m 18200

Running the Command Line version of NetworkMiner

The commercial version of NetworkMiner comes with a command line tool called NetworkMinerCLI. You can extract the Kerberos hashes from a PCAP file and save them to a CSV file using NetworkMinerCLI like this:

NetworkMinerCLI has now created a set of CSV files, one for each type/class of information found in the capture file. In this case we want the krb-816.cap.Credentials.csv file, in which the hashes and passwords are in column 5:

Posted by Erik Hjelmvik on Thursday, 14 November 2019 12:25:00 (UTC/GMT)

Tags: #PCAP​ #Kerberos​ #Linux​ #hashcat​ #John​ #JtR​ #NetworkMinerCLI​

NetworkMiner 2.5 Released

I am happy to announce the release of NetworkMiner 2.5 today! This new version includes new features like JA3 and parsers for the HTTP/2 and DoH protocols. We have also added support for a few older protocols that are still widely used, such as Kerberos and the CIFS browser protocol. Additionally, NetworkMiner can now parse PCAP files up to twice as fast as before!

Improving Passive TLS Analysis with JA3

Almost all web traffic is TLS encrypted nowadays, which prevents incident responders, analysts and investigators from inspecting otherwise unencrypted HTTP traffic for clues about malicious behavior or criminal intent. This requires analysts to use alternative approaches, such as looking at hostnames and X.509 certificates. This type of analysis is supported by NetworkMiner, since it parses Server Name Indication fields in client TLS handshakes and extracts X.509 certificates automatically when PCAP files are loaded.

In this release we’ve also added support for another passive TLS analysis technique called JA3, which is a method for fingerprinting TLS client implementations.

NetworkMiner leverages the JA3 fingerprint database from Trisul Network Analytics in order to match observed JA3 hashes to hashes of known malware and “normal” applications. This is what it looks like when the capture file “snort.log.1428364808”, from the FIRST 2015 “Hands-on Network Forensics” training (available here), has been loaded into NetworkMiner 2.5:

Image: JA3 fingerprint of a Skype client in NetworkMiner 2.5

The JA3 hash is also available in the “Parameters” tab, which is useful in order to find out what hosts that particular TLS implementation was reaching out to.

Image: Filtering on JA3 hash 06207a1730b5deeb207b0556e102ded2

HTTP/2 and DoH Support

Passive analysis of TLS traffic, such as HTTPS, often doesn’t give sufficient visibility. Many organizations therefore use TLS proxies in order to decrypt the traffic going in and out from their networks. However, more than half of all HTTPS traffic is actually http2 (RFC 7540) nowadays. This has previously been an issue for users who wanted to analyze decrypted http2 traffic from their TLS intercepting proxies with NetworkMiner. We’re happy to announce that NetworkMiner now can parse http2 traffic, that has been decrypted by a TLS proxy, and extract files from the http2 transfers.

NetworkMiner 2.5 also supports the DNS over HTTPS (DoH) protocol (RFC 8484), which is a technique for sending DNS queries as http2 POST requests and parsing the returned data as DNS responses. We’ve incorporated the DoH data into NetworkMiner’s DNS tab, so that you can analyze it just like normal DNS traffic.

Image: DoH traffic to mozilla.cloudflare-dns.com in NetworkMiner’s DNS tab

Please note that NetworkMiner 2.5 does not perform TLS decryption. This means that NetworkMiner can only parse the contents of a TLS stream if it has been decrypted by a TLS proxy, such as PolarProxy.

Extracting Kerberos Hashes from PCAP

NetworkMiner’s support for the Kerberos protocol allows you to passively track which user accounts that are authenticating to what services, simply by monitoring network traffic. This is a feature is essential in order to track credential theft and lateral movement by adversaries inside your networks. After implementing kerberos username and hash extraction we realized that this feature could also be valuable for penetration testers. We therefore decided to present extracted Kerberos credentials in a format that is compatible with tools like hashcat and John the Ripper.

Image: Kerberos krb5pa, krb5asrep and krb5tgs credentials extracted from the Wireshark sample capture file Krb-contrained-delegation.cap

For more information about Kerberos hashes, please see our Extracting Kerberos Credentials from PCAP blog post.

Even more NetBIOS and CIFS Artifacts!

NetworkMiner is a popular tool for extracting files transferred over SMB and SMB2 from capture files. It can also extract a great deal of information about the communicating hosts from protocols like NetBIOS and SMB/CIFS, but earlier this year Chris Raiter notified us about an important piece of information that was missing in NetworkMiner: NetBIOS Name Service (NBNS) lookups and responses!

A couple of months later Dan Gunter sent us another great feature request for another protocol that runs on top of NetBIOS: the CIFS Browser Protocol (aka MS-BRWS).

We’re happy to announce that NBNS queries and responses are now shown in NetworkMiner’s Parameters tab, and details like hostnames, domain names, Windows versions and uptime us extracted from the MS-BRWS protocol. See the screenshots below, which were created by loading the capture file “case09.pcap” from Richard Bejtlich’s TCP/IP Weapons School 2.0 Sample Lab into NetworkMiner 2.5. Thanks for sharing Richard!

Image: Hostname, domain and Windows version extracted from MS-BRWS traffic

Image: NBNS queries and responses in NetworkMiner’s Parameters tab

Mono 5 Required for Linux and MacOS

Linux and MacOS users, who run NetworkMiner with help of Mono, will need to ensure they have Mono 5 (or later) installed in order to run NetworkMiner 2.5. We recommend using at least Mono 5.18.

Instructions for installing NetworkMiner on Linux can be found in our blog post ”HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux”.

MacOS users can refer to our “Running NetworkMiner on Mac OS X” blog post.

Users who are unable to install Mono 5 are recommended to use the old NetworkMiner 2.4 release, which can be downloaded here:
https://www.netresec.com/?download=NetworkMiner_2-4

NetworkMiner Professional

Apart from the features mentioned so far, our commercial tool NetworkMiner Professional now comes with a few additional new features. One of these features is port independent identification of RDP traffic, so that mstshash credentials can be extracted from RDP sessions even if the service doesn’t run on port 3389. The OSINT lookup context menus in NetworkMiner Professional have also been enriched with the following online services:

• ja3er.com JA3 lookup
• abuse.ch JA3 lookup
• urlscan.io URL, DNS and IP lookup
• IPAddress.com IP lookup
• OpenDNS DNS lookup
• circl.lu IP/BGP lookup (thank you Raphaël)
• GreyNoise Visualizer IP lookup
• RIPEstat IP lookup

Several new features have also been included in the command line tool NetworkMinerCLI, including:

• Recursive loading of PCAP files with the "-R” switch.
• Configurable export types (hosts, files, DNS etc) with the “-x” switch.
• Relative paths in CSV, XML and JSON/CASE exports unless the “-- absolutePaths” switch is used.

Credits

I’d like to thank Dan Gunter, Chris Raiter, Chris Sistrunk and a few more (who I cannot mention here) for contributing with feature requests and bug reports that have helped improve NetworkMiner.

Upgrading to Version 2.5

Users who have purchased a license for NetworkMiner Professional 2.x can download a free update to version 2.5 from our customer portal, or use the “Help > Check for Updates” feature. Those who instead prefer to use the free and open source version can grab the latest version of NetworkMiner from the official NetworkMiner page.

Posted by Erik Hjelmvik on Thursday, 07 November 2019 11:45:00 (UTC/GMT)

Tags: #NetworkMiner​ #JA3​ #HTTP/2​ #http2​ #DoH​ #Kerberos​ #NetBIOS​ #PCAP​ #hashcat​ #John​ #NetworkMinerCLI​ #OSINT​

Observing the Havex RAT

It has, so far, been publicly reported that three ICS vendors have spread the Havex Remote-Access-Tool (RAT) as part of their official downloads. We've covered the six pieces of software from these three vendors in our blog post ”Full Disclosure of Havex Trojans”. In this blog post we proceed by analyzing network traffic generated by Havex.

Indicators of Compromise

Before going into details of our analysis we'd like to recommend a few other resources that can be used to detect the Havex RAT. There are three Havex IDS signatures available via Emerging Threats. There are also Yara rules and OpenIOC signatures available for Havex. Additionally, the following domains are known to be used in the later versions (043 and 044) of Havex according to Kaspersky:

• disney.freesexycomics.com
• electroconf.xe0.ru
• rapidecharge.gigfa.com
• sinfulcelebs.freesexycomics.com
• www.iamnumber.com

HTTP Command-and-Control

The Havex RAT Command-and-Control (C2) protocol is based on HTTP POST requests, which typically look something like this:

POST /blogs/wp-content/plugins/buddypress/bp-settings/bpsettings-src.php?id=84651193834787196090098FD80-c8a7af419640516616c342b13efab&​v1=043&​v2=170393861&​q=45474bca5c3a10c8e94e56543c2bd

As you can see, four variables are sent in the QueryString of this HTTP POST request; namely id, v1, v2 and q. Let's take a closer look to see what data is actually sent to the C2 server in the QueryString.

Analyzing a Havex PCAP

I had the pleasure to discuss the Havex Malware with Joel Langill, when we met at the 4SICS conference in Stockholm last month. Joel was nice enough to provide me with a 800 MB PCAP file from when he executed the Havex malware in an Internet connected lab environment.

I used the command line tool NetworkMinerCLI (in Linux) to automatically extract all HTTP downloads from Joel's PCAP file to disk. This way I also got a CSV log file with some useful metadata about the extracted files. Let's have a closer look at what was extracted:

$ mono NetworkMinerCLI.exe -r new-round-09-setup.pcap
Closing file handles...
970167 frames parsed in 1337.807 seconds.

$ cut -d, -f 1,2,3,4,7,12 new-round-09-setup.pcap.FileInfos.csv | head

SourceIP   SourcePort  DestinationIP  DestinationPort  FileSize   Frame
185.27.134.100   TCP 80   192.168.1.121   TCP 1238   244 676 B       14
198.63.208.206   TCP 80   192.168.1.121   TCP 1261       150 B     1640
185.27.134.100   TCP 80   192.168.1.121   TCP 1286   359 508 B     3079
185.27.134.100   TCP 80   192.168.1.121   TCP 1311   236 648 B     4855
185.27.134.100   TCP 80   192.168.1.121   TCP 1329       150 B    22953
185.27.134.100   TCP 80   192.168.1.121   TCP 1338       150 B    94678
185.27.134.100   TCP 80   192.168.1.121   TCP 1346       150 B   112417
198.63.208.206   TCP 80   192.168.1.121   TCP 1353       150 B   130108
198.63.208.206   TCP 80   192.168.1.121   TCP 1365       150 B   147902

Files downloaded through Havex C2 communication are typically modules to be executed. However, these modules are downloaded in a somewhat obfuscated format; in order to extract them one need to do the following:

• Base64 decode
• Decompress (bzip2)
• XOR with ”1312312”

To be more specific, here's a crude one-liner that I used to calculate MD5 hashes of the downloaded modules:

$ tail -c +95 C2_download.html | base64 -d | bzcat -d | xortool-xor -s "1312312" -f - -n | tail -c +330 | md5sum

To summarize the output from this one-liner, here's a list of the downloaded modules in Joel's PCAP file:

All three extracted modules are known binaries associated with Havex. The third module is one of the Havex OPC scanner modules, let's have a look at what happens on the network after this module has been downloaded!

Analyzing Havex OPC Traffic

In Joel's PCAP file, the OPC module download finished at frame 5117. Less then a second later we see DCOM/MS RPC traffic. To understand this traffic we need to know how to interpret the UUID's used by MS RPC.

Marion Marschalek has listed 10 UUID's used by the Havex OPC module in order to enumerate OPC components. However, we've only observed four of these commands actually being used by the Havex OPC scanner module. These commands are:

Of these commands the ”IOPC Browse” is the ultimate goal for the Havex OPC scanner, since that's the command used to enumerate all OPC tags on an OPC server. Now, let's have a look at the PCAP file to see what OPC commands (i.e. UUID's) that have been issued.

$ tshark -r new-round-09-setup.first6000.pcap -n -Y 'dcerpc.cn_bind_to_uuid != 99fcfec4-5260-101b-bbcb-00aa0021347a' -T fields -e frame.number -e ip.dst -e dcerpc.cn_bind_to_uuid -Eoccurrence=f -Eheader=y

frame.nr  ip.dst      dcerpc.cn_bind_to_uuid
5140    192.168.1.97  000001a0-0000-0000-c000-000000000046
5145    192.168.1.11  000001a0-0000-0000-c000-000000000046
5172    192.168.1.97  000001a0-0000-0000-c000-000000000046
5185    192.168.1.11  9dd0b56c-ad9e-43ee-8305-487f3188bf7a
5193    192.168.1.97  000001a0-0000-0000-c000-000000000046
5198    192.168.1.11  55c382c8-21c7-4e88-96c1-becfb1e3f483
5212    192.168.1.11  00000143-0000-0000-c000-000000000046
5247    192.168.1.11  000001a0-0000-0000-c000-000000000046
5257    192.168.1.11  00000143-0000-0000-c000-000000000046
5269    192.168.1.11  00000143-0000-0000-c000-000000000046
5274    192.168.1.11  39c13a4d-011e-11d0-9675-0020afd8adb3
5280    192.168.1.11  39c13a4d-011e-11d0-9675-0020afd8adb3
5285    192.168.1.11  39227004-a18f-4b57-8b0a-5235670f4468
5286    192.168.1.11  39227004-a18f-4b57-8b0a-5235670f4468
[...]

We can thereby verify that the IOPCBrowse command was sent to one of Joel's OPC servers in frame 5285 and 5286. However, tshark/Wireshark is not able to parse the list of OPC items (tags) that are returned from this function call. Also, in order to find all IOPCBrowse commands in a more effective way we'd like to search for the binary representation of this command with tools like ngrep or CapLoader. It would even be possible to generate an IDS signature for IOPCBrowse if we'd know what to look for.

The first part of an MSRPC UUID is typically sent in little endian, which means that the IOPCBrowse command is actually sent over the wire as:

04 70 22 39 8f a1 57 4b 8b 0a 52 35 67 0f 44 68

Let's search for that value in Joel's PCAP file:

Image: Searching for IOPCBrowse byte sequence with CapLoader

Image: CapLoader with 169 extracted flows matching IOPCBrowse UUID

Apparently 169 flows contain one or several packets that match the IOPCBrowse UUID. Let's do a “Flow Transcript” and see if any OPC tags have been sent back to the Havex OPC scanner.

Image: CapLoader Transcript of OPC-DA session

Oh yes, the Havex OPC scanner sure received OPC tags from what appears to be a Waterfall unidirectional OPC gateway.

Another way to find scanned OPC tags is to search for a unique tag name, like “Bucket Brigade” in this example.

Posted by Erik Hjelmvik on Wednesday, 12 November 2014 21:09:00 (UTC/GMT)

Tags: #Havex​ #PCAP​ #NSM​ #ICS​ #C2​ #NetworkMinerCLI​ #CapLoader​