I built an npm malware scanner and found 21 malicious packages in 24 hours

Yuri Borges — Fri, 03 Apr 2026 16:42:48 +0000

I built an automated scanner that monitors new npm packages in real time. Ran it for 24 hours against ~2000 recent registry changes and it flagged 21 malicious packages across 11 campaigns.

Four of them use attack techniques I haven't seen documented before, all targeting AI coding assistants.

The Findings

1. LLM API Man-in-the-Middle — A package overwrites ~/.claude/ on install and redirects all Claude API traffic through an attacker-controlled proxy. Every prompt and response passes through their server.

2. Encrypted Skill Backdoor — A package downloads encrypted payloads from a remote API and installs them as Claude Code skills. The payloads can't be inspected, and the server can swap them anytime without updating the npm package.

3. RAT Disguised as AI Coding Tool — Two packages ship polished coding assistant CLIs but route everything through an attacker's ngrok tunnel. Users grant full filesystem access voluntarily because they think it's a legit AI tool.

4. Redis + Raw Disk Read via postinstall — Six fake Strapi plugins use Redis to write shell payloads, open reverse shells, and read raw disk via dd to steal SSH keys and crypto wallets.

Other Catches

Dependency confusion targeting Verisign, a commercial phishing toolkit with 95 versions, credential stealers behind fake React components, and obfuscated packages impersonating ByteDance's npm scope.

None were flagged by npm, Snyk, or Socket at time of discovery.

Quick Check

If you use AI coding tools, check for unauthorized config files:


bash
ls ~/.claude/commands/
ls ~/.cursor/
ls ~/.continue/config/

Full technical reports with IOCs and MITRE mappings: yuribm.dev/security

I'm 18 and Built an Open-Source Camera That Cryptographically Proves Photos Are Real

Yuri Borges — Wed, 01 Apr 2026 14:24:07 +0000

In 2026, generating a photorealistic fake image takes seconds. The C2PA standard (Adobe, Microsoft, Google) solves this with Content Credentials — but only on Samsung S25+ and Pixel 10. The other 3 billion Android phones have nothing.

I'm 18, from Brazil, and I built TrueShot to change that.

What happens when you take a photo

14 physical sensors are sampled at the exact instant of the shutter — accelerometer, gyroscope, magnetometer, barometer, light, proximity, gravity, rotation vectors, and more
SHA-256 hash is computed on the JPEG bytes up to the EOI marker
ECDSA P-256 signs the manifest via hardware-backed Android Keystore (StrongBox preferred, TEE fallback)
The signed manifest is appended after the JPEG EOI marker — standard image viewers ignore post-EOI data, so the photo displays normally everywhere

Change one pixel → hash breaks. Forge the signature → mathematically impossible without the device's hardware key.

Anyone can verify in a browser at true-shot.vercel.app/verify. The image never leaves your browser.

The part I think is new

Sensor-based screen recapture detection

Every published method for detecting photos-of-screens uses visual analysis — moiré patterns, CNNs, Vision Transformers. The problem: modern OLED screens don't produce moiré. High-PPI displays don't cause aliasing. Visual methods are losing the arms race.

TrueShot does something different: it cross-correlates physical sensor readings to detect anomalies consistent with screen photography. No image analysis at all.

Scenario	Score	Flagged?
Normal photo (daylight)	20	No
Normal photo (dark room)	30	No
Screen capture (daylight)	70	Yes
Screen capture (dark room)	85	Yes

10 signals: focus distance, light/ISO mismatch, magnetometer magnitude, gyroscope stability, color gain blue-suppression, scene flicker, proximity, ambient darkness, step counter, and compound signals.

The approach works regardless of screen technology — LCD, OLED, MicroLED — because it never looks at the image content.

Cross-device corroboration without communication

Three reporters photograph the same protest on three different phones. Nobody pairs devices. Nobody sets anything up.

Later, an editor drops all three photos on the web verifier. JavaScript extracts the manifests and compares barometric pressure, timestamps, GPS, and ambient conditions.

Consistent sensors from independent devices = same event. Zero servers. Zero cloud. Everything happens in the browser.

Tech stack

Kotlin 2.1, Jetpack Compose, CameraX 1.4
Hilt for DI, Room for persistence
Android Keystore (ECDSA P-256, SHA-256)
Vanilla JS + WebCrypto API for the web verifier
14 Gradle modules, ~5,700 lines of Kotlin
Zero C++, zero ML models, zero third-party SDKs

What it honestly does NOT do

Does NOT detect deepfakes or AI-generated content
Does NOT guarantee content truthfulness — a staged scene photographed with TrueShot is authentic as a capture
Key attestation chain is included but not validated against Google Root CA yet
Screen detection is heuristic, not definitive — it can produce false positives on macro photography in dark rooms

Full threat model: THREAT_MODEL.md

Privacy

Zero analytics, zero tracking, zero cloud
GPS off by default, opt-in only
No Firebase, no Crashlytics, no third-party SDKs
Device ID is anonymous (SHA-256 of public key, not IMEI)
Web verifier processes everything in-browser

Try it

GitHub: github.com/YuriTheCoder/TrueShot
Download APK: Latest release
Verify a photo: true-shot.vercel.app/verify

MIT licensed. I'm preparing a paper on the sensor correlation approach for IEEE WIFS 2026 (deadline July 15). Feedback welcome, especially if you see attack vectors I'm missing.

Forem: Yuri Borges