AnyDesk and ConnectWise Vulnerabilities: What Every Houston Business Needs to Know Before the Next Attack

How Remote Access Became Load-Bearing Infrastructure

Remote access tools have become load-bearing infrastructure for modern business operations. Before the pandemic, remote desktop and remote support tools were used primarily by IT departments for internal support. The shift to hybrid and remote work between 2020 and 2023 normalized persistent remote access across virtually every business vertical.

Houston businesses are no exception. Healthcare practices in the Texas Medical Center, energy companies along the Houston Ship Channel, law firms in downtown Houston, manufacturing operations in Conroe and Katy, and logistics companies in Pearland and Pasadena all depend on remote access tools to function day to day. The tools are woven into operations so thoroughly that removing them or restricting them creates immediate business impact — which is precisely why attackers target them.

The Scale of the Problem

AnyDesk claims over 170,000 customers and 500 million downloads globally. ConnectWise is used by more than 25,000 managed service providers worldwide — meaning its attack surface isn't just the companies that run ScreenConnect directly, but every client of every MSP that deploys it. That's potentially millions of business endpoints reachable through a single tool's vulnerability.

The economics of this attack surface are straightforward from a threat actor's perspective. Remote access tools run with elevated privileges, maintain persistent authenticated sessions, operate across firewalls, and are explicitly designed to bypass the normal network perimeter. When these tools are compromised, attackers don't need to break through your defenses — they walk in through a door your IT team opened and handed them the key to.

A Pattern the FBI Has Been Warning About for Years

The FBI, CISA, and NSA have issued repeated joint advisories about the abuse of legitimate remote access software. In 2023, CISA published a guide specifically on the malicious use of remote monitoring and management (RMM) tools, noting that threat actors increasingly prefer living-off-the-land techniques — using trusted, signed software that bypasses endpoint detection — over deploying their own malware. AnyDesk and ConnectWise are both explicitly named in that advisory as commonly abused tools.

The pattern is consistent across major incidents spanning more than half a decade. SolarWinds in 2020 — supply chain attack through IT management software affecting 18,000 organizations including U.S. government agencies. Kaseya VSA in 2021 — ransomware delivered through MSP remote management platform, affecting 1,500 businesses simultaneously. ConnectWise in 2024 — authentication bypass affecting tens of thousands of on-premises deployments with exploitation by multiple ransomware groups within days of disclosure.

The tools that make IT management efficient are, by design, the most dangerous single points of failure in your security architecture. Understanding this is the prerequisite for everything that follows.

Why Houston Businesses Face Elevated Risk

Houston's economic makeup concentrates several high-value industries in a single metro area — and high-value industries attract sophisticated attackers. The Texas Medical Center is the world's largest medical complex, generating an ecosystem of thousands of affiliated healthcare organizations that collectively hold millions of patient records. The energy sector — upstream, midstream, downstream, and oilfield services — holds technical data subject to ITAR controls, operational technology connected to critical infrastructure, and financial transactions large enough to make business email compromise attacks enormously profitable.

The rapid growth of The Woodlands, Conroe, Katy, and Sugar Land as business districts has also created concentrations of professional services firms — law, accounting, consulting, engineering — that handle sensitive client data at scale but often have IT environments that lag behind their security requirements. These firms are attractive targets precisely because they hold valuable data and are perceived as having lower security maturity than the enterprise clients they serve.

For Houston businesses — particularly those in regulated industries — a compromised remote access tool isn't just a ransomware problem. It's a HIPAA breach notification event, a potential ITAR violation, a PCI-DSS audit failure, and a lawsuit waiting to happen. Understanding the specific vulnerabilities is the first step to understanding your actual exposure.

What AnyDesk Disclosed — and What They Didn't

On February 2, 2024, AnyDesk GmbH published a security advisory that disclosed something extraordinary: the company's production systems had been compromised by an unknown threat actor. This wasn't a phishing attack against an employee's credentials or a misconfigured S3 bucket leaking user data. This was a breach of AnyDesk's core infrastructure — the systems that build, sign, and distribute the software that runs on hundreds of millions of endpoints worldwide.

AnyDesk's advisory was carefully worded, describing the incident as a "security audit" that "revealed evidence of compromised production systems." The company revoked all security-related certificates, rotated credentials, and released a new version of AnyDesk (version 8.0.8 for Windows) with a new code signing certificate. Users were urged to update immediately and change passwords, particularly if the same password was used on other services.

What the initial advisory did not disclose — and what cybersecurity researchers subsequently uncovered — was the full scope of what was taken. The controlled narrative around the disclosure left many businesses unaware of how serious the underlying compromise actually was.

18,317 Credentials on the Dark Web

According to Resecurity, which tracked the incident closely, threat actors were found selling AnyDesk customer credentials on the dark web forum Exploit.in as early as January 2024 — before AnyDesk's public disclosure. Resecurity identified over 18,317 AnyDesk customer account credentials being offered for sale, priced at $15,000 for the full dataset.

The implications are significant. AnyDesk credentials provide direct access to the remote connections that users have established. An attacker with a victim's AnyDesk credentials can potentially:

• Access any device the victim has previously connected to via AnyDesk
• Monitor or take over active remote sessions in progress
• Use the victim's AnyDesk identity to establish connections to new targets, bypassing IP reputation filters because the traffic originates from a trusted account
• Pivot from a compromised AnyDesk account to the systems it manages — including servers, workstations, point-of-sale systems, and industrial control interfaces

The Stolen Code Signing Certificate: A Deeper Threat

The stolen code signing certificate is a separate and arguably more severe concern. Code signing certificates are the trust anchors of software distribution. Operating systems, endpoint protection platforms, and application control tools use code signing to distinguish trusted software from untrusted software.

A malicious application signed with a stolen AnyDesk code signing certificate would appear legitimate to Windows SmartScreen, antivirus engines, and application allowlisting systems. The attacker could distribute trojanized AnyDesk installers that pass signature verification while delivering malware payloads — and victims installing what they believe to be an AnyDesk update would be compromised without any obvious warning.

AnyDesk revoked the compromised certificate and issued a new one. Windows revokes certificates through its Certificate Revocation List (CRL) mechanism. But certificate revocation is not instantaneous across all environments — particularly in air-gapped networks, poorly managed environments, or systems that don't regularly contact Windows Update. For any installations that occurred between the certificate compromise and the revocation — a window that may have lasted weeks — the risk of trojanized software persists in the form of already-installed malicious binaries that were validated at install time.

Attribution and the CrowdStrike Investigation

The threat actor responsible for the AnyDesk breach has not been publicly identified. AnyDesk engaged CrowdStrike to conduct the forensic investigation. No specific attribution has been released publicly. The sophistication of the attack — targeting production build infrastructure rather than customer-facing systems — suggests a nation-state or advanced criminal organization with the resources to conduct extended reconnaissance before striking.

The fact that dark web credential sales predated the public disclosure by weeks suggests the breach occurred well before February 2024. The timeline of when exactly the breach occurred, how long the attacker had access, and precisely what data was exfiltrated beyond the code signing certificate and customer credentials remains opaque. This opacity is itself a risk factor — businesses cannot fully assess their exposure without knowing the full scope of what was taken.

Houston businesses using AnyDesk need to understand this wasn't just a password leak. The trust model that makes AnyDesk work — the signed software, the authenticated accounts, the persistent sessions — was compromised at its foundation. Recovery requires more than changing passwords. It requires auditing every connection made through any AnyDesk account in your environment and verifying the integrity of all AnyDesk installations currently running.

Two Separate Flaws, One Compounding Risk

Separate from the production infrastructure breach, AnyDesk disclosed two significant vulnerabilities in its Windows client in December 2024, assigned CVE-2024-12754 and CVE-2024-12755. These are distinct from the January 2024 breach — they represent software defects in the AnyDesk client application itself, not a compromise of AnyDesk's servers. Understanding the distinction matters because the remediation and detection approaches differ.

CVE-2024-12754: File Overwrite via Logging

CVE-2024-12754 is classified as an improper link resolution before file access vulnerability (CWE-59), with a CVSS v3.1 base score of 7.3 (High). The vulnerability allows a local attacker with low privileges to exploit AnyDesk's logging functionality to overwrite or corrupt arbitrary files on the Windows system.

The root cause is that AnyDesk's logging component follows symbolic links (symlinks) without proper validation before writing log data. A local attacker with the ability to create a symlink — which requires only standard user privileges on Windows — can point AnyDesk's logging target at an arbitrary file path. When AnyDesk writes log data, it writes to the symlink destination rather than the expected log location, potentially overwriting critical system files or security tool configuration files.

The attack vector is local, meaning the attacker needs an existing foothold on the machine. However, in the context of a remote access tool compromise, this is often already satisfied — the attacker who compromised AnyDesk credentials has a session on the machine. From that session, CVE-2024-12754 provides a mechanism to cause persistent damage even after the session ends.

CVE-2024-12755: Scheduled Task Privilege Escalation

CVE-2024-12755 is classified as an improper authorization vulnerability (CWE-285), with a CVSS v3.1 base score of 7.2 (High). This vulnerability allows a local attacker with low privileges to create scheduled tasks that execute with higher privileges, related to AnyDesk's interaction with Windows system services and the Windows Task Scheduler.

The mechanism exploits a race condition or authorization gap in how AnyDesk interacts with the Windows Task Scheduler service. By timing a specific request, a low-privileged process can cause AnyDesk's high-privilege service context to register a scheduled task on the attacker's behalf — a task that will then execute with SYSTEM-level privileges when triggered. This bypasses Windows User Account Control (UAC) and standard privilege management controls.

Both vulnerabilities were patched in AnyDesk version 9.0.1. If your organization has AnyDesk installations that haven't been updated to 9.0.1 or later, both CVEs remain exploitable by any process or user with local access — including malware that may have already established a foothold through phishing, a drive-by download, or a compromised software supply chain.

The Combined Attack Chain

The combination of these two vulnerabilities with the credential exposure from the January 2024 breach creates a compounding risk. An attacker who purchased stolen AnyDesk credentials from the dark web could potentially:

1. Use stolen credentials to connect to a victim machine via AnyDesk, bypassing network perimeter controls because AnyDesk traffic looks legitimate
2. Exploit CVE-2024-12754 to overwrite critical system files from within the established session, disrupting security tools or corrupting system state
3. Use CVE-2024-12755 to schedule persistent high-privilege tasks that survive the session closing and execute on a schedule
4. Establish ransomware or a backdoor with SYSTEM-level persistence, giving the attacker permanent access independent of AnyDesk going forward

This isn't a theoretical chain. The individual components — credential purchase, AnyDesk session establishment, privilege escalation, ransomware deployment — are all well-documented techniques in real-world attack playbooks. The bar for chaining these steps gets lower every month as ransomware-as-a-service groups package these techniques into ready-to-deploy affiliate toolkits.

How to Verify Your Version

AnyDesk version numbers are visible in the application's Help → About menu. In managed environments, the version can be queried via PowerShell: Get-ItemProperty "HKLM:\SOFTWARE\AnyDesk" | Select-Object -ExpandProperty Version. Any version below 9.0.1 on Windows is vulnerable to both CVEs. Version 8.0.8 addresses the code signing certificate issue from the January breach but does not include the CVE-2024-12754 and CVE-2024-12755 patches — organizations that updated to 8.0.8 and stopped there are still vulnerable to the privilege escalation chain.

How the Credential Market Operates

The 18,317 figure is more than a statistic — it's a window into the operational tradecraft of modern cybercrime. Dark web credential markets operate on a straightforward commercial model. Datasets are sold in bulk, checked for validity using automated testing tools, and priced based on the category and freshness of the accounts. The buyers are ransomware affiliates, initial access brokers, and espionage operators — each with different use cases but all treating stolen credentials as a commodity.

AnyDesk credentials are particularly valuable because AnyDesk is a commercial tool predominantly used by businesses, not consumers. The accounts that exist in AnyDesk's systems are attached to companies, IT departments, MSPs, and support operations. Purchasing one credential set may yield access to dozens or hundreds of endpoints managed through that account. The $15,000 price point for the full dataset reflects that multiplied value — the buyer is not purchasing 18,317 individual accounts, they are purchasing potential access to the networks of 18,317 businesses and their clients.

Credential Stuffing: The Immediate Attack Vector

Credential stuffing is the most immediate downstream risk from any large credential leak. Threat actors take purchased credential lists and automate authentication attempts against the AnyDesk service and any other service that might share the same credentials. AnyDesk accounts that use the same password as the victim's Microsoft 365, email, banking, or other services become a vector for account takeover across multiple platforms simultaneously.

The credential stuffing attack is industrialized. Tools like Sentry MBA, SNIPR, and Openbullet2 allow attackers to load credential lists and configuration files for specific services, then automatically attempt authentication at rate-limited pace to avoid detection. The attack runs unattended, and results — successful logins — are logged and sold or used directly. A successful AnyDesk credential stuffing attack that finds 200 valid logins from a 18,000-record dataset is a typical yield ratio; the attacker spent $15,000 and potentially gained access to 200 business environments.

Infostealer Malware and the Continuous Supply Chain

Infostealer malware represents a separate and ongoing threat to AnyDesk credentials beyond the January 2024 breach. Stealers like RedLine, Vidar, Lumma, MetaStealer, and Raccoon Stealer specifically target stored credentials in browsers, credential managers, and applications — including AnyDesk session tokens and saved connection profiles. These stealers are distributed through malicious advertisements, cracked software repositories, phishing emails, and trojanized game mods.

Once installed, an infostealer runs silently, extracts all stored credentials and session tokens, compresses them into a package called a "log," and uploads it to the attacker's collection infrastructure. Logs are then sold in bulk on markets like the Genesis Market (now defunct), Russian Market, and 2easy — often within hours of the infection occurring. The market for stolen credentials is continuous and self-replenishing; the January 2024 AnyDesk batch was a peak in ongoing credential theft rather than a unique event.

Houston businesses with AnyDesk installations should assume that some percentage of their AnyDesk credentials may be in circulation on dark web markets regardless of whether they were part of the January 2024 breach specifically. The appropriate response is not to panic, but to implement controls that make stolen credentials less useful: multi-factor authentication, access restrictions, session logging, and anomaly detection for unexpected connection attempts.

The Disclosure That Shocked the MSP Industry

If AnyDesk's breach was a slow-burn supply chain concern, ConnectWise ScreenConnect's February 2024 disclosure was an immediate catastrophe for on-premises deployments. On February 19, 2024, ConnectWise published a critical security advisory for two vulnerabilities in ScreenConnect: CVE-2024-1709 and CVE-2024-1708.

CVE-2024-1709 received a CVSS v3.1 base score of 10.0 — the maximum possible severity score. A CVSS 10.0 means the vulnerability is network-exploitable, requires no authentication, requires no user interaction, and grants complete confidentiality, integrity, and availability impact to the attacker. In plain English: any attacker with network access to a vulnerable ScreenConnect server can completely compromise it without knowing any credentials, without tricking any user, and without any prior access to the system.

How the Authentication Bypass Actually Works

The vulnerability exists in the ScreenConnect web setup wizard, which is accessible even after initial setup is complete. By manipulating the URL path to the setup wizard with specific crafted input, an attacker can bypass all authentication checks and create a new administrative account on the ScreenConnect server. Once an administrative account exists, the attacker has full control of the ScreenConnect instance — and through it, full control of every endpoint managed by that instance.

The vulnerability is deceptively simple in concept. ScreenConnect's setup wizard was designed to be accessible without authentication because it's intended to run before any administrative accounts exist. The flaw is that the wizard remains accessible via a path traversal approach even after the system is configured and live — and the wizard's elevated execution context can be abused to create new accounts regardless of the existing authentication state. The routing layer simply fails to validate that initial setup has already occurred.

The Scale of Exposure and Speed of Exploitation

ConnectWise released patches for all affected versions on February 19, 2024. For ConnectWise Cloud customers, patches were applied automatically. But for the thousands of MSPs running ScreenConnect on-premises, every server was a critical vulnerability waiting to be exploited until the patch was applied manually.

The cybersecurity research community moved at unprecedented speed. Multiple proof-of-concept exploits for CVE-2024-1709 were published publicly within 24 to 48 hours of ConnectWise's disclosure. Huntress Labs and other security vendors created ScreenConnect honeypots and observed active exploitation attempts beginning almost immediately after the PoC code circulated. Within days, CISA added both CVE-2024-1709 and CVE-2024-1708 to its Known Exploited Vulnerabilities catalog — confirming active in-the-wild exploitation at scale.

The calculus for attackers was straightforward: instead of attacking 500 businesses individually, attack one ScreenConnect server and get all 500 at once. The only question was whether each MSP patched before the attackers arrived — and many did not.

Step One: Creating an Admin Account with No Credentials

The ScreenConnect application routing logic handles URL paths to direct requests to different parts of the application. The setup wizard, at a specific internal path, is intended to be accessible without authentication during initial setup. The bypass works by constructing a URL that appears to the routing logic to be a request to a legitimate, accessible endpoint, while actually reaching the setup wizard's execution context.

The routing layer fails to properly validate that the setup wizard should no longer be accessible post-configuration. Once the attacker reaches the setup wizard through the bypass, they invoke the user creation flow with attacker-supplied credentials. The setup wizard runs with elevated application permissions and performs no validation of whether an initial setup has already occurred. The result is a new administrative account on the ScreenConnect server that the legitimate administrators are completely unaware of.

Step Two: Path Traversal for Remote Code Execution

CVE-2024-1708 is a path traversal vulnerability in ScreenConnect's file handling. Path traversal allows an attacker to access files outside the intended directory by including "../" sequences (or encoded equivalents) in file paths. In ScreenConnect's context, this allows an authenticated attacker to write files outside the expected application directories — including writing executable files to locations where they will be run by the server process.

CVE-2024-1708 is classified as requiring authentication, which places it at CVSS 8.4. However, the practical attack chain chains it directly with CVE-2024-1709: use the authentication bypass to create an administrative account, then use path traversal to write and execute malicious files on the server. The two vulnerabilities together form a complete remote code execution chain that requires absolutely no prior access to the target system.

What Attackers Did Once Inside

In observed real-world exploitation across multiple incident response investigations, attackers used this chain to accomplish several objectives in sequence, often within hours of each other.

Establish persistence before the patch drops. Webshells — persistent malicious web application files — were deployed in ScreenConnect's application directories. These webshells provide ongoing remote code execution even after the initial vulnerability is patched. This is critical to understand: patching ScreenConnect after exploitation does not remove the attacker's access. The webshell remains operational until it is specifically found and removed.

Drop redundant access tools. AnyDesk, TeamViewer, or Windows Remote Desktop configurations were installed via ScreenConnect to provide access paths not dependent on ScreenConnect itself. A victim that patches ScreenConnect but doesn't hunt for dropped remote access tools remains accessible to the attacker indefinitely through these secondary footholds.

Conduct reconnaissance before striking. Attackers executed system enumeration, Active Directory querying, network mapping, and domain controller identification. In cases where the ScreenConnect server had access to multiple client networks, attackers mapped the full scope of the MSP's client base before deciding where to deploy ransomware for maximum leverage.

Disable security tools. Stopping Windows Defender, terminating EDR processes, disabling Windows Firewall, and modifying antivirus exclusions were all documented across multiple post-incident investigations. The ScreenConnect administrative access provides the privileges needed to make these changes with no friction.

Exfiltrate data before encryption. Staging sensitive files for upload to attacker-controlled infrastructure enables double-extortion ransomware — encrypt the data AND threaten to publish it on a public leak site if the ransom isn't paid. Exfiltration typically used legitimate cloud storage services (MEGA, cloud file transfer tools) to blend with normal business traffic.

Ghost's Unique Use of Legitimate Software

Ghost ransomware (also tracked as Cring and Phantom) deserves special attention because its use of AnyDesk is not incidental — it is a central architectural choice that reflects sophisticated operational security. Ghost actors establish AnyDesk as a primary command-and-control (C2) channel on compromised systems, bypassing the need for custom malware infrastructure that might be detected by threat intelligence feeds or network security tools.

The logic is elegant from the attacker's perspective. AnyDesk is a commercially signed, widely deployed application. It communicates over ports 80 and 443 using encrypted channels. It traverses NAT without requiring inbound firewall rules. It is explicitly allowed by most corporate firewall policies because it is a recognized, legitimate business application. And critically — if an employee or IT staff sees AnyDesk in the process list, they may not question it because they know the company uses AnyDesk for support.

The Deployment Sequence

Ghost actors typically deploy AnyDesk as a persistence mechanism in the following sequence. First, they gain initial access through a phishing email, credential stuffing against an exposed service, or exploitation of a separate vulnerability. Second, they conduct initial reconnaissance to understand the environment — Active Directory structure, backup systems, security tools, and which systems hold the most valuable data. Third, they deploy AnyDesk silently using command-line installation with a specific configuration that connects to an attacker-controlled AnyDesk account rather than the victim's IT team's account. Fourth, they use the AnyDesk C2 channel to execute the ransomware payload at a time chosen for maximum impact — typically late Friday evening or immediately before a major holiday.

The use of AnyDesk as C2 also provides a fallback. If the victim's EDR detects and terminates the ransomware binary mid-execution, the attacker can reconnect via AnyDesk, diagnose what happened, and redeploy from a different location. The C2 channel persists independent of the ransomware payload itself.

Detection Challenges

The living-off-the-land technique makes Ghost particularly difficult to detect using traditional indicators of compromise. There is no custom malware binary with a known hash. There is no communication to a known bad domain. There is no unusual process name — AnyDesk.exe is as expected as chrome.exe in most business environments. Detection requires behavioral analysis: AnyDesk processes spawning child processes they shouldn't, AnyDesk making network connections to endpoints it doesn't typically reach, AnyDesk installed under a user account that isn't the IT team's account.

ThreatLocker's RingFencing and application behavior controls are specifically designed to catch these deviations — allowing AnyDesk to run while preventing it from launching cmd.exe, powershell.exe, or accessing system directories. Endpoint Detection and Response (EDR) solutions with behavioral analysis capabilities can identify when AnyDesk is being used in ways that deviate from baseline patterns for that environment.

Vishing: The Phone Call That Hands Over Access

Social engineering attacks targeting remote access tools don't always start with a technical exploit. A significant percentage of AnyDesk and ScreenConnect compromises begin with a phone call. The attacker calls a target employee, claims to be from the company's IT department, an AnyDesk support representative, a Microsoft technician, or even a law enforcement agency. The pretext varies, but the ask is consistent: "I need to access your computer to fix a problem. Can you install AnyDesk and give me the access code?"

This attack is effective because it requires no technical sophistication and bypasses all security controls. The employee installs a legitimate, signed application and voluntarily provides the access code. The "support technician" who connects is the attacker. Once connected, the attacker has interactive access to the desktop with the privileges of the logged-in user — which in most business environments is more than enough to escalate privilege, install malware, and move laterally.

Houston-area businesses have reported vishing attempts targeting employees with pretexts related to bank fraud prevention (targeting financial accounts), Microsoft 365 account suspension (targeting corporate email access), and IRS enforcement (targeting particularly around tax season). The emotional pressure of these pretexts — urgency, authority, fear — overrides the employee's normal skepticism.

Phishing for Remote Access Credentials

Credential phishing targeting AnyDesk accounts specifically increased following the January 2024 breach, as attackers knew that AnyDesk users were already on edge about credential security. Phishing emails claiming to be from AnyDesk — warning about the breach, requesting password resets, or offering security updates — redirected victims to phishing pages that harvested their AnyDesk portal credentials.

These phishing campaigns are harder to detect because they exploit context that is genuinely relevant. An AnyDesk user who has read about the January 2024 breach is predisposed to believe an email about it is legitimate. The combination of contextual awareness and emotional urgency is the attacker's most powerful tool.

Organizations can mitigate phishing risk for remote access credentials by enforcing FIDO2 phishing-resistant MFA — hardware security keys or biometric authentication — which renders stolen username and password combinations useless even if phishing succeeds. FIDO2 credentials are cryptographically bound to the legitimate site and cannot be replayed on a phishing domain, breaking the attack chain entirely.

Tech Support Scam as a Service

There is an entire industry of "tech support scam" operations, many of them based in South Asia, that use AnyDesk and similar tools as their core infrastructure. These operations run fake "Microsoft support" or "antivirus alert" advertisements, cold-call lists of business phone numbers, and operate call centers that walk victims through installing AnyDesk and granting access.

While traditional tech support scams target consumers for small-dollar fraud, the same infrastructure and social engineering techniques are increasingly being applied to business targets for higher-value outcomes — installing banking trojans, exfiltrating business banking credentials, or establishing persistent access that is later sold to ransomware operators as initial access.

Training employees to recognize and respond to unsolicited remote access requests is the most effective countermeasure. The rule should be simple and absolute: if someone calls you and asks you to install remote access software, the answer is always no, regardless of who they claim to be. Legitimate IT support is initiated by the employee submitting a ticket, not by the support technician calling and asking to take over the computer.

LockBit 3.0: Scale Through MSP Exploitation

LockBit 3.0 affiliates were among the first documented groups to exploit CVE-2024-1709 at scale. LockBit's ransomware-as-a-service model provides tools and infrastructure to affiliated attackers who conduct the actual intrusions and split the ransom revenue. The ConnectWise exploit fit perfectly into LockBit's affiliate toolkit because ScreenConnect's management plane provides high-privilege, multi-target access that maximizes ransomware impact.

A single compromised MSP ScreenConnect server could allow a LockBit affiliate to deploy ransomware across dozens of business clients simultaneously — which is the documented outcome in several post-incident investigations following the February 2024 disclosure. LockBit's leak site subsequently featured victims whose compromise was attributable to the ScreenConnect vulnerability chain, demonstrating that the group's affiliates moved from initial access to ransomware deployment within the window between patch availability and patch application.

Black Basta: Healthcare Targeting in the Texas Medical Center Shadow

Black Basta ransomware group, which emerged from the dissolution of the Conti ransomware operation, has been responsible for attacks against healthcare systems, critical infrastructure, and large enterprises globally. Black Basta was linked to ScreenConnect exploitation following the February 2024 disclosure. The group is known for its operational sophistication — typically exfiltrating data before encryption and using the threat of public disclosure as additional leverage.

Healthcare organizations in the Texas Medical Center ecosystem and their affiliated practices were specifically at risk given Black Basta's documented targeting of healthcare organizations. The group understands that healthcare organizations cannot tolerate operational downtime — patient care creates urgency that increases ransom payment likelihood significantly above the average SMB victim profile.

Bl00dy Ransomware: The Smaller Practice Problem

Bl00dy ransomware group was explicitly named by CISA in advisories related to ScreenConnect exploitation, with particular focus on healthcare and public health sector organizations. Bl00dy targets organizations with lower security maturity but high sensitivity to operational disruption — making dental practices, optometry offices, physical therapy clinics, home health agencies, and specialty medical practices in Greater Houston an attractive target.

These small healthcare organizations often rely entirely on MSPs for IT support. If that MSP's ScreenConnect server was compromised during the February 2024 window, the attack path to every small healthcare client runs directly through the MSP's management infrastructure. The small practice never had a direct vulnerability — they were compromised through their trusted service provider.

Ghost Ransomware and AnyDesk C2

Ghost ransomware uses AnyDesk specifically as a persistence and command-and-control mechanism, as detailed in the section above. Ghost actors have targeted critical infrastructure sectors including manufacturing, healthcare, government, and education. Their use of AnyDesk as C2 is explicitly documented in CISA advisories and multiple threat intelligence reports. For Houston businesses with AnyDesk deployments, Ghost represents the specific threat of an attacker who installs AnyDesk under a different account than your IT team's, creating an invisible backdoor that persists regardless of what happens to the original compromise vector.

The Economics That Drive This Pattern

The monetization calculus for ransomware attackers exploiting MSP remote access tools follows a clear logic that will continue to drive this attack pattern indefinitely. Traditional ransomware requires attacking each target individually — discovering the target, gaining access, establishing persistence, deploying ransomware. MSP exploitation is inherently scalable — compromise one management server, reach every client.

The average ransom demand for SMBs sits between $50,000 and $300,000. An MSP managing 50 clients represents $2.5M to $15M in potential ransom revenue from a single initial compromise. Even if only 20 percent of clients pay, the return on investment for the attacker is enormous relative to the cost of developing or purchasing the initial exploit. The economics will continue to drive attackers toward MSP infrastructure with the same intensity they target financial institutions — because the leverage is structurally similar.

The Trust That Becomes the Attack Surface

The managed services provider relationship is built on trust. You give your MSP privileged access to your systems — administrative credentials, remote management capability, security tool deployment rights, sometimes physical access to server rooms — because the model requires it. That trust is also the attack surface. When an MSP's tools are compromised, every client the MSP serves becomes a potential victim without having done anything wrong themselves.

Kaseya VSA in July 2021 was the blueprint. REvil ransomware exploited zero-day vulnerabilities in the Kaseya VSA remote management platform, which was used by approximately 60 MSPs serving around 1,500 downstream businesses. The attack chain was elegant in its brutality: compromise Kaseya VSA, push a malicious "update" to all managed endpoints via the legitimate management channel, encrypt everything simultaneously. The ransom demand was $70 million for a universal decryptor — the largest single ransom demand in history at the time. The ConnectWise ScreenConnect situation in 2024 followed the same template.

Questions Houston Businesses Must Ask Their MSPs

Due diligence for MSP relationships has historically focused on cost, response time, and technical capability. Security due diligence was often an afterthought. These are the minimum questions you should be asking — and documenting the answers to:

What remote management and support tools do you use to access our systems? The answer should be a specific list. AnyDesk, ConnectWise, Kaseya, N-able, Datto, TeamViewer, Splashtop — all have had significant vulnerabilities. You should know what each tool is, what it has access to, and what the patch status is.

How quickly do you patch critical vulnerabilities in your management infrastructure? The ConnectWise patch was available the same day as the disclosure. An MSP that cannot demonstrate same-day patching for CVSS 10.0 vulnerabilities has a patch management problem that directly affects your security posture.

Do you carry cyber liability insurance with a minimum $1M policy, and does it cover client notification costs? If your MSP's tools are used to compromise your business, the liability question is legally complex. An insured MSP provides at least some recourse.

Can you provide a current SOC 2 Type II report or equivalent third-party security attestation? If your MSP can't document its own security posture with independent verification, it cannot credibly manage yours.

Do you enforce phishing-resistant MFA on all administrative accounts? Password-based authentication on MSP admin accounts is a critical vulnerability. One phishing email that compromises an MSP technician's credentials can compromise every client that technician manages.

What is your incident notification procedure for clients? If your MSP discovers a breach that may affect your systems, how quickly will they notify you, and what information will they provide? If the answer is vague, the answer is insufficient.

What the KEV Catalog Actually Is

The Cybersecurity and Infrastructure Security Agency maintains a catalog of Known Exploited Vulnerabilities (KEV) — a curated list of CVEs for which CISA has confirmed evidence of active in-the-wild exploitation. Both CVE-2024-1709 and CVE-2024-1708 were added to the KEV catalog within days of ConnectWise's disclosure in February 2024. The KEV catalog is governed by Binding Operational Directive 22-01, which mandates that all federal civilian agencies patch KEV vulnerabilities within specific timeframes — typically 3 days for critical vulnerabilities.

What a KEV Listing Signals to Defenders

When a vulnerability appears in the KEV catalog, it signals three things with high confidence: the vulnerability is being actively exploited right now, proof-of-concept exploit code is likely publicly available, and waiting for routine patch cycles is insufficient — emergency patching is warranted. For any software in your environment that appears on the KEV, the appropriate response is immediate action, not scheduled maintenance window.

Cyber insurance carriers increasingly reference the KEV catalog in policy language and claim investigations. An organization running a KEV-listed vulnerable application after the listing date, without documented remediation efforts, may face denial or reduction of insurance claims. The catalog provides a clear, publicly available record of what was known and when — making the "we didn't know" defense unavailable for KEV-listed vulnerabilities.

Using the KEV as an Operational Tool

CISA publishes the KEV at cisa.gov/known-exploited-vulnerabilities-catalog with RSS and API feeds for integration with security tools. Cross-referencing your software inventory against the KEV should be a weekly routine — not a quarterly review. Set up automated alerts for new KEV additions that match your software inventory. When a match appears, treat it as an emergency: assess exposure, apply the patch or implement a compensating control, and document the response with timestamps.

CISA also publishes "quick win" guidance and advisories alongside KEV additions for major vulnerabilities. These advisories often include indicators of compromise, detection signatures, and mitigation steps that are immediately actionable. Subscribing to CISA's advisories by email is free and provides the fastest path to actionable intelligence for the most actively exploited vulnerabilities.

Step 1: Update to Version 9.0.1 or Later — Immediately

Verify your version in Help → About. Deploy the update to all endpoints via your RMM tool or endpoint management platform. Document the deployment with timestamps. Version 9.0.1 or later is required — do not run any version below this. Organizations with more than 50 AnyDesk installations should use AnyDesk's enterprise deployment options or their RMM tool to push the update silently, with a verification query to confirm successful deployment across all endpoints.

Step 2: Rotate All Credentials and Enable Two-Factor Authentication

Change passwords for all AnyDesk accounts. Use unique passwords not shared with any other service. Store them in a password manager or privileged access management (PAM) system. Enable two-factor authentication (TOTP) for all My AnyDesk portal accounts, enforced by administrative policy. This single control eliminates credential stuffing as an attack vector — even if an attacker purchases your AnyDesk credentials from a dark web market, they cannot authenticate without the TOTP code from the authenticator app.

Step 3: Restrict Unattended Access and Configure Access Control Lists

Restrict unattended access to only the specific devices that operationally require it. All other devices should require manual session acceptance. Configure Access Control Lists (ACLs) to whitelist only your specific authorized AnyDesk IDs — your IT team's, your MSP's — from connecting to each device. Block all other connection attempts by default. Audit these settings quarterly and document the configuration.

Step 4: Enable Session Recording and Centralized Logging

Enable session recording for all managed devices, particularly servers and systems with access to sensitive data. Store recordings in an immutable, centralized location outside the endpoint being managed. Route AnyDesk event logs to your SIEM or centralized log management system. Establish alerts for connection attempts from new AnyDesk IDs, connection attempts outside business hours, and session durations that exceed expected support windows.

Step 5: Disable Unnecessary Features and Monitor Traffic

If your use case is limited to screen sharing and remote control, disable file transfer and chat through AnyDesk's settings policy. Monitor AnyDesk traffic at the firewall for anomalies — unusual connection times, connections to endpoints not in your inventory, connections from unexpected source IPs. In environments with application control, verify that AnyDesk's behavior is constrained by policy using ThreatLocker RingFencing or equivalent endpoint application control.

Patch Verification and Post-Breach Investigation

Verify your ScreenConnect version in Administration → About. Patched versions are 23.9.7.8119 and 23.9.8.8114. Any version below these thresholds is vulnerable. If your server was internet-exposed between February 19, 2024 and your patch application — even for hours — conduct a compromise investigation before concluding your systems are clean. Check for new administrative accounts you did not create, webshells in application directories (.aspx files not in the original installation), new scheduled tasks, new local admin accounts on managed endpoints, and unauthorized remote access tools installed on client machines.

Access Restriction and Authentication Hardening

Restrict the ScreenConnect admin interface to explicitly whitelisted IP ranges via firewall rules. Enforce TOTP-based MFA on all administrative accounts. Implement role-based access control so technicians can only reach the client groups they support. Rotate all service account credentials quarterly and store them in a PAM system. Require client acknowledgment for end-user device sessions, reserving unattended access only for servers with additional IP-based access controls.

Logging, Monitoring, and Network Segmentation

Route ScreenConnect session logs to a SIEM with a minimum 90-day retention period (1 year preferred for compliance). Monitor for sessions initiated outside business hours, sessions to clients atypical for the connecting technician, backstage commands executed during sessions, and large file transfers. Place the ScreenConnect server in a dedicated network segment with firewall rules preventing it from initiating direct connections to client production networks outside the ScreenConnect relay mechanism.

Windows Event Log Indicators

Active hunting for RMM compromise requires knowing what to look for in Windows Event Logs. These are the highest-yield log sources for detecting post-exploitation activity via AnyDesk or ScreenConnect.

Event ID 4720 — A user account was created. Look for new accounts created outside your normal provisioning process, particularly accounts with names that mimic service accounts or system accounts.

Event ID 4732 — A member was added to a security-enabled local group. New members added to the Administrators group outside of your documented change process are an immediate red flag.

Event ID 4698 — A scheduled task was created. Any scheduled task created during a timeframe coinciding with a ScreenConnect or AnyDesk session should be investigated, particularly tasks configured to run as SYSTEM or as a domain admin account.

Event ID 7045 — A new service was installed. Ransomware actors frequently install their payload as a Windows service for persistence. New services installed outside of documented IT change processes warrant immediate investigation.

Event ID 4688 (Process Creation) with CommandLine logging enabled — Look for AnyDesk.exe or ScreenConnect processes spawning cmd.exe, powershell.exe, wscript.exe, or other scripting engines. Legitimate remote support tools should not be launching command interpreters — this is a strong indicator of compromise.

Network-Level Detection

At the network layer, AnyDesk and ScreenConnect compromise leaves detectable traces if you have the right monitoring in place.

AnyDesk relay connections — AnyDesk connects through a global network of relay servers. Legitimate AnyDesk traffic should show connections to known AnyDesk relay IP ranges. Connections on AnyDesk ports (443, 80) to IP ranges outside the known AnyDesk relay infrastructure may indicate trojanized AnyDesk being used as C2 to an attacker-controlled relay.

Large outbound transfers — Data exfiltration before ransomware deployment typically involves large outbound transfers to cloud storage services. Monitor for transfers exceeding 1GB to MEGA, Dropbox, Google Drive, or unfamiliar file transfer services during non-business hours.

SMB lateral movement — After gaining access via ScreenConnect or AnyDesk, attackers typically use SMB to move laterally. Internal SMB traffic from the ScreenConnect server to client endpoints, or from a compromised endpoint to other systems on the network, is worth investigating in context.

File System Indicators

Specific file system artifacts indicate ScreenConnect or AnyDesk compromise. In the ScreenConnect application directory, look for any .aspx files not present in the original installation — these are webshells. In the Windows Task Scheduler, look for tasks created with base64-encoded PowerShell commands in the action field — a classic attacker technique for obfuscating malicious commands. In the AnyDesk application directory and AppData folders, look for configuration files pointing to AnyDesk accounts that are not your IT team's.

Zero-Trust Remote Access Platforms

Tools like Zscaler Private Access, Cloudflare Access, and BeyondCorp Enterprise implement a fundamentally different model — instead of a persistent remote access tool installed on endpoints, they create application-level access tunnels that are policy-enforced, identity-verified, and logged at each access attempt. Users authenticate with MFA, and access is granted only to specific applications rather than to the underlying network. This eliminates the class of vulnerabilities that affects traditional remote access tools because there is no persistent agent managing broad connection access — each session is freshly authenticated and policy-evaluated.

Microsoft Remote Desktop Services with Conditional Access

For Microsoft-heavy environments, a properly configured RDS environment with Azure AD Conditional Access policies can provide remote access with enterprise-grade identity controls, device compliance evaluation, and full audit logging through Microsoft Defender for Cloud Apps. This approach eliminates third-party remote access tools entirely from the managed access path, reducing your software supply chain risk to Microsoft's own security posture.

Alternative RMM Platforms and VPN Plus RDP

If replacing ScreenConnect with another RMM, evaluate security posture explicitly: SOC 2 Type II certification, active bug bounty program, vulnerability disclosure policy, and patch SLA commitments. Platforms worth evaluating include NinjaRMM, Atera, Datto RMM, and Syncro. For environments where the remote access use case is limited to IT support, a properly configured VPN with MFA combined with Windows Remote Desktop can eliminate the third-party remote access tool entirely — a standard protocol with decades of hardening rather than a commercial tool with its own proprietary attack surface.

What Zero Trust Means in Practice

Zero trust is an architectural principle: assume no user, device, or network should be trusted by default, verify every access request explicitly, and enforce least-privilege access. In a traditional perimeter-based network, a legitimate AnyDesk session from an authorized technician is indistinguishable from a session established by an attacker using stolen credentials — both arrive with valid authentication tokens over an encrypted channel. Zero trust verifies the identity of the user, the health of the device, the legitimacy of the access request, and the appropriateness of the requested resources before allowing anything through.

Identity, Device Trust, and Least Privilege

Every remote access session must begin with verified identity — MFA with a phishing-resistant factor (FIDO2 hardware key or biometric), associated with a specific named user rather than a shared account. Device health checks via Conditional Access policies verify enrollment, compliance (disk encryption, antivirus, patch level), and OS version before the connection proceeds. Network segmentation, application-layer access controls, and just-in-time privilege elevation enforce least-privilege access: a technician troubleshooting a printer does not need access to the file server.

Session Monitoring and ThreatLocker Enforcement

All remote access sessions to sensitive systems should be recorded and monitored. Anomaly detection should trigger alerts for connections at unusual hours, connections from unusual locations, large data transfers, and command executions that deviate from the technician's baseline activity pattern. ThreatLocker's RingFencing feature — which LayerLogix deploys for clients across Greater Houston — restricts what AnyDesk can launch, access, and connect to at the endpoint level, preventing the living-off-the-land exploitation pattern even when the remote access tool itself is compromised.

The First Hour: Contain Without Destroying Evidence

Speed matters — every hour of dwell time allows attackers to deepen access and exfiltrate more data. Contain immediately: block the compromised tool at the firewall, isolate compromised systems via VLAN (not shutdown), revoke and rotate all associated credentials, and notify your cybersecurity incident response provider. Do not shut systems down before evidence preservation — memory dumps, exported logs, and disk images must be taken from running systems before any changes are made.

Days 1–3: Scope and Notify

Review all ScreenConnect and AnyDesk session logs for the exposure window. Hunt for indicators on every managed endpoint: new scheduled tasks, new local admin accounts, new registry run keys, new services, unauthorized remote access tools, and webshells in application directories. Review Active Directory for new accounts and privilege escalations. Review Microsoft 365 audit logs for forwarding rules and OAuth grants. Check for data exfiltration via large outbound transfers to cloud services.

Notify stakeholders based on data involved: HHS within 60 days for HIPAA breaches, your acquiring bank within 24 hours for PCI-DSS breaches, your cyber insurance carrier within 24–72 hours per policy terms, and affected Texas residents per state notification law. Engage legal counsel before any public statements — attorney-client privilege can protect forensic investigation findings if properly structured.

HIPAA, ITAR, and PCI-DSS Exposure

For healthcare organizations in the Texas Medical Center ecosystem, a compromised remote access tool is a HIPAA breach event under 45 CFR § 164.312 — the unauthorized access to the tool triggers notification obligations regardless of whether data was actually exfiltrated. OCR fines for inadequate access controls and audit logging have reached $1.9 million per violation category.

For energy and defense sector companies along the Gulf Coast, AnyDesk sessions routed through offshore relay servers may constitute unauthorized ITAR exports of controlled technical data — a risk that requires ITAR-compliant remote access solutions with domestic-only data routing and U.S.-person access controls. For Houston retailers and hospitality businesses, PCI-DSS v4.0 (mandatory since March 2024) requires MFA for all CDE access and third-party vendor attestation — an MSP with an unpatched ScreenConnect server accessing your CDE is a direct compliance violation.

Accept the Pattern — Design Around It

The AnyDesk and ConnectWise events are data points in a consistent pattern that will continue: tools providing broad, privileged access to business infrastructure will be targeted by sophisticated attackers who understand that compromising the tool is more efficient than compromising individual targets. The goal is not to find a remote access tool that will never be compromised — no such tool exists. The goal is to design your environment so that a compromised remote access tool does not mean compromised business.

Patch within 24 hours of CVSS 9.0+ disclosures. Audit remote access tool installations quarterly. Treat your MSP's security posture as part of your own risk profile — request annual third-party security assessments and make attestation a contract requirement. Plan for compromise, not just prevention — have a tested incident response plan that specifically addresses remote access tool compromise before you need it.

LayerLogix Can Help

LayerLogix works with businesses across Greater Houston — including The Woodlands, Conroe, Katy, Sugar Land, Pearland, and Pasadena — to audit existing remote access infrastructure, implement ThreatLocker application control and RingFencing, deploy phishing-resistant MFA, and build incident response programs that are operationally ready before the next event in this pattern. We work with healthcare practices, energy companies, legal firms, construction companies, and professional services organizations to build security programs that match your industry's compliance requirements and Houston's specific threat landscape.

Schedule a free remote access security assessment. We'll audit your AnyDesk and ConnectWise deployments, identify your specific exposure, and give you a prioritized remediation roadmap — no obligation.

Download the SMB Cybersecurity Survival Guide for a complete framework for building a defensible security program on a realistic budget.

Learn how LayerLogix's managed cybersecurity services protect Houston businesses from exactly these kinds of remote access threats.