A recently analysed Atomic macOS Stealer infection demonstrates how cybercriminals are bypassing traditional software-delivery protections by persuading users to copy and execute malicious commands themselves. Instead of relying on a conventional malicious application or exploiting a vulnerability, the campaign directed victims to a fraudulent website that claimed to provide a macOS toolkit and instructed them to paste encoded text into the macOS Terminal. 

The pasted command was not a legitimate installation instruction. It retrieved and executed a sequence of malicious scripts that ultimately installed Atomic macOS Stealer, commonly known as AMOS, on the victim’s computer. The malware then collected credentials, browser information, cryptocurrency-wallet data, messaging information and other files before transmitting them to attacker-controlled infrastructure.

The attack is important because it does not initially look like a traditional malware infection. The victim voluntarily opens Terminal, pastes the command and authorises the activity. From the operating system’s perspective, many of the actions are therefore being performed by the logged-in user through a trusted administrative tool.

This makes the campaign another example of an increasingly popular social-engineering technique sometimes described as ClickFix. The attacker does not necessarily need to defeat every security control directly. Instead, the attacker convinces the victim to perform the actions that those controls would ordinarily prevent.

The fake toolkit page creates a sense of legitimacy

The infection began through a website that presented itself as offering a toolkit for macOS. Visitors were instructed to copy a block of text and paste it into a Terminal window, supposedly to install or activate the tool.

For some users, instructions involving Terminal may appear technical and therefore trustworthy. People often assume that a complicated-looking command must be legitimate because they do not understand what it does. Attackers exploit this psychological gap by presenting command-line instructions as an official troubleshooting, verification or installation process.

The malicious text was encoded, which made it difficult for an ordinary user to understand what would happen before running it. Encoding is not encryption and does not provide meaningful security, but it can effectively hide URLs, filenames and commands from casual inspection.

A long encoded command can therefore conceal the fact that the system is being instructed to contact an unfamiliar server, download additional files, decompress content, modify permissions and execute a payload.

Users should treat any website that asks them to paste an unfamiliar command into Terminal, PowerShell, Command Prompt or a browser developer console as highly suspicious. Legitimate software vendors may occasionally provide command-line installation instructions, but such commands should come from verified documentation and should be understandable or independently reviewed before execution.

Terminal is trusted, but the command may not be

Terminal is a legitimate and powerful macOS application. Administrators and developers use it for software installation, troubleshooting, automation and system management. That legitimacy is exactly what makes it useful to attackers.

Security tools cannot simply block Terminal because doing so would disrupt legitimate administration. Instead, defenders must distinguish between normal command-line use and suspicious behaviour occurring through a trusted process.

In this campaign, the Terminal command downloaded a small shell script, extracted additional code and launched a Mach-O executable. Each stage performed part of the infection, allowing the attacker to separate the visible user action from the eventual information-stealing payload.

This staged design also makes detection more difficult. The initial command may contain only a downloader, while the malicious functionality resides in files retrieved later. A security tool examining only the first script may therefore see limited evidence of the final attack.

Organizations should monitor command-line activity for combinations such as Terminal downloading content from newly observed domains, decoding Base64 strings, writing executable files into temporary directories, changing file permissions and launching recently downloaded binaries.

No single action is necessarily malicious, but the full sequence can strongly indicate compromise.

The attack requested the user’s password

Atomic macOS Stealer campaigns frequently attempt to obtain the user’s macOS password. The password may be requested through a fake prompt or through commands that cause the user to believe authentication is required for a legitimate installation.

A valid account password provides attackers with several advantages. It may allow access to protected information, enable privileged commands, assist in decrypting stored credentials and make it easier to establish persistence.

Users have been trained to expect password prompts during software installation, which makes this behaviour particularly effective. A password request appearing shortly after a user intentionally launches what they believe is an installer may not appear unusual.

However, entering a password does not merely approve one harmless action. Depending on the command being executed, it may grant malicious code broader access to the device.

Organizations should therefore teach users to consider what initiated the password request and whether the action is expected. Password prompts should not be treated as routine confirmations that can be approved automatically merely because macOS displayed them.

Universal binaries broaden the victim population

The malicious Mach-O files observed during the analysed infection were universal binaries containing code for both x86_64 and arm64 architectures. This allows the malware to run on older Intel-based Macs as well as newer Apple Silicon systems.

Supporting both architectures increases the attacker’s potential victim population and reduces the risk that the infection fails because of hardware incompatibility.

This also demonstrates that macOS malware development has matured considerably. Attackers are no longer treating the Mac ecosystem as a minor afterthought. They are building payloads designed for modern hardware, current operating systems and the applications commonly used by Mac owners.

The persistent belief that Macs do not get malware continues to provide attackers with an additional advantage. Users who consider their devices inherently safe may be more willing to execute unfamiliar commands, install unsigned software or ignore security warnings.

macOS includes several important protections, but none of them can guarantee safety when a user is persuaded to authorise malicious actions directly.

AMOS targets high-value information

The network traffic observed during the infection indicates that the malware processed several categories of information, including credentials, browsers, messaging applications, cryptocurrency wallets and local data.

These categories reflect the commercial objectives of modern information-stealing malware. Attackers are rarely interested in one password alone. They want complete collections of reusable information that can be sold, exploited or used to support further compromises.

Browser data may contain saved passwords, cookies, autofill information and active session tokens. Session cookies can be especially valuable because they may allow attackers to access an account without knowing the password or completing the original login process.

Cryptocurrency-wallet data can provide access to digital assets that are difficult or impossible to recover once transferred. Messaging information may expose private conversations, business discussions and additional contacts who can be targeted.

Local files may contain identity documents, financial records, source code, confidential business information or password exports. Even apparently ordinary files can help attackers understand the victim’s role, organization and relationships.

The value of the infection therefore extends well beyond the initially compromised device. Stolen information can be used to attack the victim’s employer, customers, colleagues, family members and online accounts.

Browser session theft can bypass strong passwords

Organizations frequently focus on password strength and multi-factor authentication, both of which remain essential controls. However, information stealers increasingly target browser session cookies and authentication tokens that are created after the user successfully completes those security checks.

If an attacker obtains a valid session token, the target service may treat the attacker as an already authenticated user. Depending on the service and its session controls, the attacker may not need to re-enter the password or complete multi-factor authentication.

This does not mean multi-factor authentication is ineffective. It means that authentication security must also protect what happens after login.

Services should monitor for session reuse from unfamiliar devices, locations or network environments. High-risk actions should require fresh authentication, and sessions should be invalidated when compromise is suspected.

Organizations responding to an AMOS infection should not limit remediation to changing passwords. They should revoke active sessions, invalidate tokens, review registered devices and check for unauthorised application access.

Cryptocurrency wallets are particularly attractive targets

Atomic Stealer is widely associated with attempts to collect cryptocurrency-wallet information. Wallet browser extensions, local wallet files, seed phrases and related application data can provide attackers with direct access to digital assets.

Cryptocurrency theft is attractive because transfers are generally irreversible. Once an attacker gains access to the private key or recovery phrase and moves the funds, the victim usually has no bank or payment provider capable of reversing the transaction.

Users storing cryptocurrency on a Mac that may have been infected should assume that wallet-related information could have been exposed. Simply removing the malware does not secure a wallet whose seed phrase or private key has already been stolen.

Funds should be migrated to a new wallet generated on a trusted, uncompromised device. Reusing the same seed on a clean device does not solve the problem because the attacker may already possess that seed.

Users should also be cautious of fraudulent recovery services, support messages and migration tools that appear after public reports of wallet-stealing malware. Cybercriminals are remarkably willing to solve the problem they created by stealing whatever remains.

Persistence allows the malware to survive beyond the initial session

The analysed infection placed malicious executables inside hidden-looking directories under the user’s Library/Application Support path. The directory and filenames were designed to resemble legitimate Apple components, including names associated with accounts and metadata services.

This naming strategy can reduce suspicion during casual inspection. A file named AccountsHelper inside a directory resembling an Apple service may appear more legitimate than an obviously malicious filename.

Attackers frequently imitate operating-system components because users and administrators are reluctant to delete files that appear to belong to macOS. Similar-looking names can also make alerts more difficult to interpret quickly.

Persistence means that closing the browser or Terminal does not necessarily end the compromise. The malware may execute again after login or system restart, allowing continued data theft and command-and-control communication.

Incident responders should therefore search for unfamiliar files, launch agents, launch daemons, login items and scheduled execution mechanisms. Removing only the initial downloaded script may leave the persistent payload active.

Temporary directories provide a convenient staging area

The infection used the `/tmp` directory during its early stages. Temporary directories are attractive to attackers because applications routinely create files there and the content may receive less scrutiny than files written to standard application locations.

Attackers can download scripts, decompress payloads and prepare executables within temporary directories before moving the final malware to a persistent location.

Security monitoring should therefore not treat activity in temporary directories as automatically harmless. Executable creation, permission changes and process launches originating from `/tmp` can be important indicators, particularly when they follow network downloads or encoded shell commands.

Temporary files may disappear after restart or cleanup, so rapid evidence collection is essential. Incident responders should capture relevant files, process information and network connections before they are removed.

Command-and-control traffic reveals the malware workflow

The observed malware communicated with its command-and-control infrastructure using HTTP requests that reported different stages of execution. The traffic included references to boot activity, session initialization, messaging applications, credentials, browsers, wallets, authentication data and local files.

This stage-based communication suggests that the malware tracked its own progress and informed the attacker which collection activities had completed. Such telemetry can help the operator understand which devices produced valuable information and which stages failed.

The malware also contacted endpoints associated with device information, task retrieval and data feeds, indicating that the infection could potentially receive further instructions rather than operating only as a one-time data collector.

The use of unencrypted HTTP traffic in the observed sample may provide defenders with greater visibility. Network security systems can inspect URLs and request paths directly when traffic is not encrypted.

However, organizations should not depend on attackers continuing to use plain HTTP. Infrastructure and protocols can change quickly, and future versions may use HTTPS, trusted cloud services or other encrypted channels.

The most durable detection strategy is to understand which applications and devices should communicate with which destinations and to identify unusual outbound behaviour in context.

Network monitoring remains valuable for endpoint-focused malware

Although the infection began on a macOS endpoint, network visibility played an important role in reconstructing the attack. The initial download domains, payload locations and command-and-control server all generated observable traffic.

This demonstrates why endpoint and network security should operate together. Endpoint telemetry can reveal process execution, file creation and persistence, while network monitoring can identify downloads, external destinations and data exfiltration.

An endpoint alert showing Terminal executing an encoded command becomes more meaningful when network records show a connection to a newly registered or previously unseen domain. Similarly, an unusual outbound connection becomes more suspicious when the initiating process is a binary recently created in a hidden Application Support directory.

Security products should correlate users, applications, processes, destinations and transferred data rather than evaluating each event independently.

A connection from Safari to a public website may be ordinary. A hidden binary contacting an unfamiliar IP address immediately after Terminal downloaded and executed encoded content is not.

DNS and domain controls can disrupt the infection chain

The campaign used several domains for redirection, initial payload delivery and subsequent downloads. Blocking known malicious domains can prevent parts of the attack chain from completing.

DNS filtering, secure web gateways and threat-intelligence feeds can therefore provide valuable protection, particularly when indicators are distributed quickly.

However, domain blocking is inherently reactive. Attackers can register new domains, move infrastructure and change URLs far faster than many organizations update manual blocklists.

Controls should therefore also evaluate domain age, reputation, hosting patterns, certificate information and first-seen activity. A device contacting a domain that has never previously appeared in the organization may deserve additional scrutiny when the connection is initiated by Terminal or a newly created executable.

Organizations should retain DNS logs because they can reveal earlier communication with malicious infrastructure even when the endpoint is no longer available for investigation.

Traditional antivirus may not stop user-authorised execution

A malware file may be detected by antivirus after it is downloaded, but attackers continuously change hashes, packaging and delivery infrastructure to reduce signature-based detection.

The social-engineering component also complicates prevention because the user is intentionally executing the command. Security controls designed primarily to block unexpected background activity may interpret the actions differently when they originate from Terminal under the logged-in account.

Behavioural detection is therefore essential. Security tools should identify suspicious relationships between processes, such as a browser leading the user to Terminal, Terminal launching a shell, the shell downloading executable content and the downloaded file establishing persistence.

The behaviour remains suspicious even when the exact malware hash has never been seen before.

Application control can also reduce risk by restricting execution of unsigned or unapproved binaries from user-writable and temporary locations. Such policies must be designed carefully to avoid disrupting legitimate development and administrative workflows, particularly in organizations with large Mac developer populations.

macOS security controls should be centrally managed

Organizations using Macs should manage them through an enterprise device-management platform rather than relying entirely on user configuration.

Central management can enforce operating-system updates, security settings, disk encryption, approved applications, browser policies and endpoint-security deployment. It can also provide inventory and compliance information when an incident occurs.

Security teams should ensure that users cannot easily disable endpoint monitoring or grant excessive permissions to unknown applications. Changes to privacy permissions, login items and security settings should be logged and reviewed.

Developers and technical users may require Terminal access, but access to powerful tools should be accompanied by monitoring and clear acceptable-use guidance.

Blocking Terminal entirely is rarely practical and does not address the underlying problem. Attackers may simply shift to another interpreter or trusted application. The stronger approach is to make suspicious execution visible and difficult to persist.

Users should not paste commands they do not understand

The most direct lesson from the campaign is also the simplest: users should not paste commands into Terminal merely because a website instructs them to do so.

Copying and pasting a command is equivalent to allowing the website to provide instructions directly to the operating system. The fact that the user performs the final keystroke does not make the command safe.

Organizations should train users to stop when a website requests Terminal, PowerShell, Command Prompt or developer-console activity, particularly when the request is presented as a verification step, security fix, CAPTCHA, codec installation or software update.

Users should obtain applications from official stores or directly from verified vendor websites. Installation instructions should be cross-checked against official documentation rather than followed from advertisements, search-engine results or unexpected redirects.

Security awareness training should include realistic examples of command-pasting attacks. Generic advice about avoiding suspicious attachments is no longer sufficient when attackers are teaching victims how to build the infection themselves.

Advertising and search results may contribute to exposure

Malware campaigns frequently attract victims through malicious advertising, poisoned search results, fake download pages and compromised websites. Users searching for popular tools or software may encounter convincing copies of legitimate sites.

The landing page can use professional design, familiar logos and detailed instructions to create trust. Attackers no longer need their websites to look obviously fraudulent. Templates, automation and stolen brand assets have substantially improved the quality of deception.

Organizations should therefore protect users before they reach the malicious page through DNS filtering, advertising controls and secure browsing services.

Browser extensions and ad blockers can reduce exposure to malicious advertisements, although they should come from trusted sources and be centrally managed in enterprise environments.

Security teams should also monitor whether users are downloading business software from unapproved sources. Shadow IT creates both operational and security risk when employees install tools without vendor verification or administrative review.

Incident response must assume credentials have been stolen

When AMOS infection is confirmed, simply deleting the malware is not sufficient. The purpose of the malware is information theft, and the organization must assume that sensitive data accessible to the user may already have left the device.

The affected Mac should be isolated from the network while evidence is collected. Responders should identify downloaded scripts, persistent binaries, command-and-control traffic and the period during which the infection was active.

Passwords used or stored on the device should be changed from a separate trusted system. Active sessions and browser tokens should be revoked, multi-factor authentication settings reviewed and unfamiliar devices removed from accounts.

Cryptocurrency wallets should be migrated to new seeds where exposure is possible. API keys, SSH keys, developer tokens and cloud credentials stored on the system should also be rotated.

The user’s email account should be examined for forwarding rules, login activity and password-reset messages. Attackers who steal credentials may use email access to compromise additional accounts.

Organizations should review whether the affected user had access to source-code repositories, administrative consoles, customer information or cloud environments. The investigation must follow the user’s access, not merely the infected laptop.

Rebuilding may be safer than attempting limited cleanup

Information-stealing malware can install multiple components, change persistence settings and receive additional tasks. When the full extent of compromise cannot be established confidently, rebuilding the Mac from a trusted image may be safer than attempting to delete selected files.

A rebuild removes local malware, but it does not reverse data theft. Credential rotation and session revocation remain necessary.

Backups should be reviewed carefully before restoration so that persistent malware or malicious configuration is not reintroduced. User documents may be restored after validation, while applications should ideally be reinstalled from trusted sources.

The system should receive current operating-system and security updates before being returned to service, and enhanced monitoring should continue after remediation.

The broader cybersecurity lesson

The Atomic macOS Stealer campaign demonstrates how attackers increasingly target the gap between technical controls and human decision-making. The malware did not need to arrive through a conventional application installer. The victim was instructed to open a trusted system tool, paste encoded instructions and provide the permissions required for compromise.

This approach allows attackers to bypass assumptions built into many security architectures. A command entered by the legitimate user, a password supplied through a familiar system prompt and a binary launched through Terminal can appear less suspicious than an unknown program attempting the same actions automatically.

Defenders must therefore focus on behaviour and context. Terminal downloading scripts from unfamiliar infrastructure, executables appearing in temporary directories, hidden binaries imitating Apple services and unusual outbound traffic should be evaluated as a connected sequence.

The campaign also reinforces that macOS endpoints require the same security discipline applied to Windows and Linux systems. They need endpoint monitoring, application control, centralised management, network visibility, threat intelligence, user training and tested incident-response procedures.

The enduring lesson is that trusted tools do not guarantee trusted activity. Terminal is legitimate, shell scripts are legitimate and password prompts are legitimate, but attackers can combine all three into a highly effective infection process.

Security teams must protect not only against malicious software but also against malicious instructions. When a website convinces a user to paste attacker-controlled code into a trusted interpreter, the victim has effectively become part of the malware-delivery mechanism.

Organizations that recognise this shift can design controls around the full attack sequence rather than waiting for a familiar malicious file to appear. Those that continue relying only on signatures and the assumption that Mac users do not run malware may discover that the attacker has already collected the credentials, browser sessions and wallet data required for the next stage of the campaign.

Introduction

Source: Atomic MacOS (AMOS) stealer infection, (Sun, Aug 2nd) via SANS Internet Storm Center — published 02 Aug 2026.