It’s currently unknown how long hackers were in Equifax’s systems before they were detected, or if the ones discovered were the only ones that took advantage of Equifax’s open door policy. What we do know is that they (and potentially others) possibly lived within the systems for 146 days – more than enough time to exfiltrate whatever information they were seeking, make changes, and even damage data integrity by immortalizing any modifications within backups.

Since the hack, a group of hackers called the “PastHole Hacking Team” has claimed responsibility, threatening to release the data unless a ransom demand of 600 Bitcoin (a bit shy of $2.5 million USD) was paid. The ransom demand was ignored, and at this time, it is unproven that these were the actual hackers. However, in conversations with security researchers, this group has allegedly claimed access to much more data than they initially expected.

Hackers Approach

According to Equifax, the attack occurred against their public web server, which provided functionality for consumers to dispute the accuracy of credit information.

It’s said the hackers took advantage of a vulnerability in Apache Struts (CVE-2017-5638). It was a serious security flaw that allows an attacker to execute code on the server using a specially created Content-Type HTTP header.

But here’s where things get… questionable.

The flaw in the Apache Struts framework was fixed on March 6. Equifax says it noticed suspicious traffic on July 29 and took the application offline the next day. It then patched the server and put it back online the day after.

Why did Equifax wait so long to apply the patch?

There are many things wrong with this. First, the patch was available on March 6, but was not applied until July 30, essentially leaving the front door wide open for 146 days. This vulnerability was listed as a critical patch and should have been applied immediately.

Apparently, there were concerns that rolling back to an older version (that did not contain the vulnerability) could break current website functionality. While I sympathize with organizational bureaucracy, I cannot agree with this decision. They should have been worried more about system vulnerability than website functionality. Functionality loss is more acceptable and defensible than data loss.

I recognize that in an organization as large as Equifax, there was probably serious reluctance to take actions that might result in a loss of functionality. It could have caused some unhappy customers, additional customer calls, etc. for something that would have no observable consequence once successfully mitigated. The possible fallout of inaction would never be seen or appreciated by those that were inconvenienced for a short time. However, based on the threat severity of CVE-2017-5638, someone should have been empowered to make the hard calls necessary, the calls that while potentially unpopular and disruptive to the organization, would have saved it (and its reputation) from the many worse days and weeks ahead.

Given the amount of time their systems were exposed, it’s also possible that other hackers had discovered the open door and paid them a visit. Once compromised, patching the vulnerability is necessary to prevent new attacks, but likely insufficient to contain any hackers that have already visited, as, with this type of exploit, the attacker is able to run remote code, install new software and open up alternative and more preferred methods of later access.

Would ThreatWarrior™ have caught this?

Yes. In a number of different ways, including the following examples:

Once the vulnerability was identified and a signature created, it would have been delivered as a vaccination signature from the ThreatWarrior cloud. Obviously, Equifax should have patched their systems immediately to avoid compromise. If, however, they had not applied the patch (which they didn’t), the vaccine engine of ThreatWarrior™ would have detected the intrusion and immediately raised a threat event for immediate response.

Had the server been compromised before a vaccine signature was known or a patch available (a zero-day attack), upon compromise, the hacker would have changed the behavior of the machine on the network, causing the AI engine to raise a threat event for investigation.

It is currently unknown how the hackers extracted data from the Equifax systems and where it was transmitted, however, this activity could have been detected in a number of different ways:

Once compromised, the attacker would have downloaded additional tools to the machine to establish alternative connectivity (remote code exploit is the actual attack vector), which would have caused network traffic to remote servers necessary to download and install attack tools. If the IP of the attacker’s server was known to ThreatWarrior (as a server used for nefarious purposes), a threat would have been raised. Regardless, the fact that the machine’s behavior changed would have been detected by the AI engine.

After remote tools are installed, the hacker would have revisited the servers through these new connections, which would have been detected as a behavioral change.

As the data is being removed from the systems, the patterns of data transfer would raise behavioral threat events. Learn how ThreatWarrior’s network detection and response solution can provide real-time protection across your enterprise.

Hard Lessons Learned

Unfortunately, a consequence of conducting modern business is that you will make yourself vulnerable to cyberattacks. Our systems are extremely complex from the inside out. However, with tools like ThreatWarrior that use AI to learn normal behavior, it is possible to detect these attacks and prevent malicious actors from executing before they cause harm.

In this case, Equifax was vulnerable on at least two fronts; the first being incompetence (or, at the very least, a lack of concern and action) and the second being an unpatched server. But even given the magnitude and severity, this incident reiterates numerous lessons all organizations need to take note of:

• Patch security updates immediately
• Hire qualified people
• Don’t let bureaucracy get in the way of protecting customer data
• Employ state-of-the-art intrusion detection systems
• Functionality loss is more acceptable and defensible than data loss
• Keep a focused eye on your patches, because if you don’t, your replacement will