Technical Keys to the Kingdom: Flaws in ConnectWise's Legacy VA Solution

Vulnerability found by Joey Melo, Senior Consultant at Packetlabs

Co-written with Ian Lin, Director of Research and Development at Packetlabs

Binary exploitation is a highly specialized subset of security research, which is why it is rarely the primary focus during most security assessments. Its techniques are considerably more time-consuming and technically demanding than exploiting more accessible vulnerabilities found in web applications or network infrastructures. In many engagements, targeting Active Directory services or leveraging a fully weaponized SQL injection can yield more reliable access and a more significant overall impact, making those attack vectors more attractive for achieving project objectives.

For security testers, a strong indication that further investigation is warranted is when an application opts to implement a custom password or credential storage mechanism. In several instances across various products, analysts have discovered that binaries responsible for encrypting and decrypting passwords embed a symmetric key—often within legacy network scanning applications. Such is the case with one of ConnectWise’s legacy vulnerability scanning solutions. As a reference, Tenable Nessus, which is another competing vulnerability and network scanning tool, takes a different approach:

Credentials in a Nessus scan or policy are stored in the policies.db file. This file is protected using AES-128 encryption. The key used to encrypt the database is randomly generated and is only readable by the user that performed the scan. For further security, an encryption password (formerly master password) can be specified by using the "K" argument when invoking the Nessus daemon (nessus-service); this requires entering the encryption password (formerly master password) whenever Nessus is restarted.

Packetlabs decided to write a post on this vulnerability because of the risk of MSPs utilizing this tool in a continued effort to scan vulnerabilities. In our exchange with ConnectWise’s technical team, they explained that there was a need at a point in time to develop a command-line utility for authenticated network vulnerability scans using the Joval scan engine. Due to its use case, encryption and file security were handled entirely within the utility.

ConnectWise’s Password Encryption Utility

During a recent OT engagement, IT assets within the plant network were assessed via this utility from a third-party MSP. In this specific scenario, plant workstations appear to have CanPSRemote privileges over the domain controller. Entry-level engineers who work on the site would all technically have read access over the Domain Controller’s Temp directory. This is likely done to quickly retrieve assessment files, keep scripts, maintain ease of access, and installer agents for necessary software.

Although the configuration design of the OT Active Directory isn’t inherently flawed, it does expose files accessible to all plant engineers. Packetlabs consultants discovered a critical security vulnerability in the binary file named ConnectWise-Password-Encryption-Utility.exe, which encrypts domain credentials for the ConnectWise scanner. The problem lies in the encryption key being hardcoded into the executable.

Reverse Engineering the Flaw

During the investigation, a deep dive into the binary code using Ghidra, a reverse engineering tool, quickly revealed an interesting discovery: a function named main.EncryptAES. The presence of this function immediately raised suspicions, as it strongly suggested that the code was designed to perform encryption using the Advanced Encryption Standard (AES). This finding was significant because it hinted at the potential for sensitive data to be encrypted within the application.

Further analysis of the main.EncryptAES function would involve examining its inputs, outputs, and the specific implementation of the AES algorithm. 

During the deeper dive within the Decompile window on Ghidra, it was observed that a crucial memory location (DAT_00585430) was being actively loaded immediately prior to the invocation of the crypto/aes.NewCipher(key) function. This particular sequence suggests that the memory location DAT_00585430 likely holds the cryptographic key that is subsequently utilized by the crypto/aes.NewCipher(key) function to initialize a new AES cipher instance.

That memory region held the hardcoded encryption key, meaning any attacker with access to the binary could extract it and decrypt stored credentials. The identified memory region within the software contained the hardcoded encryption key. This essentially meant that if an attacker could gain access to the binary file, they could easily extract this key. Once the key was obtained, they could then use it to decrypt the CSV input files used for authenticated network scanning.

The consequences of these vulnerabilities were severe. A custom script was developed to extract the decryption key from the application and use it to decrypt the passwords stored within the CSV input files. This unauthorized access to the binary and CSV files and by extension, the decryption key enabled the attacker to obtain cleartext domain administrative credentials. These compromised credentials were then exploited to elevate privileges within the network, ultimately resulting in the attacker gaining the highest level of administrative access.

The Real-World Impact

The problem lies in that any licensed scanner utility binary would still work for this purpose. This level of access would grant the attacker complete control over the entire domain and all its resources (ERP, HMI, SCADA systems). In a relatively locked down and segmented environment became an obscure escalation path that's capable of impacting an entire plant’s process.

This rudimentary script is available on the Packetlabs Github and available for MSPs with this exact use case to replicate.

ConnectWise: A Commitment to Transparency

As a leader in the IT services platform space–and an organization at the forefront of transparency regarding their security measures–ConnectWise’s response has been more than professional and accommodating. 

Their Vulnerability Disclosure Program outlines safe harbor, and they promote research and awareness surrounding the security of their products. They’ve worked very quickly with us to acknowledge and verify that this issue exists in their legacy solution.

This is in addition to their related security commitments, which include:

• Up-to-date security bulletins: A Security Bulletin is used when publicly disclosing security vulnerabilities discovered in ConnectWise offerings. To protect their customers, they do not publicly disclose or confirm security vulnerabilities until they have conducted an analysis of the product and have issued fixes and/or mitigations

• Periodic advisories: ConnectWise provides communications on broader security-related topics that may not be linked to a specific ConnectWise product or vulnerability, but are still of importance to their partner community

• High privacy standards: ConnectWise adheres to strict industry privacy standards and complies with new privacy standards and mandates as they progress. They strive to be as transparent as possible with their data collection and usage practices to provide best-in-class products, services, and web experiences for users

• Regulatory compliance: ConnectWise is routinely and thoroughly audited by independent third-party organizations and government agencies to ensure their products and practices comply with global and regional regulations and standards

• “Secure By Design” policies: Their practices align with the three core principles set forth by the Cybersecurity and Infrastructure Security Agency (CISA), to safeguard their digital ecosystem

As of February 2025, this solution and its associated distribution were officially discontinued, with the license expiring on July 23rd, 2023. Although a previously licensed scanner utility binary may still function at the time of writing, continued use poses both operational and security risks. It’s important to note that this service should no longer be running in modern environments—not only due to the decommissioning of the service itself but also because the expired Joval/Arctic Wolf license renders any legitimate scan attempts ineffective. These remnant components or services highlight the complexity of managing legacy infrastructure and underscore the importance of thorough decommissioning practices. It also emphasizes the need for regular, diligent review of system configurations, provisioning, and automated processes over time. MSPs, system administrators, and network owners should prioritize phasing out this utility and migrating to supported alternatives as part of their security hygiene efforts.

Disclosure Timeline

• January 1st 2025 (Vulnerability Discovery)

• January 4th 2025 (Initial Contact)

• January 4th, 2025 (Private Disclosure)

• February 3rd 2025 (Disclosure Follow-up)

• February 4th 2025 (Disclosure Follow-up)

• May 12th 2025 (Disclosure Follow-up)

• May 19th 2025 (CVE ID Assigned)

• May 22nd 2025 (Technical Blog Published)

Conclusion: Retrospective for Product Teams

• Ditch Hardcoded Keys: Attackers can extract them with static or dynamic analysis, making password decryption trivial. Never store keys in the executable.

• Use Secure Key Storage: Instead of embedding keys, retrieve them securely from a server or a dedicated key management system. This ensures keys are never exposed within the binary itself.

• Make Reverse Engineering Harder: Code obfuscation isn’t a silver bullet, but it raises the bar for attackers. Making it harder to analyze the binary can slow down static analysis and reduce the likelihood of key extraction.

• Implement Dynamic Key Derivation: Rather than using a static, predictable key, derive encryption keys dynamically using user-specific inputs, such as a master password or authentication mechanism. This ensures each encryption key is unique and not hardcoded.