Harden Fibratus against tampering

[rabbitstack]

Motivation

Fibratus runs as a security-sensitive detection sensor, which makes it a natural target for an attacker trying to disable, kill, or reconfigure it to blind detection before proceeding further. Today there's no built-in tamper resistance. The install directory, the Windows service, the running process, and the service registry key are all as accessible as any ordinary application, meaning a local admin-level attacker (or malware running as one) can simply stop the service, kill the process, or delete the binaries.

Expectation

Fibratus becomes meaningfully harder to disable or tamper with from a local attacker's perspective, across every layer where it's currently exposed: install directory, Windows service, running process, registry configuration, and process mitigation policies, plus a watchdog that restores it if it's killed anyway.

Proposal

• Install directory ACLs to restrict NTFS permissions on the Fibratus install directory and all child directories/files to SYSTEM and Administrators only, via windows.SecurityDescriptorFromString with an SDDL such as D:P(A;OICI;FA;;;SY)(A;OICI;FA;;;BA) (full control to SYSTEM and Builtin Administrators, protected ACL so it doesn't inherit weaker permissions from the parent)
• Windows service hardening to deny SERVICE_STOP and DELETE to everyone except SYSTEM, so the service can't be stopped or removed by a regular admin token or a compromised lower-privileged process. Set this via the WiX Toolset's PermissionEx attribute on the ServiceInstall directive using an SDDL like D:(A;;RPWPDTLOCRRC;;;SY)(A;;CCLCSWLOCRRC;;;BA)(D;;WPDT;;;WD). SYSTEM gets full control, Administrators get read-only query/enumerate rights, and Everyone is explicitly denied stop/delete
• Process DACL hardening via SetSecurityInfo to deny PROCESS_TERMINATE to Everyone except SYSTEM on the running Fibratus process, so it can't be killed via TerminateProcess from a non-SYSTEM context.
• Registry key protection for locking down the service's registry key at HKLM\SYSTEM\CurrentControlSet\Services\Fibratus via SetNamedSecurityInfo, preventing tampering with service configuration (e.g. changing the binary path, start type, or failure actions) from non-SYSTEM/Administrator contexts
• Process mitigation policies. Evaluate programmatically setting/overriding process mitigation options per the Windows mitigation options guidance, to reduce the attack surface for code injection or exploitation targeting the Fibratus process itself
• Watchdog process. Build a separate lightweight watchdog that periodically checks whether the Fibratus process is alive and respawns it if it has died or been terminated, providing a second line of defense on top of the ACL/DACL hardening above.

Additional context

• These layers are complementary rather than redundant: DACL hardening prevents casual termination, but a sufficiently privileged attacker (e.g. SYSTEM-level compromise) could still bypass it. The watchdog provides resilience even if a single layer is defeated, and vice versa
• Worth deciding whether hardening is applied unconditionally on install/service start, or gated behind a config flag. Some environments may want it opt-in initially given the operational risk of a misconfigured SDDL locking out legitimate management tooling
• The watchdog itself will need to be considered as part of the threat model. It should probably receive equivalent tamper protections (service/process DACLs), or an attacker could simply target the watchdog instead of Fibratus directly