We’ve expanded to support VM-based workloads. Read about it!


Real-Life Examples of Workload Identity Breaches and Leaked Secrets – and What to Do About Them (Updated Regularly)

Identity-related breaches involve workloads more than ever, and that trend should continue. Here is a catalog of those incidents, with advice for mitigating the risk.
Real-Life Examples of Workload Identity Breaches and Leaked Secrets – and What to Do About Them (Updated Regularly) header image

For the vast majority of IT history, identity has been thought of in the context of humans. Usernames, passwords and other authentication mechanisms dominate our daily lives on the web. However, as technology continues to advance, the concept of identity and access management (IAM) is expanding beyond the human realm to include workloads.

In the age of digital transformation, artificial intelligence and the internet of things, all of which has been propelled forward by the rise of remote work and its heavy reliance on cloud-based resources, workload – aka machine-to-machine – identities have surged alongside. According to Microsoft’s 2023 State of Cloud Permissions Risk report, workload identities are outnumbering human identities 10 to one, and just 1% of permissions are actively used.

workload is any program or application that utilizes computing, data, networking, and storage to perform one or more tasks. Some examples of workloads include:

  • Custom applications you run in the cloud or on-premises environment (including in Kubernetes).
  • HTTP-based APIs from third-party SaaS providers or API gateways.
  • Databases 
  • Application services provided by hyper-scale cloud vendors.

Identity-based attacks thus go beyond the familiar threat vectors that have dominated headlines and lined the pockets of your foes, such as credential stuffing and phishing. While human credentials will remain firmly in the cross-hairs of malicious hackers and at the epicenter of accidental data leakage incidents, the tide is changing. 

Today’s applications are composed of services across multiple clouds, with APIs connecting to third-parties and sensitive databases that require different levels of access. In addition to being distributed, modern apps act autonomously, meaning if in the past they acted on behalf of the user using their credentials, nowadays they operate with their own identity. This dynamic has created a broader attack surface – because in order to achieve their mission of interconnectedness, scalability and user-friendliness, they need to interact and exchange data. 

Adversaries have caught on. They are quickly realizing that the pickings are far greater on the proverbial back-end, yet many organizations are still in the early stages of securing these permissions and getting a true handle on workload identity and access management. Most businesses lack adequate best practices in this area—and often the job of managing workload identities falls to DevOps engineers who view the practice as cumbersome and inconvenient.

All this introduces greater risk for organizations, and we are starting to see it manifest with real-world instances of identity-based workload credential loss incidents affecting organizations, including high-profile brands. We’ll continue to update the below list as more cases emerge.

1) Hardcoded Credentials: GitHub

When: Multiple incidents

GitHub effectively serves as ground zero for workload identity-based attacks. The enormously popular online software development platform allows users to create public repositories where they can store and share their code openly. While this encourages collaboration and knowledge sharing, it also means that sensitive information, such as access keys, passwords, and API tokens, can accidentally be included in the codebase, which is contributing to hardcoded secrets sprawl. If developers and DevOps teams are not diligent, these secrets can be exposed to the public, leading to unauthorized access and breaches. In fact, attackers are already pouncing on the opportunity with several groups emerging who specialize in writing code to scan public-facing applications for things that look like keys. GitHub, for its part, publicly acknowledged in April 2022 at least one breach. It has responded by offering dev teams free secrets scanning.

2) Access Key Exposure: Toyota

When: October 2022

Toyota discovered recently that some of its T-Connect app connectivity source code was left exposed for roughly five years on GitHub and contained an access key to the data server that stored customer email addresses and management numbers. Roughly 300,000 customer records were exposed, according to a notice from Toyota (translated from Japanese).

3) Stolen Application Keys: CircleCI

When: December 2022

In December 2022, attackers gained access to CircleCI’s GitHub and Bitbucket application keys, which are used to interact with customer repositories, as well as certain customer environment variables and API tokens. According to the company: “An unauthorized third party leveraged malware deployed to a CircleCI engineer’s laptop in order to steal a valid, 2FA-backed SSO session. This machine was compromised on Dec. 16, 2022. The malware was not detected by our antivirus software. Our investigation indicates that the malware was able to execute session cookie theft, enabling them to impersonate the targeted employee in a remote location and then escalate access to a subset of our production systems.” `As a result of the attack, intruders potentially had access to customers’ source code, environment variables, and other sensitive information contained within their CircleCI workflows. CircleCI took immediate action to address the incident, including revoking the compromised credentials, conducting a thorough investigation, and implementing additional security measures.

4) API Vulnerability: T-Mobile

When: January 2023

The mobile giant announced in a regulatory filing that 37 million current and former customers were impacted by a breach in which attackers accessed sensitive personal information through one of its API interfaces. The company didn’t share how the malicious actors were able to compromise the API, which are able to access data by interfacing with databases via permissions, but said the attack had been going on for roughly two months before it was identified and halted.

5) SMS-Based Phishing Attack: Retool

When: August 2023

Retool, a software development company, disclosed that a sophisticated SMS phishing attack compromised 27 of its cloud customers, all in the cryptocurrency sector. The breach started when an employee received an SMS, allegedly from Retool’s IT team, tricking them into logging into a fraudulent site and sharing multi-factor authentication (MFA) codes from Google Authenticator. A subsequent voice call, seemingly from an IT member who used detailed knowledge of Retool’s internal operations, secured an additional MFA code. This allowed attackers to sync their device with the employee’s Google and Okta accounts, gaining access to internal systems and customer accounts. Retool blames the severity of the breach on Google Authenticator’s new cloud sync feature, which they claim converted their MFA into less secure single-factor authentication. The breach led to almost $15 million in cryptocurrency losses for one customer, Fortress Trust. 

6) Compromised AWS Credentials: Sumo Logic

When: November 2023

Sumo Logic, a prominent data analytics firm, experienced a security breach when an attacker infiltrated its AWS account using stolen credentials. Although the exact method of how these credentials were obtained by the attacker has not been disclosed, it typically involves tactics like phishing, exploitation of weak or reused passwords, or perhaps previous data leaks. Despite the breach, the company asserts that its systems and customer data, which remains encrypted, were not affected. As a precaution, Sumo Logic promptly secured the compromised infrastructure, rotated potentially exposed credentials, and advised customers to reset their API keys, collector credentials, and any other shared credentials. The company is conducting a thorough investigation to determine the breach’s origin and extent and has enhanced its monitoring systems and security measures. 

Best practices for managing access between workloads

So what options exist for organizations wanting to mitigate the risk of workload-based credential loss? Here are some recommendations:

Regularly rotate secrets 

As you likely already have in place for user credentials, the practice of frequently changing workload credentials makes life more difficult for attackers–and helps limit the likelihood that the credentials will be usable if they are accidentally exposed to the public. Regular rotation also enhances security by increasing the likelihood of discovering unnoticed compromises and extending your organization’s adherence to the principle of least privilege.

Monitor and analyze workload activity

Keep a watchful eye on your workload identities by implementing robust monitoring and logging to track and analyze activity. This includes monitoring for suspicious or anomalous behavior, analyzing access logs, and setting up alerts for potential security incidents. Regularly reviewing your these logs will also help you uncover over-privileged or inactive identities contributing to credential sprawl.

Treat DevOps and security as a shared responsibility

Security education isn’t just an end-user priority. Security must be ingrained into the culture of everything an organization does, and that includes the relationship between developer, DevOps and security teams. By emphasizing the importance of security at every stage of the development lifecycle, organizations can create a collaborative environment that prioritizes secure coding practices, threat modeling, secure configurations, and vulnerability management. This vision is being realized with the DevSecOps movement.

Throttle down your need to manage secrets

Consider deploying a solution like Aembit, which lends visibility and centralization by acting as the control plane for workload IAM. When a workload wants to access a service, the workload reaches out to Aembit, which authenticates the workload, then checks the access policy and issues a short-lived credential instead of a long-lived secret. Your application traffic doesn’t travel over Aembit’s network. Aembit also logs all access and access attempts as events for analytics, audit, and alerting. It’s a closed-loop system that takes care of acquiring and provisioning credentials, when and where they are needed. 

Want to improve how your workloads securely access the services they depend on? For more information or to try Aembit for free forever, visit aembit.io.

You might also like

In the span of a few weeks, three leading tech authorities published findings on non-human identity security challenges. What does...
Our latest update enables secure, seamless connectivity for workloads across cloud and Kubernetes, without trust domain restrictions....
OAuth 2.0 has emerged as a de facto standard for secure authentication. Here is a step-by-step tutorial for configuring it...