A public proof-of-concept (PoC) exploit has been released for the Microsoft Azure Active Directory credentials brute-forcing flaw discovered by Secureworks and first reported by Ars. The exploit enables anyone to perform both username enumeration and password brute-forcing on vulnerable Azure servers. Although Microsoft had initially called the Autologon mechanism a “design” choice, it appears, the company is now working on a solution.
PoC script released on GitHub
Yesterday, a “password spraying” PoC exploit was published for the Azure Active Directory brute-forcing flaw on GitHub. The PowerShell script, just a little over 100 lines of code, is heavily based on previous work by Dr. Nestori Syynimaa, senior principal security researcher at Secureworks.
POC just popped for the SSO spray https://t.co/Ly2AHsR8Mr
— rvrsh3ll (@424f424f) September 29, 2021
According to Secureworks’ Counter Threat Unit (CTU), exploiting the flaw, as in confirming users’ passwords via brute-forcing, is quite easy, as demonstrated by the PoC. But, organizations that use Conditional Access policies and multi-factor authentication (MFA) may benefit from blocking access to services via username/password authentication. “So, even when the threat actor is able to get [a] user’s password, they may not be [able to] use it to access the organisation’s data,” Syynimaa told Ars in an email interview.
What can organizations do to protect themselves?
Although publicized after Secureworks’ disclosure this week, the Azure AD brute-forcing problem seems to have been known among some researchers previously, including researcher Dirk-jan:
Interesting enough I reported this very issue in December 2020 to @msftsecresponse, the latest I’ve heard is that it’s still in development for a fix. Pretty weird that other people get a different verdict on the same issue. https://t.co/2EtfEIM5BE
— Dirk-jan (@_dirkjan) September 28, 2021
Microsoft told Ars that the demonstrated technique by Secureworks does not constitute a security vulnerability and that measures are in place already to keep Azure users protected:
“We’ve reviewed these claims and determined the technique described does not involve a security vulnerability and protections are in place to help ensure customers remain safe and secure,” a Microsoft spokesperson told Ars. After reviewing Secureworks’ initial writeup, Microsoft concluded that protections against brute-force attacks already apply to the described endpoints, thereby protecting users against such attacks.
Furthermore, Microsoft says, tokens issued by the WS-Trust usernamemixed endpoint do not provide access to data and need to be presented back to Azure AD to obtain the actual tokens. “All such requests for access tokens are then protected by Conditional Access, Azure AD Multi-Factor Authentication, Azure AD Identity Protection and surfaced in sign-in logs,” concluded Microsoft in its statement to Ars.
But, Secureworks also shared additional insights that it received from Microsoft after publishing its analysis this week, indicating Microsoft is working on a solution.
“First, the log in event will be populated to Azure AD sign-ins logs. Second, organisations will be given an option to enable or disable the endpoint in question. These should be available for organisations in the next couple of weeks,” Syynimaa told Ars.
Security solutions architect Nathan McNulty already reported seeing successful login events appear in sign-in logs:
Amazing work from the Azure Identity team!
They have already added success audit logging for the WS-Trust MEX endpoint to the non-interactive sign-in logs (no failures yet)
Get-AzureADAuditSignInLogs doesn’t seem to show it does show 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 Lockout” feature designed to automatically lock accounts that are being targeted for a certain amount of time if too many log-in attempts are detected.
“When locked out, the error message is always ‘locked,’ regardless [of the password being correct or not]. As such, the feature effectively seems to block brute-forcing,” Syynimaa further shared with Ars. “However, password spraying, where multiple accounts are targeted with a few passwords, will likely not 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 will kick in and lock accounts. “Setting the value to low (like 3) helps to prevent also password spraying, but may also lock accounts too easily during the normal daily use.” Adjusting the lockout time is yet another option.
