Another Network Forensic Tool for the Toolbox - Dshell

Published: 2015-02-03
Last Updated: 2015-02-03 18:59:03 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

This is a guest diary written by Mr. William Glodek – Chief, Network Security Branch, U.S. Army Research Laboratory

As a network analysis practitioner, I analyze multiple gigabytes of pcap data across multiple files on a daily basis. I have encountered many challenges where the standard tools (tcpdump, tcpflow, Wireshark/tshark) were either not flexible enough or couldn’t be prototyped quickly enough to do specialized analyzes in a timely manner.  Either the analysis couldn’t be done without recompiling the tool itself, or the plugin system was difficult to work with via command line tools. 

Dshell, a Python-based network forensic analysis framework developed by the U.S. Army Research Laboratory, can help make that job a little easier [1]. The framework handles stream reassembly of both IPv4 and IPv6 network traffic and also includes geolocation and IP-to-ASN mapping data for each connection.  The framework also enables development of network analysis plug-ins that are designed to aid in the understanding of network traffic and present results to the user in a concise, useful manner by allowing users to parse and present data of interest from multiple levels of the network stack.  Since Dshell is written entirely in Python, the entire code base can be customized to particular problems quickly and easily; from tweaking an existing decoder to extract slightly different information from existing protocols, to writing a new parser for a completely novel protocol.  Here are two scenarios where Dshell has decreased the time required to identify and respond to network forensic challenges.

  1. Malware authors will frequently embed a domain name in a piece of malware for improved command and control or resiliency to security countermeasures such as IP blocking.  When the attackers have completed their objective for the day, they minimize the network activity of the malware by updating the DNS record for the hostile domain to point to a non-Internet routable IP address (ex.  When faced with hundreds or thousands of DNS requests/responses per hour, how can I find only the domains that resolve to a non-routable IP address?

Dshell>  decode –d reservedips *.pcap

The “reservedips” module will find all of the DNS request/response pairs for domains that resolve to a non-routable IP address, and display them on a single line.  By having each result displayed on a single line, I can utilize other command line utilities like awk or grep to further filter the results. Dshell can also present the output in CSV format, which may be imported into many Security Event and Incident Management (SEIM) tools or other analytic platforms.

  1. A drive-by-download attack is successful and a malicious executable is downloaded [2].  I need to find the network flow of the download of the malicious executable and extract the executable from the network traffic.
    Using the “web” module, I can inspect all the web traffic contained in the sample file.  In the example below, a request for ‘xzz1.exe’ with a successful server response is likely the malicious file.

I can then extract the executable from the network traffic by using the “rip-http” module.  The “rip-http” module will reassemble the IP/TCP/HTTP stream, identify the filename being requested, strip the HTTP headers, and write the data to disk with the appropriate filename.

dlink extracting stream from cap

There are additional modules within the Dshell framework to solve other challenges faced with network forensics.  The ability to rapidly develop and share analytical modules is a core strength of Dshell.  If you are interested in using or contributing to  Dshell, please visit the project at

[1] Dshell –


Keywords: dshell forensics
4 comment(s)

What is using this library?

Published: 2015-02-03
Last Updated: 2015-02-03 16:54:01 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Last year with OpenSSL, and this year with the GHOST glibc vulnerability, the question came up about what piece of software is using what specific library. This is a particular challenging inventory problem. Most software does not document well all of it's dependencies. Libraries can be statically compiled into a binary, or they can be loaded dynamically. In addition, updating a library on disk may not always be sufficient if a particular piece of software does ues a library that is already loaded in memory.

To solve the first problem, there is "ldd". ldd will tell you what libraries will be loaded by a particular piece of software. For example:

$ ldd /bin/bash =>  (0x00007fff9677e000) => /lib64/ (0x00007fa397b43000) => /lib64/ (0x00007fa39793f000) => /lib64/ (0x00007fa3975aa000)
    /lib64/ (0x00007fa397d72000)

The first line (linux-vdso) doesn't point to an actual library, but to the "Virtual Dynamic Shared Object" which represents kernel routines. Whenever you see an "arrow" (=>), it indicates that there is a symlink to a specific library that is being used.  Another option that works quite well for shared libraries is "readelf". e.g. "readelf -d /bin/bash" will list 

To list libraries currently loaded, and programs that are using them, you can use lsof. 

One trick with lsof is that it may appreviate command names to make the output look better. To fix this, use the "+c 0" option (or use a number that is long enough to help you find the right command). You can grep the output for the library you are interested in. For example:

# lsof +c 0 | grep libc-
init   1   root  mem       REG   253,0   1726296  131285 /lib64/
udevd  836 root  mem       REG   253,0            131078 /lib64/ (path inode=131285)
anvil 987   postfix  mem   REG   253,0   1726296  131285 /lib64/

The first column will tell you what processes need restarting. Also the number in front of the library (131285) is the inode for the library file. As you may note above, the inode is different for some of these libraries, indicating that the library changed. These are the processes that need restarting.

It is always best to reboot a system to not have to worry about remnant bad code staying in memory.

In addition, if your system uses RPMs, you can find dependencies using the RPM. But this information is not always complete. 


Johannes B. Ullrich, Ph.D.

Keywords: glibc libraries lld lsof
3 comment(s)
ISC StormCast for Tuesday, February 3rd 2015


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives