
warning
This article is intended for security specialists operating under a contract; all information provided in it is for educational purposes only. Neither the author nor the Editorial Board can be held liable for any damages caused by improper usage of this publication. Distribution of malware, disruption of systems, and violation of secrecy of correspondence are prosecuted by law.
Pentesting reports often include pictures from security cameras controlled by pentesters.

Such pictures look cool, but what is the impact of such actions? Unlike Watchdogs 2, in real life you cannot hack devices on the basis of camera footage. An attacker could probably gain some information by watching employees walking up and down the hallways and then use this information for social engineering… But frankly speaking, it’s all water under the bridge.
From a pentesting perspective, it’s much more interesting to run a shell on a seized camera: every camera has a small computer inside, and access to it can be useful for an attacker.
Case #1: Default password
I have no doubt that you’ve seen similar login pages on cameras’ web interfaces.

And of course, the first thought is to search Google for default logins and passwords.
info
In some cases, you don’t even need the login and password for a camera to capture an image from it. It could be enough to find the correct RTSP link that is similar to a classic HTTP link and often can be found in the camera documentation. In addition, the nmap
script has been created for this purpose, but so far it doesn’t include all possible link variants.
Imagine that you’re lucky and gained access to the web interface with admin rights. The easiest and fastest thing you can do is check whether you can run SSH or Telnet. In the example below, such a possibility exists.

Let’s try to enable SSH by checking the respective box and clicking “Save”.

Port 22 (TCP) is now available. It’s logical to try to connect to SSH using the same login and password (i.e. credentials for the web interface). Success! Although I must admit, it’s not always the case.

As you can see, this is a BusyBox shell, which significantly limits your options. There are two ways. The first one is to try to escape from BusyBox to a ‘normal’ shell (Bash, Ash, etc.). This approach can potentially bring a greater effect, but it’s too time-consuming for a time-limited pentesting audit.
Alternatively, you can try to use the standard SSH functionality: traffic proxying. In this particular case, you are dealing with a Dropbear SSH server. It’s lightweight and often installed on cameras. For maximum optimization, its traffic proxying functionality should be removed, but many manufacturers leave it, which can be exploited.
To proxy traffic via a camera, let’s try to connect to it over SSH using the following command:
ssh root@IP -D 4444

This command deploys on your system a port with SOCKS5 support, and this port uses SSH to proxy your connection via the target device (in this particular case, a camera). Let’s check whether the connection is working properly.

Even though you were unable to circumvent BusyBox limitations, the main goal has been achieved: you are proxying traffic via the camera. In my pentesting studies, I encountered infrastructures having no access restrictions when they are accessed from the camera network, which is very convenient for hackers.
Case #2: Vulnerability in firmware
Using this case as an example, I will show how to get RCE and perform pivoting on a camera in a situation when access initially wasn’t possible.
Initial conditions in this case are more complicated: you encounter a familiar web interface, try default passwords and a number of other popular passwords – but nothing works, and you cannot log into the admin panel. Time to give up? No way! Let’s search Google for registered vulnerabilities (preferably with ready-made exploits).
I managed to find a bug identified as CVE-2021-36260. Important: this is just an example; when you deal with other hardware, you can get any other sorts of bugs. But I was lucky to immediately find a ready-made exploit.
The impact of exploitation is remote code execution (RCE). Exploitation with ready-made exploits is usually performed in one command.

The script successfully executes, and you get a shell on the camera. In this particular case, it’s fully-functional Ash. You further actions depend only on your imagination. For instance, you can upload a C2 agent to gain a foothold and perform pivoting. The simplest attack vector has already been described above: traffic proxying over SSH.
Case #3: Hardcode in firmware
This time, the situation is more interesting. A firmware function will help you proxy traffic.
You log into the camera’s web interface using basic authentication (the default credentials are correct in this case). Then you check whether it’s possible to run SSH or Telnet… and find out that this is impossible.

You scan ports and see that Telnet is available.

You try to connect to it using the login and password for the web interface… with no success. You don’t give up, search Google and see that the manufacturer says: Telnet is only intended for developers; while ordinary users have nothing to do with it. Accordingly, no passwords are available in the public domain. You could sink into despair, but hackers pentesters aren’t ordinary users! You download the firmware from the manufacturer’s website and examine it.

You try to open the firmware using a regular archiver (e.g. 7-Zip)… and succeed! Surprisingly, the firmware is neither protected in any way, nor encrypted, nor employs a sophisticated file system. Everything is simple and accessible.

Congrats! You gained access to the rootfs file system. It contains the /
directory, which, in turn, contains a file called passwd
. You open it and see the hash of the root
account.

Comment is needless!

Of course, you try to brute-force this hash. The firmware is pretty old (2019), and the chance to brute-force it is quite high. Looking ahead, I can tell you that everything will work out.
Brute-forcing with hashcat:
hashcat -a 0 -m 500 '$1$ct81jPGd$V4mhTmjAOkTwNhnFsIrmt1' /usr/share/wordlists/rockyou.txt

info
Based on this password, I found out that I was dealing with cameras manufactured by a Brovotech factory in China; many manufacturers purchase their products. If you encounter a noname camera during a pentesting audit, the same password might work for you as well.
Let’s try to connect to Telnet using the brute-forced password.

Success! You managed to connect to the camera and get a fully-functional shell. But unlike SSH, Telnet doesn’t enable you to proxy traffic out-of-the-box. Accordingly, you need something else (e.g. SOCKS proxy or C2).
Let’s try the simplest and most common C2 variant: Metasploit with a Meterpreter payload. I have never encountered antiviruses on cameras; so, no need to take precautions.
Generating payload:
msfvenom -p linux/armle/meterpreter/bind_tcp -f elf -o bind

Now you have a binary, but how to upload it to the camera? Netcat is unavailable, curl is unavailable, almost nothing is available… All you can do is send it byte by byte (e.g. using printf
). The payload can be generated as follows:
cat bind | od -An -t o1 -v | tr ' ' '/' | while read line
do echo "printf '$line' >> out.bin" | tr '/' ''done
Here I must thank my colleague S0i37 who helped me to automate all this stuff.
The script executes, you copy its output and paste it on the camera. As a result, you gain a ready-to-use executable file.

Don’t forget to grant the uploaded file execution rights prior to running it. Success! The goal is achieved: you have RCE on a camera again. And you already know how to set up a proxy.
Case #4: Firmware modification
One of the most interesting cases involves firmware modification. Imagine that you have access to the camera’s web interface, but there is no way to enable SSH or Telnet. In such a situation, you can try to update camera’s firmware.
So, you’ve got network access to the camera’s web interface. As usual, don’t forget to search Google for default credentials.

You found the credentials and logged into the admin panel. But there is no possibility to enable Telnet or SSH there. However, there is a tab that can be used to update firmware from a file.

Creating firmware from scratch is an extremely time- and labor-consuming job. Therefore, let’s try to tinker with the firmware provided by the manufacturer. You go to the manufacturer’s website, find a suitable file there, download it, and open it using an archiver.
Inside you find an interesting script run.
. Its name implies that it should be executed at startup. The script contains the string telnetd
, but it’s commented out. Perhaps, if you uncomment it, then Telnet will turn on when the camera starts? Let’s check it out!

The firmware contains the rootfs file system, which, in turn, contains the /
directory with the passwd
file containing the hash of the root
account. But this time, there is no need to brute-force anything. Instead, you can simply generate the same hash from the password known to you. Then you substitute the hash and save the file.
Generating hash:
openssl passwd -1 password


You are almost ready to reflash the firmware. Is it really that simple? Well, almost… You just have to take into account the file system type used in the firmware. In this particular case, it is cramfs. You can easily unpack it using an archiver, but it’s not that easy to pack it back. To perform this operation, you have to install the environment and execute the following command:
mkcramfs romfs romfs-x.cramfs
warning
If you flash incorrect firmware, the camera most likely would be ‘bricked’, and you won’t be able to access it anymore.
Now you are 100% ready to reflash the camera.

You press the “Reflash” button, and the camera stops responding to pings and doesn’t show any signs of life.

But after a minute, it comes to life again, and you can breathe a sigh of relief. Let’s see whether Telnet is up and running. Yes, it is, and you can connect to it using the password substituted into /
.

This time, Netcat is available.

Using Netcat, you can easily drop any payload and run it. For instance, Meterpreter that was generated earlier.
You load C2 agent and start it on the camera; now you can launch the proxy. This time, you have to use several commands:
run autoroute -s 10.0.0.0/8
background
use auxiliary/server/socks_proxy
run
After that, you get fully-functional traffic proxying via the camera and a handy control over it in the form of a C2 agent.
Now that you’ve seized four cameras, an intermediate conclusion can be drawn. You’ve seen how quickly and easily a camera can be hacked used in a pentesting audit to get RCE on it and perform pivoting. The above-described scenarios can be implemented in a real-life project in a short time. Potentially, cameras can be used as footholds or traffic proxying points.
By the way, it’s quite easy to locate cameras by a combination of open TCP ports 80 and 554.
Protection
As you have probably noticed, all above-described cases involved cameras with default passwords. Cases involving manipulations with firmware exploited hardcoded passwords. Accordingly, the following steps can be recommended to protect your cameras:
- change default passwords; this will block almost all potential exploitation vectors;
- update software: manufacturers often release security updates;
- update hardware: if a device is no longer supported, it’s worth replacing it with a modern one;
- perform pentesting audits to detect such flaws in the infrastructures and take timely measures; and
- isolate the camera segment from the main infrastructure.
In some organizations, cameras are under the jurisdiction of the security department, and the IT or IS departments cannot control and update them directly. In such a case, the only solution is to isolate network segments whose updates are beyond the control of your team.
Conclusions
In this article, I provided several real-life examples demonstrating that cameras can be used to deliver complex attacks against infrastructures. Of course, not all possible scenarios were examined, and each situation is unique; however, now you are familiar with techniques that should be tried first. Should you implement something new and more effective, don’t forget to share your findings in comments.
Good luck!

2023.01.22 — Top 5 Ways to Use a VPN for Enhanced Online Privacy and Security
This is an external third-party advertising publication. In this period when technology is at its highest level, the importance of privacy and security has grown like never…
Full article →
2022.06.02 — Blindfold game. Manage your Android smartphone via ABD
One day I encountered a technical issue: I had to put a phone connected to a single-board Raspberry Pi computer into the USB-tethering mode on boot. To do this,…
Full article →
2023.02.12 — Gateway Bleeding. Pentesting FHRP systems and hijacking network traffic
There are many ways to increase fault tolerance and reliability of corporate networks. Among other things, First Hop Redundancy Protocols (FHRP) are used for this…
Full article →
2023.03.26 — Attacks on the DHCP protocol: DHCP starvation, DHCP spoofing, and protection against these techniques
Chances are high that you had dealt with DHCP when configuring a router. But are you aware of risks arising if this protocol is misconfigured on a…
Full article →
2023.02.21 — Herpaderping and Ghosting. Two new ways to hide processes from antiviruses
The primary objective of virus writers (as well as pentesters and Red Team members) is to hide their payloads from antiviruses and avoid their detection. Various…
Full article →
2022.02.16 — Timeline of everything. Collecting system events with Plaso
As you are likely aware, forensic analysis tools quickly become obsolete, while hackers continuously invent new techniques enabling them to cover tracks! As…
Full article →
2022.02.15 — EVE-NG: Building a cyberpolygon for hacking experiments
Virtualization tools are required in many situations: testing of security utilities, personnel training in attack scenarios or network infrastructure protection, etc. Some admins reinvent the wheel by…
Full article →
2023.04.19 — Kung fu enumeration. Data collection in attacked systems
In penetration testing, there's a world of difference between reconnaissance (recon) and data collection (enum). Recon involves passive actions; while enum, active ones. During recon,…
Full article →
2023.07.29 — Invisible device. Penetrating into a local network with an 'undetectable' hacker gadget
Unauthorized access to someone else's device can be gained not only through a USB port, but also via an Ethernet connection - after all, Ethernet sockets…
Full article →
2023.02.13 — First Contact: Attacks on Google Pay, Samsung Pay, and Apple Pay
Electronic wallets, such as Google Pay, Samsung Pay, and Apple Pay, are considered the most advanced and secure payment tools. However, these systems are also…
Full article →