DEV Community

Cover image for I bought us-east-1.com: A Look at Security, DNS Traffic, and Protecting AWS Users
Gabriel Koo for AWS Community Builders

Posted on • Edited on

I bought us-east-1.com: A Look at Security, DNS Traffic, and Protecting AWS Users

When people think about the term "us-east-1", they often think of AWS's very data center region that powers countless businesses worldwide. But what if someone registered the us-east-1.com domain? That’s exactly what I did, not to compete with Amazon but to enhance security in a world where cyber threats are more prevalent than ever. Let’s dive into why I bought us-east-1.com, the DNS traffic it receives, and how this domain serves as a safeguard for AWS users everywhere.

The Story Behind us-east-1.com

In December 2021, a thought struck me: Could it be that no one has registered us-east-1.com yet? Given the immense popularity of AWS's us-east-1 region, I was surprised that such a domain was still available. So, I went ahead and acquired it.

But this wasn’t just about claiming an unused domain. By owning us-east-1.com, I aimed to protect AWS users from malicious actors who might misuse it for phishing or other attacks. Imagine the potential for someone using a domain like this to create convincing but fake AWS log-in pages or phishing schemes. By owning it, I can ensure that doesn’t happen (further with my professionalism as an AWS Community Builder).

A Peek into the DNS Traffic

Owning this domain has provided fascinating insights into DNS queries—many of which are likely unintentional, generated by AWS resources and misconfigured systems. Here are the top daily DNS queries made against us-east-1.com:

Image description

prod-backend-db.cc66xuedqt2t.us-east-1.com - 23,420 queries/day

This entry is the most frequent DNS request, suggesting a significant number of backend systems inadvertently reach out to this domain. It's possible that development or testing environments are mistakenly set to us-east-1.com instead of AWS’s official DNS.

Actually if you are familiar with that AWS database service, you might get some clues on what it is.

us-east-1.com - 10,890 queries/day

Of course - this is the top level root domain.

loopback-streaming.us-east-1.com - 8,140 queries/day

The term "loopback" suggests that this may be tied to internal testing or streaming setups that inadvertently use us-east-1.com.

! Cisco Static File Reputation Host ! - 2,000 queries/day [Updated on 2024-11-23]

For cloud-sa-589592150.us-east-1.com I traced a bit from Google, it was meant to be cloud-sa-589592150.us-east-1.elb.amazonaws.com, as according to Cisco's document here it is meant to be used as part of a legacy version of their email security gateway.

Great! To the system admin who set this up, your organization's email security is now at risk since my domain could have let some malicious files enter your organization's email domain.

Cloud-Specific Service Entries

Domains like storagegateway.us-east-1.com and s3.us-east-1.com likely originate from services configured to use us-east-1.com. This highlights how systems might inadvertently look to this domain for data, increasing the risk of data leakage if the domain were in malicious hands.

My quick guess is that the user originally wanted to use vpce-randomhash-randomhash.storagegateway.us-east-1.vpce.amazonaws.com, but the domain name was manually typed and missed the .vpce.amazonaws.com part instead.

Unexpected Services

We see other services like smtp.mail.us-east-1.com and mobile.mail.us-east-1.com with smaller query counts. This could indicate email configurations or mobile services that are erroneously pointed here.

Extra - Flood of Unexpected Emails from (Official?) AWS Test Environments

Image description

Emails were sent to my  raw `@us-east-1.com` endraw  mailbox from *Thu, Dec 21, 2023, 12:45 AM* to *Sat, Dec 23, 2023, 10:40 PM*, around 60,000 in total

In addition to the DNS traffic, in 2023 December I’ve also received thousands of emails sent to one of us-east-1.com's email address, presumably from an internal AWS team using placeholder email accounts during testing. These emails, like the one shown here, often contain messages about "Data Requests" and come from addresses structured like aws-supply-chain@us-east-1.gamma.app.ketchup.aws.dev.

From the WHOIS information of the sender email's top level domain (aws.dev.), it should be owned by AWS officially, so likely there was an internal team testing something, potentially related to a supply chain application or data request system within AWS. However, instead of using internal or sandbox domains, the test emails were mistakenly directed to @us-east-1.com, likely due to placeholder or misconfigured email settings.

These emails underscore the importance of using secure, controlled environments for internal testing—especially in a company as large as AWS. Even minor oversights in placeholder email addresses can lead to unintended consequences, such as sending potentially sensitive internal only information to external entities.

Security Lesson: For cloud developers and architects, this is a good reminder to double-check your email configurations and ensure testing setups use proper sandbox or internal domains. Misconfigurations, even small ones, can lead to unintended data exposure.
In addition, do periodically check your email API logs for any abnormal/unexpected emails being sent - so that mis-firing of emails like this case could be avoided.

Why This Matters for Security

If someone else owned us-east-1.com, they could potentially:

  • Set up a fake login portal that mimics the AWS Console.
  • Capture sensitive DNS queries that could reveal system configurations or IP addresses.
  • Use it as a phishing link to trick users into providing credentials or accessing malware
    • Imagine if the domain was used to host a fake S3 API endpoint and people using the placeholder domain did uploaded real documents into it...

By owning this domain, I prevent these risks, ensuring AWS users aren’t unknowingly sending requests to a potentially malicious server. And for anyone reading this—always verify URLs before clicking. Even a slight typo can lead you into a trap.

What This Means for AWS Users

AWS has built a robust cloud ecosystem, but users are responsible for secure configurations. Here’s what AWS users can learn from this:

Check Your DNS Configurations:

Make sure your resources point to official AWS endpoints. Misconfigured DNS entries can inadvertently send sensitive information to unintended locations.

Be Mindful of Typos:

It’s easy to accidentally enter us-east-1.com instead of the official AWS domain. Double-check addresses, especially when dealing with cloud resources.

Stay Vigilant Against Phishing Attacks:

Always verify links, especially when accessing services critical to your infrastructure. Bookmarking official AWS links is a good practice to prevent phishing attempts.

Leverage a DNS Firewall like AWS Route 53 Resolver DNS Firewall:

To avoid your resources hosted on AWS from misusing the wrong domain, consider using Route 53 Resolver DNS Firewall. This service allows you to filter and regulate outbound DNS queries, helping prevent data exfiltration and accidental requests to unintended domains. You can create rule groups to block requests to specific domains or IP ranges, ensuring your resources only communicate with trusted endpoints. This added layer of security can help mitigate risks associated with misconfigurations or typos in domain names - in case your resources connected to the wrong domain, and the wrong domain is owned by a typosquater unlike myself.

As for your personal usages, do consider using a DNS resolver with built-in protection like 1.1.1.2, AdGuard, or if you are a hands on person, try building your own Pi-Hole and use it with a block list.

The Future of us-east-1.com

Owning us-east-1.com has given me insights into how resources are configured in various environments. While I monitor DNS requests, my primary goal is to ensure this domain remains out of the hands of bad actors. It serves as a reminder of the simple yet effective ways we can improve security by managing key assets—like domains.

I am welcome for suggestions on how to help AWS users detect misconfigurations or use this as a case study for security awareness in the cloud space. Until then, us-east-1.com remains a safe, controlled domain, protecting AWS users from potential security threats.

Ending Words

Registering us-east-1.com was a simple yet effective step to secure AWS users worldwide. This domain acts as a shield against phishing, data leaks, and other risks, simply by preventing misuse. If you’re an AWS user or anyone working with cloud services, take this as a reminder to double-check your configurations, always be wary of URLs, and adopt a proactive approach to security.

Security Tip: Please DO BOOKMARK the official AWS console links or type them manually to avoid phishing attempts. Here’s the correct link for us-east-1: AWS Console us-east-1.

Special Thanks [2024-12-15]

Since my article has been published in October 27, I am really thankful for those who reshared it as well as those discussing my story for raising the awareness of domain/DNS security:

P.S. I have only registered us-east-1.com, any other domain names resembling other AWS popular regions are not affiliated with myself.

Top comments (1)

Collapse
 
david_j_eddy profile image
David J Eddy

you are the hero we need.