The researchers say that 41.5% of the attacks fail, 21% lead to account lockouts imposed by protection mechanisms, 17.7% are rejected due to access policy violations (geographic or device compliance), and 10% were protected by MFA.

This leaves 9.7% of cases where the threat actors successfully authenticate to the target account, a notably high success rate.

This actually has nothing to do with the fastHTTP library, other than it happens to be the library they use.

Sounds like a classic brute force attempt, which happened to have a 9.7% success rate.
Whether this is bad config on behalf of the user, or bad config on behalf of Azure isn’t really clear.
Regardless, the fault is with Azure for not mitigating this and providing a secure-by-default service.
I can’t believe 10% of users deliberately weakened their security settings.

The article does mention MFA fatigue. I guess where so many “type in the code”/“is this you” type prompts resulted in the user just accepting (or worse, accepting by force of habit) to get rid of them.
Unexpected MFA and security alerts should be investigated immediately.

How is it possible to brute force attack a MS 365 service?

Wouldn’t the service automatically lockout after a few incorrect attempts?