Tapping the data pipeline: Fivetran connector credential abuse

The plumbing that copies data into your warehouse can read everything. Every Fivetran connector holds standing credentials at both ends, source and destination, which makes the data-movement layer itself a path to the data.

How the attack works

The Fivetran account is accessed from a new host and connector configurations are read, exposing source connection details. The attacker forces a historical re-sync on a production database connector outside its normal schedule, pulling full table contents, then creates a rogue connector that loads selected source tables to an attacker-controlled warehouse account. The warehouse shows large reads from the staging schema, customer data in motion. In ATT&CK terms this is T1552, Unsecured Credentials, with T1530, Data from Cloud Storage.

Why it works

Connectors held broad, long-lived credentials, and there was no approval gate or alert on creating a new connector or destination, so anyone who could create a connector could create an exfil path.

How to fix it

The connector authenticates with stored credentials, not the admin password, so pause the rogue and affected connectors and rotate both the source and destination credentials they hold. The non-obvious point is that you must rotate at both ends of the pipe, and that throttling a noisy connector leaves its valid credentials in place while the rogue destination keeps loading. Scope what actually moved by joining the Fivetran sync logs with warehouse query history over the window, since the connector schema is only capability. As a class fix, scope connector credentials to least privilege, require approval and alerting on new connector and destination creation, and inventory every standing credential the pipeline holds.

Practice it

We built this as a GraphLattice Range scenario so teams can rehearse pausing connectors, rotating both ends, and scoping the data movement from the sync and warehouse logs.