BeyondTrust Remote Support Flaw Exploited; ConnectWise Suspends Cloud Backup After M365 Credential Compromise; US Bankruptcy Courts Offline After IT Contractor Incident

Remote support services like BeyondTrust are likely a critical success factor for your help desk. And these services are now an active target. Because the discovered exploits predate the fix, once you've made sure that your implementation is fully updated, grab the IoCs from the Google/Mandiant blog and make sure that you're clean. Next — and here's where it gets harder — go through the targeted compensating controls to supplement the patch. These include network restrictions, credential rotation, configuration review, phishing-resistant MFA, setting the default Jump Admin policy to No Access, and reducing permissions. Did I mention making sure logs go to your SIEM and implementing monitoring? In other words, harden the environment. While you've got all those plates spinning, have someone take a look and see if the hosted SaaS version of your remote support client is viable, as it's one less component to keep updated.

Privileged access management is often one of the key products required to secure developer supply chains. It is a bit ironic that this tool is now itself a supply chain issue. I understand that BeyondTrust is holding back details at this point, but I hope they will provide a detailed post-mortem later to retain customer trust.

A compromised remote support appliance can become an attacker’s privileged jump box into the rest of the enterprise. BeyondTrust and Mandiant describe attackers harvesting credential-vault material, establishing persistence, reaching downstream systems, and deleting local logs. There’s another detail I find especially instructive: BeyondTrust reports that high-severity detections fired in real time, but a third-party triage tool automatically closed them as false positives. The company ultimately found the intrusion through a separate intelligence-driven hunt. That’s a potent reminder that an automated “benign” verdict isn’t necessarily ground truth. Patch the appliance of course, but also scrutinize privileged sessions, preserve telemetry off-device, and investigate whether brokered credentials need rotation. Kudos to BeyondTrust and Mandiant for sharing these important details. Privileged access and detection automation both require independent checks.

I have seen many organizations where this system is the only system exposed to the internet from their DMZ, outside of traditional VPNs. I can see where an attacker would want to compromise this device. In some places, it has more credibility than your run-of-the-mill RMM, while still having elevated access. Remote management systems are probably tier zero, like your routers, VPNs, and domain controllers. Treat them as such. Their target being legal is even more concerning, given how much sensitive data law firms hold.

This incident highlights one of the major challenges organisations face when integrating third-party applications into their cloud environments. We often focus on securing user accounts with strong passwords and multifactor authentication, but we also need to pay close attention to the permissions and privileges granted to applications, and nowadays to AI agents. A compromised application identity can potentially provide attackers with access to multiple systems and sensitive information without needing to compromise an individual user's account. Organisations should regularly review which third-party applications have access to their cloud environments, what permissions those applications have, and whether that access is still required. Trusting a supplier should not mean giving its applications unrestricted access to your systems.

Remember that pitch on how you could get your M365 environment fully backed up, and you wound up implementing ConnectWise? Here we are with a third-party issue. At this point your ConnectWise services should not be enabled. Right now, while you don't get new backups, the existing backups remain encrypted, preserved, and isolated. ConnectWise has to finish rotating credentials and developing guidance moving forward to prevent recurrence. While that is sorting itself out, review your M365 environments for unexpected accounts and unauthorized privileges in concert with your MSP. It's too soon to be second guessing your choice to use ConnectWise versus something else.

Oh, that is big, big bad. ConnectWise, what is going on here? One compromised service principal gets *many* customers compromised? I am wondering how this even happens in the first place; shouldn’t there be a more isolated set of credentials for backups? The more this happens, the more customers will wonder where they are going to put their data. What's even scarier: You have to think that customers will try to create their own RMMs and backup systems with LLMs, and while it seems like a good idea, is it actually safer?

Here’s a trust relationship we need to examine much more closely: A cloud backup provider’s application identity can have extensive access to customers’ Microsoft 365 environments, often without any human login or MFA challenge. Once attackers obtain that application’s credentials, they inherit whatever privileges customers have granted it. And disabling the original connection doesn’t necessarily evict the attacker. New application secrets, altered role assignments, and malicious mailbox rules may survive the shutdown of the compromised integration. Huntress’s investigation makes these persistence risks painfully concrete. Audit what third-party applications can do in your cloud environment, review their credentials and consent grants, preserve the logs, and follow the vendor’s containment guidance. One compromised integration can become many customers’ problem. And when the backup service itself must be suspended, customers also lose access to a system intended to help them recover from disasters. That’s a heck of a trust dependency.

The API credential ConnectWise failed to protect is like a single master key into all of their customers’ services. Any risk assessment should have said, "Don’t do it that way, or if you absolutely must, go to very rigid security controls to prevent compromise." Failing to do so is just like a traditional software vendor embedding hard-coded passwords in the code.

The lesson for the rest of us is that such credentials should be stored only in high security modules (HSMs) that permit their use but not disclosure or copying.

When a contractor’s cybersecurity incident interrupts a nationwide court notification system, the consequences extend far beyond the affected servers. Bankruptcy notices communicate important information to people and organizations navigating difficult financial and legal circumstances. Interrupting that process can create uncertainty precisely when people need clarity about their obligations and rights. This is why continuity planning for outsourced systems must extend beyond restoring the technology. How will essential notices be issued while the service is unavailable? What alternative processes have been tested? And how will affected parties know where to obtain reliable information? Outsourcing a critical government function doesn’t eliminate the responsibility to keep that function operating. Cyber resilience ultimately needs to protect the people who depend on our institutions.

Another example of how third-party dependencies can have a big impact. The question is, are you prepared for outages in your third-party service providers? It's not just continuity/resumption of business — consider notifications (internal and external), how long before data gets stale, and when that becomes critical. Work all these things out ahead of time. Look to see if you've implemented available HA or other options which help bridge any service gaps. As Ed says, this is about resilience and protecting the people who depend on us.

While this was not a DoD contract, this was a defense contractor. In July, the US DoD delayed Phase 2 of the Cybersecurity Maturity Model Certification (CMMC) program that would require third-party security assessments for DoD contractors starting in November. This makes a good argument for getting CMMC back on track, but the NIST requirements are still required for all government contractors, and there should be penalties for this failure.

This incident is another reminder that your organisation's ability to deliver its services can be seriously impacted by a cyberattack against one of your suppliers. It doesn't matter how secure your own systems are if a critical third party is unavailable and you have no alternative way of operating. Organisations need to identify which suppliers they depend on for critical services and ensure their business continuity and cyber resilience plans take account of those suppliers becoming unavailable. Having a contract or service-level agreement with a supplier is of little comfort when that supplier is unable to deliver the service your organisation depends upon.

Although specifics are limited aside from an offline website, this event serves as a vital reminder for system owners to incorporate third-party vendors into their security and risk management processes. Reviewing your current SLAs is a crucial first step.

Remember those OT/ICS systems which take a licking and keep on ticking? You need two things here: plans for how they are being kept updated, and for how they are protected. The owners are not going to be keen on rapidly applying updates, which is why the protections are key. Verify how they are isolated so only authorized systems can interact, and make sure you've got monitoring and alerting, there are systems which understand the proprietary protocols these talk and will detect anomalies as well as new/unexpected traffic, which you need to investigate. Remember, availability is king, downtime is a nasty four-letter word, and the system owners don't want to be compromised any more than you do. Odds are, these are systems that really are keeping the lights on.

While patching is inefficient, in the face of poor code quality, it is essential. This is as true for OT as it is for IT.

Here’s a reminder that your home media server is still a server, even if its primary job is helping you enjoy movies and television. Within about a day of the Plex2Shell proof-of-concept release, researchers were observing attempts to install cryptocurrency miners and residential proxy software on vulnerable systems. That second payload is particularly concerning: Attackers can potentially turn your home Internet connection into an exit point for other people’s malicious activity. If you operate Plex, verify that it’s updated, review its Internet exposure, and look for evidence of compromise rather than assuming patching alone is sufficient. The Internet doesn’t care whether your server is in a corporate data center or sitting next to your TV.

You've got that Plex server you're using to stream content to your devices, and remember how you set it so that your buddy across town could check some of your stuff out too? What do you want to bet Shodan has your device and information available — go look! Grab another cup of coffee, and as Ed said, update to the latest version, review your external access (port 32400), and check for the IoCs (in the boredhackerblog). If they can use the flaw to deploy a crypto miner, they can use it to deploy something else, so if you don't need to expose the service, patched or otherwise, don't. Your Plex server has three things they want: cycles, storage, and Internet access.

This vulnerability was exploited pretty much the same day details about the issue became public. Exposing a media server like Plex is always dangerous and should be avoided. But even if you do not expose Plex, update now. If your Plex server is exposed to the internet: assume compromise.

These media servers became very popular during the pandemic to watch movies together remotely. To do this in the way that Plex does it, unfortunately you’ll need to expose a non-HTTP port to the internet. This is where it can get a bit bad, since many of these systems are internal to individual home networks, aren't segmented inside the network, and may not be maintained. If you are a Plex user, make sure you update it automatically — my advice: do it daily. Could that break your system? Yes, but given how quickly vulnerabilities are being found along with PoCs, you really don't stand a chance at home.

F5 is the primary maintainer of NGINX after acquiring NGINX Inc. in 2019. In other words, this isn't just about your F5 appliances. While F5 lists some mitigations to the NGINX flaws, it's far better to update. Fortunately, it looks like the updates to the relevant NGINX software include all the fixes. Unfortunately, you're going to have to check all your NGINX, BIG-IP and F5 products for applicable updates. This would be a good time to verify you're on the most current supported versions of these products.

There have been a few recent vulnerabilities in NGINX. They usually only affect very specific configurations. But make sure you do not miss any of the updates. It is easy to miss that a particular update is new and different from the one you looked at a couple of days ago.

NGINX is such a widely used web server. Personally, I’ve been concerned about it for quite some time and have been using alternatives like Caddy. NGINX is also a Kubernetes ingress controller, which is daunting to consider given how widespread Kubernetes is. While I know F5 has purchased the product, its beginnings are questionable. I'm also concerned about the FreeNGINX project. Either way, if you use NGINX, you should update your systems often. The good news is that this is a non-standard system configuration.

It is worrying that access to such sensitive personal information could apparently be compromised because an employee stored their credentials on a personal device. This highlights why organisations need to look beyond their own systems when managing access to sensitive data. Strong authentication, appropriate access controls, restricting access to only approved and trusted devices, and monitoring for unusual activity should apply regardless of who owns the device or employs the person accessing the data. Remember, your security is only as strong as your weakest link.

The Florida FLHSMV cannot contact individuals whom they no longer have contact information for. If you lived in Florida and still have that vehicle you registered there, or if you had a Florida driver's license, assume the information related to that license or registration has been compromised; you want to be looking at your ID/credit monitoring for alerts for your information being exfiltrated. This would be a good time, whether in or out of scope of this incident, to make sure that you are monitoring everything (remember that credit card you replaced and didn't update?) and that you didn't miss any alerts that matter.

Continued reliance on reusable credentials for mission critical and/or public network applications is reckless. The managers responsible need a year or two in the penalty box.

You may recall I was not happy about Ahold Delhaize's notification regarding offline services. This is much better — they are publishing ETAs for systems, where known, as well as acknowledging what remains offline/in-progress even when they don't have an ETA. Some sites have a list of services with a up/down indicator, while AD is describing status in text. Both work, and the point is to notify and keep people updated during an outage without that notification overshadowing or impacting the incident recovery and response.

This makes two attacks against European grocery store chains in one week. So far, I have not seen any indicators that the attacks are related. The food supply chain is critical infrastructure but is not always treated like such.

A second attack in two years suggests systemic risk that goes beyond bad actors. Although official details are limited to generic references to "malicious actions," recurring breaches signal an urgent need for executive leadership to perform an end-to-end evaluation of their information security and governance framework.

This is a tale of two incidents. The first was detected in May of 2025, and the investigation and review of systems just finished, with notices being sent to affected individuals last week, 17 months later. The second occurred August 28, 2026, which they are investigating now. This has got to be rough; while the Rhysida ransomware gang is taking credit for the second incident, it's not clear if the attackers took advantage of mitigations not fully implemented or other new weaknesses, or if maybe the second incident was discovered while investigating the first. No matter how you look at it, this has to be rough on the team. I hope they publish some lessons learned that we can leverage. In the meantime, tighten up those investigation timelines, particularly implementing remediations/hardening. Make sure that you fully implement countermeasures, such as MFA, monitoring, WAF (defense in depth), and risk-based updates. Our adversaries are using tools to find weaknesses at an ever-increasing rate, forcing us to use more aggressive approaches to raise the bar. In the long term it's worth it, so make sure you're keeping senior management onboard while your team implements.

The occurrence of two separate incidents over a two-year period highlights a potential lack of security governance by county leadership. The initial incident required more than a year for review, with notifications only recently issued. Expediting the current investigation is critical, especially given that the county seemingly failed to implement necessary improvements to its information security program after the first event.

Ransomware continues exploiting failures to use strong authentication, failures to structure enterprise networks, and failures to implement least privilege WRITE access control. Years into the epidemic we should not be accepting these risks.