Report: Air-Gapped Networks Vulnerable to DNS Attacks

Common misconfigurations in how Domain Name System (DNS) is implemented in an enterprise environment can put air-gapped networks and the high-value assets they are aimed at protecting at risk from external attackers, researchers have found.

Organizations using air-gapped networks that connect to DNS servers can inadvertently expose the assets to threat actors, resulting in high-impact data breaches, researchers from security firm Pentera revealed in a blog post published Dec. 8.

Attackers can use DNS as a command-and-control (C2) channel to communicate with these networks through DNS servers connected to the Internet, and thus breach them even when an organization believes the network is successfully isolated, the researchers revealed.

Air-gapped networks are segregated without access to the Internet from the common user network in a business or enterprise IT environment. They are designed this way to protect an organization's "crown jewels," the researchers wrote, using VPN, SSL VPN, or the users' network via a jump box for someone to gain access to them.

However, these networks still require DNS services, , which is used to assign names to systems for network discoverability. This represents a vulnerability if DNS is not configured carefully by network administrators.

"Our research showcases how DNS misconfigurations can inadvertently impact the integrity of air-gapped networks," Uriel Gabay, cyberattack researcher at Pentera, tells Dark Reading.

What this means for the enterprise is that by abusing DNS, hackers have a stable communication line into an air-gapped network, allowing them to exfiltrate sensitive data while their activity appears completely legitimate to an organization's security protocols, Gabay says.

DNS as a Highly Misconfigurable Protocol

The most common mistake companies make when setting up an air-gapped network is to believe they are creating an effective air gap when they chain it to their local DNS servers, Gabay says. In many cases, these servers can be linked to public DNS servers, which means "they have unintentionally broken their own air gap."

It's important to understand how DNS works to know how attackers can navigate its complexities to break into an air gap, the researchers explained in their post.

Sending information over DNS can be done by requesting a record that the protocol handles — such as TXT, a text record, or NS, a name server record — and putting the information into the first part of the record’s name, the researchers explained. Receiving information over DNS can be done by requesting a TXT record and receiving a text response back for that record.

While DNS protocol can run on TCP, it is mostly based on UDP, which does not have a built-in security mechanism — one of two key factors that come into play for an attacker to take advantage of DNS, the researchers said. There also is no control over the flow or sequence of data transmission in UDP.

Thanks to this lack of error detection in UDP, attackers can compress a payload prior to sending it and immediately decompress after sending, which can be done with any other type of encoding, such as base64, the researchers explained.

Using DNS to Break an Air Gap

That said, there are challenges for threat actors to communicate successfully with DNS to break an air gap. DNS has restrictions on the types of characters it accepts, so not all characters can be sent; those that can't are called "bad characters," the researchers said. There also is a limit on the length of characters that can be sent.

To overcome the lack of control over data flow in DNS, threat actors can notify the server which packet should be buffered, as well as what is expected as the last package, the researchers said. A package also should not be sent until an attacker knows that the previous one successfully arrived, they said.

To avoid bad characters, attackers should apply base64 on data sent right before sending it, while they can slice data into pieces to be sent one by one to avoid the DNS character length limit, they said.

To get around a defender blocking a DNS request by blocking access to the server from which it is being sent, an attacker can generate domain names based on variables that both sides know and expect, the researchers explained.

"While the executable is not necessarily difficult, an attacker or group would need the infrastructure to continue to buy root records," they noted.

Attackers also can configure malware to generate a domain in DNS based on a date, which will allow them to constantly send new requests over DNS using a new, known root domain, the researchers said. Defending against this type of configuration "will prove challenging to organizations using static methods or even with basic anomaly detection to detect and prevent," they said.

Mitigating DNS Attacks on Air-Gapped Networks

With DNS attacks occurring more frequently than ever — with 88% of organizations reporting some type of DNS attack in 2022, according to the latest IDC Global DNS Threat Report — it's important for organizations to understand how to mitigate and defend against DNS abuse, the researchers said.

One way is to create a dedicated DNS server for the air-gapped network, Gabay tells Dark Reading. However, organizations must take care to ensure that this server is not chained to any other DNS servers that may exist in the organization, as this "will ultimately chain it to DNS servers on the Internet," he says.

Companies should also create anomaly-based detection in the network utilizing an IDS/IPS tool to monitor and identify strange DNS activities, Gabay says. Given that all enterprise environments are unique, this type of solution also will be unique to an organization, he says.

However, there are some common examples of what abnormal type of DNS behavior should be monitored, including: DNS requests to malicious domains; large amounts of DNS requests in very short period of time; and DNS requests made at strange hours. Gabay adds that organizations also should implement a SNORT rule to monitor for the length of requested DNS records.