Global DNS Hijacking Campaign: DNS Record Manipulation at Scale

FireEye’s Mandiant Incident Response and Intelligence teams have identified a wave of DNS hijacking that has affected dozens of domains belonging to government, telecommunications and internet infrastructure entities across the Middle East and North Africa, Europe and North America. While we do not currently link this activity to any tracked group, initial research suggests the actor or actors responsible have a nexus to Iran. This campaign has targeted victims across the globe on an almost unprecedented scale, with a high degree of success. We have been tracking this activity for several months, mapping and understanding the innovative tactics, techniques and procedures (TTPs) deployed by the attacker. We have also worked closely with victims, security organizations, and law enforcement agencies where possible to reduce the impact of the attacks and/or prevent further compromises.

Technique 1 – DNS A Records

The first method exploited by the attacker is altering DNS A Records, as seen in Figure 1.

Figure 1: DNS A Record

1. The attacker logs into PXY1, a Proxy box used to conduct non-attributed browsing and as a jumpbox to other infrastructure.
2. The attacker logs into the DNS provider’s administration panel, utilising previously compromised credentials.
3. The A record (e.g. mail[.]victim[.]com) is currently pointing to 192.168.100.100.
4. The attacker changes the A record and points it to 10.20.30.40 (OP1).
5. The attacker logs in from PXY1 to OP1.
   • A proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.
   • A load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.
6. certbot is used to create a Let’s Encrypt certificate for mail[.]victim[.]com
   • We have observed multiple Domain Control Validation providers being utilised as part of this campaign.
7. A user now visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt certificate allows the browsers to establish a connection without any certificate errors as Let’s Encrypt Authority X3 is trusted. The connection is forwarded to the load balancer which establishes the connection with the real mail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.
8. The username, password and domain credentials are harvested and stored.

Technique 2 – DNS NS Records

The second method exploited by the attacker involved altering DNS NS Records, as seen in Figure 2.

Figure 2: DNS NS Record

1. The attacker again logs into PXY1.
2. This time, however, the attacker exploits a previously compromised registrar or ccTLD.
3. The nameserver record ns1[.]victim[.]com is currently set to 192.168.100.200. The attacker changes the NS record and points it to ns1[.]baddomain[.]com [10.1.2.3]. That nameserver will respond with the IP 10.20.30.40 (OP1) when mail[.]victim[.]com is requested, but with the original IP 192.168.100.100 if it is www[.]victim[.]com.
4. The attacker logs in from PXY1 to OP1.
   • A proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.
   • A load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.
5. certbot is used to create a Let’s Encrypt certificate for mail[.]victim[.]com.
   • We have observed multiple Domain Control Validation providers being utilised during this campaign.
6. A user visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt certificate allows browsers to establish a connection without any certificate errors as Let’s Encrypt Authority X3 is trusted. The connection is forwarded to the load balancer which establishes the connection with the real mail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.
7. The username, password and domain credentials are harvested and stored.

Technique 3 – DNS Redirector

The attacker has also been observed using a third technique in conjunction with either Figure 1 or Figure 2 above. This involves a DNS Redirector, as seen in Figure 3.

Figure 3: DNS Operational box

The DNS Redirector is an attacker operations box which responds to DNS requests.

1. A DNS request for mail[.]victim[.]com is sent to OP2 (based on previously altered A Record or NS Record).
2. If the domain is part of victim[.]com zone, OP2 responds with an attacker-controlled IP address, and the user is re-directed to the attacker-controlled infrastructure.
3. If the domain is not part of the victim.com zone (e.g. google[.]com), OP2 makes a DNS request to a legitimate DNS to get the IP address and the legitimate IP address is returned to the user.