Endpoint

3/7/2018
02:00 PM
Michael Fimin
Michael Fimin
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Privilege Abuse Attacks: 4 Common Scenarios

It doesn't matter if the threat comes from a disgruntled ex-employee or an insider anticipating financial gain, privilege abuse patterns are pretty much the same, and they're easy to avoid.

Privileged account abuse is one of the most dangerous threats because it is relatively easy to execute and takes a long time to detect. The 2017 IBM Cost of Data Breach Study disclosed that organizations lost at least $3.62 million on forensic and investigative activities, remediation and legal expenditures associated with security incidents in 2016. But the overall damage for businesses can be irrecoverable.

No matter who the threat actor is — a disgruntled ex-employee looking for revenge or an insider with sticky fingers anticipating financial gain — privilege abuse patterns are pretty much the same. Four common scenarios offer cybersecurity professionals valuable lessons about proper privilege account management.

Scenario 1: Privilege Abuse
The simplest and most common situation is when an insider uses legitimate permissions for malicious activities. A vivid example of this is the July 2017 Anthem breach in which a third-party consulting firm, LaunchPoint Ventures, discovered one of its employees, in July 2016, had sent a file containing personal health identity information of 18,500 Anthem customers to his personal email. Besides that, the employee allegedly committed identity theft and misused non-Anthem data.

The investigation is underway. It is not yet known how the attack started, what the motives were, or what the employee did with the stolen data. But both Anthem and LaunchPoint are likely to face fines for noncompliance, bad publicity, and lawsuits from enraged customers.

Lesson Learned: Be aware of what your employees and contractors are doing by regularly monitoring the activity of all privileged users. You can deter misbehavior simply by letting people know they are being watched.

Scenario 2: Privilege Escalation
Privilege escalation is when an insider deliberately raises his or her level of permissions to get more access rights. Privilege escalation requires more effort and knowledge than simple privilege abuse. The most obvious example is the case of Edward Snowden, a contractor who worked as a systems administrator for the NSA, who leaked classified details of a NSA electronic surveillance program to the Washington Post and the Guardian in 2013.

We don't know all the details, but the most reasonable version of what happened is that the agency had poor visibility into user activity and little awareness of the keys and certificates in the IT environment. Snowden fabricated digital keys to obtain privileged access to areas way above his clearance. He also asked some NSA staffers for their usernames and passwords under the pretext that he needed them for his job.

Lesson Learned: Make sure you have rigorous control over access to systems that store confidential information, and a complete key and certificate inventory. In addition, remind your employees about your security policy and the consequences of violating it, for example, by sharing their passwords.

Scenario 3: Unauthorized Access
The unauthorized use of another user's account is particularly difficult to detect and investigate. It occurs when an employee either purposely steals someone's credentials or obtains them by mistake. These cases rarely go public, but here is one good example. Before leaving his job at engineering firm Allen & Hoshall and starting his own competitive business, Jason Needham gained the email credentials of a colleague and used them over the next two years to steal marketing proposals and client correspondence — as well as the rotating password credentials to the firm's FTP server. This enabled Needham to download schematics, staff emails, budget plans, and other sensitive data.

It is still unknown how Needham gained access to his colleague’s account. Most likely, they were either left in a visible location (hello, sticky notes on the screen) or were shared with Needham voluntarily. Since the company couldn't explain to regulatory bodies how the incident happened, it's fair to conclude they didn't have sufficient awareness of what was happening in their systems.

Lesson Learned: Detecting account hijacking can be tough, but thorough monitoring and analysis of user activity will help you detect anomalies that could indicate a security incident. It's also a good idea to implement a user termination policy that includes steps such as immediately disabling the employee's account, terminating VPN and remote desktop access, and changing all shared account passwords. Be sure that the policy is closely followed whenever an employee quits or is terminated.

Scenario 4: Human Error
Human mistakes are perhaps the most common type of privilege abuse. Actually, there are two types of mistakes to consider: when a user accidentally misuses access rights that were granted properly, or an admin grants a user excessive access rights by mistake or out of negligence. I bet every organization has experienced this issue. One example that was made public was about two employees at Vanderbilt University Medical Center (VUMC), who were granted access to 3,000 patient medical records that they didn't need for work. Their unauthorized access to this protected health information continued for 19 months, until it was discovered during a routine audit of access logs.

The audit revealed the employees had viewed far more information than was necessary to perform their work duties, such as patients’ Social Security numbers and medical record numbers. While VUMC does not believe that any data was misused, the individuals involved were disciplined for their actions, and the data breach is a violation of HIPAA regulations.

Lesson Learned: Strictly enforce the least-privilege principle to minimize the amount of data each employee can reach, and closely monitor user behavior to detect suspicious activity and new patterns. Also educate users about proper behavior and let them know they are being monitored; these steps can go a long way toward preventing costly mistakes.

The Main Lesson
These four common scenarios for privilege abuse resulting in data compromise all share the same key problem: a poor understanding of what users are doing in critical systems and how they interact with sensitive data, according to the 2017 Netwrix IT Risks Report, which my company recently published. To mitigate the threat or privilege abuse, security pros need to ensure that users have only the permissions they need to perform their duties, and monitor user activity across all levels of IT infrastructure.

Related Content:

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Michael Fimin joined Netwrix Corporation in 2007, bringing more than a decade of IT industry experience, management practices and innovation. Prior to joining Netwrix, Michael held several key positions at Aelita Software (later acquired by Quest Software), driving the ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
BrianN060
50%
50%
BrianN060,
User Rank: Ninja
3/11/2018 | 7:22:51 PM
Privilege Abuse
One could argue that the use of the word "Privilege" in this context, is an abuse itself.  Often it is taken as an entitlement or affirmation of status, even prestige - "Me, use least privilege?  How dare you?

"Authorization" comes closer to the intention: formalized and objective set of  constraints for use or access. 

I'll add that the use of "level" (as in authorization, privilege or access level), is less than optimal.  Again, there is the connotation of status or rank.  More importantly, levels apply to types or classes; where constraints are most effectively applied to instances: a particular entity, performing a particular activity, at a particular time.  It's a lot harder to hijack or elevate that type of "privilege". 
Microsoft, Mastercard Aim to Change Identity Management
Kelly Sheridan, Staff Editor, Dark Reading,  12/3/2018
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: I guess this answers the question: who's watching the watchers?
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19653
PUBLISHED: 2018-12-09
HashiCorp Consul 0.5.1 through 1.4.0 can use cleartext agent-to-agent RPC communication because the verify_outgoing setting is improperly documented. NOTE: the vendor has provided reconfiguration steps that do not require a software upgrade.
CVE-2018-19982
PUBLISHED: 2018-12-09
An issue was discovered on KT MC01507L Z-Wave S0 devices. It occurs because HPKP is not implemented. The communication architecture is APP > Server > Controller (HUB) > Node (products which are controlled by HUB). The prerequisite is that the attacker is on the same network as the target HU...
CVE-2018-19983
PUBLISHED: 2018-12-09
An issue was discovered on Sigma Design Z-Wave S0 through S2 devices. An attacker first prepares a Z-Wave frame-transmission program (e.g., Z-Wave PC Controller, OpenZWave, CC1110, etc.). Next, the attacker conducts a DoS attack against the Z-Wave S0 Security version product by continuously sending ...
CVE-2018-19980
PUBLISHED: 2018-12-08
Anker Nebula Capsule Pro NBUI_M1_V2.1.9 devices allow attackers to cause a denial of service (reboot of the underlying Android 7.1.2 operating system) via a crafted application that sends data to WifiService.
CVE-2018-19961
PUBLISHED: 2018-12-08
An issue was discovered in Xen through 4.11.x on AMD x86 platforms, possibly allowing guest OS users to gain host OS privileges because TLB flushes do not always occur after IOMMU mapping changes.