Jump to content

Darren Kitchen

Root Admin
  • Posts

    4,836
  • Joined

  • Days Won

    230

Everything posted by Darren Kitchen

  1. @40trieslater here are my thoughts based on your posts: After a factory reset, the system is restored from a backup partition however the udisk may be untouched – so this probably explains the discrepancy with your udisk/version.txt The control keys you are seeing indicates that your keyboard is not a generic HID keyboard, but rather a "fancy" composite device containing multiple HID devices (usually for multimedia controls, RGB LED controls, etc). We have also seen this behavior with bluetooth keyboards that happen to have USB functionality (for charging) like the Apple Magic keyboard and Microsoft Surface keyboard. It may have nothing to do with your Windows 10 Home 1909 version but rather that you tried it on a different computer, and in doing so the race condition was in your favor. Meaning, when the "fancy" keyboard enumerated on the Key Croc it presented multiple HID interfaces (part of what's called a USB Composite device) and each of those interfaces were mapped to HID channels. The Key Croc from v1.0 - 1.3 is expecting a single HID channel, with the regular keyboard as the first device. The additional HID channels are currently ignored. When the multimedia keys enumerate first, you get these odd results. When the regular keyboard keys enumerate first, you get keystrokes as expected. My guess is that in this case with the Windows 10 Home box, the regular keyboard keys enumerated first and everything worked. In the case of these "fancy" composite keyboards, it's luck of the draw as far as that race condition goes. It's something we're working on and hope to have a firmware update to address soon. In the meantime, I recommend trying with a standard keyboard while we nail down this bug. I hope that sheds some light on your issue. I'm aware that it's not a perfect answer, but it's the honest truth for the moment until we solve for composite devices. Anyone reading this in the future please be aware that this is an issue specific to firmware 1.0 through 1.3 – I know how these threads tend to linger on (also I hope the world is in a better place future hackers).
  2. This has now been addressed in firmware 1.3 – see the post at
  3. Try the QUACK HOLD command, but that might do it. I'll give it a shot soon. See the section on HOLD and RELEASE at https://docs.hak5.org/hc/en-us/articles/360047381354-QUACK-and-Ducky-Script-2-0 Essentially you'd want to determine the scan code from the language json and pass it to QUACK HOLD. It looks like COMMAND-r from the us.json is 12,00,15 – so the command would be: QUACK HOLD 12,00,15 QUACK DELAY 5000 QUACK RELEASE That would hold COMMAND-r for 5 seconds.
  4. Thank you all for the incredible feedback on the Key Croc – especially the 1.3 beta. We knew in development that we were on to something game changing, so to hear the enthusiasm from you all directly is truly rewarding. The amount of creativity shown in such a short period of time since initial release is encouraging. We hope that with this Key Croc firmware 1.3 we can further that creativity. As always we welcome your feedback here on the forums and of course on our Discord channel. Thanks for your support and happy hacking! Huge thanks to our team – @Korben for his work on this firmware with the support of @Foxtrot and everyone including 0xdade for feature inspiration. Changelog: General (optional) Password Protected Arming Mode built into framework/parser ARMING_PASS and (optional) ARMING_TIMEOUT can be defined in config.txt (Credits: 0xdade) Fix croc being shutdown by host machine going to sleep C2 notifications added to relevant event handlers iProduct can now be defined with PROD_ when calling ATTACKMODE, and defined in config.txt as PROD iManufacturer can be defined in config.txt as MAN Croc now waits for keyboard to enter ATTACKMODE HID Increase output log write speeds Fixed $LOOT ATTACKMODE now automatically populates /tmp/vid /tmp/pid /tmp/man /tmp/prod along with /tmp/mode Fixed payload validation at boot and added payload validation to RELOAD_PAYLOADS Payloads / Tools Add SAVEKEYS [path] UNTIL [regex] syntax support to payloads (Credits:0xdade) SAVEKEYS NEXT/UNTIL now also produce .filtered logs handling backspaces and removing control characters/modifiers. Ported GET extension script from Bash Bunny Added GET_VARS script giving your payload access to the following live data VID PID MAN PROD HOST_IP TARGET_IP TARGET_HOSTNAME Added the following helper scripts QUACKFILE (alias QFILE) ENABLE_PAYLOAD DISABLE PAYLOAD WAIT_FOR_KEYBOARD_ACTIVITY WAIT_FOR_KEYBOARD_INACTIVITY WAIT_FOR_LOOT Framework functions exported MOUNT_UDISK UNMOUNT_UDISK UPDATE_LANGUAGES ENABLE_WIFI ENABLE_INTERFACE START_WLAN_DHCP CLEAR_WIFI_CONFIG CONFIG_PSK_WIFI CONFIG_OPEN_WIFI ENABLE_SSH DISABLE_SSH Added the following scripts WAIT_FOR_ARMING_MODE WAIT_FOR_BUTTON_PRESS ARMING_MODE GET_HELPERS Misc Added get_payloads.html to udisk Fixed language file consistency, example: CONTROL/CTRL Moved examples into library/examples Debug logs moved to /root/loot so they will be automatically moved to udisk for easier debugging access DEBUG ON in config.txt now enables parser and framework debug logs at boot Download from https://downloads.hak5.org/croc Documentation from https://docs.hak5.org/ Flashing Instructions from https://docs.hak5.org/hc/en-us/articles/360048015333-Updating-the-Key-Croc
  5. It could be that the drivers aren't installed. They usually install automatically. What does device manager say?
  6. When you say stream, you're talking video rather than screenshots? If so - it may be achieved with ffmpeg: https://trac.ffmpeg.org/wiki/StreamingGuide
  7. I see how that wording is confusing. The intention was not to mislead. I will update it to make it more clear. The sales page states that video captures save mpeg files in various bitrates. When we finish up the currently in progress feature release of the Key Croc, we will investigate adding the C2EXFIL option for video files with an update. Live video streaming could be setup today using ffmpeg, which may be installed from apt on the device. There is a root shell accessible via serial. That said, this setup would require an RTMP server in order to receive the video signal. That's outside of the scope of Cloud C2 for now - however it doesn't look difficult to deploy based on this: https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-server-using-nginx.50/ Now I understand this answer may be disappointing. I wish you only the best experience with Hak5 gear. Should it not be to your satisfaction, please submit a ticket at https://shop.hak5.org/contact and we will make it right.
  8. This is by design. We can look into adding it in a future version.
  9. @fogmaster21 I recommend using the official javascript encoder from https://shop.hak5.org/pages/ducky-encoder If you manually specify a language file (json) and pick the us.json linked at https://github.com/hak5/bashbunny-payloads/tree/master/languages You will find that the following command will produce the appropriate scan code to inject the combination you want. CTRL-ALT e From the language file: "CTRL-ALT": "05,00,00", "e": "00,00,08", So this will produce the scan code 05,00,08 I hope that helps.
  10. Interesting. I had a similar problem on Kali Linux 2020.2. It seems that interface enumeration may have changed. Replacing line 75 to the following solved the problem for me: IFACE=$(route | grep 172.16.24.0 | awk '{print $8}')
  11. The Apple Magic Bluetooth Keyboard is a known issue, as is the Microsoft Surface Bluetooth keyboard. Both have USB capabilities when hard wired, but they do not utilize the standard HID channels. We are working on a patch which would streamline keystroke channel discovery and pass through for keyboards which enumerate as composite devices with multiple endpoints - such as keyboard with certain multimedia keys and RGB LED effects. Your standard, boring office Keyboards from the likes of Microsoft and Logitech without such extended capabilities should work out of the box.
  12. How are you viewing the log? I tend to cat the file here and there in payload development and have yet to have that cause issues. Are you viewing it with an editor like vim or nano? Also, is this with 1.2 or 1.3 beta? In the new version, the file is written more frequently.
  13. We're testing a patch now and will make an update as soon as possible.
  14. Powershell or Bash script?
  15. It shouldn't take but 5 or 6 minutes to fully charge - as indicated by a solid blue LED. See the getting started guide at https://docs.hak5.org/hc/en-us/articles/360034667173-Shark-Jack-Basics and be sure to read the important safety information at https://docs.hak5.org/hc/en-us/articles/360034129974-Important-Safety-Information-and-Warnings
  16. @ot2i7ba are you able to SCP files to / SSH into the Shark Jack manually?
  17. Why? The Shark Jack has its own internal battery - so it's compatible with both POE and the much more common non-powered Ethernet ports. Is there a specific use case you have that would benefit from POE?
  18. Interesting observations. I'm testing on my end with a Microsoft Surface Book machine with the Key Croc connected directly to its USB-A port. I've found that when the system enters sleep, the Key Croc stays awake and I can SSH into it without issue. However, while the target is in sleep mode the Key Croc is unable to inject keystrokes to wake the target (QUACK returns errors). That said, I am unable to reproduce the issue with keystrokes from the attached keyboard not passing through to the target. In my case, pressing keys on the attached keyboard both woke the target and were recorded. The keyboards numlock light turning off while directly attached to the target in sleep mode, but not turning off while in sleep mode when attached to the Key Croc, is likely due to the DefaultIdleState being zero. Edit: Upon further investigation, it would seem that in my first test the target had entered S0. After leaving the target idle for longer, it entered S1and I was able to reproduce what you are describing. By running the following command on the Windows target with the Key Croc both connected and disconnected, I was able to determine its device ID. powercfg /devicequery all_devices | findstr "Keyboard" Then, with the Key Croc attached running the two following commands leads to me believe that Windows believes the Key Croc is able to enter S1 sleep, while the Surface Book's onboard keyboard is only able to enter S4 sleep. powercfg /devicequery S1_supported | findsrt "Keyboard" powercfg /devicequery S4_supported | findsrt "Keyboard" I believe that by adding the PDCAP_WAKE_FROM_D3_SUPPORTED setting and removing the PDCAP_D2_SUPPORTED setting will resolve this issue. I'm investigating configurations outside keyboard.inf, or if a power state may be cloned by spoofing another device. I'll keep you posted.
  19. The Key Croc was purpose built as a keylogging pentest implant. Unlike the LAN Turtle, it doesn't feature an Ethernet port so it wouldn't make a very good covert remote access toolkit posing as a USB Ethernet adapter. That said, we provide an unrestricted root shell so you're free to explore whatever options suit your particular scenario best. By all means hack away - just be careful not to brick it as the recovery partition will be useless for factory reset should it become damaged.
  20. Thank you all for the incredible feedback on the Key Croc. We knew in development that we were on to something game changing, so to hear the enthusiasm from you all directly is truly rewarding. The amount of creativity shown in such a short period of time since initial release is encouraging. We hope that with this beta release of Key Croc firmware 1.3 we can further that creativity. As always we welcome your feedback here on the forums and of course on our Discord #beta-testing channel. Thanks for your support and happy hacking! And an especial big thank you to our team – @Korben for his work on this firmware with the support of @Foxtrot and everyone including 0xdade for feature inspiration. Changelog: General Optional Password Protected Arming Mode built into framework/parser ARMING_PASS and (optional) ARMING_TIMEOUT can be defined in config.txt (Credits: 0xdade) C2 notifications added to relevant event handlers iProduct can now be defined with PROD_ when calling ATTACKMODE, and defined in config.txt as PROD iManufacturer can be defined in config.txt as MAN Croc now waits for keyboard to enter ATTACKMODE HID Increase output log write speeds Fixed $LOOT Fixed payload validation at boot Payloads / Tools Ported GET extension script from Bash Bunny Added GET_VARS script giving your payload access to the following live data VID PID MAN PROD HOST_IP TARGET_IP TARGET_HOSTNAME Added the following helper scripts QUACKFILE (alias QFILE) ENABLE_PAYLOAD DISABLE PAYLOAD WAIT_FOR_KEYBOARD_ACTIVITY WAIT_FOR_KEYBOARD_INACTIVITY WAIT_FOR_LOOT Framework functions exported MOUNT_UDISK UNMOUNT_UDISK UPDATE_LANGUAGES ENABLE_WIFI CLEAR_WIFI_CONFIG CONFIG_PSK_WIFI CONFIG_OPEN_WIFI ENABLE_SSH DISABLE_SSH Added the following scripts WAIT_FOR_ARMING_MODE WAIT_FOR_BUTTON_PRESS ARMING_MODE Misc Added get_payloads.html to udisk Moved examples into library/examples Debug logs moved to /root/loot so they will be automatically moved to udisk for easier debugging access DEBUG ON in config.txt now enables parser and framework debug logs at boot You can download the BETA firmware here. You can find upgrade instructions here (substitute the file linked above in step one).
  21. What's up with the QUACK STRING "GUI l" part?
  22. It's not supported by default but since it's wpa_supplicant at its base this could be achieved with a script. Firmware v1.3 exposes a wifi connect function which could be used in payloads.
  23. Thanks for the detailed reports. Since the keystrokes are still passing through to Cloud C2 - just not the target - after waking from sleep it gives us a good lead to follow. We'll investigate. Any information you can provide on the USB ports (C with A adapter, hub, powered hub, etc) would be helpful.
  24. The Key Croc is based on the Bash Bunny platform so yes, it shares many of its ATTACKMODE options. That said, the payload execution framework and hardware implementation are very different. Sorta like how certain SUVs and Pickup trucks share the same frame.
  25. I could be mistaken, but I believe media keys pass through a separate HID channel (not the exact terminology) than the regular keys. Do you mind sharing the model of keyboard? It's something we can investigate.
×
×
  • Create New...