A few months ago, IONIX approached EA with an ethical disclosure of several security vulnerabilities. EA was informed of the following during that disclosure: that via a trusted third-party infrastructure it was possible to takeover some of their assets, issue valid certificates, send and read valid emails and abuse these assets to run social engineering attacks—all without being visible to their security tools.

EA recently suffered a significant breach, and we are continuing to learn the details of the attack as they are reported. Currently, it appears EA was breached due to a social engineering attack. According to Vice, a security team member believed that a series of communications that occurred over a third-party infrastructure, Slack, were valid and should be inherently trusted because of the environment in which the communications occurred.

In this blog, I’ll share a few common abuse scenarios that can be executed via similar “trusted” third-party infrastructures. These scenarios share two common traits: (i) they’re based on infrastructure supply-chain vulnerabilities and (ii) these vulnerabilities are used to establish trust between the attackers and employees of the organization, which can then lead to further escalation of the attack.

We cannot definitively state that these types of attacks occurred with EA, however, we these attacks occurring on a daily basis for our customers. We hope that sharing these use cases anonymously will encourage organizations to take steps to secure their infrastructure supply-chain. Below are two of the common abuses we see in the wild.

Infrastructure Supply-Chain Attacks

Infrastructure supply-chain attacks abuse security issues in assets that are not owned by the organization, but rather, belong to an external vendor of the organization. Hackers seek to leverage the relationship between the organization and the vendor as a path to attack the organization indirectly. Abuse of a vendor can be done in multiple ways. In software supply-chain attacks (e.g., the SolarWinds breach), the hackers manipulated trusted software components to attack organizations that use the software component. In infrastructure supply-chain attacks, the hackers abuse IT infrastructures that are external to the organization, but the organization is using. These infrastructures include cloud infrastructures, web, mail, DNS, application servers and many others.

Because these infrastructures exist outside the organization, there is very little security oversight by the enterprise—which makes them even more appealing. The hackers intent is to steal data directly from the third-party infrastructure or abuse and leverage the infrastructure without penetrating the organization. This makes infrastructure supply-chain attacks very difficult to detect, and based on our global monitoring data, hackers are increasingly using this approach.

Attackers often initiate their attack by seeking to gain privileged credentials which might allow them to expand their access. Starting with the Infrastructure supply-chain is one way of achieving that goal. This was the nature of our disclosure to EA.

Web-Based Infrastructure Abuse

When hackers take control of the infrastructure to which a domain owned by the organization points to, hackers can create a spoofed version of a web application that will appear valid and trusted to the organization’s employees and customers. This goes far beyond a typo-squatted version of the site, because it’s based on a legitimate domain and can even be granted valid certificates, the malicious site will be, for all intents and purposes, a valid site, and will bypass most if not all security scans.

In this example, an employee/customer/supplier of the enterprise would receive a valid, secure (HTTPS) URL to a web portal of the enterprise. Since the site appears valid, users would login as usual and nothing would indicate something was wrong. However, because the site is a spoofed site, hackers will receive the login credentials, and any other data the user inputs on the site.

All a hacker needs to do is wait for a privileged user to enter their credentials and they can escalate their attack against the organization.

Email Infrastructure Abuse

Many organizations rely on external mail servers for many of their domains. We see enterprises with dozens or even hundreds of external mail-servers, serving the organization’s different domains. When hackers take over one of these, traditional security tools provide no visibility of the incident (external servers). Even more devastating, security teams have no visibility of the abuse conducted by the hackers who are able read and send emails under the organization’s legitimate domains.

An example of leveraging an abused email server might be:

• Receiving an email from the security team of a customer to fill a security questionnaire to understand your exposure to security breach.
• Receiving an email from an HR representative to register for a mandatory online HR course.

In each of these cases, the email is from a legitimate and valid domain that belongs to the relevant organization. This approach is not your basic spoofing that relies on domains that try to look legitimate—these emails, from the email infrastructure sense, are legitimate. Your staff may be well trained to spot fishy emails, but that training could go out the window when everything appears valid. This is the unique and devastating aspect of an attack that preys on your employee’s trust in the infrastructure. Once they feel confident that the context of their conversation is secure, they can be easily convinced to give away the keys to the castle.

Summary

Hackers are increasingly preferring attacks via infrastructure supply-chain paths because they provide relative anonymity and significant rewards. The recent EA attack is a wakeup call for enterprises to consider how much trust they, and their employees, put in the infrastructures that are operated outside their security perimeter. The hackers are already far ahead in this race.

Protecting your external attack surface, which includes the organizations within your infrastructure supply chain, is not an impossible task. IONIX’s attack surface management platform was developed to identify the vulnerabilities that exist in these supply chains. I invite you to request your complimentary discovery of your attack surface risks.