AnyDesk and ConnectWise Security Hardening: Complete Checklists for Houston Businesses

Step 1: Verify and Update to Version 9.0.1 or Later

AnyDesk version 9.0.1 patches both CVE-2024-12754 (file overwrite via logging) and CVE-2024-12755 (scheduled task privilege escalation). Version 8.0.8 addresses the code signing certificate issue from the January 2024 breach but does NOT patch these privilege escalation vulnerabilities. Organizations that updated to 8.0.8 and stopped there remain vulnerable to the local privilege escalation chain.

Check your version in Help → About. In managed environments, query via PowerShell:

Get-ItemProperty "HKLM:\SOFTWARE\AnyDesk" | Select-Object -ExpandProperty Version

Deploy updates to all endpoints via your RMM tool with silent installation flags. Document the deployment with timestamps — this documentation matters for insurance claims and compliance audits. Establish a policy that AnyDesk versions below the current patched release are not permitted to run in your environment, enforced through application control.

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

Given that AnyDesk account credentials were confirmed on dark web markets following the January 2024 breach, any password existing at the time of the breach should be treated as potentially compromised. Change passwords for all AnyDesk accounts — My AnyDesk portal, service accounts, and any embedded credentials in scripts or automation. Use unique passwords not shared with any other service. Store them in a password manager or privileged access management (PAM) system.

Enable TOTP-based two-factor authentication for all My AnyDesk portal accounts, enforced by administrative policy. This single control eliminates credential stuffing as an attack vector — an attacker who purchases your AnyDesk credentials from a dark web market cannot authenticate without the TOTP code from your authenticator app. Authenticator app (TOTP) is preferred over SMS-based 2FA, which is vulnerable to SIM swapping attacks.

Step 3: Restrict Unattended Access — Strictly

AnyDesk's "unattended access" feature allows connections without a human present to accept the session. This is necessary for server maintenance but represents a significant attack surface on workstations and end-user devices. Audit every device where unattended access is enabled and ask: does this device operationally require unattended access, and is the access restricted to specific authorized AnyDesk IDs?

Restrict unattended access to only devices that genuinely require it for operational purposes. All other devices — workstations, employee laptops, shared terminals — should require manual session acceptance. The user present at the device must explicitly approve every incoming connection request. This prevents an attacker who has stolen AnyDesk credentials from silently connecting to end-user machines without anyone knowing.

Step 4: Configure Access Control Lists

AnyDesk supports client-level access control — specifying which AnyDesk IDs are allowed to connect to a given device. For business deployments, configure ACLs to whitelist only your IT team's AnyDesk IDs and your MSP's AnyDesk IDs. Block all other connection attempts by default. This means an attacker who obtains your AnyDesk ID cannot connect to your machines even if they somehow bypass authentication — their AnyDesk ID is not on the allow list.

Document the allowed AnyDesk IDs for each device or device group. Review these ACLs quarterly. When MSP relationships change, immediately remove the former MSP's AnyDesk IDs from all device ACLs — ex-MSP access that persists after the relationship ends is a common and serious security gap.

Step 5: Enable Session Recording and Centralized Logging

AnyDesk Business and Enterprise plans include session recording. Enable it for all managed devices, particularly servers and systems with access to sensitive data (patient records, financial systems, intellectual property). Session recordings provide forensic evidence in the event of an incident and serve as a deterrent to insider abuse — technicians who know sessions are recorded behave differently.

Store recordings in an immutable, centralized location outside the endpoint being managed. If an attacker compromises the device, you don't want them to be able to delete session records that would document their activity. Route AnyDesk event logs to your SIEM or centralized log management system. Establish alerts for: connection attempts from new AnyDesk IDs not on the authorized list, connection attempts outside business hours, session durations that significantly exceed your typical support window, and multiple failed authentication attempts.

Step 6: Disable Unnecessary Features

AnyDesk's file transfer and chat features expand the attack surface beyond what most support use cases require. If your use case is limited to screen sharing and remote control, disable file transfer and chat through AnyDesk's settings policy. An attacker who establishes a session in an environment without file transfer enabled cannot exfiltrate files via the AnyDesk channel — they must use a separate exfiltration method, which is easier to detect.

For organizations managing AnyDesk at scale, AnyDesk's enterprise deployment options allow these settings to be enforced via Group Policy or configuration management tools so they cannot be overridden by individual users or technicians.

Step 7: Apply ThreatLocker RingFencing

ThreatLocker's RingFencing feature is the most powerful protection control available for AnyDesk — it restricts what the AnyDesk process is allowed to do at the endpoint level, regardless of what an attacker attempts through an established session. RingFencing policy for AnyDesk should:

• Prevent AnyDesk from launching cmd.exe, powershell.exe, wscript.exe, cscript.exe, or other scripting engines
• Prevent AnyDesk from accessing sensitive file paths (Active Directory, financial application directories, patient record storage)
• Prevent AnyDesk from establishing outbound network connections to destinations outside the known AnyDesk relay IP ranges
• Prevent AnyDesk from modifying scheduled tasks, registry run keys, or Windows services

With RingFencing in place, an attacker who compromises an AnyDesk session can see the screen but cannot execute commands, cannot access sensitive files through the AnyDesk channel, and cannot establish the persistence mechanisms that convert temporary session access into long-term compromise. The attacker is constrained to the narrow capability set that RingFencing permits — screen sharing only.

Step 8: Monitor AnyDesk Traffic at the Network Level

AnyDesk communicates to its relay servers over ports 443 and 80. In environments with next-generation firewall capabilities, monitor AnyDesk connection patterns for anomalies: connections at unusual hours, connections from devices where AnyDesk shouldn't be running, connections to IP ranges outside known AnyDesk relay infrastructure (which could indicate trojanized AnyDesk connecting to attacker-controlled relay servers), and unusual volume of data transferred during sessions.

Step 1: Verify the Patched Version

The patched versions for CVE-2024-1709 and CVE-2024-1708 are 23.9.7.8119 and 23.9.8.8114. Check your version in Administration → About. Any version below these thresholds is vulnerable to the CVSS 10.0 authentication bypass and path traversal remote code execution chain. If you are running an end-of-life ScreenConnect version that cannot be updated to a patched release, migrating to ConnectWise Cloud or replacing ScreenConnect entirely is the only safe path — running an unpatched CVSS 10.0 on a production server is not an acceptable risk posture.

Step 2: Conduct a Post-Exposure Investigation

If your ScreenConnect server was internet-accessible between February 19, 2024 (the disclosure date) and your patch application — even for hours — assume compromise until investigation proves otherwise. Do not skip this step based on the assumption that "we would have noticed." The real-world incident described in Part 1 of this series involved nine days of dwell time with no visible indicators to the MSP. Indicators to investigate:

• New administrative user accounts in ScreenConnect you did not create
• ScreenConnect session logs showing connections to endpoints at unusual times or from unexpected geographic locations
• New .aspx or executable files in the ScreenConnect application directories
• New scheduled tasks on the ScreenConnect server or managed endpoints, particularly those with base64-encoded PowerShell in the action field
• New local administrator accounts or new domain accounts created during the exposure window
• AnyDesk, TeamViewer, or other remote access tools installed on managed endpoints without IT authorization
• Disabled or modified backup job configurations on servers

Step 3: Restrict Admin Interface Access by IP

The CVE-2024-1709 bypass requires network access to the ScreenConnect web interface. If the admin interface is accessible only from your organization's IP ranges and your MSP's office IP ranges, the attack surface is dramatically reduced. An attacker scanning for vulnerable ScreenConnect servers from an external IP address would receive a connection rejection rather than the login page — they cannot exploit a service they cannot reach.

Configure this restriction at your perimeter firewall or reverse proxy. If you use a reverse proxy (nginx, Caddy, HAProxy) in front of ScreenConnect, add IP allowlist rules at the proxy layer as an additional control. The restriction should be specific to the administrative management port — the client relay port (used by managed endpoints to report in) may need to remain accessible, but the admin interface does not.

Step 4: Enforce MFA and Role-Based Access Control

Enable TOTP-based MFA for all ScreenConnect administrative accounts. Implement role-based access control so each technician has access only to the client groups they manage, with only the permissions their role requires. A technician supporting five small business clients should not have access to the ScreenConnect configurations for healthcare clients managed by a different team. A compromised technician credential should be contained to that technician's client subset — not provide access to every client the MSP serves.

Step 5: Route Session Logs to a SIEM

ScreenConnect logs stored locally on the ScreenConnect server are vulnerable to tampering by any attacker who gains administrative access — as in the real-world incident described in Part 1. Route ScreenConnect session logs to an external SIEM (Splunk, Microsoft Sentinel, Elastic, or equivalent) as they are generated. Configure alerts for: new administrative account creation, sessions initiated outside business hours, sessions to clients that the connecting technician doesn't typically support, backstage commands executed during sessions, and large file transfers.

Log retention should be a minimum of 90 days. For healthcare-related MSPs subject to HIPAA requirements, 1 year retention is appropriate. For MSPs working with clients in regulated industries, verify that ScreenConnect log retention meets each client's applicable regulatory requirements.

Step 6: Network Segment the ScreenConnect Server

Place the ScreenConnect server in a dedicated management VLAN. Firewall rules should prevent the ScreenConnect server from initiating direct connections to client production networks — all connectivity to client endpoints should flow through the ScreenConnect relay mechanism, not through direct network paths. A compromised ScreenConnect server in a segmented network cannot directly reach your client's accounting server, patient records system, or Active Directory domain controllers through a flat internal network path.

Step 7: Require Session Acknowledgment for End-User Devices

Configure ScreenConnect to require the device user to explicitly accept incoming support sessions on end-user workstations and laptops. Unattended access should be reserved for servers with additional IP-based access controls. The human acknowledgment requirement is a meaningful deterrent — an attacker who gains access to the ScreenConnect management console cannot silently initiate sessions on endpoints where a person is present without their knowledge.

Windows Event Log Indicators

Active hunting for RMM compromise requires knowing which Windows Event IDs are most likely to contain evidence of exploitation. These are the highest-yield sources.

Event ID 4720 — A user account was created. After CVE-2024-1709 exploitation, the attacker creates a new ScreenConnect administrative account. On managed endpoints, new local accounts created during a ScreenConnect session are a red flag. Filter this event for accounts created outside your documented provisioning process.

Event ID 4732 — A member was added to a security-enabled local group. New members added to the Administrators group outside documented change management require immediate investigation. This is a primary escalation indicator following AnyDesk CVE-2024-12755 exploitation.

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. Specifically look for tasks with base64-encoded content in the action field — a strong indicator of malicious task creation. Get-ScheduledTask | Where-Object {$_.Actions.Execute -match "base64"} identifies these quickly in PowerShell.

Event ID 7045 — A new service was installed. Ransomware actors frequently install their payload as a Windows service. New services outside documented change management, particularly services with random-looking names or names that mimic legitimate Windows services, warrant immediate investigation.

Event ID 4688 with CommandLine logging enabled — Process creation events, including the full command line used to launch each process. Enable this via Group Policy (Audit Process Creation → Success, and "Include command line in process creation events"). Look for: AnyDesk.exe or ScreenConnect processes spawning cmd.exe, powershell.exe, or other scripting engines. Legitimate remote support tools should not be launching command interpreters.

PowerShell Hunt Queries

The following PowerShell commands are useful for rapid hunting on endpoints you suspect were accessed via compromised AnyDesk or ScreenConnect sessions:

Find scheduled tasks with encoded payloads:
Get-ScheduledTask | ForEach-Object { $_.Actions } | Where-Object { $_.Execute -match "powershell" -and $_.Arguments -match "encoded|base64|enc " }

Find new local admin accounts (created in last 30 days):
Get-LocalGroupMember Administrators | Where-Object { (Get-LocalUser $_.Name).PasswordLastSet -gt (Get-Date).AddDays(-30) }

Find AnyDesk installations in non-standard directories:
Get-ChildItem -Path C:\ -Recurse -Filter "AnyDesk.exe" -ErrorAction SilentlyContinue | Where-Object { $_.FullName -notmatch "Program Files" }

Find webshells in ScreenConnect directories (files created or modified recently):
Get-ChildItem "C:\Program Files (x86)\ScreenConnect\App_Extensions" -Recurse -Filter "*.aspx" | Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-90) }

Network-Level Detection Indicators

AnyDesk connecting to non-relay IPs. AnyDesk maintains a published list of relay server IP ranges. Outbound connections on ports 443/80 from AnyDesk processes to IP addresses outside these ranges may indicate trojanized AnyDesk connecting to attacker-controlled infrastructure. Enable firewall logging of outbound connections and alert on AnyDesk process connections to non-whitelisted destinations.

Large outbound transfers during non-business hours. Data exfiltration typically involves large uploads to cloud storage services — MEGA, file transfer services, cloud drives. Monitor for outbound transfers exceeding 500MB to unfamiliar destinations during evening and weekend hours. These transfers are often disguised as normal cloud sync traffic but occur at unusual times and volumes.

SMB lateral movement from management systems. After gaining access via ScreenConnect or AnyDesk, attackers commonly use SMB to enumerate and move to other systems. Internal SMB traffic initiated from the ScreenConnect server or from recently connected AnyDesk endpoints to systems they don't typically communicate with is worth investigating in context.

Zero-Trust Remote Access Platforms

Organizations evaluating replacement of AnyDesk or ScreenConnect should consider zero-trust remote access platforms as the architecturally superior alternative. Tools like Zscaler Private Access, Cloudflare Access, and BeyondCorp Enterprise implement application-level access tunnels that are policy-enforced, identity-verified, and logged at each access attempt. There is no persistent agent managing broad connection access — each session is freshly authenticated and policy-evaluated.

This model eliminates the class of vulnerabilities that affects traditional remote access tools. CVE-2024-1709 exists because ScreenConnect has a persistent management interface that accepts unauthenticated connections. A zero-trust platform that authenticates each access request independently has no equivalent attack surface — there is no "management wizard" to bypass because there is no persistent management interface at all.

Microsoft Remote Desktop Services with Conditional Access

For Microsoft-heavy environments, Azure AD Conditional Access with Windows Remote Desktop eliminates the third-party remote access tool entirely. Conditional Access evaluates: user identity (MFA required), device compliance (Intune enrollment, disk encryption, current patches, running antivirus), location (known office networks or VPN), and risk score (sign-in risk, user risk from Azure AD Identity Protection) before allowing the RDP connection. Every evaluation is logged in Azure AD audit logs. This approach trades the proprietary attack surface of AnyDesk or ScreenConnect for Microsoft's security posture — a significant reduction in third-party risk.

Evaluating Alternative RMM Platforms

If replacing ScreenConnect with another RMM tool, evaluate security posture explicitly rather than just features. Key evaluation criteria: current SOC 2 Type II certification (not in process — current), active bug bounty program, documented vulnerability disclosure policy, patching SLA for critical vulnerabilities, and incident history (how did they handle past vulnerabilities). Platforms worth evaluating include NinjaRMM (SOC 2 certified, active security program), Atera, Datto RMM, and Syncro. No RMM platform is perfectly secure — the quality of the vendor's security program predicts how they will behave when the next vulnerability is discovered.

The Core Principles Applied to Remote Access

Zero trust for remote access means: verify every user identity explicitly with phishing-resistant MFA, verify every device's health before granting access, grant access only to the specific resource needed for the specific task, log and monitor every session continuously. In practice, this translates to:

• Identity: FIDO2 hardware key or biometric MFA, with every session associated with a named individual rather than a shared account
• Device: Conditional Access policies verifying enrollment, disk encryption, EDR presence, and patch compliance before the connection is established
• Least privilege: Network segmentation and application-layer access controls that limit session access to only the resources needed — a support session for a printer issue does not grant access to the file server
• Continuous monitoring: Session recording, behavioral anomaly detection, and automatic session termination on risk signal detection

ThreatLocker as the Enforcement Layer

ThreatLocker's Zero Trust platform, which LayerLogix deploys for clients across Greater Houston, implements these principles at the endpoint level through application allowlisting, RingFencing, and network control policies. For remote access tools specifically, ThreatLocker allows AnyDesk to run while preventing it from performing the actions that make it useful to attackers — launching command interpreters, modifying system configurations, accessing sensitive file paths, or establishing connections to non-whitelisted network destinations.

This approach — allowlist the tool, RingFence its behavior — provides protection that is independent of whether the tool itself is compromised. Even if an attacker establishes a legitimate AnyDesk session using stolen credentials, ThreatLocker's policy prevents them from doing anything beyond what the policy explicitly permits. The attacker can see the screen but cannot execute the attack chain that converts session access into ransomware deployment.

Why Written Policy Matters

Security controls without documentation are implementation details, not a security program. A written remote access security policy serves three purposes: it provides the operational baseline for compliance measurement, it provides the evidence of reasonable care for regulators and insurers after an incident, and it creates clear expectations for employees, vendors, and MSPs about what is and is not permitted.

Core Policy Clauses

Authorized tools: List the specific remote access tools approved for use. Any tool not on the list requires written approval before installation. Quarterly scans will identify and remediate unauthorized installations. Unauthorized remote access tools constitute a policy violation subject to disciplinary action.

Authentication requirements: All remote access must use multi-factor authentication. Password-only authentication for remote access is prohibited. Shared accounts for remote access are prohibited. Each authorized user must have a uniquely identified account with MFA enrolled.

Vendor access: Third-party vendors and MSPs must use only approved tools, authenticate with MFA, access systems only using named individual accounts (not shared accounts), notify the organization within 24 hours of any security incident affecting their own infrastructure, and provide current SOC 2 attestation annually as a condition of continued access.

Session logging: All remote access sessions to systems containing sensitive data must be logged with session start/end time, connecting user identity, source IP, and system accessed. Logs must be stored external to the endpoint being managed and retained for a minimum of 90 days.

Incident reporting: Any suspected credential compromise or unauthorized remote access must be reported immediately by phone to [designated contact]. Remote access privileges for the affected account are suspended pending investigation.

---

Continue reading:

• Part 1: The AnyDesk and ConnectWise Breach — What Actually Happened — Complete breach narrative, CVE technical details, ransomware group activity, and real-world incident walkthrough.
• Part 3: Remote Access Compromise — Prevention, Remediation, and the Risk of Data Loss — Incident response, safe remediation sequencing, what gets embedded in compromised systems, compliance implications, and cyber insurance guidance.

Schedule a free remote access security assessment for your Houston business — no obligation.

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