Team82 has disclosed four vulnerabilities in Axis Communications’ popular line of video surveillance products. Axis published an urgent advisory.
The vulnerabilities could expose thousands of organizations to attack.
Team82 developed an exploit chain specifically targeting vulnerabilities in Axis Communications’ proprietary Axis.Remoting communication protocol.
The attack results in pre-authentication remote code execution on Axis Device Manager, a server used to configure and manage fleets of cameras, and the Axis Camera Station, client software used to view camera feeds.
Furthermore, using internet scans of exposed Axis.Remoting services, an attacker can enumerate vulnerable servers and clients, and carry out granular, highly targeted attacks.
Team82 wishes to acknowledge Axis Communications’ quick response to our disclosure. They accepted our disclosure report and worked on the patches and updates in a timely fashion.
Digital surveillance is the cornerstone of modern facilities security, with video system deployments guarding enterprises, airports, schools, and government agencies. While they provide physical security teams with a view of activity, like in any connected infrastructure that protection can be undone by a determined threat actor.
Team82 recently uncovered vulnerabilities in the proprietary Axis.Remoting protocol of popular Swedish vendor, Axis Communications, and developed an exploit chain that can be used to attack both the server and client sides of its deployments. Furthermore, using well-known internet scans, devices and services using the vulnerable protocol can be enumerated. The scans can then be used to pinpoint specific target organizations that may be vulnerable.
Attackers can leverage these exploit chains to access the centralized Axis Device Manager server used by organizations to manage their fleets of Axis devices, as well as the Axis Camera Station, software allowing end-users to access and consume camera feeds in a centralized location. Successful exploits give attackers system-level access on the internal network and the ability to control each of the cameras within a specific deployment. Feeds can be hijacked, watched, and/or shut down. Attackers can exploit these security issues to bypass authentication to the cameras and gain pre-authentication remote code execution on the devices.
Team82 privately disclosed four vulnerabilities we uncovered to Axis Communications, which promptly issued patches in updates for:
Axis Camera Station Pro 6.9
Axis Camera Station 5.58
Axis Device Manager 5.32
Axis said in an advisory published this month that it has no knowledge of public exploits of any of these issues.
As of this publication, we discovered more than 6,500 servers exposing this protocol and its services to the internet, more than half of those in the United States. Each of these servers could potentially manage hundreds or thousands of individual cameras. Given current bans on Chinese technology in many corners of the world, an organization’s choice of vendors has become somewhat limited, putting more emphasis on the protection of platforms available for these deployments.
Axis Communications, a Swedish company, is a major player in the physical security space, known for its high-end IP cameras, access control systems, and audio devices. Axis IP cameras are used in many enterprises globally, including government agencies, educational institutions, and Fortune 500 companies.
Many organizations with Axis camera deployments have a significant number of devices - sometimes across multiple sites - that they must manage. Directly connecting to each one is not feasible; Axis, however, offers two crucial services to oversee its cameras: Axis Device Manager (ADM) and Axis Camera Station.
Axis Device Manager (ADM) is its solution for managing a fleet of cameras using a centralized service. Using this software, one server can connect and control multiple cameras in different locations and networks. Using ADM, an administrator can discover and configure cameras, control their settings, configurations, and firmware version.
Axis Camera Station acts as a network video recorder-like (NVR) software, allowing users to access a matrix of cameras and view their feeds. Through the Axis Camera Station, users are able to discover and access their cameras, enabling video surveillance.
Both servers are built and installed on Windows machines, and are written in .NET. In order to connect to the servers, Axis offers a client application, allowing users to connect remotely to the server installation and control their equipment.
In order to allow the client application to communicate with the servers, Axis implements a proprietary protocol called Axis.Remoting (not to be confused with their cloud service called Axis Secure Remote Access), which enables endpoints to communicate with one another in a secure manner. In our research, we took apart the Axis.Remoting protocol, and uncovered several vulnerabilities that if exploited could enable attackers to execute arbitrary code on Axis server installations and client applications.
Our first goal was to understand the Axis.Remoting protocol. However, we discovered as we sniffed communication over the network that the protocol is wrapped in Transport Layer Security (TLS) encryption.
To unwrap TLS, we created a simple setup with our TLS server that received connections from the Axis client, unwrapped the TLS encryption in order to read the data being sent, and forward the request to a real Axis server using a new TLS connection. This enabled us to view the cleartext data being sent by the client and server, while still having a valid connection.
Once our man-in-the-middle TLS server was set up, we discovered that Axis requires a mTLS connection for a valid connection, meaning both the client and server must present a certificate to identify themselves. In order to support that, we added mTLS to the MiTM server, and that allowed us to dissect clear-text packets of the Axis.Remoting communication protocol.
Let’s examine what this reveals within the Axis.Remoting protocol:
User-Agent: The first packet sent contains the user-agent: Axis.Remoting. This is sent in order to validate that the connecting client is actually an Axis client. The server expects the client to send it, and if it is not sent, the connection is rejected.
NTLMSSP: After the first packet, an NTLMSSP challenge and response is sent between the server and client. NTLMSSP is a WIndows authentication protocol, used to authenticate users in many Windows environments. This means that in order to connect to an Axis server, a client must have credentials to the host machine/Active Directory.
Hostname: Inside the NTLMSSP, we can see the workgroup/hostname of the server (in this case: Claroty\MyHostname).
Request/Response: a JSON-based object, containing all information about the request/response.
Service::Method: A pair in every request, telling the server which functionality the client wishes to execute. Using this, the client is able to invoke remote functionality on the server.
However, since the Axis.Remoting protocol uses self-signed certificates—and does not actually validate each side of the connection—it is possible for attackers to MiTM and impersonate each side in a valid Axis.Remoting connection. This enables an attacker to decrypt Axis.Remoting requests/responses, and see the communication going on behind the scenes.
Furthermore, since Axis.Remoting relies on NTLMSSP authentication, and does not utilize any HMAC/message signing, a very common pass-the-hash vulnerability exists in the protocol. By simply passing an NTLM challenge to a legitimate client, and returning the server with the valid response from the client, an attacker can actually "authenticate" using another client to a server. Because no message signing exists in Axis.Remoting, the attacker could alter each request/response as they choose, allowing them to perform arbitrary actions.
After connecting via mTLS and performing an NTLMSSP authentication, the Axis.Remoting protocol relies on JSON-based communications with Service::Method pairs to invoke functionality on the server; one example is VersionFacade::get_ProductVersion. This is actually a common method of Remote Procedure Call (RPC) between computers, allowing clients to invoke functionality on remote servers.
But how is this done behind the scenes?
The answer is once again a common practice in .NET programming: ServiceContract. ServiceContract is a .NET pattern that defines how remote functionality is exposed. It is essentially an interface agreement between a server and clients, a declaration of which methods exist, what arguments they take, and what data types are expected and returned.
However, what happens whenever a contract’s function receives a more complicated type of argument? Instead of receiving primitives like numbers and strings, some functions receive complicated objects as parameters.
As we can see, in the case of the ServiceContract SessionFacade::LogOnAsync, an object is received as the parameter, ClientInfomrationDto. This object is composed of multiple primitive fields, including strings and numbers, and potentially other objects, below.
Whenever a function receives a parameter that is non-primitive, some form of serialization must occur, while the client sends strings and numbers, the server itself constructs the objects needed to call the function. This process is called deserialization, where the server takes the user input and constructs an object out of it.
After understanding that some deserialization must occur in the Axis.Remoting protocol, our next goal was to understand how it is done. After some time, we reached this code section:
As we can see, the server takes the user-input JSON string, and converts it to the needed object. However, after further examination, we discovered this code that creates the deserializer:
Here, we see a very dangerous piece of code: the JSON serializer is created using the TypeNameHandling.Auto settings. This setting enables the serializer to create objects of dynamic types, allowing the user to declare what object type they’re sending. This is done by including a $type field in the JSON used for deserialization, informing the serializer what type should be created.
While this feature enables great modularity, it also introduces huge risks because it enables users (and attackers) to create arbitrary objects on the server. In .NET, this is called a deserialization vulnerability, and it enables attackers to create objects that will lead to direct code execution whenever they are deserialized. So, to test this vulnerability we used the amazing Github repository ysoserial.net to generate a payload that will give us code execution, and we injected it into the Axis.Remoting communication and got remote code execution!
And of course, since the client also uses Axis.Remoting, it is vulnerable to the same flaw as well. This means that a malicious client can execute code on the Axis server, and a malicious server can execute code on the client. This can be achieved via the MiTM procedure and pass-the-challenge mechanism, as disclosed in vulnerability CVE-2025-30024, giving a MiTM attacker the ability to execute code on the client and server if the client tries to initiate a connection.
At this point, we had full remote code execution on the Axis clients and servers, and by abusing a MiTM attack scenario and forwarding a legitimate user’s request to the server, we can execute code on them both.
While this is a legitimate attack, it wasn’t yet a preauth RCE vulnerability. This meant that in order for an attacker to actually exploit this vulnerability, they would need to fulfil a set of pre-requisites, including a user connecting to their MiTM server. This was when we shifted our focus to other legacy protocols used by Axis services, giving us unexpected results.
We started exploring other options for bypassing authentication, and that was when we discovered a document released by Axis dictating the different ports used for their services for firewall policy configurations:
When reading the fallback protocols clients use if connection via TCP/55754 (the main Axis.Remoting protocol) fails, we found a weird description: HTTP with AES encryption.
At this point, we tried accessing this port. Since the documentation said it was an HTTP service, we tried using our browser, and immediately were greeted with an authentication form (the default authentication form when the server replies with the authentication header):
Even after we inserted valid credentials, we noticed that the server sends our browser weird binary-like responses, so we reached the conclusion that this port was not used for real HTTP-like connections.
After a lot of time trying to figure out this protocol, we discovered that behind the scenes, Axis implemented a binary stateful network protocol over HTTP. Unlike regular HTTP connections, which are stateless and are immediately closed after one request, Axis opens two separate communication channels over the HTTP protocol, and sends messages over them indefinitely until the connection is closed. This way, the client and server have two communication channels they can send messages over, one for receiving and one for sending messages, similar to receive line (RX) and transmit line (TX) in electronics.
The actual full protocol used to initiate this connection is quite cumbersome, but let’s see a brief explanation of the steps:
The client sends a GET / request to the server, with valid credentials
The server replies to the client with a unique channelID. This connection is kept open, and will be used by the client to receive responses from the server from now on.
The client sends a GET /channelID with the channelID they received, opening a new channel between the client and server. From now on, whenever the client wants to send a message to the server, they will use this connection.
Both the client and server send their public key to the other side.
Each side generates a random AES key and encrypts it using the other side’s public key. They then send the encrypted key to the other side, exchanging keys.
After exchanging AES keys, every sequential message will be encrypted with the other side’s AES key.
We researched the protocol and realized that Axis essentially built a raw binary socket over HTTP, with two channels for RX and TX for communications. On top of the channel, Axis implemented AES encryption and a key-exchange mechanism using asymmetric encryption (RSA private/public key encryption). After initiating the communication channels, both sides communicate with one another using the Axis.Remoting JSON-based protocol.
After having a good understanding of the HTTP-flavor of Axis.Remoting, we moved on to see how the authentication is enforced on the server side. We soon enough identified where it is enforced, and where the required authentication scheme for the HTTP endpoint was set up as AuthenticationSchemas.Negotiate.
Microsoft’s documentation explains the Negotiate authentication scheme requires the client to authenticate using either Kerberos or NTLM as a fallback, meaning that the client must have a valid user for the server’s host machine.
This meant that on the main endpoint of the HTTP server (mounted to /), each request had to first pass an authentication check. However, after digging deeper, we discovered an additional HTTP endpoint that was not set with the AuthenticationScheme.Negotiate, and this endpoint started with _/.
As we can see, this “hidden” endpoint was not set with the credentials requirement, but instead allows for Anonymous authentication, supplying no valid credentials.
Using this endpoint, it is possible for attackers to start talking to Axis services using the Axis.Remoting protocol, and exploit other vulnerabilities (for example, CVE-2025-30023), giving attackers full pre-auth RCE on Axis services.
We now have access to all the cameras’ surveillance feed, but can we hack the cameras too?
After achieving preauth RCE on Axis services, the next obvious step was to use the server to take over the camera fleet it manages. Because the main functionality of the server is to manage and control the cameras, this is actually quite easy and actually an intended use-case for the server.
To move laterally from an Axis server to the camera fleet it manages, we chose to use Axis Packages. In order to allow administrators to add functionality to their cameras, Axis enables users to install “plugins” on their cameras. This is done by either downloading an official Axis package, downloading a third-party package, or developing your own using the Axis SDK. Luckily for us, Axis implemented a great SDK for developers to develop their own Axis packages, called ACAP Native SDK.
Using this SDK, we can build a simple backdoor package that will give us code execution on a camera once it is installed. Then, all we need to do is to install our malicious package on the cameras through the ADM/Camera Station, giving us code execution on all the cameras it manages.
After finishing our vulnerability research, uncovering preauth RCE vulnerability on Axis services, we wanted to understand who might be affected by it. Our vulnerabilities require network access to services listening for Axis.Remoting communication, so theoretically if no one exposes their servers, no one will be affected. This, however, could not be further from the case.
Using Internet scanning services like Censys and Shodan, we were able to identify thousands of Axis Device Managers (ADM) and Axis Camera Stations exposed to the internet and exposing their Axis.Remoting services. In addition, because Axis is a major brand used by big corporations around the world, many of these servers are owned by major companies, government institutions, medical and educational facilities etc.
As we can see, most of the servers that expose Axis.Remoting are located in the United States (almost 4,000), each being a potential target for the vulnerabilities we disclosed to Axis.
To make matters worse, we need to remember that the Axis.Remoting protocol uses NTLMSSP challenge-and-response as part of the client-server handshake. As we saw above, this contains a lot of sensitive information about the server that hosts the Axis application, including the hostname of the computer as well as any active-directory domain it's connected to.
As we can see in green, each connection to an Axis.Remoting server will leak the hostname and domain information of the hosting server (in this case - MyHostname\Claroty). This means that by connecting to a server, it is possible to leak a lot of information about the organization that owns it. This creates a situation in which attackers can pinpoint specific targets by first leaking the associated domain-name information of the Axis server.
The risks associated with these vulnerabilities uncovered by Team82 can put thousands of organizations and tens of thousands of cameras in the crosshairs of attackers. Our exploit chain allows us to target the proprietary Axis.Remoting protocol, bypass authentication in order to access either the servers managing fleets of cameras or the cameras themselves.
From there, an attacker could remotely execute code on the device pre-authentication, an ideal scenario for a malicious actor wishing to view a camera feed, shut down cameras, or use their network access to execute code.
Furthermore, more than 6,500 instances of services with the Axis-Remoting protocol exposed to the internet were discovered. An attacker can enumerate exposed servers and devices, and get granular with their selection of targets.
Axis Communication has patched their devices and urges users to update to current versions of ADM and ACS.
Team82 wishes to acknowledge Axis Communications’ quick response to our disclosure. They accepted our disclosure report and worked on the patches and updates in a timely fashion.
The AXIS Camera Station Server had a flaw that allowed to bypass authentication that is normally required.
To Axis’ knowledge, no known exploits exist publicly as of today and Axis is not aware that this has been exploited. Axis will not provide more detailed information about the vulnerability. We appreciate the efforts of security researchers and ethical hackers on improving security in Axis products, solutions, and services.
Axis has released a patch for this flaw with the following versions:
CVSS v3: 5.3
The communication protocol used between client and server had a flaw that could lead to an authenticated user performing a remote code execution attack.
To Axis’ knowledge, no known exploits exist publicly as of today and Axis is not aware that this has been exploited. Axis will not provide more detailed information about the vulnerability.
Axis has released a patch for this flaw with the following versions:
CVSS v3: 9.0
The communication protocol used between client and server had a flaw that could be leveraged to execute a man in the middle attack.
To Axis’ knowledge, no known exploits exist publicly as of today and Axis is not aware that this has been exploited. Axis will not provide more detailed information about the vulnerability.
Axis has released a patch for this flaw with the following version:
CVSS v3: 6.8
The communication protocol used between the server process and the service control had a flaw that could lead to a local privilege escalation.
To Axis’ knowledge, no known exploits exist publicly as of today and Axis is not aware that this has been exploited. Axis will not provide more detailed information about the vulnerability.
Axis has released a patch for this flaw with the following version:
CVSS v3: 4.8
