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. 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.
  2. 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 with QuickCreds, but only when the Turtle has internet access via the RJ45 jack when plugged in. It seems like this shouldn't be a requirement, to me. It makes the attack less practical if you have to steal the existing network connection from the target workstation temporarily.
  3. 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, too. A beefier machine would be better, but if the turtle absolutely must have a network connection on that end, might as well take advantage of it. If this doesn't work, maybe tying it to a pineapple for a wireless connection and portability would work. Does anyone know why this seems to need a network on the RJ45 end?
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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 the QuickCreds module?
  14. 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.
  15. The LAN Turtle is a mips based machine running an openwrt based Linux OS. The package manager is opkg, and the package files (should be) .ipk files, I believe. You can always log into it and exit to the command line to issue opkg commands from there. If you're savvy and extra froggy, you can set up the cross compile build environment for OpenWRT on MIPS and compile whatever you're missing, yourself. Just be aware that there's not a lot of space on the device's internal storage, so you'd need to be careful about size, and such.
×
×
  • Create New...