Introduction: The Controls Were Watching the Wrong Layer

The shift to cloud platforms and identity-centric infrastructure has quietly changed where attacks happen — and, just as importantly, where they don't. In SISA's red teaming engagements, the most damaging cloud and identity findings shared a single trait: they never touched the layer the defenders were watching. No malware landed on disk. No traffic crossed a monitored network segment. The activity happened in memory, in the cloud control plane, and through legitimate identities, precisely where traditional endpoint and network monitoring has the least visibility.

Across multiple red teaming engagements SISA conducted between 2024 and 2026, one pattern consistently emerged: the security controls were deployed and working as configured. They were simply not watching the layer where the attack took place — in memory, in the cloud control plane, and inside trusted identities.

These findings point to a truth many organizations have not yet confronted: in cloud and identity environments, coverage on paper is not coverage in practice, and the most valuable ground is often the least monitored.

What SISA's Red Team Found During Cloud and Identity Assessments

One observation recurred across nearly every cloud and identity engagement: the initial foothold was rarely a broken control. It was a credential or key that should never have been reachable: sitting in a web response, baked into a mobile app, or waiting in a mailbox — and the access that followed generated no alert. The four findings below trace that pattern, from a single exposed secret to full control of cloud tenants and internal networks.

1. AWS Keys in a Web Response: No GuardDuty Alert

An AWS access key and secret key sat in plaintext inside a login page's JavaScript response. The key belonged to a long-lived Identity & Access Management (IAM) user with few restrictions, and the red team authenticated with it on the first attempt using the AWS command line. Nothing registered the access — no CloudTrail alert, no GuardDuty finding, during or after. A credential that was never meant to leave the server became working cloud access the environment could not see, the kind of exposure a dedicated cloud security assessment is built to catch.

Defensive priorities

• Never embed cloud credentials in application code or web responses; use IAM roles with the instance metadata service instead

• Enable GuardDuty in all regions and configure CloudTrail alerts for API calls from unexpected IP addresses

• Replace long-lived IAM keys with short-lived Security Token Service (STS) credentials and set key-expiry policies

• Use AWS Config rules to alert on any access key that has not been rotated in 90 days

2. Azure AD Enumeration via In-Memory Tooling

Offensive tooling loaded entirely in PowerShell memory bypassed endpoint detection that relies on scanning files written to disk. From there, the red team retrieved user lists, email addresses, SharePoint file inventories, and the full org structure, and continued enumerating the cloud tenant until the blue team network-isolated the device. In a parallel effort, AzureHound running inside a portable Parrot OS virtual machine produced a complete identity attack-path map with no endpoint alerts generated at all. The same techniques an attacker uses to walk a cloud identity estate are exactly what a focused Active Directory penetration test is designed to surface.

Defensive priorities

• Enable Anti-Malware Scan Interface (AMSI) inspection for in-memory PowerShell and alert on remote-download-and-execute patterns

• Require a compliant, managed device for all Microsoft 365 and Azure access through Conditional Access

• Restrict Graph API permissions to least privilege and throttle bulk enumeration

• Block hypervisor and virtual-machine process creation on managed endpoints via endpoint policy

3. Mobile App Reverse Engineering: Hardcoded API Keys

The red team decompiled the organization's Android app, altered its manifest to allow cleartext traffic, disabled certificate pinning, and switched on debugging. The repackaged app then intercepted all of its own API traffic. Inside the binary sat live third-party keys — Google Maps, Mapbox, and Algolia — all validated as active and all billable to the organization by any outside party who extracted them. Reverse-engineering exposure of this kind is a core focus of mobile application security testing, which most security assessments miss.  

Defensive priorities

• Implement certificate pinning against a server-managed trust store, never one hardcoded in the app

• Enable code obfuscation (ProGuard/R8) alongside integrity and tamper detection

• Never store API keys in the app package; route third-party calls through a server-side proxy

• Lock keys in the provider console to specific app signatures, IP ranges, or referrers

4. Password Spray → VPN Access → Full Internal Network

Compromised Microsoft 365 credentials opened the user's Outlook mailbox — and inside it, the red team found the internal VPN configuration files. Using the same credentials, they authenticated to the corporate VPN successfully: no device-posture check, no separate second factor for VPN access. Full internal network access followed, obtained remotely with no physical presence, and internal applications were reachable from there. A single reused credential collapsed the boundary between a mailbox and the internal network — a pivot that network penetration testing is designed to expose before an attacker finds it.

Defensive priorities

• Enforce MFA on the VPN separately from SSO; VPN access needs its own second factor

• Require device-posture checks before VPN access: OS version, EDR presence, disk encryption, managed-device status

• Alert on VPN logins from devices or geographies not seen in the previous 30 days

• Never store VPN configuration files in corporate email; distribute them through Mobile Device Management (MDM) or a secure portal only

SOC Playbook: Cloud and Identity Attack Detection & Response

Cloud and identity attacks are hard to catch because, individually, each action looks legitimate. Based on patterns observed during SISA's Red Team engagements, security teams should concentrate detection and response on in-memory execution, cloud activity that falls outside the administrative baseline, and access that bypasses the endpoint entirely.

Detection Priorities

Security teams should continuously monitor for:

1. In-memory PowerShell execution — AMSI-flagged use of IEX (Invoke-Expression) and remote-download cmdlets such as IWR, especially where no corresponding file is written to disk

2. Authenticated cloud API activity — AWS CLI or Graph API calls from IP addresses, ASNs, or geographies outside the normal administrative baseline

3. Hypervisor or virtual-machine processes launching on managed endpoints, a common way to run tooling outside the view of host EDR

4. Bulk directory or resource enumeration against Microsoft 365, Azure AD, or Graph — high-volume user, mailbox, or SharePoint inventory reads in a short window

5. VPN authentications from new devices or locations, and VPN logins that succeed with no device-posture or second-factor check

Response Priorities

When cloud or identity compromise is suspected:

1. On an exposed cloud key, revoke and rotate it immediately, move the workload to short-lived role-based credentials, and review activity logs for the entire window the key was valid

2. On in-memory tooling, network-isolate the endpoint, capture volatile memory before any reboot, and hunt for the same technique across peer devices

3. On confirmed cloud enumeration, review API permission grants, revoke excess scopes, and reset credentials for every identity that was accessed

4. On mobile-key abuse, rotate the exposed third-party keys, restrict them to app signatures and referrers in the provider console, and reissue a hardened build

5. On VPN compromise, force re-authentication behind a VPN-specific second factor, enforce posture checks, and audit every internal system reached during the session

Final Perspective

None of these findings required defeating a security control. Each one exploited a blind spot beside it. This is the gap that compliance checklists and dashboards of "deployed" controls consistently miss; often arising from implementation draft, scope boundary failures and framework evolution lag, as highlighted in SISA’s Digital Threat Report 2025-26. They confirm that a capability exists; but do not necessarily prove control survivability under adversarial pressure. Only adversary simulation — red team engagements that chain an exposed key to a cloud tenant to an internal network — reveals where visibility ends and exposure begins, because finding those seams requires operating in them.

Because in cloud and identity environments, a deployed control and a watching control are not the same thing; and attackers have learned to live in the space between them.