AWS Account Takeover via Log4Shell

To me this is less about log4j, and more about giving everything root.<p>&gt; The AWS account takeover was possible because a highly privileged IAM role had been assigned to the EC2 instance running the vulnerable Docker container app<p>The mistakes are, in order:<p>1. Binding an administrator IAM role to an EC2 instance, which is never ever a good thing to do, and<p>2. Running a docker container with full root privs - docker is not as much a security barrier as you think it is - it&#x27;s only slightly better than running the application as root on the VM itself.<p>So yes, the log4j vulnerability is dangerous, but not nearly as dangerous as running everything as root all the time.

This is a helpful writeup in terms of specific queries to look out for, but <i>any</i> RCE on a host with privileged IAM access is going to lead to this scenario.<p>&gt; The AWS account takeover was possible because a highly privileged IAM role had been assigned to the EC2 instance running the vulnerable Docker container app<p>This attack isn&#x27;t unique to Log4Shell; it&#x27;s a symptom of giving your (compromised) EC2 instance global admin access.

[Edit] too funny, the first three comments are all similar messages with three different communication styles (this one the most terse, I have much to learn)...<p>&gt; The AWS account takeover was possible because a highly privileged IAM role had been assigned to the EC2 instance running the vulnerable Docker container app. While the Log4j2 vulnerability allowed initial access to the Docker container, the privileged IAM role enabled lateral movement and ultimately a total compromise of the AWS account.<p>Saving you a click... who would realistically give such a high permission set IAM to an EC2?

Advert for gigasheet

So if they didn&#x27;t create a new user account and IAM account what would you see? If they just used the remote shell and the installed aws cli e.g. `aws s3 ls` would you be able to detect it? This article is an ad.