While browsing a GitHub repository recently, I noticed a feature with potential as a social engineering vector for payload delivery: a badge providing an almost single-click method to install an arbitrary Model Context Protocol (MCP) server directly from a README.md.

Further investigation confirms this is the documented and preferred method for distributing MCP servers.

Under The Hood

These badges simply link to insiders.vscode.dev/redirect/mcp/install using a specific schema:

https://insiders.vscode.dev/redirect/mcp/install?name=<NAME>&config={"command":"<COMMAND>","args":["<ARG1>","<ARG2>"]}

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.