Posey's Tips & Tricks
How To Deal with a DNS Poisoning Attack
When antimalware software isn't up to the challenge, it's time to take care of the problem manually.
I recently wrote a column explaining how I had experienced problems accessing Google from the Edge browser, in spite of the fact that other browsers had no trouble accessing Google. I don't want to completely rehash the article, but the short version is that I found and removed a piece of malware, but was still unable to access Google. That being the case, I manually forced Google access by modifying my PC's Host file.
After writing that column, I discovered that the inability of the Edge browser to access Google is a known bug associated with Windows 10 Insider Preview Build 14986. Although my solution to the problem works, many of the people who have discussed the issue on Microsoft's site have gotten around the problem by using the InPrivate browsing option.
Needless to say, I was relieved to discover that my inability to access Google was related to a known bug, and I was happy to have found a way around the problem. Even so, I wanted to go back and talk about a concept that I only briefly mentioned in my original post.
In the post, I said that I initially suspected that my inability to access Google might be related to a DNS poisoning attack. A DNS poisoning attack in a technique used by some forms of malware to redirect Web requests to malicious Web sites. For example, a request to access Google might be redirected to a site that infects the PC with ransomware. Given the potentially serious consequences to DNS poisoning, I wanted to spend a bit of time talking about how DNS poisoning works and how you might be able to fix the problem.
Now obviously the first thing that you should do if you suspect a malware infection is to run an antimalware scan to see if your antimalware software can detect and remove the problem. It has been my experience, however, that some of the more popular antimalware utilities either overlook or do not completely fix DNS poisoning. In fact, I have had to manually correct many such infections for friends and family.
So with that said, the first thing that you need to know is that every malware infection works differently. What I am about to show you should help point you in the right direction, but it won't fix every type of DNS poisoning attack.
If you are going to manually recover from a DNS poisoning attack, the first thing you should do is to unplug the PC's network cable or disconnect its Wi-Fi connection. You don't want the PC downloading any more malicious code while you are working on fixing the problem.
Once you have disconnected the PC, it's time to get down to business. The key to a DNS poisoning attack is to redirect Windows' name resolution process. The Windows operating system actually uses several name resolution mechanisms, most of which are leftovers from the early days.
When Windows attempts to resolve a name, it first checks to make sure that the name is not its own. After doing so, it checks the Hosts file. As you may recall, I used the Hosts file to correct my Google access problem. The reason why I did that was because the Hosts file is one of the first mechanisms that Windows uses when resolving host names. It is also a popular target for malware authors.
If Windows is unable to resolve the host name through the Hosts file, it resorts to using DNS. If DNS doesn't work, then the operating system resorts to using NetBIOS.
The order in which these mechanisms are used is controlled by the Windows Registry. As always, you should back up your PC before editing the registry, because making a mistake could destroy your operating system.
With that said, I recommend opening the Registry Editor and going to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. As you will recall, the system begins the name resolution process by checking to see if the host name is its own. The system's host name is stored in the HostName key, as shown in Figure 1.
The next thing that the operating system checks is the Hosts file. In Windows 10, the Hosts file is located at C:\Windows\System32\Drivers\etc. By default, every line in the Hosts file should be commented out (via the pound sign), as shown in Figure 2.
As previously mentioned, the name resolution order is controlled by the registry. You can verify the name resolution order by going to HEKY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider. As you can see in Figure 3, there are entries for DnsPriority, HostsPrioroty, LocalPriority, and NetbtPriority. Each of these priorities is assigned a numeric value lower numbers reflect a higher priority. Hence LocalPriority (499) is of higher priority than HostsPriority (500). You can see what this looks like in Figure 3.
As far as DNS name resolution goes, there are two main things that you can do without getting too deep in the weeds. First, check your IP address configuration to make sure that your PC has not been configured to use a rogue DNS server. Second, clear the DNS cache to get rid of any potentially malicious entries. You can do this by opening an elevated Command Prompt window and running to command shown in Figure 4.
Removing a DNS poisoning infection is more art than science. Every infection is different, and must be dealt with differently. If at all possible, you should try to clean an infection by using antimalware software before attempting a manual removal.
Brien Posey is a seven time Microsoft MVP with over two decades of IT experience. As a freelance writer, Posey has written many thousands of articles and written or contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. When He isn't busy writing, Brien Posey enjoys exotic travel, scuba diving, and racing his Cigarette boat. You can visit his personal Web site at: www.brienposey.com.