Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 05/15/2019 in all areas

  1. 3 points
    Hi everyone! Inspired by the "Making Windows scream when you unplug devices" payload, I was thinking of other fun payloads you can do with the Rubber Ducky. Lately, a co-worker of mine showed me how you can play music with powershell and after I've seen that, I just had to make a payload with this feature. For those who aren't aware of, you can use "beep" commands with powershell which will, when executed, play a tone. If you want to try it yourself, just open powershell and execute the following commmand: [console]::beep(500,300) When executed, you will hear a short "beep". You can find further information on the powershell beep command here: https://devblogs.microsoft.com/scripting/powertip-use-powershell-to-send-beep-to-console/ So now we can make our own music using powershell. Luckily, there are already some tracks available such as "The Imperial March (Star Wars)" or "Mission Impossible". When I saw this, I just had to make a Rubber Ducky payload out of this. So every time you plug in the Rubber Ducky, it will execute the powershell script and play the Star Wars Imperial March. Here is the payload: DELAY 3000 GUI r DELAY 250 STRING powershell DELAY 250 ENTER DELAY 500 REM Hide the powershell window STRING Add-Type -Name W -Names C -M ' ENTER STRING [DllImport("Kernel32.dll")] ENTER STRING public static extern IntPtr GetConsoleWindow(); ENTER STRING [DllImport("user32.dll")] ENTER STRING public static extern bool MoveWindow(IntPtr h, int X, int Y, int W, int H);' ENTER STRING [C.W]::MoveWindow([C.W]::GetConsoleWindow(),0,0,-1,-1); ENTER REM Play the Imperial March STRING [console]::beep(440,500);[console]::beep(440,500);[console]::beep(440,500);[console]::beep(349,350);[console]::beep(523,150);[console]::beep(440,500);[console]::beep(349,350);[console]::beep(523,150);[console]::beep(440,1000);[console]::beep(659,500);[console]::beep(659,500);[console]::beep(659,500);[console]::beep(698,350);[console]::beep(523,150);[console]::beep(415,500);[console]::beep(349,350);[console]::beep(523,150);[console]::beep(440,1000);exit ENTER Of course one should be able to loop this so the song will keep playing, but I'll leave that up to you guys 🙂 I know it's a kinda meaningless but fun payload, so I hope some of you will enjoy it! - zSec
  2. 1 point
    Well i am back to tell you what really happen and why it act the way it did.. It is always human factor,i never realized then i have a different power source on the PI3. (NOT ENOUGH POWER) I am still having problem with the wp6.sh to make the connection and be on the net when you are on dashboard to see bulletin. But it fix it self when you go on page network on the gui to connect at wlan0 🙂
  3. 1 point
    Made some great "white hat" usage of BashBunny this week. Bought a batch of new micro-PCs, built a golden image for them, saved it with CloneZilla. Loaded a bootable CloneZilla Live install on to BB, then made a HID/STORAGE payload that boots target into CloneZilla with pre-scripted restore, redirecting stdout back to /loot. Script on BB waits a few minutes for CloneZilla to complete, then BB reboots both the target and itself to make sure /loot is synced and visible, then checks the logfile for successful completion before LED FINISH. Bing bang boom! Fresh new PC ready to deploy with custom config. Lessons learned: It can be really hard to script blind HID keystrokes when the target might not be consistent each run (BIOS boot device menu sequence, for example). One workaround is to send multiple commands in a sequence that the target will ignore or fail recoverably if irrelevant. /loot doesn't automatically stay in sync between scripts running on BB and on the target when mounted as STORAGE.Having BB reboot itself was the only way I could reliably get it to see updates saved by the target. After a self-reboot, the same payload script can pick up where it left off by first detecting that a file is there now. If I really want real-time two-way communication between BB and target, probably need to use network instead of storage. Next time. Fun project! Thanks Hak5 for a truly useful tool.
  4. 1 point
    I'm sorry that you're not happy with your NANO. I looked through your post history and noticed that your first forum post was only yesterday at the time of writing, I would suggest allowing more time for a response on the forums as it's community-driven. If you could send me your support ticket number via Private Message, i'll take a look as soon as possible. Thanks
  5. 1 point
    thats the patch i put on. you dont know the power of the dark side. tons for like a buck plus like 4 buck shiping on "wish"
  6. 1 point
    The tetra is an OpenWRT box. So just about anything you can do in Openwrt, you can do with the tetra. It would just take some sweet iptable-fu. Also, if you’ve got physical access to the wan box, the rj-45 is input only so you could hardline it to help cut down on the frequency traffic.
  7. 1 point
    Hi all - I understand the desire to use the infusions from the WiFi Pineapple Mark V era. As Seb has previously pointed out, unfortunately the older devices are no longer capable of securely downloading these infusions over the air from our infrastructure. That being said, all of the modules/infusions may be manually installed to either local of SD storage with ease. To that effect I have published the following article on docs.hak5.org - https://docs.hak5.org/hc/en-us/articles/360023458173 Happy hacking!
  8. 1 point
    Honestly, there really is no need to keep bumping this thread... If you run `make menuconfig` (as the link I provided states) and select "Hak5 WiFi Pineapple NANO" and then return to the CLI and run `make` you will get a bootable image for the device...
  9. 1 point
    Everyone can modify it and create pull requests to Hak5's module GitHub repo. A problem imo. opinion is that the reaver version on Hak5's repo is very much outdated. I'm cross-compiling the latest version of Reaver and keeping them updated as often as I can, but using the newest version requires heavy modifications to the WPS module, due to alot of changes to Reaver.
  10. 1 point
    You could also try using a link shortening service to make any long link much smaller.
  11. 1 point
    These forums are attracting more and more of this bullshit. Admins should be shit canning these members accounts. IMHO.
  12. 1 point
    Good one hey, only thing missing is a cup of java a HackRF Looks like it could fit in there nicely
  13. 1 point
    The best way to protect the rogue AP is using the Filters tab. With proper recon, you should be able to identify the MACs or SSIDs of the target devices and add them to the filter. With the filters set to "allow" mode, only devices with a MAC address or SSID in one of the pools will be able to connect. If you are looking to minimize collateral damage then filters are a good choice. One of the benefits of a rogue AP attack is that you don't necessarily have to be inside of the building for it to be successful. If the employees have directly received instructions to connect to the rogue access point then that means a) the hacker has physical access to the building or b) has social-engineered someone into providing the credentials to employees. In either case, the hacker is already far beyond rogue access points in terms of potential harm to the company.
  14. 1 point
    Hey everyone, We have recently discovered a bug in the update process of the Bash Bunny, which causes boot-loops. The bug is triggered if the upgrade file had been extracted, renamed, or was otherwise altered. Fortunately, we have now found a fix for the issue: Plug in the Bash Bunny and unplug it immediately when the initial green LED turns off Repeat step #1 three times Plug the Bash Bunny back in and wait for it to reset. You should see either a "police" pattern or a red blinking LED. Set the switch to the switch1 position (furthest from the USB port) Wait for the device to reboot (indicated by the green led) and set the switch to arming mode immediately as the green light turns off. If all went well, you should now be able to access the Mass Storage partition of the Bash Bunny (or serial in). Delete any leftover update files (such as "ch_fw_1.3_264 (1).tar.gz") Safely eject / sync the Bash Bunny Reboot your device, by re-plugging it, while keeping the switch in arming mode. This should get your Bash Bunny up-and-running on firmware v1.0, allowing you to properly upgrade to the latest version. We recommend using the Bash Bunny Updater for this. We have released firmware 1.4 which prevents this bug from being triggered. Note: These instructions are not the same as the one from this thread. Similar, but more reliable.
  15. 1 point
    If you go into the CLI and head into the /etc/config directory, you'll find the nmap config file. You can edit it and add a line, "config 'log' " (no quotations) into the file and save it. That allowed me to set the log directory within the Turtle Shell GUI.
×
×
  • Create New...