Following a recent blog post covering the increasingly common use of compiled AppleScripts in malware, I wanted to explore methods to further hide malicious scripts and reduce the chance of detection.

Resource Forks

Typically when compiling AppleScript or JXA with osacompile the resulting compiled script is output to an .scpt file, which can then be executed with osascript or opened in the Script Editor.app by double clicking. Adding the -x argument to osacompile results in an “execute-only” script, which cannot be edited in the Script Editor and can make for a more painful experience when trying to reverse-engineer the payload.

In part 1 of this series we covered various techniques for stealing session data from the Chrome (and Chromium-based) browsers. In this part we will cover how you can defend against these techniques using a combination of managed policies and endpoint monitoring.

If you’re in an enterprise environment, consider using Chrome Device Trust Connectors for further coverage by restricting access to sensitive applications to a single managed browser.

Hardening Chrome with Enterprise Policies

In enterprise environments, Chrome (and Chromium variants) can be hardened using Chrome Enterprise Policies, making it possible to significantly reduce the browser’s attack surface.

Cookies are the keys to the kingdom - In today’s enterprise and consumer environments, Single Sign-On (SSO) and SaaS applications dominate the web landscape. These platforms heavily rely on session cookies to maintain persistent authenticated states across multiple services and domains.

As a result, post-authentication session cookies have become highly valuable targets for attackers. With the proliferation of U2F MFA adversaries are focussing on the user’s browser as a post-compromise foothold seeking to extract cookies and tokens that grant ongoing access to sensitive systems without triggering additional authentication.

As macOS endpoint controls continue to evolve, adversaries are consistently adapting their TTPs to defeat Apple’s ever-changing security frameworks. Although .dmg files remain a popular initial access vector, the traditional “right-click and open” method has become largely ineffective—especially with the security enhancements introduced in macOS Sequoia.

This analysis delves into some contemporary disk-image malware campaigns, their execution primitives and obfuscation techniques.

The Demise of “Right-Click Open”

The “right-click open” method of bypassing Gatekeeper, while helpful for a long time, has become less useful to attackers. With the advent of macOS Sequoia, Apple significantly tightened the Gatekeeper and notarization requirements. This has made it harder for unsigned or malicious applications to directly execute, even with a user’s explicit attempt to override built-in controls. While this is a positive step for overall security, it has pushed attackers to find new avenues for initial compromise.

In the evolving landscape of macOS security, NorthPoleSec’s Santa has earned a solid reputation as a flexible and lightweight endpoint security tool. Originally developed by Google, Santa acts as a binary whitelisting/blacklisting system, but in recent iterations, it also provides incredibly powerful features including file-access authorization. This lesser-known feature is a game-changer for protecting sensitive data on disk, such as session tokens, SSH keys, and browser cookies.

In this post, we’ll take a look at how Santa’s file access authorization mechanism works and how you can configure it to prevent common threat actor behaviors on macOS endpoints.