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 = "2025/01/15"
  6min_stack_version = "8.14.0"
  7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies executions of .NET compilers with suspicious parent processes, which can indicate an attacker's attempt to
 13compile code after delivery in order to bypass security mechanisms.
 14"""
 15from = "now-9m"
 16index = [
 17    "winlogbeat-*",
 18    "logs-endpoint.events.process-*",
 19    "logs-windows.forwarded*",
 20    "logs-windows.sysmon_operational-*",
 21    "endgame-*",
 22    "logs-system.security*",
 23    "logs-m365_defender.event-*",
 24    "logs-sentinel_one_cloud_funnel.*",
 25    "logs-crowdstrike.fdr*",
 26]
 27language = "eql"
 28license = "Elastic License v2"
 29name = "Suspicious .NET Code Compilation"
 30risk_score = 47
 31rule_id = "201200f1-a99b-43fb-88ed-f65a45c4972c"
 32severity = "medium"
 33tags = [
 34    "Domain: Endpoint",
 35    "OS: Windows",
 36    "Use Case: Threat Detection",
 37    "Tactic: Defense Evasion",
 38    "Tactic: Execution",
 39    "Data Source: Elastic Endgame",
 40    "Data Source: Elastic Defend",
 41    "Data Source: System",
 42    "Data Source: Microsoft Defender for Endpoint",
 43    "Data Source: Sysmon",
 44    "Data Source: SentinelOne",
 45    "Data Source: Crowdstrike",
 46    "Resources: Investigation Guide",
 47]
 48timestamp_override = "event.ingested"
 49type = "eql"
 50
 51query = '''
 52process where host.os.type == "windows" and event.type == "start" and
 53  process.name : ("csc.exe", "vbc.exe") and
 54  process.parent.name : ("wscript.exe", "mshta.exe", "cscript.exe", "wmic.exe", "svchost.exe", "rundll32.exe", "cmstp.exe", "regsvr32.exe")
 55'''
 56note = """## Triage and analysis
 57
 58> **Disclaimer**:
 59> 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.
 60
 61### Investigating Suspicious .NET Code Compilation
 62
 63.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.
 64
 65### Possible investigation steps
 66
 67- 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.
 68- Examine the command-line arguments used by the .NET compiler process to identify any potentially malicious code or scripts being compiled.
 69- 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.
 70- Investigate the source and integrity of the parent process executable to ensure it has not been tampered with or replaced by a malicious version.
 71- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise.
 72- 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.
 73
 74### False positive analysis
 75
 76- 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.
 77- 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.
 78- 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.
 79- 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.
 80- 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.
 81
 82### Response and remediation
 83
 84- Immediately isolate the affected system from the network to prevent further execution or spread of potentially malicious code.
 85- Terminate any suspicious processes identified, such as `csc.exe` or `vbc.exe`, that are running with unusual parent processes.
 86- Conduct a thorough scan of the isolated system using updated antivirus and endpoint detection tools to identify and remove any malicious files or remnants.
 87- 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.
 88- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning.
 89- Implement application whitelisting to prevent unauthorized execution of compilers and scripting engines by non-standard parent processes.
 90- 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."""
 91
 92
 93[[rule.threat]]
 94framework = "MITRE ATT&CK"
 95[[rule.threat.technique]]
 96id = "T1027"
 97name = "Obfuscated Files or Information"
 98reference = "https://attack.mitre.org/techniques/T1027/"
 99[[rule.threat.technique.subtechnique]]
100id = "T1027.004"
101name = "Compile After Delivery"
102reference = "https://attack.mitre.org/techniques/T1027/004/"
103
104
105
106[rule.threat.tactic]
107id = "TA0005"
108name = "Defense Evasion"
109reference = "https://attack.mitre.org/tactics/TA0005/"
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112[[rule.threat.technique]]
113id = "T1059"
114name = "Command and Scripting Interpreter"
115reference = "https://attack.mitre.org/techniques/T1059/"
116[[rule.threat.technique.subtechnique]]
117id = "T1059.005"
118name = "Visual Basic"
119reference = "https://attack.mitre.org/techniques/T1059/005/"
120
121
122
123[rule.threat.tactic]
124id = "TA0002"
125name = "Execution"
126reference = "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