What Happened

On Sep 7th 2017, Equifax – one of the “big-three” U.S credit bureaus – announced one of the most high profile data breaches in recent memory. This attack is estimated to have affected 143 million Americans through the loss of confidentiality of victims Social Security numbers, birth dates, and driver’s license numbers. [1].

Since this breach, additional compromises of Equifax data (both related and unrelated to this incident) have been reported – 200,000 stolen credit cards. [2], PII stolen on 693,665 UK residents[3], spyware in Equifax credit assistance site[4], exploiting Equifax’s TLAX payroll division[5] and more.

With the release of the August 2018 report by U.S Government Accountability Office titled “Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach”[6] new details on the breach sequence and steps that could had been taken are revealed.

This short writeup will go through the different steps on the 2017 Equifax’s breach and discuss how VMware AppDefense could mitigate such attack vectors.

What is VMware AppDefense

VMware AppDefense is an Application Behavioral Whitelisting solution focused on helping customers build a compute least privilege security model for data center endpoints and provide automated threat detection, response, and remediation to security events. AppDefense is focused on “ensuring good” versus “chasing bad” on data center endpoints.  When we focus our attention on what a workload is supposed to be doing, our lens for seeing malicious activity is much more focused and as a result, we narrow the exploitable attack surface of the workload down to what we know about.


Equifax’s Breach

The following diagram presents the main steps took place in the Equifax’s breach

On March 10, 2017, a new Apache Struts 2 vulnerability was published (CVE-2017-5638[7]). The exploitation of this vulnerability resulting with the ability of executing arbitrary commands on the vulnerable system.

From Equifax’s logs, it seems that on that day, unidentified individuals scanned Equifax’s public servers and determine that some servers (e.g. online dispute portal servers) are vulnerable to the above vulnerability. It is not known if the unidentified individuals executed commands, but it reported that no data was taken at that time.

According to Equifax, couple of months later, on May 13, 2017, another incident occurred resulting in unauthorized access to the online dispute portal.

From Equifax’s logs, it seems that once the attackers got execution privileges on the online dispute portal servers, the attackers began to harvest the servers for credentials and issued queries to other database servers to search for sensitive information. With these actions, the attackers were able to increase their foothold from 3 servers of the dispute portal, to 51 databases on unrelated to the online dispute portal.

Over about 76 days the attack took place, the attackers executed approximately 9,000 databases queries to retrieve PII information, executed multiple commands (e.g. credentials scraping, log cleansing, reconnaissance activities and more) and used standard encrypted web protocols to disguise the exfiltration as normal network traffic.


AppDefense and Equifax’s Breach

When analyzing the tasks performed by the attackers during the breach, different symptoms correspond with AppDefense approach of compute least privileged security model.


New Binary Detection

In order to perform actions like credential scrapping, network communication with remote database servers, exfiltration, the attackers would have needed to perform different weaponizing actions to get required tools onto the Equifax servers. The execution of those new unknown binaries would have been deviations from the known good behavior AppDefense keeps and thus the deviations would have generated high fidelity alarms. Moreover, AppDefense could have blocked the execution of such deviations which would have closed this attack vector.


New Execution Pattern Detection

In the report, it is not noted if the tools used by the attackers during the attack were downloaded to the servers or the attackers leveraged existing OS capabilities to create dedicated tools on demand (e.g. “fileless”,” living off the land” attacks[8] and similar to those documented under ATT&CK T1127[9]). The previous section discussed the situation of downloading tools to the attacked servers. In the case of fileless attacks, AppDefense addresses this attack vector by monitoring not only the executed binary, but the full execution command with its parameters. Using Machine Learning and statistical analysis of the execution parameters that invoked the process, AppDefense can recognizes an unknown execution pattern and stop such command from being executed.


New Network Behavior Detection

The report states the attackers performed at least three types of network activities. The first was using different lateral reconnaissance to find new targets (in the attack, 51 database servers from different services were breached). The second network activity was querying other servers to retrieve the PII data, and the last network activity type was the exfiltration of the gathered data out of Equifax’s network.

Like with process execution, AppDefense learns and keeps the “known good” network behavior for each allowed execution. This behavior holds data such as source, destination and protocol information. This means that each type of communication explained above, will trigger a new network behavior on the server which AppDefense will monitor and stop. Thus, activities like lateral reconnaissance, lateral movement, data gathering, and exfiltration are much more difficult for attackers to perform, will trigger alarms, and can be stopped.



Unlike other PII data breaches where changing passwords or issuing new credit card could resolve most of the risk, Equifax’s data breach effects will haunt us for many years. Although Equifax implemented multiple security controls in its network, attackers continue to find new ways to evade traditional security controls which primarily focus on “chasing bad” rather than “ensuring good”.

With the ability to define Who (Binary) can be executed, How (Execution Pattern) the execution will look like and define What (Network Behavior) communications this running process can perform, AppDefense managed to reach its fundamental approach for security of reducing attack surface by “ensuring good” versus “chasing bad”.


Barak Raz – Staff Security Researcher

Networking & Security 


Visit and learn how VMware delivers security in our products, solutions, cloud services, and across industries

Follow us on Twitter at @VMwareSecurity