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.