PoC exploit released for Azure AD brute force bug: here’s what to do
A public proof of concept (PoC) exploit has been released for the brute force Microsoft Azure Active Directory credentials vulnerability discovered by Secureworks and first reported by Ars. The exploit allows anyone to perform both username enumeration and password brute force on vulnerable Azure servers. Although Microsoft initially called the automatic logon mechanism a “design” choice, it appears the company is now working on a solution.
PoC script published on GitHub
Yesterday a ‘password spray’ PoC exploit was posted for the Azure Active Directory brute force vulnerability on GitHub. The PowerShell script, just over 100 lines of code, is heavily based on previous job by Dr Nestori Syynimaa, Senior Security Researcher at Secureworks.
POC has just burst for the SSO spray https://t.co/Ly2AHsR8Mr
– rvrsh3ll (@ 424f424f) September 29, 2021
According to Secureworks’ Counter Threat Unit (CTU), exploiting the flaw, such as brute force confirming user passwords, is fairly easy, as PoC demonstrates. However, organizations that use conditional access policies and multi-factor authentication (MFA) can benefit from blocking access to services through username / password authentication. “So even when the threatening actor is able to get [a] user password, they may not be [able to] use it to access organizational data, ”Syynimaa told Ars in an email interview.
What can organizations do to protect themselves?
Although it was made public after Secureworks’ disclosure this week, the Azure AD brute force issue appears to have been known to some researchers before, including researcher Dirk-jan:
Interestingly enough, I reported this issue in December 2020 to @msftsecresponse, the last one I heard is that it is still in development for a fix. Quite strange that other people are getting a different verdict on the same issue. https://t.co/2EtfEIM5BE
– Dirk-jan (@_dirkjan) September 28, 2021
Microsoft told Ars that the technique demonstrated by Secureworks does not constitute a security vulnerability and that measures are already in place to protect Azure users:
“We have reviewed these claims and determined that the technique described does not involve a security breach and that safeguards are in place to ensure that customers remain secure,” a Microsoft spokesperson told Ars. After reviewing the initial drafting of Secureworks, Microsoft concluded that the protections against brute force attacks already apply to the described endpoints, thereby protecting users from such attacks.
In addition, according to Microsoft, tokens issued by the WS-Trust
usernamemixed the endpoint does not provide data access and must be presented to Azure AD to get the actual tokens. “All these requests for access tokens are then protected by Conditional access, Azure AD multi-factor authentication, Azure AD Identity Protection and surfaced in connection logs,Microsoft concluded in its statement to Ars.
But, Secureworks also shared additional information it received from Microsoft after it released its analysis this week, indicating that Microsoft is working on a solution.
“First, the login event will be populated in the Azure AD login logs. Second, organizations will have the option to enable or disable the endpoint in question. These should be available to organizations within the next two weeks, ”Syynimaa told Ars.
Security solutions architect Nathan McNulty Already reported seeing successful connection events appearing in connection logs:
Amazing work from the Azure Identity team!
They have already added the success audit logging for the WS-Trust MEX endpoint to the non-interactive connection logs (no failures yet)
Get-AzureADAuditSignInLogs doesn’t seem to show up in the Graph API (good news for SIEMs) 🙂 https://t.co/A130Uh7OeY
– Nathan McNulty (@NathanMcNulty) September 29, 2021
Azure AD also comes with a “Smart lock“feature designed to automatically lock targeted accounts for a certain period of time if too many login attempts are detected.
“When locked, the error message is always ‘locked’ no matter [of the password being correct or not]. As such, the feature appears to effectively block hard forcing, ”Syynimaa added to Ars. “However, password spray, where multiple accounts are targeted with a few passwords, likely won’t be blocked by Smart Lockout. “
Syynimaa’s advice to organizations looking for a workaround against this attack is to adjust the number of failed authentications before Smart Lockout starts and locks accounts. “Setting the value to a low value (like 3) also helps prevent password pulverization, but can also lock out accounts too easily during normal daily use. »Setting the lockout time is yet another option.