Cloud security analytics: detecting attackers who use valid credentials

The most consequential cloud breaches of the past two years did not begin with malware. They began with a login. Attackers arrived holding valid credentials or authorized OAuth tokens, made well-formed calls to legitimate application programming interfaces (APIs), and left nothing malformed for a signature to match. That reality is what cloud security analytics answers. This guide defines the term precisely, explains how the analytics pipeline works, walks through two canonical breaches to show why signatures go quiet, and maps the practice across Amazon Web Services (AWS), Azure, and Google Cloud — including the telemetry economics and framework alignment most explanations skip.

What is cloud security analytics?

Cloud security analytics is the practice of applying detection analytics to cloud-native telemetry — control-plane audit logs, identity and token events, API call patterns, and workload and flow data — to surface attacker behavior. It is distinct from cloud business intelligence, from any single security information and event management (SIEM) product, and from the posture-at-rest checks of cloud security posture management (CSPM).

Each neighboring term answers a different question. The broader practice AWS defines as security analytics — collecting and analyzing security data to detect threats — becomes cloud security analytics when the telemetry itself is cloud native and the behaviors under analysis belong to identities and APIs rather than endpoints. The discipline operates as the detection layer of cloud security, alongside prevention and posture controls. It is emphatically not business analytics, even though the two share data pipelines.

The 2026 evidence explains why the discipline now stands on its own. Across Mandiant incident response and managed threat detection engagements in H2 2025 — a platform-agnostic view of major cloud and software-as-a-service (SaaS) intrusions — identity compromise underpinned 83% of cases, attackers targeted data in 73%, and vulnerability exploitation accounted for only 2% (Threat Horizons H1 2026). Carry those scope labels — the figures describe investigated intrusions, not every alert in every tenant.

The all-breach landscape looks different, and the population labels matter. Verizon's 2026 Data Breach Investigations Report (DBIR) found vulnerability exploitation in 31% of breaches — surpassing stolen credentials for the first time in 19 years — with third-party involvement climbing to 48% — up 60% year over year (Verizon DBIR 2026). M-Trends 2026, likewise an all-environment dataset, put 2025's global median dwell time at 14 days, up from 11, and found exploits the leading vector for the sixth consecutive year at 32% (M-Trends 2026). Read together, they say one precise thing — across all breaches, exploits lead, but inside major cloud and SaaS intrusions, identity dominates. Identity abuse is exactly the surface signatures cannot see.

Cloud security analytics vs cloud analytics, SIEM, and CSPM

This is the clarification most explanations miss, and it changes what you buy and build. Cloud analytics answers business questions — usage, revenue, product behavior — through business intelligence pipelines. A SIEM is a product and an architecture, a place where detection content can run. CSPM evaluates configuration at rest — public buckets, over-permissioned roles — before any attacker shows up. Cloud security analytics detects active attacker behavior in cloud telemetry as it unfolds. The table below separates the four.

Four commonly conflated terms — cloud security analytics detects behavior, cloud BI informs business decisions, a SIEM aggregates logs, and CSPM checks posture at rest.

How cloud security analytics works

Cloud security analytics turns high-volume cloud telemetry into prioritized, behavior-based detections. The pipeline is consistent across providers even when the log names differ, and it compresses into five stages:

1. Collect cloud telemetry across providers, accounts, and workloads.
2. Normalize and enrich events with identity, asset, and threat context.
3. Baseline normal behavior for every human and non-human identity.
4. Correlate events and apply behavioral analytics across sources.
5. Alert on meaningful deviations and prioritize by risk.

‍

‍

The raw material is cloud-native telemetry. Control-plane audit logs — AWS CloudTrail, Google Cloud Audit Logs, and Entra ID sign-in and audit logs — record every management action and API call in an environment. Identity and token events capture authentications, grants, and consents. API call patterns show what each identity actually does, while workload and network flow data show how data moves. Google's reference architecture describes the operational sequence for getting this right — enable the right logs, route them to an analysis destination, then analyze them there — in its security log analytics guidance.

Normalization deserves emphasis because cloud providers do not agree on schemas. The same conceptual event — an identity assuming elevated privileges — looks completely different in CloudTrail, Entra ID audit logs, and Google Cloud Audit Logs. Enrichment then attaches what raw events lack, including asset criticality, identity ownership, and threat intelligence context.

What makes the discipline cloud specific is the nature of the resources. Cloud infrastructure is ephemeral, API driven, and identity centric — workloads live for minutes, every action is an API call, and identity is the effective perimeter. The detection signal is therefore behavioral deviation from a learned baseline, not a malformed payload. That is why user and entity behavior analytics (UEBA) sits at the center of the practice, and why network anomaly detection extends the same baselining logic to the traffic that moves between workloads.

The last two stages are where analytics earns its keep operationally. Correlation stitches isolated events — a new sign-in, a permission change, a spike in data reads — into one attack narrative, and prioritization ranks that narrative against everything else competing for attention. Done well, this is the antidote to alert fatigue. It is also what moves the two numbers most security operations centers (SOCs) are measured on — mean time to detect (MTTD) and mean time to respond (MTTR) — because analysts start from a short, ranked list instead of a raw event stream.

Why signature-based detection fails in the cloud

When an attacker authenticates with valid stolen credentials or an authorized token, behavioral analytics is often the only detection surface left. Signatures match known-bad artifacts — malware hashes, exploit payloads, malicious domains. A successful login through an approved API produces none of them. There is no failed authentication, no dropped binary, and no exploit traffic to inspect. This is the shared blind spot in signature-only tooling and rule-only SIEM deployments.

‍

The 2024 campaign against Snowflake customer environments, tracked as UNC5537, is the canonical case (Google Threat Intelligence's UNC5537 analysis). Attackers used credentials stolen by infostealer malware — 79.7% of them had prior exposure, and some had gone unrotated for four years — against accounts lacking multi-factor authentication (MFA) and network allow-lists. Roughly 165 organizations were notified. No vulnerability was exploited, and no malware touched the platform. Every attacker action was an authenticated, well-formed query.

That left defenders three kinds of signal, all behavioral — impossible travel between logins, unfamiliar client applications and fingerprints, and query volumes far outside an account's baseline. Behavioral analytics built on those baselines, paired with identity analytics that scores how each account normally authenticates, is the detection-engineering answer, alongside the preventive basics the victims lacked.

The 2025 Salesloft Drift incident, tracked as UNC6395, extended the lesson from passwords to tokens (Google Threat Intelligence's UNC6395 analysis). Attackers compromised OAuth tokens from the Drift integration and used them to run well-formed SOQL (Salesforce Object Query Language) queries against numerous Salesforce customer instances — the primary reporting says only "numerous." No individual request was malformed. The tells were aggregate and behavioral — API call volume, query shape, and user-agent deviations from the integration's established baseline. This is why identity threat detection and response (ITDR) programs treat non-human integrations as first-class identities.

The pattern has continued into 2026 along two distinct tracks. July 2026 reporting mapped a year-long OAuth abuse wave associated with the ShinyHunters extortion ecosystem (The Hacker News). A separate voice-phishing campaign guided victims through enrolling attacker-controlled passkeys in Entra ID, converting a phishing-resistant control into a durable foothold (Help Net Security). Different operations, same detection problem — valid identity artifacts (tokens, session cookies, passkeys) driving legitimate APIs.

Exploits still happen in the cloud — with an important scope label. In Google Cloud's own platform telemetry, a population distinct from the Mandiant engagement data, remote code execution (RCE) rose as an entry vector from 2.9% in H1 2025 to 13.6% in H2 (Threat Horizons H1 2026).

When exploitation does occur, weaponization outruns signature distribution. React2Shell (CVE-2025-55182) is a pre-authentication RCE in React Server Components rated a maximum 10.0 on the Common Vulnerability Scoring System (CVSS) (React security advisory). It was under active exploitation within roughly 48 hours of disclosure — the Cybersecurity and Infrastructure Security Agency (CISA) added it to the Known Exploited Vulnerabilities catalog on December 5, 2025, two days after the advisory, citing evidence of active exploitation (CISA alert). Behavioral analytics closes part of that gap too — a workload that suddenly spawns a cryptominer breaks its baseline before a signature ships.

Cloud security analytics use cases and techniques

The same analytical core supports a family of use cases, each asking a behavioral question no signature can answer. SOC analysts use these detections for triage, threat hunters for hypothesis testing, and compliance teams as evidence of monitoring coverage. The payoff is earlier detection, fewer false positives, and shorter investigations. All of them build on the baselining stage of the pipeline.

• Behavioral baselining for human identities. UEBA-style models learn each user's normal sign-in geography, hours, and clients, then flag impossible travel, out-of-hours access, and first-seen applications.
• Anomaly detection on API activity. Scoring call volume, call mix, geography, and client fingerprint against each identity's baseline catches token theft and automation abuse early.
• Insider threat and exfiltration detection. Query-volume spikes and unusual data access expose insider threats and staged data theft, while network traffic analysis confirms how data actually moved.
• Threat intelligence enrichment. Correlating cloud telemetry with curated threat intelligence turns an odd login into a known-infrastructure match — and prioritizes it accordingly.

Two of these deserve emphasis because they anchor investigations. Exfiltration detection in the cloud is largely a query-and-egress problem — in the Snowflake campaign, the durable signals were query volumes and patterns far outside account baselines. And enrichment converts an anomaly into a decision — the same login scores differently when its source infrastructure is already tied to credential-stuffing campaigns.

Machine and non-human identity analytics

Service accounts, API keys, and OAuth tokens now vastly outnumber people in most cloud estates. A 2026 Tenable-authored analysis hosted by the Cloud Security Alliance (CSA) puts the ratio of machine to human identities at roughly 100-to-1. Tenable's Cloud and AI Security Risk Report 2026 separately found that 65% of organizations harbor forgotten "ghost" cloud credentials — identities nobody owns, rotates, or monitors.

Those ghosts are not hypothetical. The years-old, unrotated credentials behind the UNC5537 campaign sat in exactly that category. Non-human identities also behave nothing like people — no working hours, no travel, and highly regular call patterns — so they need baselines of their own, separate from human UEBA. A service account that suddenly authenticates interactively, expands its scope, or queries a new dataset is one of the highest-signal detections cloud security analytics produces.

Cloud security analytics vs SIEM and adjacent categories

A SIEM is where analytics can run — cloud security analytics is the behavior-detection capability that runs there. They are complementary, not competing. Confusion here is expensive — teams either buy a second product they did not need or assume their log aggregation already detects cloud attacks. The table below draws the boundaries, including the adjacent platform categories buyers encounter.

Cloud security analytics is a capability, while SIEM, CDR, and CNAPP are the products and platforms it runs on or ships inside.

SIEM platforms remain the aggregation, correlation, and compliance backbone for many teams, and that is precisely the point — the product question is separate from the capability question. Cloud detection and response (CDR) platforms answer the capability question directly, packaging cloud-native behavioral analytics with response actions for teams that want detection content maintained for them. The practical relationship often runs through cost — teams use cloud analytics to decide which telemetry earns SIEM ingestion and which routes to cheaper storage, a tradeoff the next section quantifies.

The adjacent acronyms describe scope, not competition. A cloud-native application protection platform (CNAPP) bundles posture and workload protection across the application lifecycle. CSPM assesses configuration at rest, a cloud workload protection platform (CWPP) guards the compute layer, and cloud infrastructure entitlement management (CIEM) governs who can do what. None of them replaces behavioral detection — they reduce and map the attack surface that analytics then watches. The identity-led intrusion evidence of 2026, with 83% of major cloud and SaaS cases underpinned by identity in Mandiant engagements (Threat Horizons H1 2026), explains why every one of these categories keeps converging on identity behavior.

The market has already voted on the capability-versus-product question. Standalone cloud security analytics products have repeatedly been discontinued or absorbed into broader detection and posture platforms. Treat the term as a capability you require — in a SIEM, a security data lake, or a CDR platform — rather than a box on the architecture diagram.

The economics of cloud telemetry

Cloud security analytics is only as good as the telemetry you can afford to keep. Ingest cost is the central practitioner objection to every telemetry-hungry architecture, and it is the honest reason security data lakes exist — separating cheap storage from selective detection.

Volume grows faster than budgets, and not all logs earn their keep. Data-access audit logs are the classic offender — Google's implementation guidance devotes specific attention to managing Data Access audit-log volume before routing anything (security log analytics guidance). The discipline is telemetry selection. Control-plane and identity logs carry the highest detection value per gigabyte, while verbose data-plane logs earn ingestion only where the assets justify it. That selection work is what keeps cloud security monitoring sustainable as estates grow.

Retention tiering resolves the ingest-versus-detection tradeoff. Keep live-detection telemetry hot, keep investigation telemetry warm, and keep hunting telemetry cold — still searchable, but priced like archive storage.

Tiered retention keeps high-value telemetry queryable for hunting without paying hot-storage prices for everything.

Retention is not a compliance checkbox — it decides what an investigation can see. During the UNC5537 campaign, Snowflake's default retention gave investigators a 365-day window of account activity to hunt across (the UNC5537 investigation). Organizations with shorter windows simply have less history to reconstruct.

The benchmarks frame the stakes. The Ponemon Institute's Cost of a Data Breach study put the 2025 global average at $4.44 million with 241 days to identify and contain a breach — all-environment figures, with the 2026 edition imminent (Help Net Security). Cloud remediation timelines argue the same urgency. In Push Security's review of the 2026 DBIR cloud findings, only 23% of third-party organizations had fully remediated cloud MFA gaps, and the median organization needed eight months to resolve 50% of its password and permission-misconfiguration findings (Push Security).

Implementing cloud security analytics across AWS, Azure, and GCP

The telemetry names change across providers — the behavioral questions do not. Google's reference architecture frames the question families every estate should answer: login and access anomalies, permission changes, provisioning activity, data access, and network patterns (security log analytics guidance). The table below maps those questions to each provider's key sources.

The same behavioral question families apply to every provider once its control-plane and identity telemetry is flowing.

Most enterprises answer those questions in several places at once. A multi-cloud security program normalizes provider log schemas into one analytical layer, so a single baseline logic applies everywhere. Provider-specific depth still pays — AWS threat detection, for example, layers CloudTrail data events and flow logs over the management plane to catch what account-level logs miss.

Containers add a cross-cloud workload surface. Kubernetes audit logs and runtime events look the same wherever the cluster runs, which makes Kubernetes security telemetry a natural unifier — and extends the same baselines into hybrid cloud security architectures where workloads span data centers and clouds.

Monitor the identity provider (IdP) itself, not only the workloads behind it. CVE-2026-40379, a 2026 spoofing vulnerability in Entra ID, was scored 9.3 by its CVE Numbering Authority (CNA) and 7.5 by the National Institute of Standards and Technology (NIST) (NVD record). When the IdP is the target, its own sign-in and audit telemetry becomes the detection surface.

Mapping to MITRE ATT&CK v19 and compliance frameworks

MITRE ATT&CK v19, released April 28, 2026, restructured how evasion is modeled. The former Defense Evasion tactic was retired and split into Stealth (TA0005) and Defense Impairment (TA0112) — the latter covering adversaries who break security mechanisms, pipelines, and tooling so defenders cannot see or trust what is happening. The ATT&CK cloud matrix spans 12 tactics across four platforms — Office Suite, Identity Provider, SaaS, and IaaS (infrastructure as a service) — and gives detection engineers a shared vocabulary for the behaviors this guide describes.

A starting map from ATT&CK v19 cloud tactics to the behavioral detections cloud security analytics can provide.

Compliance mapping follows naturally. Within the NIST Cybersecurity Framework (CSF) 2.0, published in 2024, the practice sits in the Detect function — one of the framework's six — under categories DE.CM and DE.AE (NIST). The CSA Cloud Controls Matrix v4, with 197 controls across 17 domains, carries the equivalent requirements in its Logging & Monitoring (LOG) domain (CSA CCM).

NIS2 (Directive (EU) 2022/2555) requires, under Article 23, an early warning within 24 hours of awareness of a significant incident, an incident notification within 72 hours, and a final report within one month. DORA (Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025 — reporting clocks that tight put a visible premium on detection speed.

Modern approaches to cloud security analytics

The field is converging on three moves. Detection is going identity first, because that is where the verified evidence points — identity underpinned 83% of major cloud and SaaS intrusions in Mandiant's H2 2025 engagement data (Threat Horizons H1 2026). Standalone analytics tools keep consolidating into platforms, from SIEM-hosted content packs to cloud detection and response platforms. And AI-assisted triage and hunting are becoming standard, because lean teams cannot manually stitch cross-surface behavior at cloud speed.

For buyers, three criteria separate durable platforms from dashboards. Look for unified visibility across cloud, identity, and SaaS surfaces. Insist on behavioral detections that keep working after credentials are stolen — the identity threat detection and response test. And weigh signal quality over alert volume, measured by what a small team can actually investigate.

How Vectra AI thinks about cloud security analytics

Vectra AI approaches cloud security analytics from an assume-compromise stance. Attackers increasingly arrive with valid identities, so the methodology prioritizes attack-signal clarity across network, identity, cloud, and SaaS — surfacing the behavior that reveals an active attacker rather than the signatures that valid-credential abuse never trips. In practice, that means baselining every identity, human and machine, stitching deviations across surfaces into one attack narrative, and elevating the few signals that indicate real progression over raw alert volume.

Conclusion

Cloud security analytics earns its own name because the cloud changed what detection must find. Attackers who arrive with valid credentials and tokens defeat signatures outright — the defining breaches of 2024 and 2025 produced no malware, no exploits, and no failed logins, only behavior that drifted from baseline. The answer is a discipline, not a single product. Collect the control-plane, identity, API, and workload telemetry that matters. Baseline every identity, human and machine. Tier retention so hunting stays affordable. Map detections to the ATT&CK v19 cloud matrix and the frameworks auditors recognize. Teams that treat cloud security analytics as a capability — wherever it runs — will keep finding the attackers their signatures never see.

‍