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.