Shellcode Detection in IPv6 Networks with HoneydV6

Sven Schindler

, Oliver Eggert

, Bettina Schnor

and Thomas Schefﬂer

Department of Computer Science, University of Potsdam, Potsdam, Germany

Department of Electrical Engineering, Beuth University of Applied Sciences, Berlin, Germany

Keywords:

Honeypot, IPv6, Shellcode.

Abstract:

More and more networks and services are reachable via IPv6 and the interest for security monitoring of these

IPv6 networks is increasing. Honeypots are valuable tools to monitor and analyse network attacks. HoneydV6

is a low-interaction honeypot which is well suited to deal with the large IPv6 address space, since it is capable

of simulating a large number of virtual hosts on a single machine. This paper presents an extension for

HoneydV6 which allows the detection, extraction and analyses of shellcode contained in IPv6 network attacks.

The shellcode detection is based on the open source library libemu and combined with the online malware

analysis tool Anubis. We compared the shellcode detection rate of HoneydV6 and Dionaea. While HoneydV6

is able to detect about 25 % of the malicious samples, the Dionaea honeypot detects only about 6 %.

1 INTRODUCTION

Current measurements of IPv6 adoption

show that

the new Internet protocol is seeing increased deploy-

ment and in some countries approaches almost 10%

of all network trafﬁc.

The deployment of IPv6-enabled security tools on

such networks is necessary in order to gain a deep

understanding how attackers might adapt to IPv6 and

what strategies are used to target the new network

protocol. It is therefore necessary to have adequate

security tools, like honeypots, available that allow a

deep analysis of usage and attack patterns in IPv6 net-

works.

Honeypots are very different from most traditional

security mechanisms. They provide a security re-

source whose value lies in being actively probed, at-

tacked, or compromised (Spitzner, 2002). The honey-

pot system has no production value and is conﬁgured

to monitor unused address space. Every communica-

tion with the honeypot is considered potentially hos-

tile trafﬁc and has to be analysed. A honeypot can

be something like a computer or even a mobile phone

which is set up to attract attackers. By using various

monitoring mechanisms, honeypots can provide valu-

able data about an attack and the strategies used by

the attacker. This information can later be used to de-

velop appropriate countermeasures.

http://www.google.com/ipv6/statistics.html

Intrusion detection systems like snort (Beale et al.,

2007) passively observe the network communication

between multiple hosts and send alarms if they de-

tect patterns that indicate malicious activities. Hon-

eypots, on the other hand, are interacting with an ad-

versary directly and therefore have a lot more con-

trol and insight into the communication. This makes

even end-to-end encrypted communication channels

available, such as between a Command-and-Control-

Server and its bots, that could not be analysed by a

network-based intrusion detection system.

In many cases, network attacks try to exploit vul-

nerabilities of the target system to run arbitrary code

under the privileges of the attacked service (Poly-

chronakis et al., 2006). A typical target action is to

spawn a shell on the remote system. This is the reason

why the transferred machine code is commonly called

shellcode. Attacking networks with exploits carry-

ing shellcode has become comparatively easy due to

the availability of tools like the Metasploit frame-

work (Metasploit, nd), which has recently started to

target IPv6-speciﬁc risks.

There currently exist two general-purpose honey-

pots which are capable of simulating different IPv6

network services: HoneydV6 (Schindler et al., 2013)

and Dionaea (Dionaea, nd). Other special-purpose

honeypots like the ssh honeypot kippo (kippo, nd)

might be used in IPv6 networks but are not generic

enough to capture a wide range of attack scenarios.

Dionea already provides the ability to detect shell-

198

Schindler S., Eggert O., Schnor B. and Schefﬂer T..

Shellcode Detection in IPv6 Networks with HoneydV6.

DOI: 10.5220/0005016801980205

In Proceedings of the 11th International Conference on Security and Cryptography (SECRYPT-2014), pages 198-205

ISBN: 978-989-758-045-1

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

code attacks through the libemu shellcode detection

library (Baecher and Koetter, nd). HoneydV6, on the

other hand, did not have the capability to detect and

to extract shellcode binaries.

Since HoneydV6 handles certain IPv6 speciﬁc

properties, like the huge address space of an IPv6 net-

work, better than Dionaea (Schindler et al., 2013), we

decided to implement shellcode detection into Hon-

eydV6 and compare the achievable detection rates.

The following section provides an overview over

HoneydV6. In Section 3 we introduce mechanisms to

detect shellcode contained in network trafﬁc. Next,

we present the architecture of our HoneydV6 exten-

sion in Section 4. We evaluated our implementation

by sending various shellcode samples to HoneydV6

and compared the detection rate of our implementa-

tion with the detection rate of Dionaea. The results of

this experiment are presented in Section 5. The paper

concludes with a summary.

2 HONEYDV6

In (Schindler et al., 2013), the authors presented the

low-interaction honeypot HoneydV6 which can be

used to simulate large IPv6 networks with thousands

of routers and hosts. HoneydV6 is an extension of the

well-known low-interaction honeypot Honeyd (Hon-

eyd, nd) focusing on attack detection in IPv6 net-

works.

By using the network packet capture library

pcap (McCanne and Jacobson, nd), HoneydV6 is

able to simulate multiple machines and even entire

networks including network latency and simulated

packet loss on a single machine. HoneydV6 imple-

ments a custom IPv6 network stack instead of using

the network stack of the underlying operating system.

The honeypot is a framework for network services

and relies on external scripts to emulate services like

telnet, ssh, or http servers. HoneydV6 provides a ba-

sic logging functionality to log events like ICMPv6

echo requests or connection attempts.

The honeypot does not further inspect the com-

munication between script and adversary, except for

some basic statistical analyses. There is no imple-

mentation of any attack detection or classiﬁcation

mechanism available. This makes it difﬁcult to dif-

ferentiate between interesting trafﬁc caused by new

attacks and potentially uninteresting trafﬁc of well-

known attacks that may be seen on a daily basis.

Our intention is to eliminate the lack of detection

capabilities by extending HoneydV6 with shellcode

detection mechanisms as discussed in the next sec-

tion.

3 SHELLCODE DETECTION AND

ANALYSIS

Shellcode detection allows honeypots and intrusion

detection systems to identify network trafﬁc that con-

tains malicious code that tries to compromise the tar-

geted system.

A simple approach for the detection of a shell-

code attacks is the matching of network trafﬁc against

known code-samples. The well-known intrusion de-

tection system snort, for example, runs a signature-

based shellcode detection which compares packets

against a database containing ﬁngerprints for various

attacks. Signature-based shellcode detection is easy,

but it has a number of disadvantages. It is not pos-

sible to detect new attacks for which no ﬁngerprints

are available. The ﬁngerprint database needs to be up

to date in order to achieve any substantial detection

rates. When new signatures are distributed, they be-

come publicly known and malware developer can test

their code samples against the signature base to evade

detection. This has lead to the development of so-

called polymorphic and metamorphic malware which

dynamically changes its signature and behaviour to

work around signature-based detection (Polychron-

akis et al., 2006).

One approach of polymorphic malware is to en-

crypt the machine code before sending it to the vic-

tim. Once the encrypted code is executed on the tar-

get machine, it decrypts itself using an attack-speciﬁc

key. Changing the encryption key produces a new

malware signature which cannot be matched against

existing ﬁngerprints of a honeypot or an intrusion de-

tection system.

In contrast to polymorphic malware, metamorphic

malware does not only change its structure but also its

behaviour. One example for metamorphic malware

is Win95/Regswap which uses different CPU regis-

ters to store essential computation values for each in-

stance (Sz¨or and Ferrie, 2001).

These examples show that a simple signature-

based shellcode detection is not sufﬁcient for modern

honeypot architectures to automatically detect new

malware samples. An alternative approach is to use

shellcode detection libraries which locate, execute

and monitor machine code contained in network traf-

ﬁc in a secure sandbox. The following sections give

an introduction into emulation-based shellcode detec-

tion libraries. We will focus on the functionalityof the

open-source library libemu which is used by Dionaea

before we discuss alternatives.

ShellcodeDetectioninIPv6NetworkswithHoneydV6

199

3.1 Shellcode Detection by Emulation

Polychronakis et al. are using a different approach

to detect even polymorphic malware (Polychronakis

et al., 2006). Instead of matching malware against

a precomputed ﬁngerprint, they propose to execute

and monitor potential malicious code as long as possi-

ble. While there are a number of scientiﬁc documents

about this topic available, we could ﬁnd only one open

source library, the libemu (Baecher and Koetter, nd),

which safely executes and evaluates malicious ma-

chine code. Other implementationsare either not pub-

lic or turned into a commercial product.

Libemu was developed in 2007 by Paul Baecher

and Markus Koetter in the C programming language.

The same authors developed Dionaea which includes

libemu as shellcode detection component. Libemu

implements an x86 emulator with the corresponding

registers, program counter, virtual memory and a ma-

chine code disassembler. This way, libemu is able to

run shellcode in a safe and insulated environment on

the emulated processor.

Besides executing and checking machine code,

libemu is able to detect machine code in an arbi-

trary byte sequence. Malicious shellcode that was

transferred over a network and installed on the tar-

get system is usually located somewhere in the tar-

get system’s memory. In order to work, many mal-

ware types need to execute functions which determine

its own location within the memory. Code imple-

menting those functions is called GetPC code, derived

from the expression ”get program counter”. An ex-

ample for GetPC code is an x86 CALL command fol-

lowed by a statement that accesses the return address

which is stored on the stack due to the CALL com-

mand execution. Libemu provides a function called

emu shellcode test()

to locate GetPC code in a

given byte sequence. If a GetPC code could be found

then

emu shellcode test()

returns the position of

the detected code sequence.

Listing 1 shows the libemu code excerpt that in-

spects a given byte sequence for call-based GetPC

code. The code block is entered if the currently in-

spected byte represents an assembly

call

instruction.

Libemu creates a copy of the current stack pointer of

the emulated CPU

and starts emulating the

call

and

subsequent assembly instructions. If libemu detects

that the stack pointer points to the same location as

before executing the instructions then it returns 1, in-

dicating that a GetPC code sequence has been found.

This is the case if the shellcode popped the current

code location, which was previously pushed on the

stack due to the

call

instruction, from the stack.

Besides the call-based GetPC code, libemu is able

to detect malware using the

fstenv

instruction. The

instruction can be used to store debug information

about the state of the ﬂoating point unit into mem-

ory. These debug information also contain the current

program counter.

/∗ c a ll ∗ /

case 0 xe8 :

/∗ . . . ∗ /

u in t3 2 t espcopy = emu cpu re g32 ge t ( c , esp ) ;

in t j ;

for ( j =0; j <64; j ++)

{

in t r e t = emu cpu parse ( emu cpu get ( e ) ) ;

i f ( r et != −1)

{

r e t = emu cpu step ( emu cpu get ( e ) ) ;

}

/∗ . . . ∗ /

i f ( emu cpu reg32 get ( c , esp ) == espcopy )

return 1;

}

return 1;

break ;

Listing 1: Excerpt of libemu’s emu get pc function.

After locating possible malware in a byte se-

quence, libemu can be used to emulate the potential

shellcode and try to detect accesses to system func-

tions and libraries. This monitoring process is called

malware proﬁling. Libemu is able to create a call

graph which visualises malware behaviour.

An alternative malware proﬁling tool called

Shellzer was presented in 2011 by Fratantonio et

al. (Fratantonio et al., 2011). The tool also emulates

malware and analyses accesses to system calls. How-

ever, Shellzer is limited to the analysis of JavaScript-,

Flash and PDF malware. Since it is no general pur-

pose malware detection library, it is not suitable for

integration into the low-interaction honeypot.

The next subsections will present alternative on-

line and ofﬂine proﬁling approaches which may be

included into an honeypot architecture.

3.2 Execution on a Real OS

Libemu emulates system resources like CPU or op-

erating system calls in order to monitor malware be-

haviour. An alternative approach is the execution of

malware on a real operating system. Of course, this

requires a new operating system setup after each run

SECRYPT2014-InternationalConferenceonSecurityandCryptography

200

of a malware sample. Virtual machines provide a con-

venient tool to setup isolated machines which can be

reset to an initial state after each malware execution.

This approach is used by Cuckoobox (Sand-

box, nd), a project that was developed by Claudio

Guarnieri within the scope of the Google Summer of

Code 2010. Cuckoobox executes malware and mon-

itors system function calls, created ﬁles, downloads,

and network trafﬁc. Furthermore, it is able to cre-

ate screenshots during the malware execution. Cuck-

oobox consists of a host and multiple guest machines.

The host machine is responsible for receiving the mal-

ware samples and distributing the samples to avail-

able guest machines. A guest machine executes the

malware sample and monitors the execution, e.g. ﬁle

accesses and system calls. The analysis results of this

approach are much more speciﬁc than the results pro-

duced by libemu. However, this approach needs a lot

more system resources because a set-up containing a

real operating system is needed.

3.3 Online Malware Analysis

The additional administration and system require-

ments of Cuckoobox can be avoided by using online

malware analysis services like Malwr (Malwr, nd) or

Anubis (Anubis, nd). Malwr provides a web inter-

face for a Cuckoobox backend which is running on

servers managed by Malwr. Anubis is a similar web

service which allows to upload Windows-based mal-

ware and which monitors access to the ﬁle system,

the Windows Registry as well as network and process

activities. In contrast to Malwr, Anubis provides an

interface to automatically upload malware samples.

The resulting protocols can be downloaded in HTML-

, XML, PDF- or ASCII text format. The captured net-

work trafﬁc is also provided as a pcap ﬁle.

3.4 Discussion

The malware proﬁling capabilities of the sandboxed

libemu execution can mainly detect code-sequences

that represent entry points for malicous activities.

Malware analysis on real operating systems can

provide a much higher level of interaction with sys-

tem components and services and makes classiﬁca-

tion of malware behaviour easier. However, it also re-

quires a sophisticated test architecture that is not easy

to build and maintain for every honeypot installation.

Therefore, we decided to extend HoneydV6 with

libemu to detect potential malware in IPv6 network

trafﬁc. Due to its modular structure and convenient

high-level functions, libemu can be easily integrated

into HoneydV6’s network ﬂow. Once potential mal-

ware has been identiﬁed, we can extract this code and

send it to an operating system-based analysis service

like Anubis. By doing so, we combine the strengths

of both approaches in the analysis of network attacks.

4 ARCHITECTURE AND

IMPLEMENTATION

This section presents the integration of libemu and

Anubis into HoneydV6. Furthermore, we introduce

an extended databaselogging facility which simpliﬁes

analysing monitored attacks. The presented modiﬁca-

tions enable HoneydV6 to collect information about

IP address, port number, and protocol type, as well as

payload and timestamp of all established connections.

In order to detect network scans, ICMP and ICMPv6

trafﬁc is also logged in a database.

Figure 1 depicts the basic components of Hon-

eydV6 (white boxes) and the malware detection ex-

tensions (blue boxes). Incoming network packets are

captured by HoneydV6 using the network packet cap-

ture library libpcap.

Figure 1: HoneydV6 with Malware Detection Components.

Depending on the packet type, the packet dis-

patcher passes the packets to a TCP, UDP, ICMP or

ICMPv6 processor. ICMP and ICMPv6 packets are

processed by an internal component, while TCP and

UDP trafﬁc may be forwarded to a conﬁgured service

script (see Section 2).

A copy of the trafﬁc that is transferred from an ad-

ShellcodeDetectioninIPv6NetworkswithHoneydV6

201

versary to a service script is handed over to the shell-

code emulation library libemu. This approach allows

HoneydV6 to process the trafﬁc as early as possible

without any modiﬁcations to the service scripts.

The necessary modiﬁcation to HoneydV6 are de-

scribed in the next section.

4.1 Connecting Libemu to HoneydV6

The ﬁrst step towards shellcode inspection is the lo-

calisation and extraction of shellcodes contained in

the network trafﬁc. In order to accomplished that,

the shellcode detection library libemu needs access

the entire honeypot trafﬁc.

HoneydV6 uses the following functions to process

TCP packets:

tcp

recv cb46 - This callback function is called by

the packet dispatcher for incoming TCP pack-

ets. It checks whether HoneydV6 emulates the

requested service and sends an ICMP or ICMPv6

error if not. HoneydV6 maintains a data structure

which contains all established connections. For

each incoming TCP packet, the honeypot looks

up the corresponding connection entry of type

tcp

con and writes the packet payload into an as-

signed ﬁle descriptor.

tcp

new46 - If tcp recv cb46 cannot ﬁnd an existing

connection entry for an incoming TCP packet, it

needs to create a new connection entry by using

this function.

cmd

tcp read and cmd tcp write - HoneydV6 uses

the library libevent to monitor read and write op-

erations to the ﬁle descriptors that are assigned

to a connection. As soon as something is written

into the in- or output-stream of a connection, one

of these two callback functions is called. There-

fore, the entire TCP payload passes these func-

tions which provides a convenientpoint to add our

trafﬁc inspection.

tcp

free - When a TCP connection is closed, tcp free

removes the connection entry from the connection

data structure.

For each function listed above, there exists an

UDP counterpart. HoneydV6 writes incoming traf-

ﬁc to the ﬁle descriptors of the corresponding service

script without doing any further inspection. The hon-

eypot does not keep a reference to the exchanged traf-

ﬁc. As soon as the payload is passed to a service

script, it is out of scope of the honeypot.

If we want to inspect incoming trafﬁc for mali-

cious shellcode, we have to keep a reference to the

exchanged payload which can be passed to libemu.

Therefore, we extended the existing tcp

con and

udp con structures with a pointer to a shellcode

buffer which gets initialised when a new connection

entry is created. We modiﬁed cmd

tcp write and

cmd udp write to copy incoming data into the buffer

before it is forwarded to the service emulation script.

We restricted the maximum size of the buffer to a con-

ﬁgurable value in order to avoid DoS attacks. Cur-

rently, the maximum payload size is set to a default

value of 1024 bytes. The inﬂuence of the buffer size

is investigated in Section 5.4. In case of larger pay-

loads which exceed the buffer size, only the ﬁrst 1024

bytes are stored and used for inspection.

It is important to note that malware proﬁling,

which is done later using Anubis when libemu could

detect a malware sample, may produce wrong results

if the shellcode binary is cropped. If precise proﬁling

results are required then the buffer size should be set

to the maximum size of the expected shellcode bina-

ries.

The inspection with libemu and Anubis requires a

lot of time. For this reason we process the payload in a

separate thread in a non-blocking manner. The libemu

function

emu getpc check()

is used to identify ma-

licious payloads. All payloads that are classiﬁed mali-

cious are uploaded to Anubis for further analysis. The

next section describes this process in detail.

4.2 Payload Inspection with Anubis

In contrast to Dionaea, HoneydV6 uses the advanced

online malware analysis service Anubis instead of

libemu to conduct malware proﬁling. Trafﬁc that is

classiﬁed malicious by libemu can automatically be

uploaded to Anubis by an internal HoneydV6process.

In order to use Anubis, we had to convert our mal-

ware samples into the executable Windows .exe ﬁle

format. Furthermore, we needed to implement a Hon-

eydV6 module which automatically uploads the gen-

erated binaries via HTTP to Anubis.

Due to performancereasons, we do not run a shell-

code inspection for TCP and UDP trafﬁc instantly. In-

stead, we extract the received payload and store it in

a newly created SQLite logging database. A sepa-

rate thread periodically inspects new binary samples

stored in the database and triggers an upload to Anu-

bis. Figure 2 depicts the structure of the new logging

database.

The table connection holds information about all

incoming connections. This includes start time and

end time, source and destination address as well as

the layer 3 protocol type. The protocol

id refers to

an entry in the icmp or tcp udp tables. All incom-

ing ICMP and ICMPv6 messages are logged in the

icmp table. Furthermore, we are logging source and

SECRYPT2014-InternationalConferenceonSecurityandCryptography

202

Figure 2: Logging database tables.

destination ports of UDP and TCP connections in the

tcp

udp table. An entry in the tcp udp table contains a

payload

id which refers to payload stored in the pay-

load table. Besides the actual payload, a payload ta-

ble entry contains a report URL which points to the

Anubis report. We also store the processed malware

sample in the ﬁlesystem and use the ﬁlename-entry in

the database to point to it, which allows later access

and analysis.

Besides its capability to allow asynchronous mal-

ware processing, the database has great advantages

over HoneydV6’s old log ﬁle format. It is now pos-

sible to create sophisticated SQL queries to gather

statistical information about accessed ports, addresses

etc. Furthermore, the database provides a central pay-

load store which is independent from capturing and

logging capabilities of service scripts.

We used the Metasploit tool msfencode (Metas-

ploit, nd) to transform the collected malware samples

into the Windows .exe ﬁle format. Besides creating

executable ﬁles, msfencode can be used to create ma-

licious payloads because it supports various machine

code modiﬁcations, e.g. removing null bytes or en-

crypting machine code. We conﬁgured msfencode to

generate unencrypted x86 binaries to keep the inspec-

tion for Anubis as simple as possible.

In our experiments, the process of generating an

.exe ﬁle took about 5 to 10 seconds on a 2,3 GHz

Quad-Core Intel Core i7 with 16 GByte RAM using

a solid-state drive (SSD). In order to ensure a non-

blocking service on slower machines, we moved the

ﬁle creation into a separate process, using the fork

system call. The process communication is accom-

plished via pipes that are created using the popen sys-

tem call.

We only process malware samples which have not

yet been inspected by an earlier connection. This

is achieved by generating an MD5 checksum for the

sample that represents a folder used to store the sam-

ple on the ﬁlesystem. If a folder with the same name

already exists on the ﬁlesystem, we assume that the

malware sample has already been processed and we

skip the inspection.

After the malware ﬁle has been successfully cre-

ated, we use the network library libcurl to upload the

ﬁle to Anubis. We attache the malware sample to an

HTTP POST request which we send to the Anubis

website. The server replies with a website contain-

ing the URL pointing to the inspection result. Hon-

eydV6 extracts this URL and stores it in the logging-

database. From there it can be accessed later to man-

ually evaluate the inspection results.

5 EVALUATION

In order to validate our implementation, we com-

pared the shellcode detection rate of the extended

HoneydV6 to Dionaea’s detection rate by sending a

large amount of malicious trafﬁc to both honeypots.

Because both honeypots are using the same shellcode

detection library (libemu), we expected an equal be-

haviour on both systems.

5.1 Generating Malicious Code Samples

We used the Metasploit Framework version 4.4.0-

release (Metasploit, nd) to generate malicious code

samples that we can send to both honeypots.

Such malicious code sample consists of an exploit,

usually a specially crafted byte sequence which ex-

ploits a software vulnerability, and shellcode which

should be placed on the target system. Metasploit

contains many different exploits targeting various

software vulnerabilities and allows it to combine var-

ious exploits with different shellcodes. Since we only

want to test the shellcode detection capabilities of our

approach, we only vary and send the shellcode bina-

ries and skip the exploits.

The tools msfpayload and msfencode of the

Metasploit Framework were used to create the test

samples. We wrote a simple bash script which calls

msfpayload -l

to create a ﬁle containing a list of

all available Metasploit shellcodes (274 at the time of

writing). For each element in the list, a second bash

script iteratively calls msfpayload and msfencode to

create shellcode binaries as follows:

msfpayload $1 R | msfencode −a x86

−e ge n er ic / none −t raw >

$ o u t f i l e 2> /dev / n u l l

ShellcodeDetectioninIPv6NetworkswithHoneydV6

203

Table 1: Distribution of payload sizes for the transmitted shellcode samples.

Size in bytes 17-32 33-64 65-128 129-256 257-512 513-1024 1025-2048 2049-4096 4097-8192

#Samples 2 3 39 28 24 3 4 4 2

In our case, msfencode takes the shellcode output

of msfpayload and converts it into an x86 binary. We

used the command line parameters

-e

and

-t

to re-

trieve an unencrypted raw binary ﬁle.

For a number of entries in the generated payload

list, msfpayload needed non-default custom parame-

ters which are not provided by our script. We skipped

these entries and obtained 107 valid shellcode bina-

ries that can be used to evaluate the honeypot detec-

tion capabilities.

5.2 Honeypot Setup

We adapted the default Dionaea conﬁgura-

tion to accept HTTP connections by adding

the entries

http

and

httpd

to the section

processors/filteremu/config/allow

in the

default Dionaea conﬁguration dionaea.conf. In order

to enable a verbose logging, we started Dionaea

with the parameters

"-l all,debug -L ’*’"

Dionaea stores all connection information in an

SQLite database called logsql.sqlite. The database

contains the tables connections and emu

proﬁles to

store connection details and malware samples.

HoneydV6 was installed using ./conﬁgure and

make from the GNU Autotools. We conﬁgured Hon-

eydV6 to simulate a single virtual IPv6 host running a

web server. The newly implemented shellcode detec-

tion was enabled by adding the necessary dbﬁle, shell-

codedir and submit entries to Honeyd’s conﬁguration

ﬁle. Detected shellcode is stored in the database ﬁle

honeyd.db.

5.3 Shellcode Transmission

We used the command line tool netcat (Netcat, nd) to

send our malware samples via HTTP GET requests

to HoneydV6 and Dionaea. A script iterates over the

list of the previously generated shellcode binaries and

creates an HTTP GET request for each binary. The

script uses a different TCP source port, starting from

5000, for each connection request to allow the cor-

relation of the logged requests. The sending process

was done consecutively in two steps. In the ﬁrst step,

we sent all trafﬁc to Dionaea before we repeated this

process for HoneydV6 in a second step.

After ﬁnishing the sending process we inspected

the Dionaea and HoneydV6 databases to determine

which connections had been identiﬁed to contain ma-

licious trafﬁc.

Table 2: HoneydV6 detection rate for different shellcode

buffer sizes.

Buffer Size 16 32 64 128 256 - 8192

#Detected 0 12 23 25 26

5.4 Results

We sent 107 different malware samples to Dionaea

and HoneydV6. Since all of the metasploit samples

are considered to be malicious, we can not observe

false positives. The samples are of different size as

shown in Table 1. For the ﬁrst test run, the shellcode

buffer size of HoneydV6 was set to the default size

of 1024 Bytes (see Section 4.1). Figure 3 shows the

number of detected and undetected samples for both

honeypots.

Figure 3: Detection rate of HoneydV6 and Dionaea.

Dionaea creates a database entry for 6 of the 107

shellcodes (about 6 %). HoneydV6 was able to detect

26 malicious samples (about 25%). All shellcodes de-

tected by Dionaea were also detected by HoneydV6.

This different result is surprising, since both hon-

eypots are using the same shellcode detection library

libemu. Hence, both honeypots are using libemu’s

emu getpc check

function to locate GetPC instruc-

tions and to decide whether a byte stream is malicious

or not.

The only difference is that HoneydV6 logs all

samples with a GetPC occurrence into its database.

Dionaea, however, uses further malware proﬁling

functions of libemu to create a complete malware pro-

ﬁle. A database entry will only be created, when the

proﬁle creation could be completed successfully. In

case of a proﬁle creation failure, no database entry

will be created even if a GetPC instruction could be

located. In contrast, HoneydV6 detects as many po-

tential attacks as possible and uses the advanced anal-

ysis function of Anubis for the further examination of

the potential malware.

Further, we investigated the inﬂuence of the size

of the shellcode buffer on the detection rate. There-

SECRYPT2014-InternationalConferenceonSecurityandCryptography

204

fore, we varied the buffer size from 16 Bytes up to

8192 Bytes. Table 2 shows the number of detected

samples for different shellcode buffer sizes. A buffer

size of at least 31 bytes was needed to detect the ﬁrst

sample. Increasing the buffer size up to 32 bytes was

sufﬁcient to detect 12 shellcode samples. Even with

bigger buffer sizes up to 8192 Bytes, libemu detected

at most 26 malware samples.

6 SUMMARY

Attack detection in IPv6 networks is still in an early

stage. Currently, there are only two general pur-

pose low-interaction honeypots available: Dionaea

and HoneydV6.

Shellcode detection in low-interaction honeypots

is an important feature for network health monitoring

and zero-day attack detection. Dionaea already pro-

vides an integrated shellcode detection mechanism.

However,since Dionaea can not be usefully applied to

very large IPv6 networks, we decided to extend Hon-

eydV6 with a similar shellcode detection component.

We achieved this goal by integrating the open-

source detection library libemu into HoneydV6. Be-

yond the detection and extraction of shellcode bina-

ries, we integrated the online malware analysis ser-

vice Anubis into HoneydV6 to allow an advanced pro-

ﬁling of malware samples.

In our evaluation, we compared the shellcode de-

tection rate of Dionaea and HoneydV6. Since both

honeypots are using the same shellcode detection li-

brary libemu, we expected a similar detection rate

for both honeypots. We found that Dionaea detected

about 6%, while HoneydV6 can detect about 25% of

all our generated malware samples. This difference in

the detection rates can be explained by an additional

proﬁling mechanism only present in Dionaea, which

is used as an additional alert ﬁlter criteria.

What is noticeable, though, is the general low de-

tection rate for shellcode attacks. This shows that

there is still a lack of more advanced open-source

shellcode detection libraries that could mitigate these

kind of network attacks.

Still it is not possible to inspect trafﬁc that is en-

crypted on service layer. This problem can be partly

solved by extending HoneydV6 with an internal TLS

implementation so that HoneydV6 is responsible for

encrypting and decrypting the communication and

therefore keeps control also over the encrypted com-

munication.

REFERENCES

Anubis (nd). Anubis: Analyzing Unknown Binaries. Avail-

able from: http://anubis.iseclab.org.

Baecher, P. and Koetter, M. (nd). libemu –

x86 Shellcode Emulation. Available from:

http://libemu.carnivore.it/.

Beale, J., Baker, A. R., Esler, J., and Northcutt, S. (2007).

Snort: IDS and IPS toolkit. Jay Beale’s open source

security series. Syngress.

Dionaea (nd). dionaea catches bugs. Available from:

http://dionaea.carnivore.it/.

Fratantonio, Y., Kruegel, C., and Vigna, G. (2011). Shel-

lzer: A tool for the dynamic analysis of malicious

shellcode. In Proceedings of the 14th International

Conference on Recent Advances in Intrusion De-

tection, RAID’11, pages 61–80, Berlin, Heidelberg.

Springer-Verlag.

Honeyd (nd). Honeyd Virtual Honeypot. Available from:

http://www.honeyd.org.

kippo (nd). kippo - SSH Honeypot. Available from:

https://code.google.com/p/kippo/.

Malwr (nd). Malwr - Malware Analysis by Cuckoo Sand-

box. Available from: https://malwr.com.

McCanne, S. and Jacobson, V. (nd). tcpdump & libpcap.

Available from: http://www.tcpdump.org/.

Metasploit (nd). Metasploit: Penetration Testing Software.

Available from: http://www.metasploit.com.

Netcat (nd). The GNU Netcat project. Available from:

http://netcat.sourceforge.net.

Polychronakis, M., Anagnostakis, K. G., and Markatos,

E. P. (2006). Network level polymorphic shell-

code detection using emulation. In Proceedings

of the Third International Conference on Detection

of Intrusions and Malware & Vulnerability Assess-

ment, DIMVA’06, pages 54–73, Berlin, Heidelberg.

Springer-Verlag.

Sandbox, C. (nd). Cuckoo Sandbox. Available from:

http://www.cuckoosandbox.org.

Schindler, S., Schnor, B., Kiertscher, S., Schefﬂer, T., and

Zack, E. (2013). HoneydV6: A low-interaction IPv6

honeypot. In Proc. of the 10th International Confer-

ence on Security and Cryptography (SECRYPT 2013),

Reykjavik, Iceland.

Spitzner, L. (2002). Honeypots: Tracking Hack-

ers. Addison-Wesley Longman Publishing Co., Inc.,

Boston, MA, USA.

Sz¨or, P. and Ferrie, P. (2001). Hunting for metamorphic. In

In Virus Bulletin Conference, pages 123–144.

ShellcodeDetectioninIPv6NetworkswithHoneydV6

205