Top 10 Non-Human Identity Risks to Recognize and Mitigate

As the number of non-human identities, such as service accounts, devices and API keys, grows faster than human ones (1:10 according to Microsoft research), organizations face a big challenge in keeping them secure.

The diverse range of non-human credentials, from certificates and keys to secrets and tokens, coupled with the complexities of hybrid and multi-cloud environments, makes centralized visibility and control extremely difficult.

With disparate tools for different non-human identity types and a lack of consistent best practices, risks like unrotated keys, lack of lifecycle management, undetected misconfigurations, and failure to promptly remediate vulnerabilities can leave critical assets and data exposed to compromise.

In this blog post, we highlight the 10 most critical non-human identity risks and attack vectors to be aware of and address.

Incomplete Offboarding of Non-Human Identities

Incomplete offboarding happens when a company deactivates a former employee's regular account but fails to reassign ownership of or deactivate non-human identities that employee created or managed, such as service accounts and API keys. These additional identities remain active and create risk unless managed properly.

Examples:

• Still-active orphaned service accounts created by former employees that are no longer monitored.
• Unused API keys that remain enabled without regular usage or review.
• Stale automation scripts that continue to run without any oversight or ownership.

Prevention:

• Assign an owner for each NHI who will be responsible for managing its lifecycle.
• When employees leave, review each NHI they “owned” and either reassign ownership or delete accordingly
• Conduct periodic audits to find additional orphaned NHIs not discovered during the off-boarding process
• Use tools to automatically detect and disable unused NHIs

Attack Scenarios

• An employee leaves the company, and while their email and personal accounts are deactivated, several service accounts they created remain active. An attacker discovers these orphaned accounts and uses them to access sensitive company data.
• A developer departs, but their API keys remain active and unmonitored. An attacker finds and uses these keys to exploit the company's API, accessing customer information without authorization.

Insecure Credential Storage 

NHI credentials are often scattered across various locations, some of which may be inherently insecure. These increase the risk of an attacker gaining access to the NHI’s credentials and compromising it.

Examples:

• AWS service account access key stored on multiple employee endpoints
• Production SSH key stored in password manager and shared with entire organization
• API tokens hard-coded in internal code repositories
• Service-specific secrets stored in AWS Secrets Manager accessible to wide group of users

Prevention:

• Limit access to sensitive SSH keys to essential personnel only
• Utilize team management and vault separation in the organizational password manager to prevent overly shared secrets
• Prevent secrets from being hard-coded in code by using secret-finding tools as part of the development workflow
• Restrict access to secrets in Secret Managers according to roles and specific workloads each team is responsible for

Attack Scenarios

• Through phishing campaign, developer’s endpoint is compromised, which leads to API tokens stored in internal code repositories stored locally that are then used to access 3rd party database services and exfiltrate data
• Attacker compromising private email account of employee accesses password manager “Emergency Kit”, gains direct access to vaults, steals production SSH key and logs on to publicly accessible production machines
• Former employee’s personal device compromised by commodity malware, leading to service account AWS access keys which were stored locally on their device being stolen

Unrotated Credentials

Unrotated credentials are a big security risk because very-long-lasting static credentials are statistically exposed to compromise for a longer period of time and in a constantly increasing number of locations in which they are stored throughout the lifetime of the NHI. Regularly rotating credentials reduce this growing risk by periodically “resetting” the surface of possible compromise.

Examples:

• Static API Keys: API keys that are rarely or never rotated, making them susceptible to unauthorized use if exposed.
• Service Account Keys: Service account credentials that remain unchanged for extended periods, increasing the risk of misuse.
• Hardcoded Credentials: Credentials embedded in code or configuration files that are not routinely updated.

Prevention:

• Establish and enforce regular rotation policies for all NHI credentials.
• Utilize automation tools to rotate API keys, service account keys, and other credentials.
• ֿSet up monitoring systems to detect and alert on old or compromised credentials.
• Use short-lived credentials whenever possible to minimize the impact of leaks.

Attack Scenarios:

• An API key for a critical service account is hardcoded into a script and not rotated for over a year. The key is inadvertently exposed through a public repository. Attackers discover and use the key to gain unauthorized access to sensitive data.
• A service account key is used to access a cloud environment and is not rotated regularly. An attacker gains access to the key and uses it for weeks to siphon data and resources without detection.

Weak Authentication

Usage of weak authentication methods increases the risk of successful brute-force attempts, credential stuffing and MitM attacks compromising NHI identities.

Examples:

• Weak password policy allowing brute-forceable service account passwords
• Snowflake service account using password instead of RSA key-pair authentication
• Jenkins using user+password instead of SSH key for accessing Git repositories

Prevention:

• Implement strong password policies that enforce complexity and regular updates
• Use SSH keys / OAuth tokens instead of regular passwords whenever possible
• Always change default passwords on initialization of new systems
• Implement brute-force prevention mechanisms

Attack Scenarios

• Weak Postgres database admin password brute-forced leading to data exfiltration
• Malicious actors gain access to GitHub repositories via credential stuffing using credentials stolen from vulnerable internet-facing server
• AWS Storage Gateway compromised via unchanged default password leading to sensitive data leakage

Insecure Account Sharing

Shared non-human identities, such as API keys and service accounts, are credentials used by multiple systems or applications to perform automated tasks. This practice is insecure because it complicates the enforcement of consistent security policies and makes lifecycle management difficult, leading to potential misuse or orphaned accounts. These identities are often over-privileged and widely distributed, increasing the risk of unauthorized access. Furthermore, detecting anomalous activities becomes challenging since these identities are used by various sources, masking malicious behavior within legitimate operations.

Examples:

• DevOps team shares a single SSH key for accessing production servers. If the key isn't rotated and an engineer leaves without proper offboarding, unauthorized access can persist indefinitely. 
• When a single API key is used across multiple applications or teams, it creates a single point of failure. If one application is compromised, the attacker can use the key to access other services. Also the identity is usually over-privileged since many applications are using the same key for different actions.
• Different EC2 instance groups with separate instance profiles that are all associated with a single role, effectively leads to the role being shared among many instances, and often such roles accumulate a large number of different IAM policies that end up with the role being over-privileged for most of the instances using them.

Prevention:

• Assign unique, least-privileged credentials to each non-human entity to limit potential damage from compromises.
• Automated processes for the regular rotation and expiration of keys and certificates.  
• Continuously monitor and log access to critical services, triggering alerts for any anomalies or unauthorized attempts for immediate action.

Attack Scenarios

• Attackers infiltrated the build environment by compromising shared credentials, and injecting malicious code into the software updates platform – such as occurred in the SolarWinds breach. 
• Attackers obtain SSH keys that are shared among multiple administrators or services. This allows them to access critical servers and potentially escalate privileges across the network. 

Third Party Compromise

Third-party services and applications that integrate into the organization’s environment introduce a different type of risk - they usually require high-privileged access to the environment, and access it via dedicated NHIs, often using long-term credentials and tokens. If a third-party provider is compromised, attackers can use their access to the organization to exfiltrate data and move laterally within the environment. By using the dedicated NHIs created for the third-party providers, attackers can more easily blend in their regular activity and delay detection.

Examples:

• Third-party services that require use of non-expiring keys, heightening risk if compromised.
• Insufficient monitoring of third-party access can delay the detection of malicious behavior through it.
• Third-party credentials that are not rotated periodically increase the statistical risk of exposure and exploitation if leaked by a 3rd party vendor being compromised.

Prevention:

• Whenever possible, when setting up integrations with 3rd party providers, opt to use authentication that utilizes short-term credentials instead of long-term credentials
• Implement policies to regularly rotate third-party credentials to minimize risk.
• Monitor third-party activities, set alerts for anomalies and verify any suspicious behavior with the provider.
• Perform thorough security assessments of third-party providers before integration.
• Limit third-party access privileges to the minimum required and segment their access to reduce breach impact.

Attack Scenarios

• A business intelligence platform like Sisense gets compromised. Attackers obtain long-lasting AWS access keys and use them to access sensitive data stored in the customer's AWS environment. The attackers can further exfiltrate data from other integrated services like Salesforce and Amazon RDS.
• A third-party service with SSH access to on-premises servers is compromised. Attackers use the stolen SSH keys to access the organization's internal systems, leading to data exfiltration and potential deployment of ransomware.

Stale Identities

Stale identities with active credentials pose unnecessary risk to the organization, as just like other credentials they may be accidentally leaked or exposed in various ways, or stored insecurely, while they could have been been disabled or deleted altogether instead. Additionally, as inactive credentials are usually non-managed, they tend to have additional compounded risks such as weak authentication or being over-privileged, which makes them more risky than other NHIs.

Examples:

• Leftover service accounts, typically provisioned by previously offboarded employees, but that are no longer required.
• NHIs used in old automation scripts that are no longer being run.
• Dedicated NHIs once used for third party integrations which are no longer being used.

Prevention:

• Periodically review identities not used over a certain threshold of time (e.g. 6 / 12 months), and disable accordingly.
• Implement automated processes for disabling non-human identities based on usage.

Attack Scenarios

• A third-party vendor which used a non-human identity to integrate with an organization’s system was later compromised. Even though the integration is no longer in use, the credentials are still active and used by the attacker.
• An organization has an old service account with elevated privileges that was used for a project that ended a year ago. This service account has not been disabled or removed. A malicious actor discovers the credentials for this stale account through a data breach or internal leak, and uses them to access data and systems.

Overprivileged Identities

Over-privileged identities in organizations have excessive access rights, posing additional security risks. Attackers gaining access to over-privileged NHIs may more easily and rapidly operate within the environment, laterally move and exfiltrate data, in a way that can dramatically impact the outcome of a breach event until the attack is detected and stopped.

Examples:

• EC2 workloads with overly permissive access of read and write permissions to sensitive data in S3 buckets, that is not necessary for the applications running on these workloads. 
• A CircleCI test job with hard-coded access keys enabling permissive access to Azure resources, poses a risk in case that access keys will be exploited by malicious actors
• Using one role for multiple apps on a GKE cluster can be risky. It's better to give each app its own permissions. If the role gets leaked, it's a big threat to data and systems.
• A GKE cluster with multiple applications using the same role, accumulating the different permissions required by all applications.

Prevention:

• Implement the principle of least privilege by restricting access permissions to only what is essential for the application's functionality.
• Conduct periodic audits to observe the usage of permissions granted to service accounts and other NHIs. Use logs and third party tools to monitor usage over time, and remove permissions that are unused for a long period of time.

Attack Scenarios‍

• A customer-facing vulnerable web application such as occurred in CapitalOne which held permissive access to an S3 bucket, allowing the attacker to exploit the permissive access to S3, which led to a data leakage.
• A third-party platform like GitHub gets compromised. Attackers obtain access to long-lasting access keys left mistakenly in code, which enable excessive permissions to an RDS database.

Shadow Identities

Fragmented IAM environments often result in unfederated local identities, leading to "shadow identities" - unmanaged non-human identities not part of the desired lifecycle management process. These shadow identities pose significant security risks and require a holistic approach to identity governance. 

Examples:

• Local database users, created by developers, which are not managed as part of the main identity lifecycle management process.
• Service accounts created for specific applications that are not de-provisioned after use.
• API keys distributed across multiple development teams without centralized oversight.

Prevention:

• Periodically mapping and attributing all local identities across the different identity stores in the various technologies used across the organization.
• Whenever possible, utilize federated authentication to prevent creation of local identities that rely on static credentials

Attack Scenarios‍

• Attackers find and exploit active but unused local database accounts that were not de-provisioned, gaining undetected access to sensitive data.
• An old, unmonitored API key is discovered and used by attackers to access multiple systems, allowing them to move laterally and escalate privileges.

Long-Term Credentials

NHIs using static credentials that never expire are at higher risk of compromise. Such credentials spread within the organization over time, are often insecurely stored, are hard to rotate and mostly lack network restrictions or extra security layers.

Examples:

• EC2 workloads using long-term AWS access keys instead of instance profiles
• Azure Functions using service principal credentials instead of managed identities
• K8s service accounts using static tokens instead of projected tokens

Prevention:

• Use temporary credentials for NHI authentication instead of long-term credentials whenever possible
• Rotate static credentials regularly
• For all NHIs which nonetheless require long-term credentials for authentication, add additional layers of security to the authentication or authorization such as IP-based network restrictions or other supported trust boundaries

Attack Scenarios

• Attackers find production workload credentials on employee endpoints
• Snowflake service account passwords found in Slack messages and exploited
• Unauthorized access via leaked Lambda configuration secrets

Token Security's Non-Human Identity Security Solution Management is now available to address these risks and help you start your non-human identity security program. Contact us for a free assessment of your environment.