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…