Rogue DNS Attacks – A less understood hacker attack

The title of this article originally included “…and why you could lose your internet this July”, but that was in Feb. 2012 when I started writing this before that life got in the way.  I’ve left the part about losing your internet but edited it to be more relevant to today.  See the section on “Operation Ghost Click” at the bottom.  These types of attacks are a little better understood these days, but still unknown to much of the public.

The Rogue DNS Attack, a.k.a. “DNS Hijacking” is one of the more misunderstood types of attacks that can open the door for hackers to use all kinds of trickery to steal information you store on or transmit from your computer, like the embarrassing video you took of yourself singing and dancing to MC Hammer wearing your Dad’s very large pants and forgot to delete.  Oh yeah and any password you type into any website.  Even your dog.

What’s that?  You don’t have a dog?  Actually you did… until they stole it.  I guess they also stole your memory of your dog.



To understand them, you first need at least a basic understanding of how DNS servers work.  The short version is that any time you type a website’s name into your browser (, to use an example everyone is thoroughly familiar with.), or click a link, etc. your computer first sends the domain name to a DNS server, which responds with the IP address(es) needed to actually reach the server where the website is hosted.

For a more detailed explanation of how the devices in your network fit together, see my previous post, How Does Your Computer Connect To The Internet?



So in addition to the legit DNS servers you know and love (obviously), there are “evil” DNS servers in the world that would love for you to use their “services” instead.  If your DNS settings were somehow changed to point to one of these Rogue DNS Servers, you’d be in a lot of trouble.  In fact, there’s a possibility you are already pointing to one now and didn’t even know it!  But more on that later.



We’ll start with the symptoms since knowing how to spot it is usually the most important piece.  First, you may notice your browser behaving strangely.  There are a few scenarios that could be involved, some of which may cause noticeable changes in behavior.

Scenario 1: When you open a browser (any browser), and try to go to a website, some other unexpected page comes up.



  • Often this page will claim it has detected spyware or a virus and that you must download some tool to remove it.  Don’t ever download a virus removal tool advertised in this manner.  The “tool” most likely is actually a virus or maybe in rare cases a red herring to distract you from some other attack.
  • Sometimes there is a legitimate reason for the redirect… for example, some public wireless services require you to agree to their terms or authenticate on some local page before they let you get out to the public DNS.  This is (usually) not an attack, but does behave much like one.



Scenario 2: When you are opening webpages you start noticing that although the webpage you requested is opening, the status bar at the bottom of your browser window is telling you it’s requesting data from some website you’ve never heard before and it happens over and over again regardless of what website you browse to.  But you may eventually get to the site you wanted, so it may seem like nothing is wrong.

There is also a third scenario that may not be noticeable at all:

Scenario 3:  Sometimes you will get a certificate error from a site you have visited before.  There are reasons for a certificate error that are less dangerous (company let their certificate expire or your clock somehow got reset to Jan 1, 1970 and the browser wrongly thinks the certificate expired).  Because of this, or because maybe you have to make a bank transaction NOW or update your facebook status NOW people assume it’s not worth investigating and elect to go to the site anyway, or worse, permanently accept the bad certificate.  If you’ve done this, or the attacker really knows what they’re doing, there may even be no noticeable symptoms at all!



I’m glad you asked!  You really do ask good questions.  The first of the scenarios listed above is bad for obvious reasons: it prevents you from accessing the internet, essentially making machines useless for the average user.  But then you just call up a computer repair service. Or like my family does with me, call your computer programmer friend/relative because you think the Geek Squad prices are too high, which is like asking your accountant to do your bookkeeping for you for free even though bookkeeping isn’t really his thing… What were we talking about again?  Oh yeah…

The second and third scenarios are WORSE.  Most users don’t notice anything wrong and continue to browse the web, not realizing that you are being redirected to a fake website posing as the real one (Scenario 2) or pointing to a proxy server which can act like ANY website you requested.  For now, don’t worry about what a proxy server is, just know that there are good ones and bad ones.  And in this case, the proxy server can see everything you input and can see and manipulate the responses you are getting from the requested site.  Attacks like this are known as:



Here’s how a MITM attack works.  Using as an example, you browse to   In the case of a Rogue DNS attack, our computer does it’s DNS request and gets the IP address of a malicious proxy server instead of the real

The proxy server then browses to behind the scenes, pretending to be you, gets the resulting page and forwards it on to you as though it were the real webpage.  It basically pretends to be  This by itself wouldn’t be such a problem (maybe slow your browsing down a bit), except now you think you are pointing to the real and are likely to enter your username and password, which the proxy server is logging so the owners now have your password and possibly everything you saw while you were on the site.

Not only that, but the proxy server, before forwarding the results to you, can also modify these results however they want before sending them back.  For example, if you search for “how to remove a virus”, maybe there are a few known sites that show you how to remove it and it can hide those links from you so you will have a tougher time finding them.  They can also take a file you are downloading (like a bank statement) and replace it with a virus, or inject malicious code into the PDF, etc.  They can even inject malicious javascript into the webpage that your computer will run.  Hope your browser is up to date!

Or put more simply, once you’re pointing to one of these bad proxy servers, there’s an endless number of tricks they could use to steal your identity and remain undetected.

Since your browser thinks you’re talking directly to Google, which you might have listed as a trusted site, it executes the malicious code.  Or even worse, you log into your web-based email site (gmail, ymail, hotmail, etc.) and your browser tells you the certificate provided by the site is invalid, but because you need to get to your email now (or just don’t know any better), you accept the invalid certificate.  Now the malicious site can act as a SECURE intermediary between you and your site, which means they can see your username, password and everything else you input or view on that site even if the site is “secure”, a.k.a. encrypted with an SSL certificate.




There is no way to confirm for sure, because hackers will always try to find ways to outsmart any standard method for protecting against anything.  But for most cases you can do the following:

First, find out which DNS server(s) you are using.



Click  Start > Run  (or if there is no “Run” option, click “Search programs and files”)

Type the following command and press ENTER:


This will open up a “Command Prompt” window.  Type the following and hit ENTER to see your network settings:

ipconfig /all

Find your network adapter and look for the line that says “DNS Servers”


Linux (and probably Mac – I don’t have one to test with):

Open a terminal window if you aren’t already at a shell prompt, type the following and press ENTER:

cat /etc/resolv.conf


Now it can be tough to know if a DNS server is bad just from the IP address.  But if you happen to know what your DNS server was originally and it has changed, this is a bad sign.

If you don’t know what DNS server you should be using, you can try looking up the IP address using the nslookup command (Windows) or host command (Linux – if nslookup not available).


Use a small website, because huge sites like Google, Twitter, Facebook, etc. do complex tricky stuff to handle their massive loads, so doing an nslookup may give you 15 results and those results may change every so often.

Generally when you run this command it will first tell you the DNS server it used, followed by the IP Address(es) of the domain you entered (in this case,

Then, run the command again, except force it to use a known public DNS server.  I generally use the Google public DNS ( or, but it’s a good idea to pick your own from a database of known DNS servers.


Did you get the same results?  If not, chances are the DNS server you were using is bogus.



There are a number of ways this can happen.  Here are the usual suspects:

Attack 1: HACKING YOUR MACHINE – Someone hacked into your computer and changed your settings.  Probably the least common method, unless you make it a habit to piss off hackers.  (Pro tip: don’t be mean to hackers.  They tend not to be forgetful.)

Attack 2: MALWARE – Someone tricked you into running a malicious application and now you have a virus that is hiding behind the scenes and changing your DNS settings to point to this bad server.  Example: DNSChanger

Attack 3: HACKING YOUR NETWORK HARDWARE – Someone hacked into the DHCP server on the network to which you are connected.  They changed the settings of your previously legitimate DHCP server to point to a Rogue DNS Server.  Now the router is broadcasting the rogue DNS server to all machines that connect to it.

Attack 4: ROGUE DHCP SERVER – This is an even more sneaky attack than the above three.  A Rogue DHCP Server does the same thing as your legitimate DHCP server.  Now any new machine that connects to your network will issue a DHCP request as usual to get an IP address and DNS servers, etc., but instead of the usual single response from your legit DHCP server, suddenly there are two responses being sent.  If your machine picks up the bad DHCP response instead of the legit one, it will blindly start using the Rogue DNS server instead of the good one that your ISP recommended.

The first 2 methods can often be prevented using standard best practices for keeping your computer secure like using strong passwords, keeping your software updated, not executing files or clicking links in suspicious emails, etc.



If you are already a victim of this attack, fixing it depends on how you were attacked.

If it was a one-time hack that caused it, and no malware was involved, rebooting your machine, reconnecting to the network or forcing a DHCP request will fix your issue.  Now you just need to make sure you update all your software and passwords so you don’t get hacked again.

If you have malware, this is a more general problem beyond the scope of this article, but the first thing to do if at all possible is IMMEDIATELY DISCONNECT the computer from the internet and do not reconnect it until you have removed the malware. If possible, use another machine for any needed research, downloads, etc.  Most malware is designed to be tricky to clean, so if you don’t have a backup image or can’t restore your machine to factory defaults, you may have to call Geek Squad or your local computer repair place for help.  Or you can try some of the how-to videos on youtube.  Here’s one example.

My next article will get into how attack 4 can happen, and what to do if it happens to you.  I will also detail my experience with a Rogue DHCP Server attack in my office.



A couple extra things I pulled out of the above article because it was getting too long:


I included this because I saw a lot of people posting things in forums where they were going to Google and the search results were redirecting them to bad websites.  Often people were responding saying it’s the “Google Redirect Virus”.  There is an actual virus known as the “Google Redirect Virus”, which is a type of browser hijacking virus.  I even recall some discussions about how this is because Google was hacked, etc.

First off, the number one site on the internet is Google.  Since most people use search engines to find practically all information on the internet that’s not from a social networking site, Google tends to be the most common page many users look at.  There are some people that call this issue the “Google Redirect Virus”.  This is because they notice funny behavior while they are clicking links in their Google search results.  But as you will see the problem has absolutely nothing to do with Google, except for the fact that it is programmed to only spring into action when you use Google.  The same thing could be done for any other site on the web.


The biggest example of this is an Estonian ring of cybercriminals taken down by the FBI in Nov. 2011 in an investigation dubbed Operation Ghost Click.  (witty, huh?)  This ring used a computer virus to infect millions of computers and trick them into pointing to their Rogue DNS Servers.  The FBI seized a large network of these servers, but since shutting them all down would “break the internet” for millions of victims, they replaced the bad servers with legitimate ones, and they referred the public to a webpage that helps you identify if you’re using one of them.

In fact, there was a period of time in early 2012 where the FBI was no longer able to maintain the Legit DNS Servers that replaced the bad ones, and they were planning to shut them all down.  many were worried that all of the remaining victims would lose internet access.  See the CNBC article titled: FBI: Hundreds of Thousands May Lose Internet in July

I wasn’t worried that this would be a major issue, because who do you blame when the internet stops working?  Your evil ISP whose customer service notoriously drives people crazy.  And those ISP’s don’t like outages, even if they’re not really at fault.  So I’m sure their networking geniuses came up with a way of rerouting traffic to known FBI DNS servers back to a legitimate one so that even victims who were still affected would maybe get a warning page or just redirected as if nothing were wrong.

But does this mean Rogue DNS Servers are no longer a problem?  Very doubtful.  There will probably be new ones popping up all over the place.  Ones not among those seized by the FBI.  So even if you aren’t pointing to one of the DNS servers seized by the FBI, you could still be pointing to a Rogue DNS Server.  In fact, when someone at my company had this problem the link above did not detect it.

How Does Your Computer Connect To The Internet?

This is my attempt at briefly and simply explaining how a computer finds the website you type into your browser’s address bar. It’s written as a primer for understanding certain types of hacker attacks that I will describe in an upcoming article.

To connect to the internet, most people, whether they know it or not, use the following devices or some equivalent of each:

1) Modem: in short, this is what physically connects you to the intenet. It takes the signal from your ISP and converts it into a signal the other devices in your home can understand, and vice-versa.

2) Router: think of this as a splicer that takes the single internet connection provided by your ISP and lets you share it among multiple devices instead of just one. It’s usually plugged directly into your modem, or your modem may have the router built in. I believe most routers these days are wireless, but support a few (usually 4) wired connections. But wired routers are still available.

3) DNS Server: Since this is almost never located in your house, this is one of the unsung heroes in the network map. When you want to browse a website, your network needs an IP address so it knows where to send your request. You may have seen these before, they are usually 4 groups of numbers separated by periods. But you don’t know You just know you want to go to (No, really, it’s actually a real site, I just checked!!! …not that I’m surprised.)

To solve this problem, there is a network of “Domain Name System” (DNS) Servers scattered all around the world. You can think of these as computers whose sole purpose in life is to keep track of all the domain names and their respective IP addresses. You tell the DNS server “I want to go to” and without even judging your character, the DNS server responds with “If you would like to visit that site, head on over to, good sir!” Without DNS servers, there wouldn’t be a There would only be And who would want to share embarassing pics and complain about how bored they are to 350 friends on that?

4) Computer (Duh!): You know what a computer is. You probably also know the computer has a network device (usually a wireless card or a wired NIC card) which allows you to communicate with all of these other devices.

But how does your computer (or network device) know what settings to use to connect to the internet??? There’s still one missing piece to the puzzle, and that is:

5) DHCP Server: Your “Dynamic Host Configuration Protocol” (DHCP) server is usually built into your router (which, as mentioned, may also be built into your modem).

The DHCP server is most famous for being the device that “assigns you an IP address”. That is, your router connects to what I call your “external IP address” provided to you by your ISP, let’s say That’s how data you request finds its way back to your network. But how does the router keep track of your computer, your roomate’s computer, your PS3, your Droid and your roommate’s iPhone? The router assigns each device is own “internal IP address” using a DHCP server. (Network geeks use acronyms like LAN and WAN, but let’s keep it simple) It usually looks something like or, etc. Without this internal IP address, there would be no way to tell the difference between data meant for your computer and data meant for your PS3.

Note: There may be a better mnemonic device out there, but if you are having trouble remembering the difference between DNS and DHCP, remember the N in DNS stands for NAME, as in where you send the NAME of the site you want to reach. And the C in DHCP stands for CONFIGURATION, as in where you get the CONFIGURATION for your network device.


The way it works is you (or your friendly neighborhood FiOS guy or equivalent) configure your DHCP server to point to some established DNS server, the IP address of which was likely recommended by your ISP (FiOS, Comcast, etc.). Let’s say it was Your DHCP server now sits and listens for requests from machines that want to connect. When you connect a computer to the network, first if it’s wireless it goes through its little wi-fi authentication song and dance, then a DHCP broadcast message is sent out across the network to everyone who is listening. The DHCP server is listening for this broadcast and upon receiving it, assigns a unique internal IP address to the device and sends a response with that internal IP address

The DHCP server also tells your Computer (and by association, your network adapter), a few other settings to use, including the DNS server specified in the DHCP settings (, remember?). And your stupid (er.. I mean “faithful”?) wireless adapter blindly accepts these settings and begins using them. This is an important detail for understanding rogue DHCP server attacks.

Then, every time you make a request to a domain like, or, your network adapter will first “resolve” the domain name by sending it to the DNS server to find out the IP address for that domain. This is a key detail in understanding rogue DNS server attacks.

Now that you have the IP address, your computer‘s network adapter can send the HTTP request to the default gateway (usually the router), and because you included an IP address, the router, modem and all other devices in between there and your destination will know where to send it.

I will be back later to post some articles explaining how rogue DHCP server attacks and rogue DNS server attacks work and how to detect and remove them. Check back soon!

SQL DML Cheat Sheet for Beginner PHP Developers

I’ve put together a printable, pocket sized (4″ x 6″) SQL quick-reference (cheat sheet).

It was originally designed for developers who are learning PHP and are just learning the basics of MySQL in order to explore adding relational database functionality to their web applications.

Included are basic DML (Data Manipulation Language) syntax and a few additional functions, commands, etc.

Please comment or contact me if you have any questions, comments, suggestions or any other feedback!

Troubleshooting CakePHP installation issues related to Apache 2 mod_rewrite – for beginners

At the BostonPHP CakePHP meetup in Feb. 2010, there seemed to be a lot of people who had trouble getting the Apache rewrite module, also known as “mod_rewrite” to work properly, and therefore could not fully take advantage of the CakePHP framework and its powerful features.

The cookbook (CakePHP’s online documentation) touched briefly on this, but because it seemed like such a universal problem, and because I was not able to find a detailed explanation targeted toward beginners anywhere on the web, I decided to write one myself.

The current article can be found at the Bakery here:…

Below is the original text from my original writeup before I later posted the article on the CakePHP Bakery site (and subsequently edited it…):


If you are able to get your default CakePHP index page to come up after installing, but without the Cake logo in the top left and without the styling, this article should help you troubleshoot the issue.

A common issue when installing CakePHP is that the main index page will come up, but without images and styling, making your page look kind of like a text and-hyperlink-only html page.

The following image is an example of how CakePHP’s homepage should look when you first install it. And it should look this way without touching ANY of the CakePHP files:

Many people after installing can get the page to come up, but it looks more like this:

If you are experiencing this issue, the problem is most likely not with your cake installation, it’s with your Apache configuration… more specifically the problem is that you aren’t using mod_rewrite correctly.

If you are not familiar with mod_rewrite and it frustrates you, don’t feel bad. I’ve installed LAMP servers (and a WAMP server or two) many different ways, through Linux package repositories, compiling PHP, Apache and MySQL individually from source, etc. and I have to say getting Apache to work the way I wanted it to (especially mod_rewrite) was one of the two or three most frustrating things I’ve ever had to deal with in my programming experience.

What is mod_rewrite, you ask? Here’s my quick explanation: mod_rewrite is an Apache module (a piece of Apache you can enable or disable) that basically allows the server to “rewrite” the URL you type into your browser behind the scenes… as well as rewriting any URL’s referenced within the HTML source of the page. You can’t see the rewritten URL’s in your browser’s address bar. Without this, you wouldn’t be able to use the MVC-friendly URL’s CakePHP is designed to use.

mod_rewrite is most likely enabled in your Apache configuration file, usually called httpd.conf (httpd is the name of the daemon process that is the Apache server, so as far as we’re concerned httpd=Apache) The rules for this rewriting are defined in the .htaccess files included with CakePHP.

CakePHP also expects you to configure Apache such that the “DocumentRoot” points directly to CAKEROOT. MAMP, WAMPServer, XXAMP, etc. do NOT do this by default. They usually have a directory called www, public_html, webroot, httpdocs, or something like that and the “DocumentRoot” points there by default. They (*AMP) expect you to either put your website there or in a subdirectory.

Cake’s .htaccess files are written on the assumption that your DocumentRoot points directly to your CAKEROOT directory. While you CAN make CakePHP work in a subdirectory of your DocumentRoot, it requires changes to .htaccess files and maybe even cake config files or index files, etc. And you may run into other issues later when trying to follow instructions that assume you have it working. So if you’re just interested in learning CakePHP, do not waste your time trying to figure out how to bypass mod_rewrite unless you REALLY have to.


STEP 1) Check for the .htaccess files and make sure they are readable.

Files starting with a “dot” like .htaccess are usually hidden by default. Depending on how your machine is set up, these hidden files can be ignored when copying, especially if you are using a file browser and you have it configured to hide hidden files (usually the default setting).

The safest option is to unzip, untar, etc. in the CAKEROOT folder, but regardless of how you do it, check to make sure the .htaccess files are there and make sure they have the proper permissions so they can be read by the server.

You should be able to find a file called .htaccess in each of the following locations:


If you decompressed (unzipped, untarred, etc.) a cake archive you downloaded from the CakePHP site and did so directly in the CAKEROOT directory, these files should all be in place.

If you decompressed an archive, then COPIED the files, especially if you did it using a graphical program like Windows Explorer (of Finder for Mac, someone correct me if I’m wrong), then it’s entirely possible that the files did not get copied.

If you don’t want to manually check for each one you can open a command prompt, preferably as user “root”, navigate to the CAKEROOT directory and run the following command:

find . -name .htaccess

This should spit out a list of .htaccess files similar to the one I gave above.

If the files are there, double check to make sure they have the correct file permissions. If they can’t be read by the server, they won’t be picked up. From the command line, navigate to the CAKEROOT directory again and run the “list (long)” command:

ls -l .htaccess

You should see something like this:

-rw-rw-r– 1 root users 139 2010-01-29 21:54 .htaccess

In this case the file is readable by everyone because there are 3 r’s. If you see this, move on to STEP 2.

If you want to understand how file permissions in UNIX-like systems work, go here:

If you do not see 3 r’s, assuming you or root has the privileges needed to modify the file, you can fix this by going to each folder that has an .htaccess file and running the following command:

chmod a+r .htaccess

STEP 2) Find your apache configuration file(s)

I know WAMPServer has a system tray icon you can click through to get to the httpd.conf. I assume MAMP, XXAMP, etc. are similar, but not identical.

If you do not know how to access your Apache configuration files, start by checking the documentation for whatever server software you are using (MAMP, XXAMP, WAMP, etc.) because although they all seem pretty similar, they are most likely not all the same.

Keep in mind the following rules (at least the ones I’m aware of) about Apache configuration files:

-Since *AMP servers are designed to make server administration more simple, it’s usually called httpd.conf, but it DOESN’T HAVE TO BE.
-It can actually be more than one file… you can include other config files from within httpd.conf.
-If you find a file called httpd.conf, it doesn’t necessarily mean it’s the one being used… there are situations where you might have more than one httpd.conf in your system.

So again, your *AMP documentation is your best bet for finding the correct file. Once you know how to access the correct file (or files), note it down somewhere. You will need this later.

STEP 3) Find out if mod_rewrite is enabled.

The easiest, most definitive way to find out if mod_rewrite is enabled on your server, if you can get it to work, is to find your CAKEROOT/index.php file and add the following line of PHP code somewhere:


Then when you open your cake page again, you will see the PHP Info page first, followed by the broken cake page like the pic above. If you can get this to work, this will make it WAYYYYYYY easier to troubleshoot your Apache issues. Therefore I will make this the one exception to my earlier rule about not modifying the cake files until you get Apache working properly.


About 3 tables down or so in your PHP Info page (the contents of this page varies depending on your php build an php.ini settings) look for a table called “apache2handler”. Towards the bottom of the table you should see “Loaded Modules”. Somewhere in that list you should find mod_rewrite. If you DO NOT find it, mod_rewrite is NOT enabled. Remember this…. we will go over what to do about it later in the post.


You can also find out what your true DocumentRoot is by looking at this PHP Info page. A little further down, there will be a table entitled Apache Environment. Find the DocumentRoot field and remember the value you see there. This will also come in handy later.

IF FOR SOME REASON YOU CAN NOT GET THE PHP INFO PAGE TO DISPLAY, you will have to make sure you are sure about which Apache configuration file or files are being used and go on to STEP 4.


Check that you have the following set up in your Apache configuration file(s) (from STEP 1)

Search through them for the following lines:

This line loads the driver/library for the rewrite_module (another name for mod_rewrite):
LoadModule rewrite_module libexec/

This line ENABLES the rewrite_module:
AddModule mod_rewrite.c

This line sets the DocumentRoot of the server. This can be in multiple places, so make sure you know where all of them are:
DocumentRoot CAKEROOT

If any of these lines are not there or are preceded by a hash (#), then you need to add them or remove the hash.

When making changes to files like this, don’t forget to take measures to make sure you can roll back your changes if needed. Remember the following guidelines:

1) Do not touch the file until you have made a backup copy of the file.

For example, I recommend you copy httpd.conf to something like httpd.conf.20100220. (today’s date stamp) so later on you can find the latest working copy if you break something else and need to quickly roll back.

2) Never delete or change any existing code in the file, always comment it out. In apache configuration files, you do this by preceding the line with a hash (#).

3) You should also add a comment on the previous line with a note about what you changed and when (and if you really want to be careful, the reason why). Include your name in case your project ever becomes collaborative.


#Modified by Bobby 2/20/2010 for the CakePHP tutorial
#DocumentRoot “/some/wrong/root/folder”
DocumentRoot “CAKEROOT”

#Added by Bobby 2/20/2010
LoadModule rewrite_module libexec/

#Removed by Bobby 2/20/2010 to prevent overlap
#Alias /cake/ “CAKEROOT/app/webroot”

STEP 5) If you made changes to the Apache configuration files in STEP 4, RESTART APACHE. You’d be surprised how many people forget this.

If you do not know how to restart Apache, refer again to your *AMP documentation. It may vary from version to version.

Now your CakePHP homepage should load correctly and you are now ready to continue with the tutorial.

If you still can’t get it to work, the CakePHP Cookbook has some info about how to use Cake’s “Pretty URL’s”. Go here:

If you have any questions/comments/corrections, either post a reply or message me directly.