Given the recent report from Microsoft regarding a cyber-attack on their organization by Russian state-sponsored hacking group, Midnight Blizzard, our SOC Team wanted to raise awareness concerning Threat Actor behavior related to Entra ID (formerly Azure ID) app registrations/app consent per what we have been seeing in the news and in the wild.
You can read Microsoft’s report detailing this behavior that was observed during their own recent compromise by this threat actor group: https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/
This post explains that the threat actor group “Midnight Blizzard” gained access to an account through a password spray and then leveraged existing OAuth applications and created additional applications to escalate privileges and compromise additional accounts.
Our DFIR team has also seen similar behavior recently during BEC investigations, where compromised account gave consent to a specific third-party application called “PerfectData Software” likely in an attempt to exfil mailbox data.
See the following link for additional information on this specific behavior: How Abuse of ‘PerfectData Software’ May Create a Perfect Storm: An Emerging Trend in Account Takeovers | Darktrace Blog
The following will detail the actions we are detecting on our end to better detect this type of post-compromise behavior related to app consent grants/permissions/registrations and how we recommend you can mitigate this type of attack in your environment.
SecurIT360 SOC Managed Services
Last week, our managed SOC services rolled out a new alert that will detect the creation of a service principal that looks for “PerfectData Software” specifically. A service principal in Entra ID (Formerly Azure AD) is an identify created to manage access for applications, hosted services, and/or automated tools.
We also plan to create an additional rule or rules to provide auditing for application management within our Monthly MDR reports.
Additionally, as always, we will continue to provide monitoring and alerting concerning initial access by looking for possible password sprays, MFA bombing, suspicious logins, etc. to attempt to prevent this sort of behavior before it happens. However, as we believe in a defense in depth approach, we will continue to expand and refine our post-access detection capabilities through the rules mentioned above.
Please feel free to contact the SOC via email at soc@securit360.com if you have any questions or concerns.
Mitigation Recommendations
By default, users are allowed to register applications and give consent to third party applications. This means that if a Threat Actor compromises a standard user account they can give consent to apps or register apps, without having any admin permissions or an admin being notified.
However, you can restrict this behavior by editing default role permissions and require admin consent to be given before a user gives access to an application. We strongly recommend you adjust this default permission and review all active registrations ASAP.
How to Change Default Permissions
- In order to restrict default user role permissions, within the Azure portal you can go to Microsoft Entra ID -> Users -> User settings and change the slider for “Users can register applications” to “No”:
See the following Microsoft KB article to learn more about default user permissions: Default user permissions – Microsoft Entra | Microsoft Learn
- To turn off or edit a user’s ability to grant consent to third part applications you can go to the Microsoft Entra admin center -> Identity- > Applications -> Enterprise applications -> Consent and permissions -> User consent settings.
- You can also configure a workflow that would allow admins to consent on behalf of users: Configure the admin consent workflow – Microsoft Entra ID | Microsoft Learn
Review Existing App Registrations
Once the permissions have been changed, perform a review of all current App Registrations within your Azure/Entra ID environment and consider disabling all of them that are not approved.
Additionally, as we saw in the Microsoft case, regular auditing of app registrations and permissions in addition to similar auditing for user accounts is always recommended and an important part of lowering the potential impact of an account compromise.
Please let us know if you have additional questions or concerns. We are always happy to help you adjust in response to new or emerging threats.
Ready to make cybersecurity your strength, not your weakness? Contact us today and let’s build a safer, more secure digital future for your business.
