Military Communications and Information Technology: A Trusted ...

Chapter 4: Information Assurance & Cyber Defence
405
To sidestep this issue, we want to employ statistical methods developed
in the field of sensor data fusion for analysing measurements from physical sensors.
These methods require that we can not only define features that we expect to
distinguish botnet traffic from other traffic, but also that we are able to describe
and formalise the difference between the two. In this section, we describe three
features that both provide evidence of botnet activity and can be described in regard
to how the presence of a botnet client will affect the measurement for a given
system. We expect that this list is not exhaustive, i.e. additional features exist which
have the desired properties and can be used to discriminate between benign and
infected systems. Identifying these will be part of our future work.
First, we introduce a feature based on measuring the delay between two
consecutive flows supposedly initiated by the same application. Following that, we
discuss the failed flow count as an indicator for peer-to-peer based botnets in section
VI.B and finally we describe how to interpret the volume of bytes transferred
in a flow for our purposes in section VI.C.
A. Inter-flow-initiation delay
A given type of client application usually interacts with another class of applications,
using an appropriate transport layer protocol. Typically, the latter application
would be called the server counterpart for the application but may be
identical in the case of peer-to-peer applications. Internet traffic is dominated by
standardised protocols many of which use a registered TCP or UDP port for their
server application. Thus, a given application usually interacts with servers listening
on the same port. When adding the assumption that a system usually runs only one
application for a given protocol, this becomes “two flow initiations with a given
destination port and originating from a given IP address are usually generated
by the same application running on the system identified by the address.” While
this conclusion may not hold in some cases, particularly when several hosts that
run a popular application share an IP address through NAT, the loose association
provided may already be enough for our purpose.
Based on the assumption described in the previous paragraph, we can measure
the delay between two successive attempts of an application to contact another
application. Again, we analyse the distribution function for the measured delays,
if an application tries to initiate a flow in regular intervals, the distribution function
will exhibit a local maximum at the configured interval value, i.e. the existence
of a local maximum can be treated as an indicator for an automated process
initiating flows. Note that we may not be able to measure the conspicuous intervals,
if the malware’s flow initiations are mixed with a legitimate user’s. However, once
the user ceases interaction with the application disguising the malware traffic for
a sufficiently long time span, the interval can be observed. We would also like to
point out that when only considering traditional netflows, this mechanism would