Daily Cyber Briefing
The Daily Cyber Briefing delivers concise, no-fluff updates on the latest cybersecurity threats, breaches, and regulatory changes. Each episode equips listeners with actionable insights to stay ahead of emerging risks in today’s fast-moving digital landscape.
Daily Cyber Briefing
Supply Chains, Power Grids, and AI Gone Wild
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Today we dive into a wave of supply chain attacks hitting everything from Notepad++ to antivirus software, nation-state hackers targeting power grids, and why 175,000 exposed AI servers might be the next big headache for security teams. Plus, the White House just threw out software security rules—what could possibly go wrong?
**MIKE HOUSCH:** Hey everybody, welcome back to Cyber Scoops & Digital Shenanigans! I'm your host, Mike Housch, and wow, do we have a packed show for you today. It's February 2nd, 2026, and the cyber world has apparently decided to kick off the new year by setting everything on fire. Grab your coffee, maybe something stronger, and let's dive in.
**MIKE:** Alright, let's start with what I think is the most concerning story of the week—energy infrastructure cyberattacks. And folks, we're barely a month into 2026, and electrical power infrastructure on two continents has already been hit.
First up, Poland. The Polish power grid faced a coordinated attack that security firm Dragos is attributing to a group they call Electrum—though most of us know them as Sandworm. Yes, THAT Sandworm. The GRU-affiliated group that's been Russia's go-to cyber weapon for over a decade.
Now, here's what makes this attack particularly significant. Dragos described it as a world-first for targeting distributed energy resources—or DERs. These are smaller sites connected to a country's central power grid. Think solar installations, wind farms, smaller generation facilities. The attackers used wiper malware called DynoWiper, which is consistent with Sandworm's previous attacks on critical infrastructure.
But here's the quote that should keep every energy sector CISO up at night: "The Poland attack is significant because of the coordinated nature of the attacks across numerous sites simultaneously and the demonstrated intent of a sophisticated adversary to systematically target this infrastructure."
And in some cases? The effects of the attacks damaged equipment beyond repair. We're talking physical destruction from cyber means, folks. Attackers took over remote terminal units and communication infrastructure at multiple sites.
**MIKE:** Now, this is where I put on my "concerned citizen" hat. The Register made an excellent point that I want to echo: cyber infrastructure attacks are now a part of military force and should be treated accordingly.
But here's the really scary part—the democratization of attack technologies has moved infrastructure attacks from nation-state specialization to something where a 30-minute YouTube video can give you a working example. Between Shodan, Google, Wikipedia, and MITRE ATT&CK, we've essentially created a complete curriculum for anyone wanting to go up against large organizations. It's wild.
And while we're on energy, there's another story where a threat actor claims to have breached Pickett and Associates, a Florida engineering firm, and is selling about 139 gigabytes of engineering data about Tampa Electric, Duke Energy Florida, and American Electric Power. Price tag? Six and a half bitcoin—roughly $585,000. Critical infrastructure data, just... for sale. On the internet.
**MIKE:** Alright, let's shift gears to everyone's favorite topic lately—supply chain attacks. And boy, do we have some doozies this week.
First up: Notepad++. Yes, the beloved text editor that basically every developer and IT professional has installed. Chinese state-sponsored attackers managed to hijack the Notepad++ update mechanism by compromising the software project's shared hosting server.
Let me walk you through how this went down. Starting in June 2025, attackers compromised the hosting provider—not Notepad++ itself, but the hosting provider—and were able to intercept and redirect update traffic. The compromise lasted until September at the hosting level, but even after losing that access, they retained credentials for internal services until December 2nd.
What did they do with this access? They selectively redirected traffic from targeted users to attacker-controlled servers that served malicious update manifests. And according to security researcher Kevin Beaumont, the victims were primarily telecom and financial services organizations in East Asia.
Multiple independent researchers have assessed this as likely a Chinese state-sponsored operation, which would explain why this was selective targeting rather than mass exploitation. They weren't trying to hit everyone—they wanted specific targets.
The good news? Notepad++ has moved to a new hosting provider and hardened their update process. The updater now verifies both the certificate and signature of downloaded installers, and they've implemented signed XML for the update server.
**MIKE:** But wait, there's more supply chain fun! eScan antivirus—yes, your antivirus, the thing that's supposed to protect you—was compromised to push malware.
On January 20th, attackers breached one of eScan's regional update servers and injected malicious code into the update distribution path. For about two hours, customers downloading updates from that server cluster received malware instead of security patches. Let that sink in—your security software, pushing malware.
The trojanized component was signed, triggered a downloader connecting to attacker C2 infrastructure, tampered with hosts files and registry to block future legitimate updates, and set up persistence mechanisms. Really nasty stuff.
Now, eScan is disputing some of the claims made by Morphisec, the security firm that disclosed this. They say the incident was limited to a small number of systems in a specific region. But here's the kicker—this isn't even the first time eScan has had this problem. Back in 2024, North Korea's Kimsuky group abused the same update mechanism to drop malware inside large corporations. Fool me once...
**MIKE:** Let's talk about MongoDB. Over 1,400 MongoDB databases have been ransacked by a threat actor running automated data extortion attacks. And folks, this is the low-hanging fruit we always talk about—databases that are insecure due to misconfiguration allowing access without any restrictions.
The attacker demands about $500 in Bitcoin to restore your data. But here's the fun part—according to a Flare report, there's no guarantee the attackers even have your data, or that they'll provide a working decryption key if you pay.
Researchers found only five distinct wallet addresses across all the ransom notes, with one appearing in 98% of cases. This is likely a single threat actor just running automated scripts against exposed databases.
And how many are exposed? Over 208,500 publicly exposed MongoDB servers. Of those, 100,000 expose operational information, and 3,100 could be accessed without any authentication at all.
Folks, this is basic security hygiene. If your database is publicly accessible without authentication, it's not a matter of if you'll get hit—it's when. And apparently, that "when" is right now.
**MIKE:** Now let's talk about something near and dear to my AI-skeptical heart—exposed Ollama servers. For those who don't know, Ollama is a popular framework for running large language models locally. And researchers from SentinelLABS and Censys found 175,108 unique Ollama hosts in 130 countries exposed to the public internet.
The vast majority are running Llama, Qwen2, and Gemma2 models, mostly relying on the same compression choices and packaging. This isn't diversity—this is a monoculture ripe for exploitation.
GreyNoise set up honeypots and captured over 91,000 attack sessions between October 2025 and January 2026. They identified two distinct campaigns systematically mapping the expanding attack surface of AI deployments.
Here's a quote that should concern everyone: "Threat actors don't map infrastructure at this scale without plans to use that map. If you're running exposed LLM endpoints, you're likely already on someone's list."
The risks here are real. Unauthorized users could query models, consume computational resources, rack up cloud bills, or launch model extraction attacks. And remember, LLMs can be manipulated to generate restricted content—misinformation, malware code, harmful outputs.
Where are these exposed servers? 36.6% in the United States, 22.5% in China, and 8.9% in Germany. So yeah, if you've spun up an Ollama instance for testing and forgot about it... maybe go check on that.
**MIKE:** Speaking of AI and cloud, let's talk about why native cloud security might be giving you a false sense of... well, security.
The Register ran a piece this week that I think every CISO needs to read. As cloud adoption accelerates, many organizations are increasingly relying on native security features from their cloud providers. Managing WAF, encryption, and key management within a single ecosystem seems efficient and convenient. But when you look at it through enterprise risk management lens? This convenience comes at significant cost.
The main issues are vendor lock-in and single point of failure risk. When one breakdown can compromise your entire system, you've got a problem.
One major limitation is lack of control. Customers often have minimal influence over timing, scope, or rollback of updates. When patches are automatically pushed across all services, the update itself becomes a risk. This isn't just a technical problem—it's a supply chain risk. The more centralized your security provider, the wider the impact radius of any failure.
And multi-cloud? Many companies want to go that route, but security remains a major obstacle. CSP-native WAF and encryption features are tightly coupled to each provider's APIs and policies. Migrating means redesigning security frameworks from scratch.
The recommendation? While cloud infrastructure thrives on integration, core security controls should remain independent. Relying solely on cloud-native security is described as a "dangerous misconception."
**MIKE:** Alright, here's a big one for all you Windows administrators out there. Microsoft is finally—FINALLY—moving to disable NTLM by default.
For the uninitiated, NTLM is a 30-year-old authentication protocol introduced in 1993 with Windows NT 3.1. It's susceptible to replay attacks, man-in-the-middle attacks, and uses weak cryptography. We've been telling people to move away from it for years.
Microsoft has laid out a three-phase transition plan. Phase one—available now in Windows 11 24H2 and Windows Server 2025—gives admins enhanced auditing tools to identify where NTLM is still in use.
Phase two, scheduled for the second half of 2026, will introduce new features like IAKerb and a Local Key Distribution Center to address scenarios that trigger NTLM fallback.
Phase three will disable network NTLM by default in future releases. The protocol will still be there—you can re-enable it through policy if needed—but it won't be on automatically.
Microsoft's quote on this is telling: "Reducing the use of NTLM will ultimately culminate in it being disabled in Windows 11. We are taking a data-driven approach and monitoring reductions in NTLM usage to determine when it will be safe to disable."
This is long overdue. If you're still relying on NTLM, start planning your migration now. The writing has been on the wall for years, and the deadline is getting real.
**MIKE:** And now for something that has the security community... let's say "concerned." The White House has scrapped what they're calling "burdensome" software security rules.
On January 23rd, the Office of Management and Budget formally rescinded two Biden-era memoranda—M-22-18 and M-23-16—that required federal agencies to obtain software security attestations from vendors before deploying their products.
OMB Director Russell Vought said these policies imposed, quote, "unproven and burdensome software accounting processes that prioritized compliance over genuine security investments."
Now look, I understand the compliance burden argument. I really do. But these memorandums were designed to enforce stricter security controls and standards to reduce vulnerabilities like remote code execution. They were a response to incidents like SolarWinds.
The good news, if you can call it that, is that agencies can still use these tools—they're just no longer required to. And agencies still need to maintain software and hardware inventories and develop assurance policies. The SBOM requirements for cloud providers remain for those who want them.
But making security practices optional instead of mandatory? In an era where we just discussed supply chain attacks on Notepad++, antivirus software, and critical infrastructure? I'll let you draw your own conclusions.
**MIKE:** Alright folks, let's wrap this up with the big picture.
This week painted a pretty clear picture of where we are in cybersecurity right now. Supply chain attacks are the new normal—whether it's through your text editor, your antivirus, or your hosting provider. Nation-states are actively targeting critical infrastructure, and the tools to do so are becoming more accessible.
AI deployments are creating new attack surfaces faster than we can secure them. Legacy protocols like NTLM are finally being put out to pasture—but only after three decades of vulnerabilities. And the regulatory environment? Well, that's... evolving.
For CISOs, the message is clear: defense in depth isn't just a buzzword, it's survival. Don't rely on any single security control, any single vendor, or any single assumption about what's safe.
Verify your supply chains. Audit your exposed services—especially those AI experiments you spun up and forgot about. Start planning your NTLM migration if you haven't already. And keep pushing for security to be a requirement, not an option.
**MIKE:** That's all for today's episode of Cyber Scoops & Digital Shenanigans. If you found this helpful, share it with your colleagues, your security team, or that one developer who keeps exposing MongoDB instances to the internet—you know who I'm talking about.
I'm Mike Housch. Stay vigilant, stay patched, and for the love of all that is holy, put authentication on your databases.