The Day My GitHub Got Compromised: A Multi-Layer Malware Analysis

(posting this here, cause some Spicy Lyrics repos had malicious commits made)

Note: The following analysis contains code samples for educational purposes only. I've shared the obfuscation and delivery mechanisms to raise awareness, but have omitted the complete weaponized payload.

Well, it happened.

I was always like "ah, who would want to compromise MY GitHub account, right?" ...right?

Well I was wrong, and it happened.

On December 23, 2025, around 12 PM CET (noon), malicious code was pushed to a LOT of my repos — including both public and private ones. The attacker had somehow gained access to my account and systematically injected sophisticated malware across multiple repositories.

Initial Discovery

Thankfully, from my investigation, the code didn't leak to the main part of our backend services. Some of the builds failed, some ran, but thankfully they were isolated. The first indication something was wrong came when Vercel sent me an email about a deployment failing. Later when I got onto my computer, I decided to check my Vercel and GitHub repo, and there it was. The classic `preinstall.js`!

The Attack Architecture

Layer 1: Unicode Steganography

The initial infection vector used an advanced technique called Unicode steganography — hiding malicious code inside invisible Unicode characters (Variation Selectors). When you open the file in a code editor, it appears nearly empty or shows just a vertical bar. However, the file actually contains thousands of invisible characters that encode the entire next-stage payload.

The malware uses Unicode ranges U+FE00-FE0F and U+E0100-E+E01EF to hide data in plain sight. It extracts the low byte from each Unicode codepoint and reconstructs executable JavaScript that gets passed to eval().

Why this works: Visual code inspection fails completely. Certain developers scrolling through commits would see what appears to be an empty file or harmless code.

Layer 2: Sandbox Evasion

One variant included a 15-minute sleep delay before execution:

Most automated malware sandboxes timeout after 5-10 minutes, so the code would never execute in the analysis environment.

Layer 3: AES-256 Encrypted Payload

The third layer is a 54KB blob of AES-256-CBC encrypted data. The decryption keys are dynamically retrieved from HTTP response headers when downloading from the attacker's server:

Header: ivbase64 - initialization vector

Header: secretkey - 256-bit AES key

Only after successful decryption does the actual malicious code become visible.

Why this works: Static analysis tools cannot determine what the payload does without executing the code and fetching the decryption keys from a live server.

Layer 4: Blockchain-Based C2

The fourth layer implement the Solana blockchain as command-and-control infrastructure. Instead of using traditional C2 servers that can be taken down, the malware queries the Solana blockchain for configuration.

Specifically, it polls transaction memos from address BjVe... every 10 seconds, looking for JSON payloads containing:

URLs to download encrypted payloads

Decryption parameters passed via HTTP headers

The malware also implements persistence by creating an init.json file in the user's home directory, tracking infection age and preventing re-execution if the infection is less than 2 days old.

Why this works: Blockchain queries look like legitimate API traffic. The infrastructure is censorship-resistant and costs attackers nothing to maintain. Security tools monitoring for suspicious domains won't flag public blockchain RPC endpoints.

The code below executes the final payload for macOS devices:

Final Payload: Cryptocurrency Stealer

After all layers are unpacked, the malware executes a comprehensive data theft operation targeting macOS systems.

(We currently only extracted and analyzed the script that would run on macOS. Currently we're unsure how the script for other OSes works and looks like).

Browser Data Theft:

- Credentials from Chrome, Brave, Edge, Vivaldi, Opera, Firefox, Waterfox

- Cookies, form history, autofill data

- Encrypted password stores

- macOS Keychain database

Cryptocurrency Wallets:

- 150+ browser extension wallets (MetaMask and others)

- Desktop wallets: Electrum, Exodus, Ledger Live, Trezor Suite, Atomic, Coinomi, Wasabi, Bitcoin Core, Litecoin Core, Monero, and many more

- Configuration files from Binance, TonKeeper

Password Harvesting:
The malware displays a fake system dialog: "Required Application Helper. Please enter password for continue" with title "Application wants to install helper" — tricking users into entering their macOS password, which then gets validated and stored.

Document Exfiltration:
Scans Desktop, Documents, and Downloads for files matching extensions: txt, pdf, docx, zip, wallet, key, keys, doc, jpeg, png (up to 10MB total). Also targets Apple Notes databases.

Data Exfiltration:
All stolen data gets compressed into /tmp/out.zip and uploaded to:

- C2 Server: 45.32.150.251 (Vultr VPS, France)

- Payload Host: 45.32.151.157 (Vultr VPS, France)

Wallet Application Replacement:
If Ledger Live or Trezor Suite are detected, the malware downloads and installs trojanized versions from the attacker's server, replacing legitimate applications. These fake wallets intercept cryptocurrency transactions.

Infrastructure Details

@blueworldclass traced both IP addresses to Vultr hosted in France (same IP range, confirming shared infrastructure). The good news: Vultr is not a bulletproof hosting provider, and the malicious infrastructure was reported and likely taken down.

How Did They Get In?

I'm still investigating the initial compromise vector. The attack happening at noon suggests it could have been manual or triggered by something I did during normal development hours (since I wasn't at my computer at the time).

Likely candidates include:

- Compromised personal access token

- Leaked credentials from a previous breach

- Phishing attack I didn't catch

- Compromised development environment or IDE extension

Indicators of Compromise

If you think you might be affected, check for:

- Files: /tmp/ijewf/, /tmp/out.zip, /tmp/script_lock.tmp

- File in home directory: init.json

- Keychain entry: pass_users_for_script

- Network connections to Solana RPC endpoints or the Vultr IPs above

- Suspicious Unicode characters in JavaScript files

Lessons Learned

Use commit signing — GPG-signed commits make it harder for attackers to impersonate you

Monitor repository webhooks — Set up alerts for unauthorized commits

Review access tokens regularly — Rotate and remove unused tokens

Don't trust "empty" files — Unicode steganography is real and effective

Sandbox dependency updates — Test new dependencies in isolated environments

Supply chain attacks are evolving — Multiple encryption layers and blockchain C2 represent the new normal

Immediate Actions I Took

- Reset GitHub password with 2FA enabled

- Force-pushed clean commits to affected repositories

- Scanned all systems for the indicators above

- Reviewed audit logs for other compromised services

Timeline

December 23, ~12 PM CET: Initial compromise, malicious commits pushed

December 23, also ~12 PM CET: Commits reverted

December 23 8:36 PM CET: @blueworldclass contacts me with deeper analysis

December 23: @blueworldclass reports infrastructure to Vultr, remediation begins

Final Thoughts

This attack was remarkably sophisticated — far beyond what I'd expect targeting an individual developer. The combination of Unicode steganography, blockchain infrastructure, multi-stage encryption, and sandbox evasion shows a well-resourced threat actor.

If you maintain open-source projects or work with sensitive codebases, take this as a wake-up call. Modern supply chain attacks aren't just about typosquatting packages — they're about compromising legitimate maintainer accounts and injecting nearly-invisible malware that can survive multiple layers of code review.

Stay vigilant. Review commits, take security seriously.

Special thanks to @blueworldclass for the deep discovery and analysis.

The Vultr infrastructure has been reported and is likely offline. However, attackers can easily spin up new infrastructure, so remain vigilant for similar patterns in your own projects.

I will be updating this blog post as we gather more information.

I've also reported this incident to GitHub Support.

Wanna contribute? Contact me on my Discord @spikerko, or let us know at hi@spicylyrics.org.