Hey Checkyourlogs Fans,

Today, we will look at a Security Recommendation regarding a Service Executable Path not being in a safe location via Microsoft Defender Endpoint.

Changing the service executable path to a common protected location is a crucial aspect of ensuring the security and reliability of software applications. Developers are advised to select secure, standardized directories for housing service executables to minimize the risk of unauthorized access, tampering, or exploitation. Common protected locations often include system folders such as “C:\Program Files” or “C:\Program Files (x86)” on Windows and “/usr/local/bin” or “/opt” on Linux. These directories are restricted and have limited user access, reducing the likelihood of malicious interference. Developers should refrain from using user-specific directories or root directories, as these locations may expose the application to security vulnerabilities. By adhering to established best practices and placing service executables in these secure directories, developers contribute to a more robust and secure software environment, safeguarding against potential threats and ensuring the integrity of the system.

Indeed, when developing Windows Admin Center plug-ins that involve services running in the system context, the security considerations become even more critical. Services operating with system-level privileges have elevated access and can significantly impact the system’s overall security. Therefore, following the executable path guidelines to mitigate potential risks is very important.

Utilizing directories such as “C:\Program Files” or “C:\Program Files (x86)” remains essential, even more so when dealing with services running under the system context. Placing services on the root of the C: drive, in this context, becomes not only insecure but potentially disastrous, as any compromise could lead to widespread system vulnerabilities.

By following best practices, developers enhance the security of their Windows Admin Center plug-ins and contribute to the overall resilience of the systems they interact with. Robust security measures, coupled with careful consideration of executable path locations, help fortify against unauthorized access, exploitation, and potential compromise of critical system components, thereby establishing a more secure computing environment.

Today, we had a very old deployment of the Data ON Must Service, an extension to Microsoft’s Flagship Windows Admin Center. Here is the security recommendation that was flagged in Defender Endpoint.

Our exposure to this was very limited, with only 1 of 53 devices.

So, as I dug into this to see exactly which service it was and I can see it is the MUSTService

Now, this was from a very old deployment of the Windows admin center, but to my point of the previous 3 posts. There are often remnants left behind from previous installs, and this can be a form of a backdoor for an attacker, especially in a secure environment.

The Windows Admin Center is particularly interesting to me because when you choose extensions from the catalogue, you are not given a choice regarding where they get installed.

This is clearly violating best practices of security and Microsoft should have put safeguards in place to not let this happen.

At the end of the day, a developer, software house, or hardware vendor built this solution that went onto one of our servers.

My most significant advice is always to check to see precisely what is being installed in your environment before it is a problem.

This was flagged during a security audit, and the remediation wasn’t straightforward as the instance of Windows Admin Center was gone.

So now we are left with remnants installed and must intervene manually.

Because it was installed with Windows Admin Center there is no object in Add/Remove Programs to get rid of it.

So, in step 1, I looked at the service itself.

Indeed, we could see the path on the C:\MUST_Service\mustservice.exe

Now you cannot just go to the folder and remove the contents as the service was running.

So first stop the service.

Or you will see something like this.

I removed the service manually by running it.

SC delete must service.

From an admin PowerShell prompt

This is just an example of how things get left behind, and we often forget or even know we must clean them up.

Ownership of this issue falls with our team because we were the ones who clicked the button to install it.

So, if you install it, you must perform your security review and due diligence.

Now is this good coding practice? I’d probably say no. But I also haven’t checked later versions of the extensions to see if this is still an issue, nor have I contacted the vendor.

I’ve seen this numerous times with other vendor solutions not deploying their code to trusted locations.

We don’t use Windows Admin Center at this location and, as such, didn’t have any other instances of this issue.

I hope you enjoy the post, and please always review your application servers / HCI Hosts. They do need care and feeding.

Thanks,

John O’Neill Sr.

Microsoft Security MVP