Terraform’s Provider Trap
A convincing infrastructure task can carry an executable trust decision before any planned deployment.
Zscaler published its analysis on 8 October after finding the campaign in July. Its researchers found a trojanised provider that ran when Terraform loaded it and still performed the expected provider work.
Opening a folder is not proof of compromise. Identify what executed.
The provider is part of the execution path
Terraform providers are not passive configuration. HashiCorp describes them as plugins, while the dependency lock file records selected versions and checksums for later runs.
Zscaler’s sample contacted a HashiCorp-themed lookalike and delivered FLATROOF followed by ROOFDECK. Windows execution depended on a compatible Unix-like shell being present.
For defenders, the practical boundary sits before the first run. Treat an unfamiliar provider source, a private registry, a changed lock file or an unexplained plugin binary as executable code review, not as routine project metadata.
A separate investigation shows how the lure can look ordinary
SentinelOne published a separate investigation on 18 September and revised it on 21 September. It described fake interview projects whose lock files directed terraform init towards attacker-controlled provider registries.
That case involved an IT-services victim in India with no known cryptocurrency connection. SentinelOne did not prove the delivery route for that victim, so it should not be treated as proof that every infection began with the same interview lure.
The two reports describe related abuse of the provider trust path, but they are not one continuous incident record. Zscaler does not establish how its sample first reached a victim.
Check the project before Terraform checks the provider
Before running external code, review provider sources, registries and lock-file changes. Confirm every registry is expected.
Checksums help detect an unexpected package after a selection has been trusted, but they do not decide whether the first source was legitimate. HashiCorp’s documentation says dependency installation occurs during terraform init and recommends reviewing lock-file changes. Teams using mirrors or several platforms can pre-populate intended checksums with terraform providers lock.
Run interview and assessment projects on an isolated, disposable system without production cloud tokens, source-control credentials, browser sessions or wallet extensions. Do not use a corporate workstation merely because the project looks like normal infrastructure code.
If the project has already run
Disconnect the host from normal work, preserve the project and execution evidence, and investigate before rebuilding it. Review Terraform and editor child processes, provider binaries, outbound connections, newly created files and account activity from the relevant time.
Scope credential rotation to the evidence, but include browser sessions, source control and cloud access when they were present on the host. Wallet credentials also belong in scope where applicable. Revoke active sessions as well as changing passwords, and check CI runners if the same project reached automation.
Do not close the incident because no infrastructure change was applied. The security question is whether the provider executed and what it could access locally.
What the evidence does not prove
Zscaler linked the activity to suspected TraderTraitor but could not independently attribute it with high confidence.
Sources: Zscaler ThreatLabz analysis, 8 October 2026; SentinelOne Labs investigation, 18 September, revised 21 September 2026; HashiCorp dependency lock documentation.
