Jump to content

cmaddy

Active Members
  • Content Count

    9
  • Joined

  • Last visited

About cmaddy

  • Rank
    Hackling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've been using virtual machines almost exclusively for testing. In my experience, the Bunny has no problem waiting for me to click the appropriate button in VMware's "Connect to..." prompt. I plug in the Bunny, there's a delay, VMware asks if I want to connect the newly discovered device to my host or VM X, Y, or Z and I click the appropriate option. After a brief pause, the Windows VM will sound the typical "ker-plunk" new device sound and the payload launches.
  2. CrackMapExec is a fantastic tool developed by Byt3bl33de3r and can be found here: https://github.com/byt3bl33d3r/CrackMapExec As stated in the repo's README, it's powered by Impacket and takes queues and inspiration from several other tools targeting SMB, WMI, and Windows in general. I recommend reading up on it if you are unfamiliar. For now, it's worth mentioning that CrackMapExec (CME) is also a Python library that can be installed with pip and used like a standard tool, i.e. you can type "crackmapexec" and use it without needing a Python script to act as a vehicle. I installed it on the Bunny and have used it for some network based attacks using RNDIS_ETHERNET mode. If you'd like to do the same, I encourage you to install pip. Connect to the Bunny via SSH and use curl with the "insecure" and output file options, like so: cd /pentest curl -k -O https://bootstrap.pypa.io/get-pip.py Now check your Bunny's current system date and time. If it's not current then you need to update it or Python and SSL will throw a fit because the date/time is wrong. Then use Python to run the script: python get-pip.py That may take some time to complete, but pip will open up a lot of possibilities and assist with Python tools and dependencies. Once that's done, you'll need to install packages required for supporting OpenSSL/PyOpenSSL. You'll need to have shared your internet connection with the Bunny for this to work. apt-get install build-essential libssl-dev libffi-dev python-dev Once those packages have been installed successfully, you should now be able to successfully use pip to install CME. If something goes wrong with this next step, it's almost certainly related to the cryptography library and a missing dependency. Read the error carefully and Google it. You can be certain there will be several GitHub and StackOverflow hits at the top. Run pip: pip install crackmapexec Once that is done, you can test everything by just running "crackmapexec" in your terminal and you should see CME spit out its help text and version information. You're now ready to include CME commands in your Bunny payloads. CME is a network attack tool, so you can use it against locked PCs. A very basic example of this is: crackmapexec $TARGET_IP That command tells CME to connect to the target's IP address via SMB. If that much can be done, CME will return a hostname and the target's operating system build. This is a fast "attack" and can be used to, let's say, fingerprint a machine quickly to prove you had access and collect some information. You can go a step further with this: crackmapexec $TARGET_IP -u "" -p "" That tells CME to try a Null session with SMB. If the target disallows Null sessions nothing bad happens. You still get the basic OS details. If the target allows for a Null session to be initiated then you can check for success and then potentially proceed with something like running CME again with the addition of "--shares" to enumerate network shares and gather additional information. If you happen to have a password hash or credentials from an earlier attack (perhaps phishing or passed to you from a teammate), those creds can be used with CME and any CME-based payload can be easily edited to include the credentials for a much wider variety of attacks.
  3. The pentest folder is in the device root, not /root. You can see it if you SSH into the Bunny and look in /. You won't see it when using STORAGE mode. For those wondering why they aren't seeing immediate results/just a blinking amber LED, you need to give Responder time to capture a hash. If you're using the Bunny against a test VM or just a convenient Windows PC, you may be waiting a while unless you force/initiate a request for a file share. QuickCreds looks for the log file Responder creates when it captures an NTLM hash. The Bunny will blink the amber LED until it sees at least one such log file. You won't get an NTLM hash and a log file until the target sends that information for something like a file share and is tricked into providing the hash to Responder.
  4. @Torrey Your suggestion got it working for me. I had the same thought about rebooting, but couldn't reboot at the time. A combination of a reboot and then switching to DHCP and back to DHCP with Manual Address got everything working. Thanks for sharing your work!
  5. Thanks for the update! Yeah, that's something that was either unclear or that I missed in the documentation. I didn't see SSH mentioned and I was using serial at the time so I didn't see SSH running either. I assumed I'd need SERIAL in the payload if I wanted to connect to the Bunny to setup tools. Now I know SSH is available as long as SERIAL isn't in use. Should work just fine with my Linux VMs now.
  6. @Torrey Thanks for the reply. I saw another post of yours linking to the latest Hak5 episode and mentioning SSH. I had assumed SSH would be available, but it was not and I didn't see it mentioned in the documentation. After removing SERIAL from the ATTACKMODE line, SSH is now listening and I was able to connect. That's good to know and really simplified things. That was the only reason I thought I'd need SERIAL, for connecting to the Bunny. Anyway, still no dice on the connection. I tried changing SharingNetworkNumberStart to 172.16.64.10. I thought it was strange because I was sure I had set it to *.10 to begin with. The change doesn't stick for me. Once I stop and restart Sharing, it goes back to *.0.
  7. Thanks for sharing this! This was exactly what I was working on today and needed to get working for some ideas I have. Your guide suggests I'm close, but still don't have a working internet connection on the Bunny. It looks like everything has been added correctly to /Library/Preferences/SystemConfiguration/com.apple.nat.plist. Here is what I have: <key>SharingNetworkMask</key> <string>255.255.255.0</string> <key>SharingNetworkNumberEnd</key> <string>172.16.64.200</string> <key>SharingNetworkNumberStart</key> <string>172.16.64.0</string> My network settings match your screenshot and I have Internet Sharing setup between my WiFi card and the RNDIS/Ethernet Gadget. I've restarted Sharing and triple checked settings, but no dice. What I'm trying to do is use ATTACKMODE ECM_ETHERNET SERIAL to share the internet connection with the Bunny and then use the serial connection to connect and install tools and updates. I get that far, but the internet connection on the Bunny fails. For the Pineapple you would have to run a command like "ifconfig bridge100 172.16.42.42 netmask 255.255.255.0 up", which would have to be changed for the Bunny's 172.16.64.* scheme. My bridge100 is currently 172.16.64.1. Did you happen to do anything else to get this working? Could you share the Bunny's network settings for you working config?
  8. @GermanNoob Thanks for the suggestion. I'm trying to work with a VM, but having difficulties connecting to the Bunny once the internet connection sharing is configured. The Bunny shows up as /dev/ttyACM0, but screen refuses to connect (Bad session name error). Might be the VM, VMware, or something else, but it's preventing me from actually using the internet connection sharing to update or try installing some tools.
  9. @b0N3z Did you ever have any luck with getting the Bunny to share a Mac's internet connection? I gave some of the guides for the Pineapple a shot (changing the IP address scheme to 172.16.64.*), but no luck getting a connection.
×
×
  • Create New...