Axios NPM Supply Chain Compromise; Apple Backports Critical Patches for iOS 18; Claude Code Source Code Exposed

Please note that this supply chain attack also drops a RAT on Win/Mac/Linux developer workstations. Please go through and scrub for the IOCs on OS and DNS, even if EDR did not alert. Some places I’m working with discovered they were infected by looking at the dev workstations using MDM/EDR to look for those IOCs, 1-2 days after thinking they were clear from the SDLC ecosystem side. This is tricky stuff, give yourself a stronger detection chance by looking everywhere.The other piece to this is on the remediation: What secrets were possibly stolen, and how do we prioritize secret rotation, while not bringing down important systems that rely on those secrets? SDLC prevention is a whole other comment.

This was a startling and audacious attack. Thankfully, it was found quickly and IOCs and various defenses were available fast. The SANS emergency webcast on the topic that same day was super helpful in figuring out what happened and what real-world defenders need to do about it. Information about altering development practices and CI/CD pipelines was particularly useful and could help put some limit on similar attacks in the future.

If you do nothing else make sure you're on the updated versions of Axios post haste. Note you need to remove the node_modules/plain-crypto-js directory. Better still, read the blog from Josh Wright: he lists things your developers, Blue Team and incident responders need to do. Even better than that, watch the SANS Emergency Briefing on Axios to get the full story on this compromise.

The Axios breach has many things to look at if you are working with CI/CD. The infection chain was very well planned and has a lot of interesting artifacts. The fact that it targeted Windows, Mac, and Linux is fascinating. Simple infection chains but very effective. The way it hidden by changing the package.json and creating a version of it that looked “clean” instead of the infected version is also interesting. The attack chain started 18 hours before the initial changes to the repo. This was a well-thought-out attack. So far “only” 135 infections but that is also because the total compromise time was 3 hours.

If you have any devices on iOS 18 get them on 18.7.7. This is serious. Then get them replaced with iOS 26 compatible devices. Don’t forget the devices in storage or otherwise seldom used.

Remember, if you have a mobile device fleet that include Apple devices, either issued by corporate or Bring Your Own Device, it is important to ensure that you have them as part of a Mobile Device Management platform so you can ensure they are updated in a timely manner. Relying on users to upgrade is not a viable vulnerability management strategy.

AAPL is recognizing that they still have a significant number of product users on the older iOS version that need protection. MSFT has done this as well in the past. While there is every reason for users to move to the newest version of an operating system, inertia and business applications mostly get in the way. It is what it is.

Apple, for security reasons, does not promise to support its hardware forever. Users of unsupported hardware and software should assume that this is a one-off. They should not expect Apple to do this ever again, much less that it will do it routinely. Apple publishes the end-of-support dates for all hardware. Obsolete Apple devices should not be used for sensitive applications in today's hostile environment. Hardware is cheap; stay current.

Apple is taking this exploit chain seriously to go back and back port these updates. Keep your phones patched.

While this would be a good time to advise any downloaded copy’s of Claude code be checked to ensure they are legitimate, that is not public code and you need to make sure it’s a licensed copy. Beyond that, grab the IoCs to make sure that you’re not impacted and have conversations about how AI agents and source code downloads are protected and verified.

Use this new item for a tabletop “Could this happen to us?” SecDevOps exercise if you have proprietary source code.

I would not suggest running Claude Code that has been leaked. There are too many opportunities for this to be backdoored.

Never ever underestimate the resourcefulness of the miscreant. Suffice it to say, the cybersecurity community will be dealing with this supply chain risk well into 2027.

Our guidance in our consultancy is to advise everyone to move to OpenSSH 10 at a minimum and TLS 1.3. It will be harder with Windows endpoints than others, however; start the process now. We still see clients using TLS 1.0. We have been fortunate that TLS hasn’t been able to be widely exploited but those days are slowly ending.

This is a useful reminder that organisations should not treat post-quantum cryptography as a distant problem. While some of the timelines discussed remain speculative, the “store now, decrypt later” risk is very real today. Organisations, particularly those that are regulated for example by the EU GDPR etc., should start planning for post-quantum cryptography migration rather than waiting for firm deadlines.

Google’s emphasis on prioritizing PQC migration for authentication services is definitely timely and appropriate. We don’t want to end up with strong authentication relying on trivial encryption – remember the early risks of NTLM over the Internet?

For most people, this is interesting but not compelling; updates will come. If, however, you work in a highly sensitive industry where store-now-decrypt-later presents measurable business risk, challenge your developers to move to PQC algorithms quickly.

The threat of a CRQC is becoming real given the announcement by GOOG. As pointed out in their research paper, the threat to ECC based cryptographic systems is nearer than originally thought. Organizations that have systems based on ECC should start planning for migration to PQC based algorithms now.

A little proportionality is indicated here. PQC is for highly sensitive, long-lived data where "store now decrypt later" (SNDL) attacks are likely to be efficient. Most of the data that we encrypt has a very short life. While nation states will clearly employ quantum computing for cryptanalysis, its use will be sparse and expensive for at least another decade. Even with quantum computing, Google talks about solving for an RSA private key in hours to days. Think about the number of RSA keys that we create every day, much less the number that are already in use. RSA will continue to be useful, efficient, and used for a very long time. If you are not already aware that your data is vulnerable to SNDL attacks, then it is almost certain that it is not.

“We switched to manual operations” should not be viewed as a success condition but rather as a last line of defense. Sixteen hours of manual control means operators were carrying the full burden of safety, monitoring, and decision-making without the automated control systems they rely on every day. That works for a while, yet it does not scale and it introduces human fatigue into a safety-critical process. The more concerning detail is that a ransomware event reached a SCADA server. That points to a breakdown in separation between business IT and control systems, or at least a pathway that should not have been available. Critical control functions need to be designed so that compromise of enterprise IT systems cannot propagate into the operational environment, and recovery should not depend on replacing core control infrastructure while under incident handling pressures.

With the increased targeting of civilian critical infrastructure in regional conflicts, organisations need to recognise that geography offers little protection in cyberspace. While physical attacks are constrained by location, cyberattacks are not. Operators of critical infrastructure, regardless of where they are based, should assume they could become targets and ensure appropriate security controls, monitoring, and resilience measures are in place to defend against such threats.

While the attack seems to be contained to the server that collected gauge readings, a concern is now how to prevent introduction of ransomware in the future. The good news is they are not only able to fail back to manual gauge reading but also that those reads are regularly performed anyway but at a much larger interval, which means staff is already trained on how to fail back and use that data appropriately. Make sure you optimize staff training and resources for success for failover scenarios.

The encouraging piece of this story is that reversion to manual practices worked. If I were responsible for critical infrastructure, I'd write, "Can we survive Volt Typhoon?" on my bathroom mirror.

Klaxons should be sounding across the country to the threat on one of our most critical infrastructures. It’s time for the government to put money behind its words (i.e., national cyber strategy) and help municipalities implement an effective cybersecurity program.

Anyone else having Adobe Flash flashbacks? Hopefully your regimen of browser restarts and updates is hands off. Remember: “Trust but verify.”

Maintenance of browsers is continuous and their stability and trust are low. Their presence and use is pervasive and their application broad, unpredictable, and otherwise risky. Prefer purpose-built clients for mission critical applications.

The findings in this report reinforce that cyber incidents are no longer exceptional but expected. It is therefore worrying to see that many organisations, and not just in the manufacturing sector, remain reactive to cyber threats. Cybersecurity needs to be embedded at board level and treated as a business risk and not as an IT risk. With increasing cybersecurity-related regulatory pressure, particularly across the EU and UK, organisations that fail to mature their security posture will face both operational and compliance risks and their board members can face personal liability.

This report should be a wake-up call for the manufacturing industry. If the UK manufacturing industry doesn’t already have an Information Sharing and Analysis Center (ISAC), they should. It’s a great way to share threat intelligence specific to that sector and perhaps more importantly, security best practices.

"An ounce of prevention..." While timely patching is necessary, its cost is high and continuous. Not so for strong authentication and structured networks.

Make sure you read through the latest guidance on how to protect your Global Administrator accounts. These accounts are equivalent to Domain Admin but I still find companies that use their Global Admin access on day-to-day accounts, or through the default PIM settings which are set to expire every 12 hours. The current guidance we provide is separate Global Admin accounts with 1-hour expirations for both token lifetimes. Guard these accounts.

Less than a month to restore operations is commendable. Note they are still forensically examining the breach which means more information is pending about what was exposed/exfiltrated. Hopefully that will complete quickly as well.

Organisations should use this breach as a learning opportunity and build this scenario, or similar scenarios where all their IT devices are wiped, to create more robust cyber resilience solutions.

While Hasbro has responded quickly, and I don’t envy them being in this position. The unanswered question is, have they taken steps to prevent recurrence? Beyond implementing your response plan, you need to assure customers and employees you have taken measures to contain/eradicate and prevent recurrence. Even if you haven’t done these things, you should be talking about how you will be (quickly) doing them.

First comes the announcement, then the loss of PII, then the commitment to cybersecurity. What’s slightly different in this case is that Hasbro is a Fortune 500-600 company. One would think that they have sufficient resources allocated to cybersecurity.