Cloud Security Gaps Attackers Actually Use

At 2am, nobody cares that your cloud security dashboard was green yesterday.

They care that an access key created eighteen months ago just called an API it had never used before, from an address nobody recognises. They care that the affected workload can reach the production database. Then someone asks whether the relevant audit logs are complete, and the incident bridge goes quiet.

That is the problem with cloud security posture. Teams often inspect individual controls, mark them compliant, and miss the paths connecting them. Attackers work the path. A stale identity reaches an exposed service, the service reaches sensitive data, and the logging gap buys time.

Closing those paths requires treating identity, network access, detection, and recovery as one system.

A green dashboard is not a security boundary

Cloud posture tools are useful. AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center, Wiz, Prisma Cloud, and similar platforms can find public storage, weak policies, missing encryption, and exposed services. Run them. Fix what they report.

Just do not confuse findings with risk analysis.

A public object store containing website assets is not the same problem as a public object store receiving database exports. An administrator role protected by phishing-resistant MFA is not equivalent to a forgotten service account carrying the same permissions. Severity without context creates a queue, not a defence plan.

The useful question is not, "How many critical findings do we have?" It is, "What can an attacker reach from here?"

Start with internet-facing assets, external identities, CI/CD systems, and workloads handling credentials. Trace their effective permissions and network routes toward production data, control planes, backups, and logging systems. Those are the attack paths worth breaking first.

Identity is where most cloud boundaries get blurry

Cloud teams usually accumulate permissions faster than they remove them. Projects move, engineers change roles, temporary access becomes permanent, and deployment identities gain one more policy every time a pipeline fails.

Inventory effective access, not just the policies you intended to assign. In AWS, begin with credential reports, IAM Access Analyzer, CloudTrail, and service last-accessed data. These commands provide a useful first pass:

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

aws accessanalyzer list-findings \
 --analyzer-arn "$ANALYZER_ARN" \
 --filter '{"status":{"eq":["ACTIVE"]}}'

Look for long-lived access keys, inactive users, roles trusted by external accounts, wildcard actions, and permissions that have never been exercised. Check workload identities too. A Kubernetes service account mapped to a cloud role can be more interesting to an attacker than a human administrator.

Zero trust has a concrete meaning here: authenticate every identity, grant only the access required for the current job, and assume the calling workload may already be compromised. It does not mean buying an identity proxy and declaring the network harmless.

Prefer short-lived credentials from workload identity federation. Put privileged human access behind phishing-resistant MFA and just-in-time elevation. Add conditions based on account, organisation, resource tags, and expected identity claims. Deny paths you never want used.

Private does not mean isolated

A private subnet can still have unrestricted outbound access, broad routes to shared networks, and credentials capable of changing the environment. Once attackers land on a workload, those routes become their options menu.

Review security groups, network security groups, firewall rules, transit routing, private endpoints, Kubernetes network policies, and DNS. Pay special attention to rules justified as temporary. Nothing ages faster than a temporary 0.0.0.0/0 exception.

Infrastructure as code should express narrow intent:

resource "aws_security_group_rule" "app_to_database" {
 type = "egress"
 security_group_id = aws_security_group.app.id
 source_security_group_id = aws_security_group.database.id
 protocol = "tcp"
 from_port = 5432
 to_port = 5432
}

This is better than allowing the application subnet to reach every address on every port. It also gives reviewers something specific to challenge.

Do not ignore egress. Restrict access to metadata services, cloud APIs, package repositories, and the public internet where the workload does not need them. An attacker who cannot reach a command server, upload stolen data, or query instance credentials has a much worse day.

Logs have to survive the thing they are recording

During incident response, missing logs turn questions into guesses. Control plane audit logs should cover every region and project, land in a separate security account, and resist alteration by workload administrators.

Test this rather than trusting the configuration screen. Create a harmless canary event, such as attaching and removing a test policy. Confirm that it appears in the central platform with the identity, source, time, and affected resource intact.

Your SOC needs detections tied to attacker behaviour, not just policy failures. Useful signals include:

• A dormant key becoming active
• A new trust relationship with an external account
• Logging, security tooling, or backup policies being disabled
• A workload identity calling identity administration APIs
• Unusual bulk reads from object storage
• New public exposure on a sensitive service

Every alert needs an owner and a tested next action. If the SOC cannot quickly revoke a session, quarantine a workload, preserve evidence, and identify affected resources, detection becomes notification theatre.

A pentest should challenge the joins

A cloud pentest that only scans public IP addresses is incomplete. The assessment should test how identity, application flaws, workload metadata, network paths, secret stores, and control plane permissions interact.

Give testers enough architectural context to attack realistic paths. Ask them to demonstrate impact safely and explain which control should have stopped each step. Offensive work finds the path. Defensive work closes it and adds detection where prevention may fail.

That distinction matters for ransomware preparation. Cloud ransomware is not limited to encrypting a virtual machine. Attackers may delete snapshots, alter retention, encrypt object data, or compromise the identities used to manage backups. Recovery copies need separate credentials, deletion protection, tested retention, and restore exercises. A backup nobody has restored is an optimistic theory.

Treat remediation as engineering work

Posture programmes stall when findings arrive as thousands of tickets with no ownership or context. Group findings by root cause. One permissive Terraform module may explain hundreds of exposed resources. One broken identity pattern may affect every new deployment.

Put preventive controls into the delivery path: policy as code with Open Policy Agent, Checkov, tfsec, Conftest, or native cloud policy services. Block only high-confidence dangerous changes first. If every minor deviation fails a build, engineers will route around the control.

Track exceptions in code or a system with an owner, reason, scope, and expiry date. Expiry matters. Permanent exceptions are undocumented architecture.

If you only do one thing this week

Pick one internet-facing production workload and trace a complete attacker path from initial access to sensitive data, administrative control, logging, and backups. Verify every boundary with actual permissions, routes, and events rather than diagrams.

You will probably find at least one assumption that no longer holds. Fix that gap, then repeat the exercise on the next workload. That is how cloud cybersecurity posture improves: one verified attack path closed at a time.

If this is on your plate, TecLeads does exactly this as part of our Cybersecurity work. If you'd like a second pair of eyes on your setup, book a 30-minute call or explore what we do.