Evading-Security-Controls - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/evading-security-controls/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 01 Sep 2026 12:19:51 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgSuspicious Dynamic .NET Compilation via Csc.exehttps://feed.craftedsignal.io/briefs/2026-09-dynamic-dotnet-compilation/Tue, 01 Sep 2026 12:19:51 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-dynamic-dotnet-compilation/Attackers utilize the C# compiler (csc.exe) to dynamically compile and execute malicious code in memory, enabling evasion of signature-based defenses and EDR hooks.The C# compiler (csc.exe) is a legitimate component of the .NET framework used for building source code into assemblies. Threat actors, including groups observed in MuddyWater operations and campaigns utilizing Agent Tesla, abuse this utility to perform dynamic, on-the-fly compilation of malicious payloads. By compiling code directly on the target host, attackers avoid writing static malicious binaries to disk, thereby bypassing traditional file-based signature detection. This technique is often employed in the post-exploitation phase to execute custom loaders, stagers, or modules that interact with system APIs to disable security instrumentation or perform further reconnaissance. Defenders should monitor for csc.exe process creation events occurring within non-standard execution paths, such as temporary user directories or user-profile subfolders, which are common staging areas for this activity.

Attack Chain

  1. Initial access is established via phishing or exploit, placing a source code file (typically .cs) on the host.
  2. Attacker writes the malicious source code to a temp location, such as C:\Users\Public\ or %TEMP%.
  3. Attacker invokes csc.exe from the command line to compile the written source code.
  4. The compiler (csc.exe) reads the source file and generates an assembly in memory or as a temporary executable.
  5. The resulting assembly is executed, either directly through process injection or via a follow-on execution command.
  6. The malicious assembly executes, performing tasks like API hooking removal or C2 beaconing.
  7. The primary objective, such as credential theft or sensitive data exfiltration, is achieved using the memory-resident code.

Impact

Successful abuse of dynamic compilation allows attackers to execute arbitrary code while significantly reducing their disk footprint. This technique has been observed in global operations targeting varied sectors, allowing actors to maintain persistence and evade endpoint security controls. Failure to detect this activity can lead to long-term undetected presence within a network, resulting in unauthorized data access and potential system compromise.

Recommendation

  1. Deploy the provided Sigma rule to detect suspicious csc.exe execution patterns.
  2. Baseline legitimate csc.exe usage in the environment, specifically identifying build pipelines or automated tools that invoke the compiler from standard directories (e.g., C:\Program Files).
  3. Implement process creation logging via Sysmon (Event ID 1) to capture command line arguments and parent process relationships for csc.exe.
  4. Hunt for anomalous process execution paths for csc.exe (e.g., AppData, Temp, Perflogs) and correlate these events with unexpected network activity or unauthorized API calls.
]]>mediumadvisorystealthevading-security-controlswindowsdot-net