Detecting Compiler and REPL Host Abuse (msbuild / dotnet / csi / rcsi / fsi)#

Table of Contents#

1. The Mechanism, Briefly
2. Why This Family Is Loud
3. Detection Signal 1 — Abnormal Parentage and Invocation Path
4. Detection Signal 2 — Suspicious Content Argument
5. Detection Signal 3 — Child-Process Lineage
6. A Sigma Rule for the Family
7. Tuning for a Mixed Fleet
8. References

1. The Mechanism, Briefly#

Each of these binaries accepts attacker-supplied content — a project file, an inline task, a C#/F# script, a workflow XOML — and executes the logic inside it. Classic examples:

• msbuild.exe project.xml with an inline C# <Task> that runs on build.
• dotnet.exe / dotnet.exe run against a project, or dotnet.exe <assembly.dll> to load and execute.
• csi.exe script.csx / rcsi.exe script.csx running a C# script.
• fsi.exe script.fsx running F#.
• Microsoft.Workflow.Compiler.exe INPUT.xml OUT.dll deserialising and executing.

In every case the trusted host does the executing; WDAC sees only the signed image. See the reference catalog for the per-binary citations.

2. Why This Family Is Loud#

Unlike a debugger quietly rewriting a thread’s context, a compiler host that executes attacker logic almost always produces observable side effects: it reads a file from a user-writable path, it often spawns a child process, and its command line names the content file. The detection problem is not “is there a signal” — it is “which of these thousands of legitimate msbuild invocations is the malicious one?” That is a filtering and baseline problem, and it is very tractable.

3. Detection Signal 1 — Abnormal Parentage and Invocation Path#

Legitimate compiler hosts have a small set of parents and a small set of installation paths. Any deviation is the signal:

• Parentage. msbuild.exe is normally a child of Visual Studio (devenv.exe), dotnet.exe, MSBuild node hosts (MSBuild.exe itself, for the worker nodes), or a CI agent (msbuild.exe under pwsh.exe/cmd.exe inside a pipeline workspace). It is not a child of winword.exe, a browser, or cmd.exe spawned from %TEMP%.
• Path. The genuine binaries live under C:\Program Files\Microsoft Visual Studio\..., C:\Program Files\dotnet\..., or the .NET Framework reference path. A msbuild.exe invoked from %USERPROFILE%\Downloads\ or %LOCALAPPDATA% is suspicious even if it is the real binary.
• Content path. The argument naming the project/script file is the strongest single atom. A project file loaded from a user-writable directory, a UNC path, or an internet-sourced URL is the canonical shape.

4. Detection Signal 2 — Suspicious Content Argument#

Per-host fingerprints on the command line:

• msbuild.exe: the project argument; inline-task smell is harder to see from the command line alone, so pair with a file-read of the project (Sysmon EID 11 or your EDR’s file events) looking for <Task + using: or Code Language="cs".
• dotnet.exe: dotnet <path>.dll where the DLL is in a user-writable location, or dotnet script / dotnet-script (the scripting tooling).
• csi.exe / rcsi.exe: any invocation with a .csx argument is suspect on a non-dev host.
• fsi.exe / fsiAnyCpu.exe: any invocation with a .fsx argument, same caveat.
• Microsoft.Workflow.Compiler.exe: the two-argument INPUT.xml OUT shape, rarely seen outside its original purpose.
• aspnet_compiler.exe: invocation outside a build farm.

The presence of these hosts on a non-developer endpoint is itself the cleanest signal. On a dev endpoint, fall back to path and content provenance.

5. Detection Signal 3 — Child-Process Lineage#

When an attacker-controlled inline task or script runs, the host frequently spawns a child — cmd.exe, powershell.exe/pwsh.exe, or an attacker payload — to extend the attack. The lineage to alert on is therefore:

msbuild.exe (or dotnet.exe / csi.exe / fsi.exe) → cmd.exe | powershell.exe | pwsh.exe | an unsigned executable

A trusted compiler host spawning a shell is almost never legitimate. This is the highest-confidence detection in the family and the most resistant to command-line obfuscation, because the child image is what it is regardless of how the parent was invoked.

6. A Sigma Rule for the Family#

A rule combining the abnormal path/parent (Signal 1), the suspicious content extension (Signal 2), and the shell-child lineage (Signal 3).

1
title: WDAC Bypass — Compiler/REPL Host Abuse
2
id: 5b2d7f0a-1c4e-4b9a-8f3d-6e0c1a2b3c4d
3
status: experimental
4
description: >
5
  Detects trusted developer compilers and REPL hosts (msbuild, dotnet, csi,
6
  rcsi, fsi, Microsoft.Workflow.Compiler) invoked from suspicious paths or
7
  parents, with script/project arguments from user-writable locations, or
8
  spawning shell children — patterns consistent with WDAC/Application Control
9
  bypass.
10
references:
11
  - https://github.com/bohops/UltimateWDACBypassList
12
  - /posts/wdac-bypass-techniques-reference-catalog/
13
author: Anubhav Gain
14
date: 2026/07/13
15
tags:
16
  - attack.defense_evasion
17
  - attack.t1127
18
  - attack.t1218
19
  - attack.t1027
20
logsource:
21
  product: windows
22
  category: process_creation
23
detection:
24
  host_image:
25
    Image|endswith:
26
      - '\MSBuild.exe'
27
      - '\dotnet.exe'
28
      - '\csi.exe'
29
      - '\rcsi.exe'
30
      - '\fsi.exe'
31
      - '\fsiAnyCpu.exe'
32
      - '\wfc.exe'
33
      - '\dnx.exe'
34
      - '\Microsoft.Workflow.Compiler.exe'
35
      - '\TextTransform.exe'
36
  user_writable_arg:
37
    CommandLine|contains:
38
      - '\Users\Public\'
39
      - '\AppData\Local\Temp\'
40
      - '\AppData\Roaming\'
41
      - '\Downloads\'
42
      - '\\\\'      # UNC paths
43
  script_extension:
44
    CommandLine|endswith:
45
      - '.csx'
46
      - '.fsx'
47
      - '.csproj'
48
      - '.vbproj'
49
      - '.dll'
50
  abnormal_parent:
51
    ParentImage|endswith:
52
      - '\winword.exe'
53
      - '\excel.exe'
54
      - '\powerpnt.exe'
55
      - '\outlook.exe'
56
      - '\chrome.exe'
57
      - '\msedge.exe'
58
      - '\firefox.exe'
59
      - '\wscript.exe'
60
      - '\cscript.exe'
61
  invoked_from_user_writable:
62
    Image|contains:
63
      - '\Users\Public\'
64
      - '\AppData\Local\Temp\'
65
      - '\AppData\Roaming\'
66
      - '\Downloads\'
67
      - '\Windows\Temp\'
68
  shell_child:
69
    ParentImage|endswith:
70
      - '\MSBuild.exe'
71
      - '\dotnet.exe'
72
      - '\csi.exe'
73
      - '\rcsi.exe'
74
      - '\fsi.exe'
75
      - '\Microsoft.Workflow.Compiler.exe'
76
    Image|endswith:
77
      - '\cmd.exe'
78
      - '\powershell.exe'
79
      - '\pwsh.exe'
80
      - '\wscript.exe'
81
      - '\cscript.exe'
82
  condition: >-
83
    (host_image and (user_writable_arg or script_extension or abnormal_parent or invoked_from_user_writable))
84
    or shell_child
85
fields:
86
  - Image
87
  - ParentImage
88
  - CommandLine
89
  - User
90
falsepositives:
91
  - Developer workstations and CI agents running legitimate builds (tier separately)
92
  - dotnet loading framework DLLs (constrain the .dll extension to user-writable paths)
93
level: medium

Note the level is medium rather than high: this family runs legitimately at scale on dev/CI hosts, so without tiering it will produce volume. The shell_child branch is the sub-condition you can promote to high confidence — a compiler host spawning cmd.exe/powershell.exe is the real deal.

7. Tuning for a Mixed Fleet#

• Tier the hosts. Developer and CI hosts route to a lower-severity queue; locked-down workstations and servers use the full-severity rule.
• Anchor legitimate paths. Allow-list MSBuild.exe and dotnet.exe from their Program Files install roots invoked by the CI service account or devenv.exe. Everything else stays in scope.
• Watch the project files, not just the process. A companion Sysmon rule (FileCreate for *.csproj/*.vbproj/*.csx/*.fsx under user-writable paths) gives you lead time before the host executes them.
• Promote shell_child. On any fleet, a compiler host spawning a shell is worth paging on regardless of tier.

8. References#

• Bypassing Application Whitelisting using MSBuild.exe — Casey Smith
• DotNet Core: A Vector for AWL Bypass — bohops
• Arbitrary Unsigned Code Execution in Microsoft.Workflow.Compiler.exe — Matt Graeber
• WDAC Bypass Techniques — The Complete Reference Catalog
• MITRE ATT&CK T1127 — Trusted Developer Utilities Proxy Execution
• MITRE ATT&CK T1127.001 — MSBuild