[placardloop]

CloudTrail logs for the last 90 days are enabled by default, cannot be turned off, and are immutable, even by root. If you view this “event” as starting when Arko was supposed to have their access terminated, that’s within the 90 day window and you can indeed trust the logs from that period.

[ctoth]

CloudTrail's 90-day immutable Event History only logs management events (IAM changes, instance launches, bucket creation). It does NOT log:

* S3 object reads/writes (GetObject, PutObject) - these are "data events" requiring explicit configuration[0]

* SSH/RDP to EC2 instances - CloudTrail only captures AWS API calls, not OS-level activity[1]

With root access for 11 days, someone could modify gem files in S3, backdoor packages, SSH into build servers - none of it would appear in the logs they reviewed. Correct?

[0] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/l...

[1] https://repost.aws/questions/QUVsPRWwclS0KbWOYXvSla3w/cloud-...

[placardloop]

SSH is totally irrelevant here. Having AWS root account access doesn’t give you any ability to SSH to or otherwise access running instances. You could access data on those instances by cloning the EBS volumes or modifying build pipelines or changing network access or similar, but these would all show up in CloudTrail even without data events enabled.

For S3 objects, you don’t necessarily need data events to identify if tampering happened. S3 objects are immutable as well, so if any changed you would see that reflected in the creation date and new hashes that S3 attaches as tags, which you can correlate with application logs to see if they match up or not. It’s not as simple as data logging, sure.

But you’re also missing the key component here that they did not say they only just enabled CloudTrail logs, they’re saying they just now enabled CloudTrail log alerting. We don’t have any idea if data events were enabled or not, or if things like flow logs were enabled or not, or what other investigation tools they have running at the application layer. However, even if none of existed, there’s still a lot more audit-ability of events that happen in an AWS account than you’re implying, even the root account.

[knert]

I’m not sure this is true. The EC2 web console terminal drops me right into root on any of my instances.

[placardloop]

Ahh you’re right, there are some that just initiate a connection via something like Session Manager, but those connections where AWS initiates the connection for you are logged in CloudTrail, even without data events, and root doesn’t give you any ability to directly SSH into an instance outside of those methods (you cannot, for example, use root to find out what the private keys are for logging into an instance) so we’re back to the fact that any such access would be auditable.

[dragonwriter]

> Having AWS root account access doesn’t give you any ability to SSH to or otherwise access running instances.

It does if access credentials to those instances are stored in any AWS service in the account (such as in Secrets Manager).

[sylens]

Even without data events, there are clues you could infer from management events that somebody is going through buckets. ListBuckets and GetBucketLocation are management events and are seen often by someone enumerating buckets to exfil data from. The fact that this actor was someone very familiar with the account might make this a moot point though as they would know exactly which bucket to go to and what region its in.