What Can be Learned from the JumpCloud Security Incident
In an ideal world, security incidents result in minimal damage, and we can learn from them to improve our future defenses. Fortunately, such appears to be the case with JumpCloud. According to JumpCloud’s blog post, its recent security incident impacted fewer than 5 JumpCloud customers and fewer than 10 devices. Moreover, working together with their incident response (IR) partner Crowdstrike (also a Salt Security partner), JumpCloud has mitigated the attack vector used by the threat actor.
Given that over 200,000 organizations use the IT management service platform, the potential outcome could have been much worse, had the attack been broader. Hundreds of thousands of companies rely on JumpCloud’s APIs to manage their key critical infrastructure and business-driving services. Any abuse of a JumpCloud API also holds the potential to affect their own security.
While invalidating API keys, as done by JumpCloud, disrupts all of the systems relying on those APIs, the alternative is far worse. A customer admin API key held by adversaries could enable them to compromise the administration and configuration of key directory and identity services for an organization. They could wreak havoc on important security services such as single sign-on (SSO), MFA, password management, device management, and more.
Defend yourself from API attacks by leveraging this security framework
Download NowHow did the incident occur?
New details released from JumpCloud and other cybersecurity companies found that a sub-group of nation-state threat actor Lazarus was most likely behind the attack. The incident started with a successful spear-phishing campaign by the threat actor, which netted them access to JumpCloud’s internal infrastructure.
With that access, the threat actor targeted and impacted a small set of JumpCloud customers. Although the names of the specific customers attacked have not been released, it is known that Lazarus has a history of targeting crypto or finance-related entities to help fund nation-state initiatives. It is possible the campaign against JumpCloud might have been part of a multi-wave campaign, using JumpCloud as an intermediary to lower the defenses of the adversary’s ultimate targets, who are JumpCloud clients.
Because JumpStart did not initially know the extent of the attack, it reset all of its customer admin API keys out of an abundance of caution to prevent further and more widespread impact.
The JumpCloud incident highlights the fact that APIs have become a ripe attack surface for cybercriminals. Bad actors are targeting APIs for any number of abuses – from data exfiltration to disruption of business services and/or digital supply changes to account and infrastructure takeover. While it is unclear what the threat actor’s intent was once they infiltrated and targeted certain customers on the JumpCloud infrastructure, the attack campaign sequence is similar to other API attack campaigns that have hit organizations recently. In those campaigns, the threat actor conducted a targeted social engineering attack, such as spear-phishing, with the goal of gaining internal system access and harvesting privileged API keys from the environment. Once an admin or privileged API key is obtained, the threat actor has the authority to exercise all available functions available to that API and could wreak havoc.
Here at Salt we recently published a whitepaper which maps this type of coordinate attack campaign to the MITRE ATT&CK Framework. The paper outlines the tactics used by an adversary during a stolen credentials based API attack.
What steps should organizations take to protect themselves?
The JumpCloud incident highlights the fact that organizations must be aware of risks in regards to their cloud service providers. They should ask their providers for an option to lock down API access to their account from a limited whitelist of locations. By locking down API access, organizations can minimize the risk of an adversary causing harm should an attacker access a privileged API key.
The JumpCloud breach also reinforces the importance of anomaly detection in runtime as part of a comprehensive API strategy. Organizations must have the ability to see their APIs in runtime to discover and monitor all of production APIs. Only runtime visibility helps you understand normal versus out-of-the-ordinary API behaviors to spot potential threats such as an API being abused with stolen credentials. With hundreds of thousands of API calls being made, identifying anomalies over time demands artificial intelligence (AI) and machine learning (ML). Only AI- and ML-driven solutions can easily baseline typical behaviors across millions of APIs to uncover even the most subtle anomalies.
If you’d like to learn how the Salt Security API Protection Platform can help you quickly identify potential API threats and vulnerabilities, please reach out to us to set up a call or schedule a demo. Salt will also be at Black Hat USA August 9-10. If you’re at the show, we’d love to set up a live meeting.
