**Detection and Analysis of Fast-Flux Service Networks**

Final Paper for CS294-28

Scott Campbell Steve Chan

**Abstract**

Fast Flux Distribution Networks (FFDN) represent an effective way for
well organized criminal organizations to present a highly available and
secure web presence. We present a methodology to detect and analyze such
networks and show that there is a significant degree of overlap between
compromised systems suggesting a high degree of organization and
centralized control.

**1.0 Introduction**

Maintaining a highly available and secure web presence is a problem
faced by all web professionals. For professional web *criminals*, the
problem is compounded by the fact that their work is considered
illegitimate by the powerful forces of government, businesses, IT
administrators and end users -- resulting in constant and determined
adversarial pressure. While sites containing legitimate content can rely
on well known techniques such as Round Robin DNS or Content Distribution
Networks (CDNs), such reliable techniques are too easy to trace and take
down. In response, the organized crime community - further known as
miscreants - developed Fast Flux DNS. The exact origins of this
technique are unclear, but they are related to the methods used by
legitimate web sites. There are a number of references dating back to
November, 2006 \[PBP\] but little before that can be found.

FastFlux DNS rotates large numbers of compromised hosts through domains
and hostnames used for spam, phishing, malicious content distribution
and related activities - the large numbers of hosts associated with any
given hostname, as well as the rotation of new addresses into these
hostnames, makes it much harder to protect against these activities
using traditional IP address based defenses. Research into fast flux
service networks is still nascent, however a small number of recent
papers have examined the problem and one paper has offered a solution
for detecting FFDNs. We review the work, and implement the proposed
detection algorithm, using it as a starting point for further
investigation. In reviewing this work, we feel that an important
distinction between dispersion and flux needs to be made, and we claim
that the existing work implicitly equates dispersion with flux, and can
be improved by introducing flux into the algorithm.

Note that we are not looking at the mechanism of FFDN member creation,
nor examining the larger bot C&C networks or communication protocols.
Our scope is the identification and measurement some basic
characteristics of live FFDN traffic and using this information to
improve detection of compromised systems and malicious domains.

**2.0 Background**

According to the Honeynet Project description \[HNP\], there are two
basic forms of Fast Flux DNS activity. We will cover just a general
discussion of the techniques since \[HNP\] provides an excellent
technical description, and is considered a standard technical reference
by most other papers. The first type is called Single Flux. Single flux
networks take advantage of the same techniques that round robin and CDN
networks use by delivering multiple IP addresses for each resource
query, but the set of addresses provided come from a huge pool of
compromised systems. When you resolve a name such as test.example.com,
the fast flux domain returns a number of A records from a larger set of
compromised hosts called flux-agents. The responses tend to have a short
TTL, reducing the effects of caching and provides resistance to any
single member of the pool being taken off line. These systems act as
relays for HTTP or SMTP traffic, allowing a great deal of screening to
protect the expensive and hard to replace core infrastructure required
for large scale computer crime.

The second type of Flux Network is called Double flux. The general
structure is similar in form to the Single Flux form - in fact the end
user will not notice any real difference in behavior or results. The
innovation for this technique is to replace the static authoritative
name servers with a dynamic set of nameservers operating on compromised
hosts. This pool of name servers adds another layer of misdirection and
hence protection. When a user requests name resolution for a host such
as flux.example.com, the top level domain .com is queried for the
authoritative name server for example.com. The name server returned for
the example.com domain is actually part of the fast-flux network itself
with the IP address associated with that name changing frequently. In
other words, the record always points to ns.example.com, but the IP
address for ns.example.com changes frequently. Lookups from the name
server are the same as the single flux version.

In doing data analysis, we came upon a set of extremely short lived
A-record lookups whose initial characteristics triggered the FFDN test,
but never returned in the passive bro analyzer and whose domain never
successfully resolved for the active querying mechanism. We have chosen
to create a distinction between an A-record whose lookups exhibit flux
in the classic sense of the word, and those whose characteristics are
merely sufficient to trigger the detector. In the case of the transient
records we will describe them as dispersive in that the resolving data
is dispersed across a large number of ASNs and IP addresses. We use the
term flux in a sense of transport phenomena - the amount of flow through
a unit area per unit time\[FLUX\]. In this case we are thinking more
about the amount of change in IP addresses over time. The recognition of
the *change over time* element is a critical distinction that we think
has been left out of a number of analyses.

**3.0 Related Work**

In researching the general topic of Fast Flux networks, we found that
there was a significant volume of literature describing how they work
and who was using them, but the number of analysis related papers was
extremely small. We break down the related literature into studies
relating to measurements and analysis of the networks themselves,
descriptive works relating to Fast Flux, and DNS related analysis.

The closest match that we found to the work that we are doing was done
by Holz et al \[HOLZ\]. In this paper a first order approximation is
presented to identify Fast Flux networks as well as the notion of
fluxiness which is used to differentiate CDNs and FFDNs. In addition the
idea to extract a large volume of high value data by directly querying
name servers for known FFDN A-records, and comparing results for web
traffic from web servers on those addresses is looked at as well. This
paper provided us with a great deal of theory and method. Primary
differences include significant modifications to the presented
algorithm, taking into account the inter relation between ASN and IP,
and the use of live traffic to generate our data set rather than lists
of known good and bad records.

The description of Fast Flux networking as described by the Honey Net
Project in \[HNP\] is probably the single most cited technical
description of the techniques workings. While the descriptive nature of
the work is still outstanding, it is mostly qualitative rather than
quantitative. This is by no mean a criticism, but is a differentiation
between it and our work.

In \[SSAC\] a nice overview of Fast Flux technique is provided along
with descriptions of miscreant motivation and the relation of Fast Flux
to Phishing and \'Domain Tasting\' (domains that are registered, but are
canceled during the Add Grace Period). The paper concludes that there is
no connection. A significant part of the paper looks at possible
mitigation techniques as well as how domain name registration mechanics
might be used against Fast Flux network operators.

In \[BZ\], a passive DNS monitoring system is described and data
analysis results were presented. Passive DNS monitoring system on live
traffic is similar to our approach, however the system described was not
real time, and captured data for later, offline analysis. In the results
section, several candidate FFDN domains were pointed out, and a clear
FFDN domain was discussed, highlighting the fact that the hosts in the
domain were dispersed across the internet, typically residing in home
DSL networks. The paper however was focused on passive DNS monitoring
and analysis, and not on FFDN.

**4.0 Fast Flux Detection Algorithm**

During the initial tool development, we used the detection algorithm
described by Holz et al. \[HOLZ\].

$$\text{flux}_{A}(n_{A},n_{\text{ASN}}) = 1\text{.}\text{32} \cdot n_{A} + \text{18}\text{.}\text{54} \cdot n_{\text{ASN}}$$

Equation 1

The idea behind the use of this design seems correct in that an
abnormally large number of ASNs referenced in an A-record lookup should
arouse suspicion. When the return value of the function exceeds some
threshold value, the A-record is considered Fast Flux. See \[HOLZ\] for
a complete description of the rational behind the numeric constants.

On using the formula on live data we discovered a number of
shortcomings. While the plainer solution (the optimal Hyperplane) is
sufficient for the data sets that were looked at in the coefficient
calculations, it can not express any sort of relationship between the
n~A~ and n~ASN~ terms. By adding this term we see:

$$\text{flux}_{A}(n_{A},n_{\text{ASN}}) = \left( \frac{n_{\text{ASN}}}{n_{A}} \right)\left( 1\text{.}\text{32} \cdot n_{A} + \text{18}\text{.}\text{54} \cdot n_{\text{ASN}} \right)$$

Equation 2

The rationale for adding the additional term is that CDN networks tend
to include a higher degree of redundancy in their infrastructure since
they are building it out on purpose. Such redundancy would typically
take the form of multiple IP addresses per ASN. FFDN do not have an
opportunity to plan out their infrastructure, so the IP addresses tend
to be more evenly distributed across ASN space.

Comparing the results between eq1 and eq2 for a known CDN (figure 1)

![](media/image1.png){width="2.75in" height="2.0625in"}

Figure 1

we see that the modifications to eq1 seem to provide some significant
degree of relief to differentiating the CDN vs. FFDN problem.
Nonetheless there are still significant false positives because of the
pervasive use of CDNs, the sheer number of discrete ASNs will override
the quotient given enough time.

Based on the method description in Holz, the derivation of eq1 is based
on a comparison of known fast flux and legitimate domains. The
legitimate domains are taken from the Open Directory Project\[OPEN\] and
the Alexa Top 500 list \[ALEXA\]. We think that eq1 seems to have
difficulty with live traffic because CDNs do not typically live in
either a list of known good search links, or in the main destination of
highly popular URLs. Since they are infrastructure, the CDN links are
not directly exercised by these URLs, but are embedded in the content of
these top sites. Because CDNs such as Akamai exhibit the same static
behavior as FFDNs, it is necessary to include other variables in the
analysis.

**4.1 Coefficient Selection**

A reasonable question can be made at this point. Having modified the
behavior of the algorithm, why would we keep the same coefficients?

As a first approximation to an individual measurement, we think that the
coefficients represent a reasonable beginning. The underlying insight
that the number of ASNs are a key indicator of how widely dispersed a
domain is across the internet at large still holds. An A-record's ASN
count should therefore have significantly more weight than the number of
returned IP addresses, which eq1 provides. It is only when you begin
taking multiple measurements that you discover eq1 does not address the
more complex dynamics and so ought to be replaced with eq2. In future
work we plan to re-evaluate the constants.

**4.2 Adding Additional Terms**

We strongly believe that there are additional terms that could be added
to eq2 which would provide more resolution regarding CDN vs. FFDN
dynamics. There are two in particular which would be beneficial.

-   [Time to threshold]{.underline}: The time it takes between the
    initial lookup and a triggering of the fast flux algorithm is
    different between many large CDN providers and FFDNs. For all of the
    identified FFDNs, the initial contact dt was zero. For the larger
    CDNs this number ranged from tens to tens of thousands of seconds.
    This distinction was not true for some of the smaller CDNs and some
    purposefully distributed services such as freenode.net.\[FREE\]

-   [Tracking a domain's NS Behavior]{.underline}: Taken over time, the
    distribution of IP addresses in the authoritative NS list for a
    domain is both dynamic and variable for many FFDNs. This is
    particularly true for mainstream CDNs, but seems to be the case for
    some less formal services such as freenode as well.

Taking into account the distribution of NS record information as well as
the time till threshold, we propose a new version of the detection
algorithm. Since we are interested in both single and double flux
detection, we decouple the A-record based part from the NS-record part.
Decouple means that the general form will look like:

$$\text{flux}_{\text{TOTAL}} = \text{flux}_{A} + \text{flux}_{\text{NS}}$$

Equation 3

With the detailed version looking like:

$\text{flux}_{\text{TOT}} = \left\lbrack \frac{n_{\text{ASN}}}{n_{A}} \right\rbrack\left\lbrack \left( \sum_{i \in \text{AREC}}^{}\frac{1}{{\Delta t}_{i}}\left( \text{An}_{\text{ASNi}} + \text{Bn}_{\text{Ai}} \right) \right) + \text{Cn}_{\text{ASN}} + \text{Dn}_{A} \right\rbrack$**Equation
4**

The important things to note here is the time dependence for A-record
flux updates so that the initial data has more weight than later ones.
The coefficients C and D are for the NS record data. Calculations for
single flux networks will only be strongly effected by the time based
terms. Double flux networks will be effected by all terms.

We have not implemented eq4 yet, but intend to use some variation of it
in future work.

**5.0 Method**

The general form of the experiment took place in two parts. The first
part consists of using the Bro intrusion detection system to identify
FFDN candidates consisting of domains and hosts using two different
variations of the FFDN detection equation as described in Holz. The
second involves an active querying mechanism that takes a list of hosts
and domains and performs queries on them periodically.

**5.1 Bro Algorithm Implementation I**

For this version, a literal interpretation of the eq1 was initially
used, focusing exclusively on A-record lookups. After a short analysis
of the results, eq2 was implemented to help combat false positives.
Since the data volume is quite high, a number of things are implemented
in order to manage state over long run times. The first and most natural
is removing any record in the main state table which still has only 1
ASN after a timeout period. In this case the timeout was set to 60
minutes.

To help limit the set of candidate records, a maximum TTL is used to
exclude records unlikely to be interesting. DNS lookup results must have
a short TTL in order to allow the rapid rotation of compromised hosts
into the FFDN pool. Because of this operational requirement for FFDNs, a
maximum TTL was set to 10 minutes. This is consistent with the
methodology proposed by Holz in that they also limited records to TTLs
smaller than 1800 seconds. We selected a higher value, possibly at the
cost of some false positives by looking at the TTL distribution of
normal records.

In addition a white list was created in order to remove the most common
legitimate domains that trigger the threshold value for eq2. For the
purposes of data gathering for this paper, no such white list was used.

A number of tests were also proposed but not used in the data gathering.
The most interesting of these is the \"reverse lookup\" test that takes
the set of IP addresses returned in an A-record. If any of the reverse
lookups for the IP addresses does not match the domain in the original
A-record, a warning is produced flagging the significant possibility of
a false positive.

Data is recorded in two forms: the alarm data contains the following
information: time, domain, number of ASN at threshold, number of IP at
threshold and the time between initial contact and matching threshold.
An example record looks like:

> May 11 10:39:56 FastFluxA threshold exceeded for load53.com ASN:6
> Arec: 6 dt: 0.0

For the transactional records, we have the following data: time, domain,
current weight based on eq2, number ASN, number IP, TTL for that
returned record, IP address provided. An example record looks like:

> May 5 16:40:31 v1.panthercdn.com 7.5 ASN: 1 A: 3 TTL: 20.0 secs
> 66.114.48.46

We recognise that this filtering might be used as a way to avoid
detection and generate false negatives. Given that behavioral
characteristics (like short TTL values) force operators of FFDNs to
behave in certain ways, we feel that the likelihood of this is quite
small.

**5.2 Bro Algorithm Implementation II**

The second implementation looks at 2 different forms of aggregating DNS
records to see how examining groups of DNS records compare to examining
individual DNS records, as well examining the \"fluxiness\" of different
sets of the DNS records associated with the domain. The first set of
records examined are the records associated with the actual DNS servers,
the NS records and the A records associated with them. All the addresses
and the ASNs associated with them are pooled and changes in the content
of this pool are tracked. These records are typically modified only in
\"double flux\" domains, and the implementation uses the minimum TTL
between the NS and A records to repeatedly schedule queries against the
domain looking for changes. The second group of records we look at is
the entire set of A records for a domain - for these records we don\'t
store any information about individual addresses, but instead pool the
set of ASNs for all the addresses and track changes in this pool. This
second pool is tracked passively - the module does not initiate any DNS
queries against the domain.

We use a simple scalar value to track changes in these two pools - for
the DNS NS/A record pool, we simply apply the Holz eq1 scoring formula
to the pool as a whole. For the ASNs in a domain, we use a simple count
of the ASNs seen. The scoring used for the DNS NS/A pool is arbitrary,
as there is no clear \"correct\" method to score this, however eq1 seems
no more or less appropriate and we are mostly interested in the rate of
change. Using eq1 gives us a basis of comparison against the original
Holz algorithm.

The module generates a notice when the score for a domain exceeds a
threshold - for the DNS NS/A pool, we use the value given by Holz, of
142.38. For the ASN pool, we use a score of 5 ASN\'s as the threshold
for logging a domain as interesting. Note that these two threshold
scores are inconsistent with each other, 5 ASNs does not necessarily
correspond to the typical number of ASNs seen to arrive at a 142.38
score with eq1. The threshold of 5 ASNs was chosen based on some of our
own initial observations that many fast flux domains seem to have a
minimum of 5 DNS A records and 5 ASNs.

To track the changes in the scoring of the different pools, we store the
history of the scores for each domain. Because multiple records may be
returned in a single DNS response packet, we store score updates at a 1
second resolution, instead of per record seen. After a score has been
updated, we queue a write of the domain\'s current status and history to
the log with a delay of 2 seconds. This 2 second delay is meant to allow
for processing of all records in a DNS response to have been completed
before writing anything to the logs. Here is a sample log entry with
information about the NS address pool and the overall ASN list for a
domain:

> 1210650497.610464 ffdns_state ops-oms.org ( 208.250.65.126
> 165.158.1.2) ( AS701 AS7911) nsttl:36000 attl:86400 lookups:4 score:
> 39.72 firstseen:1210635300 lastupdate:1210635300 lastseen:1210635300
>
> 1210650497.610464 ffdns_flux_history ops-oms.org 1210635300/39.72
>
> 1210650497.610464 ffdns_domainasn ops-oms.org ( \_AS6505\_ \_AS6471\_
> AS701 \_AS1251\_ AS7911) attl:86400 firstseen:1210635300
> lastupdate:1210650495 lastseen:1210650495
>
> 1210650497.610464 ASN_count_history ops-oms.org 1210635300/3
> 1210643154/4 1210650495/5

In order to manage state, we periodically delete the state associated
with a domain. This pruning occurs when the score for a domain has not
changed in the last 4.33 hours. We arrived at this timeout interval by
examining the update times across all DNS records seen in a 13 hour
sample of traffic, and finding that just over 95% of all domains that
have score changes (the vast majority of domains are not updated at all)
are updated within 4.33 hours of the first sighting of DNS records for
the domain. In the data seen, this same period of 4.33 hours covers at
least 90% of the subsequent update intervals. The pruning of the record
is by either one of 2 events - when DNS query initiated by the module
completes or times out, or when a record for a domain is seen. If the
domain\'s score has been unchanged for the past 4.33 hours, and the
score has not crossed the threshold for being interesting, the record is
deleted from memory and the domain is placed into a set of domains to be
ignored for the next 12 hours. The premise of this interval is to avoid
tracking any \"one off\" domains.

**5.3 Active Querying Mechanism**

When an A-record is identified as a FFDN, the value is fed into an
active tool that runs a lookup on the A-record based on the current
information in an open OpenDNS \[ODNS\] resolver. OpenDNS was used
because it is reasonably anonymous and a well trusted source of
recursive lookup data. The current version runs every 5 minutes. Data is
recorded every time a new IP address is returned for the A-record
lookup. Timestamp data is embedded into the filename to provide a simple
way to track address updates.

**6.0 Data Analysis**

In what follows, we present a number of observations regarding data
gathered by tools described in the previous sections.

Data sources include the following:

\(1\) A large National Laboratory with approximately 10 thousand systems
averaging 8-12 million discrete DNS transactions per day. 5 weeks data.

\(2\) A mid size High Performance Computing facility, composed of
approximately 8 thousand systems, averaging 6-800,000 DNS transactions
per day. 4 weeks data.

\(3\) Large University with N thousand systems and people. The feed saw
around 75% of the total DNS transactions over a 36 hour period. For
privacy reasons we did not see any other data besides the policy output
(which did not provide the total number of transactions).

**6.1 NS record Overlap and Flux**

We observed several instances of domains being flagged by eq2 as FFDN
candidates at the same time as the domains authoritative NS records.
This is exactly what we would expect for an A-record being served from a
double flux network.

In order to look at this in some detail we will take two sample domains
which happen to trigger on this form. There is nothing particularly
unusual about these two domains as they were picked at random from a
pool of approximately a dozen. As expected, the most unusual
characteristic is the large variation in the domains name server
locations and identifications. Even for any of the CDNs we observed, the
NS records remained static over large time spans and are clearly located
within network blocks under the administrative control of the parent
domain. The second is the significant overlap seen in the addresses
assigned to the various NS records and the base domains.

As already mentioned, there is nothing exceptional for this pair of
domains except that they had a regular form of \'example.com\' for the
initial A-record lookup, and \'ns1.example.com\' (etc) for the
authoritative name servers. In the case of this pair of domains, the
initial identification was derived from the Bro implementation 1 and the
larger mass of data was extracted from the active query technique
described in 5.2. Here the IP variation is not only huge, but the
majority of the results are apparently non-production systems. Looking
up the registered name servers for the domain indicate that the
ns{1,2,3} systems are considered authoritative for the main domain in
question. Results for each of the domains are as follows:

**Shared IPs** Between Domain Records

  --------------- ------------- -------------- ------------- ---------------
  log67.com                                                  979

  ns1                                          148           30 / 20%

  ns2                           1581           22 /15%       266 / 27%

  ns3             192           115/60%        59 /40%       40 / 21%

                  ns3           ns2            ns1           log67.com
  --------------- ------------- -------------- ------------- ---------------

Table 1

  --------------- ----------- ------------- ------------- ---------------
  logid92.net                                             937

  ns1                                       930           533/20%

  ns2                         167           6 / 4%        18/27%

  ns3             1659        44/26%        120/13%       27221%

                  ns3         ns2           ns1           logid92.net
  --------------- ----------- ------------- ------------- ---------------

Table 2

Sparse testing of Akamai as a sample CDN shows that the diversity of the
NS records is significant across both in terms of ASN and geography, but
the addresses involved reside in administrative domains of service and
content providers, and appear to be static. This is particularly true as
compared to the above domains. We note that this is one possible test
that can be done in order to infer the difference between most
legitimate CDNs and FFDNs.

A simple way to look at how disperse the distribution of records are is
to look at the number of unique ASNs that a domain and it\'s
authoritative NS records live in. For the same pair of domains we see:

ASN Count for Returned IP Set

  ------------------- --------------- -------------------- ---------------
  A-Record            #ASN            A-Record             #ASN

  log67.com           149             logid92.net          150

  ns1.log67.com       118             ns1.logid92.net      57

  ns2.log67.com       73              ns2.logid92.net      140

  ns3.log67.com       148             ns3.logid92.net      61
  ------------------- --------------- -------------------- ---------------

Table 3

Looking at other domains, we can get an idea of how much dispersion
there is, as well as bring out the distinction between dispersion and
flux. Two domains that are highly dispersed are akamai.net, a CDN and
the dyndns.org domain, which serves as an outsourced DNS service for
systems that may be mobile. The dyndns.org domain is interesting because
it consists of an ad hoc collection of dispersed hosts that are
customers of the service, somewhat similar to the ad hoc collection of
dispersed hosts that compromised members of FFDNs.

The list of ASNs seen in appendix 1 for the dydns.org domain show the AS
value, as well as flux. The third column is the time in seconds between
when that ASN was seen and when the domain was first observed by the
detector. As you can see, the dydns.org spans 34 ASNs, the last one,
AS35776, was detected over 40000 seconds after the domain was first
seen. Examining the times until a new ASN is observed, we see the
median, average and standard deviation are 25475, 21249.18 and 13006.35
respectively.

In contrast, the akamai.net domain has 51 identified ASNs, with a median
time until ASN observation of 905 seconds. The final ASN is also
observed roughly 40000 seconds after the first ASN. The median, average
and standard deviations for the observation times are 829, 3938.373 and
8000.39.

The following table compares the two summary statistics for the two
domains. We see that for every statistic, dydns.org has a higher value
than akamai.net, indicating that dydns.org has a greater rate of change
than akamai.net. This is an indication of the greater flux in the
dyndns.org domain versus akamai.net.

  ----------------------- ----------------------- -----------------------
  **Measurement**         **Dyndns.org**          **akamai.net**

  **Median**              25475                   829

  **Average**             21249.18                3938.373

  **Std. Dev.**           13006.35                8000.39
  ----------------------- ----------------------- -----------------------

Table 4

As a graphical representation of this flux, the following graph of the
domain to ASN data has edges that are color coded to the time until
observation. The transition from violet to yellow indicates increasing
time until observation of the ASN. It is easy to see that akamai.net
reveals most of its ASNs early on, while dydns.org has many more ASNs
appearing later. Both domains are dispersed, in fact, akamai.net is more
dispersed than dyndns.org, however akamai.net is more static.

![](media/image2.png){width="3.001388888888889in"
height="2.3409722222222222in"}

Figure 2

Two conclusions can be made from this section of analysis. The first is
that there is a significant distinction between the dynamic behavior of
FFDN NS record and that of a typical CDN. The second is the distinction
between the degree of a networks dispersion and the degree of flux.

**6.2 Flux Rate Distribution and Clustering**

Given that a flux rate is easily understood and measured, it is natural
to ask the questions (1) Are these rates constant over time? and (2) Do
the values group between various A-records? We propose that the rates
seem to become asymptotically constant over time periods of several
days, and that the clustering provides some insight into possible shared
infrastructure in Fast Flux candidates

The rate of flux is simply the value of newly added IP addresses plotted
over time. Our inspection of bro data records indicate that some
candidates seem to have more stable update characteristics than others.
In order to provide a testable data set, we use data provided by the
active querying mechanism which takes lookup results every 10 minutes.

Results from plotting a series of representative graphs can be seen in
figure 3. Note that there were many different records which grouped
together quite closely, so the various records plotted here represent
the variation in flux values and are not proportional to the actual
distribution of rates.

The flux rate distribution between the different A record lookups seems
to be loosely clustered on groupings of A records. Looking at fig 2 we
see that there are a series of tracks which seem to be clustered based
on the rate of change of IP address additions - d(IP)/dt.

![](media/image3.png){width="2.75in" height="2.0625in"}

Figure 3

To test the notion of constant rate of change, we look at a plot of
d(IP)/dt described above. On initial glance the representation seems to
be dominated by noise, but looking at the average behavior it is
consistent across the sampling time. There is no guarantee that the
values will continue to hold such consistent behavior, but for the
duration for the sample data this seems to be a legitimate
generalization.

For clustering, we use the following method. First take the time between
last and first records available in the data set, creating a series of
time boxes which will represent the unit of temporal clustering. Using
these boxes, we take vertical slices of the time vs. IP count graph and
record the A-record name and IP count value for each possible entry in
the slice. For any slice the distance between any pair of A-records is
the difference in the IP count for each of the records in that slice.
This process is repeated over all possible tie box values where both of
the A-records have data points and the result of the distance is
averaged. To provide for a complete analysis, we repeat this process for
each of the possible combinations of records. If the average distance
between the two records is lower than a threshold, then the two records
are considered part of a cluster.

After running the clustering script against the data, we saw 5 discrete
groupings fall out which align themselves with the groupings described
in 6.3.

**6.3 Common Addresses Found in Different A-Records**

In inspecting the data, we noticed that a number of IP addresses seemed
to repeat themselves across multiple A-record response sets. The results
of this may point to another possible way to infer FFDN infrastructure
shared between multiple domains. The graph visualizations in figure 4
shows a large dataset of FF domains and their IP addresses. The blue
nodes are domains and the red nodes are individual IP addresses. Notice
that many of the FF domains share the same pool of addresses, forming a
nucleus of domains with their orbiting IP addresses.

![](media/image4.jpeg){width="2.7465277777777777in"
height="2.2194444444444446in"}

Figure 4 (see appendix II for a larger image)

Figure 5 is a close-up of the cluster in the upper right corner, with a
nucleus of 2 domain names. Domain names are labeled (but not IP
addresses). Note that there is an edge which leads off the bottom of the
image to another address which is shared across 3 clusters of domains,
possibly indicating a single host that has been compromised by multiple
groups.

![](media/image5.png){width="2.748611111111111in"
height="2.2555555555555555in"}

Figure 5

This last image, figure 6, shows a dense clustering of many domains, all
sharing the same large pool of addresses. This dense clustering of
domains that share the same cloud of IP addresses shows promise as a
method of identifying fast flux domains.

![](media/image6.png){width="2.74375in" height="2.4409722222222223in"}

Figure 6

It is important to note the distinction between what we are seeing here
and the more common use of virtual domains on a normal web server. In
that case you would see several A-record lookups pointing to the same IP
address (or small set of IP addresses). What we are observing here are
common mappings between dozens of A-records and hundreds of IP
addresses. Figure 7 shows a typical virtual domain setup with multiple
domains sharing the same IP address, 67.215.66.132, which is
simultaneously a single address within the cloud of IP addresses that
edit53.com domain shares with several other domains.

![](media/image7.png){width="2.7416666666666667in"
height="1.895138888888889in"}

Figure 7

Looking at the distribution of A-record number vs IP address, we see a
significant majority ( 15,811 or 91% ) only map between a single IP and
a single A-record. For more complex arrangements, figure 8 shows the
following distribution:

![](media/image8.png){width="2.75in" height="2.0625in"}

Figure 8

This shows that for some of the larger A-record counts a full 2% of the
total addresses looked at map to 28 different A-record lookups.

In the Honey Net paper, they described the existence of only two primary
upstream "mothership" hosts which deployed and serviced thousands of
flux domains. The current high level of clustering seems to suggest that
that observation still holds some degree of truth.

**7.0 Future Work**

There are a number of natural places for improvement in this analysis.
We have identified a number of additions in the detection algorithm and
intend to move forward on them.  Increasing the breadth of data sources
also seems to be a natural place to examine as we can begin doing\
consistency checking between different sites to see if there is a
significant difference in both Fast Flux content as well as the scope
of\
IP addresses associated with each domain.  It would also be interesting
to see of either the set of IP addresses or the content delivered by
the\
service proxying is affected by geographic location or network
ownership.  This would indicate a significant advance in that the Fast\
Flux networks would also take on Unicast characteristics.

**8.0 Conclusion**

In this work we have looked at improved methods of Fast Flux network
detection and analysis.  We also created a distinction between networks
that are Dispersed vs. those that are actively exhibiting flux like
behavior.  The most significant things we found were the identification
of shared resources between various domains.  This was achieved by
looking at clusters of flux rate as well as the mappings between IP
addresses and the domains and noting that there was significant overlap
in the resulting sets.

**9.0 Acknowledgements**

We wish to thank Robin Sommer for his generous helping our data
gathering.

**10.0 References**

Karasaridis, Anestis, Meier-Hellstern, Kathleen, Hoeflin, David,
"Detection of DNS Anomalies using Flow Data Analysis" Global
Telecommunications Conference, 2006. GLOBECOM 2006, Nov. 2006, Pages1 -
6

\[SCHO\] Antoine Schonewille, Dirk-Jan van Helmond, "The Domain Name
Service as an IDS", Research Project for the Master System- and Network
Engineering at the University of Amsterdam February 5, 2006

http://staff.science.uva.nl/\~delaat/snb-2005-2006/p12/report.pdf

Gadi Evron, "Looking behind the smoke screen of the Internet: DNS
recursive attacks, spamvertised domains, phishing, botnet C&C's,
International Infrastructure and you", SecuriTeam Blog, Feb 17 2006,
http://blogs.securiteam.com/index.php/archives/298

William Salusky, "Phishing by proxy", SANS Internet Storm Center diary,
Nov 28 2006, http://isc.sans.org/diary.html?storyid=1895

\[HNP\] The Honeynet Project, "Know Your Enemy: Fast-Flux Service

Networks", July 2007. http://www.honeynet.org/papers/ff/.

Vern Paxson, "Bro: A System for Detecting Network Intruders in
Real-Time", Computer Networks, 31(23-24), pp. 2435-2463, 14 Dec. 1999.

Anestis Karasaridis, Brian Rexroad, and David Hoeflin, \\u201cWide-Scale
Botnet Detection and Characterization\\u201d , HotBots April 2007,
Cambridge, MA

\[HOLZ\] Thorsten Holz, Christian Gorecki, Konrad Rieck, Felix C.
Freiling, "Measuring and Detecting Fast-Flux Service Networks", 15th
Annual Network and Distributed System Security Symposium, February 2008

\[SSAC\] The Security and Stability Advisory Committee (SSAC) of ICANN,
\"SAC025, SSAC Advisory on Fast Flux Hosting and DNS\"

January, 20008, http://www.icann.org/committees/security/sac025.pdf

\[DNS\] OpenDNS open recursive DNS resolver http://www.opendns.com

\[FREE\] Peer Directed Projects Center - Freenode
http://www.freenode.org

\[STEG\] \"Detection of peer-to-peer botnets\", Matthew Steggink, Igor
Idziejczak, Masters Thesis, University of Amsterdam, 2008

\[BZ\] Bojan Zdrnja, "Security Monitoring of DNS traffic", CompSci780
project, University of Auckland, May 2006,
http://www.caida.org/\~nevil/Bojan_Zdrnja_CompSci780_Project.pdf

\[OPEN\] DMOZ Open Directory Project, http://www.dmoz.org/

\[ALEXA\] ALEXA Global Top 500 Web Sites,
http://www.alexa.com/site/ds/top_sites?ts_mode=global&lang=none

\[ODNS\] OpenDNS DNS server, <http://www.opendns.com/>

\[FLUX\] (From Wikipedia reference for flux) Bird, R. Byron; Stewart,
Warren E., and Lightfoot, Edwin N. (1960). Transport Phenomena. Wiley.
[ISBN
0-471-07392-X](http://en.wikipedia.org/wiki/Special:BookSources/047107392X). 

Appendix I: Data set for ASN Flux from 6.1

  ------------------------------ -------------------- -------------------
  **Domain**                     **AS NUM**           **Time(s)**

  dyndns.org                     AS3320               0

  dyndns.org                     AS20773              515

  dyndns.org                     AS28753              1294

  dyndns.org                     AS33517              1337

  dyndns.org                     AS11426              1788

  dyndns.org                     AS33662              2587

  dyndns.org                     AS6128               7047

  dyndns.org                     AS4802               8432

  dyndns.org                     AS13045              10190

  dyndns.org                     AS8767               10885

  dyndns.org                     AS6805               12004

  dyndns.org                     AS1257               12394

  dyndns.org                     AS15594              13345

  dyndns.org                     AS6197               19997

  dyndns.org                     AS812                21337

  dyndns.org                     AS4230               25079

  dyndns.org                     AS33651              25095

  dyndns.org                     AS7303               25855

  dyndns.org                     AS8820               27399

  dyndns.org                     AS7132               27886

  dyndns.org                     AS6739               28379

  dyndns.org                     AS7015               28708

  dyndns.org                     AS20001              30022

  dyndns.org                     AS33668              30550

  dyndns.org                     AS19262              31812

  dyndns.org                     AS16338              32611

  dyndns.org                     AS3209               34124

  dyndns.org                     AS15557              34455

  dyndns.org                     AS12513              34471

  dyndns.org                     AS1221               34807

  dyndns.org                     AS9132               34847

  dyndns.org                     AS5713               35301

  dyndns.org                     AS5430               37534

  dyndns.org                     AS35776              40385
  ------------------------------ -------------------- -------------------

  ------------------------------ -------------------- -------------------
  **Domain**                     **AS NUM**           **Time (s)**

  akamai.net                     AS2914               1

  akamai.net                     AS2152               1

  akamai.net                     AS20940              1

  akamai.net                     AS4436               1

  akamai.net                     AS209                1

  akamai.net                     AS1299               3

  akamai.net                     AS27524              16

  akamai.net                     AS5650               22

  akamai.net                     AS23393              22

  akamai.net                     AS600                42

  akamai.net                     AS7843               42

  akamai.net                     AS6939               77

  akamai.net                     AS19151              87

  akamai.net                     AS17113              156

  akamai.net                     AS23504              294

  akamai.net                     AS6453               308

  akamai.net                     AS23352              308

  akamai.net                     AS6432               325

  akamai.net                     AS2711               354

  akamai.net                     AS4768               711

  akamai.net                     AS13609              723

  akamai.net                     AS25074              729

  akamai.net                     AS3549               744

  akamai.net                     AS513                762

  akamai.net                     AS7065               793

  akamai.net                     AS4766               829

  akamai.net                     AS7018               905

  akamai.net                     AS13776              1024

  akamai.net                     AS8121               1067

  akamai.net                     AS3356               1113

  akamai.net                     AS5511               1113

  akamai.net                     AS10026              1113

  akamai.net                     AS24730              1116

  akamai.net                     AS7011               1269

  akamai.net                     AS3491               1373

  akamai.net                     AS3320               1587

  akamai.net                     AS11456              1845

  akamai.net                     AS26769              3511

  akamai.net                     AS3257               5269

  akamai.net                     AS701                5789

  akamai.net                     AS1273               5960

  akamai.net                     AS1221               6506

  akamai.net                     AS3                  6805

  akamai.net                     AS3462               7223

  akamai.net                     AS20001              8328

  akamai.net                     AS12310              9797

  akamai.net                     AS286                10985

  akamai.net                     AS19817              14309

  akamai.net                     AS237                20959

  akamai.net                     AS4323               34880

  akamai.net                     AS7385               39659
  ------------------------------ -------------------- -------------------

**Appendix II large versions of graph visualizations**

![](media/image9.png){width="5.992361111111111in"
height="4.427083333333333in"}

![](media/image6.png){width="5.996527777777778in"
height="5.334722222222222in"}

e![](media/image4.jpeg){width="5.997916666666667in"
height="4.846527777777778in"}

![](media/image7.png){width="5.997222222222222in"
height="4.146527777777778in"}