More on Freezer Hacks, Binance, and Amadeus Breach; Node-RED Max-Severity Flaw Exploited; Update to Fix Linux Kernel TCP Flaw

I've been concerned about where these refrigeration attacks might spread next, and the incident involving the French Blood Establishment illustrates why. Refrigeration is essential to blood supplies, pharmaceuticals, vaccines, and other healthcare services where losing temperature control can have consequences far beyond financial losses. What I find encouraging is that the EFS monitoring and alarm systems reportedly detected the manipulation, allowing personnel to move the affected products before they were lost. This is an important example of engineering resilience: Even when attackers compromise a control system, independent monitoring and operational safeguards can prevent a cyberattack from becoming a public health emergency.

Seeing EFS in this story caught my attention, since those happen to be my initials, too. But the implications here are deeply serious. We've been discussing attacks against supermarket refrigeration systems, where spoiled food and economic disruption are bad enough. Now we're seeing attackers manipulate cold storage supporting the blood supply. Compromising these systems could render vital blood products unusable, potentially disrupting life-saving medical care. Thankfully, EFS's monitoring and alarm systems detected the problem, allowing personnel to move the stored products to other facilities. That's an important demonstration of resilience under pressure. But the potential consequences are concerning. Organizations responsible for blood products, medicines, and other temperature-sensitive medical supplies need to protect remote management systems, maintain reliable monitoring and alarms, and rehearse contingency plans for protecting and relocating critical inventory. A compromised cold-storage facility can quickly become a patient-care emergency. People's lives may depend on getting this right.

Three days after our last comments about the refrigeration attacks, the supplier angle I worried about showed up at France's blood service. I said then that if your refrigeration was installed by a third party with remote support built in, you may have the same exposure and simply haven't been hit yet. EFS says it "was not targeted directly." I want to give EFS credit, because this is the good-news OT story where the controls did their job: Their "monitoring and alarm systems enabled the rapid identification of these anomalies," product was moved to other facilities, and no blood products have been reported lost. If something critical depends on a safety system, check whether that system runs on the same controller an attacker would be changing and tabletop the scenario. The Binance heist didn't need anything new to get started. It started with the same fake-recruiter trick we've been warning about for years. The part I'd pay attention to is the internal AI tool the attacker used to move to other engineers. We've rushed to connect these tools to everything, with broad access, and very few teams could tell you what theirs can reach or whose permissions it runs with. It's the security cat-and-mouse game, but on steroids. That's the question I'd be asking this week.

I spoke to a friend who works in the IT department of a large supermarket chain, and he reminded me that the issue was not just making sure the OT systems were secure at their facilities, but also making sure their suppliers were also properly protected, which makes the problem harder. The timing on those attacks is interesting when you consider the timing of efforts to address PHP2Shell, overlaid with the OT attack, which likely resulted in resource conflicts. Make sure you know how to resolve conflicts between incidents that both have potential high operational impacts before you need to do so.

The default should be that OT is hidden from the public networks. There will be exceptions for timely and convenient access to controls. Any such exceptions should use strong authentication and end-to-end application layer encryption.

This is one to put in a security awareness blast to any employees who can work from their home PCs, as Node-RED is widely used by hobbyists and ham radio operators.

I'm seeing a resurgence of detections leveraging canaries. If you're not using them, take a look at options. Make sure that you understand the consequences of a detected attack on one — I've been places where it's categorized as an actual intrusion, or where the information about the event is considered as sensitive as the most sensitive information on your network, which mostly impacts the use of third party solutions. Specific to this event, if you're running Node-RED (it'll be in your OT/ICS systems) make sure it is NOT internet accessible. Better still, make sure access is limited to only authorized devices, then deploy available updates as soon as possible. Get the IoCs from VulnCheck to your team, and make sure both that you're clean and detecting future attack attempts.

This is another vulnerability that is tricky to rank. The vulnerability is triggered by unspecified IP options. Most routers will drop IP options, block packets with IP options, or remove IP options. The multi-path TCP option is needed for the remote code execution exploit. But even with the multi-path TCP option, using only IP options, a denial-of-service attack is possible. Verify that your perimeter does not allow IP options to pass. Next, disable multipath TCP, if possible, to avoid the worst-case scenario of this vulnerability. As is so often the case, your IoT/embedded Linux devices will be the most difficult to patch or mitigate.

Prioritize deploying this update on systems which connect to the Internet or other untrusted networks. Don't forget to come back and get all your other systems. While many Linux distributions have the fix, don't assume it's available for everything; validate, and watch for the missing ones. Deploy it where you have it; don't wait to create a waterfall event. Consider turning off MPTCP listeners where not needed — this could come back to haunt you, so use caution. Another possible mitigation is to drop TCP packets which carry IP options by creating a filter which catches TCP packets with a header length of 20 bytes, and while it's almost never used, be prepared for impacts if you're using them.

When Ubuntu announced faster kernel releases a few months ago, I posed the question, "If a kernel fix shipped this Friday, when would it actually be running in production?" because Linux environments just don't patch as fast as the vulns (and patches) are coming. I don't fault developers for testing, because that testing is why people trust things in production, but when you stack your own change window and reboot schedule on top, the gap between "fixed upstream" and "fixed on my servers" stretches into weeks or months. CSA put it well: "The window that a multi-week distribution lag leaves open is becoming more dangerous." Some FUD management, though: Anthropic hasn't published its exploit, Canonical says no other exploit is known, and nobody has reported exploitation in the wild. So, as with all things in vulnerability operations, you have to consider how 'bad' the latest headline really is in practice. Dropping inbound IPv4 packets with IP options buys you time, so do that, and then patch. Try my question again with real data: Pick your most exposed Linux hosts and write down the date each one will actually be running a fixed kernel. What would it take to move that date up?

It’s interesting that AI was reportedly used to help identify and develop an exploit for a vulnerability that had been present in the Linux kernel for approximately ten years. While AI has the potential to help defenders discover and fix vulnerabilities more quickly, we should not forget that attackers can use the same capabilities. The challenge for organisations is that the time between a vulnerability becoming known and attackers developing working exploits may continue to shrink. This reinforces the importance of understanding which systems are exposed, having effective vulnerability management processes, and being able to deploy mitigations quickly when patches are not immediately available.

This vulnerability is expected to impact Linux distributions for the foreseeable future, as automated patching remains elusive. In the interim, please adhere to the mitigation steps provided by the CSA.

Ouch! There's a special kind of frustration when a password manager, the very tool we rely on to make strong authentication EASIER, tells us we may need to change our passwords, reset two-factor authentication, and remove passkeys across our digital lives. I can almost hear Obi-Wan confronting Anakin: "You were the Chosen One!" Password managers were supposed to bring balance to our authentication chaos, not leave us in darkness! But seriously, the amount of work being suggested here could be crushing for users, especially when they don't even know what was compromised. We need much more clarity from mSecure about what happened, what information may have been exposed, which customers are affected, and which protective actions are actually necessary. A password manager depends on enormous trust from its users. Incidents like this, compounded by uncertainty and vague communications, can deal a devastating blow to that trust.

This is not the best way to notify users of an incident and the need to take action. A bit more transparency and specificity is needed. For example, are users being asked to change their authenticators for their mSecure password manager, or are they being asked to change every password/etc. contained in their password manager? Unfortunately, the safe approach is to actually change your most sensitive passwords and authentication tokens. The harder initial question is whether to continue using mSecure or to find a new password manager. Without information about the security incident, making a decision to stay the course is problematic, and you may want to consider a switch. If you decide to change, evaluate carefully and execute meticulously.

When people use a password manager, they are placing a significant amount of trust in the company providing that service. That trust becomes particularly important when the provider suffers a security incident. Asking customers to change potentially hundreds of passwords, reset multifactor authentication, and remove passkeys without clearly explaining why is likely to cause understandable concern and frustration. While organisations may not be able to disclose every detail during an ongoing investigation, they should explain what they know, what they do not yet know, and why they are recommending particular actions. Effective incident communications should help customers make informed decisions, not leave them guessing about the risks they face. Regardless of this incident, and others that have affected other password managers in the past, I still recommend people use a password manager to securely manage their passwords rather than rely on their memory or that super-duper secure password that no-one can guess.

In its after-action review, mSeven Software needs to reassess how it handled crisis communications. Its email update provided limited information about the cyber incident and didn't clearly explain why taking the recommended steps was essential.

The advice to delete passkeys suggests that the mechanism was, or at least may have been, compromised before the passkeys were created.

Residential proxies are everywhere. They have even been found in smart TVs and similar devices obtained from "reputable" manufacturers. Endpoint protection will often fail you in this case. Watch your network!

I'm going to resist the spy-in-the-West-Wing version of this story, because I think the boring version is more useful. Someone on that network, just like any network, most likely installed a free app, and the app paid its bills by quietly renting out their bandwidth. That's the business model: Developers get a little money per install for embedding a proxy SDK, the user “agrees” somewhere in a EULA no human reads, and their laptop becomes someone else's exit node. Humans take the path of least resistance, and “free” is about as low-resistance as it gets, so unless there's technical policy blocking a behavior, end users will always find a way. What bothers me is that this is a known, monetized economy, and we keep treating each discovery like a surprise. Johannes is right that endpoint protection will often miss it, because from the EDR's point of view nothing malicious happened — the software did exactly what the user “consented” to. Do you know, in real time, what's installed on your managed endpoints, not just what's running or what got flagged by a detection rule? Is anyone checking your egress IPs from the outside, the way Layer3 stumbled onto these "by chance?" And for the platform folks: App stores and OS vendors are in a better position than anyone to spot these SDKs. I'd love to see them disclosed at install, the way we prompt for camera or microphone access. If it can happen on one of the most scrutinized networks in the country, there's a good chance it's happening on yours.

This story demonstrates a broader problem that can affect any organisation. Software installed on a device can potentially turn that device into part of a proxy network, allowing third parties to route their traffic through an organisation's internet connection. This is particularly challenging in environments where personal and guest devices are allowed to connect to the network. Organisations should ensure guest networks are properly segregated, monitor for unusual outbound traffic, and understand what software is running on devices connected to their networks. Otherwise, someone else could be using your internet connection without your knowledge.

The subtle part of this is that it appears to be systems on a corporate network (The White House) running proxy services which allow their network access to be rented/used, which is great if you want to change or obscure where your traffic is coming from, but not so great as they are being used to route malicious traffic and hide criminal activity. These are likely infected devices, like a phone, set-top-box, etc. Make sure that you're able to detect this traffic so you can track it down and shut down the service if found.

Proxies of this type have made their way into almost every IoT device, making the story particularly notable because of its ties to the Executive Office of the President. Although monitoring network traffic is the best line of defense, most everyday consumers simply don't do it.

This is a supply chain issue. However, against consumer networks, not enterprise. While some consumers will take action to protect themselves and their neighbors, most will not. There is a role for government here. We should at least resolve any "varying degrees of legitimacy." California, are you listening?

Earlier this week, on Ivanti, I said patching closes the door to future attacks but doesn't tell you whether someone already walked through it. I feel like I say that a lot these days. Sometimes the door you closed isn't the one they're using. Zyxel patched a GS1900 bug in June. By September it was being exploited and was on the KEV, and if you'd already installed the June firmware, you had every reason to think you were done. You weren't. Binarly found the attackers' exploit on their own C2 server and tested it, and it still worked against every June-patched build. The attackers were using a different bug in the same code, and that fix didn't ship until October 22. For about two months, the patch, the advisory, and the KEV entry all pointed at the wrong bug. Binarly said it well: "Advisories and version numbers certainly help, but they cannot be blindly trusted." I'd also like to see Zyxel's new advisory say plainly that the June fix didn't stop the in-the-wild exploit, because right now it doesn't mention the earlier CVE at all, and customers need clarity to decide whether to go hunting (Binarly also believes the exploit was LLM-generated, which tracks with how fast these are turning around). If you run GS1900s: 1) Upgrade to the Patch 3 builds; 2) Remember that the attackers' script collected device configurations and hashed root credentials, so treat those credentials and any secrets in the config as burned and rotate them.

So, Zyxel pushed out a fix for a flaw in June, but that wasn't necessarily the flaw which was reported being exploited in the wild. The fix from October gets both of them. Make sure that you're running the latest firmware on your GS1900 Series Zyxel switches. I'm sure there were interesting conversations about this at Zyxel, but for now just focus on applying the update and make sure the management console is secure (yup, there are still management interfaces exposed to the Internet, we need to change that).

Large financial organizations usually have the resources to have robust supply chain security programs that reduce the chances of something like this, if it really was the fault of a service provider. Investigation details are needed to determine how the Crédit Mutuel Account was compromised and controls/checks not enforced.

This incident highlights how a cyberattack against a third-party service provider can have serious financial consequences for the organisations that depend upon it, and why the EU's NIS2 and DORA regulations include cyber risk management in the supply chain. Organisations should ensure that appropriate controls, monitoring, and transaction limits are in place so that a compromise of one system or supplier cannot result in unrestricted access to critical systems.

A sharp contrast between this incident and the Binance hack of last week. At this point the bank has restored services, account holders have been made whole (provided assurances that their assets are fully protected), and the criminal investigation continues. As customer accounts were not leveraged for this attack, any system improvements will likely be transparent to their customers, while simultaneously being carefully checked by regulators. I bring this up not to discourage the use of crypto, but to highlight the differences in risk we need to be aware of.

If one is looking for a target account to take over, one should prefer those of the bank to those of its customers. That said, getting a hundred million out of the banking system before it can be clawed back is a heavy lift. Banks should be using multi-party controls for large transactions and spreading funds across multiple accounts. Like consumers, they should spread their eggs across multiple baskets.

When I first saw "Norad," my mind immediately went to tracking Santa Claus and also the movie WarGames. Wrong NORAD! This is Norway's development cooperation agency, whose Grants Portal supports humanitarian and development projects around the world. And there's a potentially troubling dimension to this breach beyond the exposure of personal information. Depending on what was accessed, grant records could reveal relationships among people, organizations, and projects operating in politically sensitive or dangerous environments. In some places, merely being associated with certain humanitarian or development activities could put people at risk. We don't yet know the full scope of the compromised information, but the response needs to consider more than identity theft and password resets. Protecting the people behind these records, including those working in difficult and potentially dangerous environments, should be an important part of the investigation and response.

Norad coordinates Norway’s assistance for foreign development through grants. Their grant portal was compromised, which is rough for those who not only had their information exposed but also had their grant application disrupted. The data exposed may include information about people operating in conflict zones, which puts them at risk. I’m guessing that, with 27 accounts compromised, they hadn't implemented phishing-resistant MFA, and will be doing so post-haste. Regardless of the security shortfall, it's sad when I learn that the only way funding was made available to remediate it was due to an incident like this. On a positive note, Norad is actively working to contact both the account owners and those with exfiltrated information, as well as creating and updating a site with relevant information.

It would be interesting to know what type of user accounts were compromised in this breach. Were they accounts of those applying for grants, or were they accounts of staff who administered the system? If the former, then the concern would be what access controls were in place to prevent one user account from accessing data belonging to other accounts, and if the latter, what monitoring was in place to detect unusual access to the data. Regardless, all internet-facing accounts should nowadays employ some form of multifactor authentication, and organisations should be monitoring not just for malicious attacks but account activity outside normal behaviours.