Suspicious .NET Code Compilation

Identifies executions of .NET compilers with suspicious parent processes, which can indicate an attacker's attempt to compile code after delivery in order to bypass security mechanisms.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/08/21"
  3integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/05/04"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies executions of .NET compilers with suspicious parent processes, which can indicate an attacker's attempt to
 11compile code after delivery in order to bypass security mechanisms.
 12"""
 13from = "now-9m"
 14index = [
 15    "endgame-*",
 16    "logs-crowdstrike.fdr*",
 17    "logs-endpoint.events.process-*",
 18    "logs-m365_defender.event-*",
 19    "logs-sentinel_one_cloud_funnel.*",
 20    "logs-system.security*",
 21    "logs-windows.forwarded*",
 22    "logs-windows.sysmon_operational-*",
 23    "winlogbeat-*",
 24]
 25language = "eql"
 26license = "Elastic License v2"
 27name = "Suspicious .NET Code Compilation"
 28note = """## Triage and analysis
 29
 30> **Disclaimer**:
 31> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 32
 33### Investigating Suspicious .NET Code Compilation
 34
 35.NET compilers like `csc.exe` and `vbc.exe` are integral to compiling C# and VB.NET code, respectively, in Windows environments. Adversaries exploit these compilers by executing them with unusual parent processes, such as scripting engines or system utilities, to compile malicious code stealthily. The detection rule identifies such anomalies by monitoring compiler executions initiated by suspicious parent processes, signaling potential evasion or execution tactics.
 36
 37### Possible investigation steps
 38
 39- Review the process tree to understand the relationship between the suspicious parent process (e.g., wscript.exe, mshta.exe) and the .NET compiler process (csc.exe or vbc.exe) to determine if the execution flow is typical or anomalous.
 40- Examine the command-line arguments used by the .NET compiler process to identify any potentially malicious code or scripts being compiled.
 41- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
 42- Investigate the source and integrity of the parent process executable to ensure it has not been tampered with or replaced by a malicious version.
 43- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise.
 44- Analyze network activity from the host around the time of the alert to detect any suspicious outbound connections that may indicate data exfiltration or command-and-control communication.
 45
 46### False positive analysis
 47
 48- Legitimate software development activities may trigger this rule if developers use scripting engines or system utilities to automate the compilation of .NET code. To manage this, identify and whitelist known development environments or scripts that frequently compile code using these methods.
 49- System administrators might use scripts or automation tools that invoke .NET compilers for maintenance tasks. Review and document these processes, then create exceptions for recognized administrative scripts to prevent unnecessary alerts.
 50- Some enterprise applications may use .NET compilers as part of their normal operation, especially if they dynamically generate or compile code. Investigate these applications and exclude their processes from the rule if they are verified as non-threatening.
 51- Security tools or monitoring solutions might simulate suspicious behavior for testing purposes, which could trigger this rule. Coordinate with your security team to identify such tools and exclude their activities from detection.
 52- In environments where custom scripts are frequently used for deployment or configuration, ensure these scripts are reviewed and, if safe, added to an exclusion list to reduce false positives.
 53
 54### Response and remediation
 55
 56- Immediately isolate the affected system from the network to prevent further execution or spread of potentially malicious code.
 57- Terminate any suspicious processes identified, such as `csc.exe` or `vbc.exe`, that are running with unusual parent processes.
 58- Conduct a thorough scan of the isolated system using updated antivirus and endpoint detection tools to identify and remove any malicious files or remnants.
 59- Review and analyze the execution logs to determine the source and scope of the threat, focusing on the parent processes like `wscript.exe` or `mshta.exe` that initiated the compiler execution.
 60- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning.
 61- Implement application whitelisting to prevent unauthorized execution of compilers and scripting engines by non-standard parent processes.
 62- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 63risk_score = 47
 64rule_id = "201200f1-a99b-43fb-88ed-f65a45c4972c"
 65severity = "medium"
 66tags = [
 67    "Domain: Endpoint",
 68    "OS: Windows",
 69    "Use Case: Threat Detection",
 70    "Tactic: Defense Evasion",
 71    "Tactic: Execution",
 72    "Data Source: Elastic Endgame",
 73    "Data Source: Elastic Defend",
 74    "Data Source: Windows Security Event Logs",
 75    "Data Source: Microsoft Defender XDR",
 76    "Data Source: Sysmon",
 77    "Data Source: SentinelOne",
 78    "Data Source: Crowdstrike",
 79    "Resources: Investigation Guide",
 80]
 81timestamp_override = "event.ingested"
 82type = "eql"
 83
 84query = '''
 85process where host.os.type == "windows" and event.type == "start" and
 86  process.name : ("csc.exe", "vbc.exe") and
 87  process.parent.name : ("wscript.exe", "mshta.exe", "cscript.exe", "wmic.exe", "svchost.exe", "rundll32.exe", "cmstp.exe", "regsvr32.exe")
 88'''
 89
 90setup = """## Setup
 91
 92This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
 93
 94Setup instructions: https://ela.st/install-elastic-defend
 95
 96### Additional data sources
 97
 98This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
 99
100- [CrowdStrike](https://ela.st/crowdstrike-integration)
101- [Microsoft Defender XDR](https://ela.st/m365-defender)
102- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
103- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
104- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
105"""
106
107
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110
111[[rule.threat.technique]]
112id = "T1027"
113name = "Obfuscated Files or Information"
114reference = "https://attack.mitre.org/techniques/T1027/"
115
116[[rule.threat.technique.subtechnique]]
117id = "T1027.004"
118name = "Compile After Delivery"
119reference = "https://attack.mitre.org/techniques/T1027/004/"
120
121[[rule.threat.technique]]
122id = "T1127"
123name = "Trusted Developer Utilities Proxy Execution"
124reference = "https://attack.mitre.org/techniques/T1127/"
125
126[[rule.threat.technique]]
127id = "T1218"
128name = "System Binary Proxy Execution"
129reference = "https://attack.mitre.org/techniques/T1218/"
130
131[[rule.threat.technique.subtechnique]]
132id = "T1218.003"
133name = "CMSTP"
134reference = "https://attack.mitre.org/techniques/T1218/003/"
135
136[[rule.threat.technique.subtechnique]]
137id = "T1218.005"
138name = "Mshta"
139reference = "https://attack.mitre.org/techniques/T1218/005/"
140
141[[rule.threat.technique.subtechnique]]
142id = "T1218.010"
143name = "Regsvr32"
144reference = "https://attack.mitre.org/techniques/T1218/010/"
145
146[[rule.threat.technique.subtechnique]]
147id = "T1218.011"
148name = "Rundll32"
149reference = "https://attack.mitre.org/techniques/T1218/011/"
150
151[rule.threat.tactic]
152id = "TA0005"
153name = "Defense Evasion"
154reference = "https://attack.mitre.org/tactics/TA0005/"
155
156[[rule.threat]]
157framework = "MITRE ATT&CK"
158
159[[rule.threat.technique]]
160id = "T1047"
161name = "Windows Management Instrumentation"
162reference = "https://attack.mitre.org/techniques/T1047/"
163
164[[rule.threat.technique]]
165id = "T1059"
166name = "Command and Scripting Interpreter"
167reference = "https://attack.mitre.org/techniques/T1059/"
168
169[[rule.threat.technique.subtechnique]]
170id = "T1059.005"
171name = "Visual Basic"
172reference = "https://attack.mitre.org/techniques/T1059/005/"
173
174[[rule.threat.technique.subtechnique]]
175id = "T1059.007"
176name = "JavaScript"
177reference = "https://attack.mitre.org/techniques/T1059/007/"
178
179[rule.threat.tactic]
180id = "TA0002"
181name = "Execution"
182reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Suspicious .NET Code Compilation

.NET compilers like csc.exe and vbc.exe are integral to compiling C# and VB.NET code, respectively, in Windows environments. Adversaries exploit these compilers by executing them with unusual parent processes, such as scripting engines or system utilities, to compile malicious code stealthily. The detection rule identifies such anomalies by monitoring compiler executions initiated by suspicious parent processes, signaling potential evasion or execution tactics.

Possible investigation steps

  • Review the process tree to understand the relationship between the suspicious parent process (e.g., wscript.exe, mshta.exe) and the .NET compiler process (csc.exe or vbc.exe) to determine if the execution flow is typical or anomalous.
  • Examine the command-line arguments used by the .NET compiler process to identify any potentially malicious code or scripts being compiled.
  • Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
  • Investigate the source and integrity of the parent process executable to ensure it has not been tampered with or replaced by a malicious version.
  • Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise.
  • Analyze network activity from the host around the time of the alert to detect any suspicious outbound connections that may indicate data exfiltration or command-and-control communication.

False positive analysis

  • Legitimate software development activities may trigger this rule if developers use scripting engines or system utilities to automate the compilation of .NET code. To manage this, identify and whitelist known development environments or scripts that frequently compile code using these methods.
  • System administrators might use scripts or automation tools that invoke .NET compilers for maintenance tasks. Review and document these processes, then create exceptions for recognized administrative scripts to prevent unnecessary alerts.
  • Some enterprise applications may use .NET compilers as part of their normal operation, especially if they dynamically generate or compile code. Investigate these applications and exclude their processes from the rule if they are verified as non-threatening.
  • Security tools or monitoring solutions might simulate suspicious behavior for testing purposes, which could trigger this rule. Coordinate with your security team to identify such tools and exclude their activities from detection.
  • In environments where custom scripts are frequently used for deployment or configuration, ensure these scripts are reviewed and, if safe, added to an exclusion list to reduce false positives.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further execution or spread of potentially malicious code.
  • Terminate any suspicious processes identified, such as csc.exe or vbc.exe, that are running with unusual parent processes.
  • Conduct a thorough scan of the isolated system using updated antivirus and endpoint detection tools to identify and remove any malicious files or remnants.
  • Review and analyze the execution logs to determine the source and scope of the threat, focusing on the parent processes like wscript.exe or mshta.exe that initiated the compiler execution.
  • Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning.
  • Implement application whitelisting to prevent unauthorized execution of compilers and scripting engines by non-standard parent processes.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.

Related rules

to-top