One of the most common assignments I've seen handed off to junior personal within a penetration testing team, with minimal training, is voice phishing, or vishing (hate the word all you want, I'm still going to use it). Vishing, in a nutshell, is calling someone and pretending to be someone you're not, while convincing them to do something they shouldn't. In recent news, this was done by the MGM and Caesars forum hackers. This is a real world tactic that can lead to all sorts of mayhem, so I think it's a mistake not to provide adequate training to junior personnel on the topic. Hopefully this post will help a few. I'm not going to cover every technique, or even very many techniques here. But I would like to explain a couple of tactics that made some of the calls on a recent engagement successful.

For obvious reasons, names of products, vendors, and employees specific to the organization have been changed. Also, don't try and use this outside of a legally sourced security assessment, I'm not going to endorse you using this to try and become the next APT in the news.

Preparation

To get started, you need to answer some questions. What do you know about your client? Who are you calling? Who are you pretending to be? What are you trying to get out of this?

This particular engagement was for a higher ed institution, I was trying to get user credentials, and I was impersonating help desk personnel. For obvious reasons, I won't disclose who the institution was. But higher ed often provides a way to contact any and every faculty member you could think of through a publicly available staff directory. Go ahead and think of 5 colleges or universities. If I was a betting man, I'd bet that at least 4 of the 5 have a staff directory with at least names, department, title, emails, and phone numbers.

Let me make this clear: this information does not need to be available to the general public. This is typically my first finding for this portion of a vishing engagement for higher ed. My remediation recommendation? Provide department phone numbers (not individual profiles), and route calls as needed. Lock everything else behind Single Sign-On (SSO) for faculty. Set up a separate directory for current students, also protected by SSO. Pay attention to your SSO implementation, and be sure it's not trivially bypassed. A couple months ago, I found an entirely different organization protecting a page with SSO. However, by intercepting the HTTP response to to the GET request, and modifying the "302 Found" header to "200 OK" and replacing the "Location:" header contents with the location referenced in a previous request, I could still see the "protected" page.

Armed with a staff directory, you have plenty of targets, and usually help desk employee numbers. You could even spoof the help desk department number. I won't go into spoofing in detail, just know that you could use a service like Spoofcard, or you could build your own rig: https://kaos-tech.ghost.io/crosspost/

If you're having trouble finding the help desk info in their web page, just google the university name followed by "help desk". You can also use a google dork: site:targetdom.tld "Help Desk". This particular institution had a help desk page that listed every employee and their numbers.

Adjustments

With this engagement, I started off by identifying myself, I was posing as a fictitious employee from the help desk. Sometimes the organization is large enough that this works, not everyone knows everyone. This particular institution had a fair amount of employees, so I started here. However, the pretext (scenario created for the vishing campaign) , combined with this unknown person, did not sit well with my first couple of calls. Herein lies my first piece of advice for you, the reader. Don't be afraid to make adjustments to your plan. Most of social engineering actually requires you to make adjustments. If you're stuck in your own head with the scenario you've created, things get awkward, fast.

From here, I chose to impersonate a lower level help desk technician. Unfortunately, my next target replied with the following: "You were just here!". I tried to salvage the situation with: "Right, and now I'm at my desk". They didn't buy it, and hung up on me.

Figuring the previous name was burned, I picked another real employee to impersonate. This is where things got fun.

Technology and Red Flags

My first call as this next employee yielded valid credentials. This is where I introduced my first non-technical technique. I immediately went into the ruse. I greeted the person on the other line, but didn't identify myself. After explaining the situation, this target asked who this was and apologized. She explained that her phone must be acting up, because the caller ID didn't show correctly. At this point, I gave her the first name of the employee I was impersonating, and then quickly re-iterated with the first AND last name. She apologized some more and again explained that her phone had been acting up, but also that my voice didn't sound right. I apologized and said "huh, that's weird". But she still gave up her credentials.

This was my next finding for the client, train employees to pay attention to things like an incorrect caller ID or differences in voice. Listen to their gut. This is less science, but a little intuition intervention would have gone a long way. This organization needs to train employees to verify suspicious activity somewhere out-of-band, such as a Teams message or an email. Even hanging up and calling back the same number shown on her phone would have outed me, since I had no way to intercept calls.

Tying back to adjustments, I went and added caller ID information to additional areas in Incredible PBX, verified in the asterisk database, set the caller ID in Zoiper, checked Skyetel documentation, analyzed a packet capture of a call, and verified that I was doing everything I could to ensure my outbound caller ID should show correctly. Ultimately, I worked with my contact to see what happened with a set of calls and found that their systems were switching back and forth between the employee I was impersonating, and a generic organization caller ID.

Name Dropping

For the next several calls, I again made some adjustments. I changed how I talked about my ruse, to incorporate some names of other help desk employees and known vendors in order to build some rapport prior to the "big ask" (having the target enter their username and password into an unfamiliar web page). Here's what part of this conversation looked like: "Oh, that's weird, you're the 2nd person to tell me about a caller ID issue. I've got a ticket in with Mitel." "Yeah, Claire wants us finished testing this by end of day so we can make any fixes and send a mass email on Monday. If you have any suggestions for the FAQ at the bottom, I'll try not to let Ben take it too hard, that was his portion of the project."

Name dropping can make it seem like you really do belong. Overdoing it however can sound suspicious. Find a good middle-ground for the amount of detail you provide. Don't squeeze all 10 names from the department into a single call.

Using Banter to Your Advantage

I like to start off calls by asking "Hey ___, how are you doing?" This phrase, accompanied by the correct tone of voice, creates a sense of familiarity and friendliness that will often get you what you want. It may even have the target wondering if they forgot to look at the caller ID or second guessing themselves in other ways. When they inevitably respond with "Good, how are you?" or some slight variation, throw in some banter: "Oh not too bad, just trying to close out a couple of projects before lunch" or "I'm alright, hoping to get out a little early and get a headstart on the weekend!". This type of commentary can really open up the conversation. More often than not, adding banter to the conversation has had targets warm up to me, and they forget to even ask who they're speaking with. They might even ignore the fact that the voice on the other line doesn't quite sound like Tim in IT.

Talk About Security

This kind of goes with the whole banter piece. But part of the success I had with this engagement was due in part to my mentions of security. Little things like: "Don't worry, we'll never see your password. The site doesn't store it anywhere.", "I'm not going to ask your for your password directly", or even "I know, this is contrary to all of the security awareness training we put you all through". Why would someone doing something bad even want you to think about security? Well, I want you to trust the instructions I'm giving you. One target mentioned how "this feels so wrong", but still gave up their credentials after I threw in "I know, I'm sorry, it's almost like the exact scenarios we talk about" followed by a bit of laughter.

Closing

Hopefully you gained some useful techniques to add to your next vishing engagement. Again, this wasn't meant to cover every trick in the book, but I wanted to highlight a few key areas that were fresh on my mind. Thanks for reading!