Detecting Botnets using a Collaborative Situational-aware IDPS

M. Lisa Mathews, Anupam Joshi and Tim Finin

Department of Computer Science & Electrical Engineering, University of Maryland,

Baltimore County, Baltimore, MD, U.S.A.

Keywords:

Intrusion Detection, Situational-aware, Botnet Detection.

Abstract:

Botnet attacks turn susceptible victim computers into bots that perform various malicious activities while

under the control of a botmaster. Some examples of the damage they cause include denial of service, click

fraud, spamware, and phishing. These attacks can vary in the type of architecture and communication protocol

used, which might be modiﬁed during the botnet lifespan. Intrusion detection and prevention systems are

one way to safeguard the cyber-physical systems we use, but they have difﬁculty detecting new or modiﬁed

attacks, including botnets. Only known attacks whose signatures have been identiﬁed and stored in some form

can be discovered by most of these systems. Also, traditional IDPSs are point-based solutions incapable of

utilizing information from multiple data sources and have difﬁculty discovering new or more complex attacks.

To address these issues, we are developing a semantic approach to intrusion detection that uses a variety of

sensors collaboratively. Leveraging information from these heterogeneous sources leads to a more robust,

situational-aware IDPS that is better equipped to detect complicated attacks such as botnets.

1 INTRODUCTION

Botnets have the potential to cause substantial dam-

age to the various hosts and networks they target

or affect. They are a pervasive type of attack in

which bots perform various malicious activities while

under the control of a botmaster. A few of their

well known consequences are denial of service, click

fraud, spamware, and phishing (Thuraisingham et al.,

2008; Feily et al., 2009). To make matters even more

interesting, they can be difﬁcult to detect. Bailey et

al. summarized this well when they said botnets “can

propagate like worms, hide from detection like many

viruses, attack like many stand-alone tools, and have

an integrated command and control system” (Bailey

et al., 2009). The destructive effects of botnets have

lead the Obama Administration to propose giving the

Department of Justice the ability to issue injunctions

for attacks where at least 100 computers have been

hacked (Prince, 2015).

Current state-of-the-art intrusion detection and

prevention systems (IDPSs) are recognized as hav-

ing limitations that lessen their effectiveness in deal-

ing with attacks, especially those of a more sophis-

ticated nature. Conventional IDPSs are typically

point-based solutions incapable of utilizing informa-

tion from other sources, even if this data was available

for them to use. They are limited in the attacks they

can identify by the signatures stored in their database.

They cannot detect zero day type attacks, attacks that

use low-and-slow vectors, or other complicated at-

tacks such as botnets. Many times an attack is only

revealed by post facto forensics after some damage

has already been done.

We tackle the limitations mentioned above by cre-

ating a collaborative situational-aware IDPS that uses

a variety of information sources to detect attacks. The

collaborative aspect comes from the fact that multi-

ple sensors are employed, both traditional and non-

traditional. Traditional sensors encompass the vari-

ous hardware and software available to scan and/or

monitor hosts and networks, such as Snort or Nor-

ton Antivirus or less conventional tools such as Pro-

cess Explorer. Other types of IDPSs might gather in-

formation from different sensors, but some only in-

clude sensors from a single vendor, and most simply

dashboard the information that is acquired. For the

IDPS we are developing, incorporating speciﬁc prod-

ucts or vendors is not important, and the information

is stored in a knowledge base for system integration.

The goal is to have some combination of hardware

and software that provides a clear picture of what is

happening on the hosts and network. This would a

network administrator to use the tools they already

have available to them. By nontraditional sensors,

we mean online sources in the forms of vulnerability

290

Mathews, M., Joshi, A. and Finin, T.

Detecting Botnets using a Collaborative Situational-aware IDPS.

DOI: 10.5220/0005684902900298

In Proceedings of the 2nd International Conference on Information Systems Security and Privacy (ICISSP 2016), pages 290-298

ISBN: 978-989-758-167-0

databases, forums, blogs, etc., that contain structured

and unstructured textual descriptions of potential vul-

nerabilities or exploits. These descriptions are often

for unpatched vulnerabilities, such as those from the

National Vulnerability Database (NVD), that attack-

ers could potentially use to target affected systems.

Information gathered from these different chan-

nels is stored as facts into a knowledge base using

a W3C standards based ontology that has been de-

veloped in house. In addition, high level rules, the

kind that are typically used by an analyst as they look

at data for evidence of attacks, are also encoded in

the same ontology. The IDPS that emanates from

the various sources working in conjunction is well

armed to stop complex attacks such as bonets. This

paper describes our overall approach and a prelimi-

nary version of this system that detects botnets. We

validate the system by using a variety of cues to de-

tect two botnets, namely Skynet and W32/Vobfus, aka

W32/Changeup.

The rest of this paper is organized as follows. Sec-

tion II details the background of the IDPS along with

a brief botnet overview. Section III goes over the re-

lated work. Section IV describes the system setup and

validation, and Section V contains the results. Section

VI provides the concluding remarks.

2 BACKGROUND

2.1 IDPS

Intrusion detction systems (IDSs) are a popular

method for defending cyber-physical systems against

various threats. Basically, they passively observe host

and/or network data and show an alert when anoma-

lous behavior is detected. An IDS will not take any

action against a potential threat; instead, it stores

these observations in a log ﬁle and shows an alert.

Intrusion Prevention Systems (IPSs) are more active

and will attempt to thwart any intruders from harm-

ing a system. Combining these two systems forms a

more robust defense mechanism known as an IDPS.

In previous work, we presented a novel approach

to intrusion detection and prevention by making an

IDPS situationally-aware (More et al., 2012) and col-

laborative (Mathews et al., 2012). The essence of this

IDPS is to take the data gathered from traditional sen-

sors and add to that the data gained from nontradi-

tional sensors, like online forums or Twitter feeds,

analyze this data, and create additional facts and in-

formation expressed using an ontology we created. In

combination with rules, also expressed using terms

Figure 1: Our architecture supports situation awareness

by integrating and analyzing data extracted from multiple

sources, both traditional and nontraditional. The results are

represented in a knowledge-based system and reasoned over

to detect potential attacks. Taken from (Mathews et al.,

2012).

from this ontology, that are normally used by ana-

lysts to detect attacks post facto, the system can in-

fer if a situation is indicative of an attack. The use of

heterogeneous and diverse data sources can provide a

wider picture of the system activities and information

related to potential attacks that are being discussed,

and thus, better help detect zero day attacks for which

signatures do not exist.

The designed framework can be split into two

main sections. The ﬁrst involves the gathering of data

from different channels such as online web sources,

logs from existing IDS/IPS systems, host-based ac-

tivity monitors, network activity monitors, and hard-

ware security sensors. The second section employs

an ontology to model both the intrusions in terms

of their deﬁning characteristics and the various hosts

and networks of a system in terms of their properties

and behavior. This information is stored in a knowl-

edge base as a set of rules, and a reasoner is used

to extract additional information from this knowledge

base. The system architecture designed for this col-

laborative situation-aware IDS (More et al., 2012) is

depicted in Figure 1. The components of the second

section will be described in the next few paragraphs.

The ontology used in this work is one focused on

cybersecurity concepts and is an extension of a previ-

ous ontology developed in house (Undercoffer et al.,

2003). The classes present in this current ontology al-

low an attack to be represented in terms of its means

and consequences and a system to be represented by

its host and network properties. The means of an at-

tack is the method in which it is executed, such as

a buffer overﬂow. The consequence would be the

end result, which could be denial of service (DoS)

for the previous means. Examples of system prop-

erties modeled by the ontology include operating sys-

Detecting Botnets using a Collaborative Situational-aware IDPS

291

tems, processes running, and IP addresses. As stated

in our previous work, the knowledge base is built up

by encoding the information as Web Ontology Lan-

guage (OWL (Bechhofer et al., 2004)) and Resource

Description Framework (RDF (Manola et al., 2014))

assertions. We serialize these using Notation-3 (N3

(Berners-Lee and Connolly, 2014)) triples of the form

(subject predicate object) that asserts that the relation

p holds between s and o (Mathews et al., 2012).

The reasoning logic component takes the output

from the various data channels, knowledge base as-

sertions, rules, and information representation prop-

erties of the ontology to infer the presence of an at-

tack. This reasoner allows for additional facts to be

inferred, either from rules, or from the structure of the

ontology. Take for example a triple that describes a

network activity such as “ComputerA sendsPacketTo

ComputerB”. As humans, we understand that this

can also be expressed as “ComputerB receivedPack-

etFrom ComputerA”, but with the use of the reasoner

and an owl:inverseOf statement relating sendsPack-

etTo and receivedPacketFrom, the system knows this

as well.

2.2 Botnets

Most of the top-rated IDPSs implemented to defend

computer networks will not be able to stand up to

newly published attacks, especially the more compli-

cated ones such as botnets. A botnet consists of a bot-

master, or botmasters in some cases, that gains control

of its victims through various methods, turning these

compromised computers into its bots, short for robots

(Feily et al., 2009; Bailey et al., 2009). One property

of botnets that distinguishes them from other types of

malware is their use of command and control (C&C)

servers. The bots will continue to receive instructions

from its botmaster while the botnet lives on, usually

through a backdoor. Different botnets have different

architectures and communication protocols, and these

can in fact change during the course of the attack. In

the past, these attacks have utilized a more central-

ized structure for communication amongst the mem-

bers of the botnet, while more recent designs have im-

plemented a decentralized architecture using peer-to-

peer (P2P) communication.

Skynet, discovered in December 2012, was a com-

plex botnet with different mechanisms in place to add

stealth and ﬂy under the radar while performing ma-

licious activities including execution of a distributed

DOS, illegal Bitcoin generation, and procurement of

online login credentials (Constantin, 2012). As seen

with other botnets, Skynet is a variant of another bot-

net, in this case Zeus. The supposed inventors of this

attack had possibly created nearly one million dol-

lars in Bitcoins using a modiﬁed Zeus banking tro-

jan and infested more than 12,000 computers by the

time they were caught in December of 2013 (Kumar,

2013; Constantin, 2012). Its use of Tor to hide its In-

ternet Relay Chat (IRC) C&C communication makes

identifying the servers and bots more difﬁcult. Tor

is a specialized software that provides trafﬁc encryp-

tion and anonymity by dispersing its users’ trafﬁc over

several relays, thus hiding the location of its users and

making trafﬁc analysis a challenge (Guarnieri, 2012).

The IDPS described in this paper would be able to

detect this attack using the combination of traditional

and nontraditional sensors as described without hav-

ing components speciﬁcally designed for botnet de-

tection.

3 RELATED WORK

In prior work, we described our efforts in creating

a situational-aware IDPS framework and also pre-

sented the details for a network trafﬁc based classi-

ﬁer that shows promise for detecting malicious trafﬁc

(Mathews et al., 2012; More et al., 2012). Sharma

et al. (Sharma et al., 2013) designed and validated a

framework that contains several modules for monitor-

ing various parameters that indicate the occurrence of

data exﬁltration, examples of which include network

usage and DLLs called. Monitoring these parameters

would allow a system to be proﬁled in terms of its

normal behavior for all layers, i.e., from hardware up

to application.

There have been many papers published that fo-

cus on botnet detection and even a few survey papers

that cover the different detection techniques. The pa-

per by Feily et al. (Feily et al., 2009) provides an

overview of botnet detection methods while covering

the basics of the botnets including the terminology,

characteristics, and infection life cycle. The authors

of this survey state that botnets can be classiﬁed ac-

cording to their command and control architecture,

which they also emphasize is the deﬁning property

of these attacks that also provides anonymity for the

botmaster. The four detection methods they summa-

rize and then go on to compare and contrast are sig-

nature based, anomaly based, DNS based, and min-

ing based. The evaluation criteria included determin-

ing whether the detection method could identify un-

known bots, whether it was protocol and structure in-

dependent, if it could deal with encrypted command

and control channels, the ability to detect these bot-

nets in real-time, and the accuracy of each method.

According to the authors, the most promising botnet

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

292

detection techniques are those based on a data min-

ing approach and another that utilizes a DNS based

method. Data mining detection techniques try to iden-

tify the C&C trafﬁc that is required for these attacks.

DNS based methods seek to identify DNS trafﬁc that

occurs during a botnet’s life cycle. We tried a pure

data mining approach to identify various botnets, but

the results showed that different botnets exhibit dif-

ferent patterns and implementing additional sensors

rather than just a network trafﬁc analyzer would stand

a better chance at detection.

While some detection techniques focus on one

speciﬁc type of botnet, others try to analyze different

kinds in order to ﬁnd similar characteristics. Algo-

rithms that are created as a result of studying botnets

of a speciﬁc type can sometimes be restrictive in the

sense that they can only be applied to those speciﬁc

botnets, as mentioned in the botnet survey paper (Bai-

ley et al., 2009). They described the changes botnets

have gone through while still having the end goal of

turning their targets into zombies, or bots.

Other researchers have studied cross-analysis bot-

net results. For example, Shin et al. studied one bot-

net that uses auto-self propagating techniques and two

that are non-auto-self-propagating (Shin et al., 2011).

Their experiments examined properties like the ge-

ographical distribution of infected networks and the

remote accessibility of networks to detect botnets of

both similar and different propagation type. Due to

the recognition of these attacks as a serious concern

and their complex attack vectors, many research ef-

forts result in elaborate algorithms or system com-

ponents that are designed to detect and possibly de-

ter botnet attacks. They usually do not work well on

other types of attacks. Examples of these types of sys-

tems include the works of Gu et al. (BotMiner, Bot-

Sniffer, BotHunter, and BotProbe) (Gu et al., 2009).

Many of these algorithms also require the use of deep

packet inspection (DPI), which looks at the payload

information of a packet and can be considered in-

trusive and raises privacy concerns. Our approach

demonstrates how a collaborative, situational aware

IDPS could detect different kinds of attacks includ-

ing, but not limited to, botnets.

Allowing an IDPS to understand the context or

situation in which an attack can occur can go a log

way in preventing different kinds of attacks from oc-

curring, not just the ones whose signature is in a

database. While situational awareness might be ap-

plied to more physical domains, the potential of its

implementation in the cyber realm is starting to be

realized. The authors of idsNETS (Mancuso et al.,

2012) realized this and are developing a system to

test how users with varying degrees of cyber secu-

rity knowledge understand this concept by seeing how

they defend a system/network against multiple at-

tacks, some more harmful than others. Their work fo-

cuses on studying studying situational awareness in-

stead of its implementation.

Squicciarini et al. have also realized the useful-

ness of a situational aware intrusion detection system

(Squicciarini et al., 2014). What we call an attack,

they refer to as a case or incident. Their system, Rea-

sONets, incorporates information from host and net-

work sensors, which results in information similar to

what is gathered in previous work done by us (Math-

ews et al., 2012), (Sharma et al., 2013). These authors

also use Snort, stress the importance of a reasoner and

knowledge base, and incorporate DNS blacklists as

examples of sources of additional information, simi-

lar to our previous work (More et al., 2012), (Math-

ews et al., 2012).

3.1 Data Mining Approach to Botnet

Detection

After our initial research lead us to believe that a data

mining approach would be best, we decided to try

studying different botnet pcap ﬁles to identify var-

ious patterns that exist. A pcap ﬁle contains net-

work packet data that is captured while the network

is running. The botnets studied were W32/SDbot

(McRee, 2006), Kelihos/Hlux botnet (Mila, 2013),

and Skynet/Tor (Mila, 2012).

In order to apply data mining techniques to the

botnet pcap ﬁles, we used two free and open-source

products. Wireshark is a popular network proto-

col analyzer that can capture trafﬁc on a network

and open previously obtained pcap ﬁles (Wireshark,

2015). RapidMiner is a data mining software that

provides a user-friendly GUI environment for ap-

plying data mining and machine learning techniques

and visualizing the output (RapidMiner, 2015). The

ﬁelds/attributes chosen to be exported were the source

IP address, destination IP address, protocol, packet

length, destination port, source port, and ExpertInfo.

The ExpertInfo ﬁeld that is produced by Wire-

shark is similar to other intrusion detection systems

alerts. There are ﬁve values that an individual instance

can have: NULL, Chat, Note, Warn, Error. NULLs

occur for normal trafﬁc while Chats occur with trafﬁc

that might be considered normal but there is some-

thing unusual, but not alarming, regarding the work-

ﬂow. Notes occur for packets that are suspicious but

not strongly so. The Warn value is seen for activity

perceived as out of the ordinary and should be taken

as a warning. An Error value is the worst rating indi-

cating a serious problem.

Detecting Botnets using a Collaborative Situational-aware IDPS

293

Figure 2: Block diagram of methodology.

Figure 2 represents the block diagram showing

how each botnet pcap ﬁle is preprocessed and ana-

lyzed. Looking at the confusion matrix for each ﬁle,

Chats seem to be the most difﬁcult to classify prop-

erly. The NULL class has the best results with very

few misclassiﬁed instances appearing since they were

hand-selected speciﬁcally so that only normal trafﬁc

would be included. The Note, Error, and Warn classes

were mixed; half the time the instances were classi-

ﬁed correctly for the most part, and the other half they

were not.

When looking at the resulting decision tree and

observing the paths from the root to the leaf nodes

along with the intermediate attributes, there is no dis-

cernible pattern for the attribute values. The Proto-

col and Source and Destination Port attributes were

in all but one of the decision trees. The Destination IP

Address attribute appeared only in one tree, and the

Source IP Address did not appear at all. The main

pattern observed was for the PacketLength attribute

value, which varied for the different branches of each

tree. However, a split was often seen on the value 57.

When looking at the ﬁles for each botnet and order-

ing by PacketLength, it was seen that in many cases

a value of 54 bytes would have TCP ZeroWindow

listed as part of the Info column. This occurs when

the sender is told that the destination cannot accept

more information for the moment. While this could

be used as part of a rule/policy to detect botnets, this

pattern alone would not catch them since it can also

be observed in nonbotnet trafﬁc. No obvious pattern

or trend was perceived regarding the depth or num-

ber of nodes in the tree and the accuracy. This fail-

ure to detect patterns at the syntax level in attributes

that would enable classiﬁcation provides support to

our overall approach of using semantically rich repre-

sentations and reasoning to detect attacks.

4 CURRENT SYSTEM SETUP

AND VALIDATION

4.1 Current Setup

We tested the prototype system described above

against a sophisticated botnet attack using the vari-

ous components we have created or utilized for the

IDPS. Actual binaries were desired to recreate the at-

tack since, along with the shortcomings listed in the

previous section, it is difﬁcult to ascertain the timing

of events in a pcap that someone else has created.

In other words, the particular times or more accu-

rate knowledge of the packets where important events

take place is not always easily determined. Also, it

is often the case that the exact system conﬁguration,

such as the operating system and what vulnerable ap-

plications were installed, is not mentioned. Instead,

we found the executables for the Skynet botnet, also

knows as Trojan.Tbot, from the contagio site (Mila,

2012).

The text processing module described in (Math-

ews et al., 2012) and the host parameter monitoring

system described in (Sharma et al., 2013) were uti-

lized for system validation. Even though the Skynet

botnet was discovered in December of 2012, the at-

tack was still infecting victim computers when the al-

leged creators were arrested one year later (Kumar,

2013). Virtual machines (VMs) were set up to run

the botnet in a sandboxed environment with the mod-

ules of the IDPS described in this paper in place. Ad-

ditionally, Symantec and Microsoft write-ups of the

W32/Vobfus attack were found and sent through the

text processing module. A summary of the results will

be provided below.

4.2 Text Processing Module Results

As described earlier, textual sources can provide dis-

cussions on new attacks where formal signatures are

not yet available from AV providers or vendors. Con-

sider the text below, which is a response taken from

an entry on the Reddit website to the question of how

to detect Skynet.

Look for unusual Internet Explorer and sv-

chost processes. Also if you don’t regularly

use Tor you’ll ﬁnd a “tor” folder in %App-

Data% as well as a custom directory with a

random name in %AppData% as well, con-

taining a copy of the malware. You can also

watch for anything listening locally on 42349

and 55080 (botherder, 2012).

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

294

Figure 3: Output from Reddit post sent through Security

NER.

Our text processing module can analyze this de-

scription and extract information that can aid in as-

serting the fact that host process modiﬁcation indi-

cates the presence of a botnet. Passing the response

text through our NER (named entity recognizer) re-

sults in the identiﬁcation of the relevant processes

and software as shown in Figure 3. In our ontology,

‘showsInfectionSigns’ and ‘opensPort’ are properties

of the class ‘Process’; ‘DistributedCode’ is a sub-

class of ‘MaliciousCodeExecution’, which is a sub-

class of the ‘Means’ class; and ‘DistributedCode’ has

the object property of ‘resultsIn’ with the class ‘Bot-

netAttack’, which is a subclass of ‘Consequence’. A

rule that accounts for this threat, like the one in Fig-

ure 4, could say that if a host-based sensor detects a

process ﬂagged as showing infections signs (as de-

tected by the process monitoring module), and there

are open ports 42349 and 55080 (as shown by some

Figure 4: This rule, serialized as N3, asserts RDF triples

describing a potential attack based on the presence of triples

representing the state of the system and recent events.

network monitoring tool), and that there is an abnor-

mal amount of data ﬂow observed in behavior such

as a large spike in network activity or connection at-

tempts to/from previously unseen IP addresses (as de-

tected by Wireshark), a botnet attack is likely occur-

ring.

Several parameters need to indicate abnormal ac-

tivity in order for the IDPS to throw suspicion on

this botnet. It is important that all of the indicators

are present to reduce the possibility of false positives.

One instance of a low level alert might not be of inter-

est to anyone, but if all the indicators are present, this

warrants at least additional investigation by a network

administrator.

In order to identify the malicious behavior of a

botnet, several tools and applications need to be in

place. These are used by the host and network pa-

rameter monitors mentioned earlier. Detecting Skynet

would involve the use of host monitors to detect pro-

cess behavior and registry modiﬁcations and network

monitors to detect suspicious port openings and ab-

normal trafﬁc behavior.

Figure 5 shows a screenshot of ProcessExplorer,

which has been incorporated into the host parameter

monitor, as it detects the disguised svchost.exe pro-

cess that is created after one of the Skynet ﬁles is

executed. During later executions of the botnet in-

side a new VM, the disguised process was sometimes

shown as IEXPLORER.exe. Symantec had posted

a writeup of Trojan.Tbot in their Security Response

section where the describe the technical details of

this trojan including modiﬁcations seen on an infected

system (Spasojevi, 2012). Their analysis of the botnet

listed the creation of a rogue svchost.exe process, but

interestingly did not mention anything about the In-

ternet Explorer process. False negatives would most

likely occur if their signature to detect Skynet needed

the discovery of the disguised process and didn’t in-

clude IEXPLORER.exe.

Figure 6 shows a screenshot of Regshot which

compares two snapshots of a host’s registry to detect

any modiﬁcations including keys that were deleted

Detecting Botnets using a Collaborative Situational-aware IDPS

295

Figure 5: Process Explorer showing disguised svchost.exe.

and added, values that have been deleted and added,

and values that have been modiﬁed. There were 382

modiﬁcations noted while the VM was allowed to run,

and this was without a Tor client or Bitcoin account

set up. While this might not be a big deal consider-

ing registry values can change with legitimate or nor-

mal activity, it is still something that could be of in-

terest when other suspicious host or network behavior

is observed. Netcat was used to listen on ports 42349

and 55080 and showed a connection attempt on port

42349.

Posts from Microsoft’s Malware Protection Cen-

ter and Symantec provided information on the

W32/Vobfus, aka W32/Changeup, malware including

the different attack vectors and operating systems af-

fected (Young et al., 2009; Diaz and Estavillol, 2010).

Victim computers are infected through removable me-

dia and network drives where an autorun.inf ﬁle, an

AutoRun conﬁguration ﬁle, is set to execute a copy

of the worm once the drive is accessed. The worm

will copy itself and the corresponding autorun.inf ﬁle

to any removable and network drives found on the

newly compromised machine. It will then attempt

to download additional malware from remote loca-

tions through a few speciﬁc ports to different exe-

cutables under the %UserProﬁles% folder with ran-

dom ﬁle names. Registry keys are modiﬁed so that

the malware runs each time the computer is restarted.

The worm may also attempt to modify registry keys

so that its location is hidden and Windows updates

Figure 6: RegShot showing indication of registry modiﬁca-

tion.

are disabled. The output from sending the Microsoft

technical information text through the NER is shown

in Figure 7.

4.3 Host and Network Modules Results

The IDPS outlined in this paper has the different host

and network sensors along with the modules to an-

alyze them in place to ﬂag an alert when suspicious

activity is discovered. This should help alleviate the

burden of network administrators who might moni-

tor these different tools individually. In Figure 8, the

window on the right shows the RDF assertions gener-

ated during the course of the attack. The window on

the left shows the highlighted assertion regarding the

disguise of the svchost.exe process.

VirusTotal provides an online service where ﬁles

and URLs will be sent through several antivirus and

antispamware engines and blacklists and provides a

report on any suspicious content (VirusTotal, 2015).

The results of the old VirusTotal scans uploaded onto

the contagio site show that many of the Skynet ﬁles

had a low detection rate when passed through several

IDSs/IPSs a few weeks after the attack was discovered

in December 2012 (Mila, 2012). This indicates that

relying on one sensor to detect all attacks is not ideal.

When running the bontnet ﬁles against the site as of

April 2015, some of the malware detection engines

still do not ﬂag the ﬁles as malicious.

Having forensic style rules that can detect various

complicated threats and are not limited to one partic-

ular threat would give an IDPS an advantage in dis-

covering attacks whose speciﬁc signatures have not

yet been created. Take for example the rule created

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

296

Figure 8: RDF assertions generated.

Figure 7: Output from Microsoft technical information on

W32/Vobfus sent through Security NER.

after extracting text from the Reddit post regarding

Skynet. Since the attack behavior for W32/Vobfus, as

described above, is similar to that observed in Skynet,

the same rule constructed earlier should be able to de-

tect this additional attack as well.

5 CONCLUSION

In this paper, we substantiated the need for a collabo-

rative, situational-aware IDPS to detect sophisticated

attacks. The IDPS outlined is capable of gathering

data from traditional as well as nontraditional sources,

extracting the relevant information, and storing that

information in a knowledge base as facts. When used

in conjunction with domain expert rules put in place,

malicious host and network activity will have a better

chance of being detected.

Initial experiments were conducted using several

pcaps, but a few signiﬁcant drawbacks made us switch

to ﬁnding actual binaries. The complex attack of

choice was the Skynet botnet, aka Trojan.Tbot. Old

VirusTotal scans of the botnet ﬁles reveal that upon

discovery of the attack in December of 2012, many

of the popular IDS/IPS engines failed at identifying

them as a threat. The text processing module is ca-

pable of extracting the necessary information to cre-

ate a useful rule to detect botnets, not just speciﬁc

to Skynet. Several applications, such as ProcessEx-

plorer and registry monitors, that have been incorpo-

rated into the IDPS described in this paper would de-

tect the host and network changes that are checked by

the rule created to identify the attack.

As part of our future work, we will study the num-

ber of false positives and false negatives generated by

our IDPS compared to other systems and modify our

system as needed. Any bottlenecks that occur while

gathering information from the different sensors will

need to be dealt with. Adding a conﬁdence metric or

assigning weights to the different rules in the knowl-

edge base is also a possible future contribution.

REFERENCES

Bailey, M., Cooke, E., Jahanian, F., Xu, Y., and Karir,

M. (2009). A survey of botnet technology and de-

fenses. In Conference For Homeland Security, 2009.

CATCH’09. Cybersecurity Applications & Technol-

ogy, pages 299–304. IEEE.

Bechhofer, S., Van Harmelen, F., Hendler, J., Horrocks,

I., McGuinness, D. L., Patel-Schneider, P. F., and

Detecting Botnets using a Collaborative Situational-aware IDPS

297

Stein, L. A. (2004). OWL Web Ontology Language

Overview. http://www.w3.org/TR/owl-features.

Berners-Lee, T. and Connolly, D. (2014). Notation3

(N3): A readable RDF syntax. http://www.w3.org/

TeamSubmission/n3/.

botherder (2012). Skynet, a Tor-

powered botnet straight from Reddit.

http://www.reddit.com/r/netsec/comments/14etfq/

skynet a torpowered botnet straight from reddit/.

Constantin, L. (2012). Tor network

used to command Skynet botnet.

http://www.pcworld.idg.com.au/article/444088/

tor network used command skynet botnet/.

Diaz, Jr, E. and Estavillol, P. (2010). Win32/Vobfus.

http://www.microsoft.com/security/portal/threat/

encyclopedia/Entry.aspx?Name=Win32%2fVobfus.

Feily, M., Shahrestani, A., and Ramadass, S. (2009). A sur-

vey of botnet and botnet detection. In Emerging Se-

curity Information, Systems and Technologies, 2009.

SECURWARE’09. Third International Conference on,

pages 268–273. IEEE.

Gu, G., Yegneswaran, V., Porras, P., Stoll, J., and Lee,

W. (2009). Active botnet probing to identify obscure

command and control channels. In Computer Secu-

rity Applications Conference, 2009. ACSAC’09. An-

nual, pages 241–253. IEEE.

Guarnieri, C. (2012). Skynet, a Tor-powered botnet

straight from Reddit. http://community.rapid7.com/

community/infosec/blog/2012/12/06/skynet-a-tor-

powered-botnet-straight-from-reddit.

Kumar, M. (2013). Alleged Skynet Botnet creator arrested

in Germany. http://thehackernews.com/2013/12/

alleged-skynet-botnet-creator-arrested.html/.

Mancuso, V. F., Minotra, D., Giacobe, N., McNeese, M.,

and Tyworth, M. (2012). idsnets: An experimen-

tal platform to study situation awareness for intru-

sion detection analysts. In Cognitive Methods in Sit-

uation Awareness and Decision Support (CogSIMA),

2012 IEEE International Multi-Disciplinary Confer-

ence on, pages 73–79. IEEE.

Manola, F., Miller, E., and McBride, B. (2014). Rdf 1.1

Primer. http://www.w3.org/TR/rdf11-primer/.

Mathews, M. L., Halvorsen, P., Joshi, A., and Finin, T.

(2012). A collaborative approach to situational aware-

ness for cybersecurity. In Collaborative Computing:

Networking, Applications and Worksharing (Collab-

orateCom), 2012 8th International Conference on,

pages 216–222. IEEE.

McRee, R. (2006). http://holisticinfosec.org/toolsmith/

ﬁles/nov2k6/toolsmith.pcap.

Mila (2012). Dec. 2012 Skynet Tor botnet / Trojan.Tbot

samples. http://contagiodump.blogspot.com/2012/

12/dec-2012-skynet-tor-botnet-trojantbot.html.

Mila (2013). Trojan Nap aka Kelihos/Hlux status update by

DeepEnd Research and samples. http://ontagiodump.

blogspot.com/2013/02/trojan-nap-aka-kelihoshlux-

status.html.

More, S., Matthews, M., Joshi, A., and Finin, T. (2012).

A knowledge-based approach to intrusion detection

modeling. In Security and Privacy Workshops (SPW),

2012 IEEE Symposium on, pages 75–81. IEEE.

Prince, B. (2015). Obama administration proposes giving

courts more power to issue botnet injunctions. http://

www.securityweek.com/obama-administration-

proposes-giving-courts-more-power-issue-botnet-

injunctions.

RapidMiner (2015). http://rapidminer.com/.

Sharma, P., Joshi, A., and Finin, T. (2013). Detecting

data exﬁltration by integrating information across lay-

ers. In Information Reuse and Integration (IRI), 2013

IEEE 14th International Conference on, pages 309–

316. IEEE.

Shin, S., Lin, R., and Gu, G. (2011). Cross-analysis of bot-

net victims: New insights and implications. In Re-

cent Advances in Intrusion Detection, pages 242–261.

Springer.

Spasojevi, B. (2012). Trojan. Tbot. http://

www.symantec.com/security response/writeup.jsp?

docid=2012-120716-2955-99.

Squicciarini, A. C., Petracca, G., Horne, W. G., and Nath,

A. (2014). Situational awareness through reasoning

on network incidents. In Proceedings of the 4th ACM

conference on Data and application security and pri-

vacy, pages 111–122. ACM.

Thuraisingham, B., Hamlen, K. W., Khan, L., and Masud,

M. M. (2008). Data mining for security applications.

In Embedded and Ubiquitous Computing, IEEE/IFIP

International Conference on, volume 2, pages 585–

589. IEEE.

Undercoffer, J., Joshi, A., and Pinkston, J. (2003). Mod-

eling computer attacks: An ontology for intrusion de-

tection. In Recent Advances in Intrusion Detection,

pages 113–135. Springer.

VirusTotal (2015). https://www.virustotal.com/en//.

Wireshark (2015). http://www.wireshark.org/.

Young, E., Honda, H., and Bell, H. (2009). W32.Changeup.

http://www.symantec.com/security response/

writeup.jsp?docid=2009-081806-2906-99.

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

298