X3N Posted December 5, 2008 Share Posted December 5, 2008 That would work but we have to do it last. If we cd out of the execution directory it's going to kill off the rest of the script because the rest of the tools won't be in path anymore. heres some code i put together that i was running with autoIT but its more vbsish.... Dim $oWSHShell Dim $oFSO Dim $Fol Dim $ThisFolder Dim $Subs Dim $Path Dim $FL Dim $FileList Dim $FilePath Dim $LogFile Dim $SearchDir = "C:\Documents and Settings\All Users\Start Menu" _SystemSearch($SearchDir) Func _SystemSearch(ByRef $SearchDir) $oFSO = ObjCreate("Scripting.FileSystemObject") $LogFile = $oFSO.OpenTextFile("startmenulog.txt",8,1) $ThisFolder = $oFSO.GetFolder($SearchDir) $Subs = $ThisFolder.Subfolders $FileList = $ThisFolder.Files For $FL in $FileList $FilePath = $FL.Path $LogFile.WriteLine ($FL.Path) Next $LogFile.Close () For $Fol in $Subs $LogFile = $oFSO.OpenTextFile("startmenulog.txt",8,1) $Path = $Fol.Path $SearchDir = $Path $LogFile.WriteLine ($Fol.Path) $LogFile.Close () _SystemSearch($SearchDir) Next EndFunc Quote Link to comment Share on other sites More sharing options...
X3N Posted December 5, 2008 Share Posted December 5, 2008 also i did the same thing using a native win32 version of unix find... which works exactly the same as unix's find. @echo off fnd "C:\Documents and Settings\All Users\Start Menu" > files.txt i renamed the find.exe to fnd.exe just to eliminate any possible confusion between windows built in find.exe that does something totaly different. this utility can be used for dumping all kinds of info you could even dump all *.exe's off the machine... most of the time i would try and stay using just straight bat or vbs or autoIT code when including this function into a big script but i cant think of any more elegant way to do this recursive file search... and the exe is only 64kb anyways. Quote Link to comment Share on other sites More sharing options...
DMilton Posted December 5, 2008 Share Posted December 5, 2008 As ever, I must to say it... If you use an alternative installation language, you will get an error when trying to get "%ALLUSERSPROFILE%\Start Menu". But if you answer the registry key for it into HKEY_CLASSES_ROOT\CLSID\{4622AD11-FF23-11d0-8D34-00A0C90F2719} key value, you will find the exact and correct name of the "Start Menu" folder. By example, as all of you know, I'm spanish and if I try to go to "%ALLUSERSPROFILE%\Start Menu" surely I'll can't because my Start Menu is named "Menú Inicio"... It's possible to get in a variable the key of the Start Menú by using a variation of the reliable paths method described by me in the wiki... Or simply using vbs, of course! Take a look if you want! Quote Link to comment Share on other sites More sharing options...
X3N Posted December 5, 2008 Share Posted December 5, 2008 i did this a slightly different way in autoIT basically dumping all .exe files from the programfiles directory. The code isnt super refined yet pretty simple.... takes stdout of the find command and puts the results into a txt file. also an alternative cleaner way to get the reliable paths is to use an autoIT macro like @programfiles etc... which pulls the info from the registry so it isnt language dependant. anyways hers my autoit code... took a second to dump the entire programfiles dir but not too long to not be useful. #include <Constants.au3> $cmd = 'fnd.exe "C:\Program Files" -name *.exe' Local $foo = Run(@ScriptDir & '\' & $cmd, @ScriptDir, @SW_HIDE, $STDOUT_CHILD) Local $line While 1 $line = StdoutRead($foo) If @error Then ExitLoop Filewrite("files.txt",$line) Wend feel free to modify the code to suit your needs.... Quote Link to comment Share on other sites More sharing options...
still learning Posted December 7, 2008 Share Posted December 7, 2008 this is genius..i recently was upset about my u3 walmart switchblade until i found these threads, changed my whole perspective completely Quote Link to comment Share on other sites More sharing options...
Infolookup Posted December 9, 2008 Share Posted December 9, 2008 What do you think about grabbing the cookies and internet history this way you can try to figure out if a user got infected by going to a certain site? Quote Link to comment Share on other sites More sharing options...
Tcstool Posted December 9, 2008 Author Share Posted December 9, 2008 What do you think about grabbing the cookies and internet history this way you can try to figure out if a user got infected by going to a certain site? That's not a bad idea. I have a nice VBScript for this, but it occasionally will hang up on certain systems, so I'm working the kinks out. Quote Link to comment Share on other sites More sharing options...
DMilton Posted December 10, 2008 Share Posted December 10, 2008 That's not a bad idea. I have a nice VBScript for this, but it occasionally will hang up on certain systems, so I'm working the kinks out. I think it's a good idea too. Do you know why it hangs up? What kind of systems it hangs up? If you want us to have a look to the piece of the VBScript, there'll be a good way to debug it by posting it or PM it, as you like. Quote Link to comment Share on other sites More sharing options...
Tcstool Posted December 12, 2008 Author Share Posted December 12, 2008 Thanks to some snow and a day off work, version 1.7 is now posted to the wiki: http://wiki.hak5.org/wiki/U3_Incident_Response_Switchblade Only the slow link is up to date as of right now so download from there. Changes in this version: Capture of the Firefox and IE history files for all users on the machine Capture of the Application and System error event log items (Thanks HarshReality!) Added labels to each section of output (Because I've added so much stuff when I used htis on a job site the other day I couldn't remember what was what!) Enjoy,and throw me feedback out there. HarshReality, still waiting on that HTML output! ;) Quote Link to comment Share on other sites More sharing options...
Jen Posted December 13, 2008 Share Posted December 13, 2008 Can you please make a version with hidden cmd and fix the drive error? Quote Link to comment Share on other sites More sharing options...
Tcstool Posted December 14, 2008 Author Share Posted December 14, 2008 Not being rude, but no: You seem to be the only one having a problem with the drive error, so I see no need to rework the entire thing It is important to see the command window so you can see the status of your evidence collection Quote Link to comment Share on other sites More sharing options...
DingleBerries Posted December 17, 2008 Share Posted December 17, 2008 Are you already dumping the Attached USB logs? Never know if the machine was owned by a U3 hacker.. USB connections history in the registry is maintained under the following key:HKEY_LOCAL_MACHINE\System\ControlSet00x\Enum\USBSTOR The ControlSet in use by the system depends upon the data associated with the following registry value: HKEY_LOCAL_MACHINE\System\Select\Current (Carvey, 2005). Every USB device currently and previously connected to system has the device instance identifier listed under USBSTOR key as shown in figure 5. PDF FILE WARNING Quote Link to comment Share on other sites More sharing options...
HarshReality Posted December 17, 2008 Share Posted December 17, 2008 Here's your addition for the security logs if its of interest.. cscript %WINDIR%\System32\eventquery.vbs /r -10 /fo LIST /l security >> %1\output\%computername%\syslog-%computername%.txt Quote Link to comment Share on other sites More sharing options...
Tcstool Posted December 17, 2008 Author Share Posted December 17, 2008 Here's your addition for the security logs if its of interest.. cscript %WINDIR%\System32\eventquery.vbs /r -10 /fo LIST /l security >> %1\output\%computername%\syslog-%computername%.txt You know I had this tested and sorted out to add. I was on the brink of adding security log dumps but man the security logs on windows machines get SO MESSY! Quote Link to comment Share on other sites More sharing options...
Infolookup Posted December 17, 2008 Share Posted December 17, 2008 I must say I like where this is going the history being displayed as an html file looks great keep up the good work. @ Jen have you tried formating your drive and installing the most recent U3 fireware appilcation for the drive? Also the whole idea of this project is not to be sneaky about hidding the cmd box, just enjoy it for what it is. ;) Quote Link to comment Share on other sites More sharing options...
DMilton Posted December 17, 2008 Share Posted December 17, 2008 Also the whole idea of this project is not to be sneaky about hidding the cmd box, just enjoy it for what it is. ;) I agree that in forensic works, the last you want to see is nothing, there's no sense in hidding the cmd box. This payload was made by Tcstool originaly in forensis works, I agree it can be used for other purposes as grabbing sensible info from a pc, but... Are you already dumping the Attached USB logs? Never know if the machine was owned by a U3 hacker.. PDF FILE WARNING I saw the white papper an the info looks great! You can extract not only the serial number of all attached USB, but the last date it was connected and more... For forensic matters I think is a great implementation. If you want some help in this, I'll be ready on trying to do my best with it. Quote Link to comment Share on other sites More sharing options...
Tcstool Posted December 18, 2008 Author Share Posted December 18, 2008 I agree that in forensic works, the last you want to see is nothing, there's no sense in hidding the cmd box. This payload was made by Tcstool originaly in forensis works, I agree it can be used for other purposes as grabbing sensible info from a pc, but... I saw the white papper an the info looks great! You can extract not only the serial number of all attached USB, but the last date it was connected and more... For forensic matters I think is a great implementation. If you want some help in this, I'll be ready on trying to do my best with it. I had a chance to review the white paper as well...This is great stuff, and will be really easy to add!!!! I will definitely make this a feature. Thanks for the suggestion! Quote Link to comment Share on other sites More sharing options...
DMilton Posted December 22, 2008 Share Posted December 22, 2008 We have to appoint DingleBerries the official digger! Quote Link to comment Share on other sites More sharing options...
subop Posted December 27, 2008 Share Posted December 27, 2008 Personally, I feel an incident response kit is incomplete without AutoRuns. It's extremely common for malware to want to auto run on boot, and AutoRuns enumerates a lot of different start up locations. It can even verify digital signatures, and hide programs that are verified to be from Microsoft making analysis much easier. I use something like autorunsc.exe -a -m -v. Also InjectedDLL from NirSoft can help in detecting stealthy malware that uses DLL injection. I'm also still not sure its a good idea to not follow best practices by collecting data in the order of volatility. If it goes to court and you're asked why you didn't follow best practices like everyone else, I would think you'd need to have a really good reason. Since you're collecting so much data, some of which isn't volatile, it would be nice if you could choose how intrusive you want to be before you run the software. One mode would collect just volatile data, and another collect some non volatile data such as Event Logs. It's also best practice now to collect an image of physical memory before you do anything. I think it would be nice to have an option for that as well, and maybe even the choice on whether to follow the order of volatility or not. Overall I think this toolkit is really cool. Cheers! Quote Link to comment Share on other sites More sharing options...
Tcstool Posted December 28, 2008 Author Share Posted December 28, 2008 Personally, I feel an incident response kit is incomplete without AutoRuns. It's extremely common for malware to want to auto run on boot, and AutoRuns enumerates a lot of different start up locations. It can even verify digital signatures, and hide programs that are verified to be from Microsoft making analysis much easier. I use something like autorunsc.exe -a -m -v. Also InjectedDLL from NirSoft can help in detecting stealthy malware that uses DLL injection. I'm also still not sure its a good idea to not follow best practices by collecting data in the order of volatility. If it goes to court and you're asked why you didn't follow best practices like everyone else, I would think you'd need to have a really good reason. Since you're collecting so much data, some of which isn't volatile, it would be nice if you could choose how intrusive you want to be before you run the software. One mode would collect just volatile data, and another collect some non volatile data such as Event Logs. It's also best practice now to collect an image of physical memory before you do anything. I think it would be nice to have an option for that as well, and maybe even the choice on whether to follow the order of volatility or not. Overall I think this toolkit is really cool. Cheers! Thanks for the feedback: It does check for autoruns in some places, like the Run and RunOnce keys in the registry. Myself and HarshReality have been working on a way to enumerate this without using 3rd party tools (we're trying to eliminate all of them to avoid redistribution issues), hence the hesitance to add additional ones. It might not be a bad idea for now though (If we're distributing one we might as well distribute 100 right?). However, the ones listed don't run silently and use a GUI. Order of data collection is on my personal list to work on; I was trying to round out the data we want collected first. I'd really like to get some feedback on what you think the best order would be. Definitely an easy fix and a nice addtion. Great thought!!! The original concept behind the tool was to be completely non-interactive, so any user could run it at a remote site or whatever. This is why there are no options presented. Something simple like that might not be a bad addition though. It may be we need to fork off this project into another branch for IR professionals vs. this one geared for remote users and system admins. All in all, really good thoughts. we'll definitely work some of this stuff in. Quote Link to comment Share on other sites More sharing options...
subop Posted December 29, 2008 Share Posted December 29, 2008 Easy to use, fool proof software like you've created certainly has it's benefits, but downloading and unziping a program to a directory isn't rocket science for the users :) I think there is a balance that can be found. It might not be good to have 50 different programs people need to download, but for some fairly complex software, personally I don't think there is much need to attempt to recreate it from scratch. autorunsc.exe is the command line version of AutoRuns. I don't think it's documented, but NirSoft's InjectedDLL supports the /stext <filename> option to output data to a file. As for the OOV, I'm probably not the right person to ask. There are people who live and breath Incident Response and Forensics at the ForensicFocus Forums Specifically keydet89, who I believe specializes in Incident Response for Windows. Forking the project would be cool, or just have the following options. 1. Noob 2. Professional With more options under Professional. Note: You may want to rename the Noob option. :) Quote Link to comment Share on other sites More sharing options...
Tcstool Posted December 29, 2008 Author Share Posted December 29, 2008 Good thoughts. I'll mess around with autorunssc and InjectDLL and see if I can get them worked in. The goal is to have a totally automated tool, and while I agree it's not rocket science, it's not within the goals of what we're developing here. This is after all a first responder tool (see Hak5 PhreakNIC epside :-) ). I will look into the volatility issue and see what we can do there. Quote Link to comment Share on other sites More sharing options...
X3N Posted December 29, 2008 Share Posted December 29, 2008 i found a couple real cool tools one a couple of batch downloaders of the sysinternals tools and the nirsoft tools. found on this website. http://smithii.com/si_installer http://smithii.com/nirsoft_installer Quote Link to comment Share on other sites More sharing options...
bdognet Posted December 29, 2008 Share Posted December 29, 2008 These tools are very useful. Thanks for putting them together. I'd suggest you may want to add some tools that are server specific, such as dumping all the DNS records on a domain controller, and all the DHCP records on the DHCP server. Here's a script I use to dump DNS records: dnscmd /enumzones > zones.txt for /f %%a in (zones.txt) do dnscmd /enumrecords %%a @ > %%a.txt thanks for putting this together! Quote Link to comment Share on other sites More sharing options...
Infolookup Posted February 2, 2009 Share Posted February 2, 2009 Has anyone tried to utilized the Firefox and IE History script? I have a PC that was infected and prior to blowing it out we extracted the IE history files and FF profiles I would like to use the script and statically point it to those files but its erroring out.. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.