The other day I was looking at some malware that was interesting because it employed a strategy that allowed it to avoid a hard-coded IP address for the callback domain without being susceptible to DNS filtering. The program would first attempt to resolve the malicious domain name using the host’s built in DNS resolution, but if that failed the host would then open a UDP connection on port 53 to a public DNS server and resolve the host directly. Read on for more details.
I was looking at a new malware sample that beaconed to www.*****.com. I then used FakeNet’s NXDomain feature in order to try to tease out all the possible callback domains, which is when I saw something interesting. I saw the following network traffic.
- A DNS lookup to 127.0.0.1 (the local DNS server) for domain www.****.com
- A DNS lookup sent to a hard-coded IP address of 220.127.116.11 for the same domain name.
- A HTTP beacon to a different hard-coded IP address #.#.#.#
The first connection was a pretty straight forward beacon to the primary callback domain. It was the second connection that interested me. My first thought was that the malware had changed the local DNS configuration to point to a malicious server. Malware often changes the local DNS settings so that it can redirect web requests on the victim and display ads or download more malware. But when I looked at the local DNS settings they hadn’t actually been changed by the malware. I did a quick google search on 18.104.22.168 and it revealed that this is a public DNS server.
At this point I figured out what was going on with the malware. The malware would attempt to beacon back to the callback server. If the local DNS server was blacklisting the domain, then the malware would attempt to resolve the domain using the public DNS server which theoretically wouldn’t have blacklisted the domain. The third and final connection was to the hard-coded IP address as a last ditch attempt to reach the malicious callback domain.
I looked at the malware in IDA Pro to confirm and I saw that the malware first uses getaddrinfo() to look up the malicious domain. If that fails then it opens a UDP socket using winsock and crafts a DNS request and parses the response in order to bypass any host-based DNS settings. This allows the malware to use a domain name without being susceptible to DNS filtering.
Accessing public DNS servers from internal hosts on a corporate network shouldn’t be necessary and should be blocked and I’d be interested to know how often this type of traffic is allowed in a corporate network. Unless you’re using external DNS servers as backup, only the DNS servers should be able to send outbound DNS requests. If your network access controls are well configured then the technique used by this malware should fail because internal hosts can’t send DNS requests to any external addresses. This seems pretty straightforward to me, but I’ve never run a network. Feel free to chime in if you have run a network and think that blocking internal hosts from accessing external DNS is problematic.