Jump to content

Skeletnyy Klyuch

Members
  • Posts

    4
  • Joined

  • Last visited

Everything posted by Skeletnyy Klyuch

  1. How about addind a Proxmark3 on the back of your box for 125 Mhz RFID access cards duplication? ;) Skeletnyy Klyuch
  2. UnixSecLab, Did you try launching Responder.py from the command line (cf. my screenshot above), after simply stopping dnsmasq? If you don't stop it after startup of the Turtle, you get a red error message from the Responder.py output on the screen saying there is a conflict with port 53. That error goes away and Responder.py stores the hashes if you just stop dnsmasq from the command line before starting Responder. This indicates to me that, in order to get the Turtle to work automatically, the dnsmasq must just be stopped in the startup script, after it was initially launched. Regarding your line showing an IP in the 169.254.0.0/16 range, this is symptomatic of a Windows machines failing to dynamically acquire an address while configured for DHCP, hence assigning itself a link-local IPv4 address (RFC 3927). So it seems your did something in your mods that prevented Windows to get an IP address from the br-lan when you plugged the Turtle in. I'm still working on why I can't get hashes from local accounts -- any input welcome! SK
  3. I spent some time yesterday testing this. 1. A prerequisite is the automatic installation of the Realtek driver when you plug in the Turtle for the first time, and while this will work with a Windows machine on which you admin rights, it will most likely fail in a corporate environment, where you usually don't have admin privileges. 2. Once the driver installed, my tests on a personal laptop were only half-successful. Like others on this forum, I was able to gather NTLM creds when initiating connections to shares and websites, but didn't gather any password hash for the Windows login account itself. The steps were pretty simple: I got all the dependencies installed through the Turtle SSH menu interface with the new script from Darren (with Responder installed also, obviously), then exited the interface, stopped dnsmasq, and launched manually the python Responder script with wpad proxy and forcing wpad auth, like this: cd /overlay/etc/turtle/Responder python Responder.py -I br-lan -r -d -f -w -F -v In the output, I immediately got 'Sending NTLM autentication request to 172.16.84.122', because the machine was trying to access a share or a website. When I exited (CTRL-C) the script, the hash was indeed stored both as a file and an SQLite3 entry, in /overlay/etc/turtle/Responder/logs/HTTP-NTLMv2-172.16.84.122.txt and /overlay/etc/turtle/Responder/Responder.db. Screenshots attached in this post and the next. So now I guess my question is this: what are the conditions for Responder to catch the Windows account password? This is, in my opinion, the contextual info we lack wight now, SK
×
×
  • Create New...