Hero Card: Zombies
© 2025 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 2: When Insiders Cause Problems
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 employees' time at the company. The attacker bruteforced 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
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!
- Organization-wide - Complete a clean sweep of zombies across your entire AWS Organization
- OU-based - Select an OU from the scope dropdown & quarantine the zombies within
- Account-level - Select an OU then an AWS Account from the scope dropdown & quarantine the zombies within
- Individual identities - At any selected scope, quarantine any individual identity!
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.
Example:
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 theAdminRolelast used 30 days ago, etc. c) OU-based (parent) - Quarantine all the OUs & nested AWS Accounts under the Dev OU
Zombie identities can be reanimated, gaining privileged service access through a Permissions on Demand (PoD) request.
To view the list of quarantined zombies at this scope, open the menu on the Services page:
See "Exporting a List of Zombies Per Account" in the API documentation for query details!
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:
If a zombie identity has been removed from quarantine and 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?
In rare cases, a quarantined zombie might try to reanimate without generating a Permissions on Demand 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.