The news wires have been full of stories about a cyberthreat dubbed Fast Flux, a jargon term invented in the first decade of this century, when the technique was both new and unusual.
The term has largely dropped out of common use in recent years, but now it’s back, with the same frisson of danger that it had when it was new.
Its reappearance is largely due to a warning circulated by the US Cybersecurity and Infrastructure Security Agency (CISA) with the dramatic title Fast Flux: A National Security Threat
Very loosely speaking, it refers to a trick whereby cybercriminals deliberately, and unpredictably, redirect a single server name on the internet, such as sneaky.rogues.test, to a huge range of different network addresses, making it as good as impossible to predict where that server name is going to take you in advance.
As we’ve explained in previous articles, it’s trivial to make an individual site such as a web server respond differently every time someone visits it.
Indeed, many crimeware sites these days try to guess whether the visitor is a potential crime victim or a threat researcher, and feed back dangerous malware or harmless-looking content accordingly.
Similarly, many criminals keep track of victims who have visited a phishing site recently, and on the second and subsequent visits redirect immediately to the site they are impersonating, thus giving victims a false sense of security by suppressing any suspicious signs if they try to retrace or repeat their steps.
Fast flux takes this variation even further, by very frequently changing the network addresses that victims are directed to.
To understand how this works, we’ll quickly revisit a vital service on the internet known as DNS, short for domain name system.
DNS is often described as “the phone book of the internet” (even though printed phone books are a distant memory), and it acts as a global, distributed database that converts device names into network numbers.
Humans expect to be able to use website names such as solcyber.com, but these names need converting into the corresponding numeric addresses used in network packets to send requests and receive replies.
Here, we’ve used DNS, which dates back to the 1980s, albeit with numerous tweaks and extensions along the way, to ask one of Google’s public DNS servers what internet addresses to use for solcyber.com:
Note that Google’s server isn’t officially tasked with looking after the domain solcyber.com and the network names underneath it, so the answer is flagged as non-authoritative.
Google knows what IP address to send back because its servers have gone through the process of tracking down which other servers in the huge DNS ecosystem are officially tasked with reporting where solcyber.com can be found, and has followed the necessary sequence of servers to figure out the answer for us.
The reply also reports that the so-called TTL for the solcyber.com IP address is 3600, which means that this answer has a time to live (a fancy way of saying that it is valid for) 3600 seconds, or one hour.
Your computer, after doing a lookup like this, will therefore usually cache this answer, or store it for re-use, for that length of time.
When you browse to a typical website these days, you could end up fetching hundreds or thousands of different components over the next several minutes, such as HTML files, stylesheets, font files, JavaScript programs, images, and more, perhaps making tens or even hundreds of network connections to the site.
Given that most sites don’t move around on the internet very frequently, that TTL number is meant to free you from needing to make a new DNS request every time, which would be a needless waste.
In case you’re wondering, the usual way to pronounce TTL is as an initialism, by saying tee-tee-ell. Don’t try to turn it into an acronym (a word in its own right) by pronouncing it tittle or tuttle.
Some servers use shorter, more aggressive TTLs, either because they run under very heavy load, or because they run their own set of redundant servers instead of using a cloud-based service to provide load balancing and failover in the background.
For example, here we’ve asked Google where the official name server (NS for short) for example.com can be found, to locate the authoritative source of data for the special example.com domain:
Once we knew where to look for an authoritative answer, we asked it for the DNS data for example.com, getting back a choice of six IPv4 network addresses (old-style internet numbers of four bytes, or 32 bits each), and six IPv6 addresses (16 bytes, or 128 bits, each).
Here, a more aggressive TTL of 300 seconds, or five minutes, has been used.
But many cloud-based services use similar settings to what we saw above for solcyber.com, such as Microsoft’s own Azure-based server:
Here, Google’s cached data tells us we can assume that Microsoft’s official name servers will remain where they are for at least the next three hours (12,446 seconds works out at 3hr27’26”), and that the various IPv4 and IPv6 numbers for microsoft.com itself can be considered valid for an hour (3600 seconds).
And if we ask one of Microsoft’s own name servers for authoritative information about itself and its colleagues, we get the official starting numbers for those TTL values, rather than values that have already “used up” some of their cache time on someone else’s non-authoritative server:
In case you’re wondering, 172,800 = 86,400×2, and 86,400 is a number worth remembering if you need to work with the ancient Babylonian sexagesimal (base 60) system that we have retained to this day for keeping track of times.
There are 24 hours, 1440 minutes, and 86,400 seconds in a day.
Fast-flux DNS services typically switch IP numbers much faster than that, and may publish TTLs of 60 seconds or even less.
Legitimate servers generally don’t change their IP numbers very often, so even if they have short TTLs, the IP numbers you get back are likely to be the same for hours, days, or even months.
But a fast-flux device’s DNS data, typically provided by a rogue DNS service listed as its authoritative name server, will not only give you a short TTL in order to force you into refreshing your local DNS cache very regularly, but may also give you a completely different IP address every time you look it up, making it a rapidly moving target:
An even fancier flavor of fast flux dubbed double flux by CISA sets low TTLs not only for the IP numbers through which the rogue sites themselves cycle, but also for the name servers themselves.
In this example, the rogue authoritative name server regularly replaces itself with a new server name and a new internet address.
By using a short TTL, any non-authoritative servers that have recently queried it will never be more than 60 seconds away from querying it again, and being dragged off elsewhere:
At you can imagine, the primary purpose of switching and swerving so frequently is to frustrate cybersecurity tools that rely on IP address blocklists to head malicious traffic off at the pass.
Obviously, a strong endpoint detection and response (EDR) product that monitors URLs and server names before they are used, or a protective DNS filtering tool such as DNSFilter, which SolCyber’s services use, can help you to block fast-flux networks by stopping the rogue DNS lookups in the first place.
But blocking rogue sites by their IP number alone is a common defensive tactic, and is especially useful when malicious traffic or exfiltrated data has already escaped through your firewall (or, in the case of contractors, home workers, and less well-protected users, has sidestepped your firewall or DNS filter entirely).
Indeed, the numeric network addresses in rogue packets may be all that’s left for security defenses to rely on, especially in the case of encrypted traffic that provides few or no hints of what it contains when it is seen in transit.
Remember also that once a packet is on its way to a network number determined by DNS lookup, the original server name involved in that lookup is lost. (Some network packets may contain the original server name somewhere in the data being sent, but that’s no use if the data is encrypted in transit.)
And by sweeping through a wide range of IP numbers without needing to register new domain names all the time, criminals may also be able to sidestep defenses that rely on spotting unusual network flow patterns, such as a large number of connections to a single, little-known network address that could be a indicator of data exfiltration.
Back when fast flux networks first got their name, in about 2007 or 2008, it was feasible to detect them by looking for TTLs that were unusually small, given that many legitimate services went out of their way to reduce unnecessary DNS lookups by using TTLs ranging from tens of minutes to several hours.
But with hugely increased network usage, with hugely improved network bandwidth at ever lower cost, and with users who expect content delivery networks to divert them around bottlenecks and outages within seconds rather than minutes, short DNS time-to-live values are now commonplace.
Here’s an example of a 60-second TTL in the real world, used to provide simple, low-cost accessibility for a server that doesn’t have a fixed IP number, but that automatically gets a new IP number whenever the ISP hosting it feels like changing it:
Of course, in the case demonstrated above, the short TTL is used just in case the IP number ever changes, to minimize the amount of time that an old network address might lie round in the world’s DNS caches after a change.
In contrast, fast flux networks typically have short TTL values specifically so they can regularly change the IP number, which creates a detectably different operational pattern.
A good DNS filtering tool or a switched-on SOC team will be able to use this behavioral difference as one of many signs to help them tell rogue networks from legitimate servers.
Never lose sight of the basics, even if you decide that fast-flux criminals are something you need to watch out for.
Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Featured image of swooping candle flame by Mahdi Bafande via Unsplash.
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
