Social Engineering Past 2-Factor Authentication

by | Nov 13, 2013

Social engineering past two-factor authentification

Two-factor remote access can go a long way to make compromised network passwords less useful to an attacker; however, gaps in procedures and training can make even these robust security controls useless.  To illustrate, here’s a short story from one of my many pen tests earlier this year.


The Ask:

I was tasked with a phone call social engineering assessment for a client. In previous engagements, our typical phone calls attempt to:

  • Perform Password Resets – Calling the client’s helpdesk, impersonating a user and attempting to obtain a password reset.
  • Obtain Credentials – Calling a random sample of users and attempting to convince them to provide their network credentials.

This client was using two-factor authentication on their remote access VPN. Even if I was successful in initiating a network password reset, I would still be denied access by the two-factor authentication. To make matters more difficult, I was given a target’s name who had a very limited presence on social media networks such as Facebook, Twitter and LinkedIn;  however, I was able to obtain the user’s full name, job role, and where he previously worked. I did not have any personal information about the user (DOB, hometown, spouse’s name, etc…) or network username.


The Call:

I phoned the helpdesk and began the call by stating who I was, what department I was from, the fact that I was on the road, and that I was unable to login to the VPN. After going through simple troubleshooting steps, the agent asked me to verify that I was using the proper username. Since simple Google searches can reveal a company’s email address format, and the email and Windows user name format is often the same, I had a good guess. I told her I was using the first initial of my first name followed by my last name. The agent then corrected me by telling me the proper scheme which was: first, middle, and last name initials. I then told the agent that it was still not accepting the credentials, at that time she asked me to verify the username with the one in the system. The agent then supplied me the proper username to use for the account.

With the username obtained, I needed to obtain the second authentication piece; the password. Simply asking for a password reset prompted the helpdesk agent to read out a temporary password to me over the phone. Wow, that was easier than it should have been.  Now common wisdom would suggest that the username and password are useless without an RSA SecurID code.  But I was determined to try anyway.   I simply told the agent that my key fob was malfunctioning and hasn’t rotated digits in the past 4 hours. At this point, I expected to maybe be sent to an alternative single-factor login, or told that I need to return to the office or that a new key fob would be sent to me in the mail.  However, stating that my key fob was broken didn’t seem to faze the helpdesk agent, which led me to the discovery that within the RSA management console, there is the ability to grant a user an “emergency passcode.” The helpdesk agent was well aware of this function and proceeded to initiate it for my account. This allowed me to enter the agent supplied passcode into the PIN field, thus granting me full access the user’s Citrix environment.


What Went Wrong?

  1. Undocumented Password Reset Procedures: This attack was successful due to lack of standard help desk policies, including password resets and training for the helpdesk agent I spoke with. Initially, when I called the helpdesk I was never asked any qualifying or security questions to validate who I claimed to be. In my initial statements with the agent I only needed to provide a name of an employee and the department he worked for which was enough information for the agent to initiate the reset.
  2. Lack of Training: I continued to convey a state of urgency throughout the call which placed the help desk agent in a difficult position.  The agent should have been trained to be on alert for calls expressing urgency and requests for sensitive information.  Similarly, the Emergency Passcode should have required additional validation.  The emergency passcode functionality may be necessary for the RSA SecurID technology; however, it’s unlikely that all help desk agents need to be able to initiate it.  Note: RSA provides a warning notice for emergency passcode function use. It also happens to mentions that you should properly identify users before using this function.
  • Offline Emergency Passcodes.  Generate these only for users who have forgotten their PINs and need a full passcode.  In such cases, make sure you properly identify the users before providing them iwth emergency passcodes.  Becuase emergency passcodes enable authentication without a PIN, RSA recommends that you use emergency tokencodes instead.  ¹



Here are a few ways that you can help reduce the impact of these types of attacks:

  1. Document Help Desk Password Reset Procedures: Ensure that current help desk procedures around password resets and network access issues are documented and include ways to validate the identity of the caller. Below are examples of qualifiers that can be obtained from callers  to help identify them as legitimate employees:• Employee ID
    • Phone extension
    • Cube / Office number
    • Employee supervisor (In combination with another method)
    • Unique employee attributes (Common Security Questions)
    – Spouses maiden name
    – Favorite restaurant in college
    – First pet’s name
    – First carA stronger control would be to initiate a call-back or SMS message verification with the caller.
  2. Training: Provide training for help desk personnel around password reset procedures. This training should be mandatory for all new help desk employees and required to be revisited every year.
  3. Use of Emergency Code: Limit the number of help desk agents who have the ability to initiate emergency passcodes. Only the most senior and trained help desk agents should be trusted with this functionality.  In addition, require additional employee identifiers and/or qualifying questions before giving out the code.


By: Dan Astor (#SweetAction)

1 RSA Authentication Manager 8.0 Administrator’s Guide, 2013, Pg. 87.

Dan Astor
Principal Scientist | Archive

Dan specializes in network penetration testing, adversary simulation, and red team operations. Dan is a member and lead of SRA’s R&I team, which researches and develops tools, techniques, and public content.

Dan has worked for clients in several industries including banking, entertainment & media, insurance, healthcare, pharmaceutical, manufacturing, and utilities.

Dan regularly contributes to open source tooling and blog posts. He has also obtained his Offensive Security Certified Professional (OSCP) certification.