Thread by @Laughing_Mantis

To add on to what @dildog is referencing with AWS vars and log4j

Here is a list of the AWS envs that I've seen attackers attempt to dump from the target machine

docs.aws.amazon.com/cli/latest/use…

For reference:

https://twitter.com/dildog/status/1469786190144585729?t=DgkQ7pfgkqG2H9qMj9y_7A&s=19

So when you see the "You just got RCE and you use it to info dump" people, please kindly remind them that RCE isn't always as fancy as they would love to think

Just want to add that I am now seeing #log4j payloads that will parse AWS credentials and then grab the AWS shared credentials file and upload it back to the attacker

Here are the AWS variables I am seeing being targeted in the wild by #log4j exploits at this time (even without rce):

AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
AWS_SHARED_CREDENTIALS_FILE
AWS_WEB_IDENTITY_TOKEN_FILE
AWS_PROFILE
AWS_CONFIG_FILE
AWS_ACCESS_KEY_ID

After getting these values they are attempting to exfil the AWS_PROFILE, AWS_WEB_IDENTITY_TOKEN_FILE, & AWS_SHARED_CREDENTIALS_FILE via http requests, or cat and copy to webhost or line by line dumping into a var and reading it

Everyone:
I just watched attackers infiltrate a private s3 and AWS instance by exploiting log4j on a seemingly unrelated host

IF YOU HAVE AWS VARS STORED AND YOU HAVE LOG4J VULNERABILITIES PREPARE TO ASSUME THE AWS STORED VARS ARE COMPROMISED: TEAR DOWN, REVOKE, AND REISSUE

Please see this tweet by @steveloughran for updated AWS vars that attackers are implementing

https://twitter.com/steveloughran/status/1469989910476111876