Most financial institutions understand the importance of Multifactor Authentication (MFA) in keeping unauthorized parties from gaining access to user accounts. The volume of phishing attacks (designed to collect user credentials) and stuffing attacks (designed to take advantage of users who reuse passwords on other sites) is increasing steadily.
It is only a matter of time before a user password is compromised, leaving MFA as the critical control to stop an attacker. But we often find that the way that an institution has implemented MFA can leave gaps that could allow an attacker to get around MFA. The first problem we see is ineffective MFA onboarding processes.
When a user is first set to enroll in MFA, the user must be provided with an initial password that is issued by a system or an administrator. If an attacker learns what that password is, they can enroll as that user and activate MFA. We see some institutions assigning the same simple password (Password123+, etc.) initially to all new users.
Knowing this, attackers will try to log in using these simple passwords until they get lucky, then use the password to set up MFA. In extreme cases, we sometimes see institutions using no passwords at all initially or see institutions using the default password that came with their MFA solution.
Institutions should be sure to provide each new user a unique, long, complex password for every account that requires MFA enrollment, and to communicate that password to the user using an out of band method (phone calls, etc.) to reduce the chance that an attacker will be able to intercept the password in transit.
The second problem we see is that organizations sometimes set up users for MFA enrollment, then never follow up to see if the user ever enrolled. If an institution uses MFA for remote access but a user never connects remotely, the user account is at a higher risk of unauthorized remote access if an attacker is ever able to get their password. Combine this with the default and simple passwords in the first problem, and it becomes more and more likely that a compromise will occur.
Institutions should set a time limit (5 days, etc.) for MFA enrollment, and should disable the enrollment capability after that time period. If the user later needs to activate MFA, administrators can once again allow enrollment after confirming the identity of the user. This eliminates the risk of an older account being compromised due to an outdated unused MFA activation.
Recently, Russian actors have been observed hunting for and taking advantage of outdated MFA enrollments as an entry point to the network of an institution. To avoid being a victim, institutions should immediately review their MFA enrollment processes to determine if adjustments are needed. If you need assistance in performing this analysis, we can help! Send us an email at support@bedelsecurity.com.
Additional Resources
Multi-factor Authentication Threats Heat Up
https://www.bedelsecurity.com/blog/multi-factor-authentication-threats-heat-up
Breaking the SMS Habit
https://www.bedelsecurity.com/blog/breaking-the-sms-habit
Multifactor Authentication for Domain Admins: Start Preparing Now
https://www.bedelsecurity.com/blog/multifactor-authentication-for-domain-admins-start-preparing-now
Extending Security Controls Beyond the Office
https://www.bedelsecurity.com/blog/extending-security-controls-beyond-the-office
Remote Employee Access
https://www.bedelsecurity.com/blog/remote-employee-access
What is Credential Stuffing?
https://www.bedelsecurity.com/blog/what-is-credential-stuffing
Remote Work Security
https://www.bedelsecurity.com/blog/remote-work-security
Office 365: A Case for Multifactor Authentication
https://www.bedelsecurity.com/blog/office-365-a-case-for-multifactor-authentication