During adversarial attack simulations harvesting credentials through phishing are typically performed through cloned websites. A cloned website works by essentially copying the front-end (such as the Gmail login page) and hosting it on a domain designed to mimic the real domain (gmail.com vs. gmail.com-google.net).
Once the cloned website is created, an unsuspecting visitor will visit the login page and enter their credentials. The cloned site then records the victim user’s credentials and then displays a “Login Error” message making it appear as if the victim typed their password incorrectly. The cloned website then redirects the user victim to the real website’s login page.
While this method is often succeeds in its attempt to phish and steal the victim’s credentials, there are some issues that arise with this method. Cloned websites are sometimes easy to identify as fake and two-factor authentication (2FA) adds an additional element of difficulty requiring a real-time attack.
Sometimes the attacker is unable to make a perfect copy of the website that they are attempting to mimic or the attacker will try to introduce additional fields seeking more information beyond just a username and password, all of which raises suspicion.
In some instances, victim users are 100% certain they entered their credentials correctly and are therefore immediately suspicious when they can’t login to the cloned website. In a red teaming engagement, this can be a point where we can get caught.
In addition, if 2FA is enabled on a targeted account, then the username and password make up only two-thirds of what an attacker will need to successfully phish the victim user. If the victim user is using SMS or a Time-based One-Time Password (TOTP) like Authy, Google Authenticator, RSA token, etcetera for 2FA, then the attacker must somehow manage to capture their login credentials in real-time. If they don’t, then the attacker will have to craft another ploy to capture a token.