Check for Anomalous AWS Access After the Railway Incident

If you stored an AWS access key in Railway, treat it as exposed after Railway's October 21, 2026 security disclosure. Create a replacement key, deactivate the old one (do not delete it yet), then search CloudTrail for every API call made with the old key ID, in every Region you use. Look for actions your application never performs, activity from unfamiliar Regions and IP addresses, and new users, keys, resources or charges.

This guide walks through that process step by step. It follows Railway's own published AWS guidance [1] and adds the equivalent AWS CLI commands from AWS documentation. It is for checking your own accounts only. For background on the incident, read our Railway security incident explainer.

#Key takeaways

• Why check: Railway said an unauthorized party may have accessed environment variables, and for some obtained decrypted contents. AWS keys are a common thing stored there [2].
• Rotate first, then investigate. Create the new key and deactivate the old one, but keep the old key available until you are done.
• CloudTrail is your main evidence. Event history keeps management events for 90 days and is searched per Region [1].
• Check for the attacker's footprints, not just your own app's behaviour: new IAM users and keys, new resources, odd Regions and billing spikes.
• Preserve evidence before cleaning up. Snapshot what you need before deleting anything an attacker created.

#Before you start

You need:

• The access key ID of every AWS key stored in Railway variables (for example AWS_ACCESS_KEY_ID, or a shared variable in Project Settings).
• Permission in AWS to view IAM, CloudTrail and billing.
• A rough exposure window: from the earliest time the key could have been readable in Railway until you rotated it. Railway's guide does not give a fixed start date, so use a conservative one.
• Optionally, the AWS CLI configured with a safe, separate admin identity. Do not use the exposed key to investigate itself.

#Step 1: Create a replacement key and deactivate the old one

Following Railway's guide [1]:

1. In the IAM console, search for the exposed access key ID to find its user.
2. Under Security credentials, then Access keys, choose Create access key to make the replacement.
3. On the old key, choose Actions, then Deactivate.

Railway's advice is to deactivate first rather than delete, "so you can reactivate briefly if a service you forgot about breaks" [1].

The CLI equivalents, with placeholders:

bashaws iam create-access-key --user-name USER_NAME
aws iam update-access-key --user-name USER_NAME --access-key-id OLD_KEY_ID --status Inactive

#Step 2: Update Railway and anything else that used the key

1. In Railway, edit AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, or the shared variable in Project Settings, then deploy the staged change [1].
2. Confirm your logs show no InvalidClientTokenId or SignatureDoesNotMatch errors, which would mean something is still using the old key [1].
3. Update anything outside Railway that used the old key, such as local development or CI [1].

#Step 3: Search CloudTrail for activity by the old key

CloudTrail Event history records management API calls, and Railway's guide notes it keeps them for 90 days [1].

In the console:

1. Open CloudTrail, then Event history.
2. Set Lookup attributes to AWS access key.
3. Enter the exposed access key ID.
4. Set the time range to cover the exposure window.

With the CLI:

bashaws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=OLD_KEY_ID \
  --region us-east-1

Event history is per Region, so repeat the search in every Region [1]. A script can loop through them:

bashfor r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "== $r"
  aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=OLD_KEY_ID \
    --region "$r" --max-results 50
done

Note that Event history covers management events. Data events such as S3 object reads only appear if you configured a trail to record them.

#Step 4: Know what suspicious looks like

Railway's guide lists these warning signs [1]:

If your app normally only reads from S3, any of the actions above deserve a close look.

#Step 5: Check IAM for things you did not create

1. Download the credential report from the IAM console to find users, access keys or passwords you do not recognise [1].
2. Check when each key was last used. IAM tracks this. For a specific key:

bashaws iam get-access-key-last-used --access-key-id OLD_KEY_ID

3. Review users, roles and policies for recent additions or changes.

The CLI version of the credential report:

bashaws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode

#Step 6: Check billing for unexpected spend

Railway recommends comparing the exposure window with the previous month in Cost Explorer [1]. Look at spend by service and by Region. Sudden growth in compute, data transfer or a Region you never use is a strong signal. Setting up billing alerts and budgets now helps you notice this early next time.

#Step 7: Clean up carefully

• Snapshot first. Railway advises preserving anything needed for forensics before you delete attacker-created resources, users, roles, policies or keys [1].
• Then remove what is clearly malicious, and rotate any other credentials that might have been created.
• Only delete the old key after the new setup is stable and the review is finished.
• If AWS Support sent you an irregular-activity notice, reply in the Support Center with the actions you took [1].

#Step 8: Reduce the risk next time

• Least privilege. Scope the key to the exact actions and resources the app needs.
• Prefer short-lived credentials such as IAM roles over long-lived access keys where possible.
• Turn on CloudTrail across all Regions and, if needed, data events, so evidence exists before you need it.
• Set budgets and billing alerts.
• Separate keys per service and environment.
• If your account has them, services such as AWS GuardDuty can flag unusual activity. Railway's guide does not cover them, so check AWS documentation for your setup.

See also: AWS vs GCP vs Azure, observability: logs, metrics and traces and incident management and postmortems. Using Google Cloud too? Read how to check for anomalous GCP access.

#Need a hand reviewing your cloud setup?

We help teams audit cloud access, rotate secrets and set up monitoring. Get a scope estimate for a cloud security review.

#FAQ

#How do I check if my AWS key was used by an attacker?

Search CloudTrail Event history by access key ID for the exposure window, in every Region, and look for actions your application does not perform, unfamiliar Regions and IP addresses, and new IAM users, keys or resources.

#Should I delete the old AWS access key right away?

Railway advises deactivating first rather than deleting, so you can briefly reactivate it if a forgotten service breaks. Delete it after the new key is working and your review is complete.

#How far back does CloudTrail Event history go?

Railway's guide notes it records management API calls made with a key for 90 days. Longer retention needs a trail that delivers logs to storage.

#Why must I search every Region?

CloudTrail Event history is per Region, so an attacker's activity in a Region you do not use will not show up in the one you checked.

#What should I look for in CloudTrail?

Actions such as RunInstances, CreateUser, CreateAccessKey, CreateRole, AttachUserPolicy and PutBucketPolicy, activity in unused Regions, and source IPs outside your normal ranges.

#What if I find suspicious activity?

Snapshot evidence, remove attacker-created resources and credentials, rotate everything else the key could touch, contact AWS Support and reply to any irregular-activity notice.

#Does this apply to keys not stored in Railway?

The same steps apply to any exposed AWS key. Railway's guidance is aimed at keys stored in Railway variables.

#References

1. Railway Blog, "Security Disclosure Recommendation: Check for Anomalous AWS Access." 22 October 2026. blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access
2. Railway Blog, "Security Disclosure: Wednesday October 21st." 21 October 2026. blog.railway.com/p/security-disclosure-wednesday-october-21st
3. AWS Documentation: AWS CloudTrail User Guide and IAM credential reports.

Disclaimer: independent, unofficial guidance for checking your own accounts, not affiliated with Railway or AWS. Verify commands against current AWS documentation, and contact AWS Support or a security professional for serious incidents.