<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Windows Work Folders — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/windows-work-folders/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 03 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/windows-work-folders/feed.xml" rel="self" type="application/rss+xml"/><item><title>Signed Proxy Execution via MS Work Folders</title><link>https://feed.craftedsignal.io/briefs/2024-01-03-workfolders-control-execution/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-03-workfolders-control-execution/</guid><description>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.</description><content:encoded><![CDATA[<p>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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to the target system through an unspecified means (e.g., phishing, exploiting a vulnerability).</li>
<li>The attacker places a malicious executable and renames it to <code>control.exe</code> in a directory accessible to Work Folders.</li>
<li>The attacker configures Windows Work Folders to synchronize the directory containing the malicious <code>control.exe</code>.</li>
<li>The victim system synchronizes with the Work Folders server, copying the malicious <code>control.exe</code> to the local machine.</li>
<li>The attacker triggers the <code>WorkFolders.exe</code> process.</li>
<li><code>WorkFolders.exe</code> executes the <code>control.exe</code> binary from the synced folder.</li>
<li>The malicious <code>control.exe</code> executes, performing attacker-defined actions such as establishing persistence, escalating privileges, or deploying additional malware.</li>
<li>The attacker achieves code execution in a potentially elevated context, leveraging a signed Microsoft binary (<code>WorkFolders.exe</code>) to bypass security controls.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows attackers to execute arbitrary code on a victim&rsquo;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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Monitor process creations where <code>WorkFolders.exe</code> is the parent process and <code>control.exe</code> is the child process, but <code>control.exe</code> is not located in a standard Windows system directory (Sigma rule: &ldquo;Detect Suspicious WorkFolders Control Execution&rdquo;).</li>
<li>Investigate any instances where <code>control.exe</code> is executed from unusual or user-writable locations, especially if <code>WorkFolders.exe</code> is involved (see Attack Chain step 6).</li>
<li>Enable Sysmon process creation logging (Event ID 1) on Windows systems to capture the necessary data for the provided Sigma rules.</li>
<li>Review the Microsoft documentation on Windows Information Protection (WIP) and consider implementing it to encrypt data on PCs using Work Folders.</li>
<li>Implement application control policies that restrict the execution of <code>control.exe</code> to authorized locations (e.g., <code>C:\Windows\System32</code>).</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>defense-evasion</category><category>masquerading</category><category>windows</category></item></channel></rss>