Military Communications and Information Technology: A Trusted ...

406 Military Communications and Information Technology...
fail once a system would initiate and maintain a single C 2 flow over a prolonged
time, even if that flow would carry periodic requests for updates or status reports.
Using subflows, as suggested in V.C, allows us to distinguish between idle times and
message exchanges, particularly to reveal the periodic nature of subflow initiation
in the described case.
B. Failed flow count
Botnets with peer-to-peer functionality such as Storm or Miner use a list of addresses
hard coded in the malware or distributed as a separate file to allow infected
hosts to connect to other peers. Since keeping such a list up to date is a hard problem,
a significant fraction of the addresses in the list will no longer be available at
the time the malware initiates operations. Research conducted at our institute [19]
revealed that on average only about 23% of the addresses advertised in the Miner
botnet’s peer lists would respond to connection requests, i.e. a client will usually
have to initiate flows to a significant number of addresses before finding one that
would respond to its request. We want to exploit this by taking failed connection
attempts into consideration for detecting botnets with peer-to-peer functionality.
Observing an explicit failure of a flow initiation attempt is only possible
if the contacted system signals a rejection through ICMP. Otherwise, e.g. if the packets
initiating the flow are filtered by a firewall, we have to infer the failure from
what we can observe. Since few Internet protocols use strictly unidirectional
communication, we interpret flows for which we did not observe any packet from
the responding to the initiating system as failed. This will however also be the case
when a system sends packets to a multicast address, since such an address does not
represent a single system that could generate a response. Multicast transmissions
are however often filtered by ISPs and thus we do not expect them to have any
significant effect regarding this feature. Besides that, treating multicast addresses
differently regarding this feature would be a valid option if significant changes
in usage patterns would render it useless otherwise.
C. Flow volume
For a typical protocol providing users with access to data stored at a central
location such as HTTP, the client to server direction of the flow will consist
of a small or series of small requests and one or several large responses. Following
the methodology introduced in sections V.B and V.C, each request and response
would correspond to a single subflow.
We do not expect that this will be fundamentally different for a botnet protocol,
however we want to exploit one feature that distincts regular and botnet client
behaviour. A botnet client will usually request a few pieces of data, either using
fixed requests or building them from a template. While live users’ requests may