Microsoft Patches 1,400+ Flaws, Debuts Risk Cohorts System; Cisco Secure Email Gateway Vulnerability Exploited; Ivanti Patches Exploited Connect Secure Flaw

1,400+ vulnerabilities, 76 of which are rated critical, 7 of which require no user interaction to exploit. Not such a nice way to start your day, particularly if you're bound by the KEV and need to apply the updates by October 16. At this point we've talked about grouping systems for updates according to risk — if you're still wanting to analyze CVEs but see 1,400 as a lot to analyze, the Microsoft Blog gives you an option to consider where you group updates into risk cohorts, breaking down the problem and cross cutting it according to your environment. Even so, don't get caught up in analysis paralysis: You need to have significant places where updates are applied autonomously. These numbers aren't getting smaller, and it really feels good when you check systems for updates after a bulletin like this and see they're all applied.

I've said a few times this year that "patch them all" isn't a realistic plan for the scale of vulnerabilities discovered and disclosed today. That said, I still read these mega releases as mostly good news: vendors are clearing decades of technical debt with AI-assisted testing before attackers find the same bugs. While no one really wants another standard or measurement, Microsoft's Risk Cohorts system is smart. Cohort-based vulnerability management is probably a trend we'll see emerge as best practice over the next few years. Grouping CVEs by deployment, exposure, and trust boundaries is the exposure-based prioritization vuln management teams need. I think hearing it from the vendors themselves will also help reinforce to leadership that it's not a capability problem, but a prioritization/noise/volume problem that even the vendors recognize isn't manageable with the “old ways.”

This seems like a crazy number of patches, but consider how many of them are in the news for causing chaos and destruction: none of them. One is described as a zero-day, but is nothing to get excited about. AI is good at finding vulnerabilities, but isn't great at finding ones that really matter, and AI discovery has clearly been unleashed at the world's largest software producers. I'd argue that most of these 1,400 patches are simply software bugs, not worthy of calling 'vulnerabilities,' as they're not making anyone more vulnerable. Risk Cohorts make a lot of sense. One of the sins of vulnerability management tooling is not speaking in the language of the asset owner. Instead of "install this list of CVEs on these IP addresses," we should translate this into, "Microsoft Office is out-of-date and needs to be updated on all laptops."

Adrian makes a really good point about the need to speak the language of asset owners rather than simply throwing CVE numbers at them. With more than 1,400 vulnerabilities in one Patch Tuesday, the raw numbers can become overwhelming. I'm intrigued by Microsoft's proposed risk cohorts because they encourage us to ask meaningful questions about exposure, deployment, and trust boundaries, and then apply those answers across groups of vulnerabilities. This approach has great promise as part of emerging VulnOps practices within organizations, helping teams move from vulnerability enumeration toward more intelligent, business-aware prioritization and remediation. But we need to be careful here. Even if many of these flaws turn out to be difficult to exploit in practice, we shouldn't assume they're unimportant merely because they haven't made headlines. An obscure vulnerability can become extremely important when it affects the wrong system in the wrong place. Group the analysis where it makes sense, but keep the dangerous exceptions front and center. That's a core tenet of VulnOps: the goal isn't to win at counting vulnerabilities. It's to make the right systems safer, faster.

It’s been a bumper month for Microsoft vulnerability remediation, and AI-accelerated testing means this high volume will likely persist into the new year. To prevent attackers from reverse-engineering patches and weaponizing flaws, organizations must prioritize automated patching. Treat Risk Cohorts as optional if they fit your workflow, but make patch automation your primary defense.

I have always contended that the number of patches is an inverse measure of quality, that patching passes the cost of quality from the supplier to their customers, and that it is an inefficient way to achieve essential quality. The recent application of AI to vulnerability discovery by both rogue hackers and suppliers suggests that the quality was even worse than we suspected. Remediating that quality is all but overwhelming both the suppliers and their customers. Going forward it is to be hoped that the use of AI for discovering and eliminating vulnerabilities in the legacy code base and avoiding them in new code should improve quality. That should manifest itself in a reduction in the rate of patches.

I heard that, no, you're not going to be able to just block all attachments, nor ignore them, allowing everything through. Given the criticality of email security, even coupled with your EDR, you want to jump on this. The flaw can be exploited remotely without authentication. There are no workarounds; you gotta patch, and only after you've updated and double checked that the security configuration follows the latest guidance can you take a pause to grumble about untrusted input validation.

I recently learned from a cyber insurance provider that security gateways are associated with higher insurance claims. Not only do these have significant attack surface, but buyers rarely enable enforcement. Nobody wants to explain to executives why critical emails were quarantined or blocked — it's not worth the intra-company political risks.

Oof. An email security gateway is supposed to inspect potentially dangerous attachments before they reach users. Here, processing a malicious attachment could give an unauthenticated attacker root privileges on the gateway itself. That's a particularly ugly trust-boundary failure. And consider what an attacker might do with that level of control. Beyond compromising the appliance, they could potentially manipulate, inject, or suppress messages flowing through it. A broad campaign poisoning organizational email would be bad enough. But imagine an attacker using that compromised gateway to inject carefully crafted messages targeting executives or other high-value individuals. Those messages would arrive through infrastructure the organization already trusts. That's a potentially devastating stepping stone for further attacks. These systems need rigorous patching, restricted administrative access, and monitoring from outside the appliance. Cisco specifically warns that attackers with root privileges could remove evidence of their activity. If the guard at the gate becomes the attacker, who’s watching the gate?

While mitigation deadlines are not binding on private enterprises, they should be used in prioritizing mitigation.

There’s a particularly nasty detail in Volexity’s excellent investigation: The compromised VPN appliance was fully patched at the time of the attack. The exploit chain included a mismatch between the URL used to make an access-control decision and a different path in a request header used to route the request to protected functionality. Sound familiar? We've been discussing these kinds of trust-boundary and input-interpretation problems in recent NewsBites issues. The attackers then chained additional vulnerabilities to gain root privileges, went hunting for Active Directory credentials and other sensitive information, and attempted to erase their tracks. Patch immediately, absolutely. But don't stop there. Hunt for evidence of compromise beyond the VPN appliance itself, examine external logs and forensic artifacts, and evaluate which credentials may need to be rotated. Kudos to Volexity for some outstanding forensic work.

So we have: Privilege Escalation, Remote Code Execution, Authentication Bypass, and AD/LDAP data exfiltration, coupled with a payload which cleans up traces of their activity; read the Volexity blog for details. This is where you want off-device logs for analysis. You need to apply the updates from Ivanti (if you're not on 25.1.12+ get there), verify you've implemented the current security guidance, and quadruple check no management interface is externally reachable, while hunting for the IoCs. The fix addresses the authentication bypass and remote code execution aspects of the flaw, so keep an eye out for another update which addresses privilege escalation.

Ivanti says it identified "a portion of this vulnerability" and fixed it in July's 25.1.3.0 update, then was still backporting the fix to other branches when attackers started exploiting it. When a vendor knows a flaw exists and a backport is in progress, customers on those branches should be told so they can decide whether to upgrade, add mitigations, or start hunting. The timeline here bothers me. While I know nothing is perfect, we're operating in a threat landscape where people need more data, faster, to make decisions on risk and delays in that rollout increase risk. Balanced transparency will be an important part of the vuln management way of the future.

Vulnerabilities in VPNs and firewalls are particularly risky. Timely patching is important. However, this is a highly competitive market; there are lots of VPNs and firewalls. Consider switching to products and brands with a stronger record.

Earlier this week I said exposure is rarely a decision someone approved, and the follow-up reporting backs that up. These weren't zero-days, they were old flaws and (some) end of life software. When end-of-life (EOL), unpatchable software is left internet-exposed, and no one owns the decision to retire it or wall it off, you end up with a sitting duck. I appreciate CERT-FR's pointer that source-IP filtering "should not be considered as a long-term solution," because that kind of 'quick fix' stopgap quietly becomes permanent. I always like to leave you with something actionable, so if you run facilities equipment: Find out which controllers are past end-of-life and who is accountable for them, get them off the internet and behind a VPN or protected network, and put a replacement date in the budget instead of (or at least alongside) a firewall exception.

Two things: We moved from monitoring — assuring the devices, freezers and refrigeration in this case — to controlling their behavior without modification of the access process, as well as introducing control devices needing updates, and lifecycle replacements. Call it what you would, IoT, ICS, or OT, they are all over our enterprise, large or small, and the issue is the same: you need defense in depth, coupled with lifecycle management. In other words, culture change. Be kind working with owners of these devices, they are likely working flawlessly, regardless of security, and at this point if they caught wind of this story they are wondering if they are vulnerable.

The phrase "wakeup call" is overused, but appropriate in this case, I think. This is just one example of the damage attackers could do when chaos is the only goal. We're honestly lucky there aren't more chaotic actors out there — we've been shouting about unprotected critical infrastructure exposed to the Internet for decades, even before Shodan made it painfully obvious in 2009. This constitutes a serious disruption in the food supply chain; consider smaller towns that rely on a single grocer, for example. Or the concentration risk of all the major grocery stores using the same brand equipment or supplier. The wakeup call here is for governments to realize that some agency should be getting ahead of these issues and working with operators and business owners to secure these systems before some group of teenagers or AI agents decides to spoil more food.

The latest findings introduce an interesting twist to the story. The attackers reportedly compromised refrigeration controllers from multiple vendors, many of which were running outdated firmware or were no longer supported. This raises a larger concern about the growing population of industrial equipment that remains mechanically functional long after its software becomes obsolete. We need to think about cybersecurity throughout the operational life of these systems, including what happens when the manufacturer stops providing software updates.

This cybersecurity incident is rapidly becoming a case study in three major security pitfalls: using end-of-life hardware and software, lacking an operational technology (OT) patch management process, and failing to eliminate unnecessary internet-facing devices. Regardless of whether food distribution (i.e., supermarkets) officially qualifies as critical infrastructure, it remains a critical business risk that must be actively assessed and mitigated.

There will be a lot of essential but relatively inexpensive measures taken by the victims in the wake of this attack. Many of these were suggested by my colleagues in Tuesday's Newbites. Similar measures should be taken by others in anticipation of similar attacks and mitigation of risk.

The analysis from Citizen Labs largely hinges on actions for advertisers and legal/regulatory improvements to stop the behavior. For the rest of us, it's not just a case of not clicking or engaging with ads; the primary mitigation is ad blockers and opting out of targeted advertising IDs. Time to consider making these mitigations mandatory on sensitive and targeted users. Double down on lockdown mode when traveling in risky areas, remove unneeded/unsupported apps (we all have them; when's the last time you cleaned house?), and consider loaner devices issued for travel, like smart phones, tablets and laptops, which are wiped and reimaged between trips.

This is just yet another reason why ad blockers have become best practices in endpoint management. Not only are ads effectively untrusted code from an unknown source separate from the host website or application, but they've never done a good job policing the content of the ad nor the KYC of the companies bidding on ads. Finally, adtech has become the ultimate targeting tool, which was a key benefit to the attackers in this case, who were targeting journalists at Al Jazeera.

Yikes. Advertisers have spent decades optimizing the online advertising ecosystem to deliver precisely the optimal content to precisely the right person at precisely the right moment, all to influence what we buy. Now attackers can turn that same machinery toward delivering spyware to precisely the right victim, without so much as a click. That's downright ominous. The technical sophistication that makes personalized advertising so profitable also makes it an extraordinarily powerful targeting mechanism for mercenary surveillance. Ad blockers can help protect individuals, but this problem cannot be solved solely by the people receiving the ads. Ad networks and exchanges that profit from this infrastructure need to exercise real due diligence in vetting their customers, scrutinizing executable content, detecting abuse, and blocking attacks from propagating through their infrastructure. And when they fail to exercise reasonable care, meaningful legal liability should reach those operating the networks, not merely the spyware vendors themselves. Reform of the digital advertising ecosystem is long overdue. Kudos to Citizen Lab for uncovering this frightening activity. The system designed to personalize our advertisements should never become the system that personalizes our compromises.

Citizen Lab deserves credit for highlighting this overlooked malware delivery threat. Because regulators and legislators have yet to focus on the issue, ad blocking technology remains the only effective line of defense.

Vulnerabilities in browsers expose more organizations and applications than purpose-built single-application clients.

I love this one. It's the same automation scammers use against victims, pointed back at them. Wasting their time is fun, but the intelligence is the real value: Bank accounts, crypto wallets, phone numbers, and impersonated brands pulled from live scam conversations can provide valuable intelligence for banks and telecom providers to shut down criminal infrastructure faster. I would love to see more research on how often this kind of intel turns into disruption of the criminal activity, and how we can make it faster.

In other words, an AI powered honeypot (or tar pit if you prefer). You know how you call the help desk and you get their AI and it gives you the long answer to your simple question? Imagine if the scammers had to deal with that, at scale; it would definitely reduce their throughput. Now gather the interaction data centrally and develop a profile of scammers you could forward to law enforcement. Kind of cool, isn't it? Apate has $10 million in startup funding to do this, I'm keeping an eye on this, at a minimum there are going to be some fun stories as a result.

Ha! I absolutely love this idea. Scambaiters like Kitboga have been tying fraudsters in knots for years, while projects like the Jolly Roger Telephone Company and O2's AI granny Daisy have demonstrated the joy of keeping crooks occupied with conversations that go absolutely nowhere. Now imagine scaling this approach across phone calls, email, texts, social media, and beyond. Every promising victim turns out to be another defender-controlled AI agent. Every tantalizing lead draws the attacker deeper into a web of deception. Meanwhile, defenders collect attacker phone numbers, cryptocurrency wallets, malicious domains, and other intelligence useful for disrupting criminal operations and enhancing detection across our ecosystems. I would LOVE to see attackers and their automation wandering through a vast hall of mirrors, never quite sure what's real and what’s another deception. Of course, we'd need appropriate safeguards and coordination to avoid unintended consequences. But turning the economics of automation against the fraudsters themselves? Now THAT sounds like a party I'd like to attend!

We are quickly moving toward an era of automated attacks countered by automated defenses, with humans serving primarily as reviewers. Attackers have automated their tactics for a while, and defenders are finally taking the same approach. Until these systems are fully in place, the general rule applies: if you receive an unsolicited email, call, or text, simply don't respond.

These fake websites are pretty clever, looking legitimate without a lot of hints except that they offer unexpected pricing on hard to find items, and fail on a reputation/integrity check. Yeah, if it looks too good to be true, it is. They are collecting identity and credit card information; if you find someone who fell for it, make sure they replace any credit card/payment forms used asap.

Criminals are specializing, cooperating, and organizing. This is increasing their efficiency and the risk to the rest of us. Organized crime requires organized law enforcement.

The fake remote worker scams continue, and law enforcement is working to shut them down. Complicit citizens who operate laptop farms or provide their identities are also finding themselves on the wrong side of the law. Still, you need to use diligence vetting workers, particularly those you never meet in person. Even then, validate their identity and background, and make sure the live body you do meet is the person hired. It's getting pretty easy to fake out the on-camera identity, so the old trick of meetings with cameras on is less effective, therefore (a number of you will not like this) seriously consider requiring meeting all remote workers in person at regular intervals.

Outstanding work by the men and women in blue. Organizations are clearly improving at detecting these scams and reporting them to authorities. As reports accumulate, patterns emerge that enable large-scale takedowns like the recent operation in Texas. Unfortunately, the lure of easy money often overrides common sense in humans.

While remote work appears to be here to stay, hiring should be face-to-face. Note that remote work reduces that essential control, management supervision. We must compensate for that with increased automated controls.

LAA picked the wrong week to... Seriously, this is a nightmare none of us want to live. Look at the date ranges of data exfiltrated and ask yourself how much data should be online versus archived. We all remember conversations about data retention and discoverability; nobody likes to remove information. I worked with a group that had to retain HR information for 75 years post termination/separation, counter to start when the company had no pending litigation. This doesn't mean it needs to remain in the HR systems, just be retained. And we're not going back to boxes of paper. Make sure that you communicate broadly about moving data to an archive. If you decide to delete data, expect pushback as well as locally created copies, and make sure that you fully understand the use cases before reacting.

1978. Wow. The oldest verified record stolen here dates back almost half a century. Think about the people behind these files. Legal aid records can contain deeply personal information about some of the most difficult and vulnerable moments in people's lives. Some records absolutely must be retained for legitimate legal, historical, or operational reasons, but retention shouldn't mean leaving sensitive information indefinitely accessible in everyday systems. Inventory it, establish deliberate retention and deletion rules, segregate what must be archived, and tightly control access. Otherwise, we're accumulating decades of potential liability for people who may have had no relationship with the organization for years. Old data can cause very current harm.