It’s widely agreed that delving into information security incidents to understand and address root causes is a valuable process [211]. Yet, research indicates a considerable number of organizations may overlook this potential learning opportunity, as they tend to concentrate solely on rectifying immediate issues caused by such incidents [201]. Most analyses of cyberattacks focus on a single cause, such as a phishing email, a patch that had not been applied on time, etc., and therefore make it seem that the root cause of an incident is a simple problem arising perhaps from one person’s error or negligence [202]. Yet, the reality is often more complex. Security incidents typically involve a series of events, not just one isolated issue. Acknowledging this series of events can provide a fuller picture of how compromises occur, which could, in turn, guide the development of better protective measures.
In this section, we delve into the details of a cyberattack that the company Equifax experienced. We will analyze the steps employed by the attackers to gain a foothold into the organization network, escalate their privileges to access confidential data, and eventually exfiltrate valuable information, which caused significant damage to the existing systems and disrupted ongoing business operations. By conducting this in-depth review, we aim to evaluate the potential impact of a theoretical Zero Trust strategy-aided security architecture. Specifically, we’ll examine how effectively such a model, if it had been defined and implemented, could have been utilized to contain and mitigate the effects of the attack.
Overview
Equifax, Figure 1, is one of the world’s largest private credit-tracking firms [202]. The company’s business is based on detailed consumer and business information derived from organizations such as banks, thrifts, credit unions, and many other institutions and public record providers [219] [212]. The information includes historical data about credit repayments, rent payments, employment, insurance claims, arrests, bankruptcies, check writing, and account management [211]. According to Equifax’s 2016 annual report, “the company organizes, assimilates, and analyzes data on more than 820 million consumers and more than 91 million businesses worldwide.”[203]. The enormous amount of sensitive information collected by CRAs makes them lucrative targets for cybercriminals.
On July 29, 2017, Equifax identified, and a day later confirmed, a cyberattack on its Automated Consumer Interview System (ACIS). The attack came to light after Equifax’s IT team updated a secure sockets layer (SSL) certificate on the SSL visibility appliance system that monitored the encrypted inbound and outbound network traffic between Equifax’s systems, including ACIS, and the internet [202]. The SSL certificates had expired nine months earlier, in November 2016 — which indicates a significant period of unmonitored network traffic. After updating the certificate, Equifax employees detected suspicious internet traffic exiting ACIS that contained image files related to consumer credit investigations [202]. They traced the traffic to an IP address in China — a country where Equifax did not operate [202]. After blocking the IP address, Equifax noticed suspicious traffic from a second IP address owned by a German internet service provider (ISP) and leased to a Chinese ISP [202]. As a consequence of these discoveries, Equifax decided to shut down ACIS temporarily. Further analysis revealed that the suspicious traffic resulted from a successful cyberattack on ACIS that started on May 13, 2017. The attackers gained access to ACIS and databases containing consumers’ personally identifiable information (PII) and then exfiltrated sensitive information over a period of 76 days before the attack was detected [202]. The timeline of the key events associated with the Equifax cybersecurity incident is shown in Figure 61.
On September 7, 2017, Equifax publicly announced a cybersecurity incident, potentially impacting 143 million U.S. consumers whose names, social security numbers (SSNs), birth dates, addresses, and driver’s license numbers were compromised [213]. Later, Equifax concluded that the actual number of affected consumers was approximately 148 million [202].
Before the incident, on March 8, 2017, the United States Computer Emergency Readiness Team (US-CERT) had issued a public notification about the vulnerability. This vulnerability was in the open-source Apache Struts 2 web application framework, a tool used by Equifax and thousands of other websites for creating enterprise Java applications. The vulnerability would allow an attacker to remotely execute commands on affected systems [202] [216]. This vulnerability was present in ACIS [214] and was exploited by the attackers to gain access to the Equifax network [205] [215]. Interestingly, just a few days later on March 11, 2017, a working exploit demonstrating how to attack these vulnerable websites was publicly posted on GitHub [204].”
Our Approach
We used the Cyber Safety method of analysis, which is inspired by causal analysis using system theory (CAST), which in turn was developed to determine the cause of industrial accidents [205]. The following describes the phases of our analysis.
- Action Tracing: We methodically trace the actions taken by the attackers. This allows us to reconstruct the sequence of events and understand the vulnerabilities that were exploited.
- Missing Security Control Measures Assessment: In this phase, we identify the security measures that were lacking in Equifax at the time of the breach. We do this concurrently with the action tracing, as we believe it will help us better conceptualize the aftermath of the breach.
- Organization Safety Control Hierarchy Evaluation: Next, we assess Equifax’s safety and security control infrastructure. We probe into the reasons behind its inability to prevent and contain lateral movements by the attackers within the network and how this further escalated the damage.
- Discussion: Finally, we highlight our findings from the breach to understand how embracing organization-wide security strategy based on Zero Trust principles could have proven effective in thwarting the attack.
The information about the Equifax organization, internal infrastructure, and the security measures present at the time of the breach predominantly relies on official documents detailing the Equifax cybersecurity incident, such as reports from the United States Senate and the House of Representatives Committee on Oversight and Government [207], as well as the complaint filed by the State of Indiana [208].
High-level chain of events [209], Figure 62 that occurred are:
- The company was initially hacked via a consumer complaint web portal, with the attackers using a known vulnerability that should have been patched but, due to failures in Equifax’s internal processes, wasn’t (Steps 1 and 2, illustrated in Figure 61 )
- The attackers were able to move laterally from the web portal to other servers and were able to find usernames and passwords stored that then allowed them to escalate their privileges and access further systems. (Step 3 )
- The attackers pulled data out of the network in encrypted form and undetected (Steps 4 and 5 ).
- Action Tracing
Here, we systematically follow the likely paths the attackers took by examining the Cyber Kill Chain stages, Figure 63, and demonstrating how the attackers exploited vulnerabilities, excessive privileges, and misconfigurations within the Equifax network, ultimately leading to the exfiltration of sensitive data.
→ Stage 1: Reconnaissance
In this information/intelligence gathering step, the attacker identified and selected Equifax as a target. This initial stage involved the meticulous gathering of information about the targeted entity and identifying a flaw that can be exploited [63].
We hypothesize that the attackers could have used open source intelligence (OSINT) techniques to identify that Equifax’s ACIS system used a susceptible version of Apache Struts 2 or the threat actors investigated specific network systems, searching for banners and versions that Equifax systems most likely used.
To this day, it is unclear whether ACIS was revealing the presence of Apache Struts 2 in its environment and what specific approach the attackers used for reconnaissance. However, it was discovered that some websites using the vulnerable version of Apache Struts 2 could be easily found through “Google dorking.” [202] [222]. So, it is possible the attackers have identified the range of IP addresses belonging to Equifax, they conducted a network scan, sending requests to each IP address to see if it responds. This could have allowed them to identify the running systems and open ports.
** Missing Security Control Measures **
Equifax should have ensured that ACIS did not reveal information about the software that they use, their versions, or its technical details and should have prevented sensitive information from being indexed by search engines and revealed by active scanning software for banner grabbing.
→ Stage 2: Weaponization
One of the attacker’s choice of weapon, at least for the initial exploit, happened to be the code segment that, when re-constructed properly, leads to remote code execution (RCE) in the Apache Struts 2 framework that Equifax’s ACIS system was using [215].
** Missing Security Control Measures **
This phase occurred outside of Equifax’s systems, as the Apache Struts 2 used by the ACIS application were not internally developed, so the company could not have deployed safety constraints to counter weaponization to this supply chain application vulnerability [202].
However, one might argue that had stronger governance practices been in place, such as IT asset inventory ownership [228] and patch management strategies, the attack might have been prevented. A delayed response to a known vulnerability in the software, potentially due to organizational shortcomings, created an exploitable window for the attackers.
→ Stage 3: Delivery
After constructing malicious code that could be used to remotely access Equifax’s system, The exploit is delivered to the victim’s system. According to Apache, the vulnerability existed in the Jakarta Multipart parser [215] [219]. An ‘Exception’ is thrown when an invalid value is placed in the ‘Content-Type’ header. This exception is used to display the error to the user. The attackers exploited this vulnerability to escape the data scope into the execution scope through the ‘Content-Type’ header, where the malicious code execution becomes possible. For instance, If attackers sent HTTP requests with malicious code tucked into the ‘Content-Type’ header, the application Apache Struts 2 could be tricked into executing that code and opening up the system Struts was running on to further intrusion. Attackers exploited this vulnerability to gain access to Equifax’s online dispute portal.
** Missing Security Control Measures **
A safety constraint to counter this type of vulnerability could have been to use a web application firewall (WAF). According to Memon’s analysis [221], even an open-source WAF (e.g., ModSecurity) could have protected Equifax against the attack by detecting the malicious strings passed in the HTTP headers and blocking such traffic [202]. However, because there is no reference to a WAF either in the reports we used as our main source of information or in other publicly available documents, we concluded that ACIS was not protected by a WAF. The application ACIS was the only gatekeeper left open to accepting malicious requests at the time of the attack. Once the remote code execution vulnerability was exploited, the attacker was able to access data unfettered by additional access controls. Interestingly, the other organizations had WAF in place configured to block attacks using the Apache Struts 2 vulnerability [202].
→ Stage 4: Exploitation
During this phase, the malicious HTTP request sent to ACIS exploited the vulnerability in Apache Struts 2 led to the remote execution of unauthorized code delivered in the payload.
Below, Figure 65 is an example of a valid remote code execution command injected as payload, a simple probing attack that checks to see if a system is vulnerable by executing a simple Linux-based command, ‘whoami,’ to see what user the service is running [223].
Figure 66, seen below, presents another example of the attack that is similar to the previous example that downloads a malicious payload. The difference with this particular example is the attempted persistence. The adversary attempts to copy the file to a benign directory and then ensures that both the executable runs and that the firewall service will be disabled when the system boots [223].
** Missing Security Control Measures **
At the time of the incident, Equifax had implemented vulnerability identification and patching mechanisms [207] However, they were not effectively utilized. Later, in our analysis of shortcomings in phase 3 on page 126, we explain why these safety elements failed.
→ Stage 5: Installation
In the installation phase, a remote access tool is deployed on the victim’s server or computer to establish permanent presence inside the network and spread the attack [224]. Since the method of deployment of the remote access tool (RAT) was not clearly detailed in public reports [202] [207] [208], we hypothesize here that the attackers could have deployed their remote access tool (RAT) as part of the malicious HTTP request or could have generated a valid exploit command that would download a RAT tool from a server that is under the attackers’ control.
Later, the attackers could have conducted another reconnaissance search on the online dispute portal to obtain valid credentials for database servers. Investigation revealed that other Equifax systems permitted access to their sensitive data through ACIS, which meant that the organization trusted ACIS to access sensitive assets, which in return could have allowed the attackers to gain access to unencrypted application credentials for other sensitive Equifax databases, which further stored confidential information and personally identifiable information [206] [207].
** Missing Security Control Measures **
- Authentication: Two major authentication issues were discovered in ACIS and other Equifax systems. The first was the use of weak passwords for privileged accounts with direct access without supplementary Multi-Factor Authentication (MFA). For instance, one of the databases accessed by the attackers was protected with a four lower-case letter password, which matched the database’s name [202][225]. The second was Equifax’s improper authentication practice of storing the application credentials in an unencrypted format in a file that could be shared [225]. During his appearance before the U.S. House of Representatives for an investigative hearing, Russ Ayres, who was serving as Equifax’s interim chief security officer at the time, stated the belief that if Equifax had more effectively restricted access to sensitive files across its network, it’s possible that the attackers might not have been able to locate the stored application credentials [202]. These credentials were ultimately used by the attackers to gain access to sensitive databases outside the ACIS environment.
- Least Privilege Access: The platform ACIS was given excessive permissions, allowing it to access data in systems beyond what was required for its operations. Based on reports [202] [206] [207], ACIS needed access to only three databases to function effectively. However, it was unnecessarily connected to many more, enabling it to access an array of information that it didn’t need.
- Micro-segmentation: According to a report by the U.S. House of Representatives [207], there was an absence of proper micro-segmentation involving the ACIS application within the Equifax network. ACIS was not appropriately isolated and therefore had access to, and could potentially interact with other unrelated databases. This means that Equifax chose to use a typical web application architecture without defense in depth. For instance, Sun Solaris [227], the platform that hosts ACIS, used a shared file system that spans all its systems, permitting access to administrative files system-wide [202]. The application had read and write privileges to the underlying database from the client-facing service [218], and the complete compromise of the application enabled the attacker to obtain unfettered access to the protected data. Conceptually, it would be expected to design the internet-facing applications submitting requests to a more sensitive server, where the system is architecturally designed in a layered approach [218]. This lack of segmentation in their infrastructure further allowed the possibility of attackers moving laterally throughout Equifax’s networks, accessing systems far beyond just ACIS.
→ Stage 6: Command and Control
The attackers successfully created a communication link between the compromised systems in the Equifax network, including ACIS and other databases, and their own command-and-control servers [224]. This linkage allowed them to further remotely manipulate the infiltrated systems.
** Missing Security Control Measures **
The intrusion detection and prevention systems (IDS/IPS) failed to identify and block the ongoing malicious traffic. The technical reason for this failure was that the SSL certificates necessary to analyze the encrypted network traffic entering and leaving Equifax’s systems had expired [202]. This made it impossible for the IDS/IPS to ‘read’ the encrypted traffic and consequently identify suspicious activities.
Had the SSL certificates been up-to-date, it would have been possible to restrict malicious outbound traffic and connections to unfamiliar domains at the moment of detection. Such restrictions could have helped contain the attack. We will delve deeper into the reasons for this failure later on, as we discuss the problems within Equifax’s hierarchical control structure on page 126.
→ Stage 7: Actions on Objective
In this final phase, the attackers pinpointed sensitive data of significant value, potentially for ransom purposes, and proceeded to extract this confidential information stealthily from the system.
** Missing Security Measures **
- Encryption: The absence of encryption and key management left data vulnerable, even in the event of unauthorized system access. Most probably, had the sensitive personally identifiable information (PII) stored within Equifax’s databases been encrypted, the impact of the breach could have been greatly reduced if not altogether contained. It appears from the evidence that Equifax consciously opted not to use encryption in its security architecture, as none of the breached systems exhibited any sign of data protection mechanisms [226].
- Limiting the data retained: Equifax’s systems were not configured to restrict the volume of stored data to only what was essential. This was highlighted by the former Chief Information Officer at Equifax, who openly questioned the need for retaining such an extensive amount of data within their systems [202].
- Absence of Data Loss Prevention (DLP): DLP is a security measure designed to detect and prevent unauthorized access or transmission of sensitive data, such as credit card information or personally identifiable information. This could have identified and stopped the mass transfer of sensitive data out of the network. Surprisingly, despite being recommended by the Payment Card Industry Data Security Standard, Equifax did not have a DLP system in place. As a result, it’s estimated that the attackers stole at least 14 Gb of data from Equifax’s databases over 76 days undetected [202] [228].
The attackers succeeded at all seven of the phases described above. The security measures that should have been enforced through the system design and architecture did not exist or failed to prevent them.
3. Organization Safety Control Hierarchy Evaluation
After mapping out the most likely actions the attacker took and identifying the absence of certain security measures, we now try to understand the consequences of not having adequate security-based control principles in place. To do this, we review our findings by considering the organizational structure and the timeframe during which Equifax’s systems were developed and implemented. Essentially, we investigate the reasons for the organization’s inability to contain unauthorized access by the attackers and discuss how the organizational shortcomings contributed to the attack.
Equifax’s safety control infrastructure has four levels, each representing an area of responsibility and supervision within the company [202]. These levels form a hierarchy that is meant to safeguard the company from security risks, Figure 67. However, an exhaustive understanding of this intricate hierarchy in Figure 36 is not necessary. Our primary focus will be on the first three levels, as these are the areas where operational, managerial, and strategic decisions take place, directly impacting the company’s overall security posture and contributing to the failures that resulted in the massive breach. Level 4 is beyond the scope of our analysis and involves entities like JP Morgan Chase, tasked with the role of a contractor in enforcing certain compliance measures [202].
Level 1 — Intrusion Detection and Prevention Process
Level 2 — IT and Information Security (ISec) Teams
Level 3 — Management and Board of Directors
Level 4 — Federal Agencies and State Enforcement Authorities
Level 1 — Intrusion Detection and Prevention Process (IDPP)
Equifax’s IDPP was designed to monitor and analyze inbound and outbound internet traffic to identify and block malicious activities. Figure 68 depicts what we believe is the most likely architecture of IDS/ IPS at the time of the breach [202]. This includes an intrusion detection component powered by an open-source traffic analyzer called Snort, which identifies suspicious activities in the network traffic and prohibits them or raises an alert. The architecture also includes an SSL visibility appliance system, which intercepts the traffic, decrypts it, analyzes it, and then re-encrypts it, and passes the traffic either to servers in case of inbound traffic or to the internet for outbound traffic.
As mentioned in the missing security measures of Stage 6: Command and Control, the IDS/IPS fell short due to two main issues. First, SSL certificates crucial for decrypting traffic for analysis expired in November 2016, preventing the IDPP from functioning as intended [207]. Efforts to deploy an automated SSL certificate management tool were underway but hadn’t been completed at the time of the incident [202]. This left the system unable to properly scrutinize traffic, allowing malicious traffic to pass unchecked. Secondly, the system was not equipped with an alert mechanism to notify the ISec team when IDS/IPS was non-functional. The system was misconfigured to bypass traffic if decryption failed. This oversight resulted in the system being inoperable for nearly nine months without detection.
Level 2 — IT and Information Security (ISec) Teams
This level encompassed the functions of Equifax’s IT and ISec teams, whose responsibilities included the detection, reporting, and mitigation of vulnerabilities, along with ensuring regulatory compliance. Various shortcomings were apparent across these crucial areas:
- Identification of vulnerabilities: The ISec team received security alerts from US-CERT, and the team routinely conducted scans for vulnerabilities on their internet-exposed systems [202], but due to limited understanding of Apache Struts 2 and a scan focus that was confined to the root directory resulted in false positives. Consequently, the team failed to detect the presence of the Apache Struts 2 CVE-2017–5638 vulnerability within the ACIS system.
- Remediation of vulnerabilities: The reactive design of the patching process meant that when identification and notification mechanisms failed, patching was not triggered [202]. The team didn’t prioritize a recommended upgrade to a proactive patching process, leading to a vulnerable system.
Level 3 — Management and Board of Directors
The third level is devoted to Equifax’s management and board of directors, specifically in guiding the efforts of the IT and ISec teams, overseeing the operations, and defining the priorities for the IT and ISec teams. However, they did not address known issues in Level 2 safety controls, despite having full awareness of them [202]. Understanding the flaws in the patching process and the risks associated with the use of outdated Sun servers, the necessary upgrades and migrations were not prioritized either [209][211]. The management also overlooked the importance of automating the Secure Sockets Layer (SSL) update process, thus leaving it manual and susceptible to human error [209]. On the compliance front, the decision was made to exclude the ACIS system from the compliance scope, even though it was understood that this system needed to meet specific regulatory standards such as the Payment Card Industry Data Security Standard (PCI DSS), which it was not capable of at the time [202].
Equifax’s internal management and audit team, responsible for evaluating the state of Level 2 safety controls and the associated risks, also demonstrated considerable inadequacies [216]. While they successfully identified problems in the patching and configuration management measures, they did not ensure that these weaknesses were adequately addressed, indicating a communication breakdown.
Equifax’s board of directors had the critical responsibility of setting the company’s overall risk level. However, they also fell short in a number of key areas. They failed to define a clear risk level, despite the company experiencing multiple data breaches in the past [209] [229] culminating in financial losses far beyond an acceptable threshold. In fact, the rules they appeared to be approving for executive compensation were focused exclusively on business growth [202]. This focus led to a significant oversight, as it neglected to consider the importance of managing information security risks.
4. Discussion
Designing and implementing a strong security system requires deep knowledge of what needs protection, who might pose a threat, and how severe such a threat could be. This understanding is vital; without it, it’s very difficult to create, manage, or make confident statements regarding the security level of any system. This is why, to build a secure system, there needs to be a detailed risk assessment carried out. This assessment would help pinpoint all the possible threats that the system must be built to handle and also reveal the most vulnerable points, referred to as the ‘weakest links’ within the security infrastructure.
The fundamental objective that the assessment aims for is ultimately to safeguard data. Data is the lifeblood of any organization that employs an array of security systems and measures for its protection. The Equifax data breach is a prime example of the necessity of a comprehensive security strategy within an organization’s business architecture when it comes to data protection. Equifax’s lack of clear risk strategy and communication misalignment, paired with over-reliance on a single detection measure (IPS/IDS), led to a series of vulnerabilities. Attackers exploited these to gain unauthorized access to sensitive data used for business operations. Inadequate network segmentation further enabled lateral movement and privilege escalation, facilitating access and exfiltration of confidential information.
After examining the breach and pinpointing the absence of crucial security measures and organizational shortcomings, we’ve recognized the significant potential of the Zero Trust model in enhancing organizational security. The Zero Trust model incorporates a layered, defense-in-depth architecture. It emphasizes stringent authentication, least-privilege and just-in-time access control policies, proper network segmentation, encryption both in transit and at rest, and granular policy enforcement and governance, all of which were missing in Equifax’s security approach. Moreover, continuous monitoring and analytics, another essential component of Zero Trust, would have facilitated prompt response and remediation in the face of the compromise. We are convinced that, had Equifax integrated a Zero Trust approach into their security strategy and controls, the impact of the attack could have been either entirely prevented or, at the very least, significantly contained and its consequences mitigated.
** End ***
References
- [63] “Breaking The Kill Chain: A Defensive Approach,” www.youtube.com, 2019. Available: https://www.youtube.com/watch?v=II91fiUax2g&ab_channel=TheCISOPerspective.
- [201]M.-D. Mclaughlin and J. Gogan, ‘Challenges and best practices in information security management’, MIS Quarterly Executive, vol. 17, pp. 237–262, 01 2018.
- [202] I. Kabanov and S. Madnick, ‘Applying the Lessons from the Equifax Cybersecurity Incident to Build a Better Defense’, MIS Quarterly Executive, vol. 20, p. 4, 06 2021.
- [203]“Investor Relations,” Equifax Inc., Aug. 15, 2023. Available: https://investor.equifax.com/~/media/Files/E/.
- [205] N. G. Leveson, Engineering a Safer World. The MIT Press, 2012. doi: https://doi.org/10.7551/mitpress/8179.001.0001
- [206]F. Rietta , “Equifax Missed Defense in Depth, Allowing a Massive Data Breach,” rietta.com, Sep. 18, 2017. Available: https://rietta.com/blog/equifax-defense-in-depth/
[207]“U.S. House of Representatives Committee on Oversight and Government Reform the Equifax Data Breach Majority Staff Report 115th Congress,” 2018. Available: https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf - [208]“State of Indiana Jurisdiction on Equifax,” United States Government. Available: https://calendarmedia.blob.core.windows.net/assets/95a6cbb4-1887-4b1d-8a8d-672d781015bf.pdf
- [209] J. Fruhlinger, “Equifax Data Breach FAQ: What happened, Who Was affected, What Was the impact?,” CSO Online, 2020. Available:
- [211] I. Miyashiro, “Case Study: Equifax Data Breach,” Sevenpillarsinstitute.org, Apr. 30, 2021. Available: https://sevenpillarsinstitute.org/case-study-equifax-data-breach/
- [212] T. Pileggi, “Equifax Data Breach Analysis,” www.linkedin.com, Apr. 28, 2018. Available: https://www.google.com/url?q=https://www.linkedin.com/pulse/equifax-data-breach-analysis-teresita-c-liebel&sa=D&source=docs&ust=1692447506256755&usg=AOvVaw1PikJATPkiJJfIyeqnl9tl.
- [213] R. Portman and T. Carper, “HOW EQUIFAX NEGLECTED CYBERSECURITY AND SUFFERED a DEVASTATING DATA BREACH STAFF REPORT PERMANENT SUBCOMMITTEE ON INVESTIGATIONS UNITED STATES SENATE,” Mar. 2019. Available: https://www.hsgac.senate.gov/wp-content/uploads/imo/media/doc/FINAL%20Equifax%20Report.pdf
- [215] Lucideus, “Exploiting Apache Struts2 CVE-2017–5638 | Lucideus Research,” Medium, Oct. 26, 2018. Available: https://medium.com/@lucideus/exploiting-apache-struts2-cve-2017-5638-lucideus-research-83adb9490ede
- [216]J. Thomas, “A Case Study Analysis of the Equifax Data Breach,” ResearchGate, Dec. 13, 2019. Available: https://www.researchgate.net/publication/337916068_A_Case_Study_Analysis_of_the_Equifax_Data_Breach_1_A_Case_Study_Analysis_of_the_Equifax_Data_Breach
- [218] J. Ludin, “Equifax’s Story: the Risks of Lax Security,” SecureW2, May 14, 2019. Available: https://www.securew2.com/blog/equifax
- [219] L. Lenart, “S2–045 — Apache Struts 2 Wiki — Apache Software Foundation,” cwiki.apache.org, Mar. 19, 2017. Available: https://cwiki.apache.org/confluence/display/WW/S2-045
- [220] V. Woo, “Apache Struts 2.3.5 < 2.3.31 / 2.5 < 2.5.10 — Remote Code Execution,” Exploit Database, Mar. 07, 2017. Available: https://www.exploit-db.com/exploits/41570
- [221] F. Memon , “Using ModSecurity to Virtually Patch Apache Struts CVE-2017–5638,” NGINX, Jan. 22, 2018. Available: https://www.nginx.com/blog/modsecurity-apache-struts-cve-2017-5638/
- [222] R. Awati and I. Wigmore, “What is a Google dork query and how to protect yourself?,” WhatIs.com. Available: https://www.techtarget.com/whatis/definition/Google-dork-query
- [223] N. Biasini, “Content-Type: Malicious - New Apache Struts2 0-day under Attack,” Cisco Talos Blog, Mar. 08, 2017. Available: https://blog.talosintelligence.com/apache-0-day-exploited/.
- [224] “Example Flows — Attack Flow v2.0.1 documentation,” center-for-threat-informed-defense.github.io. Available: https://center-for-threat-informed-defense.github.io/attack-flow/example_flows/.
- [225]T. Franck, “Equifax Used the Word ‘admin’ for the Login and Password of a Database,” CNBC, Sep. 14, 2017. Available: https://www.cnbc.com/2017/09/14/equifax-used-admin-for-the-login-and-password-of-a-non-us-database.html
- [226] United States Government Accountability Office, “DATA PROTECTION Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach Report to Congressional Requesters United States Government Accountability Office,” Aug. 2018. Available: https://www.gao.gov/assets/gao-18-559.pdf
- [228] T. Doan, “The Role of Asset Ownership in the Equifax Breach,” runZero, Mar. 13, 2023. Available: https://www.runzero.com/blog/role-of-asset-ownership-in-the-equifax-breach/
- [229] T. Brewster, “A Brief History of Equifax Security Fails,” Forbes, Sep. 08, 2017. Available: https://www.forbes.com/sites/thomasbrewster/2017/09/08/equifax-data-breach-history/
