With the appeal of password-less login methods being observed by an increasing number of Internet users, and single-sign-on integration through federated Google and Meta accounts becoming a daily fact of life for most online services, many service providers such as Microsoft Azure are beginning to allow self-service password recovery (SSPR) methods that are tied to multi-factor authentication via SMS PIN, apps like Mircrosoft Authenticator, or a hardware MFA token. Instead of needing to remember a password at each login, an end-user requests a password reset, enters their authenticator app PIN or approves a push-prompt notification to their mobile device, then sets a new password. This can be quite helpful for users regularly tasked with setting unique passwords to a large selection of accounts but remaining averse to the use of a password manager service like LastPass, or those who simply haven’t signed into an account in some time and experience difficulty remembering passwords or answering security questions. The convenience afforded by this sort of authentication has also extended to a related concept where many services no longer explicitly require a password to be entered on the login page and instead offer to send a “one-time” sign-in PIN to the email address associated with the user account.
This is also unfortunately a welcome change for threat actors involved in phishing or account takeover attacks. Consider some of the implications of this sort of authentication:
– “Brute force” attacks to obtain passwords, or even needing to collect a password in the course of a phishing attempt is no longer necessary. A threat actor can instead social-engineer an end user into providing a PIN via contact outside of the e-mail address or service associated with the account. For example, threat actor Alice knows that Bob owns an Betacorp account (bob@betacorp.com) and is reachable via cellphone at 555-1212, but Bob knows he should never provide his password to others. Alice poses as a Betacorp IT employee, sends a SMS message to Bob’s phone number claiming an issue with the account, and asks him to approve an MFA prompt for troubleshooting, to which Bob agrees (believing that a password is still required for his account to be hacked). Alice initiates a password reset, Bob approves the request, then Alice locks Bob out of his account. This contradicts the concept of “multi-factor authentication” as we understand it – though a password and MFA method were both configured on Bob’s account, only one authentication method was used by Alice to gain access.
– This concept also allows threat actors a unique method to stealthily maintain persistence on the account. Once Alice gains access to Bob’s account, she then configures an additional MFA recovery method of her own. This means that even if Bob is able to regain access to his account with the assistance of Betacorp’s IT team, Alice may also later re-compromise the account by initiating a self-service password reset using the recently-configured recovery method if it isn’t removed in the process of account remediation.
This is sadly not a theoretical example: infosec is now rife with cases of actors breaching a MFA-protected user account through methods such as Attacker-in-The-Middle (AiTM) phishing, or social-engineering MFA push approvals and PIN codes from end-users, then associating these accounts with additional MFA recovery methods controlled by the threat actor.
We should also consider the impact of these events on illicit “access brokers” who collect and resell access to phished accounts, often in bulk. In the past, a set of phished accounts would quickly lose value as the victims gradually regain access and set new passwords, or the accounts are disabled by their providers, requiring periodic “re-validation” by brokers. This may no longer be the case, as a threat actor or broker can provide a bulk set of accounts and a corresponding MFA method (for example, an Authenticator app running in a cloud VM), meaning a set of accounts may retain their value for long past the traditionally-accepted time frame. Brokers or the threat actors purchasing access need no longer worry if the accounts are MFA-protected by the end users, or if the password was changed or had expired since the original breach occurred – regaining access is as easy as initiating a self-service password reset. Phishing becomes an even-more valuable profession for budding cyber-criminals, as does access brokerage, meaning more skilled individuals will be drawn toward these practices.
So what does this mean for me, the security analyst/help desk technician/phished employee/casual observer looking to spread best practices?
– Regular review and maintenance of MFA methods has become more important. If you suspect your account was accessed by a malicious party, take a moment to review the MFA devices associated with your account and remove any unusual or unnecessary entries. Regular check-ups of your accounts are also key. Any unused accounts should be disabled or deleted entirely.
– If you’re a security team member or help desk technician, respond to account breaches by resetting the account’s password, ending all sign-in sessions, and either remove all MFA methods altogether (while requiring re-registration) or verify that none were added in the process of compromise. Outside of this scenario, use general help-desk support calls as an opportunity to have end-users check up on their MFA methods and ensure any unfamiliar or unused entries are removed. This measure may best be instituted as an optional step at the beginning of the call when verifying a caller’s identity.
– Security analysts should also regularly query their environment for unusual MFA registrations and develop analytic rules and alerts to detect this sort of activity. For example, a single authenticator device or phone number (SMS) being configured for a selection of unrelated accounts (particularly within a short time span) may be a sign of an active phishing campaign and should be investigated accordingly.
– Security architects and administrators might also wish to use controls to detect abnormal or risky sign-in patterns and restrict access via risky means. For instance, there are controls in Azure that can limit MFA re-configuration attempts outside of accepted geolocations, or disallow a password reset if the account suddenly exhibits a pattern of risky sign-in attempts. MFA push prompts can be enriched by providing the location from which the prompt was initiated, helping end-users spot malicious prompts (though the threat actor may also be able to determine the location expected by their potential victim and tailor their attempts accordingly).
– If your account allows one-time login via a code or link sent to the email address associated with the account, ensure that the corresponding e-mail account is similarly secured with MFA and that regular attention is given to both the password and MFA methods configured for it.
Though these are no doubt developments toward which the security community should be concerned, line-of-business activity needs to continue, the world keeps turning, and the benefits of convenience will always be in demand by your user base. Recognizing these situational changes and addressing them proactively will limit the impact of the countless creative-and-skilled threat actors active on the public Internet and keep your institution running as smoothly and securely as possible.
