We received a few emails from AWS about irregular activity related to Log4shell. I asked a few friends, and they got similar messages as well.<p>AWS provided a list of EC2 instances where they saw DNS queries which are typically used when targeting the log4j vulnerability, but they did not provide further information.<p>Have you received similar notification? What have you done about suspicious instances?<p>The ironic part is that AWS did that on Friday while half of the internet was making memes about the fact that the Log4j vulnerability was disclosed on Friday.
I think this is what AWS GuardDuty is supposed to do?<p>Edit:
<a href="https://aws.amazon.com/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/" rel="nofollow">https://aws.amazon.com/blogs/security/using-aws-security-ser...</a><p>GuardDuty
In addition to finding the presence of this vulnerability through Inspector, the Amazon GuardDuty team has also begun adding indicators of compromise associated with exploiting the Log4j vulnerability, and will continue to do so. GuardDuty will monitor for attempts to reach known-bad IP addresses or DNS entries, and can also find post-exploit activity through anomaly-based behavioral findings. For example, if an Amazon EC2 instance starts communicating on unusual ports, GuardDuty would detect this activity and create the finding Behavior:EC2/NetworkPortUnusual. This activity is not limited to the NetworkPortUnusual finding, though. GuardDuty has a number of different findings associated with post exploit activity that might be seen in response to a compromised AWS resource. For a list of GuardDuty findings, please refer to this GuardDuty documentation.
We received this as well except<p>1. We don’t use Java
2. The instances in the email are not in our accounts<p>We later received another email providing some vague reasons for this…<p>On a Friday evening I was not very happy spending time trying to hunt down the invalid instances
We received this. We have no Java.<p>The notification from AWS referenced an instance we don’t have.<p>Some clarification from AWS would be nice. It made me wonder if it was related to an ELB or something.
If I got the same (I have not seen the same for my AWS accounts), I would start capturing DNS traffic ASAP. Either at the VPC or host level. Cheap and easy to do most of the time<p>If not running Java (including agents), it may indicate some other type of compromise. Not something you should really ignore. Look at logs, cpu, disk, port usage just to start
Just a theory but it might be from an ssh user where the log4j string somehow resolves in a reverse dns lookup from the originating ip. Even when the login fails the lookup will be done.
I'm under the impression AWS in general proactively scans/monitors for (some) vulnerabilites on its infrastructure and notifies it customers.<p>Years ago I once received a warning regarding a potential exposure. I don't think it is very extensive, and in our case it wasn't a big deal, but I considered that notification back then a pretty "high level of service". Yes, such a notification can be scary, but better a little scare than having your systems compromised. This post on HN is reassurig that AWS tries to keep it that way. (We didn't get the Log4Shell warning as we're not vulnerable afaict)
Maybe it's just advertising using this period to point at products like GuardDuty. These are golden times for most vendors and suppliers of anything Security related.
Being a new and highly visible Target, maybe AWS sent out for positive emails when it saw an attempt on your VM? Or maybe one of AWS's DNS servers was listed by AWS as being used by hackers, and your own VM happened to use AWS DNS resolution?<p>Just some thoughts. Sucks to lose time, but the notices probably helped more than it hurt? Part of the price of modern defense to get false positives...<p>If I get a suspicious instance, I usually snapshot the disk and blow it away. We don't have a lot of resources for investigation, but we'd probably look at what we can get from logs, check scope of damage, and likely move on... We only run instances when we have no other choice, so they generally are pushed data, with no real pull access.