Two billion downloads per week. That’s the download totals for the NPM packages compromised in a supply-chain attack this week. Ninety-nine percent of the cloud depends on one of the packages, and one-in-ten cloud environments actually included malicious code as a result of the hack. Take a moment to ponder that. In a rough estimate, ten percent of the Internet was pwned by a single attack.

What extremely sophisticated technique was used to pull off such an attack? A convincing-looking phishing email sent from the newly registered npmjs.help domain. [qix] is the single developer of many of these packages, and in the midst of a stressful week, fell for the scam. We could refer to the obligatory XKCD 2347 here. It’s a significant problem with the NPM model that a single developer falling for a phishing email can expose the entire Internet to such risk.

And once that account was compromised, it didn’t take long for the mystery attacker to push malicious code. Within an hour, cryptocurrency stealing code was added to two dozen packages. Within a couple hours, the compromise was discovered and the cleanup effort began.

BREAKING

LARGEST SUPPLY CHAIN ATTACK IN HISTORY PULLS OFF MASSIVE CRYPTO HEIST

ATTACKS STEAL $20.05 OF ETH. ENTIRE WORLD CRUMBLING

— vx-underground (@vxunderground) September 8, 2025

While the attack was staggering in its breadth, in the end only a few hundred dollars worth of cryptocurrency was actually stolen as a result. Why was such a successful attack, when measured by deployment, so minimal in actual theft? Two reasons: First, the malware was only live for two hours before takedowns began. And a related second reason, the malicious code was specifically aimed at developer and end-user machines, while the majority of the installs were on servers and cloud deployments, where cryptocurrency transactions weren’t happening.

It brings to mind the question, what could have happened? Instead of looking for cryptocurrency to steal, if the malicious code was tailored to servers and stealth, how long would it have taken to detect? And is there malicious code on NPM and in other places that we just haven’t discovered yet?

SAP ERP CVEs

Let’s break down this Alphabet soup. SAP is an acronym for “Systems, Applications and Products in Data Processing”, a German company providing business software. ERP is their Enterprise Resource Planning software, and of course a CVE is a Common Vulnerabilities and Exposure. So to translate the acronyms, SAP’s accounting software has vulnerabilities. And in this case, CVE-2025-42944 is a ten out of ten on the CVSS severity scale.

In fact, there are four vulnerabilities altogether, all CVSS of nine or higher, and all in the underlying NetWeaver platform. SAP owned up to the problems, commenting that they operated as a backdoor, allowing unauthorized access. Patches are available for all of these issues, but some of them have been found in use in the wild.

Kerbroasting

You know it’s bad when a sitting US Senator can tell that your security has problems. Though before I read the article, I had a feeling it would be [Ron Wyden].

The issue here is Microsoft’s support for RC4 encryption in Active Directory. RC4, also known as ARC4, is a pseudorandom number generator developed at RSA in 1987. This continuing support leads to an attack known as kerberoasting.

Kerberos is one of the protocols that powers Active Directory. It works through a sort of ticket signing system. The server doing the signing takes a hash of a password and uses that hash as an encryption key to encrypt the Kerberos ticket. There are two possible problems. First, that password may be a human generated password, and therefore a weak password. And second, the legacy combination of RC4 and original NT hashing makes for extremely fast offline password guessing.

So here’s the kerberoasting attack: Take any account in the Active Directory, and request a Kerberos ticket, specifying the legacy RC4 encryption. Take this offline ticket to a modern CPU/GPU, and use Hashcat to crack that password, at a guess rate measured in the billions per second. Once that password is discovered, arbitrary Kerberos tickets can be signed, providing access to basically any account on the AD system.

This was part of the 2024 ransomware attack on Ascension health, and why the US senate is taking notice. What’s strange is how resistant Microsoft has been to fixing this issue. Microsoft states that RC4 only makes up .1% of traffic, which is nonsense, since the attack doesn’t rely on traffic. Finally in 2026, new installs of Windows server 2025 will disable RC4 by default.

Reverse Engineering and TLS Hacking

We get a great primer from [f0rw4rd] on how to defeat TLS certificates, in a very specific scenario. That scenario is reverse engineering an embedded or industrial Linux system. One of the tools you might want to use is to intercept traffic from the embedded system to some web server, but if that system uses HTTPS, it will fail to verify that certificate. What is a researcher to do?

One possible solution is to abuse LD_PRELOAD to poison the application. This approach uses dynamic library loading to insert a “malicious” library before program execution. tls-preloader is a tool to do exactly this, and supports multiple SSL/TLS libraries, allowing sniffing all that useful TLS data.

The Rest of the Story

Just recently we mentioned several 0-day vulnerabilities that were being used for in-the-wild attacks. This week we have updates on a couple of those. First is the iOS and macOS vulnerability in DNG image file processing. The basic issue is that this file type has a TIFF header that includes a SamplesPerPixel metadata, and a SOF3 section with a component count. A properly formatted file will have consistency between these two elements, and the Apple file processing didn’t handle such an inconsistency correctly, leading to memory corruption and potentially Remote Code Execution (RCE).

The other recent 0-day is a FreePBX flaw that was discovered through the presence of a clean.sh script on multiple FreePBX installs. The flaw was an automatic class loader that allowed an unauthenticated user to include module files when calling the ajax.php endpoint. One way to turn this into an exploit is SQL injection in one of the modules. This is what has been patched, meaning there are likely more exploits to find using this php injection quirk.

Bits and Bytes

The Apple CarPlay SDK had a buffer overflow that was reachable by a device connecting to the vulnerable head unit. Researchers from oligo discovered this flaw, and presented it at Def Con this year. The end result is root-level RCE, and while Apple has already published an SDK update, most cars are still vulnerable to this one.

And finally, enjoy [LaurieWired] taking a look at this year’s International Obfuscated C Code Contest (IOCCC) winners. This contest is all about pushing the limits in how terrifying C code can be, while still compiling and doing something interesting. And these entries don’t disappoint.