Anomalous Linux Compiler Activity

Looks for compiler activity by a user context which does not normally run compilers. This can be the result of ad-hoc software changes or unauthorized software deployment. This can also be due to local privilege elevation via locally run exploits or malware activity.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/09/03"
  3integration = ["auditd_manager", "endpoint"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8anomaly_threshold = 50
  9author = ["Elastic"]
 10description = """
 11Looks for compiler activity by a user context which does not normally run compilers. This can be the result of ad-hoc
 12software changes or unauthorized software deployment. This can also be due to local privilege elevation via locally run
 13exploits or malware activity.
 14"""
 15false_positives = [
 16    """
 17    Uncommon compiler activity can be due to an engineer running a local build on a production or staging instance in
 18    the course of troubleshooting or fixing a software issue.
 19    """,
 20]
 21from = "now-45m"
 22interval = "15m"
 23license = "Elastic License v2"
 24machine_learning_job_id = ["v3_linux_rare_user_compiler"]
 25name = "Anomalous Linux Compiler Activity"
 26setup = """## Setup
 27
 28This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
 29- Elastic Defend
 30- Auditd Manager
 31
 32### Anomaly Detection Setup
 33
 34Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
 35
 36### Elastic Defend Integration Setup
 37Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 38
 39#### Prerequisite Requirements:
 40- Fleet is required for Elastic Defend.
 41- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 42
 43#### The following steps should be executed in order to add the Elastic Defend integration to your system:
 44- Go to the Kibana home page and click "Add integrations".
 45- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 46- Click "Add Elastic Defend".
 47- Configure the integration name and optionally add a description.
 48- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 49- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 50- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 51- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 52For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
 53- Click "Save and Continue".
 54- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 55For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 56
 57### Auditd Manager Integration Setup
 58The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
 59Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.
 60
 61#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:
 62- Go to the Kibana home page and click “Add integrations”.
 63- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
 64- Click “Add Auditd Manager”.
 65- Configure the integration name and optionally add a description.
 66- Review optional and advanced settings accordingly.
 67- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
 68- Click “Save and Continue”.
 69- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
 70
 71#### Rule Specific Setup Note
 72Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
 73However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
 74- For this detection rule no additional audit rules are required.
 75"""
 76risk_score = 21
 77rule_id = "cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530"
 78severity = "low"
 79tags = [
 80    "Domain: Endpoint",
 81    "OS: Linux",
 82    "Use Case: Threat Detection",
 83    "Rule Type: ML",
 84    "Rule Type: Machine Learning",
 85    "Tactic: Resource Development",
 86    "Resources: Investigation Guide",
 87]
 88type = "machine_learning"
 89note = """## Triage and analysis
 90
 91> **Disclaimer**:
 92> 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.
 93
 94### Investigating Anomalous Linux Compiler Activity
 95
 96Compilers transform source code into executable programs, a crucial step in software development. In Linux environments, unexpected compiler use by atypical users may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit this by deploying malicious code or exploits. The detection rule leverages machine learning to identify unusual compiler activity, flagging potential threats by analyzing user behavior patterns and deviations from normal operations.
 97
 98### Possible investigation steps
 99
100- Review the user account associated with the anomalous compiler activity to determine if the user typically engages in software development or has a history of using compilers.
101- Check the specific compiler and version used in the activity to identify if it is a known or legitimate tool within the organization.
102- Analyze the source and destination of the compiler activity, including the IP addresses and hostnames, to identify any unusual or unauthorized access patterns.
103- Investigate recent changes or deployments on the system where the compiler activity was detected to identify any unauthorized software installations or modifications.
104- Examine system logs and audit trails for any signs of privilege escalation attempts or other suspicious activities around the time of the compiler usage.
105- Cross-reference the detected activity with known threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise.
106
107### False positive analysis
108
109- Development environments where multiple users compile code can trigger false positives. Regularly update the list of authorized users who are expected to use compilers to prevent unnecessary alerts.
110- Automated build systems or continuous integration pipelines may be flagged. Exclude these systems from monitoring or adjust the rule to recognize their activity as normal.
111- Educational or training sessions involving compilers might cause alerts. Temporarily adjust the rule settings or add exceptions for the duration of the training.
112- Users compiling open-source software for personal use can be mistaken for threats. Implement a process for users to notify the security team of legitimate compiler use to preemptively adjust monitoring rules.
113- System administrators performing maintenance or updates that involve compiling software may trigger alerts. Maintain a log of scheduled maintenance activities and adjust the rule to account for these periods.
114
115### Response and remediation
116
117- Isolate the affected system from the network to prevent potential lateral movement or further exploitation.
118- Terminate any suspicious processes associated with the anomalous compiler activity to halt any ongoing malicious operations.
119- Conduct a thorough review of recent user activity and permissions to identify unauthorized access or privilege escalation attempts.
120- Remove any unauthorized or malicious software identified during the investigation to prevent further compromise.
121- Restore the system from a known good backup if malicious code execution is confirmed, ensuring that the backup is free from compromise.
122- Implement stricter access controls and monitoring for compiler usage, ensuring only authorized users can execute compilers.
123- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
124[[rule.threat]]
125framework = "MITRE ATT&CK"
126[[rule.threat.technique]]
127id = "T1588"
128name = "Obtain Capabilities"
129reference = "https://attack.mitre.org/techniques/T1588/"
130[[rule.threat.technique.subtechnique]]
131id = "T1588.001"
132name = "Malware"
133reference = "https://attack.mitre.org/techniques/T1588/001/"
134
135
136
137[rule.threat.tactic]
138id = "TA0042"
139name = "Resource Development"
140reference = "https://attack.mitre.org/tactics/TA0042/"
...
toml

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.

Compilers transform source code into executable programs, a crucial step in software development. In Linux environments, unexpected compiler use by atypical users may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit this by deploying malicious code or exploits. The detection rule leverages machine learning to identify unusual compiler activity, flagging potential threats by analyzing user behavior patterns and deviations from normal operations.

  • Review the user account associated with the anomalous compiler activity to determine if the user typically engages in software development or has a history of using compilers.
  • Check the specific compiler and version used in the activity to identify if it is a known or legitimate tool within the organization.
  • Analyze the source and destination of the compiler activity, including the IP addresses and hostnames, to identify any unusual or unauthorized access patterns.
  • Investigate recent changes or deployments on the system where the compiler activity was detected to identify any unauthorized software installations or modifications.
  • Examine system logs and audit trails for any signs of privilege escalation attempts or other suspicious activities around the time of the compiler usage.
  • Cross-reference the detected activity with known threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise.
  • Development environments where multiple users compile code can trigger false positives. Regularly update the list of authorized users who are expected to use compilers to prevent unnecessary alerts.
  • Automated build systems or continuous integration pipelines may be flagged. Exclude these systems from monitoring or adjust the rule to recognize their activity as normal.
  • Educational or training sessions involving compilers might cause alerts. Temporarily adjust the rule settings or add exceptions for the duration of the training.
  • Users compiling open-source software for personal use can be mistaken for threats. Implement a process for users to notify the security team of legitimate compiler use to preemptively adjust monitoring rules.
  • System administrators performing maintenance or updates that involve compiling software may trigger alerts. Maintain a log of scheduled maintenance activities and adjust the rule to account for these periods.
  • Isolate the affected system from the network to prevent potential lateral movement or further exploitation.
  • Terminate any suspicious processes associated with the anomalous compiler activity to halt any ongoing malicious operations.
  • Conduct a thorough review of recent user activity and permissions to identify unauthorized access or privilege escalation attempts.
  • Remove any unauthorized or malicious software identified during the investigation to prevent further compromise.
  • Restore the system from a known good backup if malicious code execution is confirmed, ensuring that the backup is free from compromise.
  • Implement stricter access controls and monitoring for compiler usage, ensuring only authorized users can execute compilers.
  • Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.

Related rules

to-top