Cloud
A Cascade of Insecure Architectures: Axis Plugin Design Flaw Expose Select Autodesk Revit Users to Supply Chain Risk
We discovered Azure Storage Account credentials exposed in Axis Communications’ Autodesk Revit plugin, allowing unauthorized modification of cloud-hosted files. This exposure, combined with vulnerabilities in Autodesk Revit, could enable supply-chain attacks targeting end users.
Save to Folio
Key Takeaways
- Trend™ Research came across unintended exposure of cloud credentials of Azure Storage Accounts belonging to Axis Communications, a vendor dealing in network cameras, access control, and network audio devices for the physical security and video surveillance industries. The credentials were found in signed DLLs belonging to a customer-facing plugin created for usage with Autodesk® Revit®.
- The plugin’s MSI installer contained .NET DLLs that had Storage Account credentials including access keys and SAS tokens. The exposure of these credentials could allow unauthorized read and write access to three of the vendor’s storage accounts. The accounts contain MSI installers and Autodesk Revit architectural model files—extension Revit Family Architecture (RFA)–potentially distributed to other customers.
- Trend Zero Day Initiative™ (ZDI) has discovered multiple remote code execution vulnerabilities in Autodesk Revit that could be triggered by importing a malicious RFA file. Thus, attackers could mount a supply-chain attack by uploading crafted RFA files to the Axis storage account, achieving a mass compromise of Axis Communications customers consisting of Autodesk Revit users.
- Axis Communications confirmed that there has been no unauthorized access to their cloud storage, nor have there been attacks and compromises related to the reported vulnerabilities. They have taken necessary steps to address the issue, with the current available version (25.3.718) resolving all reported vulnerabilities.
In July 2024, we uncovered Azure Storage Account credentials embedded within signed DLLs distributed as part of a plugin for Autodesk® Revit®, a widely used building information modelling (BIM) software. The accounts belonged to Axis Communications, a Swedish multinational company that specializes in network video solutions and surveillance technology, offering IP cameras, access control systems, audio equipment, and video analytics software for various commercial and public safety applications. Trend Zero Day Initiative™ (ZDI) has reported these findings to Axis Communications as ZDI-24-1181, initiating an exchange of fixes and additional reports over the succeeding months—ZDI-24-1328 and ZDI-24-1329 in October 2024, and ZDI-25-858 in March 2025.
In this blog entry, we outline where this exposure lies, revisit the process that finally led to a fix, and touch on exploitable RCE vulnerabilities in the Autodesk Revit software to get a scope of the potential impact and risks involved in such a scenario.
Cloud credential exposure in AXIS plugin
On July 8, 2024, one of our VirusTotal rules for Azure Shared Access Signature (SAS) tokens detected a digitally signed DLL named “AzureBlobRestAPI.dll” issued to “AEC Advanced Engineering Computation Aktiebolag,” as seen in Figure 1.
The DLL was signed by AEC AB, an Autodesk partner that consults customers about AutoCAD and Revit platforms. Exposed credentials in signed DLLs is an uncommon sighting, which is why we decided to examine them further.
We found cleartext Azure SAS token and shared access key pairs for two Azure storage accounts under the names “axisfiles” and “axiscontentfiles” in a private method “internalSetEnvironment” of the class “AzureBlobRestAPI.DataTypes.Classes.Global.” These names can be seen in Figure 2.
The credentials turned out to be valid. As a result, they allowed a user to take control of the two storage accounts – from configuration to read/write access to the storage account artifacts. When we examined and assessed the impact, the storage accounts contained the following:
- MSI installers for AXIS Plugin for Autodesk Revit
A few MSI installers were found in a container named “installs.” They were installers for a plugin named “AXIS Plugin for Autodesk Revit” that is used with the Autodesk Revit software.
Autodesk Revit is 3D modeling software used for architecture, structural engineering, and numerous other aspects of building design. Using the plugin, customers can browse Axis product models and download associated modeling data for inclusion in Revit building models. The plugin was intended to be made available to Axis customers only.
We found the DLL containing the credentials in version 25.3.708. Every user who had the AXIS Plugin for Autodesk Revit installed had the DLL containing credentials on their systems, based on the MSI installers found in the storage account.
- Autodesk RFA files
Autodesk RFA is a proprietary file format used with Autodesk Revit for creating 3D models known as families. A family is a collection of elements with identical usage, common parameters, and similar geometry. These files are used with Autodesk Revit to examine models of products. The storage account contained the RFA files for various Axis products, such as security cameras and radars, as listed on their website.
Exchange of ZDI reports and vendor fixes
As the credentials allowed potentially unintended privileged access to the storage accounts, we immediately reported our findings to Axis Communications as ZDI-24-1181. This started the first of a series of exchanges between us and the vendor, as they arrived at a final fix for the issue.
First vendor fix
As a fix, the vendor released a new version 25.3.710 of the plugin. In this new version they obfuscated the credentials in the new plugin, possibly using Eazfuscator. However, this measure was far from enough, as credentials could still be de-obfuscated using publicly available tools like de4dot. We demonstrate this in Figure 9.
In addition, a connection string for a storage account named “axisapphelpfiles” was found in a DLL “AxisAddin.v25.3.dll” dropped by the MSI. Connection strings typically contain authentication details, endpoints, and optional configuration parameters.
This DLL is used in the user interface when the plugin is loaded on Autodesk Revit. This storage account contained web resources consisting of HTML pages and static assets used in the “Help” pages of the plugin.
The credentials for the storage account “axisfiles” were invalidated. However, the access key for the storage account “axiscontentfiles” was not. This means that the newly released version is not a successful patch for the issue reported in ZDI-24-1181. Accordingly, we filed a new bug report.
Obfuscation often helps evade static scanners that look for well-defined patterns in cleartext. However, motivated threat actors would still be able to obtain the credentials trivially. For this reason, we advised the vendor that obfuscation alone would not address the issue.
Instead, the vendor could use a least-permissive credential pair such as a read-only SAS token to let only authorized customers access RFA files, images, plugins, etc. End users should not be able to modify files on the vendor’s storage account or abuse the vendor’s storage for unauthorized access/storage, but with the privilege of the credentials that we found, all these were possible. Thus, we reported our findings as ZDI-24-1328 and ZDI-24-1329 with the recommendations we have described.
Second vendor fix
In response, the vendor released a new version (25.3.711) of the plugin. They removed the storage account’s access key altogether and created a new SAS token—still obfuscated—but with no “write” privileges. This was a great improvement compared to the vendor’s first response.
However, although the changes seemed to fix the issue, the SAS tokens in version 25.3.711 could still be used to list and read the binary large objects (blobs) stored in the containers of the storage account. One such blob container was named “installs,” which contained the previous releases of AXIS Plugin for Autodesk Revit MSI installers, including the MSI installer for version 25.3.710 reported earlier. This in turn contained valid unrotated credentials for the storage account “axiscontentfiles” first found in version 25.3.710 as ZDI-24-1328.
Hence, using the lesser privileged SAS tokens from version 25.3.711, an attacker could still find the overly permissive credentials from the previous releases of the plugin to gain complete access to the storage account once more. We reported our findings as ZDI-25-858 leading to the vendor revoking the storage account’s access key.
This series of exchanges with the vendor shows that even mature companies using cloud services offered by third party providers may, at times, not be aware of the potential catastrophic consequences of misuse and exposure of cloud credentials.
Axis Communications has confirmed that the vulnerabilities reported in relation to the Axis Autodesk Revit plugin have been fully patched. The current version (25.3.718), released in March, contains patches that resolve all previously reported issues. Additionally, the vulnerable version (25.3.710), has been removed from their storage, ensuring it can no longer be used to upload or download content. Users must upgrade to version 25.3.711 or later to use these functions. In summary, all issues have been mitigated since version 25.3.711, with subsequent updates leading up to the current version containing only minor and unrelated changes.
The company has also taken proactive steps to notify affected partners and customers. They also noted that the Autodesk Revit plugin is provided only to select partners and is generally not accessible for public use.
Potential supply chain compromise via Autodesk Revit RCE vulnerability
While assessing the possible impact of this set of findings, had there been distribution mechanisms based on the storage accounts, an attacker could potentially deliver malicious MSI installers masquerading as the plugin. Attackers could also tamper with the HTML files that are opened using the AXIS plugin.
As for the Autodesk Revit RFA files, we still had another question left to pursue: How much could an attacker achieve by tampering with the RFA files within the storage account?
The RFA files in the storage account are used by end customers within Autodesk Revit. Vulnerabilities in such file formats often allow potential attackers to gain arbitrary code execution. While examining the RFA parser used in Autodesk Revit, Trend ZDI found multiple vulnerabilities that could be exploited to achieve arbitrary code execution. For a more comprehensive look at these findings, visit the ZDI blog.
Impact: Supply chain attack
Credential leaks in customer-facing infrastructure don't just expose cloud storage — they can be the entry point for a multi-stage supply chain attack. This is not the first time we have seen such a case. In 2023, we reported a similar issue to Microsoft for their tool called PC Manager. Using the exposed tokens, it was possible to gain full control over multiple distribution mechanisms of PC Manager consisting of WinGet packages, an official subdomain, and a Microsoft-owned URL shortener service.
Ultimately, these cases are not just about specific vendors or vulnerabilities – they are strong reminders that in software supply chains, trust must be proactively earned, verified, and continually reassessed. A single misstep in plugin security, credential handling, or file exposure can have cascading consequences. Organizations must realize and fulfill the demands of supply chain security, before attackers and incidents force this realization.
Conclusion and recommendations
This exposure highlights the unforeseen risk stemming from trusted third-party software providers. Signed DLLs within a customer-facing plugin for Autodesk Revit had hard-coded Azure Storage Account credentials. These secrets granted unauthorized read/write access to MSI installers and RFA model files distributed to other customers.
Additionally, the vulnerabilities in Autodesk Revit could result in arbitrary code execution, as customers would use the plugin to download model files from Axis’s storage account. These findings show a potentially dangerous intersection of flaws that could have enabled a full-blown supply chain attack. This case reinforces the following key points:
- Just because DLLs are digitally signed, they are not inherently secure. Trust indicators must be backed by thorough internal review and static analysis throughout the development process.
- Exposure of overly permissive credentials amplifies risk. Following the principle of least privilege can significantly limit the scope of compromise.
- File formats as attack vectors become much more impactful when coupled with scalable distribution mechanisms enabled by widely trusted cloud resources – as we examined in this case.
Credential leaks in customer-facing infrastructure don't just expose cloud storage — they can be the entry point for a multi-stage supply chain attack. This is not the first time we have seen such a case. In 2023, we reported a similar issue to Microsoft for their tool called PC Manager. Using the exposed tokens, it was possible to gain full control over multiple distribution mechanisms of PC Manager consisting of WinGet packages, an official subdomain, and a Microsoft-owned URL shortener service.
Ultimately, these cases are not just about specific vendors or vulnerabilities – they are strong reminders that in software supply chains, trust must be proactively earned, verified, and continually reassessed. A single misstep in plugin security, credential handling, or file exposure can have cascading consequences. Organizations must realize and fulfill the demands of supply chain security, before attackers and incidents force this realization.
Here are several proactive measures we recommend preventing similar cases:
- Integrate a code scanning solution (such as Artifact Scanner within Trend Vision One™ Code Security) into CI/CD pipelines to detect and remediate exposed credentials before release.
- Separate public-facing assets from systems used for distributing software releases to minimize the attack surface.
- Apply defense-in-depth strategies to file format parsers by regularly conducting vulnerability assessments and code reviews.
Here are reactive measures to take if such an exposure has already happened:
- Continuously scan existing and new software releases for embedded credentials to ensure no sensitive information is inadvertently exposed.
- Subject all releases to sandboxing and thorough QA/testing environments prior to public distribution to identify potential security issues.
Trend Solutions
Trend Vision One™ Cloud Risk Management is a continuous assurance tool that provides peace of mind for cloud infrastructure, delivering over 750 automated best practice checks. Cloud Risk Management users can leverage the following Azure Storage Account rules:
- Check for Overly Permissive Stored Access Policies (StorageAccounts-015)
Ensure that Azure Storage shared access signature (SAS) tokens are not using overly permissive access policies. - Allow Shared Access Signature Tokens Over HTTPS Only (StorageAccounts-005)
Ensure that shared access signature (SAS) tokens are allowed only over the HTTPS protocol. - Disable Shared Key Authorization (StorageAccounts-028)Ensure that "Allow storage account key access" setting is disabled to prevent Shared Key authorization.
- Enable Microsoft Entra Authorization By Default (StorageAccounts-030)Ensure that "Default to Microsoft Entra authorization in the Azure portal" setting is enabled for Azure Storage accounts.
- Enable Secure Transfer in Azure Storage (StorageAccounts-001)Ensure that "Secure transfer required" security feature is enabled within your Azure Storage account configuration.
- Regenerate Storage Account Access Keys Periodically (StorageAccounts-002)Regenerate storage account access keys periodically to help keep your storage account secure.
- Enable Logging for Azure Storage Blob Service (StorageAccounts-019)Ensure that storage logging is enabled for the Azure Storage Blob service.
- Check for Publicly Accessible Web Containers (StorageAccounts-016)Ensure that Azure Storage containers created to host static websites aren't publicly accessible.
- Disable Anonymous Access to Storage Accounts with Blob Containers (StorageAccounts-016)Ensure that blob anonymous access is disabled at the storage account level to override any ACL configurations allowing public access.
- Enable Immutable Blob Storage (StorageAccounts-012)Ensure that critical Azure Blob Storage data is protected from accidental deletion or modification.
- Enable Soft Delete for Azure Blob Storage (StorageAccounts-010)Ensure that Soft Delete feature is enabled for your Microsoft Azure Storage blob objects.
- Review Storage Accounts with Static Website Configuration (StorageAccounts-017)Ensure that Azure Storage Accounts with static website configuration are regularly reviewed (informational).
- Disable Public Network Access to Storage Accounts (StorageAccounts-029)Ensure that public network access to Microsoft Azure Storage accounts is disabled in order to enhance security by preventing unauthorized access.
- Disable Anonymous Access to Blob Containers (StorageAccounts-006)Ensures that anonymous access to blob containers is disabled within the Azure Storage account.