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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
So, you have some AI tools or are thinking about deploying them and want to know a bit about securing them.
You are not alone, but there are significant challenges due to the rapidly growing capabilities of AI, and the issues around new types of vulnerabilities we may not be used to thinking of. This is a very challenging area to attempt to secure, but I hope to point you in the right direction and set you up with some resources.
Welcome back, aspiring cyberwarriors!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The post SDR (Signals Intelligence) for Hackers: Tracking People with ESP32-Paxcounter first appeared on Hackers Arise.
Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.
This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.
In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.
Drive icon indicating that the drive is locked
A recovery key was required to unlock the drive.
Attempt to access the disk’s contents and the prompt for the BitLocker recovery key
This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.
One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.
Ransomware note
Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.
Attacker’s reply to the victim’s email sent to the address in the printed ransom note
This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.
Exposed ports identified in the system in recent months
The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.
In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.
XEntry team attack
In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.
Commands executed when attempting to manipulate the web server
The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.
The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.
Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.
Attack path
One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.
A subset of the critical information identified and collected by the attackers
In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.
Scanning and RMM deployment
Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.
Commands executed through RMM tools to collect Bitlocker keys
Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.
A few hours later, ransom notes began emerging from office printers.
Ransom note printed by the XEntry team
These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.
“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)
“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)
Our teams continue to monitor these threats.
Welcome back, aspiring cyberwarriors!
If you’ve spent any time hunting through vulnerability databases, you may have noticed a recurring trend involving a certain brand of budget networking gear. Tenda routers appear time and again, not because researchers have it in for the company, but because of persistent, systemic security failures that remain largely unaddressed. These issues have almost turned Tenda into a textbook example of what not to do when it comes to product security management.
In this article, we’ll explore the reasons behind Tenda’s notorious reputation, examine the modern threats posed by their devices, and dive into a practical lab to exploit one of their information-disclosure vulnerabilities. Let’s get rolling!
Tenda is a Chinese manufacturer of networking hardware, primarily recognized for offering budget-friendly equipment for home and small business networking. Their product lineup includes wireless routers, range extenders, network switches, and IP cameras.
At first glance, you might overlook Tenda as just a small Chinese company without significant influence. However, a quick search on Shodan reveals an entirely different story.
There are over 12,000 hosts that could potentially serve as gateways for both the Chinese government and hackers worldwide to access various networks.
To understand the issues with Tenda, it’s essential to recognize a troubling pattern of behavior rather than focusing on a single vulnerability. When Carnegie Mellon’s CERT/CC identifies a significant backdoor in the firmware of several router models and reaches out to Tenda for a coordinated disclosure, one might expect a company of Tenda’s stature to acknowledge the issue and take steps toward a resolution. Unfortunately, that hasn’t been the case. CERT/CC’s recent advisory on this backdoor reveals that Tenda has remained silent since they were contacted in May 2026, with no patches released for any of the five affected router models.
This isn’t just a one-off incident. Back in 2020, researchers from Independent Security Evaluators discovered a hardcoded telnet password embedded in the Tenda AC15 AC1900. They notified the company and waited nearly double the standard 90-day disclosure period without receiving a response, ultimately publishing their findings without any acknowledgment from Tenda. If you look even further back to 2013, you’ll find a security researcher documenting a LAN-side backdoor in the Tenda W302R and W330R routers, which was also never patched. When a company remains unresponsive for over a decade and across multiple hardware iterations, it indicates a fundamental flaw in its business model rather than just a series of mistakes.
The scale of Tenda’s problems becomes even clearer when looking at firmware analysis studies instead of individual disclosures. Research scanning extensive batches of Tenda firmware images has revealed that nearly one in five contain hardcoded default credentials or even empty passwords embedded directly in the binary. This isn’t a rare oversight; rather, it points to a recurring design choice made across an entire line of products. When you combine this statistic with a vendor that ignores security disclosures, it means Tenda is, in effect, distributing routers that come pre-loaded with vulnerable access points, easily exploitable by anyone who knows where to look.
A particularly egregious example is CVE-2026-11405. This vulnerability deserves special attention due to the way it undermines the basic principles of router security. It resides within the login function of the httpd web server binary that runs on several router models. Typically, when a user submits a password, the router checks it using MD5-based verification. However, if this check fails, instead of simply rejecting the login attempt, the code unwittingly falls through to a second, undocumented authentication route. It retrieves a hidden configuration value called sys.rzadmin.password and directly compares it in plaintext to the password submitted by the attacker. If they match, the router grants administrative access at role level two, and critically, the username input during this attempt isn’t validated at all. This means that any username coupled with the correct backdoor password gains access.
Consider the implications for an average user who has followed all the right steps. You purchase the router, log into the web interface, and change the default admin password to a strong, unique one, just as every security guide advises. Unfortunately, none of that matters here since the backdoor password exists entirely outside the interface that you interacted with. It is stored in the device’s configuration, hidden from any user-facing menu and unaffected by any password changes you make through the regular admin panel. The only way to eliminate this risk is through a complete firmware rewrite from the vendor, and as of now, Tenda has provided no indication that such an update is forthcoming.
Backdoors aren’t the only serious vulnerability affecting this ecosystem. CVE-2026-36794 targets the Tenda W3 router and highlights a stack-based buffer overflow that an unauthenticated remote attacker can exploit simply by sending a specially crafted HTTP request.
There’s no need for a login or any user interaction; the attacker just requires network access to the device’s web interface. The consequence is a device crash, leading to a straightforward denial of service.
Now, let’s dive right in. While the recent backdoor vulnerability we discussed is certainly eye-catching for 2026, today we will focus on an older issue: CVE-2020-35391, which affects the Tenda N300. I have chosen this example intentionally, as it highlights a troubling trend within Tenda, specifically the consistent shipping of exploitable authentication flaws.
The issue lies in how the router manages configuration backup requests. Normally, an authenticated administrator can easily request a copy of the device’s configuration file for backup by accessing an endpoint at cgi-bin/DownloadCfg/RouterCfm.cfg. The problem arises because this endpoint fails to properly enforce authentication before releasing the file. An attacker can simply send a direct request to that endpoint and sometimes gain access to the complete configuration file. Once you have that configuration file, open it up and find the line labeled extend_pass.
That single line contains the administrative password for the router’s web interface, made accessible without any login credentials. From here, exploiting this vulnerability is straightforward. Just take that password, navigate to the router’s usual login page, and authenticate as the administrator. You will then have full control over the device, including its DNS settings, port forwarding rules, and every device connected behind it.
These days, Tenda hardware remains quite popular in various countries due to its affordability. However, we must be more cautious about security, as overlooking it could lead to significantly higher long-term costs.
If you’re interested in exploring how to both attack and secure routers, consider enrolling in the VPN & Router Hacking course. This course delves into router exploitation through manual RCE (Remote Code Execution), information disclosure, and unauthorized code execution on devices like Netgear, Netis, and Telesquare, as well as enterprise-grade systems like FortiPAM and FortiSwitchManager – and much more.
The post Router Hacking: Why the World’s Most Popular Budget Router Keeps Making Headlines for the Wrong Reasons first appeared on Hackers Arise.
Picture this: Your company just fell victim to a massive data breach. The culprit wasn't a sophisticated malware strain, a zero-day exploit, or a compromised firewall. It was a perfectly legitimate-looking login from a VP’s account, originating from an unrecognized IP address, requesting an urgent wire transfer via a spotless, text-only email.
Welcome back, aspiring cyberwarriors!
Think back to the first time you installed Kali Linux. It was probably one of those moments where you realized just how many cybersecurity tools existed. Your applications menu was packed with hundreds of tools covering everything from recon and vulnerability scanning to exploitation, password attacks, wireless security and much more.
At first, it was exciting. But most beginners spend hours clicking through the menus wondering what every tool does and when they should actually use it. Unfortunately, the sheer number of applications quickly becomes overwhelming. Even if you dedicate time to learning them, chances are you’ll forget many of their names simply because there are so many available. On top of that, documentation isn’t always beginner-friendly. Some projects have excellent documentation, while others assume you already know exactly what the tool is supposed to do before you even start reading.
The good news is that you don’t have to memorize hundreds of commands or remember every tool available. Instead, you can build your own arsenal of references that helps you quickly find the right tool.
In this article, we’re going to build exactly that. We’ll explore two resources called Arsenal-NG and Arsenal, both of which are designed to make finding offensive security tools, payloads, commands much faster.
The first tool we’ll look at is Arsenal-NG. The name pretty much explains what it does. Arsenal-NG is essentially a searchable collection of offensive security tools, commands, and predefined workflows. Whether you’re doing reconnaissance, exploiting a service, generating payloads, Arsenal-NG can help you find the right tool for the job.
Let’s install it.
Loginkali > git clone https://github.com/halilkirazkaya/arsenal-ng.git
kali > cd arsenal-ng
kali > make buildOnce compilation finishes, you can launch the program directly. For convenience, you may also want to move the binary into one of the directories listed in your PATH environment variable. Doing so allows you to start Arsenal-NG from any directory.
kali > arsenal-ngWhen it starts, you’ll immediately notice a large collection of tools organized inside the interface. Each tool includes predefined presets for different kinds of operations.
To display the complete list of available tools, simply run tools
If you already know what kind of task you’re trying to accomplish but don’t remember what tool can do it, you can use the built-in search feature. Searching by keywords makes it easy to discover them.
Once you’ve found the tool you need, selecting one of its presets walks you through the required parameters. There you simply provide the requested information and let it generate the command for you.
If you need additional information about the application itself, run help.
Unlike Arsenal-NG, Arsenal focuses primarily on web exploitation and can be used directly from your browser. There is no installation process, making it convenient when you simply need a quick reference.
You can access it here.
One thing worth mentioning is that the website supports multiple languages. If the interface isn’t already in English, simply switch the language using the selector in the upper-right corner. Once inside, you’ll notice that the content is organized into several different sections, each designed to help with a different phase of a web penetration test.
One of them is Payloads.
This area contains a huge collection of payloads covering many different types of web vulnerabilities and exploitation techniques. Whether you’re working with command injection, SQL injection, XSS, SSTI, XXE, deserialization, or other common web vulnerabilities, chances are you’ll find useful examples here.
Another valuable section is Attack Chains.
Rather than simply providing payloads, Attack Chains guide you through the overall exploitation process. They outline the sequence of steps typically required to compromise a target.
The Commands section is another good reference.
You can build the command you need by selecting the appropriate options.
Then we have Wordlists.
There are numerous wordlists organized into logical categories, making it much easier to find exactly what you’re looking for. Each category often contains several different wordlists optimized for different situations.
You’ll also find a large collection of Scripts.
These scripts cover a wide variety of purposes, including reconnaissance, AI-related security checks, subdomain takeovers, automation and more.
Of course, we’ve only scratched the surface. Arsenal contains more additional sections that are worth exploring on your own. Spend some time clicking through the different categories and seeing what they have.
Building your own cybersecurity arsenal isn’t about memorizing every command ever written. In fact, no experienced pentester or hacker remembers every tool, every option or every payload. There are simply too many of them, and new ones are being developed all the time. Arsenal-NG and Arsenal can help you organize knowledge. They are valuable when you’re getting started and they remain just as useful years later when you’re experienced.
Since many of these tools fall into different categories, such as network pentesting, web pentesting, bug bounty hunting, and more, the best way to develop your skills is through our Member Gold subscription. It gives you access to a wide variety of training courses covering different areas.
The post Linux for Hackers: Building Your Tool Arsenal first appeared on Hackers Arise.
