Git Hook Child Process

  1[metadata]
  2creation_date = "2024/06/26"
  3integration = ["endpoint", "crowdstrike", "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 child processes spawned by Git hooks. Git hooks are scripts that Git executes before or after events
 13such as commit, push, and receive. The rule identifies child processes spawned by Git hooks that are not typically
 14spawned by the Git process itself. This behavior may indicate an attacker attempting to hide malicious activity by
 15leveraging the legitimate Git process to execute unauthorized commands.
 16"""
 17from = "now-9m"
 18index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 19language = "eql"
 20license = "Elastic License v2"
 21name = "Git Hook Child Process"
 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 = "7ce5e1c7-6a49-45e6-a101-0720d185667f"
 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: Crowdstrike",
 63    "Data Source: SentinelOne",
 64    "Data Source: Elastic Endgame",
 65    "Resources: Investigation Guide",
 66]
 67timestamp_override = "event.ingested"
 68type = "eql"
 69
 70query = '''
 71process where host.os.type == "linux" and event.type == "start" and
 72  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 73  process.parent.name in (
 74    "applypatch-msg", "commit-msg", "fsmonitor-watchman", "post-update", "post-checkout", "post-commit",
 75    "pre-applypatch", "pre-commit", "pre-merge-commit", "prepare-commit-msg", "pre-push", "pre-rebase", "pre-receive",
 76    "push-to-checkout", "update", "post-receive", "pre-auto-gc", "post-rewrite", "sendemail-validate", "p4-pre-submit",
 77    "post-index-change", "post-merge", "post-applypatch"
 78  ) and
 79  (
 80    process.name in ("nohup", "setsid", "disown", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
 81    process.name : ("php*", "perl*", "ruby*", "lua*") or
 82    process.executable : (
 83      "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*",
 84      "/run/*", "/srv/*", "/tmp/*", "/var/tmp/*", "/var/log/*"
 85    )
 86  ) and
 87  not process.name in ("git", "dirname")
 88'''
 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 Git Hook Child Process
 95
 96Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse.
 97
 98### Possible investigation steps
 99
100- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process.
101- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed.
102- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful.
103- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner.
104- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise.
105- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks.
106
107### False positive analysis
108
109- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers.
110- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows.
111- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening.
112- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities.
113- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations.
114
115### Response and remediation
116
117- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands.
118- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables.
119- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts.
120- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations.
121- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks.
122- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms.
123- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected."""
124
125
126[[rule.threat]]
127framework = "MITRE ATT&CK"
128[[rule.threat.technique]]
129id = "T1543"
130name = "Create or Modify System Process"
131reference = "https://attack.mitre.org/techniques/T1543/"
132
133[[rule.threat.technique]]
134id = "T1574"
135name = "Hijack Execution Flow"
136reference = "https://attack.mitre.org/techniques/T1574/"
137
138
139[rule.threat.tactic]
140id = "TA0003"
141name = "Persistence"
142reference = "https://attack.mitre.org/tactics/TA0003/"
143[[rule.threat]]
144framework = "MITRE ATT&CK"
145[[rule.threat.technique]]
146id = "T1059"
147name = "Command and Scripting Interpreter"
148reference = "https://attack.mitre.org/techniques/T1059/"
149[[rule.threat.technique.subtechnique]]
150id = "T1059.004"
151name = "Unix Shell"
152reference = "https://attack.mitre.org/techniques/T1059/004/"
153
154
155
156[rule.threat.tactic]
157id = "TA0002"
158name = "Execution"
159reference = "https://attack.mitre.org/tactics/TA0002/"
160[[rule.threat]]
161framework = "MITRE ATT&CK"
162
163[rule.threat.tactic]
164id = "TA0005"
165name = "Defense Evasion"
166reference = "https://attack.mitre.org/tactics/TA0005/"