HACKER INTELLIGENCE INITIATIVE

Insiders: The Threat is Already Within

22

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

1 Edward Snowden is the United States (U.S.) National Security Agency (NSA) Contractor and System Administrator who acquired approximately four terabytes (TB) of data from the NSA using four laptop computers. According to the NSA, this data allegedly included approximately 1.7 million classified documents, and was the most damaging (to date) data breach ever to impact the U.S. Intelligence Community.

2 Manning worked as an intelligence analyst for the U.S. Army. Manning acquired and disclosed approximately three-quarters of a million classified or unclassified but sensitive military and diplomatic documents via the WikiLeaks website.

3 The Sony breach was discovered in November 2014 but was likely ongoing for over a year. In this attack, the attackers claimed to have taken over 100 terabytes of data from Sony Pictures Entertainment. Sony later acknowledged that the hackers not only erased data from its systems, but also stole and subsequently released to the public pre-release movies, private communications, and sensitive documents such as salary schedules and social security numbers.

1 IntroductionIn recent years, we have witnessed a growing number of enterprises and government agencies suffer data breaches. At the same time, we have witnessed significant growth in information security budgets. While organizations are buffing up their security layers—which is important—most of the focus is on preventing direct threats that come from outside, while detecting threats from within is neglected. We find this troubling, since our research indicates many significant data breaches are ultimately an “inside job.” Insiders – be they employees, contractors, business associates or partners – pose the biggest risk to enterprise data since they are by definition granted trusted access to sensitive data.

In conjunction with several Imperva customers we analyzed live production data that logged how users interacted with and accessed data stored in enterprise databases and file shares. We detected insider data threat events within every single design partner we worked with, confirming suspicions that ongoing insider abuse of data goes undetected.

Based upon this analysis, we classify the “threats from within” into one of three categories —malice, negligence, and compromise.

• Malicious insiders – trusted insiders that intentionally steal data for their own purpose – are the obvious nightmare scenario. Edward Snowden1 and Chelsea Manning2 (born Bradley Manning) are the highest profile recent examples.

• Careless and negligent insiders are the second insider threat. These are people within or directly associated with the organization that do not have malicious intent. Yet they expose sensitive enterprise data due to careless behavior— usually by trying to cut corners or simplifying their daily chores.

• Compromised insiders allow “external” threats (e.g., cybercriminals or nation-states) to act with the same level of freedom as the trusted insider itself. This is because once an insider is successfully compromised – usually via credential compromise or malware – it is in fact the insider that is directly accessing sensitive data. The Sony breach3 is a classic example of a breach resulting from insider compromise.

The investigation and analysis we conducted with our design partners detected instances of all three insider threat categories. Our approach focused on early detection of the breach of the data itself, rather than preventing initial external attacks. We believe this approach proved effective for two reasons. First, it identifies both malicious and negligent breaches, which by definition will not have any associated external attack. Second, focusing on the data itself – which is the ultimate end goal of any breach – eliminates the need for attack prevention to be 100% effective (which it never is).

33

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

2 Scope2.1 The Nature of Insider Breach

Data breaches usually take place over a relatively long period of time spanning weeks to months and even years. An insider may acquire small amounts of sensitive information over a long period of time. In some cases, breaches are noticed only after damaging events have taken place. In these cases, a company’s customers, partners, or other external groups may initially detect the breach. One of the goals of any security program should be to have early detection capabilities for breaches. For example, detect the behavior patterns of reconnaissance stage activity, before any specific damage can take place. Using early detection, a security breach discovery and investigation operation will typically span hours or days.

2.2 Our work

To understand how to identify the true warning signals that will help stop the insider data breaches at an early stage, we collected live production data from several customers of Imperva. We gathered data collected from Imperva SecureSphere audit logs that contain granular data access activity enabling full visibility of what users accessed what data over time. The data contains full database and file server audit trail records, achieved by monitoring both databases and file shares in the organization.

We applied machine-learning algorithms to identify different entities in the organization such as applications, jobs and DBAs. Our research crunched the data from two different perspectives. The first was looking at “data” anomalies, and included clustering the data by content (containing direct queries of data). Data anomaly studies yielded some success. The second was looking at “actor” anomalies, and included identifying actors and later learning some characteristics of these actors. The “actor” anomalies yielded the most success with zero false positives.

We learned behavior patterns of the employees in the organization, of peer groups in the organization, of employees from different geographic locations, and of the entire organization. Examples of such patterns are the normal access patterns within a file share (e.g., the quantity of files accessed in a month) or a database, the normal machine or IP addresses worked with, and the normal working hours and days.

To detect a breach, it is not enough to detect anomalies; there are plenty of anomalies in any good size organization. Detecting a breach requires detecting and highlighting the Meaningful anomalies. Doing so requires not only baselining good behavior, but also understanding and detecting the behaviors of bad actors. The former helps create a positive security model while the latter helps create a negative security model. Combining the two models is what identifies the truly meaningful anomalies. To “increase the signal” of bad behaviors, and to add context to identified behavioral anomalies, we also introduced deception technology. We used deception tokens – in essence false clues and fake data – that mimic real data access tokens. We found this highly effective, and anomalies from deception tokens had zero false positives.

We performed our research on many data sets to generalize our conclusions. We applied our collective understanding of normal data access behaviors to identify anomalies indicating bad behavior. We found anomalies that indicate malicious insiders, represent negligent insiders, and detected compromised insiders. We described our findings to the organizations that provided the data—who found them to be of high importance.

44

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

3 Behavioral Analysis Findings Behavior analysis identified malicious, careless/negligent, and compromised insiders. Specific findings identified in conjunction with the customers are summarized below.

3.1 Malicious Insider

3.1.1 Hoarding IP before leaving the company (or the technical writer who reads a lot)

Large copy operations from file shares are not rare in large organizations. These acts of duplication could be administrators reorganizing a file system, new employees taking a snapshot of project files or software installations from the file share. Thus, a large copy operation by itself could never be considered an anomaly. When we sorted through one of the data sets, we noticed an employee from the Technical Writing department in an organization copied many sub-directories of the file share—all located in a shared directory that belonged to the Technical Writing department. She copied different subfolders of the department-shared directory on several occasions over a period of three weeks. Each copy included a different portion of the shared directory and in each copy the employee copied a few thousands of files. Altogether, the employee copied more than 100,000 files from the organization file share to her local computer. The employee performed some of these copies in the middle of the night and sometimes on weekends.

Before that period, the employee never copied these amounts of files from the file share. Moreover, no one from her department or the entire organization copied these volumes of files from the file share.

It is important to emphasize that the employee had permission to access all the files she copied. However, she copied very large volume of files from the file share, she was copying at abnormal times, and neither she nor her peers copy these amount of files on regular basis. The anomalous data access pattern triggered an investigation.

When we requested the organization provide us with the data about this finding, they performed a short inquiry and uncovered that the employee was planning to leave the organization shortly after the incident took place.

01 2 3 4

Week number

Sunday

Monday

Tuesday

Wednesday

Thursday

Friday

Saturday

Num

ber o

f file

s acc

esse

d

5 6 7 8 9 10 11 12 13 14

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

Figure 1: Number of files accessed by user in a week

55

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

In Figure 1 the number of files accessed by the user in a week, in the time of our research are separated to days by different colors. The x-axis represents the week numbers, and the y-axis is the number of files accessed by the user each week. The colors are the weekdays. Normally, the user doesn’t access more than 10,000 files a week, and in most weeks she accesses much less. In the last two weeks, she accesses 65,000 and 50,000 files respectfully. In the last week, she accesses the most files on Friday (which is the weekend in the location of the user).

3.1.2 A DBA accessed financial information

Database systems typically work by granting unlimited data access privileges to database administrators (DBAs). Security best practices recommend that DBAs should have limited access to the data in the database. However, there is no real mechanism for enforcing it. Also in practice, sometimes DBAs are asked to look into the data for tuning and debugging purposes. In one of the data sets we examined, we noticed a DBA from the Information Technology department retrieved and modified multiple records from several internal PeopleSoft application tables on a specific day. These actions are alarming from several aspects. The first aspect is that the DBA did not access these tables through the PeopleSoft interface (he used MS Studio), and thus bypassed PeopleSoft logging and retrieval limitations. A second aspect is that the DBA retrieved an exceptionally high number of records from these tables and modified several thousands of records in one of these tables. The third aspect is that he used a highly privileged designated PeopleSoft DB account to perform the table modifications.

When checking what information was accessed by the DBA, we noticed that these tables contained sensitive financial information that should never have been exposed to an employee from the Information Technology department, and certainly should not be manipulated outside of application processes.

Figure 2: Example of abnormally large total number of database records retreived by a human user on a single day

1,000 10,000 100,000

Response size sum

1,000,000

21,335 910,946 4,402,988

4,402,988400,314193,03099,0651,372

The graph in Figure 2 is a box-and-whisker plot in logarithmic scale, with whiskers extending to 1.5 times the inter-quartile range. Different users are described by different colors. The top pane shows total daily response sizes by all users while the bottom only shows the user who triggered the incident. The right-most data point (4.4 M records retrieved on a single day) is an outlier in both populations and hence triggered an incident.

3.1.3 Attempt to access sensitive data

Failed login attempts are a regular phenomenon in database access. Users fail to login to a database due to forgotten or mistyped credentials or due to password changes. However, when a user fails to login to a database several times without success and never tries again, or when a user tries to access several databases in the organization without success, it is suspicious and may indicate that the user is not authorized to access the application. In one of the data sets we researched, we noticed a member of an Information Technology department trying to login to an application that enabled access to sensitive financial information. When exploring the data, we identified that the employee failed to login to the application three times and then stopped trying. The fact that the user stopped trying to access the database looked suspicious to us. We continued our investigation and learned that the application that the user tried to access was a desktop application with preconfigured credentials using a designated DB Account. As such, the user was never supposed to fail in the login stage. In fact, none of the other users of the same application ever failed to login. Moreover, none of the other users of this application belonged to the Information Technology department.

66

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

When informing the security manager of that organization about the incident, we discovered that Information Technology members were not authorized to access this application. Furthermore, the employee was dismissed from the organization soon after that incident.

3.2 Negligence

3.2.1 Account Abuse

We have learned from the data we investigated that in many organizations DBAs routinely use service accounts to access databases. This practice is not recommended. It leads to negligence since accountability is lost. Moreover, the identity of the user responsible for the operation cannot be uniquely established. Additionally, privileges cannot be managed, as the service accounts have high privileges.

When DBAs use a service account to access the database, it is impossible to maintain personal accountability and be able to DENY access once an employee leaves the company. In organizations that do not have tighter operational control, it is harder to detect meaningful anomalies and identify breaches as the abnormal activity gets blended into the non-characterized shared account activity. Following our observations and the evidence from the data set, some of the organizations that provided the data moved into a more restrictive, personal database account model.

3.2.2 Account Sharing

Even in organizations that do care about creating individual accounts, we were able to spot some types of abuse. The most notable one being account sharing, a practice that of course makes the whole point of personal accounts moot. Sharing of personal accounts leads to bypass of an organization’s permissions and privileges mechanism. It provides people with access to data they are not entitled to according to company policies, and leaves an incorrect access trail to this data. We have seen a few examples of account sharing in the data sets we examined. One example is of two employees from an organization who shared their accounts credentials. Each of those employees owned a personal account named identically to his respective domain user and providing access to a different production database in the organization. These two employees shared their account credentials on a regular basis. They appeared to do this whenever one of the two users wanted to retrieve data from the production database for which his user credentials did not have data access privileges.

77

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

1

2

Dat

abas

e A

No.

of d

ays

5

10

20

50

100

Database

Usage of DB accounts by domain users

1

2

Dat

abas

e B

No.

of d

ays

5

10

20

50

100

User A User B User C User D User E User F User G User H User I User J User K User L

Account A

Account A

Account B

Account BAccount B

Account B

Account GAccount G

Account G

Account A

Account E

Account E

Account I

Account IAccount K

Account K

Account I

Account F

Account F

Account B

Account E

Account F

Account G

Account I

Account K67

18

15

73

42

2217

6

3 32

127114

6 5

2

130 113

Figure 3: Sharing of database accounts

In Figure 3, column represents domain user, while color represents DB account. Numbers and bar size (in logarithmic scale) represent the number of days on which the DB Account was used by the human (domain) user to access the relevant Database. Account A belongs to User A, Account B belongs to User B and so on.

Appearance of the same color in several columns means that the account is shared; while several colors appearing in the same column mean that the user is using multiple DB Accounts.

88

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

Cases of account sharing shown:

• Users A and B routinely share their personal accounts between them, presumably by agreement, to “pool” their privileges on the two different databases (User A’s account has privileges on Database A, while User B’s account has privileges on Database B)

• Users C and D routinely use User B’s personal account, rather than use their own• User H uses the personal accounts of Users E, F and G rather than his personal account• User J uses the personal accounts of G and I rather than his personal account• User L uses the personal accounts of K rather than his personal account

3.2.3 Files Exfiltration

Although copying a large amount of files from the file share is not uncommon, and not necessarily disturbing, the exfiltration of a large amount of files to an external unidentified machine through remote connection to the enterprise is both disturbing and uncommon.

In our research we revealed an employee that copied 1,500 files from the file share—not a staggering number by itself. All files were copied automatically (through a single copy action) from a subdirectory in the file share. The copy took more than six hours, which means that each file copy operation took almost 14 seconds on average. As a comparison, an average normal file copy operation, inside the network, takes about one second to complete.

The fact that the copy took a very long time can indicate that the employee connected to the organization remotely, through VPN, and that he copied the files to a device outside the organization. When slow rate copy—that may indicate exfiltration of intellectual property—is discovered, we recommend performing an investigation. The following questions should be asked: Which files were copied? Where were they copied to? What other activities were done by the same employee related to accessing the organization’s unstructured data (file shares and/or databases)?

3.3 Compromised Insider

3.3.1 Multiple failed login attempts

As mentioned before, failed logins to a database are not uncommon. However, when a user changes his normal login activity pattern without success it is suspicious. For example, when a user tries to access a database or several databases he didn’t use before without success and/or when a user uses credentials he never used before.

We have seen in one of the data sets a user that usually accesses a specific database, tries to login to a different database he has never connected to previously, using several different DB accounts which he had reason to think might be defined on this database.

In total the failed login attempts to that database included three different DB Users in a short period (less than 10 minutes), including the same credentials that were defined for the user on a different database, and a total of 4 login attempts within one hour. The user finally succeeded in logging into the database on his fifth attempt, using an applicative account that he had guessed existed on this machine. However, this account did not allow him to perform any operations on the database due to insufficient privileges of the account.

99

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

Baseline

DB1Normal DBfor this user

DB2Anomalous DBfor this user

Successful logins

Day of incident

Failed logins Successful logins

1

333

6

1

4

1,954

Figure 4: Abnormal login pattern by user

In Figure 4, different DB account names are represented by different colors, and counts represent number of login operations. The pie charts show login successes and failures by the user. In the baseline period (left pane), the user always logged into DB1 and never into DB2, almost exclusively using the “red” account, without ever failing a login attempt. By contrast, on the day of the incident, apart from a successful login to DB1, the user tried and failed to log into DB2 11 times using four different account names, including the “red” account name which the user knew to be defined on DB1. The user eventually succeeded in logging into DB2 using the “purple” account, which is an application account name that turned out to exist on DB2, but apparently with restricted privileges.

1010

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

4 Deception FindingsAnomalies are a fact of life in modern data process environments, and not every anomaly is a breach incident. Hence, there is value in being able to clearly distinguish some anomalies from others. To that end, we introduced deception mechanisms into endpoints to add additional context to anomalies identified by behavioral analysis. This mechanism relies on decoys that we planted on endpoints, with the end goal of leading attackers into a trap. The data provided through the deception mechanisms, when correlated with other anomalies, provides strong indicators of compromise.

We worked with design partners to deploy deception technology during our research, and were able to detect incidents of advanced attacks in their early stages, before the attackers had an opportunity to compromise larger portions of the network. We were also able to detect some cases of negligence.

4.1 Negligence

4.1.1 Shadow IT

While contributing to productivity, cloud applications carry with them a significant risk. An organization may choose to use a cloud service for data collaboration, and also let employees use their personal cloud storage services.

With one of our clients, we saw an abnormal amount of traffic coming from one endpoint, which could be attributed to a specific artifact we had planted. This suggested that some process was extremely active in accessing our artifact.

After a short investigation, we concluded that an employee was using his personal cloud service, unintentionally, to backup enterprise data. While the user’s intentions may have been pure, this practice obviously puts corporate data at risk.

4.2 Compromise

4.2.1 Catching Spoofs

Once inside a network, hackers can easily pretend to be something they are not. Many applications are constantly seeking other assets on the network, and are susceptible to spoofing and Man In The Middle (MITM) attacks. Once an attacker spoofs a response, he controls the connection, where he can try to steal the victims’ credentials, or leverage existing credentials to access another server.

In one customer’s network, we noticed that the traffic from our planted artifacts suddenly changed. Artifacts that were typical regarding content and timing of one machine started to show up from a different machine. The incident response team realized that the machine from which the traffic was arriving was compromised and conducting MITM attacks against other machine in the network. The response team easily detected which process caused the malicious traffic and the malware that was responsible. By knowing which endpoints had their traffic redirected to the compromised machine, we were able to determine which accounts were likely compromised and required password change.

4.2.2 Hacking Internal Applications

Internal applications used by companies are a hacker’s favorite target. Because of their proprietary nature, internal applications tend to be much less secure, and usually run on outdated OS.

One such application inside a customer’s network managed their entire confidential list of customers along with their personal information—an obvious target for hackers. Within the customer’s network, we planted fake session information to this internal application in such a way that normal usage of the app remained unaffected. After a few months, we caught an alert because one of the endpoints tried to use our fake session data against the internal application. We were not surprised once the response team detected a Trojan performing reconnaissance, the starting phase of a possible devastating attack. The Trojan got through to the endpoint using simple phishing email and social engineering techniques, but was not caught by the customer’s other security measures.

1111

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

4.2.3 Credential Dumps

One of the most obvious cases of an advanced attack is the use of stolen credentials. In a world of statistics, it is rare to catch a glaring red flag of a compromise. However, this was exactly the case in one incident, see Figure 5. This time, the hackers got greedy trying to use several fake credentials that were planted on an endpoint. These included planted credentials inside Windows Vault, Internet Explorer, and two other fake accounts that were planted in memory. All of these tokens were dumped and used by the attackers. Each token by itself is indication enough of a compromise. But put them all together in the same day, and there is little doubt left about the seriousness of the attack.

Vault Credentials

1

09/21/2015 10:14:11 AM 9/21/2015 10:41:46 AM 9/21/2015 1:34:01 PM 9/21/2015 3:06:21 PM

2Severity

Date Time

Num

ber o

f Rec

ords

CriticalHigh

IE Browser Credentials Memory Credentials user 1 Memory Credentials user 2

Figure 5: Example of credential dumps

This type of behavior is not only indicative of a compromise, but usually of a manual operator that has a backdoor into the organization. While the attacker had no idea his activity was already detected, we were able to determine the source and scope of the attack, and completely remove the threat from the network.

1212

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

5 CONCLUSIONFrom looking at our data, we can only conclude that the current security layers are not good enough when it comes to detecting data breaches. While all of our customers had the “right” security layers in place, they were not able to identify many types of compromising, negligent, or malicious behavior. Their security tools produced many alerts, making it impossible to capture actual incidents. This ecosystem forces the security team to investigate only incidents that are “louder” than other incidents. While it may make some sense, and does bring some value, in the real world, this does not pose any threat to seasoned hackers who know how to hide their activity. At the same time, the security tools didn’t produce any alert for quite a few incidents that involved actions for which users had valid permissions, like accessing files in a file share.

What companies need are new technologies for detecting insider threats. These technologies don’t only rely on propagating and accumulating incidents, but rather, are focused on the attacker’s goals (your data) and actions (attack vectors such as dumping credentials, network manipulations and data access patterns).

5.1 Behavioral Analysis

One key technology for preventing potential data breaches within the organization is data analysis that combines machine-learning. The most important challenge in machine-learning and data analysis is the data itself, since the machine-learning algorithm is only as good as the data fed to it. A good machine-learning algorithm should rely on full visibility to data access activity, to detect the attack and not some side effect of it. Another great challenge in machine-learning is defining the parameters of the algorithms. The algorithms used by most solutions are well known and have been applied for years to different domains. These algorithms require adaptation to a specific problem domain in the form of choice of algorithm and choice of measures—which algorithm fits the problem best and how to define similarity or distance between data points in the domain.

The data analysis solution should be a holistic solution which is data center focused. It should look at accesses to databases in the organization as well as to accesses to file shares and cloud applications used in the organization.

5.2 Deception

Deception technology has an edge over other solutions because it gives the security team a binary, or “black to white”, method for detecting advanced attacks. This distinction is crucial when the security team needs to prioritize which incidents require further investigation. Good deception is hard to find, because most deception solutions rely on Honey Pots inside the network which can be easily avoided by hackers. A recent example of this is the NASA drone leak in which hackers compromised a server and then moved laterally using sniffed user credentials to gain privileged access.

With our advanced deception techniques, a hacker has virtually no way of knowing if they are walking into a trap until it is too late. Additionally, while other security solutions may track and identify malware found on your compromised assets, it is not clear whether you’ve identified the byproduct of commercial malware—such as lateral movement or symptoms of a deliberate attack against your organization. When deception credentials that should never be used by a legitimate user are in fact used to access data in your organization, it’s certain you’ve uncovered a data breach in progress.

5.3 Overall Detection

The real power of detection lies in the combination of Deception and Behavior Analytics. To catch an attack or data breach as early as possible you need multiple layers of detection. Each layer adds to the equation in uncovering a compromise, detecting every stage of the attack lifecycle. Figure 6 shows the combined detection score that we aggregated from several customers.

imperva.com

© 2016, Imperva, Inc. All rights reserved. Imperva, the Imperva logo, SecureSphere, Incapsula, Skyfence, CounterBreach and ThreatRadar are trademarks of Imperva, Inc. and its subsidiaries. All other brand or product names are trademarks or registered trademarks of their respective holders. REP-Insider_Threat-0316-rev1

HACKER INTELLIGENCE INITIATIVE REPORTInsiders: The Threat is Already Within

-1

Det

ectio

n Sc

ore

Attack Stage

TechnologyBehaviour AnalyticsDeception

Initial Compromise Reconnaissance Lateral Movement Data Access Exfiltration

0

1

2

3

4

5

6

Figure 6 - Combined detection score

From the data, we can see that combining detection technologies enables us to catch an attack in its various stages, except for the initial compromise. Assuming that a compromise is inevitable, the advanced technologies should be focused on finding the attack past the initial foothold.

Hacker Intelligence Initiative Overview

The Imperva Hacker Intelligence Initiative goes inside the cyber-underground and provides analysis of the trending hacking techniques and interesting attack campaigns from the past month. A part of the Imperva Defense Center research arm, the Hacker Intelligence Initiative (HII), is focused on tracking the latest trends in attacks, web application security and cyber-crime business models with the goal of improving security controls and risk management processes.