Post

Hunting Initial Access Part 2: Supply Chain and Trusted Relationships

Detecting initial access through supply chain compromise and abuse of trusted third-party access, the hardest foothold to hunt for.

Hunting Initial Access Part 2: Supply Chain and Trusted Relationships

Supply-chain and trusted-relationship risk connected through adversary infrastructure capability and victim

An attacker doesn’t need to breach your perimeter at all if they can breach someone you already trust and let that trust do the work for them. Supply chain and trusted relationship attacks are, in my experience, the single hardest initial access category to hunt for, precisely because the access involved is legitimate, expected, and often invisible to controls built around the assumption that threats come from outside a trust boundary rather than through it.

Why This Category Breaks Normal Detection Logic

Most security tooling is built around a fairly clean assumption: external is suspicious, internal or trusted is not. Supply chain attacks exploit exactly that assumption. A compromised software update from a legitimate vendor, delivered through the vendor’s own legitimate update mechanism, doesn’t look like an attack to a system designed to trust that mechanism—it looks like a routine, expected update. This is what makes this category genuinely different from the other initial access techniques covered previously, and why it demands its own dedicated hunting approach rather than an extension of standard perimeter-focused hunts.

Hunting Software Supply Chain Compromise

The practical hunt here starts with an honest inventory question, echoing the environmental knowledge piece: what third-party software in your environment has update mechanisms with elevated privileges, and how would you actually know if one of those updates behaved differently than expected. A hunt hypothesis worth building: for critical, high-privilege software (endpoint agents, IT management tools, anything running with system-level access), monitor for behavior following an update that deviates from that software’s established baseline—unexpected network connections to destinations outside the vendor’s documented infrastructure, unexpected child processes spawned by the software’s own update mechanism, or file modifications outside the expected installation directories.

Say a widely used IT management tool in your environment pushes an update, and in the following hour, the update process spawns a PowerShell session that then attempts to reach an external IP address never associated with that vendor before—that’s exactly the kind of anomaly this hunt is built to catch, and it’s a pattern no signature-based detection built around “trust this vendor’s update mechanism” would ever flag on its own.

Third-Party Access: The Trust Relationship That Outlives Its Purpose

Trusted relationship abuse covers a broader category—vendors, contractors, or partner organizations with legitimate access into your environment, where that access either gets compromised at the source or simply outlives its original business justification. This is less exotic than software supply chain compromise but arguably more common, and it’s worth hunting specifically because third-party access frequently gets provisioned generously at the start of a relationship and rarely gets scoped back down as the relationship’s actual needs narrow over time.

A hunt hypothesis worth running: inventory active third-party access grants—VPN accounts, shared credentials, API access tokens issued to vendors or partners—and check each against actual recent usage. Say an audit surfaces a vendor account with standing access to a file share that hasn’t been used in four months, because the underlying business relationship wound down without anyone deprovisioning the access. That dormant, forgotten access is exactly the kind of foothold an attacker who’s compromised that vendor’s own systems would be delighted to find still active and unmonitored.

Watching for Anomalies in How Trusted Access Gets Used

Beyond simply inventorying access, hunting this category well means applying the same behavioral anomaly thinking from earlier pieces specifically to third-party accounts—comparing current usage against the established pattern for that specific vendor relationship. A vendor account that’s historically only ever accessed one specific application during business hours, suddenly authenticating outside that pattern or attempting to access systems outside its documented scope, is a strong signal regardless of whether the credentials themselves are technically valid.

The Uncomfortable Reality: You Often Can’t See the Vendor’s Side

A genuine limitation worth stating honestly: much of the actual compromise in a supply chain attack happens on the vendor’s infrastructure, entirely outside your visibility, and no amount of hunting sophistication on your end changes that. What you can hunt for is the downstream effect—the moment that compromised trust actually touches your environment. This means accepting that supply chain hunting is fundamentally about catching the symptom rather than the root cause, and building your hunting hypotheses around that honest limitation rather than pretending you can see further upstream than you actually can.

Building a Standing Third-Party Risk Review Into Your Hunting Cadence

Given how much of this category depends on access hygiene rather than pure telemetry analysis, this is one of the few hunting categories that benefits enormously from being paired with a standing, periodic administrative review—a quarterly check of active third-party access against actual current business need—rather than relying purely on behavioral hunting to catch problems after the fact. The hunting and the access governance work reinforce each other here more directly than in most other categories covered in this series.

This post is licensed under CC BY 4.0 by the author.