Blog Post

Threat Hunting for Verkada Cameras

Whenever news of a breach like the one reported last week that affected Verkada cameras is reported, security analysts must quickly go on a threat hunting expedition to answer questions such as:

  • Do we have any Verkada cameras on our network?
  • Did any unauthorized remote access occur as a result of the breach? and,
  • If unauthorized access did occur, what exactly happened?

Unfortunately, this can be easier said than done, since devices like these are often untracked in asset databases and are typically unmanageable through endpoint and log-based security solutions like endpoint detection and response (EDR) and security information and event management (SIEM) technologies.

Background

Zero-trust architecture should ensure that network-enabled cameras don’t have access to the rest of the corporate network. There might be exceptions for local video streaming that would make this difficult to manage. In reality though this is rarely achieved for every network application.

If your Verkada cameras are on an isolated vlan that only allows outbound access to *.control.verkada.com, pat yourself on the back! Your Zero Trust project paid off. Make sure you tout this achievement to upper management…

For everyone else, you need to answer questions above.

The Real Threat Hunt

I’m going to demonstrate how I would do this very quickly using Awake Security.

Determine if you have Verkada cameras on your network

A quick search of verkada.com on Awake will take me to the EntityIQ Domain Profile. This has precomputed answers to most of the context I’m looking for. Answers to common questions include:

  • How many devices in my network are associated with the domain in question?
  • When was the domain first seen in my network?
  • What subdomains were accessed and by how many devices?

I can see that 47 devices on my network are associated with Verkada.com. How many of those are cameras? An easy way to pare down this list would be to filter on IOT device types using one of the built in skills within the Awake Security Platform. Another option is to review Verkada’s network configuration guide to determine which domains we should expect to see. In this case, *.control.verkada.com is used by the cameras and *.command.verkada.com is used to access the online service from a web browser. In the screenshot below, I have 34 devices that have accessed api.control.verkada.com, I can use that as a starting point to review the activity from all of these devices with a single query. While I’m at it, I’ll probably tag all of these devices with the “verkada-cam” tag for future reference. I can further investigate any device that has interesting traffic.

In the case of a Verkada camera, interesting traffic includes:

  • Traffic from a camera to an external destination other than *.control.verkada.com
  • Traffic from a camera to another device on my network.
  • Traffic to or from a camera that isn’t using TLS on port 443

I can hunt for this traffic using the Awake’s Adversarial Modeling Language or with a visual model builder. Either way, the entire process can be completed in under 5 minutes.

Conclusion

The bottom line is that when faced with breaking news of a breach, the goal is to get answers as quickly as possible. The Awake Security Platform delivers those answers, rather than a bunch of meaningless alerts devoid of context. In a matter of minutes you can identify what exactly your attack surface is and if any of it has been breached.

 

Subscribe!

If you liked what you just read, subscribe to hear about our threat research and security analysis.

Eric DeShetler
Eric DeShetler

Threat Researcher