Trellix Repo Breach: Detecting Persistence in Git Audit Logs
With the news that Trellix identified unauthorized access to a portion of their source code, I’m curious how everyone else is handling their Git audit logs right now. It’s easy to focus on the blast radius of the exposed code, but the persistence mechanisms used in these repo breaches are often the real story.
If an attacker gets write access to a repo, they aren't just stealing code—they're often poisoning the build pipeline. We've seen this time and again with supply chain attacks. Since Trellix hasn't disclosed the initial vector yet, we should assume standard credential stuffing or compromised PATs (Personal Access Tokens).
For those running self-hosted GitLab or GitHub Enterprise, I recommend checking for anomalous push behavior immediately. Here’s a basic KQL query I’m running to spot pushes outside of normal business hours or from unusual IPs:
GitPushAuditLog
| where Timestamp > ago(7d)
| project Timestamp, User, Repo, IpAddress, PushCount
| where Hour(Timestamp) 22
| summarize count() by User, IpAddress
And for ensuring no hidden webhooks were added for data exfiltration:
git log --all --oneline --grep="webhook" --since="1 month ago"
Beyond logging, are you guys enforcing signed commits yet? If the attackers modified code without valid signatures, the breach detection relies entirely on file integrity monitoring. With Trellix being a security vendor, the irony here is painful, but it serves as a wake-up call. Even the shield-makers have chinks in their armor.
How are you validating the integrity of your internal repositories after a news event like this? Are we doing enough to monitor for "authorized" anomalies, or are we just waiting for the breach disclosure?
Great point on the signed commits. We recently mandated commit-sign rules for all critical repos in our org. It adds friction for the dev team, but being able to verify the author identity cryptographically is a lifesaver in these scenarios. If Trellix had forced signing on that specific repo, they'd know instantly if the attacker introduced new code or just read it. We also integrated TruffleHog into our CI/CD pipeline to scan for accidental leaks—even if it was just read-only access, you have to assume they grabbed secrets if they were sitting in the code.
From a SOC perspective, the lack of visibility on repo access is terrifying. Most orgs send Git logs to a SIEM but rarely tune rules for 'Impossible Travel' or 'Mass Deletion' events. I'd add checking for added deploy keys:
git config --list | grep -E 'user\.(name|email)|remote\..*\.url'
If an attacker adds their own SSH key to the repo settings, they maintain persistence even after the original credentials are rotated. I wonder if Trellix's forensic team has checked for dormant deploy keys yet.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access