Social Engineering and Two-Factor Authentication
Social engineering campaigns are a constant threat to businesses because they target the weakest chain in security: people. A typical attack would capture a victim’s username and password and store it for an attacker to reuse later. Two-Factor Authentication (2FA) or Multi-Factor Authentication (MFA) is commonly seen as a solution to these threats.
2FA adds an extra layer of authentication on top of the typical username and password. Two common 2FA implementations are one-time passwords and push notifications. One-time passwords are generated by a secondary device, such as a hard token, and tied to a specific user. These passwords typically expire within 30 to 60 seconds and cannot be reused. Push notifications involve sending a prompt to a user’s mobile device and requiring the user to confirm their login attempt. Both of these implementations protect users from traditional phishing campaigns that only capture username and password combinations.
While 2FA has been strongly recommended by security professionals for both personal and commercial applications, it is not an infallible solution. 2FA implementations have been successfully defeated using real-time phishing techniques. These phishing attacks involve interaction between the attacker and victims in real time.
A simple example would be a phishing website that prompts a user for their one-time password in addition to their username and password. Once a user completes authentication on the phishing website, they are presented with a generic “Login Successful” page and the one-time password remains unused but captured. At this point, the attacker has a brief window of time to reuse the victim’s credentials before expiration.
Social engineering campaigns utilizing these techniques are not new. There have been reports of real-time phishing in the wild as early as 2010. However, these types of attacks have been largely ignored due to the perceived difficulty of launching such attacks. This article aims to change that perception, bring awareness to the problem, and incite new solutions.
Explanation of Tool
To improve social engineering assessments, we developed a tool – named ReelPhish – that simplifies the real-time phishing technique. The primary component of the phishing tool is designed to be run on the attacker’s system. It consists of a Python script that listens for data from the attacker’s phishing site and drives a locally installed web browser using the Selenium framework. The tool is able to control the attacker’s web browser by navigating to specified web pages, interacting with HTML objects, and scraping content.
The secondary component of ReelPhish resides on the phishing site itself. Code embedded in the phishing site sends data, such as the captured username and password, to the phishing tool running on the attacker’s machine. Once the phishing tool receives information, it uses Selenium to launch a browser and authenticate to the legitimate website. All communication between the phishing web server and the attacker’s system is performed over an encrypted SSH tunnel.
Victims are tracked via session tokens, which are included in all communications between the phishing site and ReelPhish. This token allows the phishing tool to maintain states for authentication workflows that involve multiple pages with unique challenges. Because the phishing tool is state-aware, it is able to send information from the victim to the legitimate web authentication portal and vice versa.
To facilitate our real-time phishing tool, we embed server-side code on the phishing site that communicates with the tool running on the attacker machine. We also set up a SSH tunnel to the phishing server. When the authentication form on the phishing site is submitted, all submitted credentials are sent over the tunnel to the tool on the attacker’s system. The tool then starts a new web browser instance on the attacker’s system and submits credentials on the real VPN portal. Figure 1 shows this process in action.
Figure 1: ReelPhish Flow Diagram
We have seen numerous variations of two-factor authentication on VPN portals. In some instances, a token is passed in a “secondary password” field of the authentication form itself. In other cases, the user must respond to a push request on a mobile phone. A user is likely to accept an incoming push request after submitting credentials if the phishing site behaved identically to the real site.
In some situations, we have had to develop more advanced phishing sites that can handle multiple authentication pages and also pass information back and forth between the phishing web server and the tool running on the attacking machine. Our script is capable of handling these scenarios by tracking a victim’s session on the phishing site and associating it with a particular web browser instance running on the attacker’s system. Figure 1 shows a general overview of how our tool would function within an attack scenario.
We are publicly releasing the tool on the FireEye GitHub Repository. Feedback, pull requests, and issues can also be submitted to the Git repository.
Do not abandon 2FA; it is not a perfect solution, but it does add a layer of security. 2FA is a security mechanism that may fail like any other, and organizations must be prepared to mitigate the impact of such a failure.
Configure all services protected by 2FA to minimize attacker impact if the attacker successfully bypasses the 2FA protections. Lowering maximum session duration will limit how much time an attacker has to compromise assets. Enforcing a maximum of one concurrent session per user account will prevent attackers from being active at the same time as the victim. If the service in question is a VPN, implement strict network segmentation. VPN users should only be able to access the resources necessary for their respective roles and responsibilities. Lastly, educate users to recognize, avoid, and report social engineering attempts.
By releasing ReelPhish, we at Mandiant hope to highlight the need for multiple layers of security and discourage the reliance on any single security mechanism. This tool is meant to aid security professionals in performing a thorough penetration test from beginning to end.
During our Red Team engagements at Mandiant, getting into an organization’s internal network is only the first step. The tool introduced here aids in the success of this first step. However, the overall success of the engagement varies widely based on the target’s internal security measures. Always work to assess and improve your security posture as a whole. Mandiant provides a variety of services that can assist all types of organizations in both of these activities.
This article was originally published here.