Jump to content


Active Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by chrizree

  1. I have several modules installed at the same time, so it should be no problem. Not sure what you might have messed up (if it was you at all), but if I would get stuck in such a situation, I would most likely do a firmware recovery and start over fresh.

  2. -B is BSSID, i.e. MAC address, not SSID (or ESSID) which is -E, you mixed them up, it's the other way around

        ATTACK MODE d: Deauthentication and Disassociation
          Sends deauthentication and disassociation packets to stations
          based on data traffic to disconnect all clients from an AP.
              -w <filename>
             Read file containing MACs not to care about (Whitelist mode)
              -b <filename>
             Read file containing MACs to run test on (Blacklist Mode)
              -s <pps>
             Set speed in packets per second (Default: unlimited)
             Enable full IDS stealth by matching all Sequence Numbers
             Packets will only be sent with clients' addresses
              -c [chan,chan,...,chan[:speed]]
             Enable channel hopping. When -c h is given, mdk4 will hop an all
             14 b/g channels. Channel will be changed every 3 seconds,
             if speed is not specified. Speed value is in milliseconds!
              -E <AP ESSID>
             Specify an AP ESSID to attack.
              -B <AP BSSID>
             Specify an AP BSSID to attack.
              -S <Station MAC address>
             Specify a station MAC address to attack.
              -W <Whitelist Station MAC address>
             Specify a whitelist station MAC.

  3. Nothing that gets logged related specifically to the payload afaik. You can run logread to see events. Events tagged especially for the Shark can be viewed using: logread -e Shark   I guess you are connecting the Shark to the network the "common" way (via a switch port). There should be no real problem with that default payload and getting loot. Is the network restricted in any way? By MAC address making the Shark not able to connect? You can always try the payload I put up on my GitHub that "steals" the MAC address of an endpoint and then uses that MAC address when connecting to the network to run nmap and save loot. It worked when I wrote it, but I know the default Shark payload should work as well.


  4. Do you have any experience involving problems with the SD card itself or has it worked as intended? I just started my Nano up after a long time not using it (just using the Mk7 nowadays) and I have no problems with either the SD card (as other have reported over time in the forum) or that PineAP refuse to stay enabled. It runs as expected. In what way are you powering the Nano? Does it get enough "juice" to make everything run problem free?

  5. Enable PineAP to get a monitor mode interface. Set the attack mode (using "d" here). Specify input and output interface. The "d" attack mode shouldn't really need two interfaces to be specified, but the module won't start mdk4 unless both are set, use wlan1mon for both. Using a blacklist = just make sure it's in the Mk7 file system somewhere and that it contains relevant MAC addresses for AP(s) to "attack". Add the path to the blacklist on the line in the module GUI. Specify channels to operate on. The Command line in the module GUI "grows" as parameters are set, for example a "full" line could look like: mdk4 wlan1mon wlan1mon d -b /root/mdk4_temp/blacklist.lst -c 1

    Then hit "Start" and the "attack" should begin (the Output box at the bottom of the module page will update every 5 seconds). If running ps ax you can see that the mdk4 process has been started in the background.

    Adding multiple MACs? Not sure, just try different variants. One on each line perhaps... or comma, or semicolon... The SSID list files on the MDK4 GitHub are specified with one SSID per line at least, so perhaps a hint on how to handle MACs as well.

  6. Doesn't that command throw a (rather long) error message back at you since the interface (wlan1) isn't in monitor mode? I can't in any way say that I'm a frequent user (or a user at all actually) of mdk4, but installing the module and its dependencies on my Mk7 wasn't all that successful. Everything looks OK when it's installed, but when running mdk4 from the command line of the Mk7 it just started attacking other APs than the one I had specified in the blacklist file (or at command line using -B). I did the same from one of my Kali boxes and that went all fine. So, I compared the mdk4 versions and the one that was installed along with the Mk7 module looked older than the one that was installed in Kali. So I removed the mdk4 package from the Mk7 and then downloaded a variant that has been made available by adde88/Zylla for the Mk7. When using that variant of mdk4 everything looked all fine. Apart from the CLI tests, also the Mk7 web GUI was successful running mdk4 (the "deauth attack mode" that is).

  7. Some modules are for sure obsolete but not because the modules themselves are obsolete, it's because of the fact that the methods (or whatever you like to call it) are obsolete/not working as a concept. I see a fair amount of "yelling" about SSLStrip, but that hasn't been working for years in practical use. Try running it on the Nano/Tetra and see how efficient it is. That along with other modules for the 6th generation that probably doesn't work anymore even if they are in the "list". Without me knowing how the Hak5 crew has been working during the development of the Mk7, my qualified guess is that they went through the list of modules for the previous generation, made a strike through over the modules that had very little chance of working in a modern "victim" environment, built some functionality straight into the Pineapple itself that eliminated the need of some modules and then actually "migrated" some modules to the Mk7. That in combination with knowledge of how many modules that was actually being downloaded for the Nano/Tetra probably made a pretty solid base on what to push further to the next generation. Which ones of the modules for the Nano/Tetra do you want for the Mk7?

  8. OK, then set it up as a Windows service. Note though that the C2 Windows binary most likely is a "non-service" binary which needs some extra steps to make it run as a service (compared to executable files that are designed to run as services).

  9. It's possible that a firmware recovery might solve it. Sounds a bit strange though that it should be needed, but if such a simple and basic thing as getting access to the Shark doesn't seem to work, maybe it's the way to go. I've never had such issues with my Shark, but if I had tried all possible (and logic) ways to solve the problem, I would do a firmware recovery to try to get it working.

  10. I haven't reacted on this post before since USB-C phones was the subject. However, I just want to add that you don't necessarily need a USB-C phone to interact with the Plunder Bug. I use the Bug with a Samsung phone that just has a MicroUSB port. It's a Samsung A3 2016 with rooted LineageOS 17.1 and it captures packets with success using the Hak5 Plunder Bug app. I.e. Samsung phone > MicroUSB male to Type A female USB OTG cable > Type A male to USB-C male cable > Plunder Bug.

    • Upvote 1
  • Create New...