Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand Improper Offboarding to cover Stale scenarios #23

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 15 additions & 8 deletions 2025/docs/1-improper-offboarding.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,23 +3,30 @@
| Threat Agents & Attack Vectors | Security Weakness | Impact |
|---------------------------------------------------|-------------------------------------------------------------------------------------------------------------|------------------------------------------------|
| Exploitability: **Easy** | Prevalence: **Widespread**<br>Detectability: **Hard** | Technical: **Severe**<br>Business: **Specific** |
| Exploiting an improperly offboarded NHI greatly depends on context. Considering the case of an inside threat, it’s quite simple to identify what necessary credentials are needed to exploit the improperly offboarded identity. | The current capabilities of offboarding NHIs, such as service accounts, are lackluster, and organizations rarely use existing possibilities. Thus, many NHIs are not properly offboarded after they are no longer needed or once the original owner has left.<br>Security teams are lacking tools to detect old NHIs that were not properly offboarded. Existing techniques of detecting such NHIs rely on incomplete information that takes a long time to compile. | Due to the deep insight a potential inside threat has of the organization, exploiting improperly offboarded NHIs could lead to compromise of critical systems, exfiltration of sensitive data and usage of advanced persistence methods. |
| Exploiting an improperly offboarded NHI greatly depends on context. Considering the case of an inside threat or lateral movement, it’s quite simple to identify what necessary credentials are needed to exploit the improperly offboarded identity. | The current offboarding capabilities for NHIs (such as service accounts) are inadequate, and organizations seldom utilize available options. As a result, many NHIs remain active long after they are no longer needed or after the original owner departs.<br>Security teams lack effective tools to identify NHIs that are no longer used and were not properly offboarded. Current detection methods rely on incomplete information that takes a long time to compile and analyze. | Because insiders often have deep knowledge of an organization, exploiting improperly offboarded NHIs could lead to compromise of critical systems, exfiltration of sensitive data and usage of advanced persistence methods. |

## Description
Improper offboarding refers to the inadequate deactivation or removal of non-human identities (NHIs) such as service accounts and access keys when they are no longer needed. This situation often arises when applications are deprecated, services are taken offline, or when the original owners or administrators of these NHIs leave the organization. Failure to properly offboard NHIs poses significant security risks. Unmonitored and deprecated services may remain vulnerable, and their associated NHIs can be exploited by attackers to gain unauthorized access to sensitive systems and data. Additionally, orphaned NHIs may retain elevated permissions, amplifying the potential damage from any security breach.
Improper offboarding refers to the inadequate deactivation or removal of non-human identities (NHIs) such as service accounts and access keys when they are no longer needed. This situation typically arises due to one of the following scenarios:
1. When applications are deprecated or services are taken offline, rendering the NHIs they depended on unneeded and unused (commonly referred to as "stale" or "dormant").
2. When the original owner departs, but the associated NHIs remain active without a new designated owner (commonly referred to as "orphaned").
3. When an administrator or developer, who is often _not_ the actual owner of the NHIs, is exposed to their credentials and then leaves the organization without revoking them (commonly referred to as "partially offboarded employee").

The failure to properly offboard NHIs poses significant security risks. Unmonitored and deprecated services may remain vulnerable, and their associated NHIs can be exploited by attackers to gain unauthorized access to sensitive systems and data. Additionally, such NHIs may retain elevated permissions, amplifying the potential damage from any security breach.

## Example Attack Scenarios
- **Orphaned Kubernetes Service Accounts:** A Kubernetes cluster belonging to a decommissioned service retains active service accounts. If an attacker gains access to this unmonitored cluster, they could exploit these service accounts to interact with other resources within the organization's infrastructure, potentially leading to data exfiltration or further compromise.
- **Ex-Employee Exploiting Unrevoked Credentials:** An employee who managed automated services leaves the organization, but the NHIs associated with those services are not disabled or transferred. The ex-employee could misuse still-valid credentials to access the organization's systems remotely, leading to unauthorized data access, service disruptions, or even sabotage.
- **Leftover Apps Used for Privilege Escalation & Lateral Movement:** An application created in a test environment, designated to test a workload, is later connected to a sensitive production environment to complete the testing suite, and is not decommissioned once the workload is transferred to run in a production server. Then, an attack reaching the less secure test environment can use this application to move laterally within the organization.
- **Dormant Kubernetes Service Accounts:** A Kubernetes cluster belonging to a decommissioned service retains active service accounts. If an attacker gains access to this unmonitored cluster, they could exploit these service accounts to interact with other resources within the organization's infrastructure, potentially leading to data exfiltration or further compromise.
- **Ex-Employee Exploiting Unrevoked Credentials:** An employee managing automated services, with access to certain credentials, leaves the organization. The associated NHIs remain active and the credentials are not revoked or rotated, allowing the ex-employee to misuse still-valid credentials and remotely access organizational systems. This can be done even if the employee's personal account was revoked, resulting in unauthorized data access, service disruptions, or sabotage.
- **Leftover Apps Used for Privilege Escalation & Lateral Movement:** An application created in a non-production environment for workload testing is connected to a sensitive environment as part of a testing suite. Even after the workload is moved to production, the application is not decommissioned. Consequently, an attacker compromising the less secure non-production environment could use this application to move laterally within the organization.
- **Employee leaves, but the account remains:** A skilled application developer who built a business-critical application departs from the organization. Although ownership is transferred to a new team, no one fully understands the application’s operations, especially that it relies on an access key. Over time, this key remains active and unnoticed, creating a security vulnerability and a prime target for stealthy lateral movement.

## How to Prevent
- Implement an offboarding process that reviews all NHIs associated with the departing employee. For each NHI, determine if it is still required. If not, decommission it; otherwise, transfer ownership to another employee and rotate any credentials the departing employee may have had access to during its creation.
- Implement an offboarding process that reviews all NHIs associated with departing employees. Determine if the associated NHIs are still required - if not, decommission them; otherwise, transfer ownership to another employee and rotate any credentials that the departing employee had access to.
- Automate offboarding steps wherever possible by integrating HR systems with identity and access management (IAM) tools.
- Regularly audit active NHIs to identify ongoing human usage and block potential misuse.
- Periodically recertify NHIs to confirm they are still in use, actively needed, and have valid owners. Decommission any identities found to no longer be needed, and ensure all NHIs have assigned owners.
- Regularly audit active NHIs to monitor ongoing usage and block potential misuse.

## References
- [Cloud Security Alliance: Decommissioning Orphaned and Stale Non-Human Identities](https://cloudsecurityalliance.org/blog/2024/06/03/decommissioning-orphaned-and-stale-non-human-identities)
- [Oasis Security: Decommissioning Orphaned and Stale Non-Human Identities](https://www.oasis.security/resources/blog/decommissioning-orphaned-and-stale-non-human-identities)
- [Ex-Employee Accessed Former Company's System and Deleted Resources](https://www.channelnewsasia.com/singapore/former-employee-hack-ncs-delete-virtual-servers-quality-testing-4402141)
- [Microsoft Breach by Midnight Blizzard Threat Actor](https://msrc.microsoft.com/blog/2024/01/microsoft-actions-following-attack-by-nation-state-actor-midnight-blizzard/)

Expand Down