See which AWS misconfigurations chain into an attack path
Connect an AWS account with a read-only role and run a scan. AWS Cloud Security checks network exposure, identity, data, servers, logging and credentials, links what it finds into paths from the internet or an outside account to what matters, and ranks the fixes that break the most paths. It is not a complete security assessment.
- 56 read-only checks
- Attack paths, step by step
- Fixes ranked by paths they break
- Evidence with every finding
- What it couldn't see, listed
- No changes to your resources
| Severity | Finding | Resource | On paths |
|---|---|---|---|
| critical | Admin ports open to the internet | sg-web (ap-south-1) | 3 paths |
| high | Instance allows IMDSv1 | web-1 (ap-south-1) | 3 paths |
| high | Running instance has an administrator role | web-1 (ap-south-1) | 2 paths |
| medium | Console user without MFA | deploy-user | 1 path |
| low | EBS volume is not encrypted | vol-logs (ap-south-1) | off every path |
Top fix: close the admin ports on sg-web · breaks 3 of 3 paths
How it works
3 steps to get going
- Step 1
Connect an AWS account
Create a read-only role in your account from our CloudFormation template, in one click. Only Tomorrow Central can use it, and only with a code tied to your connection.
- Step 2
Run a scan
The scan reads your account's configuration through that role and stores a report: findings, attack paths and fixes.
- Step 3
Fix what breaks the most paths
Start with the fixes at the top. Each one lists the findings it resolves and the paths it breaks.
What you get with AWS Cloud Security
Attack paths, not just a list
Findings are linked into paths from an entry point, such as the internet or another account, to administrator access or sensitive data, each step with its evidence.
Fixes ranked by what they break
The fixes are ordered by how many attack paths each one breaks, so the first fix is usually the one that matters most.
A gap is never a pass
When a check can't see something, the report says what it couldn't see and which permission it needed, instead of marking it clean.
Secret values stay out of reach
The role is always denied secret values, object contents, parameters and decryption, whatever the AWS-managed policies it uses allow. Function code and configuration stay denied too, unless you turn on secret scanning.
Known vulnerabilities
A vulnerability scan adds CVEs reported by Amazon Inspector, missing patches from SSM, and installed packages matched against public vulnerability data, and links vulnerable hosts into the attack paths.
Secrets left in configuration, if you allow it
With secret scanning allowed on the role, a secret scan finds keys, tokens and passwords left in Lambda, EC2 user data, CloudFormation, CodeBuild and ECS configuration. It keeps only a fingerprint and a masked preview of each, never the value.
56 checks across six areas:
- Data: 13 checks
- Servers: 12 checks
- Identity: 10 checks
- Network: 9 checks
- Logging: 7 checks
- Credentials and stored secrets: 5 checks
It reads configuration. It does not test, probe or attack anything, and it is not a complete security assessment.
Questions
What access does it need?
A role in your account with AWS's SecurityAudit and ViewOnlyAccess policies and the IAM credential report. Our template creates it, and only Tomorrow Central can assume it, with a code tied to your connection.
Does it change anything in my account?
No. The role can't create, change or delete your resources. It is always denied secret values, object contents, parameters and decryption, and function code and configuration unless you turn on secret scanning.
How do I stop it?
Delete the CloudFormation stack in your AWS account. Our access ends at once.
Can I use it now?
It is switched on for each organization by us while it is new. Talk to us and we'll set it up.