Git Hook Created or Modified

This rule detects the creation or modification of a Git hook file on a Linux system. Git hooks are scripts that Git executes before or after events such as commit, push, and receive. They are used to automate tasks, enforce policies, and customize Git's behavior. Attackers can abuse Git hooks to maintain persistence on a system by executing malicious code whenever a specific Git event occurs.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/06/26"
  3integration = ["endpoint", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the creation or modification of a Git hook file on a Linux system. Git hooks are scripts that Git
 13executes before or after events such as commit, push, and receive. They are used to automate tasks, enforce policies,
 14and customize Git's behavior. Attackers can abuse Git hooks to maintain persistence on a system by executing malicious
 15code whenever a specific Git event occurs.
 16"""
 17from = "now-9m"
 18index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 19language = "eql"
 20license = "Elastic License v2"
 21name = "Git Hook Created or Modified"
 22references = [
 23    "https://git-scm.com/docs/githooks/2.26.0",
 24    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
 25]
 26risk_score = 21
 27rule_id = "ac531fcc-1d3b-476d-bbb5-1357728c9a37"
 28setup = """## Setup
 29
 30This rule requires data coming in from Elastic Defend.
 31
 32### Elastic Defend Integration Setup
 33Elastic 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.
 34
 35#### Prerequisite Requirements:
 36- Fleet is required for Elastic Defend.
 37- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 38
 39#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 40- Go to the Kibana home page and click "Add integrations".
 41- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 42- Click "Add Elastic Defend".
 43- Configure the integration name and optionally add a description.
 44- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 45- 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).
 46- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 47- 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.
 48For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 49- Click "Save and Continue".
 50- 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.
 51For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 52"""
 53severity = "low"
 54tags = [
 55    "Domain: Endpoint",
 56    "OS: Linux",
 57    "Use Case: Threat Detection",
 58    "Tactic: Persistence",
 59    "Tactic: Execution",
 60    "Tactic: Defense Evasion",
 61    "Data Source: Elastic Defend",
 62    "Data Source: SentinelOne",
 63    "Data Source: Elastic Endgame",
 64    "Resources: Investigation Guide",
 65]
 66timestamp_override = "event.ingested"
 67type = "eql"
 68
 69query = '''
 70file where host.os.type == "linux" and event.type == "creation" and file.path : "*.git/hooks/*" and
 71file.extension == null and process.executable != null and not (
 72  process.executable in (
 73    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
 74    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
 75    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
 76    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
 77    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
 78    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
 79    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "/bin/pamac-daemon",
 80    "/usr/local/bin/dockerd", "/sbin/dockerd"
 81  ) or
 82  process.executable : ("/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*") or
 83  process.name in ("git", "dirname", "tar", "gitea", "git-lfs") or
 84  (process.name == "sed" and file.name : "sed*") or
 85  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 86)
 87'''
 88note = """## Triage and analysis
 89
 90> **Disclaimer**:
 91> 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.
 92
 93### Investigating Git Hook Created or Modified
 94
 95Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse.
 96
 97### Possible investigation steps
 98
 99- Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system.
100- Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query.
101- Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook.
102- Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
103- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes.
104- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise.
105
106### False positive analysis
107
108- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule.
109- Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts.
110- Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria.
111- Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts.
112- Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious.
113
114### Response and remediation
115
116- Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code.
117- Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule.
118- Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes.
119- Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms.
120- Implement file integrity monitoring on the .git/hooks directory to detect unauthorized changes in the future.
121- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
122- Review and update access controls and permissions for Git repositories to limit the ability to modify hook scripts to only trusted users."""
123
124[[rule.threat]]
125framework = "MITRE ATT&CK"
126
127[[rule.threat.technique]]
128id = "T1543"
129name = "Create or Modify System Process"
130reference = "https://attack.mitre.org/techniques/T1543/"
131
132[[rule.threat.technique]]
133id = "T1574"
134name = "Hijack Execution Flow"
135reference = "https://attack.mitre.org/techniques/T1574/"
136
137[rule.threat.tactic]
138id = "TA0003"
139name = "Persistence"
140reference = "https://attack.mitre.org/tactics/TA0003/"
141
142[[rule.threat]]
143framework = "MITRE ATT&CK"
144
145[[rule.threat.technique]]
146id = "T1059"
147name = "Command and Scripting Interpreter"
148reference = "https://attack.mitre.org/techniques/T1059/"
149
150[[rule.threat.technique.subtechnique]]
151id = "T1059.004"
152name = "Unix Shell"
153reference = "https://attack.mitre.org/techniques/T1059/004/"
154
155[rule.threat.tactic]
156id = "TA0002"
157name = "Execution"
158reference = "https://attack.mitre.org/tactics/TA0002/"
159
160[[rule.threat]]
161framework = "MITRE ATT&CK"
162
163[rule.threat.tactic]
164id = "TA0005"
165name = "Defense Evasion"
166reference = "https://attack.mitre.org/tactics/TA0005/"

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 Git Hook Created or Modified

Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse.

Possible investigation steps

  • Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system.
  • Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query.
  • Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook.
  • Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
  • Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes.
  • Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise.

False positive analysis

  • System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule.
  • Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts.
  • Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria.
  • Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts.
  • Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious.

Response and remediation

  • Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code.
  • Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule.
  • Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes.
  • Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms.
  • Implement file integrity monitoring on the .git/hooks directory to detect unauthorized changes in the future.
  • Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
  • Review and update access controls and permissions for Git repositories to limit the ability to modify hook scripts to only trusted users.

References

Related rules

to-top