Historically, security teams would advocate for their IT teams and management to approve the implementation of multi-factor authentication in order to reduce the impact of threats such as brute force attacks against passwords, mitigate fall out from phishing emails and other social engineering related attacks. For context, there are multiple methods of implementing two factor authentication, which includes but is not limited to, SMS based, voice and app based. Once an implementation is in place, this will provide security and incident response teams additional protection and more importantly, additional data points to investigate security alerts.
If the technology team rolls out multi-Factor authentication across the user base without a proper enforcement strategy, their environment is vulnerable to being taken over by threat actors having an interest in your company. There was an Australian Fortune 500 Energy company that planned to roll out these controls in response to an ongoing incident in the environment. However, due to poor project planning and lack of original enforcement across their users, this allowed the threat actors to register their own phones prior to the intended employees.
As with any other breach, reviewing the multi-factor authentication logs will highlight very helpful information that will help your security or incident response understand what happened and the potential origin of the threat. While there are many vendors that offer multi-factor authentication solutions from Microsoft to Okta and Duo, to maintain consistency with previous articles, we will focus on leveraging Microsoft’s environment to analyze the incident and review the logs.
When an analyst is logged into the Microsoft Azure Security Center they can navigate to the Risky Sign in tab and begin their investigation.
Key attributes to review when understanding a breach with multi-factor authentication logs:
If you suspect the user account was compromised, the next step is to reach out to the user directly through a number they have on file with the company or their business line if your company still uses desk phones. If the user confirms that the information has changed, or the activity detected was not them, then additional mitigation actions need to be taken.
There are schools of thought where some intelligence teams will request you let the threat play out so they can track what they are targeting and potentially other behaviors that could reveal who the current threat actor is. This could lead to analysis paralysis and cause more harm long term to the organization if this is allowed to persist. The objective should be to isolate and remediate as soon as possible in order to reduce the long-term impact, which could either lead to ransomware or other data leakage.
Once the decision has been made by the incident commander or lead security analyst involved, the team responsible for active directory and the management of the MFA environment should first remove any devices logged in, revoke any session tokens, unenroll the fraudulent device if one was enrolled, and ensure the user promptly enrolls their own device, registers their phone number, and leverages the app for authentication rather than SMS or voice.
As part of the due diligence, the incident response team should check any recent endpoint security logs or run a deep scan to ensure nothing malicious was left behind by the threat actor.
While no control either technical or policy based is bullet proof, implementing a zero-trust approach and monitoring user accounts with a solution that offers “user behavior analytics” can help security teams proactively monitor user account activity and be alerted much quicker should an issue be identified that falls outside their normal behavior and access.