Jump to content

U3 Incident Response Payload


Tcstool

Recommended Posts

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

Link to comment
Share on other sites

  • Replies 128
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
Share on other sites

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! :lol:

Take a look if you want!

Link to comment
Share on other sites

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....

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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! ;)

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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. ;)

Link to comment
Share on other sites

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. :lol:

Link to comment
Share on other sites

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. :lol:

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!

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 &gt; zones.txt
for /f %%a in (zones.txt) do dnscmd /enumrecords %%a @ &gt; %%a.txt

thanks for putting this together!

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...