Why your history looks clean

This is the part worth understanding, because it is the reason a manual review does not work.

The mechanism

A propagation script, temp_auto_push.bat, runs on the infected machine and:

1. reads the last commit’s author and timestamp
2. sets the system clock back to that timestamp
3. amends the commit with the payload, committing with --no-verify
4. restores the clock and force-pushes with -uf to every writable remote

The result looks like an ordinary, correctly dated commit with your name on it. git log will not show you anything wrong. One documented case carried 267 days of backdating: a commit claiming 2025-11-06 that was actually pushed on 2026-07-31.

What this means for detection

Reading history cannot find this. Two things can:

Content scanning of every ref. Not the default branch, not the working tree you happen to have checked out. Every ref, because the payload may sit on a branch nobody looks at.

Push-event reconciliation. On GitHub, look at branch activity rather than the commit list. A force push appears in the activity log as “force-pushed the branch from abc123 to def456”. That entry is generated by GitHub and tied to the real pushing identity, not to whatever author name was written into the commit. A backdated amend appears nowhere else.

git reflog                      # amended commits on branches you own
gh api /user/keys               # SSH keys you did not add

Note

Reading history cannot find this. git log shows an ordinary, correctly dated commit with your name on it.

The limit you should know about

GitHub’s Events API retains roughly 300 events for about 90 days. Past that window the push events are simply gone, and with them the ability to prove what a branch pointed at before the attack. If the compromise is older than the window, restore is not available and cleaning is the only option.

That is not a limitation of this tool. It is a limitation of the evidence.