JumpCloud(link), a cloud directory service, shares many similarities with Active Directory and offers efficient capabilities. In this post, we aim to provide clarity on a pressing question:

How quickly can we detect a compromised JumpCloud Administrator API token or Admin account, and why is it crucial?

Recent events, such as JumpCloud’s own security breach [link], have underscored the importance of early detection and monitoring in such scenarios. During their breach incident, it was revealed that their internal commands framework had been compromised, leading to the deployment of a malicious script into customer environments.(here) , based on the incident details provided by JumpCloud & Mandiant, we could infer Jumpcloud Internal Employee who had access to production database was compromised via spear phishing ,abusing his access, several malicious command jobs were scheduled on handful of JC customers organisation’s endpoints via database injection which finally resulted in infection of victims. This incident serves as a stark reminder for customers to enhance their monitoring of the JumpCloud network.

Furthermore, the growing trend of threat actors exploiting legitimate tools for command and control makes it imperative for the broader security community to be informed about ways to monitor such tools effectively.

This post is structured to provide insights for both offensive and defensive teams. It offers an overview of JumpCloud (JC) network, insights into the attacker’s perspective, and guidance on building monitoring capabilities for defenders.

Below are my personal notes and key takeaways from a recent engagement I participated in to help Detection team build monitoring around JumpCloud acting as an adversary.

Introduction:

JumpCloud’s similarity to Active Directory is notable. A JumpCloud Admin account can be equated to a Domain Admin Account in an Active Directory environment, granting extensive access to the entire JumpCloud network. The longer a threat actor remains undetected within the network, the more damage they can inflict. Therefore, it is of utmost importance to establish robust monitoring systems around JumpCloud to promptly identify and contain any anomalous behaviour.

To simplify the components and workflow of JumpCloud(JC) in comparison to traditional AD, there are several key elements:

1. User Objects: These represent individual users and their credentials.
2. System Objects: These represent machines or devices that are enrolled in JumpCloud.
3. User Groups: These are collections of users grouped together for various purposes, such as “devs,” “sysadmins,” or “marketing.”
4. System/Device Groups: These are collections of systems or devices, like servers or end-user machines, organised for management purposes.
5. Policy Objects: These are policies that can be applied to a system group or individual system to enforce specific configurations or security settings.
6. Policy Groups: These consist of multiple policies grouped together and associated with a device or system.
7. Command Object: This allows for the execution of individual commands on a system or system group for administrative purposes.

In summary, JumpCloud involves managing user and system objects, organising users and systems into groups, applying policies to enforce configurations, and executing commands as needed.

System administrators enroll devices in JumpCloud by installing the JumpCloud agent. This agent acts as an initialisation service, facilitating communication with JumpCloud’s servers. Once enrolled, administrators can manage devices using either the JumpCloud console or APIs, and JumpCloud’s cross-platform compatibility ensures it works seamlessly across different operating systems, including Windows, Mac, and Linux.

JumpCloud (JC) APIs consist of three distinct sets of APIs. When a threat actor possesses a JC API token, achieving persistence and enumeration becomes relatively straightforward due to the APIs’ accessibility over the public internet.

Directory Insights API

Directory Insights API allows you to query directory events at your organization. It provides event logs of activity within your directory and monitors user authentications to the console, SSO, RADIUS, and LDAP. Shine a light on your audit trails leading up to critical events. This is the backbone of our monitoring around JC. each operation done by an administrator or a user on JC generate specific event types, using which we can build our monitoring.Feeding the Jumpcloud directory insights event logs to SIEM systems is a must.

Note: Access to Directory insights is only available on selective plans.(here)We either can use directory insights API for monitoring JC events / use a third SIEM tools ( like Splunk) to ingest JC logs and build monitoring around it.

version 1: https://docs.jumpcloud.com/api/insights/directory/1.0/index.html

JumpCloud API

JumpCloud currently utilises two versions of APIs. Depending on the type of integration, it may be required to use both V1 and V2 APIs.

version 1 : JumpCloud API Docs

version 2: JumpCloud API Docs

To conclude, directory insight events can be used to build detection & monitoring around jumpcloud. JumpCloud API can be used to emulate threat actor actions.

Scenario:

let’s delve into the exciting aspect: a non-exhaustive list of JumpCloud (JC) events that can be triggered by a threat actor once they’ve infiltrated the compromised JC network. In this scenario, we’ll assume a threat actor has executed the following actions, and we’ll explore methods to detect these events if available. For clarity, we’ve simplified the scenario covering following steps:

1. Data Gathering and Enumeration: The threat actor begins by gathering all data and enumerating the existing JC environment.
2. Malicious Group Policy Creation: They proceed to create a malicious group policy within JC.
3. Attaching the Malicious Group Policy: The actor attaches this malicious group policy to system groups, such as ‘windows-group’ or ‘mac-group.’
4. Remote Command Execution: The threat actor executes remote commands on systems or system groups within JC.
5. System Data Erasure via MDM: Using JC’s Mobile Device Management (MDM) feature, they erase all system data across all systems.
6. Malicious Group Policy Deletion: Lastly, the actor deletes the malicious group policy and erases all previously created commands.

For each of these actions, we will identify the monitoring capabilities if available. Additionally, we will highlight key detection events corresponding to these actions.

Enumeration:

There are variety of ways that an attacker can do enumeration. The following list is non exhaustive and contains only a subset of critical/major calls that can be used by attackers.

1. Enumerate all the systems of the org : →

   1. curl -X GET https://console.jumpcloud.com/api/systems
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/1.0/index.html#operation/systems_list

2. Enumerate all the users of the org : →

   1. curl -X GET https://console.jumpcloud.com/api/systemusers
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/1.0/index.html#tag/Systemusers/operation/systemusers_list

3. Enumerate all the user groups of the org: →

   1. curl -X GET https://console.jumpcloud.com/api/v2/usergroups \
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json' \
        -H 'x-api-key: {API_KEY}'

4. Enumerate systems and system groups bound to each of the identified user with their privileges. →

   1. curl -X GET https://console.jumpcloud.com/api/v2/users/{UserID}/systems
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'
      

      curl -X GET https://console.jumpcloud.com/api/v2/users/{UserID}/systemgroups
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_userTraverseSystem https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_userTraverseSystemGroup

5. Enumerate policy groups bound to a system group : →

   1. curl -X GET https://console.jumpcloud.com/api/v2/systems/{System_ID}/policygroups
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_systemTraversePolicyGroup

6. Enumerate existing commands created by the sysadmins : →

   1. curl -X GET https://console.jumpcloud.com/api/commands/
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/1.0/index.html#tag/Commands/operation/commands_list

7. Enumerate existing command results which are still on the JC(very handy and many a times juicy sensitive info!)  : →

   1. curl -X GET https://console.jumpcloud.com/api/commandresults
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json'
        -H 'x-api-key: {API_KEY}'

      https://docs.jumpcloud.com/api/1.0/index.html#tag/Command-Results/operation/command_results_list

Unfortunately, JC directory insight events do not have any out of the box event captures for enumeration, this has to be built on need basis ingesting audit logs.

Creating a Malicious Policy on JC and Associating it with a System Group:

To create a policy or group policies and associate them with a system group, JumpCloud provides a set of APIs. JumpCloud offers a wide range of policy enforcement options, including the ability to control antivirus behavior, push custom registry keys to associated system groups, and disable security hardening policies already applied to a system group, among other capabilities.

For an attacker, this functionality can be particularly useful, as it creates an opportunity for persistence and complete control over the JumpCloud network.

1. Create a policy : →

   1. curl -X POST https://console.jumpcloud.com/api/v2/policies \
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json' \
        -H 'x-api-key: {API_KEY}' \
        -d '{
          {Policy_Parameters}
        }'

      https://docs.jumpcloud.com/api/2.0/index.html#tag/Policies/operation/policies_post

2. Associate Policy to System Group :→

   1. curl -X POST https://console.jumpcloud.com/api/v2/policies/{Policy_ID}/associations/ \
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json' \
        -H 'x-api-key: {API_KEY}' \
        -d '{
          "op": "add",
          "type": "system_group",
          "id": "{Group_ID}"
        }

      https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_policyAssociationsPost

      Once the association succeeds, policies associated with system groups are executed in real time.

How do we detect?

 We can monitor for the following directory insights events ingested to SIEM systems such as Splunk / custom monitoring via API’s. you can further refine monitoring rule in conjunction to base event.

"event_type": "policy_create"
"event_type": "policy_update"
"event_type": "policy_delete"
"event_type": "association_change"

Splunk Query : index=jc-directoryinsights sourcetype=jc:events event_type=policy_create OR event_type=policy_delete OR event_type=policy_update OR event_type=association_change 

Code Execution:

Attackers can achieve code execution on the systems/system groups using the following API.

curl -X POST https://console.jumpcloud.com/api/commands/ \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json'
  -H 'x-api-key: {API_KEY}'
  -d '{"name":"Test API Command", "command":"{AnyCommand}", "user":"{UserID}", "schedule":"", "timeout":"100"}

https://docs.jumpcloud.com/api/1.0/index.html#tag/Commands/operation/commands_post

Using the above API, an attacker can create a command and force it to immediately run on the user associated systems /user associated system group.

How do we detect?

 We can monitor for the following directory insights events ingested to SIEM systems such as Splunk / custom monitoring via API’s. you can further refine monitoring rule in conjunction to base event.

"event_type": "command_create"
Splunk Query: index=jc-directoryinsights sourcetype=jc:events event_type=command_create

Note: In case of JC breach, with the forensics provided(here), there was an immediate execution of a command which deployed and executed malicious ruby script. With the monitoring for such events, this action would have been flagged as anomaly on the customer’s network.

Using MDM feature of JC, Erase all the system data of all systems:

JumpCloud offers a range of remote Mobile Device Management (MDM) commands that empower administrators to remotely perform various operations on devices, from basic actions like restarts and shutdowns to more severe actions such as erasing all data on a system or locking users, all with a single API call. Unfortunately, threat actors can potentially abuse these commands to wreak havoc within the system.

We can achieve one of such sensitive events via the following API :

 curl -X POST https://console.jumpcloud.com/api/v2/applemdms/{apple_mdm_id}/devices/{device_id}/erase \
  -H 'accept: application/json' \
  -H 'content-type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -d '{}'

Erase an endpoint: https://docs.jumpcloud.com/api/2.0/#tag/Apple-MDM/operation/applemdms_devicesClearActivationLock

apple_mdm_id can be fetched by prior call to following end point : https://docs.jumpcloud.com/api/2.0/#tag/Apple-MDM/operation/applemdms_list

all enrolled MDM device_id’s can be fetched by prior call to following end point: https://docs.jumpcloud.com/api/2.0/#tag/Apple-MDM/operation/applemdms_list

How do we detect?

 We can monitor for the following directory insights events ingested to SIEM systems such as Splunk / custom monitoring via API’s. you can further refine monitoring rule in conjunction to base event. sample splunk query to monitor such dangerous remote calls,

"event_type": "mdm_command_result"
Splunk Query: index=jc-directoryinsights sourcetype=jc:events mdm_command_result mdm_device_id="*" "command.request_type"=EraseDevice

Delete the malicious group policy and erase all the command results:

Finally as a cleanup, an attacker may try to delete the JC commands run, deleting the created policy , removing the relevant associations.

This can be achieved by the following API:

Dis-associate associations:

curl -X POST https://console.jumpcloud.com/api/v2/policygroups/{GroupID}/associations \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}' \
  -d '{
    "op": "delete",
    "type": "system",
    "id": "{SystemID}"
  }'

https://docs.jumpcloud.com/api/2.0/index.html#tag/Graph/operation/graph_policyGroupAssociationsPost

Delete Policy:

curl -X DELETE https://console.jumpcloud.com/api/v2/policies/{id}\
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}'

https://docs.jumpcloud.com/api/2.0/index.html#tag/Policies/operation/policies_delete

Delete Command:

curl -X DELETE https://console.jumpcloud.com/api/commands/{CommandID} \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: {API_KEY}'

https://docs.jumpcloud.com/api/1.0/index.html#tag/Commands/operation/commands_delete

How do we detect?

 We can monitor for the following directory insights events ingested to SIEM systems such as Splunk / custom monitoring via API’s. you can further refine monitoring rule in conjunction to base event. sample splunk query to monitor such dangerous remote calls,

"event_type": "command_delete"
"event_type": "policy_delete"
"event_type": "commandresult_delete"
Splunk Query: index=jc-directoryinsights sourcetype=jc:events event_type=command_delete OR event_type=policy_delete OR event_type=commandresult_delete

Detection in the above-mentioned scenario represents just a subset of the monitoring capabilities that can be developed using JumpCloud events. JumpCloud provides a diverse range of event types, enabling us to expand our monitoring scope and identify potentially malicious behaviour by threat actors within our network before they can disrupt our systems.

Few of the other interesting scenarios that can be looked at and needs active monitoring,

1. Granting global sudo access while creating a JC user.
2. Adding local users via JC group policies.
3. Many admin/privileged events in a short span of time. ( ex: 100’s of deletion of command results in short span of time.)
4. Locking out existing JC user.
5. Disabling MFA on an existing JC user.
6. Reviving suspended/inactive JC users.
7. Modifying existing organisation settings. (disable MFA etc )

Comprehensive event types and their exhaustive list can be found in the JumpCloud documentation, which serves as resource for building effective and vigilant monitoring. You can access this information here: Link to JumpCloud Documentation.

The post Jumpcloud and Security : tidbit for Attack and Detect appeared first on .