Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Sorry Guest, you are banned from posting and sending personal messages on this forum.

This ban is not set to expire.

[David]

Hi everyone

I am experimenting with the Evil Twin attack these days. I have followed various tutorials and have been successful in setting up a Fake Access Point and giving internet access using dhcp + nat table . Clients can connect and have internet access.

Issue is using such a fake AP in Evil Twin scenario. I setup the fake AP using same (SSID, MAC, Channel) as of a real Access Point. Then I want to throw the clients off the old Access Point so I do a deauth. Problem is that clients get deauthed but keep connecting back to the original Access Point even though I can see the "Client *MAC* associated (unencrypted) to ESSID: ***"  messages in the terminal.

Rarely clients will connect to the Evil twin but will still keep the old IP configuration (thus no access to internet). How do I get around this? From what I have read, as long as the fake AP has same SSID,MAC etc and higher power than the real AP then clients will connect to it after getting deauthed. But thats not the case for me.

My Card: Alfa AWUS036NHA
ClientS: Windows 7 systems

[david]

Hi everyone

I am experimenting with the Evil Twin attack these days. I have followed various tutorials and have been successful in setting up a Fake Access Point and allowing internet access to clients using dhcp + nat table . Clients can connect and have internet access.

Issue is using such a fake AP in Evil Twin scenario. I setup the fake AP using same (SSID, MAC, Channel) as of a real Access Point. Then I want to throw the clients connected to original AP off their AP so I do a deauth. However, clients get deauthed but keep connecting back to the original Access Point even though I can see the "Client *MAC* associated (unencrypted) to ESSID: ***"  messages in the terminal.
(indicating they associated with the fake AP for some time atleast)

Rarely clients will connect to the Evil twin but will still keep the old IP configuration (thus no access to internet). How do I get around this? From what I have read, as long as the fake AP has same SSID,MAC etc and higher power than the real AP then clients will connect to it after getting deauthed. But thats not the case for me.

My Card: Alfa AWUS036NHA
ClientS: Windows 7 systems

[syworks]

as long as ur signal is stronger than the actual ap... client should connect to u... and also the ur ap encryption type (wep/wpa/opn) and if encrypted, u need to have the correct key set in ur fake ap...

u just need the same SSID name and stronger signal than real ap... and not the mac address..

[Er3bus]

Sysworks is right. However, If the client is attempting to use the subnet IP of the "Good" twin, that client is probably set up to use a static route(IP), ie not using DHCP to get a subnet address. Changing your address ranges might fix this. I could be misunderstanding this part, but I think that's what you're trying say.

[david]

as long as ur signal is stronger than the actual ap... client should connect to u... and also the ur ap encryption type (wep/wpa/opn) and if encrypted, u need to have the correct key set in ur fake ap...

u just need the same SSID name and stronger signal than real ap... and not the mac address..

Thank You for replying. I have made sure that signal strength of real AP is minimum by working far away at a location with minimum signals. The strength of fake AP is greater. The APs are Open so there is no key. Clients do try to authente/associate with fake AP as I see the "associated" message but they soon bounce back to original AP.

P.S Thank You for clarifying that MAC does not needs to be same. I am going to test the logic that windows 7 client prefers the AP at lower channel number if two of them have SSIDs. Does that make any sense?

[david]

Sysworks is right. However, If the client is attempting to use the subnet IP of the "Good" twin, that client is probably set up to use a static route(IP), ie not using DHCP to get a subnet address. Changing your address ranges might fix this. I could be misunderstanding this part, but I think that's what you're trying say.

Yeah when clients get deauthed they keep the old IP configuration even if they later connect to fakeAP. (although clients connecting to fake AP is not frequent ) .
I have checked and the "Good" AP has a DHCP server so client is not setup to use static IP. It says "preferred ip address" in the ip configuration when I do "ipconfig -all".

Can this have something to do with the lease time of old ip configuration?

[syworks]

would you mind sharing the commands you use or the script you run here...
from the way you said, it seem that the client didn't even connected (an ip assigned to it) to your access point..

you may also want to consider using airdrop-ng to keep on deauth client from connecting to the legitimate ap. (last resort)

I do not know about the Win7 preference on choosing channel, maybe you tried it out and can share with us here ..

[misterx]

What version of aircrack-ng do you use? Are your drivers up to date?

[open]

Hi All, here my personal opinion.
Evil Twin attack is a real pain/in/the/ass for a victim STA.
The social engineering mechanisms which should lead a proper evil twin attack need a very deep knowledge and experience.
Instead when it's a scriptkid starting it as a game, just the dos effect can be literally devastating: psychologically and economically.
Hence, I agree with the maintainers about the policy which obviously is leading airbase tool: airbase is bugged, and must stay bugged.
Airbase as is, it has never been officially updated in the right places, to provide a fully working tool for evil twin attacks.
But instead it is more a tool for educational purposes only, working just with few drivers/chipsets.
That is very good - thanks.
Giving a loaded gun to a monkey is never the right thing.
Greetings

[david]

Thanks Guys I figured it out. It was the transmit power. My card had it hard coded so I had to modify the drivers to use 30 dbm.

As far as IP issue, Let me say it again. Clients after getting de-authed are connecting to evil twin but keeping the old IP configuration unless I release and renew it myself on clients terminal.

I am experimenting with Open Encryption so that could be a possible reason since clients get deauthed and reconnect instantly. I can not test WPA/WPA2 since airbase-ng does not support it as of yet although WEP could be tried.