Fast Flux: A Hidden Threat to VoIP Providers and ISPs

In today’s world of non-stop attacks and probes, most VoIP providers and ISPs focus their defenses on keeping bad actors out. Firewalls, TLS authentication, encryption—these are essential. But one lesser-known tactic used by attackers is designed not to break in—but to get out. And if we’re not watching, they might sneak right past us.

A modern tactic is called Fast Flux, and it can turn your own infrastructure into a tool for data exfiltration. It works in ways that are tough to detect using classic defenses.

What is Fast Flux?

At a glance, fast flux sounds like something from a sci-fi movie. But it’s very real—and dangerous.

Fast flux is a technique used by cybercriminals to hide the location of their servers by rapidly changing the IP addresses tied to a domain name. These IP addresses often belong to compromised machines spread across the globe, acting as proxies. When one IP gets blocked or taken down, another takes its place. Fast. Like… flux.

This trick is often used to maintain access to command-and-control (C2) servers—critical components in a cyberattack. These servers give instructions to malware and receive stolen data, often hidden behind constantly shifting DNS records.

Why Should VoIP Providers and ISPs Care?

Caption: The Core Infrastructure devices - such as Voice Application Servers (BroadWorks AS, NetSapiens Core, Metaswitch CFS, etc.) rarely need direct, unrestricted, random outbound Internet access.

VoIP providers and ISPs rely heavily on infrastructure—servers, containers, virtual machines, internal tools. Many of these systems are designed to process calls, manage routing, handle billing, or maintain internal functions. They’re not supposed to talk to random places on the public internet.

But if one of those core servers gets compromised?

That attacker may use it to call out to a fast flux domain—something like control-server.example.com—and then exfiltrate sensitive data. DNS makes this easier because:

• The attacker can use a fast-flux domain to stay hidden.
• The infected server simply asks DNS for the domain’s IP, and suddenly it’s talking to the attacker.
• The attacker can rotate through many different IP addresses, responding with 1.2.3.4 one minute, then 2.3.4.5 another minute, then 3.4.5.5 just a few minutes later. Most monitoring tools aren't good at detecting traffic going to many different targets.
• The domains aren't hosting malware, so most Protective DNS providers (think, DNSFilter or Cisco Umbrella)

Are your Phones Leaking Data?

Smart VoIP Endpoints are one key concern area for VoIP & Cloud Communications Providers.  Many modern phones are running the Android OS, and capable of having separate apps installed. If an attacker is able to exploit the phones at customer locations when those phones can make DNS lookups or otherwise have direct Internet access, the phones could potentially leak call logs, or even calling audio.

Caption: If normal VoIP Phones at customer locations at compromised and they have outbound Internet access, they could be used to exfiltrate (leak) data to attackers on the Internet.

Fast Flux raises the question: Why do phones need unrestricted Internet access anyway? Sure, this might have been the default expectation in 2015, when everyone was excited about RSS news feeds displayed on the phone displays. But the current reality is that phones are completely managed by central service providers who are the gateway to all important data. Properly designed phones at customer locations do not need access to the public Internet.

Fighting Fast Flux in this case would require having your Customer phones use the DNS services provided by the VoIP / Cloud Communication Provider. This is a common strategy already. But then it would give the Cloud provider the options to monitor and detect suspicious behavior launched from VoIP devices.

Monitoring Outbound Activity Is Crucial

Here’s the critical point: Most core infrastructure servers should not need outbound access to the entire Internet.

If your billing database server is making DNS requests and connecting to IP addresses in foreign countries, something’s wrong.

Limiting and monitoring outbound access from core systems is one of the most effective ways to stop fast flux-based data exfiltration. Treat outbound traffic the way you treat inbound: with caution and control.

Yes, your servers probably do need ability to retrieve software updates from a central server, such as Red Hat Enterprise Linux or Oracle Linux. But that doesn't mean they should be able to access arbitrary Internet sites.

Start by asking:

Is Fast Flux the same as DNS Exfiltration?

I've alluded to the concept that access to outbound DNS can be part of an exfiltration threat on its own. In the MITRE ATT@CK framework, this is called Exfiltration over Alternative Protocol.

For example, in the FrameworkPOS malware, the credit card numbers were actually leaked directly over DNS. This might give you a good reason to filter the DNS zones actually visible to your Core infrastructure servers and your customer's VoIP phones. Does a VoIP phone need to access pool.ntp.org? Sure. Does it need to access 98adfg87scl98.example.com? Nah. DNS servers, like BIND, can be configured to allow only DNS lookups to allowed zones. 

For example, a BIND configuration file like this allows lookups for voipprovider.com and ntp.org:

options {
    directory "/var/named";  # Adjust to your system
    recursion yes;
    allow-query { any; };  # or restrict to specific subnets
    allow-recursion { any; };  # or restrict if needed
    forward only;
    forwarders {
        8.8.8.8; 8.8.4.4;  // or your preferred upstream DNS servers
    };
};

acl "trusted" {
    192.168.1.0/24;  // adjust to your network, e.g., your Core Voice infrastructure
};

view "limited-access" {
    match-clients { "trusted"; };
    recursion yes;

    zone "ntp.org" {
        type forward;
        forward only;
        forwarders { 8.8.8.8; 8.8.4.4; };
    };

    zone "voipprovider.com" {
        type forward;
        forward only;
        forwarders { 8.8.8.8; 8.8.4.4; };
    };

    # Block all other lookups
    zone "." IN {
        type master;
        file "blocked.db";
    };
};

To use the example above you also need a blocked.db config file:

$TTL 86400
@   IN  SOA localhost. root.localhost. (
        2025040501 ; Serial
        3600       ; Refresh
        1800       ; Retry
        604800     ; Expire
        86400 )    ; Minimum TTL
    IN  NS  localhost.

How to Detect Fast Flux in DNS Logs

For the systems that legitimately need broad internet access—like update servers, software containers, or some outbound proxies—outright blocking may not be an option.

But DNS logs can give us visibility. Using tools like Splunk, ELK Stack, or SIEM platforms, you can detect fast flux behavior by analyzing DNS responses over time.

Look for domains that:

• Resolve to a large number of different IP addresses in a short time
• Use IPs in ranges not normally associated with reputable hosting
• Are queried repeatedly by a small number of your systems

Once detected, those domains can be blocked or added to a watchlist, and the associated systems can be investigated.

The Takeaway

Fast flux isn’t just a DNS trick—it’s a threat vector that can quietly turn your own servers into accomplices in a data breach. VoIP providers and ISPs are particularly vulnerable because of their reliance on exposed infrastructure and high-value data.

Action Steps:

1. Audit which core servers need outbound Internet access.
2. Restrict and log all outbound connections.
3. Monitor DNS queries from infrastructure systems.
4. Use automated tools to flag domains with high IP churn.
5. Investigate and act on anomalies early.

In security, what gets monitored gets managed. And when it comes to outbound traffic from your core systems, silence doesn’t mean safety—it may mean someone’s already inside.

Read More: CISA: Fast Flux, A National Security Threat.