help-desk-social-engineeringWhy Help Desks are becoming a big target for social engineering and what you can do about it.

Help desk. What is the help desk team around for?

Helping people, right? That’s exactly why help desks have become a focus for social engineering campaigns.

Think about it for a minute. What KPIs do you use to measure a successful help desk worker?

I’m sure you have a set of metrics they report daily, weekly, or monthly to their manager. Typically, you’re talking about some amount of time spent on resolving issues, the number of issues resolved, maybe some metric on documentation, and finally, some metric on user satisfaction. Overall, these are the high-level types of metrics a help desk team would be focused on.

As a team, they are interested in getting issues resolved quickly and resolved in a manner that the user appreciates.

Each person on your help desk team is probably focused on getting through tickets. They might be slightly competitive. Who can close the most tickets that day, week, or hour? When I was running my MSP, we would often have little contests to get the team motivated to get tickets cleaned off the boards. We sometimes would give away a 4K TV, or maybe some killer concert tickets. The winner would largely claim his or her prize because they were able to close more over the course of their shift.

Back in the day when MSPs weren’t a huge target for attacks, our little contests came with no risks. We never warned our team members about being phished or manipulated.

Now, as attackers are focused on MSPs as part of the IT supply chain, we need to be aware of how they’re using social engineering to break through your help desk.

Tier 1 support teams are trained to be friendly, resolve caller’s issues and get the issues handed off quickly. They may overlook verifying a caller’s identity simply because they are mainly interested in pleasing the user on the other end of the phone. Their goal isn’t to slow the process down. They want to end calls with issues resolved. Whether for a password reset or logon issue, or whatever problem at hand, your Tier 1 team is missioned to get things fixed.

How can you start getting your team to think about social engineering as a threat targeting them?

While a lot of MSPs set in stone policies that all team members must follow, I find that simply having policies written down in a handbook are often missed or ignored. Do I think well-written policies are important? Absolutely, but I think you’ll want to get a bit more creative with how you get your teams to understand why validating information is critical to their job.

You might start by telling periodic stories of how attackers glean information (sensitive information) from help desks. And focus on how specific verification methods—say, verifying a person by calling a published phone number, contacting a trusted contact at a client company, or verifying some additional employee information.

Consider incorporating user verification into your team’s routine, rather than making it an exception for specific cases. This will help form on-going habits rather than forgettable protocols. Have your teams verify users each time they call in or submit requests.

For callers, come up with some simple steps everyone on your help desk can remember. For emailed requests, make sure your team contacts the specific users from known published phone numbers and email addresses.

Be clear on what types of sensitive information can be shared via emailed tickets vs information your team might only be able to share over the phone while talking to a trusted source. What types of information can your team share? Have you discussed this with each help desk team member? Or are you assuming they have “common sense”?

The biggest problem to think about when addressing social engineering and help desks in my humble opinion is getting through to your team that this problem could very well affect them.

As technicians or engineers, we all would like to think that we’re above social engineering. The problem is attackers are taking advantage of us when we’re most vulnerable. When we want to do a good job and are trying to help frustrated users that really don’t want to be calling in to the help desk in the first place.

You don’t have to be that downtrodden and serious when discussing security with your team. Yes, you probably don’t want to turn security into a joke, but it doesn’t have to always be doom and gloom.

To get the ball rolling, here’s some quick information on the 10 most popular names within MSPs compiled from our databases:

  1. David
  2. Jason
  3. Matt
  4. Michael
  5. Jeff
  6. Mike
  7. Steve
  8. John
  9. Chris
  10. Brian

Get your team to think about that for a minute. Might an attacker try to assume an alias with one of these names to fit in? Maybe, or maybe not. What I want you to start getting your team to think about is how to think like a hacker. If they were seriously trying to call into to your help desk and get through, what would be the easiest ways to do so? What would be the easiest ask? And then what might they do next?

If your team starts to think about scenarios (maybe even a tabletop exercise around help desk breaches), they’ll probably gain valuable security experience without having to go through the pains of actually falling for an attack.