Skip to content
Threat Feed
medium advisory

Signed Proxy Execution via MS Work Folders

Attackers can abuse Windows Work Folders to execute a masqueraded control.exe file from untrusted locations, potentially bypassing application controls for defense evasion and privilege escalation.

Windows Work Folders is a Microsoft file server role that allows users to sync work files between their PCs and a central server. The WorkFolders.exe process, when called, will automatically execute any Portable Executable (PE) named control.exe as an argument before accessing the synced share. Attackers can abuse this functionality by placing a malicious executable renamed to control.exe in a location synced by Work Folders, and then triggering WorkFolders.exe. This can lead to the execution of arbitrary code in a manner that bypasses application control policies, as WorkFolders.exe is a signed Microsoft binary. This technique has been observed in the wild and documented by security researchers. This allows attackers to execute code from locations outside the standard Windows directories, evading traditional detection mechanisms.

Attack Chain

  1. An attacker gains initial access to the target system through an unspecified means (e.g., phishing, exploiting a vulnerability).
  2. The attacker places a malicious executable and renames it to control.exe in a directory accessible to Work Folders.
  3. The attacker configures Windows Work Folders to synchronize the directory containing the malicious control.exe.
  4. The victim system synchronizes with the Work Folders server, copying the malicious control.exe to the local machine.
  5. The attacker triggers the WorkFolders.exe process.
  6. WorkFolders.exe executes the control.exe binary from the synced folder.
  7. The malicious control.exe executes, performing attacker-defined actions such as establishing persistence, escalating privileges, or deploying additional malware.
  8. The attacker achieves code execution in a potentially elevated context, leveraging a signed Microsoft binary (WorkFolders.exe) to bypass security controls.

Impact

Successful exploitation allows attackers to execute arbitrary code on a victim’s machine, potentially bypassing application control and other security measures. This can lead to a range of malicious activities, including data theft, system compromise, and lateral movement within the network. Given the legitimate use of Work Folders, identifying malicious executions can be challenging, potentially allowing attackers to maintain a persistent foothold. The lack of specific victim counts or industry targeting details in the source material limits a complete assessment of impact scope.

Recommendation

  • Monitor process creations where WorkFolders.exe is the parent process and control.exe is the child process, but control.exe is not located in a standard Windows system directory (Sigma rule: “Detect Suspicious WorkFolders Control Execution”).
  • Investigate any instances where control.exe is executed from unusual or user-writable locations, especially if WorkFolders.exe is involved (see Attack Chain step 6).
  • Enable Sysmon process creation logging (Event ID 1) on Windows systems to capture the necessary data for the provided Sigma rules.
  • Review the Microsoft documentation on Windows Information Protection (WIP) and consider implementing it to encrypt data on PCs using Work Folders.
  • Implement application control policies that restrict the execution of control.exe to authorized locations (e.g., C:\Windows\System32).

Detection coverage 2

Detect Suspicious WorkFolders Control Execution

medium

Detects execution of control.exe by WorkFolders.exe from non-standard locations, indicating potential masquerading.

sigma tactics: defense_evasion techniques: T1036.005, T1218 sources: process_creation, windows

Detect WorkFolders.exe Executing control.exe

low

This rule detects WorkFolders.exe executing control.exe, which may indicate malicious activity if the execution path is unexpected.

sigma tactics: defense_evasion techniques: T1218 sources: process_creation, windows

Detection queries are kept inside the platform. Get full rules →