split sysinternals (commando-vm vs flare-vm shortcuts)

[Ana06]

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:

• introducing flare.sysinsternals.vm and commando.sysinternals.vm packages that require sysinternals.vm and create the specific shortcuts
• install different shortcuts depending on an env variable (for commando-vm and flare-vm) in sysinternals.vm

@mandiant/vms opinions?

[MalwareMechanic]

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:

• Add per-package customizable fields in the config.xml (e.g., https://github.com/mandiant/flare-vm/blob/main/config.xml)
• Update the common.vm script with new functions that can read and action per-package customizations from the config.xml
• Use the new functions in specific packages (e.g., sysinternals.vm) to apply per-package customizations
• If no customizations provided, use default behavior

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

[day1player]

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

[emtuls]

Some of my thoughts...

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

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

3. 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 <vm name="flare"> and <vm name="commando"> 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.

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

[day1player]

I think I would prefer keeping package customizations inside of the package, like placing a single .xml file into the packages themselves.

[MalwareMechanic]

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:

1. During a regular VM install, the pre-defined config.xml for that VM flavor specifies the shortcut category locations to install for different tools in the suite.
2. During a non-regular VM install (e.g., a custom VM flavor), the user would provide a custom config.xml to specify the shortcut category locations to install for different tools in the suite.
3. During a non-regular VM install, the user does not provide any customizations. The package would install the "default" set of shortcuts.
4. Pre-existing VM user wants a different mapping of shortcuts to category, then they'd need to perform a fresh install unfortunately since there's no easy way to update them.

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:

1. Have package-specific customizations for pre-baked VM flavors (e.g., FLARE & Commando) in a package-local .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.
2. Have user-defined customizations in 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.