Social Engineering Technique – The Shell Game

When discussing social engineering techniques, the danger of an insider threat cannot be underestimated. The shell game technique is a subtle form of social engineering most frequently used by individuals with control over key documentation and specific collections of data. It is one of many techniques used by people who maliciously hack systems from the inside.

Establishing Trust

The trust that must be established for this technique to work is twofold, the malicious actor (hacker) must have: 1) a job title or role that provides access to the collection of data being manipulated and 2) an established reputation for being the go-to or definitive source for questions about (or access to) the data being manipulated.

For the purposes of this article, I will use the following scenario: An Information Security Manager involved in the IT Security Policy decision making processes who actively manipulates key decisions by using the shell game technique with IT Security Policy.

In this scenario, the manager is responsible for developing, managing, securing and representing IT security policy. He or she has control over the creation of the content and the data repository where it is officially maintained. The manager is also responsible for enforcing security across the company, which is based on policy, so employees are in the habit of going to the person holding this job title when copies of existing policy or answers about the interpretation of policy are needed.

Historic Shell Game

The shell game is an old standby used by con artists. It involves gambling on three cups and a ball (or discarded shells from a large nut and a pea). The con artist places the ball under one of the cups, scrambles the cups, and then challenges the target to locate the ball. At some point, a wager is placed, and the con artist secretly removes the ball from under the cups while quickly scrambling them, causing the target to lose the money gambled.

IT Shell Game

In IT security, data repositories are the cups and the data within them are the balls. It’s important to remember that ‘data repositories’ can be databases, shared drives, intranet sites, hard copies (paper) and human beings (accessing knowledge and skills of an employee or expert).

IT Security Policies are collections of key decisions. Like legal documents, they are the data referenced when determining what will or will not be done under certain circumstances. IT Security Policy covers everything from 1) how access is granted to every asset the company owns to 2) logical security requirements applied to specific data types. The person who controls these documents has significant power over decisions concerning changes that are (or are not) made to the physical and logical environment.

The hacker in our scenario has control over all IT Security Policies. The next steps are as follows:

  • He or she sabotages efforts to create company-wide transparency through a central repository, accessible to all appropriate individuals.
  • He or she keeps printed copies of old versions in a locked drawer or an untidy pile of papers on a desk.
  • He or she keeps track of the many different versions saved to different locations on the intranet.
  • He or she takes the draft version of policies being revised or developed, modifies them, formats them to look like a final copy, prints them out and saves them to the same drawer or desk pile.
  • He or she modifies policy immediately after it has been approved, without discussing the changes or acquiring additional approval, and save the modified version alongside the approved version.

This lays the groundwork for the shell game. The ‘shells’ are the many different versions and repositories established in the manager’s office and throughout the company. The ‘ball’ being chased is the final approved copy of an IT Security Policy, which is necessary when making key decisions concerning all aspects of IT security and IT development.

Acting as a malicious actor (hacker), the manager answers requests for copies of the policy by sending different people different versions. Sometimes these documents are pulled out of the messy pile on the desk or out of a drawer after the hacker makes a point of fumbling around while searching for the copy that he or she knows is “here somewhere.” Other times a link to an old copy saved on the intranet is provided or a modified electronic version is emailed out.

This is the equivalent to a shell game con artist pointing to a shell and saying, “the ball is here.” But when the shell is lifted it reveals a blue ball and the wager was specifically placed on the red ball.

Using Microsoft Word’s Compare feature to identify the differences between multiple documents would reveal the discrepancies, but that requires having a Word formatted copy of all variations. PDF files can make this comparison process difficult and PDFs created from a scan of a physical copy complicate matters even further.

Also, the individuals receiving the copy trust both the person and the job title and never stop to question the accuracy of the document.

At some point, someone may notice the differences between two or more copies and confront the hacker. This is (usually) easily handled through an apology, excuses about keeping track of things, and a copy of a version that may or may not be current or properly reviewed and approved.

This misinformation campaign has many malicious uses including (but not limited to): 1) eliminating employees who stand in the way of malicious objectives (e.g.: the employee is fired for failing to implement security requirements clearly detailed by IT Security Policy – the copy the person was not provided) and 2) reducing the security established on a specific system, which is then targeted by the hacker for clandestine modifications and ‘mistakenly’ left off the several-hundred-item list of systems available for review by external auditors.

Additional Application

This technique is a favorite among malicious actors who rely on falsifying data presented in reports. IT Security Policy is just one example of the many ways that this technique can be utilized.

Insider Threat Protection

There are a few things to consider:

  1. When managers are actively involved in distributing misinformation, particularly when that information concerns key decision-making documents, it should raise a red flag.
  2. All key decision-making documents (e.g.: legal documents, IT Security Policy, HR Policy, etc.) should be taken through a proper review and approval process before being published to a central repository accessible by all appropriate individuals.
  3. Consider establishing security controls around key decision-making documents that are similar to those placed on key financial assets. The person responsible for the accounting ledger does not have the power to write the checks due to the possibility of fraud. Similarly, a company may choose to place control of the repository housing these kinds of documents into the hands of someone who is not involved in the modification of systems or testing of IT security controls.

Industry standards dictate that IT Security Policy must be reviewed and approved by appropriate members of management on a regular basis (preferably annually) and made available to employees who require access. The additional controls listed above are examples of the kinds of measures that must be taken to prevent this form of exploitation.

Social Engineering Technique – The Idiot

When information security professionals discuss social engineering techniques, the conversation tends to revolve around outsiders attempting to gain access to information or physical assets – this is a serious and ever-present threat that must be appropriately addressed. However, a significant majority of breaches are caused by insider threats. This social engineering technique is one of many used by people who hack systems from the inside.

Establishing Trust

All insider jobs involve a period of establishing trust. When an employee completes work and participates in projects, the relative level of skill and competence is a key aspect to the amount of trust extended to that person. It’s also an important piece of data used to determine the relative threat a specific individual presents to an organization. For example:

  • Employee ABC: Is a programmer working on a development team with privileged access to multiple systems. ABC has consistently delivered high quality work, actively participated in complicated troubleshooting and is known for identifying highly effective ‘out of the box’ solutions.
  • Employee 123: Is a programmer working on a development team with privileged access to multiple systems. 123 has consistently delivered substandard work, which has resulted in multiple discussions with management about improving job performance. 123 frequently asks others for help in completing basic daily tasks and is known around the company as being lazy and unfocused. 123 has somehow managed to perform well enough to remain employed.

Both employees have the same level of logical access and physical access. When evaluating the risk of programmers as insider threats, it would be assumed that Employee ABC could caused significantly more damage than Employee 123. From a purely technical perspective ABC is a higher risk.

Employee 123 has established the reputation for being incompetent and lazy, which creates a perception of inability. While 123 has the logical access to do significant damage, it is assumed this individual lacks the technical skills to pursue any kind of advanced programming or clandestine activity.

By acting like an incompetent and lazy employee, 123 has established the trust necessary to act as a significant insider threat.

Getting Fired

After the hacker has completed the tasks necessary to achieve the desired goal, the next step is to make a professional mistake or participate in an activity that results in leaving the company. This could be a technical error that sets back a project by several months, a loud and profanity-laced argument with a member of management or some other drama that further solidifies the commonly held opinion that this individual is an idiot.

Reduced Perception of Risk

After this person is let go, the usual termination procedures are followed, and access is removed in a timely manner. Given the perception of this individual as incompetent, it is human nature to assume nothing more needs to be examined or addressed because it is not possible for this person to successfully modify information systems and assets without getting caught. This assumption is what the hacker is counting on because a more in-depth and careful examination of the systems would reveal multiple highly sophisticated modifications, resulting in a steady breach (or potential future breach) of data and resources.

Insider Threat Protection

While employed: If an individual is skilled and savvy enough to get through all the degrees, certifications, skills tests and interviews required for the job, then their transformation into an incompetent idiot is worthy of attention from management. It’s possible the individual truly is lazy and difficult to work with. It’s also possible that reputation is being actively established to cover their tracks. Either way. It’s worthy of investigation and monitoring. Some questions to consider:

  • Does the employee work at odd hours?
  • Does the employee attempt to access areas that are not necessary or appropriate for the job?
  • Does the employee manage to get around a thorough review of work at any point in the process?
  • Does the employee spend time ‘bothering’ people with higher, complimentary or different privileged access rights?
  • Does the employee spend a lot of time ‘playing with’ their phone?
  • Does the employee regularly bring privately owned equipment (e.g.: USB drives) to work?

While none of these activities, by themselves, is proof of malicious activity, they are worthy of note. An in-depth review of access, completed work and other activities may be warranted.

After termination: Performing thorough risk prevention and proper termination procedures across all systems and all employees are the best protection against this kind of threat. Never assume that a specific measure is unnecessary because the individual in question is perceived as being incompetent.