Implement .msi installation package for the agent instead of powershell-based installation script

[cr-secion]

The current agent installation method using the powershell script (install-sysmon-beats.ps1) has several drawbacks, making it unsuitable for many production deployments:

• Installation via powershell scripts is not a viable approach considering common software deployment tools.
• It cannot always be expected that powershell is always available, as it may be blocked or disabled on hardened systems.
• If powershell logging is enabled on client systems, script execution and plaintext credential data may get logged to the windows eventlog, which may have a security impact.
• The current implementation downloads winlogbeat and sysmon from the internet, which may not be always possible or violate existing security policies.
• The installation procedure is completely manual and therefore does not get tracked via Windows Installer. This means, that Sysmon and Winlogbeat may not get identified for software inventory, undermining patch management efforts which may result in unmanaged security risks. Furthermore, no proper OS provided uninstall mechanism is available.
• There is quite some variance of powershell versions installed on client systems,that react quite different and lead to situations that require manual troubleshooting.

Having done some research in the last days, I'd propose to use a .msi installation file instead of a .ps1 installation script. The benefits would be the following:

• Pretty much the standard method to deploy software in Windows environments.
• Sysmon and winlogbeat program files can be included in the msi archive.
• Configuration files can be included and properly defined.
• Msi packages have built-in mechanisms for command execution. Executing powershell will therefore not be necessary anymore, e.g. to install credential data into keystores, accept the sysmon EULA etc.
• They also include proper ways to install and configure services.
• Package generation works by feeding in a XML data (.wxs) defining all its aspects, which may make the whole installation procedures more maintainable compared to the current monolithic powershell script.
• Several requirement checks can easily be implemented (e.g. admin permissions, Win10 or higher for Sysmon compatibility).

The msi packages may actually be generated on the espy server itself, as there is a pretty lightweight toolkit with the name msitools available in Ubuntu repositories (https://wiki.gnome.org/msitools).

Quite a good documentation to get started with the aforementioned wxs-XML can be found here: https://www.firegiant.com/wix/tutorial/getting-started/. Also hints for service installation (https://wixtoolset.org/documentation/manual/v3/howtos/general/install_windows_service.html) and general code exec (https://www.firegiant.com/wix/tutorial/events-and-actions/extra-actions/).

Following is just an idea, but this may also be a good opportunity to put Sysmon and winlogbeat into its own Application folder (%ProgramFiles%\Active Countermeasures\Espy?), get config files and logs also in consistent seperate folders, and maybe rename the winlogbeat service to something espy related, to keep the espy-agent-components more separated from potential existing programs already installed on the system.

[fullmetalcache]

Hey Clemens,

Thanks for writing up this issue!

One thing that I will note is that we can't include winlogbeat or sysmon within an installer. This is due to the licenses for those packages. We chatted about this today and decided that what we can do is allow for users to point the installer to an internally-hosted location. This would comply with licensing for the packages while not requiring systems to traverse to the public internet.

We will do some more research on what it will take to create an MSI package for Espy and keep you posted.

Thanks!