Social Hacking of Support and Implementation Teams

Support, customer service and implementation teams are the human gateways into many systems. Because they are human, with regular access to some of the most sensitive information for a business, they pose a special security risk from two kinds of behaviour: malicious behaviours, intended to exploit the system in some way, and innocent behaviours, which place the system at risk as a by-product, rather than a goal. In this article, we will focus on malicious behaviours and how to defend against them.

Social Engineering Customer Facing and Operations Teams

The dangers of malicious behaviour initiated purposely by an employee of customer facing and operations teams are obvious – but they are not unique to them. It is the high risk of being tricked into these behaviours by a second party – social engineering hacks – that makes these teams a special security weak point, as they have more direct contact with users than members of any other team and so present tempting targets. They also expect to be contacted by strangers, whereas other teams may become suspicious as soon as they are approached and be on guard for every unexpected interaction. So while general engineering techniques such as fake surveys can be used against all teams, user-targeting hacks - an attempt to hack a single user's account - are most likely to utilize these customer facing teams.

Social engineering takes advantage of support and implementation employees to hack user accounts without investing in it technologically. Sometimes, hackers take advantage of errors in the rules that these teams are following; sometimes the rules are correct, but team members bend them out of a desire to help or through being manipulated and talked or pressured into a mistake.

Why the Rules Do Not Always Protect You

As an example of rules failing,Scott Hanselman's hacker got Amazon to send Mr Hanselman a new Kindle, and then changed the shipping address away from Mr Hanselman. The address change should not have been possible and was refused several times, but the hacker called again and again until he found a representative more eager to help than to follow the rules. Mr Hanselman also notes that the hacker was not asked to log onto Amazon to prove he had access to the account, nor did some of his suspicious requests – such as trying to eliminate a paper trail – raise a red flag.

Sometimes, the problem isn't with one company's rules or behaviours, so much as with the way that different companies reveal or request different information. Contradictory rules were at the base of the Mat Honan and Gizmodo hack from 2012, one of the best known examples of this sort of hacking. As Mr Honan puts it, "the very four digits that Amazon considers unimportant enough to display in the clear on the web are precisely the same ones that Apple considers secure enough to perform identity verification." His hacker used two companies' by-the-book actions to gain access to two accounts, based on the differences in what these companies considered private and hard-to-get information.

Both of these hackers used some information they had about their victim, and a lot of information about which rules can be exploited and which can be overcome with enough effort. That is the essence of social engineering.

How Implementation Teams can Be Socially Engineered

You might think that implementation, as it is on-site and often face-to-face with users, cannot be exploited by social engineering as it relies on impersonating a stranger. But since implementation workers are often away from the office and moving between different sites, it can be quite easy for a hacker to pretend to be not an anonymous user but a fellow-employee, or an employee of the client, who has simply not met the implementation worker before. Using supposed familiarity can help the hacker lower the implementation worker's defences. Additionally, real employees that are well known to implementation teams may gain access to information they should not be able to see, and then pass it on for profit.

Defending Against Social Engineering Attacks

So we can see that avoiding social engineering hacks requires two things: correct rules, and a willingness to follow them even when the user sounds distressed or simply very innocent and convincing, and especially when the user is known to the customer facing teams.

What forms a "correct" rule, or set of rules? At its base, exploitation of employees uses the inherent difficulty of verifying a person's right to access information. The two sides of the equation, then, are the identity of the person and the information supplied to that person. A correct set of rules would seek to reveal as little information as possible, in exchange for as much identifying information as feasible. Keep three assumptions in mind at all times: you cannot really predict what hackers may find beneficial in the information your employees disclose; no single piece of identifying information is proof of identity; and some of the things you consider to be separate pieces of identity are all discoverable from a single source.

But the rules, as we said, are not enough. Employees must also stick to the rules despite the pressures or apparent distress of the user. And most of all, employees should use their common sense and pay attention to suspicious behaviour. If they flag a user, they may be able to prevent that user taking advantage of a fellow employee. In Mr Hanselman's case, it took the hacker several tries to change the shipping address on the order. Any one of those tries could have flagged the hacker as behaving suspiciously, and a string of these flags should have stopped the shipment. Similarly, in Mr Honan's case, the hacker made two calls – one to supply a new credit card number, one to use that number to verify his identity and so gain access to the account. Paying attention to this string of calls could have prevented the hack.

Employees should also feel confident that if they stick to the rules, they will receive backing from their bosses even if the user is not a hacker and complains about the lack of assistance. And, if you are measuring your employees by how many calls they handle, you should be aware that the time pressure makes it more likely that they will make mistakes such as give the hacker hints about security questions, reveal too much information before verifying identity and agree to perform actions that break the rules.

Summary

This post provided only a glimpse of social engineering. There are multiple techniques for this form of hacking, and multiple goals, from hacking your company to hacking your users' accounts. Defending against all of them is difficult, but educating yourself and your support, customer service and implementation teams about social engineering – especially the need to be critical and on guard – is a good place to start.