{ "version": "https://jsonfeed.org/version/1.1", "title": "cyberbuff", "description": "Developer, hacker, and open source contributor.", "home_page_url": "https://cyberbuff.dev", "feed_url": "https://cyberbuff.dev/feed.json", "language": "en-US", "authors": [ { "name": "cyberbuff", "url": "https://cyberbuff.dev" } ], "items": [ { "id": "https://cyberbuff.dev/blog/loas", "url": "https://cyberbuff.dev/blog/loas", "title": "Living Off the Orchard: AppleScript", "summary": "Offensive security testing framework for macOS that provides MITRE ATT&CK-mapped atomic tests using AppleScript and JXA techniques across multiple execution methods.", "content_html": "

Attackers can leverage built-in macOS tools like AppleScript and JXA (JavaScript for Automation) to access credentials, capture screenshots, and establish persistence without installing custom tools. Can your security controls detect these techniques?

\n

Living Off the Orchard: Apple Script (LOAS) is a library of AppleScript and JXA tests mapped to the MITRE ATT&CK® framework that helps you answer that question. Security teams can use LOAS to quickly, portably, and reproducibly test their macOS environments using multiple execution methods, each generating different endpoint security logs.

\n

Who Should Use LOAS?

\n\n

Getting Started

\n

Ready to start testing? The easiest way is to download pre-built artifacts from GitHub releases:

\n
Terminal window
# Download pre-built tests from releases
# https://github.com/cyberbuff/loas/releases/latest
\n
# Execute your first test through any of the following methods:
osascript -e 'short user name of (system info)' -e 'long user name of (system info)'
osascript get_user_using_system_info.scpt
swift get_user_using_system_info.swift
./get_user_using_system_info
\n

The GitHub Actions workflow automatically generates all the artifacts needed for testing. However, if you want to compile them yourself:

\n
\n

⚠️ Security Warning: All LOAS tests should only be run in isolated lab environments or with explicit authorization. These techniques can trigger security alerts and modify system state.

\n
\n
Terminal window
# Clone and setup
git clone https://github.com/cyberbuff/loas.git
cd loas
uv sync
\n
# Validate all tests
uv run main.py validate
\n
# Generate all test artifacts
uv run main.py build
\n
# Execute your first test
osascript osascripts/T1033/get_user_using_system_info.scpt
\n

For detailed instructions on writing YAML tests and contributing, see the LOAS documentation.

\n

LLM-Optimized Documentation

\n

Ready to use with Claude, ChatGPT, or Gemini right out of the box.

\n\n

Sample Prompt:

\n
\n

Read https://loas.dev/llms-full.txt. I want to ask questions about the techniques.

\n
\n

Roadmap

\n

LOAS is actively evolving with planned enhancements:

\n\n

Conclusion

\n

As macOS continues to grow in enterprise environments, understanding and defending against AppleScript and JXA abuse becomes increasingly critical. LOAS provides security teams with the tools needed to:

\n\n

Resources

\n\n
\n

MITRE ATT&CK® is a registered trademark of The MITRE Corporation.

\n

Want to contribute or have questions? Open an issue on GitHub or reach out on X @cyb3rbuff

\n

All my content is cross posted to both cyberbuff.dev/blog and Substack. The custom blog supports hierarchical subposts with integrated table of contents, enabling readers to navigate complex topics or skip familiar sections. While Substack lacks this UI customization, it provides better subscription management and notifications. I maintain both platforms to serve different reader preferences, so use whichever suits you best.

", "image": "https://cyberbuff.dev/_astro/banner.D7XnSvf8.png", "date_published": "2025-11-27T00:00:00.000Z", "date_modified": "2025-11-27T00:00:00.000Z", "tags": [ "Security", "macOS", "AppleScript", "Adversary Emulation" ] }, { "id": "https://cyberbuff.dev/blog/loas/execution-methods", "url": "https://cyberbuff.dev/blog/loas/execution-methods", "title": "Execution Methods", "summary": "Learn how to execute LOAS tests using various methods and understand how each creates different detection telemetry.", "content_html": "

As discussed in the macOS Security Primer, AppleScript and JXA are powerful automation tools that can be weaponized by attackers. Understanding how these techniques appear in your security logs is critical for detection engineering.

\n

LOAS tests can be executed using five different methods, each creating distinct forensic artifacts and detection opportunities:

\n
    \n
  1. CLI (osascript -e) - Direct command-line execution
    2. \n
  2. Script files (.scpt) - Pre-saved AppleScript files
    3. \n
  3. Swift wrappers (.swift) - AppleScript embedded in Swift
    4. \n
  4. Applet (.app) - Packaged as macOS applet bundles
    5. \n
  5. Compiled binaries - Standalone executables
    6. \n
\n

These execution methods are documented in detail in the Red Canary Threat Detection Report. This documentation builds upon and expands their work.

\n

Each method creates different traces in your security logs like different parent-child process relationships, file system events, and security audit logs. Understanding these variations is critical for building comprehensive detection rules.

\n

The GitHub releases page provides all of these different files for each test.

\n

If you would like to compile the files yourself, install uv and then use the following commands:

\n
Terminal window
git clone https://github.com/cyberbuff/loas.git
cd loas
uv sync
uv run main.py build
\n

Each of these methods generates a different set of logs based on the execution tool.

\n

The sample Endpoint Security logs below were gathered using Mac Monitor for each execution method when retrieving clipboard content.

\n

CLI

\n

This is the simplest way to execute commands from this repository.

\n
Terminal window
osascript -e "the clipboard"
\n
\"CLI\"
\n

Script

\n

Download the script from the releases page and execute it with osascript.

\n
Terminal window
osascript get_clipboard_content_using_applescript_defaults.scpt
\n
\"File\"
\n

Swift

\n

Download the Swift file from the releases page and execute it with Swift.

\n

Note: You might need to install Xcode Developer Tools to run Swift files.

\n
Terminal window
swift get_clipboard_content_using_applescript_defaults.swift
\n
\"Swift\"
\n

Applet

\n

Download the .app file from the releases page and execute it.

\n
Terminal window
open -n get_clipboard_content_using_applescript_defaults.app
\n
\"App\"
\n

Binary

\n

Download the binary from the releases page and execute it.

\n
Terminal window
./get_clipboard_content_using_applescript_defaults
\n
\"Binary\"
", "date_published": "2025-11-27T00:00:00.000Z", "date_modified": "2025-11-27T00:00:00.000Z", "tags": [ "Security", "macOS", "AppleScript", "Adversary Emulation" ] }, { "id": "https://cyberbuff.dev/blog/loas/primer", "url": "https://cyberbuff.dev/blog/loas/primer", "title": "macOS Security Primer", "summary": "Understanding Living Off the Orchard attacks and why AppleScript/JXA techniques require specialized testing frameworks for macOS security.", "content_html": "

What is “Living Off the Land/Orchard”?

\n

“Living off the land” is a cybersecurity term describing attacks that use legitimate, pre-existing system tools instead of custom tools. Rather than bringing their own malicious software, attackers leverage the binaries, scripts, and libraries already installed on target systems. “Living Off the Orchard” is the macOS-specific variant of this concept - a play on Apple’s association with orchards.

\n

Why Attackers Choose This Approach

\n\n

What Can AppleScript/JXA Do?

\n

AppleScript and JXA are powerful automation tools pre-installed on every Mac. While designed for legitimate system administration, these capabilities can be weaponized for:

\n\n

Why a Dedicated AppleScript Testing Framework?

\n

While LOOBins and Atomic Red Team provide extensive macOS coverage, AppleScript and JXA deserve specialized focus.

\n

Making LOAS a separate framework allows for:

\n\n

Real-World Threat Landscape

\n

Threat actors have consistently demonstrated the effectiveness of AppleScript and JXA in real-world attacks:

\n\n

See It In Action

\n

Here’s an example of how AppleScript can be used to prompt for credentials:

\n
set userPassword to text returned of (display dialog "macOS Security Update" & return & "Enter your password to continue:" default answer "" with icon 1 with hidden answer)
-- Credential now captured in userPassword variable
\n

\"Credential

\n

To your users, this looks like a legitimate system prompt. To your SIEM, it might look like nothing at all.

", "date_published": "2025-11-27T00:00:00.000Z", "date_modified": "2025-11-27T00:00:00.000Z", "tags": [ "Security", "macOS", "AppleScript", "Adversary Emulation" ] }, { "id": "https://cyberbuff.dev/blog/atomic-red-team-mcp/claude-becomes-c2", "url": "https://cyberbuff.dev/blog/atomic-red-team-mcp/claude-becomes-c2", "title": "Claude becomes C2", "summary": "Breaking Everything, Everywhere, All at Once", "content_html": "

Purple team exercises face a fundamental challenge: while attacks have become more sophisticated and cross-platform, our testing approaches remain fragmented. Security teams juggle platform-specific tooling, manual result correlation, and the constant context switching between testing environments.

\n

The solution? AI-powered orchestration that transforms rigid automation into intelligent, conversational security testing. In this post, you’ll discover how to transform your AI assistant into a multi-platform threat orchestrator that can simultaneously execute atomic tests across Windows, Linux, and macOS. We’ll walk through:

\n\n

By the end, you’ll have Claude coordinating distributed atomic tests across your entire infrastructure through simple natural language commands like “Execute System Network Configuration Discovery atomics on all platforms and give me a consolidated report.”

\n
\n

This post continues from Part 1, where we saw how Claude transforms from a helpful AI assistant into a sophisticated adversary emulation engine. Now, we’re taking it to the next level: multi-platform orchestration.

\n

Most foundational concepts—such as what MCP is, how Atomic Red Team MCP works, and the core introductory use cases—are thoroughly explained in Part 1 of this series. If you haven’t read Part 1 yet, I recommend starting there to get essential background before exploring the advanced orchestration techniques and multi-platform workflows described in this post.

\n

The Multi-Platform Challenge

\n

Adversary emulation has evolved beyond manual coordination—tools like OpenAEV, Caldera, and other adversary emulation platforms already solve the basic multi-platform execution problem. You can absolutely orchestrate execution of atomic tests across Windows, Linux, and macOS using these established frameworks.

\n

But here’s what’s still missing: intelligent, conversational orchestration.

\n

Current tools require you to:

\n\n

Want to test registry persistence on Windows, then immediately adapt based on results? You’re still configuring playbooks, navigating web interfaces, or scripting custom logic.

\n

The real breakthrough isn’t just orchestration— it’s AI-powered orchestration that can analyze, learn, and adapt to your testing needs. What if you could simply say: "Execute registry persistence on Windows, analyze the logs using Splunk MCP, then recommend and run the best Linux persistence technique that would fit this attack scenario XYZ"?

\n

That’s where MCP orchestration transforms the game. You get the infrastructure orchestration of existing tools combined with the intelligent reasoning of LLMs, all through natural language instead of configuration files.

\n

Enter the Cross-Platform C2… Er, AI Assistant

\n

What if you could coordinate atomic tests across all platforms simultaneously using natural language? What if Claude could become your universal threat orchestrator, speaking fluent Windows, Linux, and macOS?

\n

That’s exactly what multiple MCP servers enable. By running Atomic Red Team MCP servers on different platforms and connecting them to a single AI assistant, you create a unified testing interface that enables centralized command and distributed execution.

\n

Here’s the architecture that makes it possible:

\n

\"Multi-platform

\n

Setting Up Your Distributed Testing Infrastructure

\n

Prerequisites

\n

Before You Begin

\n

Ensure you have the following installed on each target platform:

\n

All Platforms:

\n\n

Client Machine:

\n\n

Network Requirements:

\n\n

Optional but Recommended:

\n\n

Step 1: MCP Server Deployment

\n

Deploy MCP servers across your target platforms (Windows, Linux, and macOS). Make sure to save the authentication tokens from each deployment as these are needed to connect your AI assistant to the servers.

\n

💡 Tip: Always test in a lab before deploying on production systems

\n

Windows deployment (PowerShell):

\n
Terminal window
# Install uv
\n
powershell -ExecutionPolicy ByPass -c “irm https://astral.sh/uv/install.ps1 | iex”
\n
# Generate secure authentication token
\n
$TOKEN = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 32 | ForEach-Object {[char]$\\_})
Write-Host "Windows server token: $TOKEN" -ForegroundColor Green
\n
# Configure and launch
\n
$env:ART_MCP_TRANSPORT = "streamable-http"
$env:ART_EXECUTION_ENABLED = "true"
$env:ART_MCP_PORT = "8000"
$env:ART_MCP_HOST = "0.0.0.0"
$env:ART_AUTH_TOKEN = $TOKEN
\n
uvx atomic-red-team-mcp
\n

Linux Deployment

\n
Terminal window
# Install uv
\n
curl -LsSf https://astral.sh/uv/install.sh | sh
\n
# Generate secure token
\n
TOKEN=$(openssl rand -hex 32)
echo "Linux server token: $TOKEN"
\n
# Configure environment
\n
export ART_MCP_TRANSPORT="streamable-http"
export ART_EXECUTION_ENABLED="true"
export ART_MCP_PORT="8000"
export ART_MCP_HOST="0.0.0.0"
export ART_AUTH_TOKEN=$TOKEN
\n
uvx atomic-red-team-mcp
\n

macOS Deployment

\n
Terminal window
# Generate secure token
\n
TOKEN=$(openssl rand -hex 32)
echo "macOS server token: $TOKEN"
\n
# Launch server
\n
export ART_MCP_TRANSPORT="streamable-http"
export ART_EXECUTION_ENABLED="true"
export ART_MCP_PORT="8000"
export ART_MCP_HOST="0.0.0.0"
export ART_AUTH_TOKEN="$TOKEN"
\n
uvx atomic-red-team-mcp
\n

Verify whether the MCP servers are running.

\n

Test each server

\n
Terminal window
curl http://10.2.20.14:8000/health # Windows
curl http://10.2.20.15:8000/health # Linux
curl http://10.2.20.16:8000/health # macOS
\n
\n

Note: These commands are for initial setup and testing. For production use, implement proper service management with systemd, scheduled tasks, or launch daemons.

\n
\n

Step 2: Enable Unified Control

\n

Next, you’ll connect all servers to your AI assistant. Replace the bearer tokens in the configuration below with the tokens you saved from the previous step.

\n
{
  "mcpServers": {
    "atomic-windows": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://10.2.20.14:8000/mcp",
        "--header",
        "Authorization: Bearer abc......windows",
        "--allow-http"
      ]
    },
    "atomic-linux": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://10.2.20.15:8000/mcp",
        "--header",
        "Authorization: Bearer def......linux",
        "--allow-http"
      ]
    },
    "atomic-macos": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://10.2.20.16:8000/mcp",
        "--header",
        "Authorization: Bearer ghi......macos",
        "--allow-http"
      ]
    }
  }
}
\n

Restart your client, and Claude will have direct access to atomic testing capabilities across all three major operating systems.

\n

Multi-Platform Attack Scenarios

\n

Scenario 1: Run Persistence atomics across all platforms

\n

Imagine simulating an adversary who establishes persistence on Windows through registry manipulation, then moves to a Linux system using cron jobs:

\n

Execute registry persistence atomic test on atomic-windows server, then immediately follow up with a cron persistence test on atomic-linux server

\n

Claude coordinates both attacks:

\n\n

Here is a sample output on what that would look like.

\n

\"Multiplatform

\n

Scenario 2: Detection Rule Validation

\n

Ever wondered how to efficiently execute atomic tests across Windows, Linux, and macOS—and get immediate validation results for your entire detection stack?

\n

For example: Want to assess your detection coverage against “Living off the tunnels” techniques? Run Cloudflare tunnel atomics on every major platform and instantly check whether your rules trigger the right alerts

\n

My detection rule targets Cloudflare tunnels. Find and execute Cloudflare tunnel atomics on atomic-windows, atomic-linux, and atomic-macos to validate detection coverage across platforms.

\n

After execution, query Splunk MCP and see whether there are any alerts for Cloudflare Tunnels.

\n

Claude will

\n
    \n
  1. Query: Queries and retrieves the atomic GUIDs for Cloudflare tunnel across all MCPs.
    2. \n
  2. Execution: Automatically finds and executes the Cloudflare tunnel atomic across Windows, Linux, and macOS.
    3. \n
  3. Detection: Checks Splunk MCP for any new Cloudflare alerts triggered by these activities.
    4. \n
  4. Reporting: Summarizes the entire lifecycle of the attack, from execution all the way to detection outcomes.
    5. \n
\n

\"Attack

\n

Scenario 3: Threat Intelligence to Multi-Platform Playbook

\n

Remember those advanced prompts from Part 1? They become even more powerful with multiple platforms:

\n

Analyze this threat intelligence report and find platform-specific atomic tests. Execute Windows-specific TTPs on atomic-windows, Linux TTPs on atomic-linux, and macOS TTPs on atomic-macos. Provide a unified execution report.

\n

Claude will:

\n
    \n
  1. Parse the threat intel for TTPs
    2. \n
  2. Map TTPs to platform-specific atomic tests
    3. \n
  3. Execute tests on appropriate platforms
    4. \n
  4. Generate a comprehensive multi-platform assessment
    5. \n
\n

\"Threat

\n

What’s Next?

\n

This enables several use cases:

\n\n
summary_svg:last-child]:rotate-180 [&[open]>summary]:mb-3\" open>Important

With great power comes great responsibility. Use these capabilities in\nisolated, controlled environments, on systems you own or have explicit\npermission to test.

\n

This AI-powered orchestration approach opens up many possibilities, and I am curious about your experiences:

\n\n

Additional Resources

\n", "date_published": "2025-11-04T00:00:00.000Z", "date_modified": "2025-11-04T00:00:00.000Z", "tags": [ "Security", "Atomic Red Team", "MCP", "Adversary Emulation" ] }, { "id": "https://cyberbuff.dev/blog/atomic-red-team-mcp", "url": "https://cyberbuff.dev/blog/atomic-red-team-mcp", "title": "Atomic Red Team MCP", "summary": "Use Atomic Red Team MCP server to create, query, and execute atomics from Atomic Red Team", "content_html": "

Hello everyone! 👋

\n

I’m excited to release the Atomic Red Team MCP Server - a tool that has transformed my adversary emulation workflow significantly. But before diving into the technical details, let me tell you why I built this.

\n

⚠️ The Problem That Sparked This Tool

\n

As someone who regularly works with threat intelligence and detection engineering, I found myself repeating the same tedious process over and over.

\n

You probably know this pain too:

\n

You get threat intel about a new ransomware campaign. First, you spend 20 minutes sifting through atomic-red-team and others, searching for tests that match the TTPs. Half the time, the perfect test doesn’t exist. So you craft a custom test, validate the YAML syntax, execute it in your lab, debug why it failed, fix the test, run it again, and finally confirm it triggers your detection rules.

\n

What should be a 5-minute task turns into hours of manual work. There had to be a better way. This is where AI-powered automation changes everything.

\n

🤖 Enter AI-Powered Adversary Emulation

\n

What if I could just ask my AI assistant to handle all of this? Instead of manually searching and creating tests, what if I could simply say:

\n\n

The Atomic Red Team MCP Server makes exactly this possible. It brings 1500+ atomic tests directly into Claude, VSCode, Cursor, and other AI assistants, transforming security testing from manual grunt work into natural conversations, reducing multi-hour processes to minutes.

", "image": "https://cyberbuff.dev/_astro/banner.BmR21x4n.png", "date_published": "2025-10-31T00:00:00.000Z", "date_modified": "2025-10-31T00:00:00.000Z", "tags": [ "Security", "Atomic Red Team", "MCP", "Adversary Emulation" ] }, { "id": "https://cyberbuff.dev/blog/atomic-red-team-mcp/claude-becomes-the-apt", "url": "https://cyberbuff.dev/blog/atomic-red-team-mcp/claude-becomes-the-apt", "title": "Claude becomes the APT", "summary": "Breaking Things with Atomic Red Team MCP because manual exploitation is so last decade", "content_html": "

💭 What Is MCP?

\n

Model Context Protocol (MCP) allows AI assistants like Claude to directly interact with external tools and databases instead of relying on copy-paste workflows between systems. Before MCP, you’d search GitHub for atomic tests, copy YAML to Claude, get responses, then manually transfer everything back to your terminal - essentially acting as a human API bridge.

\n

With MCP, Claude can directly query atomic test databases, validate YAML syntax, and execute commands within the same conversation context. It’s like giving your AI assistant API access to your security toolchain rather than making it work through you as a proxy. This eliminates the context-switching overhead that kills productivity in security workflows.

\n

✨ Key Features

\n\n

⚡ Real World Scenarios

\n

Ready for some practical magic? Here’s what becomes possible:

\n

Scenario 1: Threat Intel Analysis

\n

You receive a threat report about the new macOS Stealer. You need to test your defenses.

\n

Try this:

\n
summary_svg:last-child]:rotate-180 [&[open]>summary]:mb-3\" open>Example

Analyze the threat intelligence report at threat-intel-report-link-here. First, identify all TTPs mentioned in the report and cross-reference them against the existing Atomic Red Team library to find matching atomic tests. For any TTPs that don’t have corresponding atomics, generate new atomic tests. Finally, compile everything into a structured playbook YAML file with entries formatted as:

- auto_generated_guid: abcdef-abcd-abcd-abcd-abcdef
  name: Atomic Test name 1
  technique_id: T1000
\n
- auto_generated_guid: abcdef-abcd-abcd-abcd-abcdef
  name: Atomic Test name 2
  technique_id: T1000
\n

\"Threat

\n

Behind the scenes, the AI assistant will

\n\n

Traditional approach: 45+ minutes, with MCP: 5-10 minutes

\n

Scenario 2: Detection Rule Validation

\n

Your team deployed a new detection rule targeting Cloudflare tunnel abuse - a technique increasingly used by threat actors for persistence and C2 communication.

\n
summary_svg:last-child]:rotate-180 [&[open]>summary]:mb-3\" open>Example

I need to test my ‘Cloudflared Tunnel Execution’ detection rule that flags\ncloudflared tool usage for maintaining persistence. Find existing atomic tests\nthat would trigger this, or create a new test using techniques from\nhttps://lottunnels.github.io/lottunnels/Binaries/cloudflared/

\n

What your AI assistant delivers:

\n\n

\"Detection

\n

Traditional approach: 30+ minutes, with MCP: 3-5 minutes

\n

🛠️ Troubleshooting

\n

AI not recognizing your requests? Add “using atomic-red-team MCP” to your prompt. If issues persist, start a fresh chat conversation.

\n

🚧 Limitations

\n\n

🎉 Ready to streamline your security testing?

\n\n

\"Watch

\n

Give it a try!

\n

Coming next: Run Atomic Red Team MCPs across Windows, Linux, and macOS with centralized AI assistant control

\n

Note: Huge thanks to Michael Haag for the inspiration with his “Claude found the APT” work - I’m totally borrowing his clever naming convention for “Claude becomes the APT.”

", "date_published": "2025-10-31T00:00:00.000Z", "date_modified": "2025-10-31T00:00:00.000Z", "tags": [ "Security", "Atomic Red Team", "MCP", "Adversary Emulation" ] } ] }