Read: 3 mins.
Print Friendly, PDF & Email

The Security Operations Center (SOC) noticed logins to Azure Active Directory (AAD) from yahoo.com and gmail.com email addresses and asked the IT Security team to investigate. At the time, we did not allow many B2B Guest credentials for those domains, but alarmingly, the accounts in question successfully authenticated even though they did not exist in our AAD tenant. Who were those people? Did we have a security breach? What did they access?

The Hunt

An investigation was launched by multiple members of the security team, combing through Splunk logs, Incident Detection and Response (IDR) systems, Azure AD sign-in audits, Office 365 Security & Compliance tools, and other related areas, but the search came back empty with the exception of the “User logged in” events reported by the IDR. A scripted query through Active Directory and Azure AD also found no such users existing anywhere in our identity provider systems.

The users in question accessed App ID “0000000c-0000-0000-c000-000000000000” that corresponds to the “Microsoft App Access Panel” — or the “MyApps.microsoft.com” portal. Were there any applications accidentally published to all users by default? No, there were none without specifically being granted rights.

“Microsoft App Access Panel” App ID

Logs did not show any further actions involving the suspect logins or their IP addresses.

The Cause

My senior security colleague opened a critical case with Microsoft for a possible breach, and after further analysis, the Office 365 Sr. Support Escalation Engineer referred him to a Microsoft 365 Unified Auditing article that details how to “use the audit log to investigate common issues”. Specifically, he was directed to the section, “Investigate why there was a successful login by a user outside your organization“. Turns out, the behavior is by design.

When an external user tries to access a Microsoft first-party application, he would be asked to authenticate with Azure AD to verify his identity even if the account does not exist in that tenant.

A Microsoft first-party application includes, but is not limited to:

  • Microsoft App Access Panel
  • SharePoint Online
  • OneDrive for Business
  • Exchange Online
  • Power BI
  • Microsoft Teams
  • Yammer

Once confirmed, a “User logged in” event is recorded in the Unified Audit log. All that means is that our Azure AD successfully confirmed the account’s identity (and only its identity), and a resource in our tenant was not necessarily accessed nor was an action taken by that external user. This process is allowed by “pass-through authentication“.

As Microsoft’s documentation clarifies:

  • “Azure AD allows pass-through authentication only for first-party applications, such as SharePoint Online and OneDrive for Business. It isn’t allowed for other third-party applications.”
  • “In order for a pass-through user to access SharePoint or OneDrive resources, a user in your organization would have to explicitly share a resource with the external user by sending them a sharing invitation or anonymous sharing link.”

Sample Scenarios

  • An external user was sent a OneDrive for Business link and is asked by Azure AD to authenticate in order to access the shared file or folder.
  • An external user meant to log in to her own company’s Exchange Online portal but accidentally went to our company’s. Azure AD asks her to authenticate, and upon successful confirmation, she is redirected to her company’s Exchange Online mailbox.

Audit Record

Refer to the below audit record for a “User logged in” pass-through authentication event:

Audit Record /Microsoft

  • A) “ID: Unknown” (Type: 0) = User does not exist in the Azure AD tenant
  • B) “[email protected]” = External user’s UPN
    • Same as “User” and “UserId” fields in the audit record
  • C) “ApplicationId” = Application that triggered the logon event. In this case, “0000-0ff1-ce00-000000000000” is SharePoint Online/OneDrive for Business
  • D) “ResultStatusDetail: Success” = Pass-through authentication successfully confirmed the identity with Azure AD
  • E) “RecordType: 15” = Event, “UserLoggedIn”, is a Secure Token Service (STS) logon event in Azure AD

Next Steps

When a user has successfully authenticated to your Azure AD tenant via pass-through authentication, and logs do not show any further activity by said account or IP address, the Microsoft Sr. Support Escalation Engineer advised to “carry out due diligence to make sure the user only appears in the UserLoggedIn events.” He added, “Otherwise these events can be ignored.”

Related Posts

Credits:
– Featured Image by Matthew Henry via Unsplash