Introduction

Hello everyone, this is Akaike.

I often get the chance to conduct security assessments of customers' AWS environments, and there is a resource I run into almost every time.
It is "a poor EC2 instance that was created from the Management Console with default settings and then left alone"...

To convey just how dangerous this common scenario is, this time I will actually create one and check.
Let's look at what is risky about it, and what Security Hub, Amazon Inspector, and Amazon GuardDuty detect, together with the actual findings.

Creating one with default settings

First, let's launch an instance from the Management Console with default settings.
I only enter a name and create it with everything else left at the defaults.

A key pair selection dialog appears during creation, so this time I select "Proceed without a key pair".

The settings of the instance created this way were as follows.

• Basic settings

  • Name tag: management-console-ec2
  • Instance type: t3.micro
  • AMI ID: ami-0967230e9fa45db6d
  • AMI name: al2023-ami-2023.12.20260710.0-kernel-6.18-x86_64 (Amazon Linux 2023)
  • Virtualization type: hvm
  • Availability Zone: ap-northeast-1a
  • Tenancy: default
  • Detailed monitoring: Disabled
  • EBS optimized: Enabled
  • Enhanced networking (ENA): Enabled
  • Key pair: None
  • IAM instance profile: None

• Network settings

  • VPC ID: Default VPC
  • Subnet ID: Default public subnet
  • Public IPv4: Auto-assigned
  • Private IPv4: Auto-assigned
  • IPv6 address: None
  • Source/destination check (SourceDestCheck): Enabled
  • Security group: Newly created security group

• Storage

  • Root device name: /dev/xvda (EBS)
  • Volume type: gp3
  • Size: 8 GiB
  • IOPS: 3000
  • Throughput: 125 MiB/s
  • Encryption: None
  • Delete on termination (DeleteOnTermination): Enabled

• Instance metadata (IMDS)

  • Metadata endpoint (HttpEndpoint): Enabled (enabled)
  • IMDSv2 (HttpTokens): Required (required)
  • PUT response hop limit: 2
  • Access to tags in metadata: Disabled (disabled)
  • Nitro Enclaves: Disabled
  • Hibernation: Disabled

Dangerous points

What goes wrong if you leave it with these settings? Here are the three especially dangerous points.

Accessible from the internet

If you don't specify a VPC when creating an instance, the default VPC is used, and the subnets of the default VPC are configured to automatically assign public IPs.

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/default-vpc.html

As a result, this instance was also assigned a public IP.

There is also a feature called VPC Block Public Access, which can block communication with the internet in bulk on a per-VPC basis, but this is not enabled unless you explicitly turn it on.

https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa.html

In other words, with the defaults, it is in a state where it can be accessed from the internet...

The SSH port is wide open

The automatically created security group is, by default, configured to open SSH (or RDP for Windows) to 0.0.0.0/0.

And when combined with the aforementioned public IP, this SSH port becomes reachable from all over the world...

EBS is not encrypted

With the default settings, EBS encryption is disabled...

Also, EBS encryption by default can be enabled on a per-Region basis, but this is not set unless you explicitly turn it on.

https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html

Findings from security services

I left the instance described above running as it was for about a week after creating and launching it.
So from here, let's look at what kinds of findings AWS security services raised for this instance.

AWS Security Hub CSPM

The failed (FAILED) controls associated with the resources I created this time (instance, security group, and EBS volume) were the following five.

The dangerous points described earlier line up almost exactly as the findings.
Details of each control are described in the official documentation below.

[EC2.19] Security groups should not allow unrestricted access to ports with high risk

This detects that a high-risk port such as SSH (port 22) is open to 0.0.0.0/0.
It is worth noting that fully opening a security group is treated as the most severe item even within the FSBP.

https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19

[EC2.18] Security groups should only allow unrestricted incoming traffic for authorized ports

This control detects that unauthorized ports are opened without restriction.
The target resource is the same security group as EC2.19, but the angle is different, and the fully open SSH is flagged by both controls at the same time.

https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-18

[EC2.9] EC2 instances should not have a public IPv4 address

This is a finding for the instance having a public IPv4 address.
As a result of the public IP being attached through the default subnet's auto-assignment, this control fails.

https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-9

[EC2.3] Attached Amazon EBS volumes should be encrypted at-rest

This is a finding for the EBS volume being unencrypted.

https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-3

[SSM.1] Amazon EC2 instances should be managed by AWS Systems Manager

This is a finding for the instance not being managed by Systems Manager.
Because no IAM instance profile was attached to this instance, it cannot be managed from SSM even though the SSM Agent is running.

https://docs.aws.amazon.com/securityhub/latest/userguide/ssm-controls.html#ssm-1

Amazon Inspector

Amazon Inspector produced two types of findings: package vulnerabilities and network reachability.

https://docs.aws.amazon.com/ja_jp/inspector/latest/user/findings-types.html

There were 33 findings in total, with a breakdown of 14 HIGH and 19 MEDIUM.

Package vulnerabilities

The 32 detected findings are as follows.
There were 32 Package vulnerability findings, with CVEs detected in the kernel, vim, glib2, python3, sssd-related packages, and others included in the initial packages of Amazon Linux 2023.
(Sorted by severity and score)

Even a freshly created instance will have findings if the AMI already contains known vulnerabilities.
Especially in a state like this one, where dnf update has not been run after launch, findings are commonly raised.

Network reachability

The remaining one was a Network reachability finding, with the following details.

This is a finding that port 22 is reachable via the internet gateway.
There was a similar finding in CSPM, but Inspector also flagged it because it likewise determined that the instance is reachable from the outside.

Amazon GuardDuty

Finally, Amazon GuardDuty.
This was the part where I most felt "the danger of default settings" this time.

The finding raised for the target instance was the following single one.

UnauthorizedAccess:EC2/SSHBruteForce is a finding type indicating that an EC2 instance is being exposed to SSH brute-force attacks, and it is suspected that SSH brute-force attacks were carried out against this instance.

https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-ec2.html#unauthorizedaccess-ec2-sshbruteforce

While Security Hub and Inspector findings were configuration-based detections saying "this is a dangerous state," GuardDuty's is a detection of actual harm: "there is a suspicion of being actually attacked."

Note that Amazon Linux 2023 has SSH password authentication disabled by default, so this brute force does not immediately lead to an intrusion. (In this case, no key pair was created either, so logging in is effectively impossible.)

Still, the fact that an instance with a public IP exposed SSH fully open, and was targeted by unknown parties while it was left alone, should be taken seriously...

Conclusion

That was about the dangers of creating EC2 from the Management Console with default settings.
To sum up, the default settings that can be created with just a few clicks in the Management Console were in fact the following dangerous settings.

• A public IP is assigned
• SSH is fully open
• EBS is not encrypted

As I mentioned at the beginning, I see such instances almost every time I do a security assessment of a customer's AWS environment.
However, these can be addressed with a little extra effort: restrict the SSH source or use Session Manager for connections / do not attach a public IP / update packages.

That said, it is quite common for such poor instances to be created by someone before you know it...
So enabling Security Hub, Amazon Inspector, and Amazon GuardDuty as in this article lets you notice problems in a multi-layered way, from configuration flaws to actual attacks, and I recommend enabling them.

I hope this article conveys that "a single instance created with defaults and left alone" can become a surprisingly risky entry point.