FakeGit Campaign: 7,600 GitHub Repos and SmartLoader via Fake MCP Servers

We've started implementing a policy where any code pulled from GitHub Actions must reference a specific SHA commit hash, not a branch tag. It’s tedious, but with campaigns like FakeGit using typosquatting and lookalike repos, trusting a 'main' branch is a huge risk right now.

Also, be careful with the MCP servers specifically; a lot of devs are enabling these blindly to get LLMs connected to their local environments. We've blocked execution of unsigned binaries in dev sandboxes as a temporary stopgap.

From a threat hunting perspective, the SmartLoader C2 traffic usually stands out because it tries to look like standard API calls but fails on TLS fingerprinting. I recommend adding a KQL rule to your SIEM for processes spawned from archive tools (like explorer.exe or cmd.exe) immediately initiating network connections.

ProcessCreate
| where ProcessVersionInfoOriginalFileName in ~"explorer.exe"
| where NetworkIP is not null
| where InitiatingProcessVersionInfoOriginalFileName in ~"WinRAR.exe" or "7zFM.exe"


It might catch some false positives with legitimate installers, but better safe than sorry with this volume of repos.

It's wild that they managed to spin up 800+ fake MCP repos without getting flagged faster. It speaks to the difficulty GitHub has distinguishing between a 'copy-paste' learning project and a malicious clone.

I've been advising my team to check the 'Commit History' tab. If you see a repository with years of history and then a sudden massive spike in activity or a batch of 'documentation fixes' adding ZIP files, that's your red flag.

Agreed on SHA pinning, but we also need to inspect the payload configuration itself. Since these rely on 'complex setups,' we added a pre-flight check to validate the mcp. for suspicious patterns. This simple Python script helps flag base64 blobs or unauthorized URLs before the code even runs.

import , re
with open('mcp.') as f:
    config = .load(f)
    if re.search(r'data:[^;]+;base64', str(config)):
        raise ValueError("Suspicious encoding detected in config")

Building on the pre-flight checks, we noticed SmartLoader often hides C2 configs in Base64 within the server configuration. We added a CI step to scan for long alphanumeric strings and attempt a decode, flagging any results that look like URLs or IP addresses.

grep -r --include="*." -Eo '[A-Za-z0-9+/]{50,}={0,2}' . | base64 -d

Excellent insights on the CI checks. From an IAM perspective, the biggest risk here isn't just the SmartLoader itself, but the potential for credential theft when developers test these 'AI skills' with their real API keys.

We've started enforcing a policy where any integration running in a dev environment must use short-lived, scoped credentials. Additionally, we added a pre-commit hook to scan for accidental key leaks in local config files:

git diff --cached --name-only | xargs grep -iE 'api_key|secret_token|aws_access'


It acts as a last line of defense against typosquatting repos designed to harvest credentials.

That’s a solid approach on the Base64 inspection. We’ve also observed attackers relying on 'mirrored' packages that don't actually exist in public registries to avoid static analysis. To catch this, we integrated a quick validation step in our pipeline that queries the registry directly for every dependency. If a package in requirements.txt isn't found on PyPI, we abort the build.

import requests

def verify_package(pkg_name):
    return requests.get(f"https://pypi.org/pypi/{pkg_name}/").ok

Great insights on the payload checks. To catch these earlier in the pipeline, we've started requiring developers to run a Trivy scan locally immediately after cloning. It helps identify the obfuscated scripts often hidden in these 'learning' repos before they ever reach CI.

Here is the simple hook we are testing:

#!/bin/bash
trivy fs . --severity HIGH,CRITICAL --exit-code 1