Allow specification of different Target Drive

[joeavanzato]

Allow specification of different Target Drive

[joeavanzato]

The way I think I will approach this is to check if this parameter is set with a target such as 'D:' and then create script-level variables which will be used instead of the actual environment variables - in the case this isn't specified, these will represent the actual environment variables. If this is set, the drive letter will simply be replaced. There will be some edge cases that present issues but they can likely all be worked out - this will assume a 'standard' Windows installation where most items are in the default locations. This will at least allow inspection of file-based artifacts.

I am still brainstorming best approach for registry/service/task/etc artifacts as these are all currently acquired via PowerShell cmdlets rather than direct XML or file inspection - may have to either skip or change how these are approached longeterm.

[joeavanzato]

Registry Approach:

For HKLM Hives (SOFTWARE, SYSTEM, etc) - these can be loaded from $targetdrive\Windows\System32\config (assuming they are in a healthy state).

If a remote drive is specified using '-drivetarget', paths to the relevant hives will be collected and mounted underneath the current HKLM but with the names prefixed with 'ANALYSIS_' - so for example, a SYSTEM will be mounted as 'HKLM\ANALYSIS_SYSTEM' - then a global script variable will be used to re-target all registry references so anything which previously used 'HKLM\SYSTEM' will instead use 'HKLM\ANALYSIS_SYSTEM' and so on.

User hives are still being worked out as I already had plans to iterate through the HKEY_USERS hives as opposed to just using HKCU - so I will probably finish that functionality with this together to make scanning more robust. Then we can do the same thing with NTUSER.DAT hives as described above.

[joeavanzato]

User hives are now fully implemented - when running locally, trawler will use all of the hives under HKU instead of just HKCU.

When performing a drive retarget, existing profiles will be scanned for NTUSER.DAT and USERCLASS.DAT files - these will be loaded under HKU as 'ANALYSIS_$PROFILENAME' and 'ANALYSIS_$PROFILENAME_Classes' respectively.

Working on ensuring each check now uses this list of hives instead of base HKCU still. HKLM hive retarget references are mostly done. Any 'file-based' artifact is also mostly done except for Scheduled Tasks and parsing WMI repository (OBJECT.DATA) and BITS Jobs database files.

[joeavanzato]

This is now mostly handled - there are a few small bugs that are still being worked out but using the '-drivetarget' parameter the user can specify the base location of a Windows install that may exist in another location besides 'C:' for inspection which will result in loading detected registry hives and re-targeting file-based inspections. A few checks do not function with this yet (WMI, BITS) but that is being worked on.