Leveraging Jamf for Red Teaming in Enterprise Environments

Leveraging Jamf for Red Teaming in Enterprise Environments

Speakers: Lance Kane, Service Architect, SpecterOps; Dan Mayer, Security Researcher, SpecterOps

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=IDFeNbz2lI4

Reading time: 9 min

Type: Briefing

TL;DR

SpecterOps researchers Lance Kane and Dan Mayer revealed that Jamf Pro — the dominant mobile device management platform in enterprise macOS environments — can be systematically abused for privilege escalation, lateral movement, and persistent code execution, often undetected by modern EDRs. They released two open-source tools at the talk: Eve, a purpose-built Jamf attack toolkit, and Jamf Hound, a BloodHound-compatible graph-based attack path mapper for Jamf environments.

Introduction

Jamf Pro manages macOS devices across thousands of enterprise environments, and its target demographic is telling: it is most commonly deployed in technology companies and large enterprises with strong developer teams. That means the endpoints under Jamf management are disproportionately owned by cloud administrators, senior engineers, and others with elevated privileges and sensitive access — exactly the accounts red teams and adversaries most want to compromise.

Kane and Mayer spent the last year conducting red team engagements across Fortune 500 clients where macOS was present, building a systematic understanding of how Jamf's management capabilities can be turned against the organizations using them. Their core finding: Jamf is rarely monitored, its credentials are routinely exposed in places where developers get lazy (Git commits, S3 buckets, shell history), and once an attacker holds Jamf credentials, they have a remarkably powerful execution primitive that bypasses most EDR detection.

The session included live CLI and UI demonstrations of their tooling and closed with concrete defensive recommendations developed in coordination with the Jamf security team.

Why Jamf Is a High-Value Target

▶ Watch: Jamf in Enterprise Environments (02:00)

Kane opened by explaining the structural reason Jamf represents such an attractive attack surface. The platform is almost always configured once and then left alone — IT administrators enroll devices, push policies, and update group memberships, but rarely revisit the configuration baseline for security review. "Once it's working, we don't really touch it," Kane said, describing the common posture.

This configuration drift is compounded by cloud enrollment: many organizations have Jamf credentials embedded in automation pipelines, infrastructure-as-code repos, and cloud storage in ways that long predate secrets management best practices. In one engagement, the SpecterOps team found Jamf credentials in a Git commit and used them to execute code undetected across an entire macOS fleet against "one of the most popular modern EDRs" for six to seven weeks. In subsequent assessments, the team deliberately searched for Jamf credentials in Git commits, S3 buckets, and cloud-hosted storage as a first-pass technique — and "it continued to pay dividends."

The reason EDR evasion is so reliable is structural: endpoint detection tools have to accommodate Jamf's legitimate management behavior. Jamf does a lot of "weird stuff" that, from an EDR perspective, looks like privileged system activity — because it is. Distinguishing malicious Jamf API calls from routine administrative operations is a fundamentally hard detection problem.

Jamf's Permission Model and Attack Graph Fundamentals

▶ Watch: Jamf Permission Model Explained (04:00)

Jamf Pro offers two principal types of API access. JSS object permissions govern create, read, update, and delete operations on management objects — scripts, policies, packages, computer records, and groups. JSS settings permissions cover the Jamf server itself, such as certificate rotation and check-in frequency. Kane and Mayer focused almost entirely on JSS object permissions, where they found the most impactful attack paths.

Every JSS object type has a corresponding API endpoint accessible over standard HTTP/HTTPS methods (GET, PUT, POST, DELETE), with payloads submitted as JSON or XML. This means that any principal with the right permissions can interact with Jamf programmatically, without ever logging into the web UI — and that interaction is often poorly monitored.

Mayer introduced Jamf Hound, which models the Jamf environment as a BloodHound-compatible graph. On the left of the graph are Jamf principals (local accounts, API clients, group memberships); in the middle are the objects they can modify (scripts, policies, extension attributes, packages); on the right are the macOS endpoints those objects can execute against. Attack paths become visible: an attacker who compromises a site admin account with script-creation rights can trace a path to code execution on any device that admin manages.

Privilege Escalation via the Jamf API

▶ Watch: Privilege Escalation Techniques (12:01)

Kane walked through two privilege escalation paths, each with a live Eve CLI demonstration.

Account manipulation. If a compromised Jamf principal holds create accounts or update accounts permissions, it can create new local Jamf accounts with arbitrary privileges (including full administrator), or reset the password on existing accounts to assume their access. A critically important nuance: in the Jamf UI, create accounts and update accounts permissions are linked — enabling one automatically enables the other. Automation accounts (Terraform service accounts are a common real-world example) frequently carry these permissions without administrators realizing the implication.

In the live demo, Kane authenticated to a Jamf tenant using Eve with a compromised Terraform account (ID 13) and demonstrated reading the account's privilege list, confirming it held both create accounts and update accounts, then using a template to modify the account's privileges — escalating from a constrained service account to effectively full administrative access.

API client and role manipulation. The second path targets Jamf's API clients. If a compromised principal can create or update API roles and API clients (called "integrations" in the UI), it can synthesize a new client with any permissions, generate credentials for it, and authenticate as that client. This allows an attacker to create a persistent backdoor API credential with whatever Jamf capabilities they need, entirely within normal Jamf administrative operations.

Code Execution Primitives

▶ Watch: Code Execution via Scripts and Policies (20:02)

Mayer covered three distinct execution primitives, each representing a different Jamf feature that can be weaponized for code execution on managed endpoints.

Script + Policy. The most common path, and the one SpecterOps encountered most often in legitimate Jamf admin forums. An attacker creates a script object (any interpreted language, using any interpreter expected on the endpoint), then creates a policy that references that script and scopes it to target devices. The policy trigger is set to the next check-in, which by default occurs every fifteen to twenty minutes. Code executes silently on targeted machines under Jamf's trusted management context. In the Eve UI demonstration, Mayer showed targeting by username search rather than by device ID, making it easy to pursue specific high-value users across the fleet.

Run Command tag. An underdocumented feature of Jamf's policy XML: a <run_command> tag that executes a one-liner shell command directly, without requiring a script object. This reduces the permission set needed for execution — no script-creation rights required, only the ability to create or modify policies. The implication is that organizations that identify and remove all execute script edges from their attack graph using Jamf Hound are still not fully protected: the run command path remains.

Computer Extension Attributes. The most impactful primitive for fleet-wide execution. Extension attributes are a Jamf feature that pushes a script to every managed device during inventory collection (the jamf recon command, which runs every twenty-four hours by default). Any extension attribute an attacker creates will execute on every machine Jamf manages — not scoped to specific targets. Mayer demonstrated creating an extension attribute with a mock payload: "Imagine this is a crypto miner. Extension attributes are a great way to get your Monero balance up relatively quickly." The execution scope makes this primitive particularly dangerous for destructive or financially motivated actors.

Defensive Recommendations

▶ Watch: Defensive Guidance and Jamf Coordination (30:03)

Kane and Mayer closed with concrete defensive guidance, developed in collaboration with the Jamf security team, who proactively reached out to SpecterOps when the talk was announced.

Audit access and review logs. JSS access logs and Tomcat access logs record every API hit against the Jamf server. In cloud Jamf deployments, the Jamf support team can search these logs on request, and a paid log-forwarding service exists for organizations that want real-time visibility.

Monitor object changes. Changes to scripts, policies, extension attributes, and accounts are the primary indicators of Jamf-based attack activity. Integrating Jamf object change events into SIEM pipelines gives defenders a detection surface they can actually trace back to the initial compromised principal.

Rotate and time-gate API credentials. In every red team engagement, credentials were found in places they should not be (shell history, cloud storage). Time-limited credentials render those finds useless. Rotate Jamf API credentials on a schedule and enforce short TTLs where possible.

Firewall Jamf API endpoints. Restrict which source addresses can hit privileged Jamf API endpoints. Create bastion hosts for administrative operations so that credentials found on a compromised endpoint cannot be immediately reused from an attacker-controlled machine.

Run Jamf Hound against your tenant. The BloodHound-compatible collector maps the full attack graph of a Jamf environment, showing which principals can reach which execution edges. Running it proactively is the fastest way to identify overpermissioned service accounts and API clients before a red team does.

Notable Quotes

"Anything's stealthy until someone's looking for it."

— SpecterOps colleague Lee, cited by Lance Kane [[▶ 10:00]](https://www.youtube.com/watch?v=IDFeNbz2lI4&t=600s)

"We went months undetected against big-name EDR vendors protecting customer environments, moving across macOS."

— Lance Kane [[▶ 04:00]](https://www.youtube.com/watch?v=IDFeNbz2lI4&t=240s)

"If you compromise any type of Jamf principal that can interact with those resources and deploy packages, your malware is now getting code-signed and treated with the same validity as their internal software."

— Lance Kane [[▶ 10:00]](https://www.youtube.com/watch?v=IDFeNbz2lI4&t=600s)

"Extension attributes are a great way to get your Monero balance up relatively quickly."

— Dan Mayer [[▶ 30:03]](https://www.youtube.com/watch?v=IDFeNbz2lI4&t=1803s)

Key Takeaways

• Jamf credentials in Git commits, S3 buckets, and shell history are a critical exposure. Treat Jamf API credentials as privileged secrets equivalent to domain admin passwords, rotate them regularly, and enforce time-limited TTLs.
• Three execution primitives exist independently of each other. Eliminating script-creation rights does not prevent code execution via policy run commands or extension attributes — all three attack paths must be addressed.
• Extension attributes execute fleet-wide. A single malicious extension attribute runs on every Jamf-managed device within twenty-four hours, making it the highest-blast-radius primitive in the toolkit.
• EDR products do not reliably detect Jamf abuse. Because legitimate Jamf management activity is structurally indistinguishable from malicious operations, detection must come from Jamf-native log monitoring and change detection rather than endpoint telemetry.
• Two open-source tools are now publicly available: Eve (Jamf attack toolkit, Python-based) and Jamf Hound (BloodHound-compatible attack graph mapper). Defenders should run Jamf Hound against their tenants immediately to understand their attack surface.

Slides: No slides PDF is available for this session.