Daily Blog #732: Multiple Identity Provider Disorder

Hello Reader,

This summer, we encountered a fascinating incident that highlights a surprising gap in how some third-party services handle authentication. Brian Krebs later covered the underlying issue in his post “Crooks Bypassed Google’s Email Verification to Create Workspace Accounts, Access 3rd-Party Services,” but our investigation was already finished by then. Let’s dive in.

---

The Scenario

Imagine your company has a third-party service provider where employees can create their own accounts. This service also supports authentication through multiple identity providers—like Google, Apple, or Facebook—to make logging in easier.

However, there’s a catch: in some cases, the third-party service will treat an identity-provider-based login as if it were the same account an employee created manually—even if they never actually linked their account to that identity provider.

---

How this Exploit Worked

1. Manual Account Creation

   A user signs up for a third-party website using their company email address and even enables multi-factor authentication (MFA).

2. Multiple Identity Providers

   The third-party site allows users to log in via providers like Google. Ideally, this is meant for convenience instead of creating an account manually.

3. Domain Hijack

   A threat actor finds a loophole that lets them register the same email address on Google Workspace—even though the domain actually belongs to someone else. (See Krebs’s article for how they bypass Google’s verification.)

4. Unintended Access

   Once the attacker has set up that Google Workspace email, they sign in to the third-party service using Google. Because the service trusts Google’s authentication, it grants the attacker access to the real user’s account—MFA included.

---

Why This Shouldn’t Work

• Identity Provider Verification

  Google (or any identity provider) should confirm domain ownership before allowing someone to create email accounts for that domain. Attackers found a way around this requirement.

• Third-Party Account Linking

  The third-party service should recognize that the user’s existing account isn’t linked to Google. However, many services fail to confirm whether an account was created manually vs. through an identity provider, resulting in the user’s legitimate account being “taken over.”

---

Our Investigation

In the logs, we noticed a user’s account authenticating via Google—odd, since that user’s company uses Microsoft 365. After reaching out to Google, we learned that the domain had recently been set up on Google Workspace, which led to a small set of logs confirming a brand-new account. Initially, we thought the third-party website might have suffered a larger breach. Then Brian Krebs’s coverage explained exactly how attackers managed to bypass Google’s email verification, confirming our findings.

---

Things to look for

• If you’re investigating an incident and see a user “miraculously” authenticating—especially if it’s not a straightforward case of stolen tokens—check the identity providers the third-party service supports.

This case was a stark reminder that even well-known platforms can be manipulated if there’s a loophole in domain or email verification procedures.

Also Read: Accessing multiple shadow copies at once with AIM

Read More

Daily Blog #721: The new hardest question to answer in an incident

Hello Reader,

When an attacker compromises a single user’s credentials, the immediate concern is no longer limited to that user’s inbox or workstation. Instead, it can quickly expand to the entire ecosystem of externally hosted services and apps connected to that account. This challenge poses several unique problems:

1. Identification of All Linked Services

Many organizations lack a centralized, real-time inventory of the external services each login has access to. As a result, the incident response team must quickly piece together which third-party platforms are integrated with the compromised account—an often gargantuan task.

2. Visibility Gaps

Even when SSO or identity management systems are in place, visibility might be limited. Some SaaS vendors offer only basic logs, making it difficult to determine if the attacker accessed or manipulated data within those services. Some offer no logs at all!

3. Third-Party Risk Management

Security posture assessments and vendor questionnaires help, but they don’t always guarantee robust incident response capabilities from each third-party. If data was accessed or stolen, companies must coordinate with multiple external providers to understand the breach’s scope, which can slow down containment efforts. Sometimes just knowing who to contact at the individual vendor in the event of an incident can take days. 

4. Regulatory and Compliance Overlaps

Access to third-party systems often means multiple compliance regimes could be in play (e.g., HIPAA, GDPR, PCI DSS). Failing to account for these can lead to significant fines, reputational damage, and legal complications.

So if you are trying to determine where you should focus your teams attention to be prepared for the next incident, start the long journey to building the catalog, knowledge and contacts to be able to answer this question on demand. 

Also Read: Spotlight on zeltser challenge participant - Chris Eng

Read More

Daily Blog #312: Remote Connections and Credential Exposure Part 1

Hello Reader,
      I've had two Sunday Funday challenges now that both relied on the responders knowledge of what credentials they leave for the attacker to find/exploit when responding. I don't know how well understood this is so I thought I would setup some virtual machines and then connect to them through a series of remote access methods to see what it exposed to the attacker. In this series I am planning to connect remotely with the following:

1. RDP
2. Network Share
3. Remote Registry
4. Powershell
5. F-response
6. PSExec

On the virtual machine being connected to I will then run the following three tools to see whats exposed:
1. Windows Credential Editor
2. Mimikatz
3. Meterpreter

and document my results. My hope is that if this is not already tested and documented that you will get fresh insight on how to best respond and interact over the network.

Also Read: Daily Blog #311

Read More

Daily Blog #296: Domain lastlogin timestamps and tracking recon

Hello Reader,
         Normally I would save something like this for Saturday Reading but the following two articles brought enough interesting thoughts that they deserved their own post. The first is from 2009 and if you are doing any work within an Active Directory environment deserves your attention, read it here:

http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

What's important to take away from this article is that Active Directory since the introduction of Windows 2003 Domain Function Level provides a synchronized timestamp across domain servers called 'lastlogontimestamp'. This first of the two articles we will talk about today is important if you are interested in two things:

1. When the last time all users interacted with the domain, the article specifies levels of interaction as interactive, network, and service logins. However as you'll see in the second article that isn't exactly true. However what is going to be true is that this timestamp is sync'd across all domain controllers within the domain.
2. That the timestamp itself does not reflect the actual true last logon time of a user. It just reflects if that user account has logged in within the last 14 days.

The second part may seem like it makes the first part and its caveat less useful but I would say to you don't give up on it just yet. Take a look at the second article linked here:
http://blogs.technet.com/b/askpfeplat/archive/2014/04/14/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self.aspx

where we learn that not only is the timestamp synchronized across domain controllers but applications that are trying to query across the domain count towards this logon event. So why is this useful to us? What should you taken away from this?

1. If an attacker or a rogue insider is trying to gather intelligence across you enterprise by querying different groups, service accounts and the like that it will in fact trigger a logon event that will change the lastlogon timestamp. This means that if you quickly preserve these timestamps today you can find the last logon values of service accounts that don't do domain logins. Then moving forward if that timestamp changes you can act on it to determine who is suddenly enumerating information about your domain.
2. That if you extended auditing rules setup, as mentioned in the second article, you can catch which account is actually going out and enumerating. The enumeration does not require that the account in question has the credentials of the resource being queried and does not actually login into the account. Instead its just a by product of how the querying is being done within the api itself.

So there you go, Internal IR people go petition IT to change your Domains by adding additional event logging and preserving the current state of your lastlogon timestamps now to take advantage of this to its full extent.
Consultants start querying this across the domain to start getting additional intelligence regarding when recon may have taken place. If you start noticing that a large number of old service accounts and unused accounts all have recent last logon timestamps that should be a clue that this timestamp may relate to some domain recon within the environment.

Let me know your thoughts!

Also Read: Daily Blog #295

Read More