Binance Loses $6.3 Billion in Cryptocurrency Theft; European Refrigeration Hijacked Again; GCHQ Media Devices Lost, App Falsely Indicated Terrorism Suspects

Largest crypto theft on record. Let that sink in. Even with the frozen ETH/ARB and stablecoins, the attacker still has over 2.4 billion under their control. Here's the deal: We all need to be getting smarter on crypto currency. As you read the writeup on this event, you should already understand not only all the moving parts, but also mitigations before you start putting real money into crypto. Understand the speed at which this currency moves versus traditional currency as well as the safeguards. Read the terms and conditions to understand where crypto does and doesn't have you covered. If this is still all Greek to you, many banking apps are adding Crypto services; read the EULA that goes with that service, then read it again, carefully. Don't risk any more than you can afford to lose.

While large billion-dollar heists like this make the news, there are each day many smaller crypto thefts that can be quite devastating to the victims. For example, just this week BTCpay reported that older versions of the BTCPay server are being actively targeted. Before getting serious about crypto, learn how to protect your assets.

Outside of large volumes of international payments, there is very little business reason to be using digital "currencies" — if the real risks or insurance cost were considered, very few legal use cases show any ROI. If your organization is determined to do so, there are a few that are certified as "stable" by government agencies in the US, EU and some Asian countries. But heed the International Monetary Fund guidance from December 2025: "Turning stablecoins into a force for good in the global financial system will require concerted actions by policymakers, at both the domestic and international levels."

This incident will be one to watch for when Binance hopefully releases a full report on how the attack happened. Crypto exchange heists are nothing new, with the ByBit cold wallet heist occurring just 20 months ago, which was also attributed to North Korea. While the ByBit heist was a very sophisticated third party compromise that had to be perfectly timed, I'm hoping this wasn't just another engineer getting hit with an infostealer on their laptop. No crypto exchange compromise of this magnitude should be possible through the compromise of a single laptop. Major crypto exchanges like Binance know better.

Reporting confirms a meticulously planned and state-executed cyber operation. It proves two key facts: North Korea remains a top-tier threat in financial cyber warfare, and attackers will always exploit an organization through its weakest point.

I am very interested in adding fingerprints of attacked devices to our honeypot. Please contact me if you have access to an affected fridge and are interested in collecting some data I could use.

When I first commented on the French refrigeration attacks, I questioned whether they were related to the unexplained freezer failures at US military commissaries. The Pentagon is now investigating those incidents as suspected cyberattacks, although a connection to the European attacks has not been established. What concerns me more is that a second wave of attacks has spread across multiple countries and retailers just weeks after the original incidents became public. We are seeing how common weaknesses in widely deployed industrial equipment can create systemic risk across otherwise independent organizations. I would like to know why the initial attacks and subsequent warnings were not sufficient to prevent another round of physical damage.

A lot of times, people assume that the 'crown jewels' of their business are whatever is the most regulated, or the thing that might generate the most expensive fine if it were compromised. In reality, crown jewels are the things that, if damaged or compromised, could grind operations to a halt. If a grocery store's loyalty card database is compromised, that's a bad day for customer trust, privacy, and your brand, but it doesn't stop you from selling meat and produce. If your refrigeration systems go offline, that takes out entire product lines and causes significant losses. As you prioritize your own crown jewels, how are you defining them? Two things worry me more than the food. First, this is the second wave in about three weeks, and the installer for several affected sites says a software update isn't enough and the units also need physical modification, which is especially tough when the stores or maintenance contractors might not have enough technical staff to go around. Second, if your HVAC, access control, or 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. If you're in retail, food, healthcare, or anywhere else the cold chain matters: 1) Scan your own external address space for building management and refrigeration controller interfaces, 2) Ask your facilities contractors, in writing, how they connect remotely and who holds those credentials, and 3) Get end-of-life controllers off the internet now, even if that means a technician on site, because no patch is coming for them.

Regrettably the common denominator is exposed OT devices. I suspect the average supermarket is not thinking about these when it's considering security, focusing more on payment processing and physical access. We all thought we had a bit of time before a repeat of the prior attack occurred. Changing operational processes to use private connections to these systems as well as securing the controlling system will take some time, time which we don't appear to have. This may be one of those cases where you close the hole, reverting to more local/manual processes, then implement the secure solution. Don't assume these attacks will only happen in Europe, or only to refrigeration systems; those are what's of interest today. Make sure that you have updated information on how your OT systems are accessed as well as information on the protections for the systems which access/control them. Don't forget to ask about access by maintenance and support services/contractors.

Penetration tests weren't enough for organizations to pull critical infrastructure off the Internet. Shodan made all these systems easily searchable nearly two decades ago. Private and government organizations have reached out individually to notify companies of their levels of exposure. Perhaps these systems simply need to get hacked before we'll see broad change. Perhaps governments will regulate refrigeration units and classify them as critical infrastructure (if they aren't already). It is unfortunate that actual damages often need to occur before we see security controls and technical debt more seriously considered.

The industry's failure to heed mid-October's warning underscores a persistent disconnect: Threat intelligence has little value if organizations don't apply it to their risk management practices. Even simple measures, such as applying compensating security controls to EOL systems, could have blunted the attack. It's a frustrating reminder that in cybersecurity, old lessons often have to be re-learned.

There's a sobering human story buried in this oversight report. GCHQ's analysis of technical information associated with an unusually behaving software application led to intelligence that incorrectly identified innocent people as potential terrorism suspects. Five police stops resulted, including detention, examination of electronic devices, and collection of biometric information. The oversight investigation concluded that the problem wasn't reasonably foreseeable by GCHQ, but acknowledged the serious harm experienced by those individuals. This is an important reminder that technical conclusions must be carefully validated before they're used to justify consequential actions against people. An incorrect security assessment can be much more than a false positive on a dashboard. It can profoundly affect someone's life and dignity.

This one frightens me, and I echo a lot of Ed's concerns here. Five port stops detained multiple people under counter-terrorism powers, had their devices downloaded, and had their biometrics taken, because a target discovery method was unreliable in a way nobody caught until the intelligence had already gone to police. Then the oversight body concluded it wasn't a "relevant error" under the Investigatory Powers Act, because the interception was lawfully authorized and the flaw wasn't foreseeable. And because it isn't an error, the report says, "there is no mechanism to inform an affected person in these circumstances." IPCO itself asked whether that engages Article 13 of the European Convention on Human Rights, the right to an effective remedy, and decided that "intelligence can sometimes simply be wrong." *Sit with that for a moment*. If you're one of those people, you may never learn why you were stopped, what is still held about you, or whether it will happen again the next time you travel. GCHQ deserves credit for finding and reporting the flaw, and I don't doubt the good faith here. But good faith isn't a remedy, and these kinds of things could happen without good faith. Anyone who has worked in threat intelligence knows the distance and level of confidence between "this is associated with activity" and "this person did it," and every hop from an identifier to a human life should carry its confidence and caveats with it. As more of this analysis gets automated, the number of conclusions about people goes up and the time spent checking each one goes down. I don't have easy answers or advice on this one.

Monitoring a fleet of thumb-drives, let alone CD/DVD media is quite the task. Particularly if you consider the cost, making it trivial to just purchase a replacement if something happens. But if you consider that it could contain proprietary information, that sort of kills the argument about replacement being trivial. This is a place where you could leverage DLP to raise exceptions to IP and other sensitive data being stored on these, regardless of ownership, reducing the likelihood of unknown media containing that data and also triggering tracking for those which do.

If you're using an Android set-top-box, make sure that you're using a Google certified device. It's better to replace a questionable device than to attempt to clean it. If your device was supplied by your service provider, check with them on any needed updates or replacements. While you're at it, consider your smart TV or monitor. If you're not using the streaming components, why connect them to the Internet? If they must be connected, see if they'll work on a network with device isolation to limit their access to other devices they have no need to interact with.

Buying certified devices is usually a good baseline, but doesn't seem to have been enough here. The manufacturer, Videostrong, built the backdoor into its own firmware and used obfuscation to load malicious code after the first boot, slipping past Google's OEM tests (according to Google). That's a supply chain where the supplier was the attacker. And this isn't only a living-room problem: Google also found it on telehealth devices and digital signage. How many of you have a no-name Android box running a lobby screen on the corporate network because it was easier? Inventory your Android-based appliances that can't run traditional security tooling (which may start with some good, old-fashioned NMAP scanning of your networks to even find them), put them on an isolated segment with tight egress, and watch for proxy-style outbound traffic.

We've seen reports of devices sold with malware pre-loaded before, but I always assumed this was a done by a dodgy supplier or through supply chain compromise, like the recent incident with Ledger's crypto cold wallet devices. Malware-enabled devices as part of the manufacturer's business plan is a first, however. It is the sort of bold plan that only a manufacturer in China (or someone partnered with a manufacturer in China) could successfully pull off at scale. There were concerns that TP-Link could have been doing something similar for the Chinese government, as they successfully cornered the market for cheap, consumer Wi-Fi access points, but we haven't seen any evidence of foul play yet.

A prime example of hiding in plain sight for years. Videostrong Technology seemingly realized that criminal operations carry much higher profit margins than conventional hardware manufacturing. As our ecosystem grows increasingly connected, more vendors may debate following this lucrative path.

Check your versions of Ivanti Connect Secure. While version 22.7 is not impacted, it’s EOL on January 31, 2027, so you still need to get to version 25.1.1.3. Good news is that if you're on 25.1.3.0, you're not impacted; bad news is that 25.1.3.0 needs newer hardware or updated virtual machines based on this version. Not seeing any workarounds, so knuckle down and get the fixes deployed, then make sure that you're monitoring for IoCs.

Lee's right to knuckle down and patch, but don't stop at the update. Patching closes the door to future attacks but doesn't tell you whether someone already walked through it. Here, Volexity found the actor deployed no malware or web shell, re-exploited the device for each command, and tampered with logs, which allowed it to evade Ivanti's Integrity Checker Tool. A clean integrity check is not an all-clear, and this type of hardware sits on your remote-access edge, where your users' credentials pass through. The guidance is actionable: hunt with Volexity's indicators using network-side telemetry, since the appliance's own logs may not be trustworthy. If you can't rule out compromise, follow Ivanti's recovery steps and treat every credential that touched it as burned, which is painful, but better safe than sorry.

Instead of updating Ivanti Connect Secure, consider removing it. I highly recommend correlating your asset inventory with CISA KEV. Any vendors or products that consistently get their customers hacked should be flagged for replacement as soon as possible. Vendor risk management should be more than just a process that occurs at the time a product is purchased and implemented — it should continue to monitor the reputation of a product or a vendor throughout its lifecycle. Ivanti is just one of many vendors still selling products that continue to put customers at risk, year after year.

It feels like KEV entries have exploded this year compared to the last two, and AI-driven automation is almost certainly fueling the fire. At what point does the KEV catalog become a relic of a slower era, and when do organizations just accept that full patch automation is the only viable path forward? Curious to hear your take.

Don’t get distracted by CUI/PII/etc. This appears to be a case of DLP detection of sensitive data and subsequent permission management. It doesn't matter if you're using a local file server, Google Drive, OneDrive or something else — you need to be diligent about the permissions on data, particularly sensitive data. Users need to clearly understand what data may be stored in which locations as well as their obligations to properly secure it. It simplifies things if all central storage is authorized to store your most sensitive data, but it still needs appropriate access controls to ensure need-to-know. DLP can help you, but your users are still the primary defense. Verify your DLP capabilities as well as your user training. Make sure there are resources to help make informed decisions about exactly how a given set of data needs to be stored, shared or otherwise handled.

There's a particularly revealing lesson in the details of this audit. GSA had data loss prevention technology, but its controls missed sensitive documents because of shortcomings in configuration, monitoring, and oversight. The inspector general even found that available OCR capabilities weren't being used, and that a 15-megabyte file-size limitation created additional blind spots. For security teams, having DLP deployed is only the beginning. Test it against realistic examples of the data you're trying to protect, including scanned documents and large files. Review broad sharing permissions, validate detection rules, and periodically verify that the controls work as intended. A security tool is valuable only to the extent that it actually provides the protection we're depending on.

Almost all PC and phone operating systems try to nudge (OK, trick) users into enabling automatic cloud backup. IT procedures should be in place to avoid one way this happens, and logs should be monitored for data flow to those services.

So you have an application with a database — a database which is neither password-protected nor encrypted, while being publicly accessible. These are issues you need to understand prior to production deployment. Doubly so if you're storing sensitive data, but realistically, if you do it for everything, you're not going to have things fall through the cracks. Make sure the barn door isn't wide open: Verify that all your databases are not publicly accessible and have strong, non-default, credentials. Then loop back on how sensitive data is protected. Fix issues as rapidly as possible, as adversaries are going to be looking for this trifecta.

Make sure security is involved in all third-party decisions where sensitive data is involved. Security teams need to be prepared with RFP evaluation questions/criteria and timely response. No passwords and no encryption should have been very visible red flags.