Repeated unauthorized force-pushes to org repo after npm malware tokens keep getting compromised (injected code attached)

[prashannaLeo]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Supply chain security

Discussion Details

I'm dealing with a recurring token compromise and need advice on what I'm missing.
The most alarming part:
This happened while my laptop was completely powered off.
I received a message from my CTO asking why I had closed a PR but I hadn't even turned on my laptop that day. That's when I realized my account was compromised. I immediately revoked all tokens, changed passwords, and signed out all sessions. But a week later, the exact same thing happened again unauthorized actions from my account while I was not actively using it.
Timeline:

Last week: Ran npm install in a cloned repo containing a known malicious package loader
The loader executed and likely harvested stored credentials
Unauthorized force-pushes started appearing in an org repo under my account
I deleted the repo, revoked all PATs/SSH keys/OAuth tokens, changed password, signed out all sessions, and enabled 2FA
This week: It happened AGAIN same scenario, same force-pushes from my account to the same org repo
The malicious code that was injected:

What I've done (twice now):

• Revoked all tokens (classic + fine-grained)
• Removed all SSH keys and regenerated mine
• Changed password and signed out all active sessions
• Enabled 2FA with authenticator app
• Deleted the infected repo folder
• Scanned for the loader signature files on my machine (no traces found)

What's concerning:

After doing all of this last week, the unauthorized pushes resumed

This suggests either:

• A token I missed is still valid
• The malware persisted beyond the npm package (maybe a system-level infection?)
• An org-level token or GitHub App is compromised and not tied to my account
• The attacker created a new PAT during the initial infection window

Any guidance on breaking this cycle would be greatly appreciated. I feel like I'm securing my account but missing something that keeps giving the attacker access. At this point, I'm considering a full OS wipe and starting fresh.

[abdulraufqasim]

Here is a comprehensive and effective response you can use to reply to this security discussion. It directly addresses the mystery of the powered-off laptop, explains the technical mechanisms likely at play, and provides actionable remediation steps.

Hi there,

I completely understand how alarming it is to see unauthorized activity occurring while your machine is powered off, especially after you've already taken such extensive remediation steps. This is a terrifying situation, but you are not crazy—there is a logical explanation for how this is still happening.

Based on the timeline and the payload injected into postcss.config.js shown in image_615d44.png, here is a breakdown of what you are likely experiencing and how to stop it.

How is the Attacker Still Pushing?
If your personal tokens are revoked and 2FA is on, the attacker is almost certainly no longer authenticating through your personal GitHub account. Instead, they are likely using one of these three persistence methods:

Git Author Spoofing & Lateral Compromise: Git does not authenticate the author of a commit, only the pusher. Anyone with write access to the repository can set git config user.email to your email address. Because the malicious code was pushed to the org repo, it is highly probable that another teammate pulled the repo and ran a build. Their tokens were then harvested, and the attacker is now pushing via your teammate's compromised account while spoofing your email to cover their tracks.

Malicious Deploy Keys: When attackers compromise an account with admin access to a repository, they often add a hidden Deploy Key with write access in the repository's settings. Deploy keys are tied to the repo, not your user account, meaning your password resets and token revocations did not invalidate it.

CI/CD Pipeline Poisoning: The code injected in image_615d44.png is placed in a build configuration file (postcss.config.js). This means the payload will execute automatically whenever the CSS is processed. If your organization uses GitHub Actions or another CI/CD tool to build the project, the runner itself is executing the malware. The attacker may be using the runner's GITHUB_TOKEN or stealing environment variables to force-push code back to the repository.

Immediate Action Plan
To fully lock the attacker out, you need to look beyond your personal account and secure the organization:

Verify the Commits: Check the unauthorized force-pushes in the GitHub UI. Do they have the green "Verified" badge? If they do not, it is definitive proof that the attacker is spoofing your email using another authentication method.

Audit Repo-Level Access: Immediately go to the organization repository settings and audit Deploy Keys, GitHub Apps, and Webhooks. Delete anything you do not explicitly recognize.

Trigger an Org-Wide Reset: Treat the entire engineering team as compromised. Every developer who has interacted with that repository since the initial breach must revoke their tokens and audit their local environments.

Analyze the Payload: For context on the attacker's motives, the obfuscated script in image_615d44.png explicitly references Ethereum RPC endpoints (e.g., eth.blockscout.com, ethereum-rpc.publicnode.com). This indicates the malware is likely scanning local environments and CI runners for cryptocurrency wallets, private keys, or attempting to drain smart contracts.

[Divya-shr]

This is a solvable puzzle!! The fact that force-pushes resumed after a full token/password/SSH rotation is actually the most important clue — it means the compromise isn't at the "stolen credential" layer anymore, it's at the "something on my machine or in my account settings keeps minting new credentials" layer. Here's a draft answer you can post:

The fact that this happened again after a full credential rotation is the key diagnostic signal. It tells you the attacker isn't just replaying an old stolen token — something is actively generating new access. That narrows the search a lot. A few things people often miss in exactly this situation:

1. Check the GitHub Security Log, not just "revoke everything"
   Go to github.com/settings/security-log and filter for oauth_authorization, personal_access_token, public_key, and ssh_certificate_authority events. This shows you exactly when a new token/key was created, from what IP, and — critically — whether it happened again after your rotation. If a new PAT was minted post-rotation, your machine (or something with access to your session) is still compromised, not just your old credentials.

2. OAuth Apps and GitHub Apps are separate from PATs — and easy to forget
   Revoking PATs and SSH keys doesn't touch authorized OAuth Apps or GitHub Apps. Check both:

github.com/settings/applications (Authorized OAuth Apps)
github.com/settings/installations (Installed GitHub Apps)

A malicious OAuth app with repo scope survives password changes, 2FA enrollment, and PAT revocation entirely — this is a very common way "I did everything and it happened again" plays out.

3. Credential helpers and cached sessions on disk
   git config credential.helper may be pointing at OS-level credential storage (Windows Credential Manager, macOS Keychain, or a plaintext ~/.git-credentials) that still holds a valid token even after you "signed out all sessions" in the browser. Check:

git config --global --get credential.helper
cat ~/.git-credentials 2>/dev/null

Also check ~/.gitconfig for injected url.insteadOf rewrites or a hijacked credential.helper pointing at a malicious script.

4. npm/yarn config and persistence hooks
   Malicious loaders frequently modify:

~/.npmrc / ~/.yarnrc (registry hijacks, auth tokens, or _authToken fields)
Shell startup files: ~/.bashrc, ~/.zshrc, ~/.bash_profile

Scheduled persistence: cron jobs (crontab -l), macOS LaunchAgents (~/Library/LaunchAgents), or Windows Scheduled Tasks / Run keys

A signature-based scan finding "no traces" doesn't rule this out — a lot of these loaders drop small, non-signature-matched shell one-liners rather than a detectable binary.

5. Environment variables

env | grep -i -E "token|github|npm"

Some info-stealers just dump GITHUB_TOKEN/NPM_TOKEN env vars, which persist across reboots if they're set in a shell profile rather than the session.

My honest recommendation: given this has now recurred after a full rotation, I would not trust the machine anymore. Signature-based malware scans are unreliable against custom loaders. At this point:

Pull the security log evidence above first (for your CTO/security team — they'll want IOCs and timestamps).
Do the full OS wipe you're already considering — this is the right call, not overkill.
Rotate credentials from a clean, different device, not the infected one, so nothing on the compromised machine can observe the new tokens.
Ask your org admin to check the organization audit log (github.com/organizations//settings/audit-log) for the force-push events — it'll show whether the action came from a PAT, OAuth App, deploy key, or SSH key, which tells you precisely which door is still open.
Report the malicious package to npm (npm.im/support) and to GitHub Security Advisories so others get warned — include the package name/version if you can share it.

The org-level audit log in particular will likely give you the definitive answer faster than anything on your end.