I recently received a support case where the customer was concerned that a bad actor “fim_password_service@support.onmicrosoft.com” was performing SSPR \ Password Reset operations on their Azure AD user’s without authorization.
UPDATE (2022-10-28)
There are other opeations which may be logged as fim_password_service@support.onmicrosoft.com being the actor. This includes
- SSPR portal updates to a user during SSPR password reset from https://aka.ms/sspr portal
- MFA and SSPR Security Info registration from https://aka.ms/mysecurityinfo portal such as adding/deleting/updating Microsoft Authenticator registration details (StrongAuthenticationPhoneAppDetail, AuthenticatedTimestamp and OauthTokenDriftTime etc.)
If you have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles
Unknown Actors in AAD Audit Reports
Verify first-party Microsoft applications in sign-in reports
When checking the Azure AD Audit Logs, they found entries similar to the below screenshot:
This is concerning as the customer has no account in their AAD tenant with the UPN fim_password_service@support.onmicrosoft.com.
We performed a reproduction of a standard SSPR operation performed by a known user, and confirmed that these logs appeared and are to be expected.
A successful SSPR operation will first show the user who performed SSPR performing verification steps, submitting a new password, and then the fim_password_service@support.onmirosoft.com service account resetting the user’s password as seen in the below example:
If you expand your audit log search for all operations with the target account specified, you will see that the user who actually initiated the SSPR action is also audited.
We found it odd that this service account was performing the actual password reset so there was an escalation opened with our engineering team to review. They confirmed the same, that this is to be expected.
” fim_password_service@support.onmicrosoft.com is an internal account used to indicate password reset is done in App context versus App + User context. “
This means that as the user doesnt know their password, the reset operation can’t be completed in the context of the SSPR app + User, so in certain scenarios such as SSPR, AAD operations are performed in the App context only and thus are audited as the actor being the internal account fim_password_service@support.onmicrosoft.com.
UPDATE (2022-10-28)
There are other opeations which may be logged as fim_password_service@support.onmicrosoft.com being the actor. This includes
- SSPR portal updates to a user during SSPR password reset from https://aka.ms/sspr portal
- MFA and SSPR Security Info registration from https://aka.ms/mysecurityinfo portal such as adding/deleting/updating Microsoft Authenticator registration details (StrongAuthenticationPhoneAppDetail, AuthenticatedTimestamp and OauthTokenDriftTime etc)
The engineering team acknowledged that this can be confusing to customers and they are working on publicly documenting this account to prevent future support cases in the future. I’ll be sure to update with a link when that occurs.
Hope this answers someone’s questions in the meantime!