Most credential-stealing malware has a boring business model. Steal logins, dump them on a stealer log shop, get paid in bulk pennies per record. The operator behind a campaign called PhantomRaven skipped that step entirely. CrowdStrike’s newest analysis, published in September, found no trace of the stolen data on any underground market. Instead the operator appears to have used it to go hunting for real bugs in the very companies whose developers got infected, then filed the findings through legitimate bug bounty programs and collected the payout like any other researcher.
That is the detail that makes this worth a proper look, not the malware itself, which is fairly ordinary npm supply chain tooling. The interesting part is what happens after the theft, and the fact that CrowdStrike is confident the malware’s code was written by a language model rather than a person.
How the packages get in the door
PhantomRaven has been running since November 2022 and Koi Security and DCODX first flagged it publicly in October 2025. Over that stretch the operator, working under a cluster of linked npm accounts including jpd12, jpd13, jpd15, npmhell, npmpackagejpd, and jpdhackerone11, has published more than a hundred packages to the npm registry. Two confirmed examples are transform jsbi to bigint and sort imports es6 autofix, names built to sit one keystroke away from something a developer would actually type.
That naming trick is worth pausing on, because it is not simple typosquatting anymore. A growing share of these campaigns rely on what researchers now call slopsquatting: package names that do not exist in any registry until an attacker registers them, but that show up anyway because a coding assistant hallucinated them. Ask a model for a library that does X and it will occasionally invent a plausible sounding name with total confidence. Whoever gets there first and claims that name on npm now sits directly in the install path of every developer who trusted the suggestion without checking. We do not know for certain that PhantomRaven’s targets were seeded that way rather than through classic misspellings, but the pattern fits the broader trend, and it is one more reason to stop treating a package manager’s autocomplete or an assistant’s import suggestion as ground truth.
The part that actually let these packages survive on the registry for years is a technique the report calls a remote dynamic dependency. The published package itself is close to harmless. It contains a small installer hook that reaches out to an external server at install time and pulls down the real payload on the spot. Static analysis of the package as published finds nothing worth flagging, because the malicious logic is not in the package. It arrives later, from infrastructure the attacker controls, which they can update, rotate, or shut off the moment anyone gets close. Anyone who has done source composition analysis for a living will recognise the problem immediately: you can review the code that ships, but you cannot review the code that shows up thirty seconds after npm install finishes.
What actually gets stolen
Once it lands, the payload is a fairly complete developer-machine census. It pulls email addresses out of git and npm configuration, grabs CI/CD environment variables from GitHub Actions, GitLab CI, Jenkins, and CircleCI runners, and records the machine’s public IP, username, and timestamps. None of that is exotic on its own. What makes it dangerous in aggregate is that a CI/CD environment variable dump from a real pipeline is not a password to one system, it is frequently the keys to several: package registry publish tokens, cloud provider credentials scoped for deployment, sometimes a GitHub App token with write access to more than one repository.
This is the same underlying weakness we wrote about when we covered the ChainDrop npm worm, a separate campaign that hit 444 packages with credential theft and its own command and control infrastructure. Two unrelated operators reaching for the same target tells you something about where the actual weak point in modern software delivery sits, and it is not the application code most security budgets are aimed at.
The part that should worry bug bounty programs
Here is where PhantomRaven stops looking like an ordinary infostealer. According to the report, the operator claims to have collected bounties from at least nine organisations across technology, retail, and hospitality, and in August 2025 reported what they described as a remote code execution vulnerability discovered through a malicious npm package they had themselves published.
Read that last sentence twice, because the mechanics matter. If a threat actor already has your CI/CD secrets, your build server’s outbound access, and a live foothold from a developer machine, finding a genuine security weakness in your production environment is no longer a hypothetical exercise for them. They are not guessing where the bug might be. They have already walked the hallway. Filing that discovery through a bug bounty program launders unauthorised access into a legitimate-looking paid engagement, and it does it in a way that is very hard to distinguish from an honest researcher who got lucky, unless someone on the triage side happens to ask how a report from an unknown account with a thin history came together so quickly and so precisely.
We have not seen anyone publish the actual submission text, so we cannot say for certain that every one of those nine payouts followed this exact path. But the absence of PhantomRaven’s stolen data from any stealer log marketplace is the strongest signal in the whole report. Criminals sell what they cannot use themselves. This operator kept everything, which only makes sense if they had a better use for it than resale.
Malware written by a model, not a person
CrowdStrike’s attribution here is unusually direct for a vendor report. Their analysts concluded with high confidence that the developer used a large language model to write the malware, based on verbose comments, placeholder code left in the final artifact, and statistical patterns in the token distribution that match generated rather than hand written code.
That is a genuinely new kind of forensic signal, and it cuts both ways. For now, sloppy, over-commented, template-shaped code is a tell, and it is helping researchers attribute campaigns faster than they used to. But that tell only exists because whoever built PhantomRaven did not bother to clean up after the model, the same pattern we keep running into whenever we look at attacker-built tooling generated this way: functional code shipped with none of the hardening or review a human author would normally apply out of habit, not caution. The people running these operations are treating output from a coding assistant exactly the way a rushed developer treats it inside a legitimate company, which is to ship it and move on. The next operator who spends an afternoon cleaning up the comments will not leave the same fingerprint, and attribution will get harder again. Anyone deciding whether AI narrows or widens the gap between defenders and attackers should sit with that for a minute: it currently does both, on different sides of the same campaign.
What this actually means for you
- Treat your dependency tree as an active attack surface, not a one-time approval. A package that looked clean on the day someone approved it can still fetch new code on every install. That is exactly the blind spot a secure code review of your build and install scripts is meant to close, and it needs repeating on a schedule, not once at onboarding.
- Stop putting long-lived, high-value secrets where a compromised laptop can read them. Static publish tokens and broad cloud credentials sitting in CI environment variables are exactly what this malware went looking for. A cloud configuration review is the fastest way to find out how much blast radius a single stolen CI variable actually has in your environment, before you find out the hard way.
- If you run a bug bounty or VDP program, add a little healthy suspicion to intake. A report that arrives unusually fast, from a new account, with unusually precise internal detail, deserves a second look at how the researcher could plausibly have gotten there. We covered a related pipeline weak point in our writeup on CI pipelines as the softest target, and the logic is the same here: the shortcut into your bounty payout and the shortcut into your production environment are often the same door.
- Assume a foothold already happened somewhere and go looking for it. If your developers pull from public registries, and almost everyone’s do, the honest starting point is not “are we vulnerable” but “how would we know if we already were.” An assumed breach assessment answers exactly that question instead of hoping the answer is no.
Bottom line
PhantomRaven is not remarkable for its exploit or its malware, both of which are unremarkable by 2026 standards. It is remarkable because it shows a full loop closing: an AI model helps write the tooling, the tooling harvests real access into real companies, and that access gets recycled into legitimate, paid bug bounty income instead of a criminal marketplace. Every one of those steps was already possible on its own. Watching them chain together into one operator’s business model is the part worth remembering the next time a security report lands from an account with no history and answers that arrive a little too fast.