Fingerprinting Third-Party SaaS Integrations as Attack Vectors

Third-party SaaS integrations are attack vectors. OAuth grants, service accounts, and dormant tokens can let attackers in even when the main application has no flaw. Fingerprinting that integration layer means identifying what is connected, what credentials it holds, and what those credentials can reach. A pen test that skips this work leaves a major attack surface unexamined.

Why SaaS integrations have become the preferred entry point for attackers

The traditional perimeter assumed that an organization controlled what connected to its systems. SaaS changes that relationship because each approved integration creates standing access for another service. That access can outlive the task, team, or business relationship that justified it. The application may remain secure while a trusted connection becomes the way in.

For attackers, this changes the work required to gain entry. Instead of breaking into the application, they can take over a connection the business has already authorized. A valid OAuth token carries the permissions, or scopes, granted to that connection. Possession of the token can therefore let an attacker use the connection's permissions without possessing a user's password. The weakness is not necessarily broken software but trusted access left unreviewed.

Unit 42's 2026 IR Report identifies software supply chain risk through trusted SaaS integrations and vendor connectivity as one of four major threat trends. The report describes a shift from isolated compromise to widespread operational disruption. It also found that preventable gaps materially enabled over 90% of breaches, including unmanaged third-party connectivity across SaaS and cloud. That figure puts integrations among the preventable gaps that attackers use to get in, so they belong inside the security boundary even if they seem like harmless business plumbing.

What the ShinyHunters campaigns and related supply-chain incidents reveal about how this plays out

Microsoft's July 2026 analysis of ShinyHunters activity documents two primary intrusion paths observed between mid-2025 and mid-2026. In the first, attackers impersonated IT support and guided users through an OAuth consent workflow. The malicious application appeared to be a legitimate Salesforce Data Loader tool. Once authorized, its token let attackers enumerate instances, persist in CRM data, and use discovered credentials to move to other SaaS platforms. The consent process itself supplied the foothold.

With the second path, attackers had no need to persuade a downstream customer. Attackers compromised upstream integration vendors and reused the OAuth tokens those vendors held. In the Salesloft Drift incident in August 2025, attackers used compromised Drift credentials to get connection secrets that downstream SaaS applications used. OAuth tokens then provided access across multiple customer Salesforce instances. Microsoft identifies this as a documented campaign entry point.

In the Gainsight incident in November 2025, a token was again used by someone other than its expected user. Salesforce flagged unusual activity involving Gainsight-published applications. Requests used OAuth tokens issued to the Gainsight-Salesforce connector but came from infrastructure outside Gainsight's systems. The token let attackers in without a Gainsight vulnerability.

The Klue incident followed the same structural path. An attacker gained access on June 11, 2026, through a compromised legacy credential tied to an integration service, and the activity was detected on June 12, 2026. The attacker obtained OAuth tokens Klue held for third-party platforms, including Salesforce. LastPass reported that an unauthorized actor used Klue-held tokens to access LastPass customer data in Salesforce.

Across these supply-chain cases, Salesforce was not the vulnerable component, and entry did not require credentials stolen from the end customer. The attacker effectively became the trusted integration. Microsoft's analysis places the activity across tenants in retail, education, and manufacturing, showing a pattern that crossed industry boundaries. MFA did not stop these paths because the authorization had already been granted.

How the integration attack surface actually forms — permission drift, dormant tokens, and non-human identities

This exposure accumulates through ordinary business work. A pilot tool receives broad permissions to speed up onboarding, then retains them after its role narrows. That is permission drift, a widening gap between what a connection needs and what it can do. An integration that is no longer used may still have valid, refreshable tokens. The business process ends, but its access survives.

Service accounts, integration users, and API keys can retain production permissions after the employee who created them leaves. Ownership changes do not necessarily change authorization. Shadow IT and shadow AI extend the problem beyond approved tools when employees connect personal AI tools or unsanctioned applications to enterprise SaaS data. Data can flow through those connections outside the normal security controls.

Each downstream customer that authorized the vendor's application inherits risk from the upstream breach. The reach of that breach depends on the vendor's customer connections and the breadth of their scopes. Revoking and rotating tokens can break functionality across hundreds of integrations, making cleanup operationally painful enough to defer. Meanwhile, token use can look legitimate because the access is legitimate.

The visibility gap also extends beyond OAuth. Unit 42's 2026 IR Report describes a legacy third-party billing application that exposed an undocumented, unauthenticated interface to the internet. Existing controls missed it because traffic appeared consistent with normal application behavior. A closer look found SQL injection points and hidden shell functionality. The case shows why ordinary monitoring is not the same as understanding a third-party component's internal attack paths.

What fingerprinting the integration layer looks like in a whitebox pen test

The tester catalogs authorized OAuth applications, service accounts, API keys in configuration files, third-party webhooks, and integration users. These are different forms of access, so an application list alone is not enough. The work establishes both what is connected and which identities or credentials make each connection function. It produces the inventory needed for every later test.

The next step is to compare granted permissions with the integration's stated purpose. A connection that only reads data may have read-write scopes. An application with little trust may have admin-level access. The tester examines those mismatches to establish what the integration could do.

Token analysis adds time to that picture. The tester identifies long-lived tokens, tokens that can be refreshed indefinitely, and refresh tokens exposed in environment variables, code repositories, or logging output. A narrow permission can still leave lasting exposure if the credential remains usable after the integration is abandoned. But to know the risk, the tester needs to know the token's scopes as well as how long it lasts. The inventory needs both dimensions.

Looking through source and configuration then finds credentials that may not show up in platform settings. The tester examines source code, CI/CD pipeline configurations, infrastructure-as-code files, and environment variable stores for hardcoded integration secrets. Cloud configuration shows the IAM roles, managed identity assignments, and service account permissions that belong on the map. Together, these sources show where credentials are held and what access they support.

The tester also needs to check token-processing code because integrations pass authorization between systems. For JWTs, the tester examines algorithm confusion involving RS256 → HS256, acceptance of alg:none, and missing expiration. These checks show whether an integration handshake accepts tokens it should reject or lets them stay usable with no expiration limit. The purpose is to prove a validation failure within the test's scope.

Finally, source code and cloud configuration expose handlers and interfaces absent from the known application perimeter. These include undocumented endpoints, unauthenticated interfaces, and webhook or URL-processing features. For the latter, SSRF testing asks whether a supplied URL can make the component reach resources it should not, including cloud metadata. Each step builds on the inventory by connecting an entry point to its permissions and reachable resources.

The vulnerability classes that most commonly appear once the integration surface is mapped

Mapping those connections reveals familiar weaknesses at boundaries that were trusted when the software was built. Hardcoded secrets provide the most direct example. A token or API key embedded in a repository or configuration file can expose integration access without any flaw in the connected platform. The Sisense incident illustrates this path. The remediation is parameterized secret management and scanning at the pull request level.

Over-permissioned OAuth scopes are a different kind of finding because the failure sits in configuration. A pen test establishes the consequence by demonstrating what the token permits beyond the integration's purpose. JWT misconfigurations sit at the handshake between systems instead. Algorithm confusion, alg:none acceptance, and missing expiration can break the rules for which tokens the integration accepts.

SSRF appears in webhook and URL-processing features that accept destinations from users or third parties. SQL injection occurs when data from a connected system reaches database queries without the parameterization controls used for user-facing inputs. A related database-boundary example is LangChain's GraphCypherQAChain, CVE-2024-8309, with CVSS 9.8. That vulnerability involves prompt-driven Cypher injection and enables unauthorized database operations, cross-tenant data access, and service disruption.

AI-assisted development adds pressure by accelerating the creation of integration endpoints without security review. Even with generated code, the tester needs to check how those endpoints handle incoming data and authorization. The common defect across these classes is misplaced trust in the source of an input. Data arriving from a connected service still crosses a trust boundary, even when the business approved the connection.

Why a blackbox or annual scan misses the integration attack surface entirely

A blackbox tester starts with what can be discovered externally, such as a company name or IP address. That approach can examine the exposed perimeter, but it cannot enumerate dormant OAuth tokens or inspect secrets in private repositories. Over-permissioned service accounts are also out of reach of that external view.

Automated scanning has a related limitation. Known signatures can flag potential defects, but they do not establish whether a legitimately granted OAuth scope exceeds an integration's business purpose. Nor do they explain whether a token can be reused across tenant boundaries. To answer those questions, a tester needs to know what the connection is meant to do. Microsoft's ShinyHunters analysis illustrates the gap by describing activity that evaded conventional authentication detections through trusted identities, approved applications, and legitimate workflows.

An annual schedule further limits testing that cannot examine the integration layer. New tools come in, old tools become dormant, and service accounts change hands as employees come and go. A point-in-time assessment can become stale as those relationships change. Passing an external compliance test therefore says nothing about an integration layer that was never examined. Testing that layer requires access to what the integration actually is, which makes whitebox access a prerequisite.

What a rigorous integration-focused pen test should produce and how to evaluate whether one did

The first evidence of a serious integration test appears before testing begins. The tester should request source code repositories, cloud configurations, and OAuth application registrations. Without those inputs, the proposed work cannot enumerate the surface described here. A provider that does not request them is not planning to examine those integration paths. Scope should spell out that access so the work covered by application testing is clear.

The inventory should name every third-party application that is connected and list its scopes, token lifetime, and business owner. Findings should then connect that inventory to demonstrated consequences. A working exploit or documented attack chain should show what an attacker with the relevant access could actually do. A note that permissions are broader than necessary is not equivalent to proof of their business impact.

Tests of business logic should cover how a compromised upstream vendor could use tokens it already holds to reach the organization's data. The ShinyHunters supply-chain pattern makes that a concrete testing scenario. After remediation, a retest should establish whether the identified scope or exposed secret has been addressed. Pull request-level scanning and review should also cover webhook handlers, token-processing code, and OAuth callback implementations so later changes do not quietly restore the weakness.

Finally, the report and letter of attestation should spell out what the test covered in the integration layer. That gives SOC 2, HIPAA, and other compliance auditors evidence that third-party connectivity was within scope. More importantly, it gives the engineering leader a clear account of what was examined, what was exploitable, and what was corrected.