Here it is below - for us it was #4 which i should clearify was not vague just my tired memory of it - since once i received this i was very relieved and proceeded to sleep. I can tell they are definitely trying and IMO doing the right thing with their efforts below was the followup email that let us get sleep.
Earlier today, we provided you a notification with a list of instances that may still be running a version of log4j that has a known security vulnerability and needs to be patched. We want to provide you additional details about that email.
The list of instances was obtained by monitoring for specific DNS queries which are typically used when targeting the log4j vulnerability. These DNS lookups can indicate that someone is attempting to exploit the log4j vulnerability on your instance. Each of the instances provided has made a DNS lookup to one of the suspect domains between 12:00 AM and 11:59 PM PST on December 16th 2021. While we are not able to tell whether the instance was compromised, we strongly recommend that you take action to update log4j across all of your Java environments, whether they are publicly accessible or not.
In some cases, the list of instances included instance IDs that may not currently be present within your EC2 environment. This happened for a number of reasons:
1. EC2 instances may have been terminated since the scan was completed at 11:59 AM PST on December 16th 2021;
2. EC2 instances that have been stopped and restarted may appear with the incorrect instance ID;
3. ECS, EKS, and Fargate containers have been included with the underlying instance ID instead of the container ID;
4. EC2 instances used by underlying network services were erroneously included in the list of instances. These services are not themselves running unpatched log4j, but can be indicative of these DNS queries coming from within your VPC.
While it is not always possible for us to pinpoint the exact instances making these DNS queries, it is critically important that you patch all Java environments for the log4j issue, whether they are publicly accessible or not. To help you, we are also providing a 15-day free trial to Amazon Inspector which can assist you in finding vulnerable resources by scanning your Amazon Elastic Compute Cloud (EC2) instances and container images for the log4j vulnerability.
Please take the steps explained in this security blog post [1] to protect your resources. You also can find more information about log4j in our security bulletin [2].
If you have any questions or concerns, please reach out to AWS Support [3].
Earlier today, we provided you a notification with a list of instances that may still be running a version of log4j that has a known security vulnerability and needs to be patched. We want to provide you additional details about that email.
The list of instances was obtained by monitoring for specific DNS queries which are typically used when targeting the log4j vulnerability. These DNS lookups can indicate that someone is attempting to exploit the log4j vulnerability on your instance. Each of the instances provided has made a DNS lookup to one of the suspect domains between 12:00 AM and 11:59 PM PST on December 16th 2021. While we are not able to tell whether the instance was compromised, we strongly recommend that you take action to update log4j across all of your Java environments, whether they are publicly accessible or not.
In some cases, the list of instances included instance IDs that may not currently be present within your EC2 environment. This happened for a number of reasons:
1. EC2 instances may have been terminated since the scan was completed at 11:59 AM PST on December 16th 2021;
2. EC2 instances that have been stopped and restarted may appear with the incorrect instance ID;
3. ECS, EKS, and Fargate containers have been included with the underlying instance ID instead of the container ID;
4. EC2 instances used by underlying network services were erroneously included in the list of instances. These services are not themselves running unpatched log4j, but can be indicative of these DNS queries coming from within your VPC.
While it is not always possible for us to pinpoint the exact instances making these DNS queries, it is critically important that you patch all Java environments for the log4j issue, whether they are publicly accessible or not. To help you, we are also providing a 15-day free trial to Amazon Inspector which can assist you in finding vulnerable resources by scanning your Amazon Elastic Compute Cloud (EC2) instances and container images for the log4j vulnerability.
Please take the steps explained in this security blog post [1] to protect your resources. You also can find more information about log4j in our security bulletin [2].
If you have any questions or concerns, please reach out to AWS Support [3].
[1] https://aws.amazon.com/blogs/security/using-aws-security-ser... [2] https://aws.amazon.com/security/security-bulletins/AWS-2021-... [3] https://console.aws.amazon.com/support