Jump to content

Scriptmonkey_

Active Members
  • Content Count

    17
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Scriptmonkey_

  1. This works beautifully btw. I've been using this for exactly what you suggest @Jenny_b against hosts with a removable storage exclusion applied. I've nicknamed it "the Exfiltrator", basically configured a DHCP server, nfs server, SMB, ftp and a simple php webpage offering upload and download, with the DHCP server, it's an awesome little beastie for that and some other things ;)
  2. Not had any issues here, but I'm primarily accessing it from an Ubuntu 18.04 base. I have ssh'd to it using Windows 10 and had no issues but I'm off on leave now for the holidays so no access to it at the moment but will double check when I can. Just to eliminate the obvious, it isn't just taking a while to regenerate its keys is it? It happens on connection so it could just be taking a while maybe?
  3. Honestly the only thing I can offer is "Try Harder" to coin a phrase. It took me a few attempts to get the reset function to trigger but it worked for me. If there are LEDS flashing patterns that aren't related to network activity, then I'd say there is clearly something running and its down to you to figure it out. I figured out the above, you may need to do some other incantation. There are other rescue modes advertised on the openwrt docs, perhaps you booted into one of those. Here LMGTFY: https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset Your description sounds like you've got it booting into the first example given.
  4. netdiscover, arp-scan, nmap -sn (or for that matter: https://nmap.org/book/man-host-discovery.html Also perhaps you should review some of the lovely free educational material published by Hak5... in particular this one may be of use: From the manual itself: I would recommend reading more of the manual: https://docs.hak5.org/hc/en-us/categories/360000982574-Packet-Squirrel The default IP, credentials and operation of the device is explained in full there. As for DNSSPOOF, that's a tool built by someone else. Read it's manual too. What are you trying to even? Instead of losing your temper, stop trying to run before you can walk, read the manuals that are provided for your products (because by your own admission you've not done this), then come to the forum with actual output from what you're seeing, try logging your script output for example - the packet squirrel will write to its local flash if you're having issues with USB keys. If you're a "newbie" theres no shame in it, and people will want to help you. Everybody has to start somewhere, but I would say buying 7 rather expensive products without a use case is probably the first mistake you've made. These products use mostly publicly available tooling essentially putting them in nicely designed little packages and wraps them with some extra bits and pieces that make them worthwhile buying. You can do all of the packet squirrel's attacks with a laptop and two network cards. I'd suggest getting your attack working there, then transferring it to the packet squirrel platform, as by trying to dev directly on the platform you're going to be pulling your hair out especially if you've not figured out how to SSH to it yet. The point of the packet squirrel? I use my packet squirrel all the time: As a OpenVPN tunnel for my laptop/switch. Diagnostics for my familie's PCs (here plug this in when you get home... i'll RDP in) or on jobs where I want to surrepticiously gather packets from a host to another host. e.g. MFPs that scan, fax and print are a perfect use case. I can get documents both scanned and printed along with NTLMv2 credentials when the printer auths to something to either do an address book lookup or dump a file on a file share. It all fits together with a small USB power bank, into the floor panel. Out of sight, out of mind. Yeah I can do all that with just my laptop, but it packages it all up very nicely in a tiny piece of kit.
  5. Have used these a few times both for gear they sold anyway (think I bought my rdv2 from them) and hak5 gear recently when I grabbed a shark jack. Nice to have a reliable european distributor of hak5 gear! Welcome to the forums.
  6. Thanks, I was using a pin and it just kept missing it or slipping off 🙂 Wrote up the recovery guide into another thread but yeah, looks like firmware upgrade is basically scp firmware file to /root/ boot cycle it into arming mode and wait for LEDs to stop doing the hokey cokey.
  7. So anyone who's seen the other firmware post has probably seen my adventures in trying to figure out the firmware upgrade process as the suggested tool in the post just doesn't exist, is available on github if you need it, but the links in the download center appeared to be broken earlier. I ended up bricking my shark to some degree - Turns out though as it's based on openwrt it has the inbuilt recovery features. So these are the steps I took to restore its functionality - you can follow, but it is by no means the official help, nor is it without massive risk. I was willing to chalk my jack up to being a lost cause. 1. Charge it - You probably won't have LEDS here to help you out (no charge level indication) but you only need sufficient power to "wait" for it to actually boot, so plug it in for 5 minutes and just let it charge. 2. Using either a pin*, sim-card removal tool, etc locate the hole on the back of the case and insert it most of the way, you should feel a button at the end of the travel. Rest it on it, but do not depress it. *I found it difficult to "aim" my pin, at the button as it's tiny... so I removed the casing of the shark jack... there are no screws, it comes apart with a spudger inserted down the side, really easily. 3. Power on the device to ARMING mode (middle position). Depress button using your pin now. Count 1000, 1, 1000 2... etc until 1000 7. remove pin! 4. Plug device into your Network Jack within a minute or so you should see green lights, indicating activity on the network port. 5. Set your host's IP to 192.168.1.2 and attempt to browse using a web browser to 192.168.1.1 you should see a screen like the following: 6. Once you've proven connectivity to the recovery webpage, PLUG IN YOUR USB-C... KEEP THE SHARK JACK POWERED THROUGHOUT THIS PROCESS. 7. Select the OS tab. 8. Using a normal "upgrade-*.*.bin' firmware file available from the hak5 download center (download it, check the checksum), browse to the firmware. 9. CONFIRM YOU ARE ON THE OS TAB AND IT SAYS "e.g: OpenWRT.bin" DO NOT DO ANY OTHER TAB or you will be on your own. - select "start upload file". 10. Page will switch to a loading screen informing you to wait until the device reboots. 11. Once the device has rebooted you should notice this... the LEDs will have done their boot cycle (flashing greens) and turned to either flashing amber, indicating arming mode, or flashing/static blue to indicate the device is either charging or charged. 12. Set your host's IP to 172.16.24.2 and attempt to SSH to the device. You may get prompted about the SSH host key having been changed and may need to delete it from your known_hosts file, but once done... you can log back into the device using the default credentials of root:hak5shark. Now go get a celebratory beverage of your choice and get your hack on.
  8. Well... snifflebiscuits. I believe I've done did broke it. Lost network connectivity as the file was transferring (not sure why, it was there, I wasn't touching it, just SCP stopped transferring the file and said connection reset by peer). Next boot, I can only assume it tried to take to the partial file that I'd uploaded and appears to have flashed that. All switch modes are unresponsive. I don't suppose there is a "Users Be Stupid, Factory Reset" magical on-off-switch-button combination in order to restore the firmware? Edit2: I've actually managed to recover this myself. I've taken the liberty of writing up the procedure I took in a forum post and deleted some of my posts from here as it was just cluttering up the place.
  9. I concur. The shark jack gets incredibly hot when charging. Still seems to work however, but I would definitely listen to the advice of DO NOT LEAVE IT CHARGING. Also working on it, I think there is a thermal cutoff being reached or something. I plugged it into a network port and had the USB-C connected from a reliable power bank as I was doing some dev on it and despite it continuing to flash the green LED the entire device became unresponsive. It was again, incredibly hot, like trying to hold a cup of coffee without a handle.
  10. Can confirm I'm getting the same issue. Edit: Don't think I need to do it manually. Reviewing the binaries on the host I found /usr/bin/shark_framework which has some interesting lines in. Looks like if you copy the firmware file to /root/, have the switch in arming mode... it'll autodetect and apply the firmware. #!/bin/bash SWITCH_POSITION=$(/usr/bin/SWITCH) MODE="OFF" UPGRADE_FILE=$(ls /root/upgrade-*.bin 2>/dev/null | tail -n1) LOG="logger -t Shark [*]" LOG_ERR="logger -t Shark -p 3 [!]" function upgrade_leds() { /usr/bin/LED OFF while true do echo 1 > /sys/class/leds/shark:red:system/brightness sleep 0.2 echo 0 > /sys/class/leds/shark:red:system/brightness echo 1 > /sys/class/leds/shark:blue:system/brightness sleep 0.2 echo 0 > /sys/class/leds/shark:blue:system/brightness done } function execute_upgrade() { $LOG "Checking for firmware upgrade" [[ -f $UPGRADE_FILE ]] && { $LOG "Firmware upgrade found" upgrade_leds & led_pid=$! cp $UPGRADE_FILE /tmp/upgrade.bin rm $UPGRADE_FILE sleep 2 && kill $led_pid $LOG "Executing UPGRADE" /usr/bin/LED B && echo "sysupgrade -n /tmp/upgrade.bin" | at now exit } || { $LOG "No firmware upgrade found" return 1 } } <snipped> Giving it a shot now.
  11. I have a few ideas in mind for it, beyond just "quick!!!! make the SOC go red!" Hoping to get one progressed today and will submit it to the github payloads when it's ready for sharing. Also, for a device that can quickly check if there is a sterile area in the visitor areas of buildings when on an Phys SE job, this tool is pretty damn discrete. Certainly more so than "hey can I just er do some work! thannnnkkkss!" and whipping out a laptop with an ethernet cable.
  12. Phew thank goodness for the manual install, I rarely use my pineapple but when I do I invariably always end up factory resetting it due to forgotten passwords thanks Darren for providing the infusions for manual installation. I'm wondering if simply upgrading the openssl libraries on the underlying operating system should be enough to get this working again with firmware v2.4. not played too much with openwrt, but curious.
  13. Oof! So more of a look into it, Looks like duckyscript doesn't actually have any control flow features? I can't do tests or loops? Eesh. The HID mode on the BB doesn't require ducky script only does it?
  14. So I was in a similar situation. 1. BashBunny info populated as per the OP screenshots - You're correct, the RNDIS Ethernet adapter comes above the wifi in the stack and OSX sets the BB as the default GW for the machine, no internet for anyone but you can ssh to the BB just fine. Correcting the derp with a route -n delete default gw 172.16.64.1 command and netstat -nr confirming the routing for IPv4 is correct at least, still does not restore the internet however for some unknown reason. What did fix it... hitting "assist me" in the network settings dialog and allowing it to configure the wifi network as an internet connection. That then reordered all my network adapters in the graphical listing of the network settings pane and now I can plug the BB in without losing internet on the host. However, despite following all the instructions in the OP and deleting the crazy route for the default gw to 172.16.64.64 on the BB and replacing it with a 172.16.64.10 (the ip of my mac) still doesn't give me network connectivity. No idea why the ip on the BB for its default route is 64.64 either. Would definitely appreciate any help trying to get this working, would like to update the OS.
  15. So managed to win a Bash Bunny as a prize in a CTF competition at a local conference over here and its day 1 of ownership. Have upgraded the firmware to version 1.3 and having a blast playing about with it over the serial console. I was thinking of porting a payload I use based on work I did with an old friend of mine called "Blinking Hell" (http://blog.scriptmonkey.eu/bsides-london-2013-blinking-hell-extracting-data-using-keyboard-lock-states/) which allows for export of data via the "lock" keystates. I'd say we got there first in 2011 using a teensy, but we didn't go public until 2013 :'( and it kinda just got left in the weeds other than our own private developments as we were using it in a very niche manner to suit our work. Any way bitter tears aside :) I'd like to port it over to the bunny. I've had a good root about using google and searching the forums and cannot see for the life of me how I can create ducky script to read the state of the various "lock" keys. I see people talking about it happening and asking "if it can" but no idea "how" to do it. I am assuming from reading the ducky script git pages its going to be some obscure command that isn't covered in the usual manual/howto. Cheers!
×
×
  • Create New...