Malware Trivia: Episode 5
Hi there and welcome to a new round of questions and answers on data security. This week’s questions come from Chani, who is concerned with rootkits and DNS poisoning.
How do malware researchers find malware samples and malicious sites?
Keeping up to date with the developments in the malware underground is a critical requirement for the virus researcher. We get malware from different sources, of which the most important ones are:
• Honeypots: unpatched systems without any security measures that are waiting to get infected. This is an effective method of gathering 0-day exploits and Internet worms;
• Malware collection exchanges: malware updates exchanged between the company and other industry vendors and online scanning services;
• Customer reports via the BitDefender forums;
• Proprietary technologies for crawling the web in search of malware;
I have heard that rootkits are very silent and difficult to detect and remove. So how would we come to know that if our computer is infected with it or not?
It is true that most of the malware equipped with rootkits run extremely silent and practically undetectable, but their presence on a system can be revealed through special software. One of the best tools for detecting rootkit activity (or, at least my special favorite) is the freeware application Gmer that can accurately detect rootkit presence and allows you to stop the driver.
However, removing a rootkit from the system is a tough job and needs much more than stopping the rootkit driver. If you find your system compromised, then you probably need an antivirus with anti-rootkit feautres. And, since we’ve got a state-of-the-art antirootkit module, I’d recommend you a 40-day trial of a BitDefender product of choice.
What is DNS poisoning? Is it an infection on a PC?
DNS poisoning is one of the most insidious types of attacks against all kinds of computers, regardless of the operating system they are running. Think of the hosts file as a catalog that associates a specific domain with an IP address, so that commonly-used URLs not to be checked against the DNS server. For instance, one could “hard-code” a domain name (say hotforsecurity.com) to an IP address (say 127.0.0.1) into the hosts file, which will result in all requests to hotforsecurity.com to be passed to localhost. In a real-life situation, an attacker could use a Trojan to stealthily modify your hosts file and point your favorite social network to a different server, where a phishing page is waiting for you to “log-in”.
A new entry in the “hosts” file hijacks hotforsecurity.com to localhost
Now imagine that, since the hosts file is “poisoned”, when you try to access that specific URL in the browser, you won’t notice anything suspicious. This proof-of-concept is just a mild example of what could happen to you when your hosts file gets tampered with. More than that, the rules set in the hosts file apply system-wide, which means that all browsers and applications installed on the system will follow this kind of redirects without asking any questions.
That’s it for today. As usually, I’m waiting for your IT security questions in the feedback form below. See you next Monday.