Ghost logins: When forgotten identities come back to haunt you

Workforce identities – the accounts that your employees use to access their suite of business applications – are increasingly complex. 

Previously, employees only really had one primary identity linked to their AD profile that they used to access their work laptop and corporate domain, with maybe a second layer of authentication for a VPN connection to access internal network services. Apps were installed locally on the user device without any further authentication required.

Now, the vast majority of the business apps that employees use are accessed over the internet, in the browser. Employees rely on a long list of third-party services, all with their own separate accounts. 

This obviously makes managing these accounts harder. There are many more accounts, and many more apps, with significantly less central oversight and control. As yet, there is no master interface to administer your SaaS sprawl. You might expect this to be your IdP (e.g. Okta or Microsoft Entra) but when we consider that only 1 in 3 apps support SAML SSO, and only 1 in 5 business apps are actually behind SSO, the vast majority of your business apps need to be administered individually. 

But, this is actually just the tip of the iceberg. When we look under the hood at the makeup of an identity, it gets worse still. There are a lot of components to pick at, but the one we’ll focus on in this article is that multiple login methods can exist for a single user account, simultaneously. We call these ghost logins. 

How are ghost logins created? 

Ghost logins can be created in the following ways:

• A user self-adopts an app, setting up an account with a local username and password. The app is later adopted companywide and brought under SSO. This creates an additional SSO login method, likely as the default, but the local login will continue to exist unless explicitly disabled or deleted. 

• Secondary/backup login methods can often be added later in the app settings after logging in. This includes things like setting up a secondary email to send a login link to, or setting up API access to remove the need to authenticate altogether. 

So, ghost logins are very easily introduced through the normal course of app adoption and use by employees. 

Why do apps allow ghost logins? 

From the perspective of product-led growth (PLG) with a focus on a seamless user experience to encourage new users, allowing users the freedom to choose from multiple logins makes sense. It also shows us that in most cases (with a few exceptions), vendor product and security teams do not harmonize particularly well, as the focus on flexibility typically comes at the expense of security.

This is a widespread challenge that affects all third-party app vendors and service providers. And unfortunately, the way to remediate this vulnerability varies considerably from app to app, vendor to vendor. 

Why do ghost logins pose a risk? 

Ghost logins pose a risk for a number of reasons, as they: 

• Typically have less secure configurations than your preferred login method – and may be missing key controls like MFA.  

• Are effectively shadow logins – IT/security don’t know about them, and if using an IdP as your primary identity security interface, they won’t necessarily be visible without taking a deeper look at individual apps. 

• Can often be used simultaneously with SSO – so you can have two (or more) concurrent sessions with SSO and non SSO logins active at the same time, without the user being kicked out of the previous session.

Ghost logins provide opportunities for attackers to bypass security controls for initial access and persistence in an application (which we’ll come onto in more detail later). They also provide an opportunity for malicious insiders, e.g. a disgruntled employee, to access systems even after SSO access is revoked. If the security team relies on IdP logs to audit app logins (which many do, because audit log availability per app can be limited) these accounts can therefore be hidden from the security team, creating a blind spot. 

It’s very easy to see how these vulnerable login methods can be overlooked by security teams – let’s look at how they can be identified and exploited by hackers. 

How can ghost logins be abused by attackers?

Let’s take an example scenario: You’re using an IdP solution like Okta or Microsoft/Entra with SAML SSO as the default login method for your core business apps. Via your IdP you require MFA when authenticating to your IdP apps page, and also potentially when signing into an individual connected app. 

However, you only recently introduced your IdP solution, and your users previously accessed this app with a local username and password. Although you asked your users to configure MFA in the app itself, not all of them did. And when you deployed your IdP solution, you didn’t manually unset all the local password-based logins for the apps you connected to it. 

Unknown to you, there are now hundreds of local accounts for core business apps which lack MFA. 

There are two main scenarios in which ghost logins can be utilized by an attacker:

• To bypass robustly configured login methods such as SSO to compromise an app identity during the initial access phase of an attack. 

• To create additional login methods for an already compromised account to ensure persistent access – even if the original compromised login method is revoked or disabled. This could be either the result of compromising an identity belonging to a specific app, or having previously compromised an IdP account (e.g. Okta).

Let's look at these use cases in more detail.

Ghost logins for initial access

Arguably the most dangerous use case for ghost logins is to conduct credential attacks against accounts using a username and password. Logins with a weak or guessable password, or a reused password that has appeared in a public data breach dump, are primed for account takeover. 

The cyber crime ecosystem seems to be leaning toward the theft, sale, and use of stolen credentials (not just emails and passwords, but session tokens too).

• According to the 2024 DBIR, more than 1000 credentials appear on criminal forums and marketplaces every day, with the majority (65%) appearing less than a day after first being discovered.

• In June, Troy Hunt at Have I Been Pwned (HIBP) wrote about the impact of channels like Telegram and the sale of combolists (username, password, login portal URL), after being sent 122GB of data scraped out of thousands of Telegram channels, containing 361M unique email addresses (of which 151M had never been seen in HIBP before).

• In July, 10 billion passwords were leaked in the RockYou2024 compilation. 

So, it’s easier than ever for attackers to identify breached credentials and weaponize them at scale. 

Realistically, any username and password combination for addresses belonging to a specific organization/domain can be attempted on any app. Breached credential data will often provide a strong indicator of other apps also in use for that organization. And for apps with a custom tenant URL (that cannot be easily guessed) data dumps often helpfully include the URLs for those login pages, too.  

As evidenced previously, attackers have a huge (and growing) data set with which to conduct credential stuffing attacks. The risk posed by the massive amounts of leaked credentials is heightened because: 

• Many employees reuse passwords (we see credential reuse for 1 in 3 employees). This isn’t just for low-risk apps either, and includes the reuse of highly sensitive IdP creds. 

• Organizations don’t typically rotate or enforce changes to SaaS app passwords in the same way they might for company account/device login connected to Active Directory.  

The recent Snowflake breach provides compelling recent evidence for this, where credentials were successfully used that dated back to 2020. 

Ghost logins aren’t limited to just username and password either. For example, a breached social account such as Facebook or Google can result in a broader compromise if those accounts have been connected to any corporate apps.  

So, exploiting ghost logins can be a highly effective method for attackers to gain initial access to a user account from which to launch further attacks.  

Ghost logins for persistence and defense evasion

Now, we’ll take a look at how attackers can leverage ghost logins as part of the later stages of an attack, having already established an initial foothold via account compromise. 

If an organization has a reasonable level of security monitoring in-place (depending on log availability from the particular app vendor), or a victim receives a notification about an unusual login (e.g. from a new device or unusual IP) then access to an account can be short-lived. However, ghost logins can provide attackers with the tools to maintain persistent access to a compromised account, even if the initial compromised login method is disabled or revoked. 

For example, if a social login is used to access an account, an adversary may be able to configure a separate username/password login, or even (though much less commonly) connect a second social account that the adversary controls. This allows the adversary to maintain persistent access to the user account even in the event of password changes or MFA changes. The attack will go unnoticed if the victim organization relies on SSO logs for auditing access to SaaS applications because the attack bypasses SSO, as the login remains local to the SaaS app or, in the case of an OIDC SSO login, the adversary’s own social account.

Another quirk is that it’s common for ordinary users to become app-level admins when an app is self-adopted by an individual or team. If an attacker is able to gain control of such an account, it can then be used to target other users without needing to deliver phishing links by hijacking SAML-based authentication. In this scenario, users attempting to sign in using SAML SSO are directed it to an attacker-controlled tenant in a watering hole attack (also known as SAMLjacking, which you can read more about in another blog post). 

Check out the video below to see this in action. In this example, the attacker has managed to compromise an Okta account providing SSO access to multiple downstream apps, and is attempting to establish persistent access ahead of any incident response efforts to kick them out of the primary Okta account and target other users to move laterally inside the organization.

If you're curious as to how an attacker might be able to compromise an IdP account such as Okta, you should check out our blog post on AitM and BitM phishing techniques.  

Remediating ghost logins

While they are easy to introduce, ghost logins are not quite as easy to get rid of. This is not because removing them is complex (though it may be depending on which apps are in use), rather because:

• If you’re relying on an IdP solution for cross-app identity data, you’re naturally limited to only apps that are connected to your IdP for login via SSO – which we find is only around 1 in 3 apps per organization. This leaves a significant blind spot, where you may be unaware of many of the apps (and associated identities) in use.  

• For the apps you are aware of, you will only be able to observe login methods set via the IdP – excluding local logins. For this information, you will need to query each app individually. This may be possible via API, but for many apps you may need to log into the admin portal. This naturally requires that you are an app administrator (which is not always the case when apps are self-adopted by users rather than central IT/security teams). 

• When in the app, the tools you have at your disposal to disable and unset non-SSO logins may vary. It may be possible to remove password-based logins, but might not be possible to prevent it entirely, or block other login methods. 

As an example, check out this excerpt from our Snowflake webinar, where we demonstrated how to remediate ghost logins in Snowflake (and how complicated it can be!).

Using Push to find and fix ghost logins across your app inventory

To be able to effectively combat ghost logins at scale, you need to be able to:

• Find all apps in use across your business users, inside and outside of your IdP/SSO.

• Identify and correlate all accounts, login methods, and MFA types in use to pinpoint risky accounts and login methods for remediation, per app and per user.

• Mitigate the potential impact of ghost logins by enforcing best practice identity configurations.

To help tackle this problem, Push instantly detects every login performed in browsers running the Push extension, and gives you the tools to discover, remediate, and mitigate ghost logins at-scale – protecting your identities from account takeover.

Conclusion

The important take home is that, even for cloud identities on downstream SaaS apps you have configured to use your tightly controlled SAML SSO provider, they might still be accessible using much weaker cloud identities. 

Applying the same scrutiny to SaaS apps as you would to your domain credentials is key to stopping identity attacks. It’s important to audit downstream apps to put controls in place to prevent ghost logins, identifying and disabling weak authentication mechanisms, and enforcing password-based controls to prevent weak and reused passwords. 

If you'd like to learn more about ghost logins and other identity attack techniques, check out the SaaS attack matrix on GitHub.