Jump to content

UnixSecLab

Active Members
  • Content Count

    33
  • Joined

  • Last visited

About UnixSecLab

  • Rank
    Hak5 Fan +

Recent Profile Visitors

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

  1. I just looked at the file that you linked to, and compared to what you wrote, you're @ and " are still backwards. The file has: for /f "tokens=3" ... blah blah where you're quote has: for /f @tokens=3 ... blah blah which is wrong. Your initial share showed " where @ should be, and now you're displaying @ where " should be.
  2. Did you try plugging a network cable into the RJ45 jack with internet access before plugging the turtle into the computer? That seems to be the only way it grabs creds when I test.
  3. The existing QuickCreds works pretty consistently for me, now. The only problem is that it requires the RJ45 jack end to also have a connection. I still haven't gotten one of my project computers set up to act as a surrogate "other end," but I will. I tried disabling the QuickCreds, configuring the responder module manually per Mubix's guide, and I get nothing (with or without a network cable plugged in.) I wonder if QuickCreds has to be uninstalled to make the manual procedure work properly. All I know at this time is that it works on a Windows 10 Pro with anniversary update workstation
  4. The inject.bin is the file you create when you compile your ducky script using the encoder.jar file. You have to compile your own inject.bin every time you want to change what the payload is going to be. Just write yourself a ducky script, and then grab the encoder from the github wiki site and compile your own inject.bin.
  5. I may have to rig up either one of the Raspberry PI or the BeagleBone Black as a surrogate 'internet' connection for the RJ45 end to see if it'll work without a true internet connection, and it just wants a dadgum network plugged in for no real reason. It wold be kludgey, but at least it would make it portable without jacking into the network first. It would also mean I could have it send the loot to the other machine as soon as it detects that it has some, if keys are set up between the two. The other machine could be set up to crack the loot once it's been uploaded, with this scenario, to
  6. Analyzer-Session.log is probably the one that is size 0. I tried using the Turtle without a network cable plugged into the RJ45 jack and have 0 success with it this way thus far. I would hope that this doesn't actually require a network plugged into it since this attack's primary purpose is to present as dhcp from the turtle itself to get the creds. There's no need for the network outside of man in the middle poisoning of other stuff like DNS, unless I'm wrong.
  7. The directories will always show as size "0" so you need to go into them and do the ls -ltra to see if the files inside are growing or not. But you know that 17 is the newest directory and thus is the one you need to go into to check for this particular session. At a minimum you should have FOUR files in that directory all ending with "-Session.log" Hope this helped.
  8. I log in, exit the Turtle shell menu, cd to loot, ls -ltra to see what the latest directory is, cd to that, and ls -l to see what files are there and how big they are (if they're size 0, not worth trying to view.) I use "cat" or "more" to view the file.
  9. I pulled out my other LAN Turtle, because I remembered that it hadn't been configured for this module, yet. I installed QuickCreds on it, tried a fresh session, and waited about 3 minutes before giving up on it. Unplugged it and waited again. For this second session, I locked my workstation while it was plugged in, and then waited some more. It didn't snag anything on this session until I actually logged back in, but it did snag on the login. Proxy-Auth-NTLMv2-172.16.84.139.txt The file has 19 lines in it for one account over and over.
  10. Oddly enough, the next time I plugged it in right after this update, I saw the light go yellow after a bit. I logged in and it actually got the hash (finally.) with no more changes from me. I don't know why this is so sporatic. It's very hit and miss, and with all of the testing I've been doing, it's heavy on the "miss." This is encouraging, though.
  11. 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.
  12. 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
  13. 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
  14. 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
  15. I'm not sure whom you are replying to specifically, but if it was me, I never set up the responder module through the turtle config separately from the QuickCreds module. Are both modules supposed to be configured? It looks like a conflict to do it that way, since QuickCreds sets it up a specific way and runs it, and "responder" has settings that change the behavior. And both of them are at the same 99-<script name> level in the autostart_modules directory. If we're supposed to set up both, what are the configuration options that the responder module needs that don't conflict with th
×
×
  • Create New...