Regenerate docs

docs/attack-techniques/AWS/aws.persistence.iam-create-admin-user.md

@@ -26,6 +26,12 @@ Establishes persistence by creating a new IAM user with administrative permissio
 
 - Create the IAM user and attach the 'AdministratorAccess' managed IAM policy to it.
 
+References:
+
+- https://permiso.io/blog/s/approach-to-detection-androxgh0st-greenbot-persistence/
+- https://blog.darklab.hk/2021/07/06/trouble-in-paradise/
+- https://expel.com/blog/incident-report-from-cli-to-console-chasing-an-attacker-in-aws/
+
 
 ## Instructions
 

docs/attack-techniques/AWS/aws.persistence.iam-create-user-login-profile.md

@@ -29,6 +29,11 @@ user intended to be used programmatically through the AWS console usual login pr
 
 - Create an IAM Login Profile on the user
 
+References:
+- https://permiso.io/blog/s/approach-to-detection-androxgh0st-greenbot-persistence/
+- https://blog.darklab.hk/2021/07/06/trouble-in-paradise/
+- https://expel.com/blog/incident-report-from-cli-to-console-chasing-an-attacker-in-aws/
+
 
 ## Instructions
 

docs/attack-techniques/GCP/gcp.privilege-escalation.impersonate-service-accounts.md

@@ -51,7 +51,21 @@ stratus detonate gcp.privilege-escalation.impersonate-service-accounts
 ## Detection
 
 
-Using GCP Admin Activity audit logs event <code>GenerateAccessToken</code>.
+Using GCP Admin Activity audit logs event <code>GenerateAccessToken</code>. 
+To get this event, you need to [enable IAM audit logs for data access activity](https://cloud.google.com/iam/docs/audit-logging#enabling_audit_logging).
+More specifically, you need to enable <code>DATA_READ</code> for your GCP project, e.g. using Terraform:
+
+```hcl
+data "google_client_config" "current" {}
+
+resource "google_project_iam_audit_config" "audit" {
+  project = data.google_client_config.current.project
+  service = "allServices"
+  audit_log_config {
+    log_type = "DATA_READ"
+  }
+}
+```
 
 Sample successful event (shortened for clarity):
 
@@ -97,9 +111,9 @@ Sample successful event (shortened for clarity):
 When impersonation fails, the generated event **does not contain** the identity of the caller, as explained in the
 [GCP documentation](https://cloud.google.com/logging/docs/audit#user-id):
 
-> For privacy reasons, the caller's principal email address is redacted from an audit log if the operation is 
-> read-only and fails with a "permission denied" error. The only exception is when the caller is a service 
-> account in the Google Cloud organization associated with the resource; in this case, the email address isn't redacted.
+> Audit logging doesn't redact the caller's principal email address for any access that succeeds or for any write operation.
+> For read-only operations that fail with a "permission denied" error, Audit Logging might redact the caller's principal 
+> email address unless the caller is a service account.
 
 Sample **unsuccessful** event (shortened for clarity):