Sunday, February 6, 2011

Domain Hacking

In this post I will tell you about How the Domain names are hacked and How they can be protected. The act of hacking Domain names is commonly known as Domain Hijack ing . For most of you, the term “Domain Hijack ing ” may seem to be like an alien. So let me first tell you what Domain Hijack ing is all about.

Domain Hijack ing is a process by which Internet Domain Names are stolen from it’s legitimate owners. Domain Hijack ing is also known as Domain theft. Before we can proceed to know How to Hijack Domain names, it is necessary to understand How the Domain names operate and How they get associated with a particular web server (website).
The operation of Domain name is as follows
Any website say for example consists of two parts. The Domain name ( and the web hosting server where the files of the website are actually hosted. In reality, the Domain name and the web hosting server (web server) are two different parts and hence they must be integrated before a website can operate successfully. The integration of Domain name with the web hosting server is done as follows.
1. After registering a new Domain name, we get a control panel where in we can have a full control of the Domain .
2. From this Domain control panel, we point our Domain name to the web server where the website’s files are actually hosted.
For a clear understanding let me take up a small example.
John registers a new Domain “” from an X Domain registration company. He also purchases a hosting plan from Y hosting company. He uploads all of his files (.html, .php, javascripts etc.) to his web server (at Y). From the Domain control panel (of X) he configures his Domain name “” to point to his web server (of Y). Now whenever an Internet user types “”, the Domain name “” is resolved to the target web server and the web page is displayed. This is How a website actually works.
What happens when a Domain is Hijack ed
Now let’s see what happens when a Domain name is Hijack ed. To Hijack a Domain name you just need to get access to the Domain control panel and point the Domain name to some other web server other than the original one. So to Hijack a Domain you need not gain access to the target web server.
For example, a hacker gets access to the Domain control panel of “”. From here the hacker re-configures the Domain name to point it to some other web server (Z). Now whenever an Internet user tries to access “” he is taken to the hacker’s website (Z) and not to John’s original site (Y).
In this case the John’s Domain name ( is said to be Hijack ed.
How the Domain names are Hijack ed
To Hijack a Domain name, it’s necessary to gain access to the Domain control panel of the target Domain . For this you need the following ingredients
1. The Domain registrar name for the target Domain .
2. The administrative email address associated with the target Domain .
These information can be obtained by accessing the WHOIS data of the target Domain . To get access the WHOIS data, goto whois.Domain, enter the target Domain name and click on Lookup. Once the whois data is loaded, scroll down and you’ll see Whois Record. Under this you’ll get the “Administrative contact email address”.
To get the Domain registrar name, look for something like this under the Whois Record. “Registration Service Provided By: XYZ Company”. Here XYZ Company is the Domain registrar. In case if you don’t find this, then scroll up and you’ll see ICANN Registrar under the “Registry Data”. In this case, the ICANN registrar is the actual Domain registrar.
The administrative email address associated with the Domain is the backdoor to Hijack the Domain name. It is the key to unlock the Domain control panel. So to take full control of the Domain , the hacker will hack the administrative email associated with it. Email hacking has been discussed in my previous post How to hack an email account.
Once the hacker take full control of this email account, he will visit the Domain registrar’s website and click on forgot password in the login page. There he will be asked to enter either the Domain name or the administrative email address to initiate the password reset process. Once this is done all the details to reset the password will be sent to the administrative email address. Since the hacker has the access to this email account he can easily reset the password of Domain control panel. After resetting the password, he logs into the control panel with the new password and from there he can Hijack the Domain within minutes.
How to protect the Domain name from being Hijack ed
The best way to protect the Domain name is to protect the administrative email account associated with the Domain . If you loose this email account, you loose your Domain . So refer my previous post on How to protect your email account from being hacked. Another best way to protect your Domain is to go for private Domain registration. When you register a Domain name using the private registration option, all your personal details such as your name, address, phone and administrative email address are hidden from the public. So when a hacker performs a WHOIS lookup for you Domain name, he will not be able to find your name, phone and administrative email address. So the private registration provides an extra security and protects your privacy. Private Domain registration costs a bit extra amount but is really worth for it’s advantages. Every Domain registrar provides an option to go for private registration, so when you purchase a new Domain make sure that you select the private registration option.

How to set up a phising website !

I realize that we’re probably going to get flagged for this big-time, but just to clear things up: this may not necessarily be strictly for malicious purposes, nor is it intended to be (the full disclaimer is at the end of this article). This is a simple guide for setting up a phishing website using strictly free software, intended as both educational and even useful in some circumstances.

The Required Software

We will be using this software for this guide:

Apache Configuration

The crux of this tutorial centers around configuring Apache to “be” a certain website. For this example, we want to masquerade as Google. The first step is to configure Apache to pretend to be the site we wish to masquerade as, from the machine destined to be the phishing server.

The Apache master host configuration file (which is the traditional/deprecated httpd.conf within your installation directory) should have sections such as this for each website you wish to masquerade as:

(note that the paths are relative to a Unix/Linux installation; modify them for your system; comments are everything after the ‘#’ character for clarification)

 NameVirtualHost: *:80 # Any hostname/IP, TCP port 80 (default for HTTP)  # Virtual Host delimiter, e.g. a website under this installation ServerName # main website name ServerAlias * # Any other name for DocumentRoot /var/www/google # where the fake website's pages are stored  # Per-directory configuration directives                 Options FollowSymLinks MultiViews                 AllowOverride None                 Order allow,deny                 allow from all # we phish for anyone, you could modify this for only select hosts, however  CustomLog /var/log/apache2/google.log combined  # log the visits to the fake website 

With Apache’s httpd.conf containing that, and optionally some other Apache optimization within the other configuration files, a service restart will make the fake site (Google in this case) “live”, but without any content or visitors.

Appearing as the intended site

In our configuration file, we told Apache that any requests for “” from our server should be directed to the “/var/www/google” directory for content (which should be empty). In order to appear as Google to the visitors we wish to phish, we need Google’s content within this directory.

The easiest way to retrieve content from the existing website is via the “wget” command, which is standard on Linux/Unix installations (Windows users can simply visit the page and save it directly to the content folder instead). For our example, our wget command:

user@Phisher:/var/www/google$ wget -O index.html

…would retrieve Google’s home page and store it within the file index.html within the content directory used by Apache2 for requests made to “” to our server. Keep in mind that “index.html” is (by default) the file sent to the users’ browser when a request is made to the root directory ‘/’ of a site.


Before we get to the step of directing users to our instead of Google’s, we should modify the site’s content so we can retrieve (phish) the content we want.

This is where this could easily turn malicious, and I would like to remind you, dear non-malicious reader, of the extensive disclaimer at the end of this article.

As a non-malicious example, we will pretend we are a parent seeking to monitor Google searches from a network of children (a very probable and applicable scenario). All that is required is a little modification of the index.html file, and/or creation of a Google-compliant search.php file.

Although the access logs for the server would suffice (providing IP information to identify the searcher), you will still probably want to return real Google results so as to convince the visitors that this is the real Google website.

Modifying the “form” HTML element to point to an alternative search processing file may be necessary, while in most cases it would suffice to create your own “search.php” file (with the Apache PHP module installed) to process search queries and retrieve results from Google.

Easiest way to retrieve search queries from Google is probably to pass the query string from your phishing site’s search.php as HTTP POST data to, and using some simple XML parsing and formatting to present the results in a results page that exactly mimics Google’s.

That last bit requires a bit of PHP/Perl programming skill (over the head of most parents I know), and represents the biggest challenge in phishing: changing the pages to get what you want.

Redirecting Visitors To Your Site

At this stage, your Apache server installation should be set up and ready to serve up requests aimed for the site you’re masquerading as, and it the content for the site should be filled with content that looks exactly like the real site, only providing you with the data the user thinks they are entering on the real site.

Now, for the process of sending users to your site instead of the real one: simple DNS manipulation.

DNS Re-cap: The Internet’s DNS (Domain Name System) is the process of translating a domain name (e.g. into a routable IP Address, e.g. or As Apache’s virtual host system permits, multiple domain names can resolve to the same IP Address for the serving of separate web (HTTP) content.

In short, you need to make your target machines manually resolve “” (as in our example) to the IP address of your phishing server.

This means that you can’t make the entire Internet redirect a given domain name to your site, at least not without severe and easily-detectable DNS hijacking. Instead, you should focus on your target set of hosts, i.e. the children in our parenting example we explained earlier.

To do this manually, you must modify the host file of each system. The host file is a manually-editable “database” of domain names and their corresponding IP addresses, and takes authority over DNS queries to a remote system.

On Windows systems, this file is located at “C:\Windows\System32\drivers\etc\hosts”, and on Linux/Unix/Macintosh systems this file is at “/etc/hosts”. The format is extremely basic, with examples in both as to how to statically enter DNS entries.

On Windows systems, after entering this information, it is necessary to execute the command “ipconfig -flushdns” to clear the memory-cached DNS resolution entries so the new changes can take effect.

While this method works, it is not practical for, says, 5-100 hosts. In that case, it is then necessary to simply add a real DNS server to the network using one of the free tools mentioned above. I won’t go into detail as to configuring an individual piece of DNS server software to resolve a domain to your phishing server’s IP (RTFM), but I will tell how to make the server’s resolutions take effect for the whole network.

Most networks, especially those within homes, have a DHCP server, many times integrated into their router. Simply place the IP Address of your new rogue DNS server (presumably the same as your web server) to the top of the list of DNS servers within your DHCP parameters, and following the next renewal, your server will take the top authority for DNS resolutions for your network (other than the host file).

There is also a way to, using a *nix router, manually route all traffic to a host for processing – see theUpside-down-ternet page for these details (and for a guide to dick around with wardrivers).

What you’ve done…

…is this: everytime someone requests (in this example), either a rogue DNS server you set up or a host’s host file will resolve the domain name to the IP address of your phishing server, which will accept the request and serve up content from a directory containing content that appears as the targeted site, only with some other purpose for your benefit.

There may be other ways to set this up, but this is certainly the fastest. Keep in mind that if your server goes down, all queries will still go to the real site unless you de-listed all DNS servers except the rogue one you set up.

Other Suggestions

Instead of drastically modifying the content for your site, for example if you wish to simply have a static web history via access logs, then you could simply make your rogue DNS server (via wildcards) resolve alltraffic to your phishing server, which simply retrieves the target content via wget and serves it to the client.

To accomplish this proxy solution, you would need to modify the VirtualHost directive to make the 404 (not found) error page the same page as the “index.php” page, which calls and processes the wget script (I recommend using stdout to redirect the content from wget to the browser as opposed to saving every piece of content to a file before serving it)

Also, please note that none of this guide applies to secure (HTTPS) websites. HTTPS communication takes place on port 443 instead of port 80, and there is a solid authentication process for verifying secure sites as opposed to insecure sites.

* Disclaimer *

Don’t use this guide for malicious purposes, despite how easily this guide could be adopted for such goals. The example I used throughout the article was for a parent wishing to monitor children’s Google searches, and as such any possible malicious purposes are not in any way implied.

We have no affiliation with Google, inc. We simply used their site as an example to phish because they are very popular and a parent may wish to monitor a child’s Google activity, realistically.

If you get detained for phishing, or any other criminal activity for that matter, then the mere visit to this page does not place any of the blame on us: you chose to do whatever you did based on your own decision.

This guide is educational only, and should not be interpreted as an invitation to violate one’s privacy.

Don’t be a jerk.