Building an Evil-AP with TL-MR3020 – Part 3 – The Landing Page

This is part 3 of the “Building an Evil-AP with TL-MR3020″ series. If you haven’t read part 1 and 2 you can find them here.


Now, we got the user to authenticate through the captive portal. At the moment it is obviously possible to write whatever you want into the box (once again I’d like to point out that you shouldn’t use the code I’ve provided, it is not secure). With the current captive portal firewall rules the user can only browse freely on the internet after authenticating. Thus we need to either change the firewall rules or add evil stuff on the landing page. It is up to you but I’ll add stuff onto the landing page.

Current landing page.

Validating Credentials

It is likely that people will provide inaccurate information on the login page. To remedy this it is possible to use the captured credentials and try to authenticate with the selected service. For example if a person decide to authenticate with a specific social-media (or intranet) page a script can be running in the background and try to login with the provided credentials. If they are not valid the script can execute ndsctl and kick off the user. Even better, the validation should probably be done before authenticating the user with ndsctl in the first place.

This is probably illegal in most places so make sure you’re not breaking any laws.

Iframes &| Embedded code

There are tons of fun stuff you can do with this. Both for information gathering and exploitation. Although first you’d need information about your target. Here you can run code that gather information about the targets machine, browser and so forth. Irongeek got a page that display tons of information based on information your browser gives up (link). This information you can use to fingerprint and then attack the target (injecting an exploit or trying to serve the target a backdoor). If you’re feeling lucky you can load Metasploits browser autopwn in an iframe or perhaps (and most likely better) a BeEF hook.


Some people got a Linkedin account and don’t logout. Also, the standard setting will show a user that a Linkedin account have visited their ‘page’. Obviously we’ll now create a dummy page on Linkedin and then add an iframe that will load view our profile. This way it is possible to find the identity of the user accessing the AP (if the stars align).

Depending on how you try to present your Evil-AP it might be easy or hard to get a user to run code or own themselves somehow. But hey, if you don’t ask there’s zero chance of it happening. For example an Evil-AP impersonating a city Wi-Fi might try to get the user to download an app that will show them tourist information or perhaps a Microsoft Word document with a malicious macro. It could be interesting to see if a user is willing to download a rogue SSL certificate and install, who knows. It just might work!