Change your router’s login information

As a bit of an extension from an earlier post, I’d just like to reiterate the importance of changing the default login information for your router (or your customers’ routers).  I’ve seen another uptick in DNS-Changer/DNS Hijack activity which includes the modification of router DNS settings to include malicious IP addresses, most of which hail from within the Russian Federation.

There is an easy way to correct this.  For starters, obviously, you need to ensure your router isn’t infected.  If the DNS settings have been changed, blank them out, then follow it up with a new username/password for your router.  It doesn’t need to be anything complex; even simply changing it to anything else will do the trick.  The malware responsible aren’t brute forcing the passwords or anything like that; they’re simply leveraging knowledge of the default login info for each router model to weasel their way into the settings and add their own DNS information.

It also goes without saying that all client PCs need to be clean before making the change, lest the settings will be reversed by any active malware on the network after you change them.  It is possible to change the login info first, and then blank out the DNS settings if you’re unsure which machine is causing problems and you just wish to prevent propagation of the malware/further information theft.  But this must be done from a clean machine.

Many ISPs will warn users if they’re affected by such DNSChanger infections.  By cleaning the malware off the PCs and checking the routers, you can ensure the problem is resolved.  However, there is one final setting to check:


This registry value will often be modified to include the same malicious DNS servers.  Be sure to check it on each machine, lest a clean machine can quickly become infected once again!

“Infected” routers threaten death by DNS

Recently, I took delivery of a client’s PC which had been thoroughly scanned, but he was concerned that it might not be fully clean.  If you’ve followed my work, you already know that this is relatively common; scanners, for all their merits, can only access what they’re allowed to access, and they can only detect what they’re written to detect.  Even heuristic detection can only go so far, and with today’s polymorphic malware (a.k.a., malware which changes its form with every specimen), signature-based detection is hardly reliable for the ever-common zero-day threats.

Such was indeed the case with this client’s computer, which was indeed still infected, regardless of clean scans by Symantec, Ad-Aware, and other utilities.  Although nothing had identified them, they were almost certainly a new variant of the Trojan.Tracur family of malware.  Previous versions of the Trojan have been known to create copies of local system services, using legitimate descriptions for legitimate services and even the same names—just suffixed with the number “32”.  Normally it drops related files in the system32 directory, but this variant actually had created its sister files inside \ProgramData over 30 of them, one for nearly every single service on the system.

But that isn’t the subject of this blog post.  More interesting was the phone call I received once this client had taken their PC back home and begun using it again: he was still having problems, he told me.  Web sites were loading with weird formatting, and when using Chrome, login attempts at popular sites popped up another window prompting a second login.  The behavior sounded very similar to what some rootkits attempt to steal passwords and financial data.

This situation might not sound strange, but you have to understand: I never return infected computers.  I had performed the same rigorous inspection on his before calling him to pick it up, including a full analysis of all OS loading points, drivers, services, and the master boot record of the system drive.  I also check for policies, malicious proxies, faulty DNS caching, and infected critical system files—nearly all of this manually, using tools which I have specially developed for the task.

So I wasn’t convinced that malware was still on the PC—but I was concerned that perhaps we were missing something else.  I reviewed his logs (of which I keep detailed copies for every client) and found no signs of any danger, so I began considering other possibilities.  What else could possibly be the problem?  His router.

Router infections are nasty little things.  Technically, they aren’t infections, but rather, corrupted settings (thanks to malware) which lead to compromised PCs and information. They aren’t necessarily new; this has been a trend which actually started a couple of years ago and has become increasingly common among malware.

It’s actually pretty simple how they work: once a client computer has been infected, the malware takes advantage of the fact that no one ever changes their default router password.  Equipped with this information, it accesses the router configuration and changes the DNS servers to malicious servers of its own, which can filter and steal traffic passing through them or even redirect users to altogether different sites when they request a page.  This can be made entirely transparent to the user, as the displayed web address (the so-called FQDN) is still the same—only the resolved IP address has changed.

It isn’t uncommon for such router infections to reinfect clients even after they’re cleaned, presenting a seriously hazardous situation.  The solution involves simultaneously performing a hard reset on the router (by holding down the reset button for 15 seconds or longer) and disinfecting the PC (and all affected PCs on the network) before connecting back to the router.  Following that, the network must be reconfigured on the router, and a password needs to be set to prevent future infiltrations.

In my client’s case, there really wasn’t any proof that this was what was happening with his PC, but it was the next logical step after rechecking his PC remotely using some log-generating deep system scanning software.  So we reset the router, which seemed to resolve the internet traffic issues.  However, the problems with Chrome persisted, even without any extensions installed.  Given the options, we eventually elected to uninstall Chrome, chalking up the additional problems to a possible unknown bug in the browser itself.  Case in point: no other browsers, including Mozilla Firefox, had the same issue.  Just to be certain, I rechecked all proxies, the master boot record, and system files.  The PC was indeed 100% clean, and my client was happy.