An Ever Changing Enemy
The Honeynet Project & Research Alliance
Last Modified: 13 July, 2007
INTRODUCTION
One of the most active
threats we face today on the Internet is cyber-crime. Increasingly
capable criminals are constantly developing more sophisticated means
of profiting from online criminal activity. This paper demonstrates
a growing, sophisticated technique called fast-flux service networks
which we are seeing increasingly used in the wild. Fast-flux service
networks are a network of compromised computer systems with public DNS
records that are constantly changing, in some cases every few minutes.
These constantly changing architectures make it much more difficult
to track down criminal activities and shut down their operations.
In this paper we will
first provide an overview of what fast-flux service networks are, how
they operate, and how the criminal community is leveraging them, including
two types which we have designated as single-flux and double-flux
service networks. We then provide several examples of fast-flux
service networks recently observed in the wild,. Next we detail how
fast-flux service network malware operates and present the results of
research where a honeypot was purposely infected with a fast-flux agent.
Finally we cover how to detect, identify, and mitigate fast-flux service
networks, primarily in large networking environments. At the end
we supply five appendixes providing additional information for those
interested in digging into more technical detail.
HOW FAST-FLUX SERVICE NETWORKS WORK
The goal of fast-flux
is for a fully qualified domain name (such as
www.example.com) to have multiple (hundreds or even thousands)
IP addresses assigned to it. These IP addresses are swapped in
and out of flux with extreme frequency, using a combination of round-robin
IP addresses and a very short Time-To-Live (TTL) for any given particular
DNS Resource Record (RR). Website hostnames may be associated with a
new set of IP addresses as often as every 3 minutes. A browser
connecting to the same website every 3 minutes would actually be connecting
to a different infected computer each time. In addition, the attackers
ensure that the compromised systems they are using to host their scams
have the best possible bandwidth and service availability. They often
use a load-distribution scheme which takes into account node health-check
results, so that unresponsive nodes are taken out of flux and content
availability is always maintained.
A second layer is often
added for security and fail-over: blind proxy redirection. Redirection
disrupts attempts to track down and mitigate fast-flux service network
nodes. What happens is the large pool of rotating IP addresses
are not the final destination of the request for the content (or other
network service). Instead, compromised front end systems are merely
deployed as redirectors that funnel requests and data to and from other
backend servers, which actually serve the content. Essentially the domain
names and URLs for advertised content no longer resolve to the IP address
of a specific server, but instead fluctuate amongst many front end redirectors
or proxies, which then in turn forward content to another group of backend
servers. While this technique has been used for some time in the world
of legitimate webserver operations, for the purpose of maintaining high
availability and spreading load, in this case it is evidence of the
technological evolution of criminal computer networks.
Fast-flux “motherships”
are the controlling element behind fast-flux service networks, and are
similar to the command and control (C&C) systems found in conventional
botnets. However, compared to typical botnet IRC servers, fast-flux
motherships have many more features. It is the upstream fast-flux mothership
node, which is hidden by the front end fast-flux proxy network nodes,
that actually delivers content back to the victim client who requests
it. Flux-herder mothership nodes have been observed to operate successfully
for extended periods of time in the wild. These nodes are often observed
hosting both DNS and HTTP services, with web server virtual hosting
configurations able to manage the content availability for thousands
of domains simultaneously on a single host. Until late March 2007, we
observed the appearance of only two primary upstream mothership hosts
deployed and serving the many thousands of domains in flux, suggesting
that this technique was primarily developed and utilized by small number
of groups or individuals. Domain registrations of .hk, and .info
were found to be among the most heavily utilized TLDs for registering
fast-flux domains, but this registration abuse is most certainly shared
amongst all registrars (as occasionally .com and other TLD domains are
also witnessed).
We have categorized
two different types of fast-flux networks, single-flux and double-flux.
Everything you have read up to this point discusses single-flux networks.
Double-flux has an additional layer of protection by also constantly
changing the IP addresses for the Authoritive Name Servers. Below
we give examples of each, starting with single-flux.
SINGLE-FLUX NETWORKS
In Figure 1 below we
demonstrate a single-flux network. We compare a normal web browser
communicating directly with a typical website against the case of a
single-flux service network, where the end user’s browser communication
is proxied via a redirector (the ¨flux-bot¨ or ¨flux-agent¨). When
a victim believes that they are browsing
http://flux.example.com,
their browser is actually communicating with
the fast-flux service network redirector which redirects the requests
to the target website. Single-flux service networks change the DNS records
for their front end node IP address as often as every 3-10 minutes,
so even if one flux-agent redirector node is shut down, many other infected
redirector hosts are standing by and available to quickly take its place.
We have found these fast-flux networks to be composed of primarily compromised
home computers.
Fast-flux networks
are responsible for many illegal practices, including online pharmacy
shops, money mule recruitment sites, phishing websites, extreme/illegal
adult content, malicious browser exploit websites, and the distribution
of malware downloads. Beyond our regular observation of new DNS and
HTTP services, other services such as SMTP, POP, and IMAP can be delivered
via fast-flux service networks. Because fast-flux techniques utilize
blind TCP and UDP redirects, any directional service protocol with a
single target port would likely encounter few problems being served
via a fast-flux service network.
DOUBLE-FLUX SERVICE NETWORKS
Double-flux networks
are a more complex technique providing an additional layer of redundancy.
Specifically, both the DNS A record sets and the authoritative NS records
for a malicious domain are continually changed in a round robin manner
and advertised into the fast-flux service network. From our observations
of double-flux networks active in the wild, DNS and HTTP services are
both served from the same upstream mothership node. Figure 2 below demonstrates
the difference between a single-flux service network and double-flux
service network. Please note that in the figure below that request
caching is not taken into account and that the outbound request would
usually emanate from the client's preferred nameserver instead of the
client itself.
On the left-hand side,
we depict a single-flux lookup: the client wants to resolve the address
http://flux.example.com/
flux.example.com.
First, it asks the DNS root nameserver which
name server is responsible for the top-level domain .com and receives
an answer (omitted in the picture). In a second step, the client queries
the .com
nameserver for the domain example.com and receives
as an answer a referral to the nameserver ns.example.com. Now
the client can query the authoritative DNS server ns.example.com for
the actual IP address of the address flux.example.com. The authoritative
nameserver answers with an IP address that the client can then attempt
to initiate direct communication with. For a normal DNS lookup, the
answer IP address usually remains constant over a certain period of
time, whereas for single-flux nodes, the answer changes frequently.
At the right hand side,
we depict a DNS lookup for an address within a double-flux domain. Again,
the client wants to look up the address flux.example.com. Once
again, the first step (lookup at root nameserver) is omitted for sake
of brevity. Next, the client queries the nameserver responsible for
the top-level domain .com for the authoritative nameserver for
the domain example.com. In a third step, the client then queries the
authoritative DNS server ns.example.com for the address
flux.example.com.
However, this authoritative nameserver is actually part of the double-flux
scheme itself and its own IP address changes frequently. When a DNS
request for flux.example.com is received from the client, the
current authoritative nameserver forwards the queries to the mothership
node for the required information. The client can them attempt to initiate
direct communication with the target system (although this target system
will itself be a dynamically changing front end flux-agent node). ADVANTAGES
FOR THE ATTACKER ¨Traditional¨ cyber-crime
activities such as phishing typically require an attacker to compromise
one or more victim computer systems (either individually or via mass
auto-rooters) and establish a fake or fraudulent web site. Content would
then be advertised to victims either by mass emailing or more targeted
marketing (spear phishing), often through other compromised computer
systems and botnets. The computer systems hosting the malicious content
would be identified either by public DNS name or directly by IP address
embedded within the email lure messages. These types of scams
are identified relatively quickly by security professionals and can
be quickly shut down. As the average time of survival was reduced for
these phishing websites, criminals began to add additional layers of
protection, such as server address obfuscation or utilize groups of
proxy servers to redirect network. Such systems are limited in scale
and can still be tracked down fairly quickly with international co-operation.
We are now seeing the next evolutionary step, the fast-flux network.
In the end, it’s all about Return on Investment (ROI) for the criminals,
and fast-flux service networks provide a reliable way to maximize the
returns on their criminal activities for relatively low effort.
Fast-flux service networks offer three major advantages to operators
of Internet based criminal activity. The first advantage
is found in both legitimate and criminal operations: simplicity.
Only one suitably powerful backend server (or mothership) host is needed
to serve the master content and DNS information. The published
URLs (such as via phishing lures) point to front end proxy redirectors,
which then transparently redirect client connection requests to the
actual malicious back end server or servers. This makes the content
delivery infrastructure much simpler for criminals to manage.
Instead of having to build (or compromise) and maintain many servers
to host their phishing or malicious websites, they now require only
a small number of well managed core systems to host their scam sites
and malware, whilst other attackers can specialize in building and operating
reliable fast-flux service networks to deliver their malicious content. The second advantage
is that front-end nodes are disposable criminal assets that can offer
a layer of protection from ongoing investigative response or legal action.
When a security professional is responding to an incident and attempts
to track down a malicious website hosted via a fast-flux service network,
they typically recover only a handful of IP addresses corresponding
to disposable front-end nodes which may be spread across multiple jurisdictions,
continents, regional languages and time zones, which further complicates
the investigation. Because of the proxy redirection layer, an
electronic crimes investigator or incident responder will often find
no local evidence of the hosting of malicious content on compromised
front end systems, and traffic logging is usually disabled so audit
trails are also limited. Thirdly, fast-flux
service networks extend the operational lifespan of the critical backend
core servers that are hidden by the front-end nodes. It can take much
longer to identify and shut down these core backend servers due to the
multiple layers of redirection – particularly if these nodes are hosted
in territories with lax laws and criminal-friendly ‘bullet-proof’
hosting services. Very few operational changes have been observed in
live backend servers during the extensive monitoring of fast-flux service
network cores, which is a testament to the success of this operational
model. REAL
WORLD FAST-FLUX EXAMPLES Having explained the
underlying principles, we will now look at a fast-flux service network
from the point of view of a criminal and review the basic steps required
to setup a fast-flux service network. First, our criminal(s) registers
a domain for their attack. An example would be a bogus domain
name that appears similar to a bank, or a site promoting pharmaceutical
drugs. In our case, we will use example.com’. Based
on our research, the domain extensions .info and .hk are
some of the most commonly abused Top Level Domains (TLD’s). This is
may be due to the fact that resellers for these domain registrars are
more lax in their controls than other TLDs. Often these false
domains are registered by fraudulent means, such as using stolen credit
cards and bogus or otherwise invalid registrant account detail. The
criminal(s) will often already have control of a network of compromised
systems to act as their redirectors, or they can temporarily rent a
botnet. In addition, registrations for the domains are often the
cheapest. The criminal(s) then publish Name Server (NS)
records that either point to bullet-proof hosting, or at any of the
proxy/redirects flux-agent nodes under their control. Examples
of bullet-proof hosting providers could include DNS services operated
from Russia, China, or many other countries around the world.
If the criminals do not have access to this type of hardened service,
they will host the DNS services on their own compromised systems, and
often the mothership node that is hosting the master web sites can also
be found serving DNS services. We will now review two actual
deployments. Single-Flux: A Money
Mule
Below are the single-flux
DNS records typical of such an infrastructure. The tables show DNS snapshots
of the domain name divewithsharks.hk taken approximately every
30 minutes, with the five A records returned round-robin showing clear
infiltration into home/business dialup and broadband networks.
Notice that the NS records do not change, but some of the A records
do. This is the money mule web site.
First we will review
the DNS records for a single-flux service network. This is a real
world example demonstrating a money mule recruitment scam. A money
mule is someone that acts as an intermediary in transferring or withdrawing
money often involved in fraud. For example, a criminal will steal
money out of someone’s bank account, transfer it to the money mule’s
bank account, then have the money mule withdraw the funds and send them
to a location for pickup, perhaps in a different country.
What is unique about some current money mule scams is that the money
mule may think they are working for a legitimate company, not realizing
they are acting on the behalf of criminals in money laundering schemes.
Often the money mule is actually just another victim in a chain of other
victims.
;; WHEN: Sat Feb 3 20:08:08 2007
divewithsharks.hk. 1800 IN A 70.68.187.xxx [xxx.vf.shawcable.net]
divewithsharks.hk. 1800 IN A 76.209.81.xxx [SBIS-AS - AT&T Internet Services]
divewithsharks.hk. 1800 IN A 85.207.74.xxx [adsl-ustixxx-74-207-85.bluetone.cz]
divewithsharks.hk. 1800 IN A 90.144.43.xxx [d90-144-43-xxx.cust.tele2.fr]
divewithsharks.hk. 1800 IN A 142.165.41.xxx [142-165-41-xxx.msjw.hsdb.sasknet.sk.ca]
divewithsharks.hk. 1800 IN NS ns1.world-wr.com.
divewithsharks.hk. 1800 IN NS ns2.world-wr.com.
ns1.world-wr.com. 87169 IN A 66.232.119.212 [HVC-AS - HIVELOCITY VENTURES CORP]
ns2.world-wr.com. 87177 IN A 209.88.199.xxx [vpdn-dsl209-88-199-xxx.alami.net]
Single-flux nets appear
to apply some form of logic in deciding which of their available
IP addresses will be advertised in the next set of responses.
This may be based on ongoing connection quality monitoring (and perhaps
a load-balancing algorithm). New flux-agent IP addresses are inserted
into the fast-flux service network to replace nodes with poor performance,
being subject to mitigation or otherwise offline nodes. Now let’s
take a look at the DNS records of the same domain name 30 minutes later
and see what has changed:
;; WHEN: Sat Feb 3 20:40:04 2007 (~30 minutes/1800 seconds later) divewithsharks.hk. 1800 IN A 24.85.102.xxx [xxx.vs.shawcable.net] NEW divewithsharks.hk. 1800 IN A 69.47.177.xxx [d47-69-xxx-177.try.wideopenwest.com] NEW divewithsharks.hk. 1800 IN A 70.68.187.xxx [xxx.vf.shawcable.net] divewithsharks.hk. 1800 IN A 90.144.43.xxx [d90-144-43-xxx.cust.tele2.fr] divewithsharks.hk. 1800 IN A 142.165.41.xxx [142-165-41-xxx.msjw.hsdb.sasknet.sk.ca] divewithsharks.hk. 1800 IN NS ns1.world-wr.com. divewithsharks.hk. 1800 IN NS ns2.world-wr.com. ns1.world-wr.com. 85248 IN A 66.232.119.xxx [HVC-AS - HIVELOCITY VENTURES CORP] ns2.world-wr.com. 82991 IN A 209.88.199.xxx [vpdn-dsl209-88-199-xxx.alami.net] |
As we see, highlighted
in bold two of the advertised IP addresses have changed. Again, these
two IP addresses belong to dial-up or broadband networks. Another 30
minutes later, a lookup of the domain returns the following information:
;; WHEN: Sat Feb 3 21:10:07 2007 (~30 minutes/1800 seconds later) divewithsharks.hk. 1238 IN A 68.150.25.xxx [xxx.ed.shawcable.net] NEW divewithsharks.hk. 1238 IN A 76.209.81.xxx [SBIS-AS - AT&T Internet Services] This one came back! divewithsharks.hk. 1238 IN A 172.189.83.xxx [xxx.ipt.aol.com] NEW divewithsharks.hk. 1238 IN A 200.115.195.xxx [pcxxx.telecentro.com.ar] NEW divewithsharks.hk. 1238 IN A 213.85.179.xxx [CNT Autonomous System] NEW divewithsharks.hk. 1238 IN NS ns1.world-wr.com. divewithsharks.hk. 1238 IN NS ns2.world-wr.com. ns1.world-wr.com. 83446 IN A 66.232.119.xxx [HVC-AS - HIVELOCITY VENTURES CORP] ns2.world-wr.com. 81189 IN A 209.88.199.xxx [vpdn-dsl209-88-199-xxx.alami.net] |
Now, we observe four
new IP addresses and one IP address that we saw in the first query.
This demonstrates the round-robin address response mechanism used in
fast-flux networks. As we have seen in this example, the A records for
the domain are constantly changing. Each one of these systems
represents a compromised host acting as a redirector, a redirector that
eventually points to the money mule web site. A significant response
issue is that the incident responders do not know the ultimate destination
of the money mule site unless they have access to one of the redirector
nodes. This creates a far more dynamic and robust environment
for the criminals. Next we will consider double-flux networks,
where criminals add an additional layer of complexity to improve their
security.
Double-Flux: MySpace
Double-flux is where
both the NS records (authoritative name server for the domain) and A
records (web serving host or hosts for the target) are regularly changed,
making the fast-flux service network much more dynamic. For double-flux
techniques to work, the domain registrar has to allow the domain administrator
the ability to frequently change the NS information, which is not something
that usually occurs in normal domain management.
In the example below,
we observe a phishing attack directed against the popular social networking
web site MySpace. The attacker has created a bogus website called
login.mylspacee.com. This fake website appears visually to
be the real MySpace web site, but instead harvests MySpace user authentication
credentials from anyone who is tricked into logging in to the fake site.
To make it harder for security professionals to shut down the fake site,
both the NS and A DNS records are constantly changing.
Observing DNS activity
in such incidents, it is very common to detect a consistent pattern
of between five to ten A record in a set of round-robin responses, in
addition to a five NS record round-robin response set for any double-flux
domain. This signature is becoming the hallmark for identifying double-flux
domains. In the table below, observe that these DNS records are constantly
changing:
;; WHEN: Wed Apr 4 18:47:50 2007 login.mylspacee.com. 177 IN A 66.229.133.xxx [c-66-229-133-xxx.hsd1.fl.comcast.net] login.mylspacee.com. 177 IN A 67.10.117.xxx [cpe-67-10-117-xxx.gt.res.rr.com] login.mylspacee.com. 177 IN A 70.244.2.xxx [adsl-70-244-2-xxx.dsl.hrlntx.swbell.net] login.mylspacee.com. 177 IN A 74.67.113.xxx [cpe-74-67-113-xxx.stny.res.rr.com] login.mylspacee.com. 177 IN A 74.137.49.xxx [74-137-49-xxx.dhcp.insightbb.com] mylspacee.com. 108877 IN NS ns3.myheroisyourslove.hk. mylspacee.com. 108877 IN NS ns4.myheroisyourslove.hk. mylspacee.com. 108877 IN NS ns5.myheroisyourslove.hk. mylspacee.com. 108877 IN NS ns1.myheroisyourslove.hk. mylspacee.com. 108877 IN NS ns2.myheroisyourslove.hk. ns1.myheroisyourslove.hk.854 IN A 70.227.218.xxx [ppp-70-227-218-xxx.dsl.sfldmi.ameritech.net] ns2.myheroisyourslove.hk.854 IN A 70.136.16.xxx [adsl-70-136-16-xxx.dsl.bumttx.sbcglobal.net] ns3.myheroisyourslove.hk. 854 IN A 68.59.76.xxx [c-68-59-76-xxx.hsd1.al.comcast.net] ns4.myheroisyourslove.hk. 854 IN A 70.126.19.xxx [xxx-19.126-70.tampabay.res.rr.com] ns5.myheroisyourslove.hk. 854 IN A 70.121.157.xxx [xxx.157.121.70.cfl.res.rr.com] |
About 4 minutes later,
for the same domain, only the A records have changed. Notice that
the NS records have remained the same.
;; WHEN: Wed Apr 4 18:51:56 2007 (~4 minutes/186 seconds later) login.mylspacee.com. 161 IN A 74.131.218.xxx [74-131-218-xxx.dhcp.insightbb.com] NEW login.mylspacee.com. 161 IN A 24.174.195.xxx [cpe-24-174-195-xxx.elp.res.rr.com] NEW login.mylspacee.com. 161 IN A 65.65.182.xxx [adsl-65-65-182-xxx.dsl.hstntx.swbell.net] NEW login.mylspacee.com. 161 IN A 69.215.174.xxx [ppp-69-215-174-xxx.dsl.ipltin.ameritech.net] NEW login.mylspacee.com. 161 IN A 71.135.180.xxx [adsl-71-135-180-xxx.dsl.pltn13.pacbell.net] NEW mylspacee.com. 108642 IN NS ns3.myheroisyourslove.hk. mylspacee.com. 108642 IN NS ns4.myheroisyourslove.hk. mylspacee.com. 108642 IN NS ns5.myheroisyourslove.hk. mylspacee.com. 108642 IN NS ns1.myheroisyourslove.hk. mylspacee.com. 108642 IN NS ns2.myheroisyourslove.hk. ns1.myheroisyourslove.hk. 608 IN A 70.227.218.xxx [ppp-70-227-218-xxx.dsl.sfldmi.ameritech.net] ns2.myheroisyourslove.hk. 608 IN A 70.136.16.xxx [adsl-70-136-16-xxx.dsl.bumttx.sbcglobal.net] ns3.myheroisyourslove.hk. 608 IN A 68.59.76.xxx [c-68-59-76-xxx.hsd1.al.comcast.net] ns4.myheroisyourslove.hk. 608 IN A 70.126.19.xxx [xxx-19.126-70.tampabay.res.rr.com] ns5.myheroisyourslove.hk. 608 IN A 70.121.157.xxx [xxx.157.121.70.cfl.res.rr.com] |
Checking again one
and a half hours later, the NS records for this domain have migrated
and five new NS records appear. Similar to the previous example, we
see that the A and NS record are hosted at dial-up or broadband providers,
indicating that these are compromised hosts used by an attacker for
nefarious purposes:
;; WHEN: Wed Apr 4 21:13:14 2007 (~90 minutes/4878 seconds later) ns1.myheroisyourslove.hk. 3596 IN A 75.67.15.xxx [c-75-67-15-xxx.hsd1.ma.comcast.net] NEW ns2.myheroisyourslove.hk. 3596 IN A 75.22.239.xxx [adsl-75-22-239-xxx.dsl.chcgil.sbcglobal.net] NEW ns3.myheroisyourslove.hk. 3596 IN A 75.33.248.xxx [adsl-75-33-248-xxx.dsl.chcgil.sbcglobal.net] NEW ns4.myheroisyourslove.hk. 180 IN A 69.238.210.xxx [ppp-69-238-210-xxx.dsl.irvnca.pacbell.net] NEW ns5.myheroisyourslove.hk. 3596 IN A 70.64.222.xxx [xxx.mj.shawcable.net] NEW |
FAST-FLUX MALWARE
Flux node agents share
the most essential and basic capabilities of the traditional, but minimalist
IRC-based bot in several ways: they regularly phone home to announce
their continued availability, they check for updates, perform download
operations, and allow for the execution of arbitrary commands on the
local operating system by a remote attacker. However, almost without
exception, fast-flux Command and Control (C&C) activity observed
in the wild thus far has been HTTP protocol based.
The ability of Fast-flux
agents to proxy or redirect TCP services appears to be an outgrowth
from the redirect functions of legacy IRC bots that possess optional
UDP proxy or redirect capabilities. The bundling of these features
enables a fast-flux service network to become a powerful criminal tool
and helps to make the fast-flux service network operator less easily
detectable. The fast-flux front end nodes will either act on command
or execute hard-coded instructions to redirect inbound traffic received
on configured ports to a specifically chosen upstream fast-flux mothership
node. Several fast-flux service network operations have been observed
maintaining distributed nodes that act primarily in performing availability
and connection quality tests of individual flux-agents within the fast-flux
service network. For an example of the development cycle of fast-flux
malware, refer to Appendix A. For an example of the infection
process for the malware, refer to Appendix B.
Below we summarize two commonly used malware that have adopted fast-flux capabilities.
Warezov/Stration:
Storm:
FAST-FLUX
CASE STUDY We have discussed several
real world examples captured in the wild. Now let’s take a closer,
more detailed look at an incident. In this case, we deliberately
infected a honeypot system with a fast-flux agent. The system
was contained in a controlled Honeywall environment. The malware we
used was called weby.exe and had the MD5 hash 70978572bc5c4fecb9d759611b27a76
http://xxx.ifeelyou.info
http://xxx.iconnectyou.biz For which the server
responds with what appears to be a consistent 197 byte binary/encoded
configuration response. We are still attempting to reverse
engineer complete details of this session. For full packet
payload of the binary/encoded configuration response, please refer to
Appendix D. STATISTICS To give you a better
feel of the scope of fast-flux service networks and how many systems
are typically involved, below we provide statistics about one specific
fast-flux service network. This example was involved in delivery of
a PharmaShop scam. Key points include: We collected data from
03 February 2007 to 11 February 2007. The domain itself
greatfriedrice.info was created January 02, 2007 at 15:11 and was
terminated February 13, 2007 at 04:26 EST. To gather our information
we queried DNS every 2 minutes and then collected information on the
IP addresses assigned to the domain name and how those IP addresses
(A and NS records) changed over time. A total of 3,241 unique IP addresses
were utilized in this fast-flux service net during the study. Of these
unique IP addresses, 1,516 were advertised as Authoritative NS records.
2,844 were short lived TTL A record round robins used for HTTP proxy/redirect.
256 different Autonomous Systems (AS's) were represented in the infection
base. 181 AS’s served fluxDNS, and 241 AS’s served fluxHTTP redirection.
This may be an indicator of provider policies regarding inbound blocking
policies of either UDP 53 or TCP 80 into subscriber populations.
Below is a table highlighting the AS’s that had the most infected
systems as part of the fast-flux service network. This example was chosen
because it was monitored at the highest resolution (every 2 min). To
date over 80,000 flux IPs have been logged so far with over 1.2 million
unique mappings.
DETECTION & MITIGATION Our goal is to not
only to explain the threat of fast-flux service networks, but also offer
advice on how to identity and mitigate them. We provide several suggestions
that highlight potential steps that can be taken and provide a brief
overview of possible mitigation strategies. However, this is not a complete
overview, since this complex topic deserves a paper on its own. It can be very difficult
to detect and shut down fast-flux service networks. The detection of
domain names being served by a fast-flux service network depends upon
multiple analytical passes over DNS query results, with increasing flux
detection accuracy gained by employing a scoring mechanism to evaluate
multiple relatively short lived DNS records, taking into account including
the number of A records returned per query, the number of NS records
returned, the diversity of unrelated networks represented and the presence
of broadband or dialup networks in every result set. This concept of
analyzing short TTLs with the associated scoring of result sets per
domain or hostname from multiple successive TTL expiration periods can
work in identifying the use of fast-flux service networks. First, service providers
can detect upstream mothership nodes by probing any suspected flux-agent
proxies in specific ways. Assuming that the suspect flux-agent
is in fact a proxy redirecting TCP port 80 or perhaps UDP port 53 traffic
to some as of yet unknown host upstream, the use of any specially crafted
request with an otherwise low probability of occurrence in the wild
may enable egress/Internet bound IDS sensors to alert on network events
that in turn identify the mothership. The basic idea is to send out
probe packets and then observe them on their way from the flux-agent
to the actual mothership. You will likely need to do additional heavy
lifting to identify any other fast-flux service net infrastructure components
that include the distributed health/availability/connection quality
monitoring hosts, in addition to the phone-home and registration mechanisms. The following example
demonstrates a flux mothership host discovery process which leverages
IDS sensor deployments. This is accomplished most simply through
the use of a Base64 encoded text string, in this case it is “helloflux”
which is then delivered through a flux agent as part of an HTTP request
or DNS query. We do this essentially to exercise the full network
communications path using easily detectable strings. This can be accomplished
with the following two steps for use with any flux agent reported by
DNS monitoring of provable flux domains. The following two Snort
signatures trigger on HTTP and DNS communication that contains the Base64
encoded string “helloflux” (aGVsbG9mbHV4IAo). We set up these signatures on different
IDS sensors across the network and then in a second step inject a message
into the fast-flux service network. If one of the IDS sensors picks
up the message, we can trace to which destination it is really sent
by the flux-agent. alert tcp $HOME_NET
1024:5000 -> !$HOME_NET 80 (msg: "FluxHTTP_Upstream_DST";
flow: established,to_server; content:"aGVsbG9mbHV4IAo"; offset:
0; depth: 15; priority: 1; classtype:trojan-activity; sid: 5005111;
rev: 1;) alert udp $HOME_NET
1024:65535 -> !$HOME_NET 53 (msg: "FluxDNS_Upstream_DST";
content: "|00 02 01 00 00 01|"; offset: 0; depth: 6; content:"aGVsbG9mbHV4IAo";
within: 20; priority: 1; classtype:trojan-activity; sid: 5005112; rev:
1;) The following simple
shell scripts injects the Base64-encoded string “helloflux”
(aGVsbG9mbHV4IAo) one for a HTTP request and then another for
a DNS request. With the help of the Snort signatures from above, we
can then trace the path of the strings through the network. If a service provider
lacks IDS capability in the user space, yet has the capability to report
on NetFlow, this mechanism can also be used to detect fast-flux service
networks. This is not as good as the IDS-based detection method presented
above, but looking for TCP 80 and/or UDP 53 into user IP space is a
start. This kind of traffic should normally not occur and is thus a
sign of a possible flux-agent. The following listing provides
some further ideas to stop this kind of threat. In brackets, we list
which party could implement such mitigation policies: This is just a very
brief overview of how fast-flux service networks can be mitigated, and
further research is required in this subject area. SUMMARY Fast-flux service networks
demonstrate an evolutionary step for online crime operations.
Fast-flux service networks create robust, obfuscating service delivery
infrastructures that make it difficult for system administrators and
law enforcement agents to shut down active scams and identify the criminals
operating them. The robustness, obfuscation capabilities, scalability
and increased availability of fast-flux service produce an increased
Return on Investment (ROI) for the criminals who operate them. Just
as in legitimate business, the Internet represents a huge economic business
model for online crime, which unfortunately means that we can expect
techniques such as fast-flux service networks to continue to evolve.
Often emerging threats such as fast-flux service networks are a step
ahead of security professionals, and it looks likely that this particular
arms race will continue into the foreseeable future. ACKNOWLEDGEMENTS A paper of this complexity
requires the input and cooperation from many people and organizations.
In particular the Honeynet Project would like to thank the following
people:
The networks based
upon these malware variants have been erected to provide a robust platform
for sending large volumes of unsolicited email (spam). They have been
very successful in this goal and employ advanced techniques such as
the constant automated creation of many malware variants to frustrate
anti-virus signature creation. Infected machines download these updates
on a regular schedule in order to increase the amount of time it takes
for a system to be cleaned and taken offline. These updates must be
hosted on websites, so if their public IP addresses remain static, the
update sites can potentially be taken down fairly easily. Until recently,
a strategy of auto-generating pseudo-random domain names which moved
around was used to protect such download sites. Starting in May 2007,
the criminal organization behind this spam business moved to a fast-flux
service network model. This group is now hosting their DNS services
and malware download sites via fast-flux service networks and appear
to be enjoying continued success in their criminal endeavor.
The biggest competitor
of the Warezov/Stration gang is perhaps the criminal organization operating
a very large spam sending network based on the family of malware variants
dubbed Storm/Peacomm/Peed. They employ a UDP-based P2P model for botnet
command and control. This is a highly robust way to operate a large
distributed network if the complexities of managing peer lists and minimizing
latency can be overcome. They have also employed novel techniques to
counter anti-spam solutions, such as generating image-based spam on
the fly on the endpoints flux-agent nodes themselves, rather than simply
relying on template based messaging. These images are randomized in
ways which frustrate the OCR (object character recognition) technologies
used in some anti-spam products and have been most commonly used to
facilitate fraudulent pump and dump stock spam schemes. In June 2007
this group was observed attempting to modify their P2P network to support
fast-flux style networking. This is a significant advance for spam-sending
malware and requires further study.
$ echo fluxtest.sh ;
#!/bin/bash
# Simple shell script to test
# suspected flux nodes on your managed networks
echo " aGVsbG9mbHV4IAo" | nc -w 1 ${1} 80
dig +time=1 aGVsbG9mbHV4IAo.dns.com @${1}
