On this most ghoulish day of the year, we’re bringing you a cautionary tale of the dangers lurking in your third-party applications. 

Identity attacks like phishing, credential stuffing, and session hijacking are now the leading cause of cybersecurity breaches, as attackers shift their attention to the sprawl of third-party applications and services that have become the backbone of business IT. 

Ghost logins are one of the leading factors in successful credential stuffing attacks — but unless you’ve been following the identity attack research from Push Security, you’re probably not aware of them. 

Ghost logins 101

Ghost logins are C. Ghost logins are hidden from the view of security teams, meaning they’re likely to possess weak configurations that make them susceptible to account takeover attacks. According to our research, ghost logins are present for around ten percent of all accounts per organisation. 

Why do ghost logins exist?

Identity management used to be something that was centrally managed via Active Directory. Most users probably only had one or two identities that you really cared about: one to log into their company laptop and domain, and one to access the VPN. 

Now, there are 200+ business apps in use per company, creating thousands of sprawled identities across an ecosystem of business apps and services accessed over the internet.

Most businesses have tried to solve this problem with single sign on (SSO). The logic being that if you can use a single set of credentials (and therefore, a single identity) to access all of your business apps, and then secure those credentials with MFA, then this problem goes away. However…

SSO expectations versus reality

Unfortunately, the reality of SSO implementation is flawed, because: 

1) Apps accept multiple login methods that can be configured — and used — simultaneously.

2) Most apps can't be locked down to restrict which login methods are accepted.

3) Users often self-adopt apps, and default to a username and password (and typically miss out MFA). 

4) SSO isn’t always possible if you aren’t using a supported identity provider (IdP) - and only one in three apps support SAML, the preferred enterprise-grade protocol.

5) Even where SSO is possible, configuring an app for SSO doesn't automatically delete any legacy local logins. 

Inevitably, this means that there are many situations in which users will create local accounts - typically with a username and password, and without MFA. This is how ghost logins are born.

Ghost logins are invisible to security teams

As you might expect, this means ghost logins are pretty much invisible. Because your IdP doesn’t give you visibility of local logins, you’d need to log into the app admin dashboard to find them.

Getting admin permissions for a self-adopted app is the first hurdle. But even with access, it’s not always easy to gather this level of account configuration data. Let’s look at a real-world example.

Case study: Snowflake

The recent attacks on 165 Snowflake customers, resulting in hundreds of millions of breached customer records, were the product of a credential stuffing campaign using stolen credentials from infostealer infections dating back to 2020. 

The industry response to Snowflake was typical: check whether Snowflake has been set up for SSO, and if so, job done — we’re protected by MFA.

The reality was that MFA was not — and could not — be centrally enforced for username and password accounts. Even if MFA was applied at the IdP level for SSO logins, it was not enforced for local username and password logins. It needed to be opted-into by the user. 

This meant the most logical thing to do was to disable local accounts.

Because Snowflake is essentially a cloud-hosted SQL database, there was no easy-to-use GUI to access local account config data. Once you’d managed to get an admin account with the right permissions, you needed to run various commands to find and unset the accounts. Even if you didn’t have the exact type of admin account, misleading results would be returned — and even after you had fixed the vulnerability it took hours to update the database. 

This meant that organisations were exposed to these attacks for a prolonged period, and were left uncertain as to whether they had addressed the vulnerabilities or not. 

Ghost logins are coming for your accounts — so who’re you gonna call?

The first step to busting those ghost logins is acknowledging that ghost logins are real — and they can hurt you. Finding and fixing ghost logins is a challenge for most organisations. Since you can’t rely on the view provided by your IdP, you need to:

    • Discover the apps in use across your organisation

    • Get admin rights, audit each app, and unset any local credentials (enforcing MFA at the app-level too if you can, for good measure)

    • Configure the app to prevent local accounts being created (again, if possible)

Not only is this a sisyphean task with continually moving goalposts, but depending on which apps you use, and how they’ve been designed, it may not be possible to remediate every instance of ghost logins.

For that reason, it’s important to also invest in your identity threat detection and response capabilities — for when, not if, an account takeover attempt occurs.

Dan Green Security Researcher Push Security