PhantomRaven Attack Exploits NPM’s Unchecked HTTP URL Dependency Feature

An example of RDD in a package's dependencies list. It's not even counted as a 'real' dependency. (Credit: Koi.ai)
An example of RDD in a package’s dependencies list. It’s not even counted as a ‘real’ dependency. (Credit: Koi.ai)

Having another security threat emanating from Node.js’ Node Package Manager (NPM) feels like a weekly event at this point, but this newly discovered one is among the more refined. It exploits not only the remote dynamic dependencies (RDD) ‘feature’ in NPM, but also uses the increased occurrence of LLM-generated non-existent package names to its advantage. Called ‘slopsquatting’, it’s only the first step in this attack that the researchers over at [Koi] stumbled over by accident.

Calling it the PhantomRaven attack for that cool vibe, they found that it had started in August of 2025, with some malicious packages detected and removed by NPM, but eighty subsequent packages evaded detection. A property of these packages is that in their dependencies list they use RDD to download malicious code from a HTTP URL. It was this traffic to the same HTTP domain that tipped off the researchers.

For some incomprehensible reason, allowing these HTTP URLs as package dependency is an integral part of the RDD feature. Since the malicious URL is not found in the code itself, it will slip by security scanners, nor is the download cached, giving the attackers significantly more control. This fake dependency is run automatically, without user interaction or notification that it has now begun to scan the filesystem for credentials and anything else of use.

The names of the fake packages were also chosen specifically to match incomplete package names that an LLM might spit out, such as unused-import instead of the full package name of eslint-plugin-unused-imports as example. This serves to highlight why you should not only strictly validate direct dependencies, but also their dependencies. As for why RDD is even a thing, this is something that NPM will hopefully explain soon.

Top image: North American Common Raven (Corvus corax principalis) in flight at Muir Beach in Northern California (Credit: Copetersen, Wikimedia)

Making A Virtual Machine Look Like Real Hardware To Malware

Running suspicious software in a virtual machine seems like a basic precaution to figure out whether said software contains naughty code. Unfortunately it’s generally rather easy to detect whether or not one’s software runs inside a VM, with [bRootForce] going through a list of ways that a VirtualBox VM can be detected from inside the guest OS. While there are a range of obvious naming issues, such as the occurrence of the word ‘VirtualBox’ everywhere, there many more subtle ways too.

Demonstrated is the PoC ‘malware’ application called Al-Khaser, which can be used to verify one’s anti-malware systems, such as when trying to unleash a debugger on a piece of malware, run it inside a VM, along with many more uses. Among its anti-virtualization features are specific registry key names and values, file system artefacts, directory names, MAC addresses, virtual devices, etc.

In order to squeeze by those checks, [bRootForce] created the vbox_stealth shell script for Bash-blessed systems in order to use the VirtualBox Manager for the renaming of hardware identifier, along with the VBoxCloak project’s PowerShell script that’s used inside a Windows VirtualBox guest instance to rename registry keys, kill VirtualBox-specific processes, and delete VirtualBox-specific files.

Theoretically this should make it much harder for any malware to detect that it’s not running inside Windows on real hardware, but as always there are more subtle ways that are even harder to disguise.

Continue reading “Making A Virtual Machine Look Like Real Hardware To Malware”

Satellite Snooping Reveals Sensitive Unencrypted Data

In an era where running a website without HTTPS is shunned, and everyone wants you to encrypt your DNS queries, you’d expect that the telecommunications back-ends are secured tightly as well. Especially the wireless bits between terra firma and geosynchronous communication satellites.

But as recently discovered by US researchers, the opposite is actually true. The paper by [Wenyi Morty Zhang] et al. (PDF) goes into great detail on how they discovered these unencrypted IP traffic flows and what they found in these captures.

With an off-the-shelf consumer satellite dish mounted to the roof of a university building in San Diego, they performed a scan of IP traffic on 39 geosynchronous satellites. To their surprise, they found unencrypted data that belonged to companies like T-Mobile for their cellular backhaul, Internet traffic targeting airliners, and VoIP communication — all in the clear.

Even more worrying was what looked like military traffic and corporate VPN data containing unencrypted login details, corporate emails and much more. While T-Mobile immediately enabled encryption after this discovery, it remains to be seen whether anyone else will. It’s probably best to assume that any communication can be intercepted and to use e.g. PGP-encrypted emails for anything sensitive.

The researchers have made the IP encapsulation parser (in Python) for DVB-S2(X) captures available for anyone who wants to give this experiment a whirl themselves.

This Week In Security: Court Orders, GlassWorm, TARmageddon, And It Was DNS

This week, a US federal court has ruled that NSO Group is no longer allowed to use Pegasus spyware against users of WhatsApp. And for their trouble, NSO was also fined $4 million. It’s unclear how much this ruling will actually change NSO’s behavior, as it intentionally stopped short of applying to foreign governments.

There may be an unexpected source of leverage the US courts can exert over NSO, with the news that American investors are acquiring the company. Among the requirements of the ruling is that NSO cannot reverse engineer WhatsApp code, cannot create new WhatsApp accounts, and must delete any existing WhatsApp code in their possession. Whether this actually happens remains to be seen.

Continue reading “This Week In Security: Court Orders, GlassWorm, TARmageddon, And It Was DNS”

A screen shot of Wireshark in action.

Hacking A Banned Chinese Security Camera

Over on YouTube [Matt Brown] hacks a Chinese security camera recently banned by the US government. If you didn’t hear about this you can find out more over here: Major US online retailers remove listings for millions of prohibited Chinese electronics.

After powering the camera with a power-over-Ethernet (PoE) adapter [Matt] sets about monitoring network activity with Wireshark. The first data comes from DNS for the host devaccess.easy4ipcloud.com, which whois reports is operated by Alibaba Cloud LLC in California. This is a Chinese owned company with servers in the United States.

[Matt] covers some basics of TLS and how it works. He then goes on to explain how a Man in the Middle (MITM) attack works at a high level. To setup a MITM attack against the camera [Matt] sets up some port redirections using iptables for ports 443, 15301, 8683, 9898, and 12337 which his Wireshark analysis indicates were being used. His MITM attack works, which means the device is not properly verifying its certificate signing chain.

[Matt] goes on to reverse engineer the custom UDP protocol used for transmitting video data. He uses a vibe-coded Python program along with ffmpeg for that and manages to reconstruct a few frames of video taken from the UDP packet capture.

We think it would be safe to say that [Matt] did indeed find a few security problems with the camera as-is, but we don’t think that’s the point of the ban. The real problem is that there is auto-update facilities for the device firmware which means that in future malicious software could be uploaded by the manufacturer in the form of a firmware update. So even if this device was secure against MITM attacks and didn’t send unencrypted video data over UDP you would still have the problem of the firmware update if there is no trust.

Continue reading “Hacking A Banned Chinese Security Camera”

This Week In Security: F5, SonicWall, And The End Of Windows 10

F5 is unintentionally dabbling in releasing the source code behind their BIG-IP networking gear, announcing this week that an unknown threat actor had access to their internal vulnerability and code tracking systems. This security breach was discovered on August 9th, and in the time since, F5 has engaged with CrowdStrike, Mandiant, and NCC Group to review what happened.

So far it appears that the worst result is access to unreleased vulnerabilities in the F5 knowledge management system. This means that any unpatched vulnerabilities were effectively 0-days, though the latest set of patches for the BIG-IP system has fixed those flaws. There aren’t any reports of those vulnerabilities being exploited in the wild, and F5 has stated that none of the leaked vulnerabilities were critical or allowed for remote exploitation.

Slightly more worrying is that this access included the product development environment. The problem there isn’t particularly the leak of the source code — one of the covered projects is NGINX, which is already open source software. The real danger is that changes could have been surreptitiously added to those codebases. The fact that NGINX is Open Source goes a long way to alleviate that danger, and when combined with the security built into tools like git, it seems very unlikely that malicious code could be sneaked into the NGINX public code base. A thorough review of the rest of the F5 codebases has similarly come up negative, and so far it looks like the supply-chain bullet has been dodged. Continue reading “This Week In Security: F5, SonicWall, And The End Of Windows 10”

Attack Turns Mouse Into Microphone

As computer hardware gets better and better, most of the benefits are readily apparent to users. Faster processors, less power consumption, and lower cost are the general themes here. But sometimes increased performance comes with some unusual downsides. A research group at the University of California, Irvine found that high-performance mice have such good resolution that they can be used to spy on a user’s speech or other sounds around them.

The mice involved in this theoretical attack need to be in the neighborhood of 20,000 dpi, as well as having a relatively high sampling rate. With this combination it’s possible to sense detail fine enough to resolve speech from the vibrations of the mouse pad. Not only that, but the researchers noted that this also enables motion tracking of people in the immediate vicinity as the vibrations caused by walking can also be decoded. The attack does require a piece of malware to be installed somewhere on the computer, but the group also theorize that this could easily be done since most security suites don’t think of mouse input data as particularly valuable or vulnerable.

Even with the data from the mouse, an attacker needs a sophisticated software suite to be able to decode and filter the data to extract sounds, and the research team could only extract around 60% of the audio under the best conditions. The full paper is available here as well. That being said, mice will only get better from here so this is certainly something to keep an eye on. Mice aren’t the only peripherials that have roundabout attacks like this, either.

Thanks to [Stephen] for the tip!

Continue reading “Attack Turns Mouse Into Microphone”