MITRE ATT&CK vulnerability series: Trusted relationship
What many who are not information security-savvy may think is that the attack surface of an organization is confined to simply the organization network. Unfortunately, this is not true. In reality, organizations often engage in business with third-party partners that exposes the organization to possible exploitation.
This article will detail what the trusted relationship attack is, some real-world examples of this attack, how to detect trusted relationship attacks and tips for how to mitigate trusted relationship attacks.
What is the trusted relationship attack?
Attackers can breach or leverage organizations that let third-party partners have access to their network. It is customary in some industries and businesses to grant their third-party partners access to network resources in the course of their business relationship. Examples of third parties that would be granted this access include IT contractors, managed service/security providers and infrastructure service contractors.
It is this valid account (based upon a trusted relationship) used by the third-party partner that may be lost or otherwise compromised, thereby opening up the organization to attackers’ prying hands.
Sometimes, third-party access is granted via Virtual Private Network (VPN) or private network circuit. Logistically speaking, this expands the organization’s attack surface boundary to all of their third-party partners that have this elevated access.
MITRE and ATT&CK
MITRE is a not-for-profit corporation dedicated to solving problems for a safer world. Beginning as a systems engineering company in 1958, MITRE has added new technical and organization capabilities to its knowledge base — including cybersecurity.
To this end, MITRE released the MITRE ATT&CK list as a globally accessible knowledge base of adversary techniques and tactics based upon real-world observations. This information can then be used as the basis for the development of threat models and methodologies for cybersecurity product/service community, private sector and government use.
In 2013, Target fell victim to a trusted relationship attack where attackers used Target network credentials used by a heating and ventilation company that was servicing a Target store. These credentials allowed the attackers to pivot into Target’s network with ease with the same access that the third-party partner had.
MenuPass is a China-based threat group that targeted IT MSPs, mining companies, manufacturing companies and a university. This group used the credentials granted to these companies to access victim resources in a major campaign that ran from 2016 to 2017.
How to detect the trusted relationship attack
The first step to detecting a trusted relationship attack is to create a threat model. Threat models should spell out everywhere trust is granted between entities. These relationships with third-party partners can then be audited.
With a threat model implemented, the best way (and possibly the only proactive way) is to monitor the usage of second-party, third-party and trusted entities. The trust model-based monitoring should use frequent audits to get a reasonably real-time picture of how these trusted parties are using the priceless credentials that you granted to them.
Nobody likes it when their trust has been violated, and without a doubt, this extends to the world of enterprise. However, unlike trust between two individuals that many times is broken without leaving a trace, business relationships that end up in credentials being handed over are often documented in relatively great detail. With this said (and at least a shred of hope extended to you), below are some mitigation methods that will help prevent future trusted relationship attacks.
My number 1 mitigation tip is to be proactive on making that threat model mentioned above. This is the best way to manage trusted relationships and will give you the best idea of how these credentials you gave out are being used. Monitoring is key here.
Network segmentation and isolation
Systems with sensitive information, especially systems that trusted entities have no business accessing, should be isolated with a liberal sprinkling of network segmentation.
Think of it as like how a SCADA system should be isolated from the general organization network as much as practicable. When systems with sensitive information are isolated, this shrinks your attack surface to a more manageable size with less risk to your information security environment.
Ensure that your organization uses a tight authentication policy when granting credentials to trusted entities. Make sure that password credentials are changed regularly. You may want to also add another layer of authentication, such as two-factor authentication, to better ensure that the credentials will not be compromised — or at the very least will minimize the time available to abuse said credentials.
Vet trusted entity security policies
The last measure you can take to mitigate a trusted relationship attack is to vet the security policies of the trusted entities that you have granted credentials to. Make sure that their security policies properly cover how client network credentials are to be handled.
As a further measure, if you have not yet established a trusted relationship with an entity, require that your organization review a possible trusted entity’s security policies as a matter of course when onboarding one of these entities. Sometimes just trusting one wrong entity is the difference between breach and safety.
It is a fact of life that trusted relationships arise in the business/enterprise world, requiring one entity to have access credentials to another entity’s network and resources. Like other trusted relationships in life, a breach of this trust can cause serious damage. By following the tips above for how to detect and mitigate trusted relationship attacks, your organization will be far better positioned to minimize a trusted relationship attack if not stop it in its tracks.