I am on a Windows 11 domain-connected device. My enterprise uses Microsoft Defender with various attack surface reduction rules enabled.
One ASR rule is blocking Syncthing: “Block process creations originating from PSExec and WMI commands”
While Microsoft provides local ways to disable this rule, they are accompanied by a warning that even if you are a local admin, your attempts at overriding enterprise rules will be trumped by Microsoft Defender’s “enterprise-level management platform”.
Are there any alternatives for making Syncthing work?
The issue is with process creation, not with the mere presence of files.
The installation went fine except for one thing:
On a non-domain-controlled Windows 10 device, the very last step was fast. I am guessing that last step confirms that Syncthing is running? If true, it invites me to open its configuration page on the very last step.
On the domain-controlled Windows 11 device, the last step takes several seconds. I am guessing that is because of a timeout or other detected issue while trying to start up Syncthing or while waiting to verify its running? The final dialog on the installer does not provide that checkbox to open the configuration page. (This is probably an installer bug! Because the checkbox is missing suggests the installer knows there is a problem. The installer did not report a problem to me, and it should have.)
On a non-domain-controlled Windows 10 device, the very last step was fast. I am guessing that last step confirms that Syncthing is running? If true, it invites me to open its configuration page on the very last step.
On the domain-controlled Windows 11 device, the last step takes several seconds. I am guessing that is because of a timeout or other detected issue while trying to start up Syncthing or while waiting to verify its running? The final dialog on the installer does not provide that checkbox to open the configuration page. (This is probably an installer bug! Because the checkbox is missing suggests the installer knows there is a problem. The installer did not report a problem to me, and it should have.)
The “open configuration page” option on the final wizard page was a user request (see issue 14). The way this (currently) works is that the installer does run a WMI query to determine if the syncthing.exe process is running. It waits up to 10 seconds (the latest, not-yet-released version of the installer shortens this to 5 seconds–10 seconds is too long) to see if Syncthing is running.
The reason for the delay is that the user might not have selected to start Syncthing (service or not), and displaying the checkbox is pointless if Syncthing isn’t running, so there’s a few seconds delay for the WMI query. (The reason for the delay is that if the query runs too soon after starting Syncthing, service or not, it returns no results.) So this is actually by design (not a bug): If Syncthing isn’t running, there will be short delay before the installer finishes.
Sigh I will look into a different way of hiding or displaying that checkbox. (Good grief; anti-malware is complaining about running a WMI query that doesn’t make any changes? This is really getting ridiculous…)
TLDR: Syncthing Windows Setup does run a WMI query. It does not use psexec. (Now that we’re getting to the silly extreme of blocking all WMI queries, I’ll re-evaluate the WMI part.)
That is about how long the installer waits before showing me the last screen. I guess because the check fails, I am not invited to open the configuration page on the last screen. That is where I feel the installer could be improved: If the check fails and if user select the option to start syncthing, it would be good to warn the user.
I want to be clear that the issue is with starting syncthing, not in merely placing it on the filesystem. I can reproduce the Windows Defender event any time I try to start up.
Does the same issue occur when the actual syncthing.exe is started? (i.e. the official binary executable from the Syncthing project)
(?) That’s what Syncthing Windows Setup does–it starts the official binary executable from the Syncthing project.
If Syncthing isn’t starting from Setup when you’ve selected to start it, the question, of course, would be why it isn’t starting. To know that, I would recommend finding out if the problem is reproducible and also using the /log parameter on the installer command line to produce a log file. The content of the log may be instructive.
As an aside: Blocking process creation using WMI for the current user is quite a silly thing to do. There’s nothing magic about creating a process using WMI; processes created by WMI don’t gain magical powers that other processes don’t have.
Apologies, I am speaking to more of a traditional sense of an installer, where the installer just throws the program on your system and you run the program separately, like as with Microsoft Office.
So yes, installing triggers the issue likely because it’s starting Syncthing. I can also trigger the issue by using the Start Syncthing icon in my start menu .
Through some trivial Google searching, I can find several examples of concerns about WMI and recommendations of restricting access to it.
Keep in mind that in a corporate setting, administrators may wish to restrict access to a tool for reasons beyond just traditional vulnerabilities. Data exfiltration, process snooping, etc. are general concerns that may influence decisions.
At least temporarily, I’d recommend not using any scripting platform until it’s been ruled out if there is egress filtering that would prevent Syncthing from functioning properly. Because if there is, it’s pretty much a dead end.
Once it’s been verified that Syncthing can be started directly, but not indirectly via an external script and/or wrapper, then the focus can be on getting the script/wrapper working in your managed Windows environment.
If the syncthing.exe binary executable is readily accessible via Windows Explorer on your workstation, simply double-click it to launch.
However, if the syncthing.exe executable on your workstation isn’t readily accessible, download the official release (same one used by Syncthing Windows Setup):
No installation necessary. Just double-click the zip file to open the archive, then depending on the local policy settings, you may be able to run syncthing.exe directly from the open archive folder. If not, drag syncthing.exe (the other files are optional) to a desired folder and double-click to launch.
Either way, Windows will open a command-prompt to run syncthing.exe in (leave the command-prompt window open for the duration of the test).
If your default web browser doesn’t automatically open and display Syncthing’s web GUI, copy-and-paste the following URL or simply click it: http://127.0.0.1:8384/
sigh This is because StartSyncthing.js indeed uses WMI to start syncthing.exe without a console window and “below normal” process priority.
I’ll reiterate: Blocking WMI from creating a process as the current user is pointless because the process starts as the current user. Just because WMI started the process doesn’t mean it gains magical powers to do anything the current user cannot do. It’s just a normal user process, just like if the user double-clicked on the executable from the Explorer. In this case, there’s nothing nefarious about the fact that WMI started the process.
That works! If I open PowerShell, change to the C:\Users\[username]\AppData\Local\Programs\Syncthing directory (I did a one-user install), and just run syncthing.exe, it works!
That means the issue is not the application itself, the issue is with how it is being started.
A problem: Syncthing doesn’t go to the background. I can’t get the command line back or close the PowerShell window unless I kill the Syncthing process. Is there a recommended way of doing this? I checked the command-line options and nothing stood out in a quick review.
Just curious, why not make it work like a standard Windows service? I could use NSSM to do it manually, but that may make upgrades fragile?
Syncthing Windows Setup runs Syncthing as a service if you install in administrative (all users) installation mode. The caveat is you have to manually add permissions to synchronized folders so the service account can access them. (The documenation spells all of this out.)
Regarding WMI: I stand by the fact that blocking WMI process creations for the current user is pointless and doesn’t improve security (and in fact, needlessly prevents a legitimate use of WMI).
Nonetheless, I will go ahead and develop a new tool for starting and stopping Syncthing for the current user. It’s ridiculous that this is even necessary, but it is what it is. (It seems there’s about as much paranoia regarding WMI as there is with PowerShell…)