Fix URL-encoded filesystem entries in the Velociraptor loader

[Zawadidone]

Closes #707 and #708

[Schamper]

Wouldn't this also be an issue on non-zip (directory) Velociraptor targets?

[Zawadidone]

@Schamper yes it will, I would like to enforce the usage of a ZIP file as target, because extracting a ZIP file causes all kinds of errors. For example, the only option to extract a ZIP file in an automated manner is with unzip -o [...], which enables overwriting existing files without prompting, which possible removes valuable traces.

Should this explicitly be documented in the comments of the loader or should the loader also support a non-zip directory Velociraptor target?

[Schamper]

We don't use Velociraptor so I can't really speak for it, but I do think I've heard people say they sometimes work with unzipped collections. If there are no other reasons to drop support for it, I'd suggest to let it in.

I'm not a huge fan of the explicit URL decoding under a generic decode_name flag, but I don't immediately have a better suggestion. I was thinking maybe to pass a callback function, but I'm not sure I like that either 😄. I'll also throw it up for discussion in the team to see if anyone has a nice idea.

[Schamper]

After a short discussion we decided it may be best to tweak the ZipFilesystem and DirectoryFilesystem implementations slightly to facilitate customization by subclasses a little better. You can then subclass these filesystems within your loader and provide the customized behaviour. This subclass can live within the same file as the loader as far as I'm concerned (we also do this in other cases where we e.g. subclass the registry plugin to provide a custom implementation).

I've created #707 and #708 to implement this in the respective filesystems. Would you be up for making these changes?

[Zawadidone]

Yes but I don't understand how to fix the issues. I will add comments to the issues.

[OlafHaalstra]

Would be nice to keep the support for a non-zipped folder since we noticed a huge hit on performance when working with zip archives rather than unzipped directories.

@Zawadidone wondering if you do not have the same problem with zipped vs unzipped

[OlafHaalstra]

To add to the need for this.

Example, the following path is not picked up by target-*:

uploads/auto/C%3A/Users/Test/%2Essh/known_hosts 

This totally makes sense since the openssh module is looking for the .ssh folder:

Can we include the fix not only for the zip loader, but also for the folder loader?

[OlafHaalstra]

@Schamper yes it will, I would like to enforce the usage of a ZIP file as target, because extracting a ZIP file causes all kinds of errors. For example, the only option to extract a ZIP file in an automated manner is with unzip -o [...], which enables overwriting existing files without prompting, which possible removes valuable traces.

Should this explicitly be documented in the comments of the loader or should the loader also support a non-zip directory Velociraptor target?

@Zawadidone Under which circumstances do you run into files that are overwritten?

[Zawadidone]

Would be nice to keep the support for a non-zipped folder since we noticed a huge hit on performance when working with zip archives rather than unzipped directories.

@Zawadidone wondering if you do not have the same problem with zipped vs unzipped

Yes we have the same performance hit when working with a collection stored in a ZIP file, but only when executing the MFT plugin. The other plugins are 'fast' but that's only because they return less records compared to the MFT plugin.

I haven't had the time for it, but I want to look into solving the following issues:

• Improving the speed of the MFT plugin by reading the MFT records using the segment size (Parse MFT records based on segment numbers #665)
• Debugging performance issues with the MFT plugin when using a collection stored in a ZIP file

[Zawadidone]

To add to the need for this.

Example, the following path is not picked up by target-*:

uploads/auto/C%3A/Users/Test/%2Essh/known_hosts 

This totally makes sense since the openssh module is looking for the .ssh folder:

Can we include the fix not only for the zip loader, but also for the folder loader?

Yes this PR will include a fix for both the ZIP as well as the DIR loader.

[Zawadidone]

@Schamper yes it will, I would like to enforce the usage of a ZIP file as target, because extracting a ZIP file causes all kinds of errors. For example, the only option to extract a ZIP file in an automated manner is with unzip -o [...], which enables overwriting existing files without prompting, which possible removes valuable traces.
Should this explicitly be documented in the comments of the loader or should the loader also support a non-zip directory Velociraptor target?

@Zawadidone Under which circumstances do you run into files that are overwritten?

On Linux systems that use symlinks see #699, but this could occur on all kind of systems that use symlinks.