add fully working solution for privesc via terraform state file poisoning and reference from s3 privilege escalation to that technique

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md

@@ -52,6 +52,19 @@ These are some examples:
 
 - If an EC2 instance is storing the **user data in a S3 bucket**, an attacker could modify it to **execute arbitrary code inside the EC2 instance**.
 
+### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
+
+It is very common that the [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files are being saved to blob storage of cloud providers, e.g. AWS S3. The file suffix for a state file is `.tfstate`, and the bucket names often also give away that they contain terraform state files. Usually, every AWS account has one such bucket to store the state files that show the state of the account.
+Also usually, in real world accounts almost always all developers have `s3:*` and sometimes even business users have `s3:Put*`.
+
+So, if you have the permissions listed over these files, there is an attack vector that allows you to gain RCE in the pipeline with the privileges of `terraform` - most of the time `AdministratorAccess`, making you the admin of the cloud account. Also, you can use that vector to do a denial of service attack by making `terraform` delete legitimate resources.
+
+Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
+
+{{#ref}}
+terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
 ### `s3:PutBucketPolicy`
 
 An attacker, that needs to be **from the same account**, if not the error `The specified method is not allowed will trigger`, with this permission will be able to grant himself more permissions over the bucket(s) allowing him to read, write, modify, delete and expose buckets.