Snagging creds from locked Windows/OS X machines using USB-Armory/Hak5-Turtle(room362.com)
room362.com
Snagging creds from locked Windows/OS X machines using USB-Armory/Hak5-Turtle
https://room362.com/post/2016/snagging-creds-from-locked-machines/
5 comments
anyone understand what exactly is the system broadcasting to the new DHCP server? I can't imagine any system is so bad to the point of sending anything more sensitive than a user name
(It's actually "broadcasting" to the proxy (WPAD) server.)
I just skimmed the article but the idea sounded really familiar (so forgive me if I'm wrong) but this is what I think is going on...
You set up a "rogue" host providing DHCP and proxy services. In the DHCP response to the client, the server can tell the client what proxy server to use (see "WPAD"). When the client contacts it, the "rogue" proxy server then basically sends back an "Authorization Required" to the client (workstation), noting that NTLM authentication is just fine, thank you. That client will then happily respond and send along its (NTLM) credentials to the "rogue" server.
If I was on a computer I'd do a quick Google. I'm almost certain that I've read of pretty much this same exact attack before.
Edit: Here's a very, very similar attack over three years ago: https://www.trustedsec.com/july-2013/wpad-man-in-the-middle-...
I just skimmed the article but the idea sounded really familiar (so forgive me if I'm wrong) but this is what I think is going on...
You set up a "rogue" host providing DHCP and proxy services. In the DHCP response to the client, the server can tell the client what proxy server to use (see "WPAD"). When the client contacts it, the "rogue" proxy server then basically sends back an "Authorization Required" to the client (workstation), noting that NTLM authentication is just fine, thank you. That client will then happily respond and send along its (NTLM) credentials to the "rogue" server.
If I was on a computer I'd do a quick Google. I'm almost certain that I've read of pretty much this same exact attack before.
Edit: Here's a very, very similar attack over three years ago: https://www.trustedsec.com/july-2013/wpad-man-in-the-middle-...
The explanation is somewhat convoluted, but I believe they're impersonating a Windows server and convincing the target to send NTLMv2 credentials for the logged in user. Haven't looked at the protocols for a bit, but there may be some restrictions on when you're able to use this attack vector, e.g., local file sharing permitted, domain member, etc.
I'm thinking our intern might be willing to test out a few more theories and put together a more comprehensive blog post.
I'm thinking our intern might be willing to test out a few more theories and put together a more comprehensive blog post.
Check out https://github.com/Spiderlabs/Responder for some additional info and links.
I think the crux of the issue is that a Windows workstation already authorised on an existing AD domain server will change its default gateway and proxy to the hot-plugged USB Ethernet device but not invalidate the existing credentials so they are captured by the device. Presumably the credentials are transmitted unencrypted.