Secure coding

Least Privilege Vulnerabilities Exploitation Case Study

Dimitar Kostadinov
July 29, 2020 by
Dimitar Kostadinov


The principle of least privilege is a security concept that limits security exposure in IT environments through balancing security, productivity, privacy and risk. To put it simply, least privilege controls restrict each user’s access rights to the minimum they need to perform their job.

Did you know that 74% of data breaches start with privileged credential abuse? According to Centrify’s Privileged Access Management in the Modern Threatscape survey, that is exactly so.

Learn Secure Coding

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Privilege attacks may come in many shapes and sizes. Let’s review briefly some variations of such attacks with a reference to real cases.

  1. Privilege abuse: An employee of a third-party consulting firm stole the personal health identity data of 18,500 Anthem customers in 2017
  2. Privilege escalation: Both the Home Depot and Target data breaches happened due to a third-party vendor's credentials being somehow compromised, giving the hacker access to their networks
  3. Unauthorized access: An ex-employee of the engineering firm Allen & Hoshall appropriated some intellectual property, client correspondence and other sensitive data after using email credentials of a former colleague
  4. Human error: Two workers at Vanderbilt University Medical Center (VUMC) were granted access to 3,000 medical records of patients, despite the fact that such authorization was not related in any way to their job duties

Not using the least privilege principle is a recipe for disaster. As you can see, the ingredients may be different, but the bitter aftertaste is all the same. 

This article will focus on the 2017 Equifax data breach — an incident of massive proportions that could have been avoided if the proper defensive mechanisms were set in place.

Case study: Equifax data breach

The initial compromise took place on March 10, 2017. It was due to an unpatched vulnerability (CVE-2017-5638) existing in an Apache Struts instance running on Equifax’s web servers. Although that in itself was a significant security failure on the part of Equifax’s administrators, we will focus on their failure to apply least privilege controls.

After the unknown hackers managed to access the web server, they could circumvent all security measures at the edge. Being in this position, attackers usually seek to scan internal networks in order to attempt to sneak into the database, where the real treasure is. This is a common lateral move tactic.

It does not matter if the inner communications, where the applications are running, move around in the context of a private data center or a public cloud. Perhaps the most aggravating circumstance, as far as the principle of least privilege is concerned, is that internal networks’ traffic is often less monitored. Unfortunately, that was also the case with Equifax.

In the period from May through July 2017, the criminals managed to get a hold of the private information of millions of people stored in multiple Equifax’s databases. Note that it was not until the middle of May when the attackers started to move laterally from the compromised server into other sectors of the network, siphoning data out of databases under the nose of the unsuspecting IT team. Prior to extracting the data, the bad guys encrypted it to make it blend with the rest of the internal network traffic.

Digital forensic records showed that attackers had resided in Equifax’s networks for 76 days before being discovered. One of the reasons the cyber exploitation against Equifax was so successful was the fact that the company had permissive access controls accompanied by open network architecture. Hospitality is a good thing — within limits.

Access management of Equifax could have been stricter. For example, access to users should be given on a need-to-know basis. If any user is regarded as trusted, malicious actors would not have a difficult time finding their way around the system. It will feel like home to them. No wonder that during the Equifax exploitation the attackers were able to execute up to 9,000 database queries — a fact that in itself should have been a giant red flag if the security team was more vigilant with respect to abnormal network traffic/behavior.

One of the changes the new Equifax CISO, Jamil Farshchi, made in the wake of the breach was to strengthen access control protections and identity management across the entire company’s infrastructure. These aspects are central to the implementation of the least privilege principle. This is because keeping systems more siloed would mean that Equifax can effectively minimize the free-for-all of unneeded access. Though convenient, this bodes nothing but trouble.

Segmentation could be an excellent technical measure for a company to enforce the principle of least privilege, as it allows only container connections-based whitelisting. Furthermore, a policy like that can enforce the rule that web servers (which are internal applications) are forbidden to connect to external networks or the database. Such a policy would have directly stopped Equifax's malicious actors in their tracks, unable to move further from the initial zone of infiltration.

This statement is not as far-fetched as it may seem. Take, for instance, the assumption investigators arrived at that after the first incursion the attackers had to stop because they had not had the expertise nor the tools to probe further. Likely, then the foothold had been sold to more experienced attackers. The point is that any obstacle you put in the way of the bad guys may buy you some time at least.

“We had one of the most impactful breaches of all time,” stated Equifax CISO Jamil Farshchi. The personal data of some 143 million consumers (57% of US adult population) were stolen from Equifax. What makes this data breach potentially the biggest disaster is the permanent nature of the stolen private data:

  • Names
  • Addresses
  • Dates of birth
  • Social Security numbers
  • Drivers’ licenses
  • Credit card numbers (about 200,000 clients)

The customers of Equifax who were most concerned about their credit score paid for its in-depth analysis only to have even more personal data stolen from them, including bank details. This exposed them to fraud and eventually damage to their credit score.


Current estimations show that the breach cost Equifax $1.4 billion on cleanup expenses, plus another $1.38 billion following a record-breaking settlement with the FTC in order to resolve consumer claims among other things.

As we have seen, this costly disaster was likely avoidable. A zero-trust approach to Privileged Access Management (PAM), generally speaking, could make a huge difference as far as a given organization’s cybersecurity is concerned. In the end, a stringent least-privilege policy will not turn your organization into some kind of impregnable fortress, but it certainly would make things for hackers a lot more difficult and may save you from unnecessary worries.

Learn Secure Coding

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.



  1. 9 InfoSec Lessons from the Equifax Data Breach, BeyondTrust
  2. 74% Of Data Breaches Start With Privileged Credential Abuse, Forbes
  3. An Information Security Expert’s Take On The Equifax Breach, FRSecure LLC
  4. Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach, GAO
  5. Equifax Data Breach Analysis – Container Security Implications, NeuVector
  6. Equifax Data Breach – What Really Happened There?, VMware, Inc
  7. Equifax data breach FAQ: What happened, who was affected, what was the impact?, CSO
  8. Equifax's Security Overhaul, a Year After Its Epic Breach, Wired
  9. Equifax's Data Breach Costs Hit $1.4 Billion, Information Security Media Group
  10. Privilege Abuse Attacks: 4 Common Scenarios, DarkReading
  11. The ‘least-privilege’ model protects digital assets and user productivity, VentureBeat
Dimitar Kostadinov
Dimitar Kostadinov

Dimitar Kostadinov applied for a 6-year Master’s program in Bulgarian and European Law at the University of Ruse, and was enrolled in 2002 following high school. He obtained a Master degree in 2009. From 2008-2012, Dimitar held a job as data entry & research for the American company Law Seminars International and its Bulgarian-Slovenian business partner DATA LAB. In 2011, he was admitted Law and Politics of International Security to Vrije Universiteit Amsterdam, the Netherlands, graduating in August of 2012. Dimitar also holds an LL.M. diploma in Intellectual Property Rights & ICT Law from KU Leuven (Brussels, Belgium). Besides legal studies, he is particularly interested in Internet of Things, Big Data, privacy & data protection, electronic contracts, electronic business, electronic media, telecoms, and cybercrime. Dimitar attended the 6th Annual Internet of Things European summit organized by Forum Europe in Brussels.