Snagging creds from locked machines

[azzarin]

On 9/13/2016 at 10:44 PM, ptrac3 said:

Try to do something like this:

mkdir -p -m 700 /root/logs

rm  /overlay/etc/turtle/Responder/logs
ln -s /root/logs /overlay/etc/turtle/Responder/logs

I am still unable to receive any hash with a locked Win 10..I run "python Responder.py -I br-lan -f -d", is that correct?

Du you have the Responder "Enabled" in the module list? Im only getting the hash if thats enabled.

[azzarin]

1 hour ago, azzarin said:

Du you have the Responder "Enabled" in the module list? Im only getting the hash if thats enabled.

Ok. now it does not get any creds at all. Don't know what happend. It does not look like a stable way of getting creds.

[M@$T]

14 hours ago, azzarin said:

Ok. now it does not get any creds at all. Don't know what happend. It does not look like a stable way of getting creds.

Maybe someone can post the entire code that is needed? Would help out a lot in that way

 

My turtle is on the way so hopefully next week I can test it out

[Skeletnyy Klyuch]

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

[Skeletnyy Klyuch]

[UnixSecLab]

My own further research shows that the 99-QuickCreds script is indeed stopping dnsmasq, but something must be killing the DNS (port 53) portion and restarting dnsmasq afterward.  Unfortunately, if you kill dnsmasq altogether (by moving the /etc/rc.d/S##dnsmasq to use a lowercase s instead of an uppercase s) it essentially bricks the turtle.  It runs, but it never presents an IP to the host machine if dnsmasq doesn't start.  I suspect this is by design.  Either a module such as autossh (so you have a way in) or similar is needed in order to get in when you do this, or you have to go through an unbricking process since you never have access to it from the host again.  This isn't a problem, except I was hoping to not have to peel the sticker back.  No big deal.

I'm wondering if the thing we're missing in this is that DNS has to be running properly at auto-start time of the QuickCreds module (responder needs to own that port) because the dhcp offering dns at the initial load of the driver for the network device (the turtle) needs that?  If that's the case, that makes sense why nobody has had any luck on this.  I'm going to do the following for further testing:

1) Set up a dummy startup script that writes a "nestat -plant | grep 53" to a file on a repeating loop every 30 seconds or so.  Unplug the turtle and plug it back in for testing.

2) Disable that startup script by moving it to a lowercase s as mentioned above.  Unplug and replug for testing (shouldn't write to the file this time.)

3) Write a second startup script that sleeps for a set number of seconds before moving the other back to an enabled name (S instead of s). Unplug/replug for testing.

4) If the above works as I believe it will, I'm going to modify the second script to re-enable dnsmasq's startup script after a set sleep duration (so I don't have to unbrick the thing again.)

5) Disable dnsmasq, make sure QuickCreds is enabled.  Clean up all previous QuickCreds junk directories and cp /dev/null to the responder.log to clean the slate.

6) Plug it in and watch the yellow LED.  Hope that it does the 3 blinky blinks.  If it doesn't, I'll wait an appropriate amount of time (because dnsmasq should be re-enabled at this point).

7) Unplug/replug so I can check on the loot potential.  Also check the netstat startup script output to show that dnsmasq was indeed disabled as required for the loot grab.

8) Post my results here when I'm done.

[UnixSecLab]

Okay, I did everything I described in my last post.  I did get logs that show python owned port 53 as expected, but still no responder database file and no output indicating the "creds" were stolen in the responder.log file.  This was tested on a Windows 10 laptop with anniversary update that is not associated with Active Directory, so local accounts, only.  I do see an inconsistency that I can't explain, after looking at the Responder.conf file, but I don't think that's the issue.

In the Config-Responder.log file, there is this line:

    Settings.DatabaseFile = /etc/turtle/Responder/Responder.db

However, in the /etc/turtle/Responder/Responder.conf configuration file, the Database line just says "Responder.db" along with the rest of them (Responder-Session.log, Poisoners-Session.log, and so on.)  Those -Session.log files all show as being in /etc/turtle/Responder/logs/<name of file> in the Config-Responder.log output, but not the Responder.db.  I changed this to logs/Responder.db in the configuration file and now the Config-Responder.log shows it in the right location.  The file doesn't exist, though, so still not quite working right.

I notice in the Reponder.log that there are entries like this:

09/18/2016 12:31:54 AM - [*] [LLMNR]  Poisoned answer sent to 169.254.215.253 for name testmachine

The other stuff is all 172.16.84.172.

Again, it makes me wonder if there's some configuration missing from the QuickCreds that setting this up manually all the way might not cover.

Finally, I'd like to know if there's a specific reason this needs "screen" to run.  I know it's convenient to be able to attach to the screen session with "screen -r responder" but if it's only because there is a lack of a "nohup" on the turtle, there is a trick for kicking off a process in the background without nohup.  It might or might not require the cron module to be installed, but you can do this:

echo "my_command_to_run.sh" | at now

Just replace "my_commmand_to_run.sh" with whatever the actual command you want run is.

I'm going to set this aside for now, and try again later.  I never got to hand it off to my coworker for testing on an AD enabled machine, but I'll try to get with them again next week.

 

 

[Skeletnyy Klyuch]

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

[UnixSecLab]

Skeletnyy Klyuch,

I didn't launch Responder.py manually at all.  What I've been working on is troubleshooting the QuickCreds module, specifically, rather than following the manual process that some people have managed to make work.  I forced dnsmasq to NOT start on plug in, which is why Responder.py did not have a conflict.  That conflict on port 53 is because something is starting dnsmasq back up after QuickCreds stops it, but before QuickCreds starts the Responder.py piece.  It's a race condition of sorts.  I've confirmed that the QuickCreds script does stop dnsmasq successfully if you start it manually while dnsmasq is running, but when it's called initially by plugging it in while it is enabled, it still gets a conflict error.  And I had debugging code in place to show when each script gets called (dnsmasq from /etc/init.d, and QuickCreds from auto_start modules) and QuickCreds is stopping it, but the "init.d" script is not starting it back up.  Something else on the turtle is starting it back up.  I wrote my debugging in such a way that it would only write out the "stopped dnsmasq" if a test of ${?} showed that it was stopped successfully, so I know it truly did stop it.  I haven't figure out what starts it back up, yet, so I took a round about path of disabling it.

The first time I disabled dnsmasq from starting by moving it from /etc/rc.d/S60dnsmasq to /etc/rc.d/s60dnsmasq, the turtle wouldn't allow any logins no matter how many times I unplugged/replugged it, which is why I wrote some extra sauce to automatically move that back to /etc/rc.d/S60dnsmasq as described yesterday.  Oddly enough, I was able to log in on a single plugin after it had been disabled.

As for the 169.254.x.x IP in the logs, I'm aware that's a Windowsism for not obtaining a valid IP, but it still doesn't make any sense.  The ONLY log entries that had that were the LLMNR ones.  All of the others had 172.16.84.172.  This was from the /root/loot/0001 folder, and I removed all of the /root/loot/#### folders as well as clearing the /root/loot/responder.log file (using cp /dev/null /root/loot/responder.log) between each test so that I had clean slates with no possible way of accidentally viewing old data and getting myself confused.

There has never been a Responder.db file created from any of my testing, even in the alternative location /etc/turtle/Responder instead of /root/loot/####.

I'd really like to see the QuickCreds module fixed so that it works "out of the box" consistently, but at this point, it's not (for me, anyway.)

I just hope that the testing I've been doing and reporting here helps someone else along the way.

[Forgiven]

On September 15, 2016 at 10:46 PM, UnixSecLab said:

Regarding the new QuickCreds module, I installed this using "configure" from the module list, then enabled it.  None of the Windows machines I used for testing responded with "creds" as far as I could tell.  Three of the log files in the loot/000# directory showed growth, and looking at them I can see where it says it is responding with poison responses, but it never snags any results.  I tried disabling all other networking on one of the targets and it still did not work.  I'll be taking this to work with me tomorrow to let one of the corporate security team members try it on a workstation that is associated with an active domain controller (since my personal ones are not, in case this is the issue.)

I did notice while reviewing the Config log that it keeps complaining that some other service has port 53 tied up.  I looked at the /etc/turtle/autostart_modules/99-QuickCreds script, and the 'start' function looks like it is calling /etc/init.d/dnsmasq stop, but it's not working correctly.  If I run netstat -plant before starting QuickCreds, it shows dnsmasq owns that port.  If I run 99-QuickCreds start manually and check again, a bunch of services are listening that belong to python, but 53 still blongs to dnsmasq.  If I manually stop dnsmasq before running the QC start script, then start QuickCreds as above, python owns port 53 as expected.  Running the QuickCreds stop actually works properly and re-starts dnsmasq as expected.  I'll dig through this script with a more careful eye and see if I can figure out why it's hosed on start, but I don't know if this is why I never get creds or not.

The three targets I tried were two Windows 10 laptops and a Windows 7 laptop.  I tried in both "logged in" and "workstation locked with windows-L key" modes.  I got nothing for my troubles.

UnixSecLab,

Darren made a change to line 115 in the QuickCreds program about 22hrs ago.  You might try to update the module and re-test.  Note that someone also found they get an error after /root/loot/0008 and offered up a suggested fix that hasn't been implemented as of yet.

[Jhac]

Forgiven,

Just tried that version for the QuickCreds module, it blinks and creates a folder every single time I get it into a machine but the folders are always empty.

Any ideas?

[Forgiven]

1 hour ago, Jhac said:

Forgiven,

Just tried that version for the QuickCreds module, it blinks and creates a folder every single time I get it into a machine but the folders are always empty.

Any ideas?

I'm still working on it.

[846846]

Before this works a Realtek driver has to be installed on the machine. What if not, like Win 7 machines? Someone got a trick for this?

Thanks.

[tdhuck]

I watched the youtube video published with mubix specifically talking about setting this up on the Lan Turtle. I also read his blog post. I am a newb when it comes to this stuff, but Darren's explanation of this module on the Lan Turtle seemed very basic. I don't know if it is working with my Lan Turtle. When I plug it into my windows 10 laptop (non domain, local user) I hear the noise it makes when a USB device is plugged in, the LEDs blink slow, then turn off (the orange one) then rapidly blinks for about 5-10 seconds and then stays solid, which is when I unplug it from the windows 10 machine (lock screen). According to the description in the Lan Turtle module, that means it is done grabbing the hashes. When I ssh into the Lan Turtle, I see a bunch of numbers counting up, which is correct according to the code Darren showed in the youtube video and I see responder.log. If I nano/vi into responder.log, I see a few lines that state creds saved, but that's it...not sure where I should see the hashes, assuming it grabbed something.

[Mr-Protocol]

Looks like check in /root/loot/##### directories.

[tdhuck]

40 minutes ago, Mr-Protocol said:

Looks like check in /root/loot/##### directories.

Sorry, I forgot to add another sentence after stating that I checked the responder.log file. When I ls into the numbered directories I see 4 files, when I try to view any of the 4 files, they are all empty. I tried this a handful of times on two devices, one was a windows 7 desktop and the other was a windows 10 laptop (both of them owned by me). The highest the numbered directories got to was 12, but I did not try this 12 times. It seems that each of my attempts creates 2 numbered directories. 6 attempts does seem a bit more realistic.

Thanks.

[Mr-Protocol]

The video shows there should be a Proxy Auth NTLM.txt file of sorts in one of the folders. Testing it out now.

[DoctorCPU2]

The updated 1.1 version of the QuickCreds module worked most of the time testing locked and unlocked Windows 7 and 10 workstations.

I changed line 132 in the module so the responder.log indicates which folder has NTLM hashes saved.

Code:

 echo "Creds saved! "$((dircount)) >> /root/loot/responder.log
 

Thanks Darren!

[tdhuck]

13 hours ago, Mr-Protocol said:

The video shows there should be a Proxy Auth NTLM.txt file of sorts in one of the folders. Testing it out now.

What did your results look like?

[tdhuck]

3 hours ago, DoctorCPU2 said:

The updated 1.1 version of the QuickCreds module worked most of the time testing locked and unlocked Windows 7 and 10 workstations.

I changed line 132 in the module so the responder.log indicates which folder has NTLM hashes saved.

Code:

 echo "Creds saved! "$((dircount)) >> /root/loot/responder.log
 

Thanks Darren!

Where is the default location and what should the file name of the results be?

Thank You.

[Chiakilen]

21 minutes ago, tdhuck said:

Where is the default location and what should the file name of the results be?

Thank You.

You should have something like this.  At /root/loot

[tdhuck]

5 hours ago, Chiakilen said:

You should have something like this.  At /root/loot

Your picture is too small, I can barley make out the file names, but the files I do have are empty. It appears we do have the same output/structure.

[tdhuck]

Maybe I am doing the final step wrong. How do I view those log files?

I noticed that some directories have this file, Proxy-Auth-NTLMv2-172.16.84.154.txt, and others don't. They have other files, but not the proxy file.

I tried more and vi, but it gives me errors or just shows ~ down the left side.

[tdhuck]

[UnixSecLab]

I updated the QuickCreds module and tried it on the same Windows 10 anniversary update laptop I used last weekend.  I get the same "dnsmasq" is running instead of python for port 53 errors for the DNS portion.  The loot directory still contains the same 4 files only.  I did the "fix" so that python could actually take port 53 by moving /etc/rc.d/S60dnsmasq to /etc/rc.d/s60dnsmasq, and have a script that automatically moves it back on next login in place as before.  I restarted it with this work around in place.

I really think the issue is that it's too slow to issue the DHCP information.  The LLMR logs show the private IP Microsoft uses, then the actual 172.16.84.x address a little while later.

09/24/2016 03:57:01 PM - [*] [LLMNR]  Poisoned answer sent to 169.254.215.253 for name Workstation
09/24/2016 03:57:02 PM - [*] [LLMNR]  Poisoned answer sent to 169.254.215.253 for name Workstation
09/24/2016 03:57:02 PM - [*] [LLMNR]  Poisoned answer sent to 169.254.215.253 for name Workstation
09/24/2016 03:57:19 PM - [*] [LLMNR]  Poisoned answer sent to 172.16.84.172 for name Workstation

I'm thinking of blowing away the current config with a firmware update again, and do a fresh install of everything, then try again.  I'll also try it on some other systems again as needed.  I was hoping to get this to work on my home gear before handing off for my coworker to test, but I may not be able to get it to work out of the box on my stuff.