Amazon Health Log Overload and Incorrectly logged as root user

Some AWS services log excessively and conflicting information in events

Free Content on Jobs in Cybersecurity | Sign up for the Email List

I wrote about this on Twitter and already submitted this to the AWS Wishlist.

Amazon Health logs an excessive amount of logs making it hard to find logs that are actually useful.

In one particular account I use ONE service in a particular account. One. I turned off AWS Trusted Advisor already because it was logging activity with a service-linked role. I wrote about those here:

I thought I could reduce the health events by removing the widget from the AWS dashboard but no. I login, check CloudTrail and this is what I see (when you remove false from the read only filter and refresh).

I happen to be testing something so I am logged in as the root user I am not actively creating these events. All I did was navigate to the AWS dashboard. And apparently that triggers all these events? I don’t know.

If you look closely at the events sometimes there are multiple events at the exact same time:

They are logged as the root user but I think this is a mistake. I am not performing any actions and this is still happening. I think they may have even occurred when I was logged out.

In the past I talked to AWS about this and they said it was a problem when services logged events as the root user. They were working to get all teams to stop doing that. I wonder if that initiative got lost somewhere along the way as employees and leadership changed at AWS.

Actions taken by the root user only should be logged as the root user name. Actions taken by a service should indicate which service triggered the event — not a user name.

The IP address shows my IP address.

However, the User Agent shows an AWS Internal user agent.

That is not accurate.

When I look at the events they all look the same. I am not sure what they do, but if every user in your account generates this many logs, CloudTrail is going to have a whole lot of noise in it. Even it if doesn’t, it’s still a lot of noise. The events are kind of meaningless to me.

I think these events should go into a separate “system” category if they are not directly triggered by a user action. If they are, then have events and sub-events. All I did is login. That’s it. If looking at the AWS dashboard has 50 associated events, show one login event and when you expand that event, show all the related nested events. This is too complicated to sort out.

I also think it is inaccurate. You can’t have an AWS Internal user agent and my IP address. It’s got to be an AWS Internal User Agent and AWS Internal IP address.

Also, stop logging part of the root email address in the logs. That just makes it easier for people who can see the logs to try to guess the username and password. It should simply have the user root. And anything that is not an event directly triggered by the root user — should not be logged as an action taken by the root user.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab