The credit reporting agency Equifax reported on September 7th, that it had been breached. On Friday, we outlined what we knew at the time, which was replete with intelligence gaps. Five days have gone by and some of these gaps have now been filled in. Here’s what we know so far, and what we can learn from the Equifax breach.

Equifax Timeline

Figure 1 – Timeline of events surrounding Equifax breach


Threat Actor Claims

There have been at least two claims made by financially-motivated threat actors. One actor had made an extortion attempt and claimed to possess the data, the other offered web shell access to an Equifax server. The credibility of either of the claims was unknown and based on the available evidence the likelihood they were genuine could not be judged.

1. Extortion attempt

A Tor hidden service was established around September 8th on which claims were made the owners had compromised the Equifax data and were trying to monetize it. They valued the data at 600 Bitcoin (USD 2.7 million), alleging Equifax executives had amassed USD 3 million in shares by conducting insider trading prior to alerting the public to the breach incident. The operators of the hidden service set a deadline of September 15th for this ransom demand, claiming they would delete the data they possessed if it was paid. If no ransom was paid, the actors said the data would be released publicly. At the time of writing these claims were not confirmed, the site was no longer reachable and the email address had been disabled.

Equifax Statement on Tor site

Figure 2 – Statement on Tor hidden service

On September 11th, an actor using using the same nickname – “pasthole” – claimed on Pastebin that a portion of the data was sold to an unidentified buyer. The actor also said they were responsible for the Tor hidden service previously used to announce an extortion attempt against Equifax. An email address and PGP key provided in the post provided no direct links between the now-offline Tor hidden service and the Pastebin post. None of the claims in this post could be substantiated at the time of writing.

2. Web shell access offered for sale

On September 8th, an actor known as “1×0123” claimed to have gained web shell access to an Equifax server, and subsequently offered this access for sale. In their initial post to their Twitter account, 1×0123 posted a screenshot of what appeared to be a listing of Equifax subdomains allegedly being accessed via the Equifax website. In a follow up post, 1×0123 then claimed to offer access to the web shell in exchange for 1 Bitcoin (BTC) and supplied a Jabber ID for contact. Based on 1×0123’s screenshot, it appeared as though they used the WSO web shell, which is a popular tool among certain hacking communities. We did not detect any evidence of authenticity for the alleged web shell access. The screenshot below shows the post made by the actor, who redacted the screenshot.

Equifax 1x0123 claim

Figure 3 – Claim made by 1×0123 

Apache Struts Touted As The Web Application Vulnerability

In its breach disclosure, Equifax originally stated a web application vulnerability had been exploited which resulted in the data breach. There have been allegations this vulnerability affected Apache Struts reported in the media. This was following publication of an equity research report by Robert W. Baird & Co., which claimed an Equifax representative had told them Apache Struts was exploited to access the compromised information. None of this information could be confirmed at the time of writing.

Criticisms Leveled Towards Equifax’s Response

1. Executives sold shares prior to disclosure

Three Equifax Inc. senior executives were reported to have sold shares collectively worth almost USD 1.8 million shortly after the company discovered the security breach on July 29th. The timing of these sales has led some to question whether the individuals had dumped the shares as a result of the breach. Equifax, however, said the executives had not been informed of the breach incident prior to them selling the shares.

2. Equifax data breach checker

Equifax released a service designed to allow individuals to check whether they were implicated in the data breach, but following this there were multiple reports that it was returning incorrect results. A test conducted by the media outlet ZDNet used fake names and social security numbers that returned the result “may have been impacted”. Equifax acknowledged that some consumers who visited the website shortly after it was launched may not have received confirmation they were impacted. It was not known whether the breach checker functioned correctly at the time of writing.

3. Legal updates

Following complaints from consumer advocates in relation to Equifax’s terms of service, the company announced that using its TrustID monitoring service would not result in a user forfeiting their right to join a class action law suit against the company in relation to the breach incident.

On September 8th, The Register also reported two class action lawsuits had been filed against the company, in Portland, Oregon and North Georgia US District Courts. The lawsuits saw Equifax accused of negligence and violations of the U.S. Fair Credit Reporting Act. The complaint filed in Oregon reportedly sought USD 70 billion in damages for residents of that state alone.


1. At the time of writing, it was not known exactly how many individuals were impacted by this data breach
2. Despite the claims made by two threat actors, the individual(s) responsible for this breach and their motivations were unknown
3. Although Equifax stated a web application vulnerability was exploited, the exact vulnerability exploited is not known.


The breach has had a demonstrably negative impact to Equifax, both in relation to its reputation and its finances. As of September 13th, Equifax stock (EFX) is down $31.16 per share ( since the announcement of the breach. Data breaches frequently increase the amount of scrutiny around a company’s security posture, but the reporting on managers selling their shares, lawsuits and the way Equifax responded to the breach all likely degraded its brand reputation.

The impact of this data breach to individuals largely depends on the motivation of the actors that gained access to it. For financially motivated actors, the exposed information would almost certainly be of high value as part of fraudulent activity; payment card details can be used to make fraudulent purchases, while personally identifiable information (PII) can be used in identity theft. This kind of data is also frequently offered for sale or traded on criminal locations, showing another potential means of profit. The New York Post published an article on September 8th, which said payment card fraud had “unexpectedly” spiked in August 2017. The article cited the co-founder of a fraud prevention service called Forter, who assessed the spike was likely tied to the Equifax breach. The co-founder, Liron Damri, reportedly claimed a 15 percent increase in fraud attempts was detected in August 2017. At the time of writing, there was insufficient evidence to confirm a link between the Equifax breach and the increased fraud levels.

While debate continues as to whether this was a “zero day” exploit targeting a previously unknown vulnerability or a lapse in patching which caused the breach, the exact nature of the exploit is largely a side-show. The attack lifecycle describes a number of different stages that an attacker needs to traverse in order to successfully achieve its goals:

1. Initial Reconnaissance
2. Initial Compromise
3. Establish Foothold
4. Escalate Privileges
5. Internal Recon
6. Move Laterally
7. Maintain presence
8. Complete Mission

The successful exploitation of the Apache Struts server merely compromises one of the eight steps, in particular the third one: “Establish Foothold”.

In order to effectively defend against attackers, an organization must have prevention and detection mechanisms operating at all stages of the attack lifecycle. It cannot be assumed that patching a particular web application framework against security vulnerabilities is sufficient.

Assuming that attackers are able to penetrate the perimeter of an organization is the “assume breach” model and is an essential part of a mature organization’s approach. In brief, it states that a defender should assume that attackers have already breached their outer defenses and are moving within the organization’s internal network. This corresponds to steps four through eight of the attack lifecycle. A defender can effectively respond to such an intrusion by exercising the principle of least privilege to reduce potential privilege escalation vectors, limiting opportunities for an attack to move laterally within an organization and detecting abnormal behavior, hunt for the introduction of persistence mechanisms and monitor the network for suspiciously large transfers to unknown systems outside of the organization.

Combining these techniques is called “defense in depth” and allows an organization to be robust against attackers wielding zero day exploits.