Attacks that Smish, Phish, and Vish Their Way around MFA

Multi-factor authentication and Smishing/Phishing Attacks

Multi-factor authentication (“MFA”) is widely considered to be a best practice and one of the most effective cyber security protections, both for consumer accounts and for corporations. While MFA certainly adds a layer of protection and is a particularly valuable defense against account takeover attacks, cyber criminals are continuing to develop new attack vectors to bypass MFA and reduce its effectiveness. These new attack vectors can take different forms, such as SIM swapping,¹ bribing corporate insiders, or socially engineering corporate employees through smishing, phishing, and vishing to enter their credentials into attacker-controlled sites that have been made to look like the normal corporate logon domain. This article focuses mostly on the latter—which for convenience we’ll call Smishing/Phishing Attacks—which have been the subject of news reports in the past year.²

These Smishing/Phishing Attacks present challenges for even the most experienced Chief Information Security Officer (“CISO”): How do you secure your environment from password-based attacks if a Threat Actor (“TA”) can bypass MFA? How do you detect an attack, especially where the social engineering may occur on an employee’s personal phone? And how do you detect and respond to an attack where it can be difficult to distinguish between TA activity and activities of the legitimate user?

Stroz Friedberg, an Aon Company has served as the retained incident responder for multiple companies that were victims of these attacks. This experience has given us unique insight into the anatomy of a Smishing/Phishing Attack, what companies have done successfully to identify, stop, and contain these attacks, and enhancements that can be implemented to prevent a future MFA-based attack.

Anatomy of a Smishing/Phishing Attack

Based on what we observed, Smishing/Phishing Attacks typically proceed as follows: The TA sends smishing text messages or phishing emails to the target company’s employees, often to personal devices. The messages include links to a fake, attacker-controlled website that mimics the company’s actual login page. For example, if the company is using the third-party authentication provider Okta, the fake domain might be something like www.company-okta.com instead of www.company.okta.com. Given the realistic nature of the websites and the number of employees who receive messages, it is likely that at least some employees will click on the link and enter their credentials. After entering their credentials into the fraudulent site, the TA forwards the credentials to the legitimate site, usually through automation. The employee will then receive a one-time password (“OTP”) either via SMS or from within their authenticator application. The fraudulent site will prompt the employee to enter that OTP, which the TA will then forward to the legitimate site, thereby gaining control of the employee’s account. If the user has push notifications enabled, then the user might accept the push notification instead of entering an OTP. The acceptance of the push notification will similarly result in an employee account takeover. Once the TA controls the employee’s account, the TA can then gain access to all applications integrated with the company’s single sign-on (“SSO”) portal, which frequently includes commercial applications like Salesforce, Workday, Slack, Jira, and Confluence, in addition to company-specific proprietary apps.

The team responded to an even more sophisticated version of this attack in which the TA gained access to the company’s firewall by exploiting a zero-day vulnerability. The TA then changed the SSO website address in the company’s firewall configuration to redirect employees from the legitimate SSO website to a fraudulent website with a nearly identical interface and URL. Instead of using smishing as an initial attack vector, this TA changed the legitimate SSO login page, so employees were less likely to suspect any suspicious activity.

These Smishing/Phishing Attacks allow the TA to take over employees’ accounts in a way that organically evades protection tools. The initial attack—the smishing messages—are sent to personal phones into which the company lacks access absent a mobile device management solution. Once in the system, the TA controls an actual account and can gather valuable information and data without needing to deploy any malware, run malicious scripts, or take other actions that are likely to trigger alerts on the victim company’s antivirus or endpoint detection and response tools.  Similarly, since the attacker, logged on as the user, is only accessing services to which the user has normal access, the attacker’s browsing is unlikely to be flagged as anomalous by analytics tools that track user behavior.

From the perspective of an incident responder, these factors make a Smishing/Phishing Attack more difficult to investigate. For one, without an MDM solution in place, the company cannot block or monitor access to the fraudulent site. Incident responders must instead rely on SSO authentication logs to determine which users entered credentials into the fraudulent site, so detection can only occur after successful authentication by the TA. Second, each individual application that is accessed must be reviewed. This is difficult to do at scale because most organizations do not have centralized SSO application logging, and each application may have different log retention periods, which makes preservation of evidence more critical to understanding the incident scope and more difficult to achieve. While we have not seen this attack vector lead to ransomware or data extortion, these attacks can be highly disruptive to business operations and negatively impact customer trust (and we see no technical reason why a ransomware group or data extortionist could not leverage such an attack in the future to exfiltrate a company’s data and demand a ransom payment).

Recommendations

These Smishing/Phishing Attacks are sophisticated and fast. Unlike an APT or large-scale ransomware attack where the TA might sit in the system for weeks or months, the TA must move in and out of compromised accounts quickly and act while compromised credentials are still working. As noted earlier, the nature of the attacks makes them difficult to detect and contain. In responding to these types of attacks, we identified certain controls and practices that may help companies prevent, detect, and respond to Smishing/Phishing Attacks³:

• • FIDO2 Authentication: Potentially the most effective way to stop an MFA attack, FIDO2 authentication uses asymmetric encryption (public/private key authentication model) that incorporates the domain name or application ID of the site or application to which a user is authenticating, among other data points, when sending an authentication request. With this authentication security model, even if an employee enters his or her credentials into a fraudulent site, the authentication request would not be successful because the request is validated using the domain name or application ID, with which the FIDO2 device is interacting with, as part of the key. Therefore, a FIDO2 login attempt to a phishing site cannot be replayed on the legitimate site because the legitimate site will not recognize the authentication request. While some companies, particularly in the tech industry, have begun using FIDO2 authentication on a widespread basis, other companies may prefer to use such advanced authentication only for a select group of users with access to highly sensitive information, such as software developers.
  • Biometric Authentication (Non-FIDO2): A less viable alternative to FIDO2 Authentication is biometric authentication. While biometrics can provide an alternative to passwords or be used as a second factor, requiring corporate employees to use face or fingerprint identification, for example, may run afoul of corporate culture and may present privacy concerns that FIDO2 authentication does not. Biometric authentication is also more difficult and costlier to implement, so is not likely to become a widespread alternative form of authentication at the enterprise level.⁴
  • Monitoring of New Devices: Organizations can configure identity-related software to receive alerts whenever a new device (i.e., a workstation or mobile phone) is added to an employee’s account. In the attacks the team has investigated, the attackers sometimes add their own device to the impacted SSO account, and the addition of a new device to an Okta or Duo account may suggest anomalous activity.
  • Monitoring of User Agents: If an organization has particular, unique identifiers in employee user agents, it can monitor for anomalous user agents as a potential sign of malicious activity. In one matter we investigated, the client’s employees worked almost exclusively on Mac devices, but the TA used a Windows machine, which could have been alerted upon.
  • Mobile Device Management: Issuing company phones with MDM software pre-installed or requiring MDM software on employees’ phones can help an organization block, detect, and respond to smishing messages sent to those devices.
  • Proactive monitoring of domains containing the company name. Fake corporate logon pages normally have the company’s name in their domain name. Monitoring for the registration of any URL that contains the company’s name can provide early detection.
  • Shortening Session Length: A TA’s access to a victim’s network only lasts as long as the session length allowed by the company. We have seen session lengths for certain applications last as long as 45 days, giving the TA a large window in which to maintain persistent access once logged in. Reducing session lengths to shorter time periods will limit the TA’s access.  Should an organization identify a compromised user in this type of attack, it should reset session tokens and passwords across the enterprise.
  • Least Privilege Access: Enforcing least privileged access is good security hygiene generally, and it’s a particularly important way to protect data against unauthorized access after a Phishing/Smishing Attack.
  • DNS-Based Analytics: Several software products are available to block or alert on suspicious or know-bad URLs. Even though the fake login page domains are normally registered right before the attack, at least one DNS-based IDS product pulls non-public metadata from the registrars that can potentially link the new URL to known-bad actors.
  • Centralized Logging: Following a compromise, the priority for the incident response team is to identify the scope of the impact—specifically which SSO applications the TA accessed and what actions the TA took within each application. The starting place for the IR should be authentication logs for the organization’s SSO provider (e.g., Okta or Duo) for any known compromised accounts, in order to identify the apps the user accessed during the period of potential compromise. The investigation will then focus on the logs for the apps the TA may have accessed, so the analysis could involve dozens of logs sources. If these logs are not stored in a centralized location (or not stored by the company at all and only in the possession of the third-party application provider), identifying the scope of the compromise will be much more laborious and difficult.
  • Authentications from Known Proxies: During an incident, TAs will commonly use anonymous infrastructure to prevent attribution.  Monitoring and alerting on authentications from known proxies, especially proxies that are not used by the organization, can be a high-fidelity indicator of malicious activity. The authentication logs of certain identity access and management platforms will specify if an authentication request came from a known proxy.

Contributors:

Brian Lichter, Andre Maccarone, & Eric Friedberg⁵

Sources:

¹ SIM swapping occurs when the attacker socially-engineers a cell phone owner’s telecom provider to move the employee’s cell phone number to an attacker-controlled mobile phone so that one-time passwords will be sent to the attacker instead of the legitimate owner.  Of course, to authenticate to an online account, the attacker must also have some other means to obtain the owner’s account username and password.

² According to its security blog, Cloudflare was the target of such an attack in August 2022,  https://blog.cloudflare.com/2022-07-sms-phishing-attacks/, and Okta also published a post about this attack vector on its security blog, https://sec.okta.com/scatterswine.  Examples of news articles include https://www.theregister.com/2022/08/25/twilio_cloudflare_oktapus_phishing/ and https://www.pcmag.com/news/hackers-behind-twilio-breach-targeted-over-130-organizations.

³ FIDO2 and biometric authentication should prevent SIM swapping and even some cases of bribery to obtain credentials.  SIM swapping can also be prevented by using an authentication app rather than an SMS OTP as the second factor and educating users that they may be the victim of SIM swapping if their phone ceases to function.  User education is also a key defense against SIM-swapping, as users must spring into action if and when they notice that their mobile phones do not function.

⁴ Certain forms of biometric authentication, such as Apple’s Face ID, are FIDO2 compliant.  While FIDO2-compliant forms of biometric authentication are widely used at the personal level, they are less likely in their current form to be widely adopted at the enterprise level for the reasons noted above.

⁵ Brian Lichter is a Vice President of Engagement Management with Stroz Friedberg, LLC, an Aon company.  Andre Maccarone is a Manager in Stroz Friedberg’s Digital Forensics & Incident Response practice.  Eric Friedberg helped to found Stroz Friedberg in 2000 and until his retirement at the end of 2022, served as the company’s Co-President.