Honeynet Height Interactive Tool Sebek3 Detecting

Techniques

Dr.Farraj Aizzden, Mohammed Almehdhar, Mohammad Ismail Amro King Fahd University of Petroleum and Mineral

fazzedin@kfupm.edu.sa , g200804340@kfupm.edu.sa ,mamro@kfupm.edu.sa

Abstract

It is usually assumed that new versions of SEBEK are hard to detect and

solve all the problems in the previous version that attempts to detect them

can be unconditionally monitored. we focused on creating a virtual

honeynet using VMWARE as proof of concept of honeynets, and

scrutinize this assumption and applying methods that attackers used to

detect the previous version of SEBEK (version 2) and applied them on

the new version of SEBEK (version 3) and check also if there are any

new methods to do the same on SEBEK 3.

I. Introduction :

Sebek is the main capture tools in the honey projects that has been

detected by several ways ,the new version of sebek(sebek3) should solve

all problems with the previous version .In this term paper we build a

virtual honeynet to check if the sebek3 still have the same problems as

old version and if there are new ways to detect it .

The Honeynet Projectis an international volunteer organization dedicated

to computer security

research. It was founded in 1999 and holds non-profit (501c3) status in

Illinois, USA. Membership is drawn from active chapters in over 25

countries, which helps to provide a global research perspective, and the

organization is strongly committed to the ideals of the Open Source

movement[1] .The goal of the Honeynet Project is to learn about “the

tools, tactics and motives involved in computer network attacks”, which

is primarily carried out through the use of honeypots and honeynets

(networks of honeypots). A honeypot has been defined as “a security

resource whose value lies in being probed, attacked, or compromised"[2].

Honeynets

are one type of honeypot. A honeypot is a resource who's value is

in being probed, attacked or compromised. A Honeynet is a high-

interaction honeypot, meaning it provides real operating systems for

attackers to interact with. This high interaction can teach us a great deal

about intruders, everything from how they break into systems to how they

communicate and why they attack systems..

A virtual Honeynet

is a solution that allows you to run everything you need on a single

computer. The term virtual because it all the different operating systems

have the 'appearance' to be running on their own, independent computer.

These solutions are possible because of virtualization software that allows

running multiple operating systems at the same time, on the same

hardware. Virtual Honeynets are not a radically new technology, they

simply take the concept of Honeynet technologies, and implement them

into a single system. This implementation has its unique advantages and

disadvantages over traditional Honeynets. The advantages are reduced

cost and easier management, as everything is combined on a single

system[3].

A Self-Contained Virtual Honeynet

is an entire Honeynet network condensed onto a single computer. The

entire network is virtually contained on a single, physical, system. A

Honeynet network typically consists of a firewall gateway for Data

Control and Data Capture, and the honeypots within the Honeynet. Some

advantages of this type of virtual Honeynet(s) are:

Portable, Virtual Honeynets can be placed on a laptop and taken

anywhere. The Honeynet Project demonstrated this funtionality at

the Blackhat Briefings in August, 2002

Plug and Catch, You can take the one box and just plug it in to any

network and be ready to catch those blackhats. This makes

deployment much easier, as you are physically deploying and

connecting only one system.

Cheap in money and space, You only need one computer, so it cuts

down on your hardware expenses. It also has a small footprint and

only takes one outlet and one port! For those of us with very

limited space and power, this is a life saver.[4]

There are some disadvantages:

Single Point of Failure, If something goes wrong with the

hardware, the entire honeynet could be out of commission.

High Quality computer, Even though a Self-Contained Honeynets

only require one computer, it will have to be a powerful system.

Depending on your setup, you may need a great deal of memory

and processing power.

Security, Since everything might be sharing the same hardware,

there is a danger of an attacker getting at other parts of the system.

Much of this depends on the virtualization software, which will be

discussed later.

Limited Software, Since everything has to run on one box, you are

limited to the software you can use. For instance, its difficult to run

Cisco IOS on an Intel chip.[4]

Honeypot taxonomy

There are two primary categories of honeypots, research and

production. Additionally, there are two types of honeypots, high-

interaction and low-interaction, depending on what they allow attackers

to accomplish. Lastly, there are honeynets, or groups of honeypots,

designed to look like a network (Gen I and Gen II). This subsection will

discuss honeypots and the next subsection will discuss honeynets

generations.

Honeypot Categories

A research honeypot is deployed to collect information on new

attacks and the blackhat community. Usually, detecting an attack is very

difficult and a time-consuming work. However with a honeypot, since it

does no actual work, any activity on the honeypot machine is

immediately assumed to be malicious. Therefore, if an administrator

suddenly sees traffic going into the honeypot, he can begin to inspect that

traffic and determine exactly what its purpose is. If the traffic is deemed

to be malicious, the administrator must then decide when enough data has

been collected and the honeypot can be shut down for analysis.

A production honeypot is deployed (usually in a business setting)

for the purpose of mitigating security risks in an organization. Production

honeypots protect a network as follows. First, a honeypot does not only

detect threats from the Internet, but if deployed on an internal network, it

can also detect insider threats (because insider criminals will access the

honeypot to obtain information). Second, a honeypot can be a good

barometer of threats against the network. Third, by making a honeypot

seem very valuable to an attacker, a good administrator can lure in a

hacker, and have them spend their resources exploiting the honeypot

when they would otherwise be compromising the general network.

Honeypot Types

High-interaction honeypots are honeypots that do not emulate the

operating systems. Instead they are full operating systems and

applications found in many homes and organizations today. These

solutions are more time consuming than low-interaction solutions, but can

potentially capture more types of information and in greater depth [11].

Low-interaction honeypots are honeypots that emulate computers,

services, or functionality. These are easier to deploy, but may be limited

in the amount or type of information they can collect. Examples of this

type of honeypots include Nepenthes, honeyd, and honeytrap.

Honeynet Generations

Generation I

Gen I Honeynets were developed in 1999 by the Honeynet Project

(Figure 1). The purpose of Gen I Honeynets was to capture the maximum

amount of attacker activity and give them a feel of a real network. The

architecture of Gen I Honeynets is uncomplicated. The approach used for

data capture and data control is simple, which makes it detectable by

attackers sometimes. However, it can capture large amount of

information and even can help in capturing unknown attacks. [12]

Figure 1. Gen I honeynet architecture [2]

The ability of this architecture to control and capture attacks makes

it very effective in capturing known, automated, and beginner level

attacks. However, it is not effective in capturing advance attacks because

it can be easily detected by advanced attackers. Data Control is done by

putting a layer three firewall in front of Honeypots. The firewall works as

a gateway in NAT (Network Address Translation) mode and controls all

the inbound and outbound connections. It allows all inbound connections,

but limits outbound connections. The firewall keeps track of all the

outbound connections an attacker makes, and when a certain limit is

reached, it blocks all outgoing connections from the Honeynet. [12]

As we know that the purpose of data capture is to log as much

information as we can without attackers knowing it. In Gen I Honeynets,

data logging is done on multiple layers to avoid single points of failure.

The first layer of data logging is a firewall. We do not get detailed

information through firewall logs but any information available is helpful

in the case of a Honeynet. Firewalls give information about the

source/destination IP address, source/destination port, protocol, and

date/time. The second layer of data logging is the IDS. An Intrusion

Detection System (IDS) is deployed on the gateway, which logs every

packet and its payload traveling on the wire. IDS logs provide most

useful information about every packet traveling to and from the

Honeynet. IDS also raise an alert when it catches any suspicious activity.

The third layer of data logging is the system logs which log the attacker’s

activity on the Honeypot itself. The keystrokes and screenshots are

captured by installing a modified version of bash or a kernel module. The

logs are securely forwarded to a remote server over the network to

analyze them. The disadvantage of transferring the logs over the network

is that it can be easily detected by an advanced attacker. [16]

Generation II

Gen II Honeynets, shown in Figure 2, were developed in 2002 by

the Honeynet Project after identifying the problems and issues in Gen I

architecture. The problems in Gen I were solved by changing the

architecture of Gen II Honeynet. In Gen I architecture, the firewall works

on layer three which is easily detectable. This problem is addressed by

deploying a layer two gateway device, which makes it harder to detect.

[12]

The firewall works in a BRIDGE mode and controls all the

inbound and outbound connections as in Gen I architecture. This

connection control mechanism allows only a predefined number of

connections to be initiated from the honeynet to the honeynet

administration stations. The new ability added to the gateway in Gen II is

the IPS (Intrusion Prevention System). Basically, IPS is similar to the

IDS but has also the capability to block and modify the attacks. As we

know, most of the IDSs have a signatures database of known attacks. So,

if the packet traveling on the wire matches the signature, the IPS can

block or even modify that packet. This capability helps in distinguishing

between legitimate and malicious activity. If an attacker would try to run

an exploit against a non-Honeypot system, the IPS would be able to block

or modify the attack with known signatures even if the number of

connections initiated is still bellow the allowed limit. The IPS mechanism

works with known attacks only, so unknown attacks can bypass this

technology. For that reason, the IPS is combined with a connection

control mechanism. Using the connection control mechanism, unknown

attacks will be blocked after a certain limit of connection trials even if it

does not match any signature. The mechanism of using L2 bridge firewall

in honetnets Gen II instead of L3 firewall that were used in honeynets

Gen I makes the Honeynet harder to detect as the bridges are very hard to

identify. [13]

Figure 2. Gen II honeynet architecture [12]

The data capture mechanism in Gen II is somehow similar to the

mechanism used in Gen I. Data logging is done on three layers: firewall

layer, network layer (IDS) and system layer (SysLog). The most difficult

part is to capture the attacker’s activity on the Honeypot itself. Sebek is

the newest and greatest development that has been done for data

capturing during Gen II. A data Collection and Alerting mechanism is

also introduced in Gen II Honeynets. The data Collection mechanism

allows the collection and analysis of the data from distributed Honeynet

deployments. The alerting mechanism notifies if someone breaks into the

Honeynet, which helps in keeping track of the activity. [12]

Generation III

Gen III honeynets were released in the end of 2004 [13]. Gen III

has similar architecture to that of Gen II. The only difference between the

two architectures is that Gen III has more improvements in the

deployment and management [13].

In our term project, we deployed virtual homemade high

interaction honeypots with the honeywall gateway version 1.4 which is

the latest version of honeywall CDROM. This version of honeywall was

distributed to meet the requirements of deployment and management for

Gen III honeynets. There are no major changes between Gen II and Gen

III. For that reason, we designed our honeynet on the basis of Gen II.

Sebek

is a new way to capture the activities of an intruder on an Linux

and Windows systems was developed: A kernelbased Sebek [2] is able to

record all data accessed by users via the read() system call on the

honeynet. It replaces the normal read() system call with a new entry in the

system call table pointing to its own versio of this system call. It is then

able to record all data accessed via read() [3]. Because Sebek lives

entirely in kernel-space and has access to all data read, this rootkit is able

to access most communication unencrypted and it can for example log

SSH-sessions, recover files copied with SCP

and record all passwords used by intruders. The recorded data is

sent via UDP to the Sebek server, the other part of Sebek’s client/server

architecture. This transmission is done by modifying the kernel in order

to hide these packets such that an intruder can not see them. In addition,

all network counters and data structures have to be readapted in order to

make detecting these changes more difficult. Further information about

Sebek and its architecture can be found in [3].

In this paper we reuse that a qualified attacker ways to detect

Sebek2 and apply them on Sebek 3 , to check weather these problems

has been solved in the new version of Sebek(sebek 3) and if there any

new method to detect sebek 3. The paper is outlined as follows: Section II

gives an overview of , related work in the field of detection of honeynets.

Several ways to detect Sebek, , an overview of our honeynet and

methods to detect sebek , are presented in section III. Directions of

further work areoutlined in section IV and we conclude this paper with

section V.

II. Related work

Unfortunately, there is little scientific literature on the topic of

honeynets and none on detecting Sebek 3. The only related work was

published for Sebek 2 such as two fake issues of Phrack [4], a Hacker

magazine that is famous for its articles in the blackhat community. In

Phrack 62 [5] an article entitled “Local Honeypot Identification” was

published. It describes a method to disable Sebek by just overwriting

Sebek’s read() system call in the system call table with the original value

and thus disabling Sebek. detect the existence of Sebek on a host were

also presented in the article Another idea to defeat Sebek was published

in issue 63 of the Phrack magazine [7]: The article “Advanced Honey Pot

Identification” describes a way to search through memory and look for

characteristic symbols used by Sebek. Issue 61 of the Phrack magazine

contained an article on detection of hidden kernel modules in its

“Linenoise” section [8]. The article describes a brute force method for

detecting hidden modules by looking for what appears to be the key

module structure. This method was able to locate a hidden Sebek module.

There also is a tool named chkrootkit which “is a tool to locally check for

signs of a rootkit” [9]. While the documentation claims that the tool is

able to detect Sebek, this is only true for very old versions of Sebek.

Detecting is accomplished by searching /proc/ksyms for the string several

ways to detect and circumvent Sebek.

Detecting Sebek

Sebek is a kernel module, so it leaves several traces of its existence

in memory. We now describe ways to track down those traces, thus

leading to the detection of Sebek. One of our first experiments originally

was aimed at making logging by Sebek unreliable. An easy way to detect

Sebek which can be used even by unprivileged local users:

user@honey:~ dd if=/dev/zero of=/dev/null bs=1

This simple command results in backward running packet and byte

counters of the network interface, so even an unprivileged user was able

to detect Sebek by checking the output of ifconfig. To understand why

using dd should lead to unreliable logging by Sebek, one has to take a

closer look at the logging process: As explained above, Sebek replaces

the normal sys read() call in the system call table with its own version and

is thus able to record all data accessed via read(). The logging data is then

transfered in a covert way via UDP over the network[3]. Therefore, if we

are reading a single byte via a read(1), Sebek has to transfer nearly 100

Bytes of data including all the network headers over the network to the

host doing the logging. So if we are able to do a read(1) some tens of

thousands of times per second, this will lead to a congested network and

finally to dropped packets. And we are able to identify a congested

network with the help of the ping command.

This leads to another way to detect Sebek, which we call the dd-

attack, since it can accomplished with a simple command like dd, as

shown above. To detect Sebek on a host, we first ping a local IP-address

(e.g. the gateway) in order to get an overview of the current performance

of the network. Then dd is started in the background and we rerun the

ping command. If Sebek is installed on a host, this leads to an enormous

increase in the average round-trip time. In practical tests of this attack the

average round-trip time grew from 0.7 milliseconds to over 4800

milliseconds.

published in Phrack 63 [7]: Sebek is a kernel module and it has to

use some kernel memory in order to be able to store its variables like

magic number and source or destination port. Version 2.1.7 uses some

randomization and other stealth techniques in order to prevent easy ways

to find these variables, but Sebek leaves some traces in memory that can

be found: • Since Sebek by default chooses a random number below

1000000000 as the module name it is easy to create heuristics to detect

the Sebek module purely by its name in the lists of modules generated by

the methods outlined in [8]. A small obstacle in doing so is that there are

legitimate modules with purely numeric names like 8390, a driver for a

generic Ethernet chipset. Helpful in the detection of Sebek symbols is the

knowledge that all it’s symbol names start with a letter, followed by a

number with up to three digits. Also helpful is the fact that a conversion

table to translate IP addresses into integers is left in memory. In addition

to falsify /proc/net/dev output, Sebek has to keep more than 200 bytes of

strings in memory, which can be located without great effort. The hidden

Sebek module still has a complete module header structure in memory.

This structure can be found with very little effort[8] and used to locate

Sebek’s code (e.g.its cleanup function) and variable storage. While the

placement of variables in Sebek’s variable storage block is different every

time Sebek is compiled, it is still possible to locate the variable storage

block via the module header. That information can be used to

successfully guess most variables like magic number, source and

destinationport with a few tries. All these traces can be found by

traversing memory an looking for appropriate structures and thus leading

to a way to detect hidden kernel modules, identify the Sebek kernel

module and extract secrets from the module. In [5], a way to detect the

changes in the system call table for Solaris is proposed. When Sebek

installs its read() monitoring function, it replaces the function pointer in

the system call table at NR read with a pointer to its own function,

declared in the module. While on a system without Sebek, the system call

pointers are close to one another in memory, this changes if Sebek is

loaded into memory. The address of Sebek’s function does not lie near

the address of sys write, the successor of sys read in the system call table.

Thus, if the addresses of sys read and sys write lie far apart (e.g. more

than 4096 byte), we conclude that the system call table was modified by

some rootkit. Furthermore, there is another similar way to detect Sebek:

After Sebek has replaced the function pointer in the system call table, sys

read points inside the memory range of a module. This is a clear sign that

the system calls were changed and a rootkit is present. We wrote a

program that searches through memory and finds both of these anomalies.

Approach:

In this paper , we introduce methods that used to detect sebek2 and

apply them in sebek3 . Specifically. We tried to detect sebek with direct

command line in Linux and Windows based,write a program to check

system call table ,we also use an API programs to check the existence of

sebek.

Our homemade honeypots as virtual machines. Honeypots have

been installed with VMWARE Workstation. VMWARE allows different

machines that run different OSes to run on the same computer system

[14]. We deployed four virtual machines as honeypots. One machine runs

Windows-XP. The other machine runs Ubuntu-8.1. All systems placed

within the honeynets are standard production systems. These are real

systems and applications. These honeypots are meant to be probed and

attacked. Figure 1 shows a scheme.

figure3:Virtual Honeynet Architecture()

We have configured the honeywall and put it on VMWARE

machine with the honeypots in a virtual team.We started our mission with

DD attack method (see Detecking sebek A) this method has applied for

both systems win32 and linux .In windows we have opened two

command line the first one to measure the round –trip time using ping

command before copying files and during copying process ,and we found

that :

Stat Round Trip

Time (millisecond)

Before

copying

0.4

During copy

(1)

60

During copy

(2)

15

Linux

Before

copying

0.7

During copy

(1)

45

During copy

(2)

20

Table 1

As shown in table 1 that sebek3 has solved the problem of

generating the huge traffic (due DD attack) which reduced the TTL from

about 7200mms to 60mms .and even this it will give some sing to the

existence of sebek but it will not much clear as which in sebek2.

The second method we applied is In [5], a way to detect the

changes in the system call table we carried this idea forward and

implemented it: When Sebek installs its read() monitoring function, it

replaces the function pointer in the system call table at NR read with a

pointer to its own function, declared in the module. While on a system

without Sebek, the system call pointers are close to one another in

memory, this changes if Sebek is loaded into memory. The address of

Sebek’s function does not lie near the address of sys write, the successor

of sys read in the system call table. Thus, if the addresses of sys read and

sys write lie far apart (e.g. more than 4096 byte), we conclude that the

system call table was modified by some rootkit. This is a clear sign that

the system calls were changed and a rootkit is present. We wrote a

program that searches through memory and finds both of these anomalies.

As an example, table 2 shows the places of two system calls in memory

before and after Sebek is loaded. One can clearly see that the system call

table was modified and something malicious is happening.

System

Call

Address Before Address After

Read C014C91C F8BEE8840

Write C014C97F C014C97F

Table (2)

Detecting Sebek Useing Anti Rootkit Software:

Rootkitrevealer:

The term rootkit is used to describe the mechanisms and techniques

whereby malware, including viruses, spyware, and trojans, attempt to

hide their presence from spyware blockers, antivirus, and system

management utilities. There are several rootkit classifications depending

on whether the malware survives reboot and whether it executes in user

mode or kernel mode. Because Sebek is a rootkit-style kernel module we

use new anti Rootkit open source software to detected sebek in its register

record figure show the sebek hidden register key, figure 4 show the

traffic that sebek send to sebek server when this tool do the scan, we can

solve this problem by hooking the cmd and rewriting the output that

contain sebek string.

Show Kernel Active Process List

Sebek can also be identified on Windows looking at loaded drivers,

we use the KProcCheck with -d parameter that will print a list of all

loaded drivers by tranversing the PsLoadedModuleList ,the result show

Figer 4 sebek hidden register key

that sebek 3 solve this problem by give new name other than sebek to its

module in configuration step .

IV. Conclusions

From all the methods used in this paper we conclude that, Sebek 3

has been solving some problems that presented in sebek 2, but on the

other hand we have shown that Sebek 3 can be detected. An

unsophisticated attackers might not be able to circumvent Sebek 3 or not

even try to do so, we assume that sophisticated attackers can detect

honeynets .If there are already very advanced techniques of detecting and

disabling honeynets discussed in the open wild [5], [7], we have to

assume that there are much more evolved techniques available to highly

advanced attackers and there is always new ways to defeat it .

V. Further work

There is a broad range of possibilities to enhance our work in

further detecting sebek 3 . For further detecting Sebek we see lots of

possibilities. Some of them include:

• Sebek leaves many traces in memory: It is a kernel module and thus

uses some special data structures, it uses characteristic variables and

builds UDP packets in memory. Therefore it should be possible to search

through memory and detect its existence in several other places than by

looking for module structures.

• Hook into the low level networking layer at the level of the

network drivers to unhide Sebek’s logging packages. If we turn the table

again and take the view of a honeynet researcher, we see some topics of

interest in order to harden Sebek and its general approach to log activities

of intruders:

• Obviously, transforming Sebek to be a kernel patch instead of a

loadable kernel module should be aspired. Detecting and removing Sebek

if it is not dynamically loaded as a kernel module would be much more

difficult and installation after a reboot would become a non-issue. On the

other hand, deployment of Sebek would get complicated by doing so. In

our opinion this is actually desirable, since

honeynets are dangerous and ethically problematic tools and

entities wishing to deploy honeypots should be willing and able to got to

the pains of patching and compiling a kernel.

• Adding further cleaning of module structures in memory after

installing the Sebek kernel module, using a less predictable way of

generating the “random” symbol and module names.

• Further obfuscating the placement of Sebek’s variables in

memory and adding decoy variables.

• Using source and destination ports and MAC addressees in

addition to the magic number when identifying Sebek packages to extend

search space from 248 to 2160 Packets when brute-forcing.

On the other hand from all these methods we can gain what

problems are still sebek suffer and try to fined new solution for all these

problems

References

[1] “The honeynet project.” Internet: http://www.honeynet.org/.

[2] Know Your Enemy: Honeywall CDROM Roo, 3rd Generation

Technology”. Honeynet Project & Research Alliance,

http://www.honeynet.org. August, 2005

[3] “Sebek.” Internet: http://honeynet.org/papers/honeynet/tools/sebek/,

2004.

[4] The Honeynet Project, “Know your Enemy: Sebek,” November 2003.

http://www.honeynet.org/papers/sebek.pdf.

[5] “Phrack magazine.” Internet: http://www.phrack.org/.

[6] J. Corey, “Local Honeypot Identification,” September 2003.

http://www.phrack.org/fakes/p62/p62-0x07.txt.

[7] “Snort inline.” Internet: http://snort-inline.sourceforge.net/, 2004.

[8] J. Corey, “Advanced Honey Pot Identification,” Januar 2004.

http://www.phrack.org/fakes/p63/p63-0x09.txt.

[9] madsys, “Finding hidden kernel modules (the extremway),” 2003.

http://www.phrack.org/phrack/61/p61-0x03_Linenoise.txt.

[10] “chkrootkit homepage.” Internet: http://www.chkrootkit.org/.

[11] The Honeynet Project, “Know Your Enemy: GenII

Honeynets,”November 2003. http://www.honeynet.org/papers/gen2/.

[12] m1lt0n, “Keeping 0day Safe,” Januar 2004.

http://www.phrack.org/fakes/p63/p63-0x08.txt.