Turning Camera Surveillance on its Axis

Turning Camera Surveillance on its Axis

Speaker: Noam Moshe, Team Lead and Lead Vulnerability Researcher, Claroty Team82

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=7J7UgLwrxdQ

Reading time: ~7 minutes

Type: Briefing

TL;DR

Claroty Team82 researcher Noam Moshe discovered a pre-authentication remote code execution vulnerability chain in Axis Communications' camera management software — Axis Camera Station and Axis Device Manager. Exploiting an unsafe .NET deserialization flaw via a hidden unauthenticated endpoint in a fallback protocol, an attacker with internet access could compromise any exposed Axis server and pivot to take full control of every camera it manages. Approximately 6,500 internet-facing Axis servers were identified on Shodan and Censys, with nearly 4,000 located in the United States.

Introduction

Axis Communications is one of the world's largest manufacturers of enterprise IP cameras, serving corporations, warehouses, hospitals, schools, and government facilities. Managing a fleet of cameras across multiple locations requires centralized management software and — increasingly — remote access from outside the corporate network. To support this, Axis developed a proprietary protocol called Axis Remoting, which the company's documentation describes as safe to expose to the internet because it is fully encrypted and authenticated.

Moshe's research began when scanning an organization's internet-exposed services and discovering an unfamiliar open service: Axis Remoting. The combination of an esoteric proprietary protocol and a large vendor footprint made it an attractive target. What followed was a deep dive into protocol internals that uncovered a path from zero credentials to root-level execution on cameras inside a target organization's network.

Reverse Engineering the Axis Remoting Protocol

Axis Remoting is a Windows .NET desktop application using a proprietary client-server protocol wrapped in mutual TLS (mTLS). Because the traffic is encrypted, Moshe's first step was setting up a man-in-the-middle mTLS proxy to intercept and inspect plaintext communication between the client and server.

▶ Watch: Protocol Reverse Engineering (06:00)

The unwrapped protocol revealed two phases. First, authentication using NTLMSSP (NTLM challenge-response), which validates that only credentialed Windows domain users can connect. A useful side effect of NTLM authentication: the server leaks its own hostname and domain name in the challenge packet — without requiring any valid credentials from the connecting client.

Once authenticated, the protocol operates as a JSON-based RPC mechanism. Clients can invoke methods on the server's backend using .NET's WCF ServiceContract decorator pattern. This is where the critical flaw appears: when an RPC call passes a complex object rather than a primitive type, the server must deserialize it. Axis chose to use Newtonsoft JSON with TypeNameHandling.Auto — a setting that allows the client to specify the exact .NET class to instantiate on the server's backend. This is a textbook unsafe deserialization vulnerability, and in .NET it leads directly to remote code execution via gadget chains.

From Post-Auth RCE to a Full Pre-Auth Attack Chain

The deserialization vulnerability was confirmed to work, but required authentication — a significant limitation. Moshe could generate malicious payloads using the well-known ysoserial.net tool, and by performing a man-in-the-middle attack (intercepting and modifying a legitimate client's authenticated connection), he could inject the deserialization payload mid-stream to achieve RCE on both the Axis server and the connecting client. However, the goal was fully unauthenticated exploitation.

▶ Watch: Deserialization Exploit and Fallback Protocol Discovery (14:02)

After reaching a dead end on the main Axis Remoting port, Moshe turned to Axis documentation, which noted that if the primary port is inaccessible, a fallback protocol is available — described as "HTTP with AES encryption." That unusual description motivated further investigation.

The fallback protocol is not standard HTTP at all. It uses HTTP as a transport layer but implements raw binary socket communication on top of it. The handshake works as follows: the client sends a GET / request and receives a channel ID; a second connection using that channel ID establishes bidirectional Rx/Tx streams; the endpoints then perform a key exchange using asymmetric cryptography (public key exchange followed by AES key encryption), after which all subsequent messages are AES-encrypted. Despite the custom encryption scheme, the underlying payload is still serialized JSON Axis Remoting packets — meaning the same deserialization RCE vulnerability applies.

The authentication on the fallback HTTP server was configured as "negotiate" (Kerberos or NTLM) on all routes — with one exception: the endpoint /_/ was configured to allow anonymous access. This hidden endpoint accepted unauthenticated connections, allowed the full key exchange to complete, and then passed traffic into the Axis Remoting RPC layer. Combined with the deserialization flaw, this gave fully unauthenticated remote code execution on any Axis Camera Station or Axis Device Manager server exposed to the internet.

Pivoting to the Cameras

Controlling the Axis management server is only the first step. Axis cameras are Linux-based devices running Axis OS, and they support installing arbitrary packages — signed or unsigned — through the Device Manager admin interface.

▶ Watch: Camera Pivot via Package Installation (12:01)

By crafting a malicious ACAP (Axis Camera Application Platform) package containing a reverse shell payload and pushing it via Device Manager to all managed cameras, the researcher achieved code execution on every camera in the target fleet. The cameras themselves did not require patching — the package installation mechanism is a legitimate feature of the platform that happens to be weaponizable once the server is compromised.

The full attack chain: exploit the /_/ auth bypass → complete the key exchange → send a ysoserial.net deserialization payload → gain RCE on the Axis server → use Device Manager to push a malicious package → achieve a reverse shell on every managed camera.

Scale and Impact

A Shodan and Censys search for internet-facing Axis Remoting servers identified approximately 6,500 exposed instances globally, with close to 4,000 in the United States alone. Querying these servers for the NTLMSSP challenge (which leaks hostname and domain without credentials) revealed that exposed servers belong to a diverse set of organizations: educational institutions, medical facilities, government entities, and large corporations.

▶ Watch: Internet Exposure Analysis (20:03)

Two factors explain the large number of exposed servers. First, ongoing bans of Chinese IP camera vendors in the US and European markets have consolidated demand around Western suppliers like Axis, reducing the diversity of available options. Second, the protocol's "fully encrypted and authenticated" marketing language led administrators to believe exposure was safe — a false assurance that conflated encryption with security.

Moshe and Claroty Team82 conducted coordinated disclosure with Axis Communications. Axis responded positively, notified its customer base directly, and ensured that all affected users received prominent update prompts. Patches for both vulnerabilities have been available for several months.

Notable Quotes

"When I see a service that is esoteric and unknown, usually that's my goal to search vulnerabilities in — and this was what led me to my research." — Noam Moshe, 02:00

"The client fully controls what is the class that is created on the server's backend. This is super dangerous because this is a very classic deserialization vulnerability where the client can create arbitrary classes in the server's memory space — and in .NET, this immediately leads to remote code execution." — Noam Moshe, 10:01

"People often think that whatever is encrypted is secure. However, this is obviously not the case." — Noam Moshe, 22:03

"We need to make sure we are patching, we are staying up to date, and of course, we are not exposing servers that should not be exposed to the internet." — Noam Moshe, 24:03

Key Takeaways

• Proprietary "secure" protocols are not necessarily safe to expose to the internet. Axis Remoting's mTLS and NTLM authentication provided strong perimeter security on the primary port, but a fallback protocol with a hidden unauthenticated endpoint bypassed both entirely.
• TypeNameHandling.Auto in Newtonsoft JSON is a well-known RCE vector. Any .NET application that accepts remote input and deserializes it with type-name handling enabled should be treated as vulnerable until proven otherwise.
• Encryption and authentication are necessary but not sufficient. The fallback protocol implemented a custom encrypted channel but still passed untrusted data into an unsafe deserializer. Encryption protects data in transit — it does not protect the application at the endpoint.
• Management plane compromise enables full fleet takeover. Once an attacker controls the Axis server, they can leverage legitimate platform features (package installation) to implant code on every camera. Network segmentation between management servers and cameras is critical.
• Patch immediately and audit internet exposure. Organizations running Axis Camera Station or Axis Device Manager should confirm they are running patched versions and audit firewall rules to ensure Axis Remoting ports are not exposed to the public internet.

Slides

No slides PDF was available for this talk.