惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
aimingoo的专栏
aimingoo的专栏
月光博客
月光博客
博客园 - Franky
Martin Fowler
Martin Fowler
U
Unit 42
阮一峰的网络日志
阮一峰的网络日志
Recent Announcements
Recent Announcements
The Cloudflare Blog
博客园 - 聂微东
酷 壳 – CoolShell
酷 壳 – CoolShell
宝玉的分享
宝玉的分享
J
Java Code Geeks
B
Blog RSS Feed
博客园 - 三生石上(FineUI控件)
MongoDB | Blog
MongoDB | Blog
腾讯CDC
博客园_首页
博客园 - 司徒正美
D
DataBreaches.Net
I
InfoQ
GbyAI
GbyAI
IT之家
IT之家
罗磊的独立博客

Vectra AI Blog

Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Why You Need an NDR to Protect Your Modern Network Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI Vectra AI named in Gartner hype cycle for security operations 2025 Vectra AI Vectra AI How Sanofi Detected and Stopped a Cyberattack How MITRE ATLAS Helps Detect LLM Attacks in Cloud AI Detecting Iranian APT identity attacks across hybrid environments Vectra AI Vectra AI Vectra AI Breaking down the axios supply chain incident Vectra AI Vectra AI
Vectra AI
Zoey Chu · 2026-06-24 · via Vectra AI Blog

Picture a modern cloud attack: a successful login, an over-permissioned app, a token that survives remediation, and a connection that blends into normal cloud traffic.

This is not hypothetical. Microsoft has reported that Midnight Blizzard, also tracked as APT29 and NOBELIUM, used password spraying to compromise a legacy non-production tenant account without MFA, then used that foothold to abuse OAuth applications, move laterally, and access and exfiltrate corporate email. NSA and partners have warned that APT29 targets cloud-hosted infrastructure through inactive and automated accounts, and can use tokens, device registration, and proxy infrastructure to maintain access and obscure activity.

APT29 is not an outlier. Storm-0558 used forged authentication tokens to access cloud-hosted email, while Storm-0501 shows financially motivated actors moving from hybrid environments into cloud data theft and disruption.

That is the cloud problem in miniature: the attack is real, but the evidence is scattered across identity, application permissions, cloud administration, data access, and network behavior.

For years, cloud security has been built around partial views: control-plane logs, packet capture where deployment was practical, and SIEM timelines reconstructed after the fact. Each approach has value. None of them, on its own, gives defenders the connected picture of how an attack moves through the cloud.

Attackers do not move according to how security tools are organized. They move through identities, APIs, workloads, services, and network paths, leaving defenders to connect too much, too manually, and too late.

Cloud security has a correlation problem

Most organizations do not lack cloud security data. They have posture findings, identity alerts, native cloud logs, workload signals, network telemetry, and SIEM events. The problem is that these signals often live in different tools, belong to different teams, and speak the language of different cloud providers.

That fragmentation creates room for attacks to hide. A compromised identity, a permission change, a new workload, and an unusual outbound connection may each appear in different places. Alone, each can look explainable. Together, they may describe an attack moving through the environment.

For risk owners and security leaders, this creates a dangerous illusion: the organization can see many parts of the cloud but still misses how risk is unfolding. For practitioners, it creates a daily burden of pivoting across consoles, stitching together timelines, translating provider-specific logs, and deciding whether seemingly unrelated events represent a sequence of attacker behaviors mapped to the MITRE ATT&CK framework. What may appear as isolated signals, in reality, represent reconnaissance, credential access, privilege escalation, lateral movement, or persistence unfolding across the cloud. The issue is not visibility in one place. It is the lack of correlation across the places attackers move.

Multi-cloud makes the visibility gap harder to ignore

Most enterprises do not operate in one clean cloud. They run AWS and Azure, use GCP for analytics or AI, rely on OCI for enterprise applications, or inherit new cloud estates through acquisition.

Each cloud adds its own identity model, logging format, network abstraction, and operational language, making manual correlation harder exactly when defenders need it to be faster. Just as a team starts to understand what an attacker is doing in one cloud, the attack may already be unfolding somewhere else.

Attackers exploit this. UNC3944, a.k.a. Scattered Spider, has been observed targeting identity providers, SaaS security gaps, and cloud platforms including Azure, AWS, and GCP, abusing permissions, virtualization platforms, and cloud synchronization tools to move laterally and steal data. Multi-cloud environments do not create the problem. The problem already exists. Multi-cloud environments compound it.  

Example of a hybrid, multi-cloud attack path

A hybrid, multi-cloud attack rarely respects organizational or cloud boundaries. The attacker follows identities, permissions, workloads, and trust relationships wherever they lead. The challenge for defenders is that the investigation often becomes fragmented across cloud-native tools even though the attack itself remains connected.

And that challenge is only getting harder as attackers move faster. Recent research demonstrated an autonomous AI system exploiting vulnerabilities, harvesting credentials, and moving laterally through cloud environments without human intervention. Activities that once unfolded over hours or days can increasingly occur in minutes. Defenders are not just dealing with fragmented visibility; they’re dealing with less time to connect the dots.

Learn more about how attackers move with our ebook.

The control plane shows change. Flow logs show movement.

A cloud attack often starts in the control plane: an identity authenticates, an identity and access management (IAM) policy changes, a key is created, a role changes, a security group opens, or a workload is launched. Those signals matter. They show who did what, what changed, and what access may now be possible. But they do not always show what that access enables.

The cloud network plane shows how workloads, services, applications, and users communicate: whether a new workload reached a sensitive database, a service contacted an unfamiliar destination, or traffic moved between environments that should not normally interact.

In an investigation, those details have to come together quickly. A new key, a routine-looking workload connection, and a harmless-looking outbound flow may be easy to dismiss separately. Connected in time, they may show an identity being used to create access, move through the environment, and reach data.

Packets provide deep visibility where they are practical. But in dynamic, multi-cloud environments, broad packet collection can be complex to architect, scale, and maintain. Flow logs offer a more scalable way to observe cloud network-plane behavior: which systems communicated, over what ports and protocols, in what direction, and with what volume or pattern.

But flow logs are still another signal unless they are connected to identity, control-plane activity, workload context, and attacker behavior. That correlation turns cloud telemetry into actionable detection before stages of impact.

The next step is unified cloud observability and detection

A cloud strategy that depends on every team interpreting every provider separately will struggle to keep pace. Even Zero Trust depends on connected visibility. Defenders need connected visibility to validate that identity, control-plane changes, and workload behavior align with what is happening in the cloud network plane, where applications communicate, services interact, data moves, and the business truly operates.

The answer is not another dashboard, raw log stream, or another alert that sends analysts back into the same manual investigation loop. Cloud security must move from collecting telemetry to connecting behavior.

Security teams need to know, in real time, whether identity activity, control-plane changes, workload behavior, and cloud network-plane communication are part of the same attack. Existing tools are useful, but too often they leave defenders with fragments: posture, identity, traffic, and logs. In a fast-moving cloud attack, fragments are not enough. In addition, teams also need cloud detection and response capabilities, supported by AI-driven investigation tooling and response capabilities that turn connected signal into context, guidance, and action at the speed modern attacks demand.

The means connecting signal at speed across planes and providers, so security teams can see the attack path while there is still time to act.

This is the driving force behind Vectra AI Platform’s expanded cloud network observability capabilities across Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and Oracle Cloud Infrastructure (OCI). The Vectra AI Platform brings control-plane and cloud-network-plane visibility together so organizations can detect cloud attacks as connected behavior across their multi-cloud environments, not as disconnected events.

As attackers use AI to compress timelines and move across domains, modern cloud security must connect the right signals fast enough to understand the attack before it becomes a breach.

Want to hear more from our Vectra AI team? Learn more about multi-cloud security with our latest podcast.