top of page

GhostDNSbusters (Part 2)

Illuminating GhostDNS Infrastructure

This research was undertaken in collaboration with Manabu Niseki (@ninoseki on Twitter) and (

Manabu is a Tokyo-based researcher who has been tracking GhostDNS for a number of years. His leads and insight into GhostDNS assisted in confirming the findings documented in this blog post.

We will continue to collaborate with on a shared goal of identifying the threat actors operating the infrastructure detailed in this blog.

This post picks up where we left off in our September 8, 2020 blog post titled “GhostDNSbusters”. In that post, we identified:

  • IP addresses being used by miscreants to compromise home routers

  • IP addresses of rogue DNS servers

  • Domain names affected by those DNS servers, directing users to phishing pages

This post will provide details on newly identified GhostDNS infrastructure, provide information about the phishing servers in use, and enumerate additional domain names targeted by miscreants.


During the process of identifying active GhostDNS-related infrastructure, we observed several distinct “groups” of servers. Most involve a single DNS resolver and a single HTTP server used to host the phishing pages. However, one group uses six different DNS resolvers and two HTTP servers, and changes the HTTP servers on a weekly basis.

Internal Name

Timeframe Observed

DNS Server(s)

HTTP Server(s)


Wildcard DNS?


14-MAY – current

Two, which rotate each Monday.

For the week of Oct 5:




18-AUG – current




12-SEP – current




10-SEP – 23-SEP




08-AUG – current



Table 1: List of recently active GhostDNS infrastructure

The bottom four groups shown in Table 1 are configured in a similar way. Each has a single DNS server, which acts as authoritative for a distinct list of targeted domain names. When the domain name, or select hostnames within them are queried, the servers respond with the IP address of their associated phishing HTTP server. That response has a “time-to-live” of 10800 (measured in seconds, which is three hours).

For example, here are some example queries and results from the “EDA” group, starting with one of the targeted domain names:

Figure 1: Example query for a domain poisoned by the “EDA” DNS server

A query for the “www” hostname within that domain will also point to the phishing IP address:

Figure 2: Example hostname query for a domain poisoned by the “EDA” DNS server

However, DNS wildcards are not used by this group, as seen here:

Figure 3: Example NXDOMAIN query for a domain poisoned by the “EDA” DNS server

In the figure above (Figure 3), we see that the “” query isn’t directed to the phishing server. Instead, a NXDOMAIN response is returned, which indicates that the hostname does not exist. (In reality, that hostname does exist, but since this DNS server is (maliciously) configured to be authoritative for the zone (domain), but doesn’t contain a record for the “img” hostname, and isn’t configured to perform DNS wildcarding, it returns an NXDOMAIN response.)

In contrast to the behavior observed by the other infrastructure groups, the CDD group takes a different approach. For all DNS zones that the DNS server is configured to answer authoritatively for, any hostname query will return a response with the IP address of a phishing HTTP server. Here’s an example:

Figure 4: Example wildcard response for a domain poisoned by a “CDD” DNS server

Also unique to the CDD group (compared to the four others mentioned in this blog post) are the weekly rotation of phishing servers, and the availability of SSL/TLS on them. CDD’s phishing servers have a self-signed x.509 certificate that is reused when they rotate in new phishing servers. The x.509 certificate in use recently changed, presumably because it was due to expire soon.

Certificate observed prior to 2020-09-24:

subject= /C=BR/ST=SAO PAULO/L=OSASCO/O=Google. Inc./OU=Principal/CN=SAY MY NAME/

issuer= /C=BR/ST=SAO PAULO/L=OSASCO/O=Google. Inc./OU=Principal/CN=SAY MY NAME/


notBefore=Oct  8 23:28:42 2019 GMT

notAfter=Oct  7 23:28:42 2020 GMT

MD5: FCB3ECAA96C6A9026CD933281A30551F

SHA1: 4E04C2D45F37D7D4E757C27A0A0735B503F319E4

Certificate observed after 2020-09-24:




notBefore=Sep 24 19:44:55 2020 GMT

notAfter=Sep 24 19:44:55 2021 GMT


SHA1: 8D9B394BA67D1913566115094C1AD0257FEFF26E

This reuse of x.509 certificates allows us to identify new and historical phishing servers used by this group, as we can use Augury to show us where/when this x.509 certificate has been observed.


Similar to the earlier blog post in this series, Passive DNS (PDNS) and DNS Query datasets from Augury were utilized in order to provide further context around the nature of the requests being targeted by the attackers – for which their rogue DNS servers provide redirects to phishing pages. Each group has a unique list of domains that are hijacked. The following is a list of targeted domain names in use by recently-active GhostDNS servers, broken down by the “Internal Name” indicated earlier in this article:






Table 2: List of domains targeted by each active GhostDNS infrastructure


Here, we show a snapshot of the real Web site for, as it appears in Internet Explorer 11:

Figure 5: Snapshot of the resulting page when typing “” into IE11 and pressing Enter

We did not specify HTTPS when accessing the page – we simply typed into the address bar and pressed Enter. As seen in the above screenshot (Figure 7), the address bar shows that we were taken to an SSL-encrypted URL. Also, because the address bar is highlighted in green, we know that the SSL (x.509) certificate presented for this session is a valid, EV certificate, issued by a trusted certificate authority.

When the same action (typing into the address bar and pressing Enter) is taken, but using the phishing server in use by the “EDA” group, the result is a non-encrypted page, using an outdated background, copied from the site:

Figure 6: Snapshot of the page, as served by the “EDA” group phishing server

As seen in Figure 8, the page served by the “EDA” phishing server does not show an SSL-enabled connection in the address bar. A similar experience is observed when performing the same action, but using the “CDD” group phishing server:

Figure 7: Snapshot of the “” page, as served by the “CDD” group phishing server

When using a URL that specifies SSL (HTTPS), the “EDA” phishing server doesn’t respond, as the server is not listening on the port used by HTTPS (443/tcp).

Figure 8: Snapshot of attempting to access, via the “EDA” group phishing server

Attempting to access the same (HTTPS) URL when using the “CDD” phishing server will cause an SSL certificate mismatch error to be displayed in the browser, as seen here:

Figure 9: Snapshot of attempting to access, via the “CDD” group phishing server


NOTE: This list contains GhostDNS-related DNS server and HTTP server IP addresses, as identified as active at some point between our previous GhostDNS blog post (September 8, 2020) and this one. Earlier indicators of compromise are available at the end of that blog post.

Rogue DNS servers [10]

HTTP Phishing servers [13]



bottom of page