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:
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,