Preexisting Trust: The New Gateway for Initial Access Threats

Meta: Attackers are exploiting trusted relationships in cloud environments. Learn how “preexisting trust”
became a top initial access vector and how to lock it down.

Cloud environments run on trust. Services trust each other to exchange data. Teams trust internal tools
to behave securely. Organisations trust vendors to deliver safe code.

But attackers have caught on, and now they’re targeting that trust to get in the door.

This briefing explores how preexisting trust relationships are becoming one of the most overlooked attack
surfaces in the cloud. Using real-world examples (including SolarWinds), we’ll unpack how these relationships
are exploited and what practical steps you can take to reduce your exposure.
‍

What Exactly Is “Preexisting Trust” in Cloud Infrastructure?

Preexisting trust is all the automatic “yeses” inside your cloud environment - the relationships that
are never questioned after setup. These include:

• Service-to-service API trust
  
• IAM roles or SSO connections across users and accounts
  
• Cross-cloud or hybrid federations
  

They make systems work smoothly, but they’re often invisible during security reviews. And when one trusted
entity is compromised, attackers don’t need to break in. They’re already inside.
‍

How Attackers Exploit Trust That’s Already There

Attackers don’t always break the door down. They just use a trusted key.

If a third-party service, internal tool, or federated identity is compromised, attackers can:

• Move laterally without detection
  
• Inherit broad permissions
  
• Operate under the radar of traditional alerting systems

Real-World Example:

Scenario: Your app trusts a vendor via API token.
Risk: That token is stolen.
Outcome: Authenticated requests come in from the attacker. No brute force required.

The SolarWinds Attack: A Case Study in Broken Trust

In 2020, SolarWinds showed the devastating power of misused trust.

Attackers inserted malware into the company’s software updates. Because the update came through a
‍trusted, signed channel, it wasn’t questioned, and was pushed to 18,000+ customers.

Once inside, attackers:

• Escalated privileges
• Pivoted across networks
• Exfiltrated sensitive data from government and enterprise systems

Lesson: Even widely trusted vendors can become threat vectors.

What You Can Do About It

Strategy 1: Make Trust Earned, Not Permanent

Trust should decay over time - just like passwords.

• Revalidate connections quarterly
  
• Use mTLS or signed tokens
• Monitor trusted services like you would unknown traffic

Strategy 2: Minimise What Trust Can Access

Least privilege isn’t just for users. Trusted services need it too.

• Scope access to what’s strictly necessary
  
• Run regular access audits
• Use conditional policies for time, device, or location

‍

Final Word: Trust Isn’t the Problem. Blind Trust Is.

Cloud systems need trust to work, but that trust must be earned, scoped, monitored, and revoked when necessary.

If attackers are using your trusted pathways against you, that’s not a tool problem. It's a trust hygiene problem.

Build trust like you build security: deliberately, temporarily, and with guardrails.

‍