Tutorial: DNS Spoofing

DNS Spoofing

Greetings my fellow hackers.

As you may have noticed by my lack of posts, I've been away for a while working on a big project with a team (which won't be finished anytime soon), and I have also been putting together a small side project for Null-Byte that I will be announcing soon. So sorry if I've been lagging, I'm back now and I'm finally making a tutorial. I know that DNS Spoofing has been covered here already by OTW but I feel like I have to make my own input on this. I'll be using Ettercap so that's something original, am I right? Alright, let's get to it.

What Is DNS Spoofing?

DNS Spoofing (sometimes referred to as DNS Cache Poisoning) is an attack whereby a host with no authority is directing a Domain Name Server (DNS) and all of its requests. This basically means that an attacker could redirect all DNS requests, and thus all traffic, to his (or her) machine, manipulating it in a malicious way and possibly stealing data that passes across. This is one of the more dangerous attacks as it is very difficult to detect, but today I will show you both how to perform it and how to detect if it is being performed by somebody else on your network.

Step 1: Preparation

Let's start by booting up Kali Linux, whether it's a Virtual Machine (VM), a native boot, or a dual boot. If you haven't got Kali yet (which you should by now, granted that you're on this website) go get it on the official website.

Make sure you have a working internet connection before you continue and make sure that you are on the same network as your target. This is a LAN (or WLAN) attack and so both the attacker and victim must have the same network gateway. Let me point out in advance that the victim could be running any operating system, it does not matter.

Step 2: Configuring

We now need to edit the Ettercap configuration file since it is our application of choice for today. Let's navigate to /etc/ettercap/etter.conf and open the file with a text editor like gedit and edit the file. We can use Terminal for that.

So now we want to edit the uid and gid values at the top to make them say 0 so go ahead and do that.

Now scroll down until you find the heading that says Linux and under that remove both the # signs below where it says "if you use iptables".

Great, we're done with the configuration.

Step 3: Ettercap

Now let's run this show by opening Ettercap. You can do it the lame way through launchpad or the cool way using Terminal. I'm going to teach you the cool way. Go ahead and open up Terminal and type:

What we want next is to select our sniffing interface. Let's zoom through the steps real quick.

First select Sniff > Unified sniffing… > (Select the interface connected to the internet) > OK

(You can find out which interface is connected to the internet by typing in Terminal ifconfig and seeing which interface gives you an IP address).

Then swiftly do Start > Stop sniffing because it automatically starts sniffing after we press OK and we don't want that.

Now we want to scan for targets on our network and pick one. To do this, go to Hosts > Scan for hosts and wait until it does the scan. It should only take a few seconds depending on the size of your network (which I assume isn't very large).

So we've dealt with the scanning but how do we see our targets? Well, go back to Hosts and select Host list to see all the targets that Ettercap has found.

Now what we want to do is add our victim machine to Target 1 and our network gateway to Target 2 but first we need to know both of their IP addresses. To find out our victim's IP address, we first need to know who we are attacking, and we can do so using nmap to find the information we need on the target machine. Once you are sure who your victim is, select their IP address from the host list in Ettercap and choose Add to Target 1. Now you need to find your gateway IP address (your router). To do this, open Terminal and type ifconfig and look at where it says Bcast: and that will tell you the IP address of your gateway. Alternatively, you can also use the route -n command. Now select the gateway IP from the host list and choose Add to Target 2.

Step 4: Action

Now that we have both Targets set to our victim and gateway, we can proceed to the attack.

Go to the MITM tab and select ARP poisoning, choose Sniff remote connections and press OK. Now go to Plugins > Manage the plugins and double click dns_spoof to activate that plugin.

We now need to edit another file in the Ettercap folder.

This etter.dns file is the hosts file and is responsible for redirecting specific DNS requests. Basically, if the target enters facebook.com they will be redirected to Facebook's website, but this file can change all of that. This is where the magic happens, so let's edit it.

First, however, let me explain what can and should be done with the hosts file. So in a real life scenario, an attacker would use this opportunity to redirect traffic to their own machine for data sniffing. This is done by starting an Apache server on the Kali machine and changing the default homepage to a clone of, let's say facebook.com or chase.com so that when the victim visits those websites, after being redirected to the attacker machine they will see the clones of the aforementioned sites. This will probably fool the unsuspecting user into entering their credentials where they really shouldn't. Enough talk, let's do it.

First, redirect traffic from any website you would like to your Kali machine. For that, go down to where it says "microsoft sucks ;)" and add another line just like that below it, but now use whatever website you would like. Also, don't forget to change the IP address to your IP address.

Now we need to start Apache to accept incoming traffic.

Let's head over to the default html page folder. That is where we can take control of what the victim sees when they get redirected. The location is /var/www/html where you will find the index.html page. You can alter the document to your needs and, once you think you have done sufficient fooling to your victim, you can save the page and changes will take effect instantly. Let's see here...

The final thing left to do here is to start the attack. Go back to Ettercap and select Start > Start sniffing and that should do it.

Now every time the victim visits the webpage you indicated in the etter.dns file (in my case it's facebook.com) they will be redirected to the fancy and inconspicuous page above. You can see how this can be extremely malicious, since the attacker could write a script that fetches the requested page immediately and sets up the etter.dns file and listens in on the login, all automatically. This should really alert you that it is really that simple to perform a DNS Spoofing attack with very few resources.


So how do you protect yourself from it? There are a couple of ways: using software built for ARP poisoning detection or checking the arp command manually on a regular basis (which is a pain).

Let's look at the software first, there are a few that I will mention.

  1. XArp

A GUI advanced ARP spoofing detection and active probing software. It is designed for this kind of job and works on both Windows and Linux (configurable for OS X as well).

  1. Snort

You most probably know Snort for its IDS amazingness, but I'm sure you haven't heard that it also detects ARP spoofing (you may have).

  1. ArpON

This is a portable handler daemon for securing ARP against spoofing and cache poisoning.

There are a few others like Arpwatch, Antidote and ArpAlert but you could just Google them.

Now how about manual checking? Well, this one is a little tricky since it requires you know something beforehand. What you could do is remember the MAC address (or parts of it that will help you recognise it when you see it) of the default gateway (i.e. your router) and keep checking it in the ARP cache.

To check the ARP cache, go to the Terminal and type arp -a and you will see several entries like this:

(I removed the BSSID (MAC address) entries for 'security' reasons (not really))

If you can remember something like the first or last 6 characters of your gateway's MAC address and continually check arp -a to see if it matches, then you've got yourself a way to detect ARP poisoning without needing any 3rd party software. Isn't that great?


Now you know how DNS spoofing works and, most importantly, how to protect yourself from it. Being in a White Hat forum means not only learning attacks but also their remedies. This is particularly useful in real life scenarios and I hope that if you get yourself into this sort of heap you will know how to escape it.

I hope you enjoyed today's tutorial and hopefully you learned something from it. Any suggestions for future tutorials I will be happy to take in. Very soon I will be releasing something to the Null-Byte community so stay tuned.

Here's a handy PDF version of this post if you want to save it and read it in a nice format later: click here.

As always have a great day, peace.

Just updated your iPhone? You'll find new features for Podcasts, News, Books, and TV, as well as important security improvements and fresh wallpapers. Find out what's new and changed on your iPhone with the iOS 17.5 update.


I am newbie in the world of hacking and hell I don't know the silliness of my question which reads as -

Is there any way to bring a remote target onto my network(I am using a govt ISP 3G service) and then proceed with the method explained by you?

No, not that I'm aware of, you can't really force someone to connect to your LAN. The on thing I can think of is making an evil twin if they are within range of wireless.


You could try your luck and hack the ISP of your target, and then route all of the victim's traffic through to your machine. Although this is highly unrealistic, it is still a possibility.


Very detailed and comprehensive, good job!


Thanx TRT...Hoping to make this highly unrealistic thing realistic.
Thanking u washu too

https websites wont work... even if, HSTS would block most of them.

Many websites still utilise the HTTP protocol by default, without redirecting users to the HTTPS version, which many don't even offer support for.

Also, by ARP poisoning your victim, they would not be able to distinguish between the legitimate website and the clone, as long as the clone which you fabricate is convincingly similar (and as long as any subtle differences remain inconspicuous).


Your example was irrelevant, you will not be able to spoof facebook.com though. Your article was great except that.

I did all it said in your tutorial, but and it says that the ip of the victim was successfully spoofed to my ip.

However the victims browser, in this case Safari, won't open the site, because "it cant make a secure connection to the server of www.facebook.com"

So this won't work in Safari. (?)

For that there is sslstrip, which I will cover in a future tutorial. I apologise if that caused confusion among people.


Ah, which Will prob only Work with the sslstrip+?

I'm not quite sure I understand your question. Please rephrase it.


It was more a statement, since (as far as I've read) the SSLstrip by moxie won't work with https, but the sslstrip2 by LeonardoNve would work against https.

That's peculiar, since both have functioned properly when I conducted tests on them. I might look into this later, and thanks for noting that.


Well at least with the hsts bypass, but keep me posted about what you figure out! I might be wrong.

Effectively you are right, most websites use HSTS now and the only way to bypass it is with sslstrip2.


Do you know where we can get sslstrip2?

DNS spoofing will generally not work on HTTPS websites unless the client chooses to ignore the warning signs or if you manage to obtain the private key for the site.(for those who asking for https)

not with firefox, they don't have the option

they cant choose to ignore the warning

Nice tutorial! I got a question though: Does this work even from within a (windows) domain enviroment with dhcp/dns services?

The reason im asking this is because domain networks seem to have fixed values cause of the authentification against the DC (domain controller).


OTW, first of all... thanks for the hours of fun, null-byte rocks.

Now, I've tried every method I found (after hours and hours of searching) for sniffing and spoofing the local network. I've attempted to do MITM attacks with both ettercap and arpspoof, I've also tried DNS spoofing with both dnsspoof and ettercap's plugin.

My problem is that I never could capture images with driftnet, urls with urlsnarf (MiTM) or force the target to a fake website running in the attackers localhost (DNS spoofing) . I'm sure both issues have to be related, but I couldn't find any useful info online.

Does someone have any advice that could help me tackle the problem? The steps I followed always match the ones you explain in your tutorials.



SHQ27 - Sorry for the late reply but, in short, unless the victim network/target is using an ancient browser and accessing some random, completely insecure (no SSL/HTTPS/HSTS) clearnet URL and their browser even allows them to do that (ref above, SE7EN is right, neither FireFox nor Chrome will allow users to ignore 'insecure URL' warnings, it just wont resolve the destination at all), this method of DNS spoofing (even with StripSSL2) is pretty much redundant. I wouldn't bother wasting any time trying to master it - it's just an interesting localhost/network experiment.

can I spoof site1 to site2 and then site2 to site3 and so on?

hi guys

I'm really new to this stuff, just got a raspberry pi 4 and am running kali on it.
already updated kali and everything, installed ettercap manually (common and graphical version)
I just can seem to get ettercap running, keep getting this error

"parse error etter.conf line 172"

any tips? I tried removing ettercap and re-installing it. I got the same error. Also restarted my raspberry pi.

thanks for the help already!

Hey . thanks for the tutorial bit this Technik doesnt work , it makes the target slow internet and cnt open anypage. I meant no redirect , no internet.

Plz make a working Technik.

Thanks, but I have detected that while we are doing DNS spoofing on a victim device the browser device could detect that an attacker has changed some informations and the browser does not let the victim to visit our phishing page and it shows a massage that says an attacker round here.
Cuz the informations are encrypted that's why it can detect those kind of situations. Have you bypassed this security?

Share Your Thoughts

  • Hot
  • Latest