Anatomy of an AWS Cloud Misconfiguration in BFSI

A Security Hub console showing four hundred findings tells you almost nothing useful. The number is a function of how many controls are enabled, not how exposed you are. The question that matters is narrower and harder: which of these findings, in combination, form a path from the internet to something that matters?

The observations below are anonymised and aggregated across multiple AWS assessments of production environments in the Indian BFSI sector. No client, account, application or resource is identified, and every example is sanitised. What is deliberately preserved is the pattern — because the same four findings recur, and they recur together.

The central argument of this article is that severity assigned per-finding is misleading. A Security Hub finding should not automatically be interpreted as an exploitable vulnerability, and a "medium" that sits on an attack path frequently matters more than a "high" that sits in isolation.

First, a Taxonomy Worth Adopting

Before the findings, a distinction that changes how a backlog gets prioritised. Most AWS security findings fall into one of five categories, and they warrant different responses.

The last row is where most real incidents live, and it is the row a per-finding severity score handles worst.

Finding 1 — Internet-Exposed Administrative Ports

What we observe. Security groups permitting TCP/22 or TCP/3389 inbound from 0.0.0.0/0. Less commonly but more seriously, database and management ports — 3306, 5432, 6379, 27017, 9200 — reachable from the internet. In production environments we have reviewed, these are rarely deliberate; they are almost always a troubleshooting rule that outlived its purpose.

Why it happens. A migration window, an urgent vendor access request, or a break-glass debugging session. Someone opens the port, the incident closes, and nothing prompts removal — because nothing breaks. Security groups have no expiry semantics, so a temporary rule is indistinguishable from a permanent one.

Security Hub signal. EC2.13 and EC2.14 (SSH/RDP from 0.0.0.0/0) under AWS Foundational Security Best Practices, with corresponding CIS AWS Foundations Benchmark controls. Note that these controls check the security group definition, not whether an instance is actually attached and running — which is precisely why a finding needs validation before it is prioritised.

Attack path. Internet-wide scanning identifies the open port within minutes of exposure. From there: credential stuffing against reused passwords, brute force against weak ones, or direct exploitation of an unpatched service. Access to the host is the objective — not the port.

Why authentication is not sufficient. This is the argument we most often have to make explicitly. "It requires a key pair" answers only one of several threats. It does not address a vulnerability in the listening service itself, which is reachable pre-authentication. It does not address a stolen or leaked private key. It does not address a compromised vendor or developer endpoint that legitimately holds credentials. And it does nothing about the log noise that makes genuine authentication anomalies hard to spot. Authentication is a control on who gets in; exposure is a decision about who may attempt entry at all.

aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values='0.0.0.0/0' \
            Name=ip-permission.from-port,Values=22 \
  --query 'SecurityGroups[].GroupId' --output text

# then confirm whether anything is actually behind it
aws ec2 describe-instances \
  --filters Name=instance.group-id,Values=<sg-id> \
            Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].{Id:InstanceId,PublicIp:PublicIpAddress}'

Remediation and prevention. Immediately, restrict source ranges to known CIDRs. Strategically, remove the need for inbound administrative access entirely: AWS Systems Manager Session Manager provides shell access over the SSM API with IAM-based authorisation and full session logging, and requires no open inbound port, no bastion and no key distribution. To prevent recurrence, enforce a Service Control Policy or a policy-as-code check in the pipeline that rejects 0.0.0.0/0 on administrative ports, so a non-compliant group cannot be deployed rather than being detected afterwards.

Finding 2 — Stale and Over-Privileged IAM Access Keys

What we observe. Long-lived AKIA keys with last-used dates measured in years; keys belonging to users who have left; keys created for a one-off migration and never revoked; and — the compounding factor — those same keys attached to identities holding far broader permissions than their purpose requires. Across anonymised assessments, a recurring pattern is a service account created for a single integration that has accumulated policies through successive projects.

Why it happens. Keys are created because they are the path of least resistance: a script needs credentials, a vendor tool asks for them, a CI job needs to authenticate. Nothing forces expiry. And crucially, revoking a key risks breaking something unknown, while leaving it costs nothing visible — so the asymmetry always favours inaction.

Security Hub signal. IAM.3 (keys rotated within 90 days), IAM.8 (unused credentials disabled), IAM.22 (unused credentials removed after 45 days), and the CIS controls covering root key existence and credential hygiene.

Why static credentials are structurally different. A temporary credential from an IAM role expires whether or not anyone notices it was stolen. A static key does not: it is portable, works from any network, survives instance termination, and typically triggers nothing when used from an unfamiliar location. It converts a transient host compromise into durable account access — which is the single most consequential property in this article.

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

# per key: age and last-used service/region
aws iam get-access-key-last-used --access-key-id <AKIA...>

# permissions actually exercised, versus permissions granted
aws iam generate-service-last-accessed-details --arn <principal-arn>

That last command is the one most teams skip and the one that makes least privilege tractable. Rather than reasoning about what a principal might need, service-last-accessed data shows which services it has actually used. Permissions never exercised are the safest place to start cutting.

Remediation and prevention. Disable before deleting — it is reversible and surfaces breakage safely. Investigate any key that is unused but recently active, since that combination is worth understanding rather than simply revoking. Replace static keys with IAM roles: instance profiles for EC2, task roles for ECS, IRSA for EKS, and OIDC federation for CI/CD pipelines, which removes long-lived keys from build systems entirely. Prevent recurrence with an SCP restricting iam:CreateAccessKey to a narrow set of principals, and treat any new key as an exception requiring justification.

Finding 3 — Missing VPC Flow Logs

What we observe. Flow Logs disabled entirely, or enabled on one VPC while others — often those added later, during expansion or acquisition — have none.

This is a visibility gap, not a vulnerability. Enabling Flow Logs prevents nothing. No attacker is deterred by them and no exploit is blocked. Rated purely as a configuration item it is unremarkable, which is exactly why it survives so many remediation cycles — it never looks urgent next to a "critical".

Why it matters anyway. Its value is realised entirely during incident response, at which point it cannot be retrofitted. CloudTrail answers which API calls were made. GuardDuty answers which known-bad patterns were detected. Neither answers what talked to what, when, and how much data moved. Without Flow Logs, questions like "did this host communicate with an external endpoint before we contained it" and "how much data left the environment" are unanswerable — and unanswerable questions force worst-case assumptions in regulatory notification.

For BFSI entities in India this has a specific operational consequence. CERT-In directions require specified incidents to be reported within six hours of detection, and CERT-In directions also set expectations around retention of ICT system logs. An organisation that cannot characterise scope inside that window is not reporting from evidence; it is reporting from assumption.

Remediation and prevention. Enable at the VPC level with a defined retention period, deliver to S3 or CloudWatch Logs in a dedicated logging account an attacker with production credentials cannot reach, and — the step that converts storage into detection — feed them into your SIEM with rules that actually fire. Logs nobody queries are an archive, not a control. Prevent recurrence by making Flow Logs part of the landing-zone template so new VPCs inherit them, rather than a checklist item at build time. This is the same principle we cover in cloud misconfigurations that cause breaches: fix the template, not the instance.

Finding 4 — Overly Permissive KMS Key Policies

What we observe. Key policies with wildcards in the principal, action or resource position. The pattern below is common in environments where a key was created quickly to unblock a deployment:

{
  "Sid": "AllowAccountUse",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::<account-id>:root" },
  "Action": "kms:*",
  "Resource": "*"
}

This grants every KMS action to the entire account, delegating authorisation wholly to IAM. It is not automatically a breach — but it means the key policy provides no independent constraint, so any IAM principal with permissive KMS permissions can decrypt.

{
  "Sid": "AllowServiceRoleDecryptOnly",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::<account-id>:role/<service-role>" },
  "Action": ["kms:Decrypt", "kms:DescribeKey"],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "kms:ViaService": "s3.<region>.amazonaws.com" }
  }
}

Why encryption alone is not the control. Encryption at rest defends against a specific threat: someone obtaining the underlying storage. It does not defend against an authorised call. If a compromised principal can invoke kms:Decrypt, the data is returned in plaintext through a legitimate API path, and the encryption is transparent to the attacker. Encryption at rest satisfies a control requirement under most frameworks; whether it provides meaningful protection depends entirely on the authorisation around the key.

Remediation and prevention. Enumerate policies with wildcard actions, scope principals to specific roles, constrain actions to those genuinely required, and add kms:ViaService or encryption-context conditions so a key usable for S3 cannot be used arbitrarily. Separate duties so key administrators and key users are distinct — a role that can schedule key deletion should not also be a routine data consumer. Review policies on a defined cycle rather than only at creation, since drift accumulates.

How These Combine: The Path That Matters

Individually, three of the four findings above are arguable. Chained, they are not. The realistic sequence:

Note what the sixth step does. It does not help the attacker — it damages the defender's ability to bound the incident. A finding that is genuinely unexploitable can still determine whether you notify ten thousand customers or a hundred.

The risk changes significantly when these appear together, and a per-finding severity model cannot express that. The practical fix is to ask a different question during triage: what does this finding enable, and what is one step away from it?

Why This Lands Harder in BFSI

The technical mechanics are identical in any sector. The consequences are not.

BFSI environments concentrate sensitive customer and financial data, operate large and fast-changing cloud estates, and carry heavy third-party and supply-chain dependency through payment processors, KYC providers and core banking integrations — each of which is typically granted programmatic access, and therefore an identity worth compromising.

The regulatory dimension deserves care rather than alarm. RBI expectations for regulated entities address security operations, access control and incident response; CERT-In directions set incident reporting and log retention obligations; ISO 27001 treats access control and cryptographic key management as controls requiring evidence; and PCI DSS applies where cardholder data is in scope. None of these should be read as meaning that a single Security Hub finding is automatically a regulatory violation. An open security group is a technical weakness; whether it constitutes non-compliance depends on scope, applicability, compensating controls and how the requirement is actually written. Conflating the two damages credibility with auditors and with engineering teams, and we would rather teams argue severity on technical grounds than on a compliance claim that does not survive scrutiny.

What is defensible is narrower and stronger: these four patterns weaken the evidence base that regulated entities are expected to maintain, and the visibility gap in particular directly undermines the ability to meet a six-hour reporting obligation with facts rather than estimates.

Remediation Matrix

The "typical risk" column is a starting point, not a verdict. Severity should be derived from the actual resource, its reachability, the permissions attached, the sensitivity of the data behind it and the compensating controls present — not assigned from the name of the control that produced the finding. Two identical EC2.13 findings can differ by an order of magnitude in real risk.

Seven Actions Worth Taking This Quarter

The Underlying Point

Every finding discussed here is well documented and none is novel. They persist not because they are hard to fix but because, examined individually, each looks tolerable — and a per-finding severity model never surfaces the combination that makes them dangerous.

AWS Security Hub is most valuable when organisations stop treating findings as an isolated compliance checklist and start analysing how multiple configuration weaknesses can form real attack paths. A backlog sorted by severity closes the most findings. A backlog sorted by attack path closes the most risk — and those are rarely the same list.

How Adayptus Helps

• Cloud Security Assessment — manual, expert-led review across AWS, Azure and GCP, with findings validated for real reachability rather than reported from configuration alone.
• Cloud Identity Review — the over-privilege and static-credential problem addressed directly.
• CSPM and CWPP — continuous posture coverage between deep assessments.
• BFSI Security — RBI-aligned security for banks, NBFCs and fintech.
• Managed SOC & MDR and Incident Response — turning Flow Logs and CloudTrail into detection, with a response path built around the six-hour reporting window.
• Red Teaming and Continuous Security Validation — proving whether these paths are genuinely traversable in your environment.

Related reading: top cloud security risks for CISOs, CSPM vs CWPP vs CNAPP, and cloud security for fintech and NBFCs in India.

Frequently Asked Questions

Click any question to expand the answer.