Hero Card: Zombies

One-Click Least Privilege. Zero Disruption.

© 2026 Sonrai Security. All rights reserved.

Overview

A Zombie, in the context of the Cloud Permissions Firewall, is considered to be any identity (user, role, etc.) that has been unused for at least 90 days.

Inactive but enabled Zombie identities provide the capability for threat actors to escalate privileges, move laterally, gain access to sensitive data, and more.

Rather than deleting Zombie identities entirely, we opt to help you quarantine them so they remain present within your cloud but can no longer be used. Quarantining consists of denying use to all permissions for which the identity has been assigned.

Zombies may reanimate after some time (think quarterly reporting scripts, staff returning from paternity leave, etc.), but these identities are subject to requesting privileged service access through Permissions on Demand (PoD).

Why Do Zombies Matter?

Example 1: When Outsiders Become Insiders

Example 1: When Outsiders Become Insiders

An attacker discovered an unused but enabled IAM identity that belonged to a former employee who had left the company months earlier. Due to poor offboarding practices within the organization, this identity was still active and had been granted elevated privileges during the employee's time at the company. The attacker brute-forced the credentials for the identity, trying common passwords and variants until the role was successfully accessed.

The identity had access to various critical systems, including databases containing sensitive financial data and other customer information. The attacker began exfiltrating this data and attempted to disrupt the company's services by altering configurations and deploying malicious scripts.

Example 2: When Insiders Cause Problems

Example 2: When Insiders Cause Problems

One day, the development team encountered a puzzling issue: performance problems and unexplained service outages affecting several of the company's key applications. Initially, the team suspected a bug in the recent code deployment and began investigating potential causes.

After digging deeper, they discovered unexpected changes to configurations and security settings in the AWS environment. These changes seemed to originate from an inactive IAM identity belonging to a former third-party contractor who had left the company several months earlier. The identity had been granted elevated privileges during the contractor's time but had remained enabled long after their departure.

After extensive investigation, an insider threat was determined to be at fault for the disruption, trying to create ways into the organization for employees of a competitor!

---

Quarantine Your Zombies

Easily and efficiently manage your unused identities at any level!

Select the scope at which you want to take action and click the button to see the changes you are about to make. When ready, click the button to immediately apply quarantine to those identities in your cloud.

Scope Level	AWS	GCP	Action
Enterprise	Organization	Organization	Complete a clean sweep of zombies across your entire cloud Organization
Grouping Layer	Organizational Unit (OU)	Folder	Use the scope dropdown to select an OU (AWS) or Folder (GCP) and quarantine all zombies within
Resource Layer	Account	Project	Use the scope dropdown to select an AWS Account or GCP Project and quarantine all zombies within
Identity	Individual Identity	Individual Identity	At any selected scope, preview a list of available zombies and quarantine any individual identity!

Example: Quarantining Zombies in AWS

This view is scoped to an AWS Account (Sandbox) nested within multiple OUs. In this context, the types of quarantine available are:

a) OU-based (nested) - Quarantine all identities within the Dev Sandbox Account

b) Individual identities - Quarantine the unused DevRole, or the AdminRole last used 30 days ago, etc.

c) OU-based (parent) - Quarantine all the OUs & nested AWS Accounts under the Dev OU

info

In AWS, Zombie identities can be reanimated, gaining privileged service access through a Permissions on Demand (PoD) request.

However, not all actions are audited. If a zombie attempts to take an unaudited action, it will be denied access but no PoD request will be generated.

In GCP, Zombie identities can only be reanimated by manually removing them from the quarantine list.

A quarantined GCP identity cannot take actions that trigger PoD requests.

To view the list of quarantined zombies at this scope, open the menu on the Services page:

tip

Our API documentation includes sample GraphQL queries showing how to look for zombie identities in an account.

Remove Zombies from Quarantine

If you would like to remove a zombie from quarantine, enabling it to reanimate and use non-privileged permissions for a service, you can leverage the Quarantine List.

Expand the rows using the caret on the lefthand side to view the currently quarantined zombies, using the trash bin icon to remove them from the list:

info

If a zombie identity that was removed from quarantine remains unused, it will repopulate within the zombie hero card. If you wanted to prevent that identity from being marked as a zombie in the future, create an exemption.

Special Considerations

Silent Reanimation Attempts

A quarantined zombie account tried to take an action, and I didn't get any notification. What happened?

For GCP zombies, this is normal. Quarantined identities cannot take actions in your GCP environment, so are unable to trigger notifications or Permissions on Demand (PoD) requests from Sonrai CPF.

For AWS zombies, a quarantined identity that tries to act will normally generate a PoD request... but in rare cases, a zombie might try to reanimate without notification! Don't worry, your cloud is safe and the action will fail - but it's important to understand why this can happen, and how to ensure your automated tools run smoothly.

Why it happens...

This behavior may occur if a zombie identity is an automated tool that runs infrequently and uses unaudited actions. For example, consider a Snowflake integration that only runs annually to check the contents of a specific AWS S3 bucket. (Note that AWS Data Events like the s3:ListBucket permission don't create an entry in the CloudTrail audit log.)

Such an identity will be marked as a possible zombie after 90 days of inactivity and may become quarantined. The next time it tries to act, Cloud Permissions Firewall will block the action but won't send a Permissions on Demand notification because there was no audit log event recorded.

What to do...

The best way to ensure that automated tools don't fail silently when they try to reanimate depends on your specific implementation.

Option 1: Create a Zombie Detection exemption for this identity, so that it will not be flagged as a zombie or quarantined.

Option 2: Change the frequency that your automated tool is run, to ensure that identity avoids turning into a zombie.