Key Takeaways:
- Encrypted doesn’t mean secure. Weak encryption and static keys within FaciliWorks allow attackers to easily recover plaintext passwords, defeating the purpose of encryption entirely.
- Default credentials magnify impact. FaciliWorks ships with default SQL and application logins that can give attackers immediate administrative access.
- Defense in depth is essential. To mitigate risks, administrators should apply least-privilege permissions and disable default accounts. Software developers and vendors should also enforce proper password hashing and protect application code through obfuscation or binary hardening.
Weak encryption vulnerabilities in enterprise software can expose sensitive credentials even when data appears protected. Netragard researchers identified reversible encryption mechanisms within FaciliWorks that allowed recovery of plaintext credentials through analysis of the application’s code.
Rather than relying on implementation flaws in a single component, this issue stems from how credential protection is handled throughout the application.
FaciliWorks Credential Storage and Encryption Overview
FaciliWorks software is a web-based CMMS (Computerized Maintenance Management System) with an on-prem deployment option generally run on Microsoft’s IIS web server utilizing a Microsoft SQL Server database back-end. The SQL user credentials are stored in a file on disk in an encrypted format on the web server, and the FaciliWorks application user credentials are encrypted within the database.
We’ll demonstrate how an attacker can crack the encryption to expose plaintext credentials, revealing just how vulnerable this data really is.
SQL Credentials Stored in the Web.config file
A web application’s configuration file, typically “web.config” for IIS applications, stores connection strings for any databases the application needs to access. 
This generally means that if an attacker can compromise the configuration file, the SQL credentials are also compromised. FaciliWorks, however, attempts to mitigate this by storing the credentials in an encrypted format.
Analyzing Disassembled DLLs
Looking through the application’s code files on the IIS web server, our team found many DLLs of interest. A quick check confirmed that these were .NET DLLs, which made them suitable for disassembly using popular tools such as dnSpy or JustDecompile. Furthermore, these DLLs were not packed or obfuscated in any way, allowing the disassembled code to be much more easily read and understood than it otherwise should be.
After some digging, we were able to identify the functions responsible for encrypting and decrypting the SQL credentials stored in the “web.config” file. The team also identified the functions responsible for encrypting and decrypting FaciliWorks application user credentials stored within the SQL database. One such example is the DecodePassword function. In both cases, the algorithm utilized is a custom stream-style shift cipher that uses hardcoded per-character keys to decrement ASCII byte values and construct the plaintext string, effectively behaving like a simple repeating-key Vigenère scheme.
Decrypting SQL Credentials
A simple tool was quickly assembled to execute these decryption functions against input strings, and thus successfully recover the plaintext Microsoft SQL Server credentials.
For added confirmation, the decrypted SQL username was checked against the FaciliWorks documentation and found to match the default specified in the setup procedure.
As the FaciliWorks documentation indicates, the SQL user is granted “sysadmin” permissions on the SQL instance. Not only were we able to gain access to the FaciliWorks database, but also to every other database running on the SQL Server instance.
Decrypting Application User Credentials
With direct privileged access to the FaciliWorks SQL database, the encrypted application usernames and passwords used to login to the FaciliWorks web application interface were completely accessible to us. This data is stored in the “SECURITY_USER” table, specifically in the “UserID” and “Password” columns.
As alluded to earlier, the functions for handling application user credentials are different than those which handle the SQL credentials, however they are similar in kind and thus the process for defeating the protection mechanism was identical. By simply extending the decryption tool a bit, all application usernames and passwords in the database were easily decrypted.
As before, referencing the documentation confirmed that some of the decrypted credentials matched the default credentials for the FaciliWorks application.
Conclusion
Armed with so many plaintext passwords, an attacker could quickly pivot further into an environment by using credential replay tactics, password spraying attacks, or using statistical analysis (looking at you, PACK!) to make cracking efforts against captured password hashes much more targeted and effective.
This example exposes critical vulnerabilities, underscoring the urgent need for robust code protection, powerful encryption, proper credential hashing, hardened default deployments, and stronger end-user training to combat password reuse risks.
Scope disclaimer: The findings in this post are based on a specific, older deployment of FaciliWorks observed during a security assessment. We have not evaluated current or supported versions and make no claims about whether the issues described remain present today. This research should not be interpreted as a product‑wide vulnerability advisory; instead, it is intended to highlight common weaknesses in credential protection and encryption design using this instance as a real‑world example.
FAQ
What did the research demonstrate about FaciliWorks encryption?
The assessment showed that FaciliWorks stores both SQL and application credentials using reversible encryption. By examining the underlying code, researchers demonstrated how these credentials could be decrypted—revealing that encryption alone doesn’t necessarily mean the data is secure.
How could attackers take advantage of weak encryption in FaciliWorks?
If an attacker gains access to the FaciliWorks web server or configuration files, they could decrypt the stored SQL credentials. Because the default SQL user often has “sysadmin” rights, this could expose every database on the SQL Server instance, not just the FaciliWorks one. Impact then expands to include compromise of all user FaciliWorks application login credentials within the database which can be decrypted in a similar manner.
What are the real‑world risks of FaciliWorks credential exposure?
Decrypted credentials can be reused in credential replay or password spraying attacks, allowing adversaries to move laterally across systems and expand their level of compromise within the network.
What are the risks of weak encryption?
Weak encryption creates a false sense of security by allowing sensitive data to appear protected while remaining easily reversible. This can lead to exposure of plaintext credentials, including database and application accounts, which attackers can use to gain unauthorized access. If those credentials are highly privileged or reused across systems, the impact expands to privilege escalation, lateral movement, and broader compromise of the environment. In this case, recovering a single SQL credential with elevated permissions enabled access not only to the application database, but to all databases on the SQL Server instance.
