UNC2891 Bank Heist: Physical ATM Backdoor & Linux Forensic Evasion

Introduction

When investigating cyber intrusions, the focus is often on payloads, lateral movement, or impact. But in many real-world cases, initial access remains a blind spot in both public research and internal post-incident analysis.

This blog uncovers a unique, stealthy approach used by a financially motivated threat actor group to compromise critical banking infrastructure. It reveals a previously undocumented anti-forensics technique (now recognized in MITRE ATT&CK), backdoor presence invisible to process listings, and a rare instance of physical network compromise using embedded hardware.

Key Takeaways From This Blog

• Initial access can be physical and extremely low-profile, evading most traditional defenses.
• Memory and network forensics were the only effective techniques in detecting the backdoor.
• An unpublished anti-forensics tactic, now cataloged in MITRE ATT&CK as T1564.013 (Linux bind mount abuse), played a central role in the campaign’s stealth.
• Threat actors used custom malware suites to infiltrate and maintain persistence on ATM switching systems.

Physical Backdoor Installed in ATM Network

One of the most unusual elements of this case was the attacker’s use of physical access to install a Raspberry Pi device. This device was connected directly to the same network switch as the ATM, effectively placing it inside the bank’s internal network. The Raspberry Pi was equipped with a 4G modem, allowing remote access over mobile data.

Figure 1. UNC2891’s workflow.

Using the TINYSHELL backdoor, the attacker established an outbound command-and-control (C2) channel via a Dynamic DNS domain. This setup enabled continuous external access to the ATM network, completely bypassing perimeter firewalls and traditional network defenses.

Network Forensics Exposed Hidden Beaconing

Despite the stealthy placement of the device, a forensic review of the network monitoring server revealed several unusual behaviors. Notably, outbound beaconing occurred every 600 seconds, and there were repeated connection attempts to the Raspberry Pi on port 929. However, no matching process ID (PID) or suspicious processes were found during the triage phase.

This raised an important question for the investigators: Do forensic triage tools capture process state during system sleep or idle states? The lack of suspicious processes during triage led to the need for further investigation into how system states might affect data collection.

To answer this question, the team deployed a custom script. The script was designed to capture socket connections every second over a 10-minute period, ensuring a detailed review of any hidden or time-dependent network activity.

Forensic Challenges in Uncovering the Backdoor

Although a connection was visible, no corresponding process ID (PID) could be found, raising suspicions of a rootkit or anti-forensics technique at play. The absence of any evidence in the process list further deepened concerns, prompting investigators to capture a memory dump for deeper analysis.

Figure 2. The forensic triage tool is unable to collect the relevant process name or ID associated with the socket.

Masquerading of Backdoor Process

Two suspicious processes appeared during memory review:

On the surface, the process seemed legitimate. But its location was unusual:

The backdoor process is deliberately obfuscated by the threat actor through the use of process masquerading. Specifically, the binary is named “lightdm”, mimicking the legitimate LightDM display manager commonly found on Linux systems. To enhance the deception, the process is executed with command-line arguments resembling legitimate parameters – for example,

lightdm –session child 11 19 — in an effort to evade detection and mislead forensic analysts during post-compromise investigations.

These backdoors were actively establishing connections to both the Raspberry Pi and the internal Mail Server.

Figure 3. The Network Monitoring Server continuously beacons to both the Raspberry Pi and the Mail Server.

Why Wasn’t This Detected in Triage?

Despite repeated analysis, standard forensic triage failed to reveal the backdoor because the attacker leveraged Linux bind mounts to hide backdoor processes from conventional detection tools—a technique that had not been documented in public threat reports at the time. This method has since been officially added to the MITRE ATT&CK framework as T1564.013 – Hide Artifacts: Bind Mounts.

Curious about how bind mounts work? Check out our previous blog post for a detailed explanation.

UNC2891’s Objectives

Group-IB’s investigation revealed that the ultimate target was the ATM switching server, with the intent to deploy CAKETAP – a rootkit designed to manipulate HSM responses – and spoof authorization messages to facilitate fraudulent ATM cash withdrawals. Fortunately, the threat actor’s campaign was disrupted before they could achieve their objective.

Incident Summary

In this case, the Network Monitoring Server acted as a pivot point, with connectivity to almost every server within the data center. Once compromised, it granted the threat actor lateral access across the entire internal environment.

Key observations:

• The Mail Server had direct internet connectivity, making it a persistent foothold.
• Even after the Raspberry Pi was discovered and removed, the attacker maintained internal access through a backdoor on the Mail Server.
• The threat actor leveraged a Dynamic DNS domain for command and control:
  • This method obscured domain ownership and activity.
  • Allowed for rapid IP rotation or infrastructure switch, reducing disruption if an IP was blocked or seized.

Figure 4. UNC2891’s multi-Pivot access path.

This multi-pivot access path – combining physical, network, and infrastructure control – made containment especially challenging and highlights the sophistication of UNC2891’s operation.

Detection & Defense Recommendations

Group-IB recommends the following, in order to detect or prevent similar attacks:

• Monitor mount and umount syscalls (via auditd, eBPF, etc).
• Alert if /proc/[pid] is mounted to tmpfs or external filesystems.
• Block or alert on binaries executing from /tmp or .snapd paths.
• Physically secure switch ports and ATM-connected infrastructure.
• Capture memory images in addition to disk during incident response.

Conclusion

Our research is a strong reminder that:

• Forensic triage tools aren’t sufficient on their own – you need memory and network forensics.
• Rootkits and obscure Linux features, such as bind mounts, can effectively defeat traditional incident response playbooks.
• Physical and logical access vectors must both be part of threat models for banking infrastructure.