Introduction

Attack path management has historically focused on identity systems like Active Directory and Entra ID. That focus made sense. These systems define authentication, authorization, and privilege at scale, and they remain central to how access is granted across an environment. But they are not the full picture. There are entire classes of systems that introduce attack paths that do not exist in the directory.

Device management platforms are one of the most important examples. These systems are responsible for managing endpoints at scale, deploying software, enforcing configuration, and executing administrative actions across entire fleets of devices. In practice, that means they can often execute code directly on managed systems. From an attacker’s perspective, that capability is significant. Control of a device management platform can allow an attacker to execute arbitrary code across endpoints, even when they do not otherwise have a path to those systems through traditional directory relationships.

The same dynamic exists in macOS environments. Organizations with significant macOS deployments rely on platforms like Jamf to manage and control their endpoints. These platforms introduce their own set of attack paths; paths that historically have not been visible in directory-focused analysis. This has created a gap. Organizations with macOS-heavy or macOS-first environments have had limited ways to model how control propagates across their systems. Even in mixed environments, critical portions of the attack surface have remained unmodeled simply because they exist outside of the directory.

That is beginning to change.

Bringing Attack Path Management to macOS Environments

One of the most immediate implications of this expansion is straightforward:

Attack path management now extends to macOS environments.

For many organizations, macOS systems are not a niche component of the environment. They are widely deployed across engineering, security, and executive teams, often representing some of the most privileged and business-critical users in the organization. In some cases, they represent the majority of the environment. In these environments, there often isn’t a central directory that manages devices the way Active Directory does in Windows environments. While identity may be handled by a provider like Okta, the administration and control of macOS systems is typically performed through platforms like Jamf. In practice, this makes the device management platform a primary control layer for the environment. Historically, this created a challenge.

Attack path management has been most effective in environments where directory infrastructure, particularly Active Directory, served as the central point of control. Organizations that were less dependent on those systems, or that operated primarily in macOS and cloud-first environments, had fewer ways to model how control could propagate across their infrastructure. That limitation is no longer necessary. By incorporating macOS device management into the attack graph, organizations can now model attack paths that involve macOS systems directly. This includes paths where control of a management platform can be used to execute code across managed endpoints, as well as paths that originate from those endpoints and extend into other parts of the environment.

This is particularly important because macOS environments are often integrated with cloud identity providers like Okta. In many enterprise environments, Jamf does not operate in isolation. It is commonly integrated with identity providers like Okta to support single sign-on, device enrollment, and lifecycle management for macOS systems. Okta integration with Jamf Pro is not about logging users into macOS devices directly. It is about controlling access to the system that manages those devices. With sufficient privilege in Jamf, that access can be translated into code execution across the fleet. From an attack path perspective, these integrations create connected systems. Control of one can often be leveraged to gain control in the other, forming attack paths that span identity and device management platforms.

Device Management as an Attack Surface

While this expansion brings immediate value to macOS environments, the implications are broader. Jamf is not unique in the role it plays. It is one example of a class of systems responsible for managing and controlling endpoints at scale. Platforms like Microsoft Configuration Manager (SCCM) and Intune serve a similar function in Windows environments, providing centralized mechanisms for deploying software, enforcing configuration, and executing administrative actions across large numbers of devices.

This is not just a theoretical concern. The recent Stryker attack demonstrated how attackers are targeting device management platforms like Intune as high-leverage points of control within enterprise environments. Compromise at this layer can translate directly into broad access across managed endpoints.

These platforms introduce powerful capabilities. They allow administrators to operate across entire fleets of systems, often with elevated privileges and limited friction. In practice, this means they can be used to execute code, modify system state, and influence how endpoints behave, at scale. From an attack path perspective, these capabilities matter. Control of a device management platform can introduce entirely new paths through an environment. In many cases, these paths do not rely on traditional directory relationships at all. Instead, they are derived from the ability to directly control endpoints through the management layer.

This has already been demonstrated in the Windows ecosystem. Research, such as the Misconfiguration Manager project, has shown that platforms like Microsoft Configuration Manager expose attack primitives that can lead to full domain compromise, even though those primitives exist outside Active Directory. Jamf introduces a similar class of risk for macOS environments. By modeling these platforms in the attack graph, we move beyond a directory-centric view of the environment and begin to capture a more complete picture of how control can propagate across systems.

Modeling Jamf in the Attack Graph

To understand why this matters, it helps to look at how a device management platform like Jamf translates into attack paths. Jamf is not just an administrative tool. It is a system designed to control large numbers of endpoints, and that control is expressed through a set of capabilities that can be modeled as attack primitives. When represented in the graph, these primitives become edges, relationships that describe how control over one object can be used to gain control over another. Several categories of primitives stand out.

Privilege Escalation Within the Management Plane

Like most administrative systems, Jamf includes its own permission model. Users, groups, and API clients are granted varying levels of access to perform actions within the platform. In many environments, these permissions are broadly assigned to enable operational efficiency. From an attack path perspective, this creates opportunities for escalation.

An attacker who gains access to a lower-privileged Jamf account may be able to expand their control within the platform, modifying policies, accessing API capabilities, or changing configurations that affect how authentication is handled. In some cases, this includes the ability to modify single sign-on configuration. As detailed in Lance Cain’s research on Jamf attack paths, a principal with the ability to update SSO settings can reconfigure authentication to trust an attacker-controlled identity provider. By manipulating how authentication attributes are mapped, an attacker can gain privileged access within the Jamf environment.

Code Execution Across Managed Endpoints

One of the most powerful capabilities of Jamf is its ability to execute actions across managed devices. This includes:

• deploying scripts
• installing packages
• enforcing configuration changes

In practice, these mechanisms often result in code execution on endpoints, frequently with elevated privileges. From an attack path perspective, this introduces a direct route to system-level control. An attacker who can modify or create policies can execute arbitrary code across one or many devices, without needing traditional access paths to those systems.

This is particularly impactful when those devices belong to high-value users. For example, control over Jamf can be used to execute code on a device associated with a privileged identity in another system, such as an administrator in Okta. This creates a bridge between platforms, where control over device management becomes a path into identity infrastructure.

In the image above, we see three jamf_Account nodes that have the ability to execute code on several managed devices.

Scalable, Fleet-Wide Impact

Device management platforms are designed for scale. A single change, such as updating a policy or modifying a script, can affect hundreds or thousands of systems simultaneously. This changes the nature of attack paths. Rather than progressing system by system, an attacker can operate across large portions of the environment in a single step. A compromise that reaches the management plane can quickly translate into broad control across endpoints.

Hybrid Attack Paths Across Systems

Perhaps the most important aspect of modeling Jamf is what happens when these capabilities intersect with other platforms. In real environments, attackers rarely operate within a single system. They move between identity providers, device management platforms, and other services as they progress toward their objective. This creates hybrid attack paths spanning multiple systems.

We can then identify a path from a non-privileged Active Directory User to one of the jamf_Account nodes that had execution permissions across the fleet.

Example Attack Path

A simplified example illustrates how these paths emerge:

• A low-privileged user gains access to Jamf.
• That access is used to execute code on a macOS device belonging to an Okta administrator.
• The attacker leverages that access to compromise the Okta environment.
• The compromised Okta account is then used to regain elevated access to Jamf.

In this case, privilege escalation is not confined to a single platform. It emerges from their interaction. Other paths may begin in the identity provider itself. Compromise of an Okta administrator, for example, may allow an attacker to assign access to the Jamf application, resulting in authenticated access to the Jamf environment with elevated privileges, even if the attacker did not previously have access to Jamf at all. These are not edge cases. They reflect how modern environments are actually structured: interconnected systems in which control of one platform can be leveraged to gain control of another.

What This Enables in BloodHound Enterprise

By incorporating platforms like Jamf into the attack graph, BloodHound Enterprise expands the set of relationships that can be analyzed and understood. Attack paths are no longer limited to those derived from directory infrastructure. They can now include paths that originate from, traverse through, or depend on device management systems. This has several practical implications.

First, it allows organizations to identify attack paths that were previously invisible. Control over a management platform can now be evaluated alongside more traditional access methods, providing a more complete picture of how an attacker could move through the environment.

Second, it enables prioritization based on real impact. Not all access is equal. The ability to execute code across a fleet of managed devices represents a fundamentally different level of risk than access to a single system. By modeling these relationships directly, organizations can better understand which paths introduce the greatest potential for widespread compromise.

Finally, it reinforces a shift in how environments are understood. Rather than thinking about identity systems, device management platforms, and other technologies in isolation, BloodHound Enterprise models how they interact, how control in one system can be leveraged to gain control in another.

Expanding the Model

The addition of Jamf is not about a single platform. It reflects a broader shift in how attack paths are modeled. Modern environments are composed of multiple systems that each introduce their own control planes. Some of these systems have been well understood for years. Others have only recently been explored from an attack path perspective. Device management platforms are a clear example of the latter.

Work in the Windows ecosystem has already demonstrated the impact of platforms like Microsoft Configuration Manager. Extending this model to macOS environments via Jamf shows that the same patterns hold across platforms. As organizations continue to adopt new technologies, additional systems will emerge that introduce meaningful control over the environment. Each of these systems represents a potential source of attack paths. The goal is to model them accordingly.

Getting Started

This new extension provides an opportunity to extend attack path analysis into areas of the environment that may not have been previously considered, particularly for organizations with significant macOS deployments.

If you are already using BloodHound Enterprise, we recommend working with your Account Manager to upgrade to the new BloodHound Enterprise – which includes support for Okta, Jamf, and GitHub – and begin incorporating this data into your environment and exploring the attack paths revealed.

For organizations that have not yet adopted BloodHound Enterprise, this represents a broader shift in how identity risk can be understood.

Attack path management is no longer limited to traditional directory environments. It now reflects the full set of systems that define and control access across modern infrastructure, including macOS environments and the platforms used to manage them.