Beyond Buzzwords: The Hidden Dangers of Ephemeral Accounts in Cybersecurity

What are Ephemeral Accounts?

Corporate audits today, for cyber security insurance or compliance, focus on group memberships to identify who has access to what. This process identifies who is a Domain Admin, Enterprise Admin, Local Administrator, Database Global Admin, Global Admin in Azure, and Root Access in AWS. Accounts with this level of access likely have static privilege. I like to call these accounts game-over accounts. If these accounts are compromised, the company will have a massive issue on its hands.

Other account types lurking in your environment can cause this level of damage. Many DevOps accounts and API keys can also cause this level of damage if compromised. DevOps accounts sometimes fall under the radar outside of the scope of compliance and cybersecurity insurance.

The new Privileged Access Management buzzword among vendors, analysts, and operations teams is Ephemeral Accounts. A common phrase I tend to hear is that we don't have static privileged accounts; we use ephemeral accounts. To create an ephemeral account, you request access to an account via a Privileged Access Management (PAM) solution, an account is created in real time with a random name, and privileges are assigned. To facilitate convenient workflows, many companies enable the use of ephemeral accounts because they can conveniently be created and deleted at will. This convenience comes with significant risk to organizational access.

The problem with ephemeral accounts

There is an inherent problem with these Ephemeral accounts, as the names are randomly generated, used with high levels of privilege, and revoked in real-time. This process makes it nearly impossible for the security operations team to understand:

• Who created the account?
• What is the purpose of the account?
• What action happened with the account?
• Was the action authorized?

Ephemeral Accounts are a Security team's nightmare. The endpoint logs indicate a login with a random account, like this admin-temp-as8d9e8. It's given AD Enterprise Admin rights, and the account is used to take an unknown action by an unknown person. Once the action is completed, the account is deleted. The problem with this is that you now have an unresolved Security Identifier (SID) in the audit or with permissions to some file share. The logs show the account existed, but these audit logs are quickly rotated on a busy Domain Controller. Many PAM vendors say you can check the audit logs on the PAM solution to figure out what actually happened. Still, the endpoint logs tell a different story, and who wants to correlate logs between two disparate systems? This is critical information required for the incident response teams to understand who did what. These teams spend hours reviewing logs, trying to put the pieces together, and an account that looks like this, "38dkfjrms," does not indicate who is using the account or what its purpose is.

One of the most common things an attacker does is compromise an account, create a new account, and add permissions to gain persistence. This process is precisely the same process when an ephemeral account is created. Many companies that are using ephemeral accounts are ignoring account creation and account elevation event IDs, such as 4720, A user account was created, 4722 A user account was enabled, 4724 An attempt was made to reset an account's password, and 4732 A member was added to a security-enabled local group.

How to altogether avoid them

To avoid ephemeral accounts you can use an Identity Governance and Administration (IGA) solution to automatically create a privileged account that is assigned to a privileged user and assign no privileges to the account. That account can have a specialized indicator that only the company knows, such as -a or -ADMIN. When an account has an indicator with an abbreviation in the front or backend of the account, it allows you to determine the use. The SOC team would immediately know the accounts use. Taking this step further, allowing the account to be personalized with a user's name or an application's name will tie the account back to the person or application that was using it.

Taking that a step further, that account should never have standing privilege. This poses a significant risk for the organization. Accounts with group memberships of roles that never get revoked when not in use are target accounts for attackers. Revoking privileges that are not permanently required allows your company to significantly reduce its attack surface.

Adding JIT or just-in-time access allows your administrators to have the privileges they require only when needed.

The results

This approach provides cleaner auditing and logging. All endpoints no longer have randomly generated account names appearing in logs. The account names match the user or application using them, as well as the defined privileges. The Security Operations team knows exactly who is using what account and what the accounts are used for. Risk is also reduced since each administrator account no longer has privileges unless it's in use, the PAM solution automatically rotates the password, and permissions are revoked since the account is not in use. Incident response teams know exactly where to look and identify threats.

About the Author: This article was written and contributed by Richard Hosgood — PAM Principal Presales Engineer at One Identity North America. With 12 years of experience in cybersecurity, Richard has helped numerous organizations secure their data and systems against threats. A seasoned expert, he brings a unique understanding of how to leverage customer resources to drive effective cyber solutions.

Richard's expertise spans the latest technologies and trends in Privileged Access Management, Security Service Edge, Identity Governance, and more. His passion for protecting companies' digital footprints is matched only by his commitment to delivering exceptional results. With extensive experience working with Safeguard, Richard is a trusted advisor to organizations seeking to build secure enterprise architectures that protect their most valuable assets.