Git Hook Command Execution

  1[metadata]
  2creation_date = "2024/07/15"
  3integration = ["endpoint", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5updated_date = "2025/03/20"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects the execution of a potentially malicious process from a Git hook. Git hooks are scripts that Git
 11executes before or after events such as: commit, push, and receive. An attacker can abuse Git hooks to execute arbitrary
 12commands on the system and establish persistence.
 13"""
 14from = "now-9m"
 15index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
 16language = "eql"
 17license = "Elastic License v2"
 18name = "Git Hook Command Execution"
 19note = """## Triage and analysis
 20
 21> **Disclaimer**:
 22> 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.
 23
 24### Investigating Git Hook Command Execution
 25
 26Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems.
 27
 28### Possible investigation steps
 29
 30- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields.
 31- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated.
 32- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts.
 33- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise.
 34- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command.
 35- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise.
 36- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms.
 37
 38### False positive analysis
 39
 40- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes.
 41- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious.
 42- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them.
 43- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise.
 44
 45### Response and remediation
 46
 47- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
 48- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions.
 49- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts.
 50- Restore any modified or deleted files from a known good backup to ensure system integrity.
 51- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly.
 52- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
 53- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only."""
 54references = [
 55    "https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git",
 56    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
 57]
 58risk_score = 47
 59rule_id = "dc61f382-dc0c-4cc0-a845-069f2a071704"
 60setup = """## Setup
 61
 62This rule requires data coming in from Elastic Defend.
 63
 64### Elastic Defend Integration Setup
 65Elastic 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.
 66
 67#### Prerequisite Requirements:
 68- Fleet is required for Elastic Defend.
 69- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 70
 71#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 72- Go to the Kibana home page and click "Add integrations".
 73- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 74- Click "Add Elastic Defend".
 75- Configure the integration name and optionally add a description.
 76- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 77- 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).
 78- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 79- 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.
 80For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 81- Click "Save and Continue".
 82- 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.
 83For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 84"""
 85severity = "medium"
 86tags = [
 87    "Domain: Endpoint",
 88    "OS: Linux",
 89    "Use Case: Threat Detection",
 90    "Tactic: Persistence",
 91    "Tactic: Execution",
 92    "Tactic: Defense Evasion",
 93    "Data Source: Elastic Defend",
 94    "Data Source: SentinelOne",
 95    "Resources: Investigation Guide",
 96]
 97type = "eql"
 98
 99query = '''
100sequence by host.id with maxspan=3s
101  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
102   process.parent.name == "git" and process.args : ".git/hooks/*" and
103   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
104  ] by process.entity_id
105  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
106   process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id
107'''
108
109
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112[[rule.threat.technique]]
113id = "T1543"
114name = "Create or Modify System Process"
115reference = "https://attack.mitre.org/techniques/T1543/"
116
117[[rule.threat.technique]]
118id = "T1574"
119name = "Hijack Execution Flow"
120reference = "https://attack.mitre.org/techniques/T1574/"
121
122
123[rule.threat.tactic]
124id = "TA0003"
125name = "Persistence"
126reference = "https://attack.mitre.org/tactics/TA0003/"
127[[rule.threat]]
128framework = "MITRE ATT&CK"
129[[rule.threat.technique]]
130id = "T1059"
131name = "Command and Scripting Interpreter"
132reference = "https://attack.mitre.org/techniques/T1059/"
133[[rule.threat.technique.subtechnique]]
134id = "T1059.004"
135name = "Unix Shell"
136reference = "https://attack.mitre.org/techniques/T1059/004/"
137
138
139
140[rule.threat.tactic]
141id = "TA0002"
142name = "Execution"
143reference = "https://attack.mitre.org/tactics/TA0002/"
144[[rule.threat]]
145framework = "MITRE ATT&CK"
146
147[rule.threat.tactic]
148id = "TA0005"
149name = "Defense Evasion"
150reference = "https://attack.mitre.org/tactics/TA0005/"