macOS malware in 2018 exposed RAT and supply chain risks

At a glance

What this is: This year-in-review shows macOS threats shifting toward RATs, trojanised applications, cryptomining abuse and phishing-led wallet theft, with trust in signed or approved software repeatedly exploited.

Why it matters: It matters to IAM practitioners because attacker success often depends on abused credentials, trusted execution paths and over-permissioned user workflows, all of which intersect with identity governance and privileged access assumptions.

👉 Read SentinelOne's full review of macOS malware trends in 2018

Context

macOS threats are not just a malware problem, they are a trust problem. When attackers can ride on signed applications, user approval, phishing, or software update paths, the platform’s default trust model becomes part of the attack surface. In identity terms, this is the same governance failure that appears when credentials, tokens, and elevated user actions are accepted without enough assurance about who or what is really behind them.

The 2018 macOS pattern also shows how identity and endpoint security overlap. Malware that uses reverse shells, LaunchAgents, or spoofed applications is not only trying to execute code, it is trying to inherit the trust of a user session, a software reputation, or a privileged workflow. That makes the article relevant to IAM, PAM, and NHI governance because the control gap is often authority, not only detection.

Key questions

Q: What breaks when macOS users trust signed or approved software by default?

A: Default trust breaks when attackers use signed installers, app store distribution, or user-approved tools to gain persistence and remote control. The software may look legitimate at install time, but its behaviour can change afterward. Security teams need runtime verification, not just reputation checks, because trust at delivery does not guarantee trust at execution.

Q: Why do macOS malware campaigns often become an identity and access problem?

A: Because many campaigns abuse session authority, user approval, or privileged execution to reach their objective. Once a malicious app inherits a trusted workflow, it can steal screenshots, open shells, or capture data without further authentication. That makes the real failure the grant of authority, not only the malware payload itself.

Q: What do security teams get wrong about cryptojacking on endpoints?

A: They often treat cryptojacking as a nuisance rather than a sign of broader trust abuse. In practice, a mining payload can indicate trojanised software, persistence mechanisms, or control channels that could support more damaging activity. The resource theft is visible, but the underlying execution path is usually the real problem.

Q: How should organisations respond when malware gains persistent macOS access?

A: Contain the endpoint, revoke any related user sessions or tokens, and review whether the malware used LaunchAgents, LaunchDaemons, or other persistent launch paths. Then identify what trusted execution decision allowed the payload to run. Containment should cover both the device and any identity or access artefacts exposed during the compromise.

Technical breakdown

RAT-based macOS malware turns user trust into execution

Remote access trojans, or RATs, give an attacker interactive control after initial execution. In this article, families such as Empyre-backed variants, EvilOSX, EvilEgg and CrossRAT show how a payload can blend persistence, screenshot capture, file theft and command execution into a single foothold. The technical pattern is simple: a loader, a persistence mechanism, and a remote command channel. Once the malware is running, the attacker no longer needs repeated exploitation. That makes the initial trust decision, whether from a user, app store, or signed installer, the real control point.

Practical implication: restrict which execution paths can establish persistence or open outbound command channels, especially for signed or user-approved apps.

Supply chain trust and signed app abuse in macOS infections

The AppleJeus and App Store examples show two different trust failures. One abuses a valid developer signature to bypass built-in security checks, while the other relies on software distributed through a trusted store to gain user confidence. In both cases, the malware does not need to look obviously malicious at the point of install. It only needs to look like legitimate software long enough to be executed, persist, and reach a remote payload. This is why signed code and distribution reputation are assurance signals, not proof of safety.

Practical implication: validate software provenance, constrain installation sources, and monitor for abnormal post-install behaviour even when binaries are signed.

Cryptojacking and phishing succeed by inheriting session access

The cryptomining and wallet-theft cases in the article rely on access that already exists somewhere in the user workflow. A fake utility, phishing email, or deceptive app can open a reverse shell, steal wallet data, or capture screenshots without needing a kernel exploit. The attacker objective is not just infection, but monetisation through stolen credentials, wallet contents, or system resources. For security teams, this is a reminder that session trust, browser trust, and user approval can be as exploitable as a password.

Practical implication: tighten phishing-resistant access, limit what user sessions can launch, and monitor for credential or wallet abuse after suspicious execution.

Threat narrative

Attacker objective: The attacker wants durable remote control and monetisable access to victim systems, wallets, data, or compute resources.

1. Entry occurs through trojanised apps, phishing email, malicious chat-group tools, or trusted distribution channels that persuade the victim to run the payload.
2. Escalation or persistence follows through LaunchAgents, LaunchDaemons, Automator workflows, sandbox escapes, or configuration changes that keep the malware active.
3. Impact is achieved through reverse shells, screenshot capture, file theft, cryptomining, wallet theft, or exfiltration of personal data and activity.

NHI Mgmt Group analysis

Platform trust is the core weakness in macOS malware campaigns. The 2018 cases show that attackers do not need to beat every control if they can inherit trust from signatures, approved stores, or user action. That shifts the security problem from simple malware detection to governance of execution trust, provenance, and privilege boundaries. For practitioners, the lesson is that trust decisions must be continuously verified, not assumed.

macOS malware is increasingly a credentials and session problem, not just an endpoint problem. Reverse shells, credential theft, wallet targeting and screenshot capture all depend on access that is already granted somewhere in the workflow. That makes the identity angle real, even in an endpoint article: session authority, user approval, and privileged execution are being repurposed by attackers. Practitioners should treat macOS infections as potential identity and access events, not isolated device incidents.

Command-and-control persistence on macOS resembles unmanaged non-human identity behaviour. A RAT that installs LaunchAgents or LaunchDaemons and repeatedly phones home is operating like an unauthorised machine identity with its own runtime access pattern. That is where NHI governance becomes relevant, because the control question is whether a software process should be allowed persistent identity-like behaviour at all. For practitioners, persistent runtime access must be inventoryable, attributable, and revocable.

Cryptomining abuse proves that low-friction threats can still consume high-value enterprise trust. Several of the 2018 examples used harmless-looking utilities or adware-like installers to drive resource theft and secondary payload delivery. This pattern matters because security teams often under-rank low-complexity threats until they become a persistence path. The right response is to measure where software can execute, persist, and call out, then reduce that trust surface before attackers exploit it.

Named concept: trusted execution drift. When signed software, app stores, user approvals and bundled utilities are treated as safe by default, the security model drifts away from actual runtime behaviour. That drift lets malware blend in after install and forces defenders to detect abuse after trust has already been granted. Practitioners should anchor controls to runtime verification rather than installation reputation.

What this signals

Trusted execution drift: when users, stores and signed installers are treated as authoritative by default, the programme shifts from prevention to cleanup. For identity and security teams, that means runtime trust checks, device posture, and access telemetry have to be correlated before the attacker turns a benign-looking app into a persistent control channel.

The recurring use of session-like persistence and outbound control channels means endpoint incidents should be fed into access governance workflows, not just EDR queues. Where malware steals wallet data or captures sensitive activity, the follow-on questions are who approved execution, what privileges were present, and whether the affected session should be considered compromised.

Security programmes that already map privileged access and non-human runtime behaviour will be better positioned to absorb macOS malware trends without overreacting to every alert. The practical shift is toward reducing the number of ways software can inherit trust, then proving that remaining trust is still warranted at runtime.

For practitioners

• Inventory trusted macOS execution paths Map the installers, app store sources, LaunchAgents, LaunchDaemons and Automator workflows that can create persistence or remote control on managed Macs. Prioritise paths that can run without additional user scrutiny, because those are the routes attackers repeatedly abuse.
• Monitor for post-install behaviour changes Alert on signed or user-approved software that suddenly opens outbound command channels, takes screenshots, writes to persistence locations, or spawns shells. The key signal is not the install event itself but the behaviour that follows.
• Tighten user approval and elevation controls Reduce the number of workflows where a user can bless elevated execution for a tool claimed to solve a problem. Require stronger validation for admin prompts, and treat social-engineering success as a governance failure, not just a user mistake.
• Classify malware as an identity event when credentials or sessions are abused If malware touches session tokens, wallet access, browser activity, or privileged user actions, route it into identity and access review as well as endpoint response. That helps connect device compromise to downstream access exposure.

Key takeaways

• macOS malware in 2018 showed that trust in signed apps, stores and user approvals can be abused as effectively as a technical exploit.
• The year’s RATs, trojans and cryptojacking tools repeatedly used persistence and remote control, making runtime trust the real control gap.
• Practitioners should connect endpoint compromise to identity governance, because session abuse, elevated execution and token theft are often part of the same incident.

Key terms

• Remote Access Trojan: A remote access trojan is malware that gives an attacker interactive control over a compromised system after execution. It usually combines a loader, persistence and a command channel so the attacker can issue instructions, exfiltrate data or deploy additional payloads without repeatedly exploiting the target.
• LaunchAgent: A LaunchAgent is a macOS mechanism used to start user-level processes automatically. Attackers abuse it to make malware survive reboots and user logins, turning a one-time execution into persistent access that looks like normal operating behaviour from the system’s point of view.
• LaunchDaemon: A LaunchDaemon is a macOS service that runs in the background, often with elevated privileges and outside a user session. Malware uses it to maintain persistence and execute tasks reliably, which makes it a high-value control point for defenders watching for unauthorised system-level automation.
• Trusted Execution Drift: Trusted execution drift is the gradual weakening of a security model when signed software, approved stores, and user consent are treated as proof of safety. It matters because attackers can exploit the trust signal after installation, not just during delivery, and defenders then inherit a harder runtime problem.

What's in the full article

SentinelOne's full analysis covers the malware families, persistence mechanisms and campaign details this post intentionally leaves at a higher level.

• Family-by-family examples of macOS RATs, including how each one establishes persistence and command and control.
• Campaign descriptions for AppleJeus, WindShift and other 2018 cases, including infection paths and payload behaviour.
• Hands-on defensive guidance for detecting Automator-based trojans, LaunchAgent abuse and reverse-shell activity.
• Context on how cryptomining, spyware and phishing campaigns converged on the macOS platform during the year.

👉 SentinelOne's full article covers the campaign-by-campaign malware details and persistence techniques.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle and secrets management. It helps practitioners connect access control decisions to the broader security programme they support.