While reading this blog post over Christmas, I learned of a VS Code feature that I was previously unaware of. According to the official documentation the tasks feature is intended to provide a bridge between VS Code and external applications for task automation, such as running builds without leaving the IDE. However, as discussed in the Open Source Malware post, attackers are abusing this feature to trigger execution of shell commands when the repo is opened in the IDE.

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.