GET /.aws/credentials Requests in Your Logs: Scanners Hunting AWS Keys

203.0.113.7 - - [18/Oct/2026:03:51:11 +0000] "GET /.aws/credentials HTTP/1.1" 404 162 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
198.51.100.42 - - [18/Oct/2026:03:51:12 +0000] "GET /.aws/config HTTP/1.1" 404 162 "-" "python-requests/2.31.0"
192.0.2.88 - - [18/Oct/2026:04:12:03 +0000] "GET /root/.aws/credentials HTTP/1.1" 404 162 "-" "Go-http-client/2.0"

What the request is

~/.aws/credentials and ~/.aws/config are the shared configuration files that the AWS CLI and the AWS SDKs read at startup. The credentials file holds aws_access_key_id, aws_secret_access_key and sometimes aws_session_token, grouped into named profiles, as plain INI-style text with no encryption of its own. The config file holds the matching per-profile settings — region, output format, assumed-role and SSO configuration — which is less immediately usable but names roles and accounts an attacker would otherwise have to guess.

Neither file is protected by anything except its location: it normally lives in a user’s home directory, outside any web root, with filesystem permissions. A scanner asking for /.aws/credentials is testing whether that assumption broke on your host. It usually breaks in one of a few ways — root pointing at a project directory or a home directory rather than at a public/ subdirectory, a container image where the application runs as a user whose home is the same directory it serves, a deployment artifact or backup that carried a .aws folder into the served tree, or an alias that maps a parent directory into the URL space.

That is why the request list is longer than one path. The counted variants here include the bare /.aws/credentials and /.aws/config, home-directory forms such as /root/.aws/credentials, and the same names one level down under the directory names frameworks and containers commonly use: /config/, /app/, /backend/. Each one is a single cheap GET, and only one has to be reachable for the scan to pay off.

Who sends it

This is undirected, internet-wide scanning. The senders are mass scanners sweeping address ranges, credential-harvesting botnets that feed any recovered access key straight into cloud abuse such as resource hijacking or data access, and research crawlers that catalogue exposures. Nothing about a request to /.aws/credentials means your organisation was singled out.

The user agent proves little. Some clients announce an HTTP library such as python-requests or Go-http-client; many copy a current Chrome string. The shape is more telling: several paths from one address within seconds, no Referer, no requests for CSS, JavaScript or images, and a move on to other well-known secret files — .env, .git/config — as soon as these return 404. The same crawler run usually shows up on the /.env and /.git/config pages of your log too.

Is your server exposed?

Check what your logs already answered, then test the live path from the host itself:

# Every .aws path in the log, with the status it received
awk '$7 ~ /\.aws\// {print $9, $7}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

# Anything that was NOT 404/403 — this is the list that matters
awk '$7 ~ /\.aws\// && $9 !~ /^(404|403)$/ {print}' /var/log/nginx/access.log

# Ask your own server, from your own server, and read the status code
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/.aws/credentials
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/.aws/config

# Does an AWS credentials file sit inside a served tree at all?
find /var/www /srv /app -maxdepth 5 -path '*/.aws/*' -type f 2>/dev/null

Run the curl checks with the Host header of each vhost you serve, not just the default one — a dotfile rule added to the main site and forgotten on a staging or internal vhost is the usual way these files stay reachable. Give rotated and compressed logs the same awk pass, since an exposure may have been closed after it was already used.

How to block it

The durable fix is that no .aws directory should exist anywhere under a document root: point root at the application’s public directory, and keep credentials in the home directory of the service account or, better, replace static keys with an instance role or another short-lived credential source so there is no file to leak.

Add a dotfile rule as the second layer, in every server block:

# ACME and other well-known URIs must stay reachable
location ^~ /.well-known/ {
    allow all;
}

# Everything else with a dot-prefixed path segment: not found, not logged
location ~ /\. {
    access_log off;
    log_not_found off;
    return 404;
}

The ^~ prefix location is matched ahead of the regular-expression location, so ACME challenges keep working while /.aws/credentials, /root/.aws/config and /app/.aws/credentials all hit the regex — it matches a dot after any slash, not only at the start of the URI. Returning 404 rather than 403 tells the scanner nothing about which paths exist.

If any of these paths ever returned 200, the block is not the end of the job: the keys in that file are disclosed, and they have to be rotated and their use reviewed.