In this blogpost I explain how me and my colleagues found two vulnerabilities during one of our Red Team engagements which allowed us to elevate our privileges and lateral move in the client’s network. It explains the vulnerabilities, and defensive and mitigating advice.
It was a Red Team with an assumed compromise scenario where we entered the network through a VPN and had RDP access to one machine. From here we were very limited in the network. It was a small network with no significant misconfigurations in Active Directory, with no possibility to escalate our privileges. The customer did strict network segmentation which limited us from reaching other hosts in the network but a few. We started enumerating the few network shares that we did have access to and this is were it gets interesting. We found the installer for Ivanti Workspace Control 10.5.50.0 and a file called ‘WMDBConn.txt’.
Ivanti Workspace Control is a software solution that centralises the management of user workspaces across various platforms and devices. It allows IT administrators to control applications, user settings, and security policies to ensure consistent user experiences and optimise resource use.
Vulnerability 1 – Recovering Ivanti Workspace Control Agent credentials
Key Takeway: Credentials for Ivanti Workspace Control database can be recovered from a config file.
The file seemed to contain encrypted connection details for the Ivanti Workspace Control agent to connect to the Ivanti Workspace Control server. We downloaded the Ivanti installer from the share and installed the software locally and started looking how the software worked. We eventually discovered that the file res.exe (C:\Program Files (x86)\Ivanti\Workspace Control\svc\res.exe) contains logic to decrypt the connection details. We used dnSpy(ex) to decompile the .NET assembly to readable C# code and to understand the decryption routine.
We copied the relevant sections of the decryption routine to a Visual Studio project and built a decrypter for the connection string that is able to recover the database username and password. In this case the Ivanti agent was configured to directly connect to the Ivanti Database without a relay server, so the credential in here is a MSSQL username and password to connect to the Ivanti Workspace Control database server. The source code for this tool can be found here.
Vulnerability 2 – Escalating to Management Console Access / Improper Authorization
Key Takeway: By having valid Ivanti Workspace Control database credentials and executing a “console lockout reset” one get access to the Management Console. This gives full administrative access to the management console, and can result in full takeover of systems that are running the Ivanti Workspace Control software and connected to this server.
From here on we logged in to the Ivanti database using the decrypted credentials and started looking through the data. Initially we didn’t find much in the data and tables, but looking at the documentation we knew that the access could be powerful since Ivanti Workspace Control allows you to configure a lot of functionality (e.g. change computer settings, execute programs & scripts, etc.). We downloaded the management console for Ivanti Workspace Control (found on the same share we found the WMDBConn.txt) and installed the software locally. When opening the management console it prompts for a connection to the database for storing it’s data. We went through the setup and provided the credentials recovered from WMDBConn.txt. We were excited to see it accepted the credentials and prompted a valid Workspace Control datastore was found. Clicking finish restarts the software where it initializes the software and logs in using specified credentials. At this point the software unfortunately prompted that we have not been granted access to the Workspace Control console and the software exits.
We started looking at the database and where those authorization are stored, so we could maybe give ourselves the needed rights to login. At this point one of our operators came across the following helpful articles from Ivanti:
- Solve a Console lockout
- https://forums.ivanti.com/s/article/The-pwrtech-exe-lockedout-parameter-does-not-accept-Windows-Authentication-credentials?language=en_US (unfortunately now behind login)
We discovered the management console’s pwrtech.exe has a /lockedout parameter that can add our current Windows user account to the Technical manager Administrative Role, thus granting the user full access to the Workspace Control Console. We ran pwrtech.exe with the parameter and had to re-enter the decrypted credentials we recovered from the WMDBConn.txt file. After entering the credentials the software added our windows identity (this was from a local VM, not domain joined) to the Technical manager Administrative Role and we were able to access the management console. From here on we had full access to the management console and for example we were able to create custom scripts that were executed by the connected Ivanti Agents. This effectively means we were able to go from one Ivanti Agent connection file to management console access, to executing (PowerShell) scripts with administrative privilege’s on the Ivanti Agents.
Disclosure Timeline
After we discovered the vulnerabilities during the Red Team we performed a responsible disclosure to Ivanti, notifying them about the issues.
| 24-08-2023 | Initial disclosure to Ivanti |
| 25-08-2023 | Vendor acknowledged the disclosure, started looking into vulnerabilities. |
| 30-08-2023 | Vendor notified us that the vulnerabilities were previously disclosed to them, and they started refactoring to fix the problem. They will keep us up-to-date on mitigating measures. |
| 05-09-2023 | Vendor let us know timelines for fixing these vulnerabilities is unknown. It needs architectural changes. Some mitigation advices is given. |
| 16-01-2024 | I Requested status update of the vulnerabilities. |
| 18-01-2024 | Vendor answered. Still working on fixing the vulnerabilities. |
| 29-01-2024 | Status update by vendor. Still working on long-term fix. |
| 07-05-2025 | I sent another check-in to see if vulnerabilities are fixed and to ask about any CVE’s assigned to them. |
| 09-05-2025 | Vendor answered work is ongoing. Will come back with a more complete update. |
| 14-05-2025 | I ask about the CVE’s again. |
| 14-05-2025 | Vendor answered they do not share CVE’s until shortly before disclosure. Partial fix is done for the first vulnerability (Recovering the Ivanti Workspace Control Agent credentials). Second vulnerabilities is marked as “accepted risk”. |
| 15-05-2025 | I urge them to disclose the CVE’s publicly and publish mitigating advice for the vulnerabilities since it has been almost 2 years since initial disclosure. I notify them of the blogpost. |
| 19-05-2025 | Vendor answered it gets escalated internally. |
| 20-05-2025 | Vendor answered fixing the vulnerabilities means rearchitecting the product which is the reason why no full fix is available. The first vulnerability is partially fixed, but will be fully fixed in a future release. A CVE will be shared publicly shortly before they disclose the issue. Second finding is reviewed internally again, and marked as “no security boundary is broken”. |
Mitigating & Defensive Advice
So far the vendor reported the following mitigating advice:
“One can enable FIPS-mode and/or don’t use the dynamic datastore setup through DHCP for example. But this all depends on the current setup and configuration of the customer. But this all depends on the current setup and configuration of the customer. To make sure they are safe I would advise them to reach out to the support desk or directly to me.”
Unfortunately I don’t have a working Ivanti Workspace Control instance to trial and test with, but the following general advice can be given:
- Make sure you don’t expose the WMDBConn.txt configuration file on (public) shares in your network, although I expect there are more ways to recover these credentials. Each Ivanti Workspace Control client install needs these credentials to connect to the server, so these credentials would be likely stored in a way on the client’s system (e.g. registry or config file). This also means you potentially could retrieve these credentials from each Ivanti Workspace Control’s managed system.
- Monitor the Ivanti Workspace Control logs for log-in’s that happen from locations in the network that are not common or with weird (unknown) user accounts. Networks should be segregated into different segments for clients, servers and administrative work, so administrative log-in’s to the management console should only happen from the management segment of the network. Furthermore, the /lockedout parameter of the pwrtech.exe adds our current Windows Username to the “Technical manager Administrative” Role, so it’s worth monitoring this role/ group for changes.
- Make sure your software is up-to-date. Whenever new updates of software (e.g. Ivanti Workspace Control) comes out, it should be installed to fix bugs and security issues. Migrate to other products or solutions when software becomes end-of-life (EOL). Ivanti Workspace Control has been marked end-of-life by end of 2026.
- Make sure you have robust and up-to-date incident response procedures. Defending networks can be challenging, even more so when companies (and networks) grow. Make sure you are ready when a compromise happens and you know how to respond and potential remove an actor from the network.
- Practice what you preach. Regularly asses the security of your network with Risk Based Penetration Tests, Red Teams and Purple Teams. Generally Risk Based Penetration tests can be used to detect as many misconfigurations and vulnerabilities as possible in an internal network or (Azure) Active Directory while also trying to get access to “critical assets” to prove potential impact or risk for the business. During Red Teams a full compromise can be simulated, from gaining initial access to moving towards objectives. This test focusses on testing your maturity. E.g. did you mitigate most vulnerabilities and misconfigurations in your network, and are you able to detect and respond to a malicious actor inside your network. Purple Teaming can be used to repeat certain attacks by the Red Team, so together with the Blue Team defensive and responsive mitigations can be improved.