Open Ana06 opened 7 months ago
I'd vote for the environment variable route to avoid future synchronization issues with different packages. For example, if you update flare.sysinternals.vm
you will likely have to update commando.sysinternals.vm
and that could be very annoying to have to update multiple packages frequently.
Another option is to consider per-package customizations (this is something I've always wanted). I can imagine per-package customizations working as follows:
config.xml
(e.g., https://github.com/mandiant/flare-vm/blob/main/config.xml)common.vm
script with new functions that can read and action per-package customizations from the config.xml
sysinternals.vm
) to apply per-package customizationsThere would likely need to be a standardized interface for per-package customization options that are supported (e.g., package shortcut mappings). I can image something like the below:
FLARE VM: config.xml
<package name="sysinternals.vm">
<shortcuts>
<shortcut category="Utilities" exe_name="procexp" />
<shortcut category="Utilities" exe_name="procmon" />
<shortcut category="Utilities" exe_name="ADExplorer" />
</shortcuts>
</package>
COMMANDO VM: config.xml
<package name="sysinternals.vm">
<shortcuts>
<shortcut category="Utilities" exe_name="procexp" />
<shortcut category="Utilities" exe_name="procmon" />
<shortcut category="Reconnaissance" exe_name="ADExplorer" />
</shortcuts>
</package>
I am in agreeance with @MalwareMechanic I think env variables would be the quickest route but also this opens an opportunity to build in a new feature (per-package customizations), so that is what would get my vote
Some of my thoughts...
One issue I could see with something like adding the specific tools to config.xml
might be if someone from either CommandoVM
or FlareVM
did want to add a specific tool from a suite package that was set as a tool in the others config.xml
but not in their own, how would they be able to get it?
config.xml
, which is fine, but we need to notate that somewhere in our documentation.What happens to tools from a suite that both VM's don't want?
Another potential issue is keeping categories
in sync between configs if we go the route of putting packages into config.xml
, albeit a smaller synchronization issue than having a flare.sysinternals.vm
& commando.sysinternals.vm
, since categories shouldn't change often, but also...there could be the potential that we may want different categories for the same tool.
.xml
that we place inside of sysinternals.vm
, similar to https://github.com/mandiant/VM-Packages/blob/main/packages/libraries.python3.vm/tools/modules.xml, but is instead more similar to how you're suggesting the layout to be inside of each VM's config.xml
. Possibly with <vm name="flare">
and <vm name="commando">
at the top instead of the package name
xml
that is located where we would expect to modify things related to that specific package and still give us flexibility for how we want things to look in each VM.In all though, I do like the idea of the per-package customization options, and adding it into the config.xml
for each wouldn't be a bad idea. 🙂
I think I would prefer keeping package customizations inside of the package, like placing a single .xml
file into the packages themselves.
One issue I could see with something like adding the specific tools to config.xml might be if someone from either CommandoVM or FlareVM did want to add a specific tool from a suite package that was set as a tool in the others config.xml but not in their own, how would they be able to get it? It seems that the only way would be to pass in a custom config.xml, which is fine, but we need to notate that somewhere in our documentation.
Just to clarify, a "suite package" is a package that installs a suite of tools like sysinternals.vm
right? I can see four scenarios assuming we used the config.xml
for per-package customizations:
config.xml
for that VM flavor specifies the shortcut category locations to install for different tools in the suite.config.xml
to specify the shortcut category locations to install for different tools in the suite.What happens to tools from a suite that both VM's don't want? I think it would be nice to have a place somewhere for tools that aren't used from either package, for the case that someone who is making their own custom config knows what all might be available and can choose some from the list, and also gives us awareness for if we want to add one from the list in the future.
Good point! We'd likely need a documentation page to cover customizable options for the packages that support customization. A machine readable format could be useful if we wanted a more sophisticated installer that would allow per-package customization. The installer could parse the machine readable documentation and dynamically show the per-package customization options. That'd be cool!
Another potential issue is keeping categories in sync between configs if we go the route of putting packages into config.xml, albeit a smaller synchronization issue than having a flare.sysinternals.vm & commando.sysinternals.vm, since categories shouldn't change often, but also...there could be the potential that we may want different categories for the same tool. An alternative I can think of is just a single .xml that we place inside of sysinternals.vm, similar to https://github.com/mandiant/VM-Packages/blob/main/packages/libraries.python3.vm/tools/modules.xml, but is instead more similar to how you're suggesting the layout to be inside of each VM's config.xml. Possibly with
and at the top instead of the package name This gives us the ability to consider a single xml that is located where we would expect to modify things related to that specific package and still give us flexibility for how we want things to look in each VM. We would need some sort of environment variable (or other alternative) that is set to distinguish between which installer is running.
So in terms of "customization" I think the location of the customization is important. If the options are stored in the package itself, then the options can only be updated via a pull request. If they are stored in the config.xml
, the options become dynamic and can easily be changed by us and users.
We could have the best of both worlds:
.xml
file. These would be options that make each flavor feel like that flavor. We'd likely need a env
variable or something like you proposed to differentiate between them during install.config.xml
that are easily changeable. I could see these overriding the predefined flavor options in option 1 above.In general, I've always wanted per-package customizations at the config.xml
level so we could change package categories more easily -- like a mapping of package to category.
Details
Since https://github.com/mandiant/VM-Packages/commit/f55f6f51e3aea53d1ec82f42d76bc4cdee45b930 sysinternals is creating a shortcut for ADExplorer in Reconnaissance. Do we want this tool in FLARE-VM? If not, how do we do it to install different shortcuts for flare-vm and command-vm? Ideas:
@mandiant/vms opinions?