Inside Cloud and Identity Security Gaps: Findings from SISA's Red Teaming Operations

 

Inside Cloud and Identity Security Gaps

Cloud adoption has changed how organizations build and manage their digital environments. Applications, databases, identities, APIs, workloads, and business data now operate across cloud platforms and hybrid infrastructures. While this transformation improves flexibility and scalability, it also creates new security gaps.

SISA’s Red Teaming operations show that attackers do not always need to exploit a sophisticated software vulnerability to reach critical cloud resources. In many cases, legitimate credentials, excessive permissions, weak authentication, exposed secrets, and gaps between on-premises and cloud environments can provide the access they need.

The key lesson is simple: cloud security and identity security can no longer be treated as separate security problems.

Why Cloud and Identity Security Are Connected

Traditional security strategies often focused on protecting a network perimeter. Cloud environments have changed that model.

Users can access applications from anywhere, employees may use multiple SaaS platforms, developers can provision cloud resources, and applications communicate with cloud services through APIs and service accounts.

This means an attacker who obtains a valid identity may not need to “break into” the cloud. They may simply authenticate and use the permissions already assigned to that account.

SISA’s Red Team engagements specifically examine identity compromise, credential abuse, privilege escalation, lateral movement, persistence, logging, and monitoring to understand how attackers could move through an environment after initial access.

1. Exposed Cloud Credentials Can Become the First Step

One of the clearest examples from SISA’s Red Team work involved an exposed AWS IAM key.

During an engagement, SISA’s team discovered a base64-encoded string in publicly available code that contained an AWS IAM credential. The exposed key provided partial AWS CLI access.

The problem did not stop with the leaked credential.

The Red Team was able to enumerate cloud resources, identify S3 buckets, access confidential files, and discover additional secrets connected to services including DynamoDB, Redshift, and Lambda. The team also created resources in a less-monitored AWS region, demonstrating how incomplete cloud visibility can allow suspicious activity to remain unnoticed.

This demonstrates how a seemingly small identity exposure can become part of a much larger attack chain.

2. Weak IAM Permissions Increase the Blast Radius

Identity and Access Management, or IAM, determines what users, applications, and services can access.

A compromised identity becomes significantly more dangerous when it has excessive permissions.

For example, an account that only needs access to one storage location should not automatically have broad permissions across databases, compute resources, or administrative functions.

SISA’s Red Team approach focuses on following realistic attack paths rather than simply identifying individual weaknesses. This helps demonstrate what an attacker can actually achieve after obtaining an identity or foothold.

Organizations should therefore regularly review:

• User permissions
• Privileged accounts
• Service accounts
• Cloud IAM roles
• API keys
• Temporary credentials
• Dormant accounts
• Third-party access
• Cross-account permissions

Least privilege is especially important because limiting permissions can reduce the impact of a compromised identity.

3. MFA Gaps Still Create Major Identity Risks

Multi-factor authentication is an important layer of identity protection, but SISA’s recent Red Team engagements found critical externally exposed systems where MFA was not enforced.

These systems included VPN portals, HR applications, helpdesk platforms, productivity applications, and ERP systems. Weak password practices sometimes made the problem worse.

SISA also observed password spraying at scale. In one engagement, more than 350 domain accounts were compromised, including two Domain Admin accounts, while another environment involved 1,531 compromised accounts. Multiple environments also lacked effective account lockout protections.

For organizations using cloud-based identity platforms, MFA should therefore be considered a core control rather than an optional security feature.

4. Stolen Sessions Can Bypass Traditional Defenses

Identity attacks are no longer limited to stealing usernames and passwords.

SISA reported the use of reverse-proxy phishing techniques that captured credentials as well as session cookies and authentication tokens. In one engagement, access remained available for more than 20 days, allowing the simulated attackers to access sensitive information.

This highlights an important distinction: authentication and session security are not exactly the same thing.

Even when MFA is successfully completed, organizations need controls that detect suspicious session behavior, token reuse, abnormal locations, and unusual access patterns.

Phishing-resistant authentication, conditional access, shorter session lifetimes, and anomaly-based session controls can help reduce this risk.

5. Source Code Can Become a Cloud Entry Point

Cloud credentials are also exposed outside traditional identity systems.

SISA found secrets in public source-code repositories, including AWS IAM keys, database credentials, SMTP credentials, JWT signing secrets, MongoDB and PostgreSQL credentials, and API tokens. In one case, an active AWS key was exposed directly through an HTTP response.

Developers may unintentionally expose credentials through:

• Public Git repositories
• Configuration files
• CI/CD pipelines
• Application responses
• DevOps scripts
• Container configurations
• Infrastructure-as-code files

Automated secret scanning, pre-commit controls, centralized secret management, and continuous monitoring of public repositories can help identify these exposures earlier.

6. On-Premises Breaches Can Lead to Cloud Compromise

Another important finding from SISA’s Red Team work is that attackers do not necessarily need to start inside the cloud.

In one scenario, the Red Team gained an on-premises foothold through targeted phishing. From there, they identified DevOps scripts and container orchestration files containing Azure keys. Those credentials became a bridge into the cloud environment.

After gaining cloud access, the simulated attackers were able to escalate privileges, create resources, and access sensitive information.

This shows why organizations should not treat on-premises infrastructure and cloud environments as isolated security domains.

Attackers look for connections between them.

7. Cloud Visibility Must Extend Across Regions

Cloud monitoring can create another blind spot when organizations focus only on their primary workloads or regions.

In SISA’s AWS Red Team scenario, resources were enumerated in lesser-used regions, and new instances were created in an area where monitoring was not as strong.

This is a valuable reminder that cloud security monitoring should cover the entire environment.

Security teams should understand:

• Which regions are authorized
• Which accounts can create resources
• Which identities can change IAM policies
• Which services are enabled
• Where sensitive data is stored
• Which cloud logs are being collected
• Whether alerts are generated consistently across regions

A security control that works only in one region does not provide complete cloud visibility.

8. Cloud Misconfigurations Can Expose Sensitive Data

SISA’s forensic-driven findings also show that cloud misconfiguration can directly contribute to data exposure.

In its 2023–24 findings, SISA reported that 2% of investigated cases involved data exfiltration resulting from cloud misconfigurations in Amazon S3 buckets.

Cloud storage should therefore be reviewed for:

• Public exposure
• Excessive permissions
• Incorrect bucket policies
• Weak access controls
• Unused credentials
• Missing encryption controls
• Insufficient logging
• Unmonitored data access

Regular cloud security assessments can help identify these issues before they become part of a real attack path.

9. Red Teaming Shows How Individual Gaps Become Attack Chains

A vulnerability scanner may identify an exposed credential.

An IAM review may identify excessive permissions.

A cloud assessment may identify an exposed storage bucket.

An identity assessment may identify missing MFA.

But real attackers can combine these weaknesses.

This is where Red Teaming provides a different perspective.

SISA describes Red Team engagements as realistic adversary simulations designed to understand how attackers gain access, move through environments, remain undetected, and reach business-critical objectives. The approach includes attack-path design, stealthy execution, detection and response evaluation, and evidence-backed reporting.

Instead of asking only, “Is this vulnerability present?” Red Teaming asks a broader question:

“What can an attacker achieve by chaining these weaknesses together?”

How Organizations Can Reduce Cloud and Identity Security Gaps

Organizations can strengthen their cloud and identity security by focusing on several areas.

Strengthen Identity Controls

Enforce phishing-resistant MFA across externally accessible systems, apply conditional access, remove unnecessary privileged access, and implement smart lockout policies.

Apply Least Privilege

Regularly review IAM permissions and remove unnecessary access from users, service accounts, applications, and third-party integrations.

Protect Secrets

Use automated secret scanning, pre-commit hooks, centralized vaulting, and continuous monitoring for exposed credentials.

Improve Cloud Monitoring

Monitor authentication activity, IAM changes, resource creation, unusual regions, storage access, and other high-risk cloud events.

Connect On-Prem and Cloud Security

Treat identity and credentials as common attack paths across hybrid environments. A compromise in one environment should trigger investigation of connected cloud resources.

Test Real Attack Paths

Red Team exercises can help organizations understand whether their controls actually detect and contain a realistic multi-stage attack. SISA recommends objective-driven testing based on realistic adversaries rather than simply measuring the number of alerts generated.

Conclusion

SISA’s Red Teaming findings demonstrate that cloud security failures are often closely connected to identity weaknesses.

An exposed IAM key, missing MFA, excessive permissions, leaked source-code secrets, weak monitoring, or an insecure connection between on-premises and cloud infrastructure may appear to be separate issues. During a realistic attack, however, they can become connected steps in a single attack path.

As organizations continue moving applications and data to cloud platforms, security teams need visibility across identities, credentials, permissions, workloads, APIs, regions, and connected infrastructure.

The goal is not simply to prevent attackers from getting in. It is to understand how far an attacker could move if one identity or cloud resource were compromised — and whether the organization would detect and stop that movement in time.

That is where continuous cloud security assessment, strong identity controls, threat hunting, and realistic Red Teaming can provide valuable insight.