GemStuffer: Turning RubyGems into a Data Exfiltration Channel
Just caught the report on GemStuffer, and it’s an interesting twist on supply chain attacks. Instead of dropping malware, the actors are abusing the RubyGems registry infrastructure to exfiltrate scraped data from U.K. council portals.
What stands out to me is the low download count mentioned by Socket. This isn't a 'spray and pray' malware campaign; it's a targeted data exfil operation using a trusted channel (the gem registry upload API) to bypass network egress filters. Since most orgs whitelist rubygems.org, the traffic likely flies under the radar.
I whipped up a quick KQL query for those using Sentinel to look for abnormal upload activity to this domain:
DeviceNetworkEvents
| where RemoteUrl contains "rubygems.org"
| where InitiatingProcessFileName == "gem"
| where NetworkDirection == "Outbound"
| summarize UploadBytes=sum(SentBytes) by DeviceName, RemoteUrl, bin(Timestamp, 1h)
| where UploadBytes > 1000000 // Flagging uploads > 1MB
The payloads are reportedly repetitive, which suggests an automated script is generating these gems. How is everyone handling 'trusted' package registries in your egress filtering? Do you rely on SBOM analysis, or are you actually deep-packet inspecting TLS connections to places like npm or RubyGems?
Good catch on the trusted channel angle. We usually block outbound connections to the internet from build servers, only allowing artifacts via an internal proxy like Artifactory. If we see a gem push command hitting the public internet from a CI runner, alarms go off immediately. It's the only way to be sure you aren't part of someone's exfil pipeline.
From a SOC perspective, blocking rubygems.org is a nightmare for devs. I'm more interested in the payload analysis. Since they are just pushing data, maybe we can look for high entropy in the gemspec files? I’d love to see a Yara rule that flags gem files containing base64 blobs that decode to HTML/JSON (the scraped data).
This reminds me of using DNS for exfil. It’s clever because the 'destination' is ostensibly allowed. If they are scraping council portals, they are likely targeting vulnerable web apps first. The gem is just the dump truck. I wonder if they are using the same compromised credentials to push gems as they are to scrape the data?
That's a stealthy vector for sure. DFIR teams should note that the uploaded gems are public, meaning the stolen data is exposed online until the gem is yanked. For rapid triage, you can inspect remote metadata without installing the package. To check the size or dependencies of a suspicious gem:
gem specification suspicious_gem --remote
This helps flag outliers—like a 50MB gem claiming to be a utility library—during investigations.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access