Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
The fastest way to fall in love with an AI tool is to watch the demo.
Everything moves quickly. Prompts land cleanly. The system produces impressive outputs in seconds. It feels like the beginning of a new era for your team.
But most AI initiatives don't fail because of bad technology. They stall because what worked in the demo doesn't survive contact with real operations. The gap between a controlled demonstration and day-to-day reality is where teams run into trouble.
Most AI product demos are built to highlight potential, not friction. They use clean data, predictable inputs, carefully crafted prompts, and well-understood use cases. Production environments don't look like that. In real operations, data is messy, inputs are inconsistent, systems are fragmented, and context is incomplete. Latency matters. Edge cases quickly outnumber ideal ones. This is why teams often see an initial burst of enthusiasm followed by a slowdown once they try to deploy AI more broadly.
What actually breaks in production
Once AI moves from demo to deployment, a few specific challenges tend to emerge.
Data quality becomes a real issue. In security and IT environments, data is often spread across multiple tools with different formats and varying levels of reliability. A model that performs well on clean demo data can struggle when fed noisy or incomplete inputs.
Latency becomes visible. A model that feels fast in isolation can introduce meaningful delays when embedded in multi-step workflows running at scale.
Edge cases start to matter. Production workflows include exceptions, unusual scenarios, and unpredictable user behavior. Systems that handle common cases well can break down quickly when confronted with real-world complexity.
Integration becomes a limiting factor. Most operational work requires coordinating across multiple systems. If an AI tool can't connect deeply into those workflows, its impact stays limited regardless of how capable the underlying model is.
Governance is where enthusiasm runs out
Beyond technical challenges, governance has become one of the biggest reasons AI initiatives stall. With general-purpose AI tools now widely accessible, organizations are grappling with serious questions around data privacy, appropriate use cases, approval processes, and compliance requirements.
Many teams discover that while AI experimentation is easy, operationalizing AI safely requires clear policies and controls. Without them, even promising initiatives get stuck in review cycles or fail to scale.
When done properly, governance transcends its goal of preventing misuse. It becomes a framework that lets teams move quickly and confidently, with appropriate oversight built in from the start.
What determines whether AI actually delivers
Teams that successfully move beyond the demo tend to share a few habits. They test AI against real workflows rather than idealized scenarios, using real data, real processes, and real constraints. They evaluate performance under realistic conditions, measuring accuracy under load, monitoring latency, and understanding how the system behaves when inputs vary. They prioritize integration depth, because AI operating in isolation rarely has much impact. And they pay close attention to the cost model, since AI usage can scale quickly and without visibility into consumption, costs can become a blocker.
Perhaps most importantly, they invest in governance early. Clear policies, guardrails, and oversight mechanisms help teams avoid delays and build confidence in their deployments.
A practical checklist before you commit
If you're evaluating AI tools, a few steps can help surface limitations before they become blockers: run proofs of concept on high-impact, real-world workflows; use realistic data during testing; measure performance across accuracy, latency, and reliability; assess integration depth with your existing stack; and clarify governance requirements upfront.
These aren't complicated steps, but they make a significant difference in whether a promising demo leads to meaningful production deployment.
AI has real potential to change how security and IT teams work. But success depends less on the sophistication of the model and more on how well it fits into real workflows, integrates with existing systems, and operates within a clear governance framework. Teams that recognize this early are far more likely to move from experimentation to lasting impact.
Looking for a structured approach to evaluating AI tools in practice?The IT and security field guide to AI adoptionwalks through selection criteria, evaluation questions, and a step-by-step process for finding solutions that hold up beyond the demo.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/MfhFL71
via IFTTT
Unit 42 recently got hands-on with frontier AI models, and our initial findings indicate a major shift in the speed, scale and capability of AI models to identify software vulnerabilities. We are now seeing the first frontier models to demonstrate the autonomous reasoning required to function not merely as a coding assistant, but as a full-spectrum security researcher. This brings worrisome advancements in:
Autonomous zero-day discovery
Collapsing the patching window for N-days
Advanced chaining of complex exploitation paths
Real-time adaptation to bypass controls of hardened environments
The impact of frontier AI models on the threat landscape goes way beyond vulnerability discovery and exploitation. As these models become widely available in the near future, we are likely to see dramatic increases in the speed and scale of AI-enabled attacks across the entire attack lifecycle.
Frontier Models Exposing the Fragility of Our Software Ecosystem
As discussed at length by our colleagues at Anthropic, frontier AI models are a significant advancement in the capabilities of AI models. These models can, with minimal human expertise, identify vulnerabilities in systems and software. They can also analyze attack paths, including identifying complex exploit chains.
Our initial threat assessment is that frontier AI models will significantly increase the risk of zero-day and N-day vulnerabilities in software. They lower the barrier to entry for unskilled attackers to find complex exploit chains, while also dramatically accelerating the vulnerability discovery-to-exploitation cycle.
Open Source Software and Supply Chain Risks
Open source software (OSS) in particular may face significant risks from frontier AI models, at least in the short term. It has traditionally been considered that “given enough eyeballs, all bugs are shallow.” However, the transparency of exposing source code resulted in some striking observations in our tests of frontier AI models.
When we run them against source code, frontier AI models demonstrate a strong ability to identify vulnerabilities and complex exploit chains. When we test the models against compiled code (the executable version of code), however, we see only marginal advancements compared to publicly available AI models. Consequently, open-source software faces a greater immediate risk.
It is crucial to remember that nearly all commercial software incorporates open-source components within its compiled code.
To be clear, Unit 42 does not believe that OSS is inherently more vulnerable than commercially available software. We assess OSS has a heightened risk of being compromised due to the open nature of the software development ecosystem. This includes the availability of public source code for threat actors to rigorously test for vulnerabilities beyond the visibility of defenders, and the limited number of maintainers (and their time) for many OSS projects.
Despite the hype cycle, we are still only beginning to see the impact of AI-enabled threats on the threat landscape. Yes, we have seen incredible gains in the speed and scale of attacks leveraging AI in multiple cases and through security researcher testing. To date, these incidents still represent a very small percentage of the overall threat activity Unit 42 tracks.
That said, threat actors continue to invest in AI research and testing capabilities. As we noted in our threat research into a few AI-related malware samples, we see threat actors testing AI for:
Writing malware
Remote decision making (e.g. augmenting or replacing a C2 operator)
Local decision making (e.g. locally executed agentic attack flows)
With the advancements and public release of frontier AI models, Unit 42 believes the threat landscape is likely to see the rapid increase in speed, scale and sophistication of cyberattacks that we have warned about. Most critically, we don’t need to teach frontier AI models how to hack. They already know how to do it and can do it autonomously.
We will illustrate a few areas where we believe we will see advanced usage of AI using a common attack path. In this case, we will apply the thought experiment to spear phishing leading to data exfiltration for extortion:
Reconnaissance: An attacker leverages frontier models to rapidly scrape the internet for targeting intelligence. This includes:
Identifying key leaders and their contact information via press releases, LinkedIn and corporate websites
Identifying software used in the environment via job postings, press releases for partnering agreements
Finding other available information to inform the large language model (LLM) to write well crafted spear-phishing emails, texts or audio scripts for social engineering attacks
Initial access: A human reviews the reconnaissance data and the draft phishing emails and sends them to targets with malware attached. An AI agent on the command-and-control (C2) server waits for the malware to check in after initial delivery.
Lateral movement and discovery: A Model Context Protocol (MCP) server autonomously instructs the installed malware to:
Scan inside the network
Map what it can see
Identify running software versions
Gather exposed credentials on endpoints and in databases
Move laterally across devices collecting sensitive data as it goes
The agent automatically tests each set of credentials as they are discovered, enumerates their privileges and tracks success/failure statistics automatically.
Exploitation: Throughout lateral movement and discovery, an AI agent collects data and sends it back to the MCP C2 server. The agent analyzes the running services and applications, identifies vulnerabilities, writes custom exploit code and passes the exploit back to the onsite malware. The malware executes autonomously to continue its progress with privilege escalation, defense evasion and lateral movement across network segments.
Exfiltration and documentation: The collected data is returned to an MCP server and dropped into a datastore. It is then analyzed by an LLM to automatically provide a summary of key findings to the human operator. These findings include an assessment of the value of the stolen dataset based on the operator’s intended use of the data.
Figure 1 illustrates the complete attack path.
Figure 1. AI-enabled attack path.
It should be clear that we do not currently expect to see entirely new attack techniques created by AI. Rather, we see AI enabling attacks to move faster, autonomously and against multiple targets simultaneously.
It is the speed and scale of AI-enabled attacks that we need to prepare for as defenders, not completely unknown techniques.
We know how cyberattacks are carried out. We know the forensic evidence they leave behind. We need to shift to hardened environments that are designed for prevention and rapid response.
What Security Teams Should Do Right Now
Unit 42 recommends a thorough review of your current security policies to adopt an aggressive prevention and response mindset. Mitigations that rely on active monitoring and response prior to containment will be outpaced by AI-assisted adversaries.
Operate under assumed breach conditions: Extend endpoint protection capabilities across all environments, preventing by default and monitoring at a minimum.
Establish code visibility and governance: Strictly manage and track the origin sources of OSS and assume package registries are no longer safe. Create a software bill of materials (SBOM) for all software to enable rapid identification and patching of integrated code libraries. Implement version pinning, hash checking and cooling-off periods for updates.
Harden development and build ecosystems: Restrict build systems from reaching the internet. Adopt secure vaults for developer secrets. Aggressively scan build environment and production networks for exposed secrets.
Collapse the patching window: Transition from routine maintenance to urgent, "time-to-deploy" enforcement. Use auto-updates and out-of-band releases to counter the AI-accelerated N-day threat.
Automate incident response pipelines: Deploy AI models to triage alerts, summarize technical events and conduct proactive threat hunts. Manual triage cannot scale to the volume of bugs a frontier AI model can discover.
Refresh vulnerability disclosure policies (VDPs): Prepare for an unprecedented volume of bug reports. Organizations must have automated workflows to ingest, validate and prioritize vulnerabilities.
Prioritize hard architectural barriers: Shift toward memory-safe languages and hardware-level isolation.
Conclusion
We are entering a period of significant volatility in the cybersecurity landscape. In the short term, the proliferation of frontier AI models capabilities risks empowering adversaries to exploit zero-days and N-days at an unprecedented scale. We are talking about N-hours instead of N-days. It is also likely to enable attackers to move at greater scale, sophistication and speed than ever before. However, this is just a transition period as defenders adapt to the new speed and scale of AI-enabled threats.
The ultimate goal of this transitory period is a future where defensive capabilities dominate, and where AI models are used to identify and fix bugs faster and earlier than threat actors. Unit 42 is committed to ensuring that defenders remain ahead of threat actors. We will continue to aggressively hunt, analyze and report threat intelligence to enable defenders.
Watch our live threat briefing from Thursday, April 16, as Sam Rubin, SVP, Consulting and Threat Intelligence, Unit 42, and Marc Benoit, CISO, Palo Alto Networks discuss how frontier AI models find and exploit previously undetected exposures at machine scale and speed, and share practical steps security leaders need to take now to adapt their defenses to avoid business disruption. Watch now.
Cybersecurity researchers have discovered a critical "by design" weakness in the Model Context Protocol's (MCP) architecture that could pave the way for remote code execution and have a cascading effect on the artificial intelligence (AI) supply chain.
"This flaw enables Arbitrary Command Execution (RCE) on any system running a vulnerable MCP implementation, granting attackers direct access to sensitive user data, internal databases, API keys, and chat histories," OX Security researchers Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar said in an analysis published last week.
The cybersecurity company said the systemic vulnerability is baked into Anthropic's official MCP software development kit (SDK) across any supported language, including Python, TypeScript, Java, and Rust. In all, it affects more than 7,000 publicly accessible servers and software packages totaling more than 150 million downloads.
At issue are unsafe defaults in how MCP configuration works over the STDIO (standard input/output) transport interface, resulting in the discovery of 10 vulnerabilities spanning popular projects like LiteLLM, LangChain, LangFlow, Flowise, LettaAI, and LangBot -
CVE-2025-65720 (GPT Researcher)
CVE-2026-30623 (LiteLLM) - Patched
CVE-2026-30624 (Agent Zero)
CVE-2026-30618 (Fay Framework)
CVE-2026-33224 (Bisheng) - Patched
CVE-2026-30617 (Langchain-Chatchat)
CVE-2026-33224 (Jaaz)
CVE-2026-30625 (Upsonic)
CVE-2026-30615 (Windsurf)
CVE-2026-26015 (DocsGPT) - Patched
CVE-2026-40933 (Flowise)
These vulnerabilities fall under four broad categories, effectively triggering remote command execution on the server -
Unauthenticated and authenticated command injection via MCP STDIO
Unauthenticated command injection via direct STDIO configuration with hardening bypass
Unauthenticated command injection via MCP configuration edit through zero-click prompt injection
Unauthenticated command injection through MCP marketplaces via network requests, triggering hidden STDIO configurations
"Anthropic's Model Context Protocol gives a direct configuration-to-command execution via their STDIO interface on all of their implementations, regardless of programming language," the researchers explained.
"As this code was meant to be used in order to start a local STDIO server, and give a handle of the STDIO back to the LLM. But in practice it actually lets anyone run any arbitrary OS command, if the command successfully creates an STDIO server it will return the handle, but when given a different command, it returns an error after the command is executed."
Interestingly, vulnerabilities based on the same core issue have been reported independently over the past year. They include CVE-2025-49596 (MCP Inspector), LibreChat (CVE-2026-22252), WeKnora (CVE-2026-22688), @akoskm/create-mcp-server-stdio (CVE-2025-54994), and Cursor (CVE-2025-54136).
Anthropic, however, has declined to modify the protocol's architecture, citing the behavior as "expected. While some of the vendors have issued patches, the shortcoming remains unaddressed in Anthropic's MCP reference implementation, causing developers to inherit the code execution risks.
The findings highlight how AI-powered integrations can inadvertently expand the attack surface. To counter the threat, it's advised to block public IP access to sensitive services, monitor MCP tool invocations, run MCP-enabled services in a sandbox, treat external MCP configuration input as untrusted, and only install MCP servers from verified sources.
"What made this a supply chain event rather than a single CVE is that one architectural decision, made once, propagated silently into every language, every downstream library, and every project that trusted the protocol to be what it appeared to be," OX Security said. "Shifting responsibility to implementers does not transfer the risk. It just obscures who created it."
from The Hacker News https://ift.tt/hMdGYrC
via IFTTT
Cybersecurity researchers have flagged a new malware called ZionSiphon that appears to be specifically designed to target Israeli water treatment and desalination systems.
The malware has been codenamed ZionSiphon by Darktrace, highlighting its ability to set up persistence, tamper with local configuration files, and scan for operational technology (OT)-relevant services on the local subnet. According to details on VirusTotal, the sample was first detected in the wild on June 29, 2025, right after the Twelve-Day War between Iran and Israel that took place between June 13 and 24.
"The malware combines privilege escalation, persistence, USB propagation, and ICS scanning with sabotage capabilities aimed at chlorine and pressure controls, highlighting growing experimentation with politically motivated critical infrastructure attacks against industrial operational technologies globally," the company said.
ZionSiphon, currently in an unfinished state, is characterized by its Israel-focused targeting, going after a specific set of IPv4 address ranges that are located within Israel -
2.52.0[.]0 - 2.55.255[.]255
79.176.0[.]0 - 79.191.255[.]255
212.150.0[.]0 - 212.150.255[.]255
Besides encoding political messages that claim support for Iran, Palestine, and Yemen, the malware embeds Israel-linked strings in its target list that correspond to the nation's water and desalination infrastructure. It also includes checks to ensure that in those specific systems.
"The intended logic is clear: the payload activates only when both a geographic condition and an environment-specific condition related to desalination or water treatment are met," the cybersecurity company said.
Once launched, ZionSiphon identifies and probes devices on the local subnet, attempts protocol-specific communication using Modbus, DNP3, and S7comm protocols, and modifies local configuration files by tampering with parameters associated with chlorine doses and pressure. An analysis of the artifact has found the Modus-oriented attack path to be the most developed, with the remaining two only including partially functional code, indicating that the malware is still likely in development.
A notable aspect of the malware is its ability to propagate the infection over removable media. On hosts that do not meet the criteria, it initiates a self-destruct sequence to delete itself.
"Although the file contains sabotage, scanning, and propagation functions, the current sample appears unable to satisfy its own target-country checking function even when the reported IP falls within the specified ranges," Darktrace said. "This behavior suggests that the version is either intentionally disabled, incorrectly configured, or left in an unfinished state."
"Despite these limitations, the overall structure of the code likely indicates a threat actor experimenting with multi‑protocol OT manipulation, persistence within operational networks, and removable‑media propagation techniques reminiscent of earlier ICS‑targeting campaigns."
The disclosure coincides with the discovery of a Node.js-based implant called RoadK1ll that's designed to maintain reliable access to a compromised network while blending into normal network activity.
"RoadK1ll is a Node.js-based reverse tunneling implant that establishes an outbound WebSocket connection to attacker-controlled infrastructure and uses that connection to broker TCP traffic on demand," Blackpoint Cyber said.
"Unlike a traditional remote access trojan, it carries no large command set and requires no inbound listener on the victim host. Its sole function is to convert a single compromised machine into a controllable relay point, an access amplifier, through which an operator can pivot to internal systems, services, and network segments that would otherwise be unreachable from outside the perimeter."
Last week, Gen Digital also took the wraps off a virtual machine (VM)-obfuscated backdoor that was observed on a single machine in the U.K. and operated for about a year, before vanishing without any trace when its infrastructure expired. The implant has been dubbed AngrySpark. It's currently not known what the end goals of the activity were.
"AngrySpark operates as a three-stage system," the company explained. "A DLL masquerading as a Windows component loads via the Task Scheduler, decrypts its configuration from the registry, and injects position-independent shellcode into svchost.exe. That shellcode implements a virtual machine."
"The VM processes a 25KB blob of bytecode instructions, decoding and assembling the real payload – a beacon that profiles the machine, phones home over HTTPS disguised as PNG image requests, and can receive encrypted shellcode for execution."
The result is malware capable of establishing stealthy persistence, altering its behavior by switching the blob, and setting up a command-and-control (C2) channel that can fly under the radar.
"AngrySpark is not only modular, it is also careful about how it appears to defenders," Gen added. "Several design choices look specifically aimed at frustrating clustering, bypassing instrumentation, and limiting the forensic residue left behind. The binary's PE metadata has been deliberately altered to confuse toolchain fingerprinting."
from The Hacker News https://ift.tt/cZl5vIj
via IFTTT
Web infrastructure provider Vercel has disclosed a security breach that allows bad actors to gain unauthorized access to "certain" internal Vercel systems.
The incident stemmed from the compromise of Context.ai, a third-party artificial intelligence (AI) tool, that was used by an employee at the company.
"The attacker used that access to take over the employee's Vercel Google Workspace account, which enabled them to gain access to some Vercel environments and environment variables that were not marked as 'sensitive,'" the company said in a bulletin.
Vercel said environment variables marked as "sensitive" are stored in an encrypted manner that prevents them from being read, and that there is currently no evidence suggesting that those values were accessed by the attacker.
It described the threat actor behind the incident as "sophisticated" based on their "operational velocity and detailed understanding of Vercel's systems." The company also said it's working with Google-owned Mandiant and other cybersecurity firms, as well as notifying law enforcement and engaging with Context.ai to better understand the full scope of the breach.
A "limited subset" of customers is said to have had their credentials compromised, with Vercel reaching out to them directly and urging them to rotate their credentials with immediate effect. The company is continuing to investigate what data was exfiltrated, and plans to contact customers if further evidence of compromise is discovered.
Vercel is also advising Google Workspace administrators and Google account owners to check for the following application OAuth application:
As additional mitigations, the following best practices have been recommended -
While Vercel has yet to share details about which of its systems were broken into, how many customers were affected, and who may be behind it, a threat actor using the ShinyHunters persona has claimed responsibility for the hack, selling the stolen data for an asking price of $2 million.
"We've deployed extensive protection measures and monitoring. We've analyzed our supply chain, ensuring Next.js, Turbopack, and our many open source projects remain safe for our community," Vercel CEO Guillermo Rauch said in a post on X.
"In response to this, and to aid in the improvement of all of our customers’ security postures, we've already rolled out new capabilities in the dashboard, including an overview page of environment variables, and a better user interface for sensitive environment variable creation and management."
from The Hacker News https://ift.tt/5BclpCx
via IFTTT
Threat actors are initiating cross-tenant Microsoft Teams communications while impersonating IT or helpdesk personnel to socially engineer users into granting remote desktop access. After access is established through Quick Assist or similar remote support tools, attackers often execute trusted vendor-signed applications alongside attacker-supplied modules to enable malicious code execution.
This access pathway might be used to perform credential-backed lateral movement using native administrative protocols such as Windows Remote Management (WinRM), allowing threat actors to pivot toward high-value assets including domain controllers. In observed intrusions, follow-on commercial remote management software and data transfer utilities such as Rclone were used to expand access across the enterprise environment and stage business-relevant information for transfer to external cloud storage. This intrusion chain relies heavily on legitimate applications and administrative protocols, allowing threat actors to blend into expected enterprise activity during multiple intrusion phases.
Threat actors are increasingly abusing external Microsoft Teams collaboration to impersonate IT or helpdesk personnel and convince users to grant remote assistance access. From this initial foothold, attackers can leverage trusted tools and native administrative protocols to move laterally across the enterprise and stage sensitive data for exfiltration—often blending into routine IT support activity throughout the intrusion lifecycle. Microsoft Defender provides correlated visibility across identity, endpoint, and collaboration telemetry to help detect and disrupt this user‑initiated access pathway before it escalates into broader compromise.
Risk to enterprise environments
By abusing enterprise collaboration workflows instead of traditional email‑based phishing channels, attackers may initiate contact through applications such as Microsoft Teams in a way that appears consistent with routine IT support interactions. While Teams includes built‑in security features such as external‑sender labeling and Accept/Block prompts, this attack chain relies on convincing users to bypass those warnings and voluntarily grant remote access through legitimate support tools.
In observed intrusions, risk is introduced not by external messaging alone, but when a user approves follow‑on actions — such as launching a remote assistance session — that result in interactive system access.
An approved external Teams interaction might enable threat actors to:
Establish credential-backed interactive system access
Deploy trusted applications to execute attacker-controlled code
Pivot toward identity and domain infrastructure using WinRM
Deploy commercially available remote management tooling
Stage sensitive business-relevant data for transfer to external cloud infrastructure
In the campaign, lateral movement and follow-on tooling installation occurred shortly after initial access, increasing the risk of enterprise-wide persistence and targeted data exfiltration. As each environment is different and with potential handoff to different threat actors, stages might differ if not outright bypassed.
Figure 1: Attack chain.
Attack chain overview
Stage 1: Initial contact via Teams (T1566.003 Spearphishing via Service)
The intrusion begins with abuse of external collaboration features in Microsoft Teams, where an attacker operating from a separate tenant initiates contact while impersonating internal support personnel as a means to social engineer the user. Because interaction occurs within an enterprise collaboration platform rather than through traditional email‑based phishing vectors, it might bypass initial user skepticism associated with unsolicited external communication. Security features protecting Teams users are detailed here, for reference. It’s important to note that this attack relies on users willfully ignoring or overlooking security notices and other protection features. The lure varies and might include “Microsoft Security Update”, “Spam Filter Update”, “Account Verification” but the objective is constant: convince the user to ignore warnings and external contact flags, launch a remote management session, and accept elevation. Voice phishing (vishing) is sometimes layered to increase trust or compliance if they don’t replace the messaging altogether.
Timing matters. We regularly see a “ChatCreated” event to indicate a first contact situation, followed by suspicious chats or vishing, remote management, and other events t that commonly produce alerts to include mailbombing or URL click alerts. All of these can be correlated by account and chat thread information in your Defender hunting environment.
Teams security warnings:
External Accept/Block screens provide notice to users about First Contact events, which prompt the user to inspect the sender’s identity before accepting:
Figure 2: External Accept/Block screens.
Higher confidence warnings alert the user of spam or phishing attempts on first contact:
Figure 3: spam or phishing alert.
External warnings notify users that they are communicating with a tenant/organization other than their own and should be treated with scrutiny:
Figure 4: External warnings.
Message warnings alert the user on the risk in clicking the URL:
Figure 5: URL click warning.
Safe Links for time-of-click protection warns users when URLs from Teams chat messages are malicious:
Figure 6: time-of-click protection warning.
Zero-hour Auto Purge (ZAP) can remove messages that were flagged as malicious after they have been sent:
Figure 7: Removed malicious from ZAP.
It’s important to note that the attacker often does not send the URL over a Teams message. Instead, they will navigate to it while on the endpoint during a remote management session. Therefore, the best security is user education on understanding the importance of not ignoring external flags for new helpdesk contacts. See “User education” in the “Defend, harden, and educate (Controls to deploy now)” section for further advice.
Stage 2: Remote assistance foothold
With user consent obtained through social engineering, the attacker gains interactive control of the device using remote support tools such as Quick Assist. This access typically results in the launch of QuickAssist.exe, followed by the display of standard Windows elevation prompts through Consent.exe as the attacker is guided through approval steps.
Figure 8: Quick Assist Key Logs.
From the user’s perspective, the attacker convinces them to open Quick Assist, enter a short key, the follow all prompts and approvals to grant access.
Figure 9 – Quick Assist Launch.
This step is often completed in under a minute. The urgency and interactivity are the signal: a remote‑assist process tree followed immediately by “cmd.exe” or PowerShell on the same desktop.
Stage 3: Interactive reconnaissance and access validation
Immediately after establishing control through Quick Assist, the attacker typically spends the first 30–120 seconds assessing their level of access and understanding the compromised environment. This is often reflected by a brief surge of cmd.exe activity, used to verify user context and privilege levels, gather basic system information such as host identity and operating system details, and confirm domain affiliation. In parallel, the attacker might query registry values to determine OS build and edition, while also performing quick network reconnaissance to evaluate connectivity, reachability, and potential opportunities for lateral movement.
Figure 10: Enumeration.
On systems with limited privileges—such as kiosks, VDI, or non-corp-joined devices—actors might pause without deploying payloads, leaving only brief reconnaissance activity. They often return later when access improves or pivot to other targets within the same tenant.
Stage 4: Payload placement and trusted application invocation
Once remote access is established, the intrusion transitions from user‑assisted interaction to preparing the environment for persistent execution. At this point, attackers introduce a small staging bundle onto disk using either archive‑based deployment or short‑lived scripting activity.
After access is established, attackers stage payloads in locations such as ProgramData and execute them using DLL side‑loading through trusted signed applications. This includes:
AcroServicesUpdater2_x64.exe loading a staged msi.dll
Allowing attacker‑supplied modules to run under a trusted execution context from non‑standard paths.
Figure 11: Sample Payload.
Stage 5: Execution context validation and registry backed loader state
Following payload delivery, the attacker performs runtime checks to validate host conditions before execution. A large encoded value is then written to a user‑context registry location, serving as a staging container for encrypted configuration data to be retrieved later at runtime.
In this stage, a sideloaded module acting as an intermediary loader decrypts staged registry data in memory to reconstruct execution and C2 configuration without writing files to disk. This behavior aligns with intrusion frameworks such as Havoc, which externalize encrypted configuration to registry storage, allowing trusted sideloaded components to dynamically recover execution context and maintain operational continuity across restarts or remediation events.
Microsoft Defender for Endpoint may detect this activity as:
Execution from user‑writable directories such as ProgramData
Attack surface reduction rules and Windows Defender Application Control policies can be used to restrict execution pathways commonly leveraged for sideloaded module activation.
Stage 6: Command and control
Following successful execution of the sideloaded component, the updater‑themed process AcroServicesUpdater2_x64.exe began initiating outbound HTTPS connections over TCP port 443 to externally hosted infrastructure.
Unlike expected application update workflows which are typically restricted to known vendor services these connections were directed toward dynamically hosted cloud‑backed endpoints and unknown external domains. This behavior indicates remote attacker‑controlled infrastructure rather than legitimate update mechanisms.
Establishing outbound encrypted communications in this manner enables compromised processes to operate as beaconing implants, allowing adversaries to remotely retrieve instructions and maintain control within the affected environment while blending command traffic into routine HTTPS activity. The use of cloud‑hosted hosting layers further reduces infrastructure visibility and improves the attacker’s ability to modify or rotate communication endpoints without altering the deployed payload.
This activity marks the transition from local execution to externally directed command‑and‑control — enabling subsequent stages of discovery and movement inside the enterprise network.
Stage 7: Internal discovery and lateral movement toward high value assets
Shortly after external communications were established, the compromised process began initiating internal remote management connections over WinRM (TCP 5985) toward additional domain‑joined systems within the enterprise environment.
Microsoft Defender may surface these activities as multi‑device incidents reflecting credential‑backed lateral movement initiated from a user‑context remote session.
Analysis of WinRM activity indicates that the threat actor used native Windows remote execution to pivot from the initially compromised endpoint toward high‑value infrastructure assets, including identity and domain management systems such as domain controllers. Use of WinRM from a non‑administrative application suggests credential‑backed lateral movement directed by an external operator, enabling remote command execution, interaction with domain infrastructure, and deployment of additional tooling onto targeted hosts.
Targeting identity‑centric infrastructure at this stage reflects a shift from initial foothold to broader enterprise control and persistence. Notably, this internal pivot preceded the remote deployment of additional access tooling in later stages, indicating that attacker‑controlled WinRM sessions were subsequently leveraged to extend sustained access across
Stage 8: Remote deployment of auxiliary access tooling (Level RMM)
Subsequent activity revealed the remote installation of an additional management platform across compromised hosts using Windows Installer (msiexec.exe). This introduced an alternate control channel independent of the original intrusion components, reducing reliance on the initial implant and enabling sustained access through standard administrative mechanisms. As a result, attackers could maintain persistent remote control even if earlier payloads were disrupted or removed.
Stage 9: Data exfiltration
Actors used the file‑synchronization tool Rclone to transfer data from internal network locations to an external cloud storage service. File‑type exclusions in the transfer parameters suggest a targeted effort to exfiltrate business‑relevant documents while minimizing transfer size and detection risk.
Microsoft Defender might detect this activity as possible data exfiltration involving uncommon synchronization tooling.
Mitigation and protection guidance
Family / Product
Protection
Reference documents
Microsoft Teams
Review external collaboration policies and ensure users receive clear external sender notifications when interacting with cross‑tenant contacts. Consider device‑ or identity‑based access requirements prior to granting remote support sessions.
Enable Safe Links for Teams conversations with time-of-click verification, and ensure zero-hour auto purge (ZAP) is active to retroactively quarantine weaponized messages.
Disable or restrict remote management tools to authorized roles, enable standard ASR rules in block mode, and apply WDAC to prevent DLL sideloading from ProgramData and AppData paths used by these actors.
Enforce Conditional Access requiring MFA and compliant devices for administrative roles, restrict WinRM to authorized management workstations, and monitor for Rclone or similar synchronization utilities used for data exfiltration via hunting or custom alerts tuned to your environment.
Enable network protection to block implant C2 beaconing to poor-reputation and newly registered domains, and alert on registry modifications to ASEP locations by non-installer processes. Hunting and custom detections tuned to your environment will assist in detecting network threats.
The attackers will often initiate Teams calls with their targets to talk them through completing actions that result in machine compromise. It may be useful to establish a verbal authentication code between IT Helpdesk and employees: a key phrase that an attacker is unlikely to know. Inform employees how IT Helpdesk would normally reach out to them: which medium(s) of communication? Email, Teams, Phone calls, etc. What identifiers would those IT Helpdesk contacts have? Domain names, aliases, phone numbers, etc. Show example images of your Helpdesk vs. an attacker impersonating them over your communication medium. Show examples of how to identify external versus internal Teams communications, block screens, message and call reporting, as well as how to identify a display name vs. the real caller’s name and domain. Inform employees that URLs shared by an external Helpdesk account leading to Safe Links warnings about malicious websites are extremely suspicious. They should report the message as phish and contact your security team. If they receive any URLs from IT Helpdesk that involve going to a webpage for security updates or spam mailbox cleanings, then they should report that to your security team. Treat unsolicited and unexpected external contact from IT Helpdesk as inherently suspicious.
When Defender detects credential‑backed WinRM lateral movement following a Quick Assist session, Automatic Attack Disruption can suspend the originating user session and contain the users prior to domain‑controller interaction — limiting lateral movement before your SOC engages. Look for incidents tagged “Attack Disruption” in your queue.
Teams/MDO, Entra ID, and MDE signals are automatically correlated into unified incidents. This entire attack chain surfaces as one multi-stage incident — not dozens of disconnected alerts. Review “Multi-stage” incidents for the full story.
Threat analytics reports for these TTPs include exposure assessments and mitigations for your environment. Detection logic is continuously updated to reflect evolving tradecraft. Check your Threat Analytics dashboard for reports tagged to these Storm actors.
When an external user initiates contact, Teams presents the recipient with a message preview and an explicit Accept or Block prompt before any conversation begins. Blocking prevents future messages and hides your presence status from that sender.
Following security recommendations can help in improving the security posture of the org. Apply UAC restrictions to local accounts on network logonsSafe DLL Search ModeEnable Network ProtectionDisable ‘Allow Basic authentication’ for WinRM Client/Service
Microsoft Defender provides pre-breach and post-breach coverage for this campaign, supported by the generic and specific alerts listed below.
Tactic
Observed activity
Microsoft Defender coverage
Initial Access
The actor initiates a cross‑tenant Teams chat or call from an often newly created tenant using an IT/Help‑Desk persona
Microsoft Defender for Office 365 – Microsoft Teams chat initiated by a suspicious external user – IT Support Teams Voice phishing following mail bombing activity – A user clicked through to a potentially malicious URL. – A potentially malicious URL click was detected.
Microsoft Defender for Endpoint – Possible initial access from an emerging threat
Execution
The attacker gains interactive control via remote management tools to include Quick Assist.
Microsoft Defender for Endpoint
– Suspicious activity using Quick Assist – Uncommon remote access software – Remote monitoring and management software suspicious activity
The implant or sideloaded host typically beacons over HTTPS
Microsoft Defender for Endpoint
– Connection to a custom network indicator – A file or network connection related to a ransomware-linked emerging threat activity group detected
Data Exfiltration
Widely available file‑synchronization utility Rclone to systematically transfer data
Microsoft Defender for Endpoint
– Possible data exfiltration
Multi-tactic
Many alerts span across multiple tactics or stages of an attack and cover many platforms.
Microsoft Defender (All) – Multi-stage incident involving Execution – Remote management event after suspected Microsoft Teams IT support phishing – An Office application ran suspicious commands
Hunting queries
Security teams can use the advanced hunting capabilities in Microsoft Defender XDR to proactively look for indicators of exploitation.
A. Teams → RMM correlation
let _timeFrame = 30m;
// Teams message signal
let _teams =
MessageEvents
| where Timestamp > ago(14d)
//| where SenderDisplayName contains "add keyword"
// or SenderDisplayName contains "add keyword"
| extend Recipient = parse_json(RecipientDetails)
| mv-expand Recipient
| extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
VictimRecipientDisplayName = tostring(Recipient.RecipientUserDisplayName)
| project
TTime = Timestamp,
SenderEmailAddress,
SenderDisplayName,
VictimRecipientDisplayName,
VictimAccountObjectId;
// RMM launches on endpoint side
let _rmm =
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
| extend VictimAccountObjectId = tostring(InitiatingProcessAccountObjectId)
| project
DeviceName,
QTime = Timestamp,
RmmTool = FileName,
VictimAccountObjectId;
_teams
| where isnotempty(VictimAccountObjectId)
| join kind=inner _rmm on VictimAccountObjectId
| where isnotempty(DeviceName)
| where QTime between ((TTime) .. (TTime +(_timeFrame)))
| project DeviceName, SenderEmailAddress, SenderDisplayName, VictimRecipientDisplayName, VictimAccountObjectId, TTime, QTime, RmmTool
| order by QTime desc
B. Execution
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "cmd.exe"
| where FileName =~ "cmd.exe"
| where ProcessCommandLine has_all ("/S /D /c", "\" set /p=\"PK\"", "1>")
C. ZIP → ProgramData service path → signed host sideload
let _timeFrame = 10m;
let _armOrDevice =
DeviceFileEvents
| where Timestamp > ago(14d)
| where FolderPath has_any (
"C:\\ProgramData\\Adobe\\ARM\\",
"C:\\ProgramData\\Microsoft\\DeviceSync\\",
"D:\\ProgramData\\Adobe\\ARM\\",
"D:\\ProgramData\\Microsoft\\DeviceSync\\")
and ActionType in ("FileCreated","FileRenamed")
| project DeviceName, First=Timestamp, FileName;
let _hostRun =
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("AcroServicesUpdater2_x64.exe","DlpUserAgent.exe","ADNotificationManager.exe")
| project DeviceName, Run=Timestamp, Host=FileName;
_armOrDevice
| join kind=inner _hostRun on DeviceName
| where Run between (First .. (First+(_timeFrame)))
| summarize First=min(First), Run=min(Run), Files=make_set(FileName, 10) by DeviceName, Host
| order by Run desc
D. PowerShell → high‑risk TLD → writes %AppData%/Roaming EXE
let _timeFrame = 5m;
let _psNet = DeviceNetworkEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("powershell.exe","pwsh.exe")
| where RemoteUrl matches regex @"(?i)\.(top|xyz|zip|click)$"
| project DeviceName, NetTime=Timestamp, RemoteUrl, RemoteIP;
let _exeWrite = DeviceFileEvents
| where Timestamp > ago(14d)
| where FolderPath has @"\AppData\Roaming\" and FileName endswith ".exe"
| project DeviceName, WTime=Timestamp, FileName, FolderPath, SHA256;
_psNet
| join kind=inner _exeWrite on DeviceName
| where WTime between (NetTime .. (NetTime+(_timeFrame)))
| project DeviceName, NetTime, RemoteUrl, RemoteIP, WTime, FileName, FolderPath, SHA256
| order by WTime desc
E. Registry breadcrumbs / ASEP anomalies
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"\SOFTWARE\Classes\Local Settings\Software\Microsoft"
| where RegistryValueName in~ ("UCID","UFID","XJ01","XJ02","UXMP")
| project Timestamp, DeviceName, ActionType, RegistryKey, RegistryValueName, PreviousRegistryValueData, InitiatingProcessFileName
| order by Timestamp desc
F. Non‑browser process → API‑Gateway → internal AD protocols
let _timeFrame = 10m;
let _net1 =
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemoteUrl has ".execute-api."
| where InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","firefox.exe")
| project DeviceName,
Proc=InitiatingProcessFileName,
OutTime=Timestamp,
RemoteUrl,
RemoteIP;
let _net2 =
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where RemotePort in (135,389,445,636)
| project DeviceName,
Proc=InitiatingProcessFileName,
InTime=Timestamp,
RemoteIP,
RemotePort;
_net1
| join kind=inner _net2 on DeviceName, Proc
| where InTime between (OutTime .. (OutTime+(_timeFrame)))
| project DeviceName, Proc, OutTime, RemoteUrl, InTime, RemotePort
| order by InTime desc
G. PowerShell history deletion
DeviceFileEvents
| where Timestamp > ago(14d)
| where FileName =~ "ConsoleHost_history.txt" and ActionType == "FileDeleted"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath
| order by Timestamp desc
DeviceProcessEvents
| where Timestamp > ago(2d)
| where FileName =~ "rclone.exe" or ProcessVersionInfoOriginalFileName =~ "rclone.exe"
| where ProcessCommandLine has_all ("copy ", "--config rclone_uploader.conf", "--transfers 16", "--checkers 16", "--buffer-size 64M", "--max-age=3y", "--exclude *.mdf")
J. Quick Assist–anchored recon (no staging writes within 10 minutes)
let _reconWindow = 10m; // common within 1-5 minutes
let _stageWindow = 15m; // common 1-2 minutes after recon, or less
// Anchor on RMM
let _rmm =
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
| project DeviceName, RMMTime=Timestamp;
// Recon commands within X minutes of RMM start (targeted list)
let _recon =
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe")
| where ProcessCommandLine has_any (
"whoami", "hostname", "systeminfo", "ver", "wmic os get",
"reg query HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion",
"query user", "net user", "nltest", "ipconfig /all", "arp -a", "route print",
"dir", "icacls"
)
| project DeviceName, ReconTime=Timestamp, ReconCmd=ProcessCommandLine, ReconProc=FileName;
// Suspect staging writes (ZIP/EXE/DLL)
let _staging =
DeviceFileEvents
| where Timestamp > ago(14d)
| where ActionType in ("FileCreated","FileRenamed")
| where FileName matches regex @"(?i).*\\.(zip|exe|dll)$"
| project DeviceName, STime=Timestamp, StageFile=FileName, StagePath=FolderPath;
// Correlate RMM + recon, then exclude cases with staging writes in the next X minutes
let _rmmRecon =
_rmm
| join kind=inner _recon on DeviceName
| where ReconTime between (RMMTime .. (RMMTime+(_reconWindow)))
| project DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd;
_rmmRecon
| join kind=leftouter _staging on DeviceName
| extend HasStagingInWindow = iff(STime between (RMMTime .. (RMMTime+(_stageWindow))), 1, 0)
| summarize HasStagingInWindow=max(HasStagingInWindow) by DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd
| where HasStagingInWindow == 0
| project DeviceName, RMMTime, ReconTime, ReconProc, ReconCmd
K. Sample Correlation Query Between Chat, First Contact, and Alerts
Note. Please modify or tune for your specific environment.
let _timeFrame = 30m; // Tune: how long after the Teams event to look for matching alerts
let _huntingWindow = 4d; // Tune: broader lookback increases coverage but also cost
// Seed Teams message activity and normalize the victim/join fields you want to carry forward
let _teams = materialize (
MessageEvents
| where Timestamp > ago(_huntingWindow)
| extend Recipient = parse_json(RecipientDetails)
// Optional tuning: add sender/name/content filters here first to reduce volume early
//| where SenderDisplayName contains "add keyword"
// or SenderDisplayName contains "add keyword"
// add other hunting terms
| mv-expand Recipient
| extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
VictimUPN = tostring(Recipient.RecipientSmtpAddress)
| project
TTime = Timestamp,
SenderUPN = SenderEmailAddress,
SenderDisplayName,
VictimUPN,
VictimAccountObjectId,
ChatThreadId = ThreadId
);
// Distinct key sets used to prefilter downstream tables before joining
let _VictimAccountObjectId = materialize(
_teams
| where isnotempty(VictimAccountObjectId)
| distinct VictimAccountObjectId
);
let _VictimUPN = materialize(
_teams
| where isnotempty(VictimUPN)
| distinct VictimUPN
);
let _ChatThreadId = materialize(
_teams
| where isnotempty(ChatThreadId)
| distinct ChatThreadId
);
// Find first-seen chat creation events for the chat threads already present in _teams
// Tune: add more CloudAppEvents filters here if you want to narrow to external / one-on-one / specific chat types
let _firstContact = materialize(
CloudAppEvents
| where Timestamp > ago(_huntingWindow)
| where Application has "Teams"
| where ActionType == "ChatCreated"
| extend Raw = todynamic(RawEventData)
| extend ChatThreadId = tostring(Raw.ChatThreadId)
| where isnotempty(ChatThreadId)
| join kind=innerunique (_ChatThreadId) on ChatThreadId
| summarize FCTime = min(Timestamp) by ChatThreadId
);
// Alert branch 1: match by victim object ID
// Usually the cleanest identity join if the field is populated consistently
let _alerts_by_oid = materialize(
AlertEvidence
| where Timestamp > ago(_huntingWindow)
| where AccountObjectId in (_VictimAccountObjectId)
| project
ATime = Timestamp,
AlertId,
Title,
AccountName,
AccountObjectId,
AccountUpn = "",
SourceId = "",
ChatThreadId = ""
);
// Alert branch 2: match by victim UPN
// Useful when ObjectId is missing or alert evidence is only populated with UPN
let _alerts_by_upn = materialize(
AlertEvidence
| where Timestamp > ago(_huntingWindow)
| where AccountUpn in (_VictimUPN)
| project
ATime = Timestamp,
AlertId,
Title,
AccountName,
AccountObjectId,
AccountUpn,
SourceId = "",
ChatThreadId = ""
);
// Alert branch 3: match by chat thread ID
// Tune: this is typically the most expensive branch because it inspects AdditionalFields
let _alerts_by_thread = materialize(
AlertEvidence
| where Timestamp > ago(_huntingWindow)
| where AdditionalFields has_any (_ChatThreadId)
| extend AdditionalFields = todynamic(AdditionalFields)
| extend
SourceId = tostring(AdditionalFields.SourceId),
ChatThreadIdRaw = tostring(AdditionalFields.ChatThreadId)
| extend ChatThreadId = coalesce(
ChatThreadIdRaw,
extract(@"/(?:chats|channels|conversations|spaces)/([^/]+)/", 1, SourceId)
)
| where isnotempty(ChatThreadId)
| join kind=innerunique (_ChatThreadId) on ChatThreadId
| project
ATime = Timestamp,
AlertId,
Title,
AccountName,
AccountObjectId,
AccountUpn = "",
SourceId,
ChatThreadId
);
//
// add branch 4 to corrilate with host events
//
// Add first-contact context back onto the Teams seed set
let _teams_fc = materialize(
_teams
| join kind=leftouter _firstContact on ChatThreadId
| extend FirstContact = isnotnull(FCTime)
);
// Join path 1: Teams victim object ID -> alert AccountObjectId
let _matches_oid =
_teams_fc
| where isnotempty(VictimAccountObjectId)
| join hint.strategy=broadcast kind=leftouter (
_alerts_by_oid
) on $left.VictimAccountObjectId == $right.AccountObjectId
// Time bound keeps only alerts near the Teams activity; widen/narrow _timeFrame to tune sensitivity
| where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
| extend MatchType = "ObjectId";
// Join path 2: Teams victim UPN -> alert AccountUpn
let _matches_upn =
_teams_fc
| where isnotempty(VictimUPN)
| join hint.strategy=broadcast kind=leftouter (
_alerts_by_upn
) on $left.VictimUPN == $right.AccountUpn
| where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
| extend MatchType = "VictimUPN";
// Join path 3: Teams chat thread -> alert chat thread
let _matches_thread =
_teams_fc
| where isnotempty(ChatThreadId)
| join hint.strategy=broadcast kind=leftouter (
_alerts_by_thread
) on ChatThreadId
| where isnull(ATime) or ATime between (TTime .. TTime + _timeFrame)
| extend MatchType = "ChatThreadId";
//
// add branch 4 for host events
//
// Merge all match paths and collapse multiple alert hits per Teams event into one row
union _matches_oid, _matches_upn, _matches_thread
| summarize
AlertTitles = make_set(Title, 50),
AlertIds = make_set(AlertId, 50),
MatchTypes = make_set(MatchType, 10),
FirstAlertTime = min(ATime)
by
TTime,
SenderUPN,
SenderDisplayName,
VictimUPN,
VictimAccountObjectId,
ChatThreadId,
Protecting your organization from collaboration‑based impersonation attacks as demonstrated throughout this intrusion chain, cross‑tenant helpdesk impersonation campaigns rely less on platform exploitation and more on persuading users to initiate trusted remote access workflows within legitimate enterprise collaboration tools such as Microsoft Teams.
Organizations should treat any unsolicited external support contact as inherently suspicious and implement layered defenses that limit credential‑backed remote sessions, enforce Conditional Access with MFA and compliant device requirements, and restrict the use of administrative protocols such as WinRM to authorized management workstations. At the endpoint and identity layers, enabling Attack Surface Reduction (ASR) rules, Zero‑hour Auto Purge (ZAP), Safe Links for Teams messages, and network protection can reduce opportunities for sideloaded execution and outbound command‑and‑control activity that blend into routine HTTPS traffic.
Finally, organizations should reinforce user education—such as establishing internal helpdesk authentication phrases and training employees to verify external tenant indicators—to prevent adversaries from converting legitimate collaboration workflows into attacker‑guided remote access and staged data exfiltration pathways.
This research is provided by Microsoft Defender Security Research with contributions from Jesse Birch, Sagar Patil, Balaji Venkatesh S (DEX), Eric Hopper, Charu Puhazholi, and other members of Microsoft Threat Intelligence.
Learn More
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
With the release of Vault Enterprise 2.0, we are continuing to modernize how organizations secure and distribute secrets across hybrid and multi-cloud environments. As part of this release, Vault secret sync now supports workload identity federation for cloud service provider destinations, eliminating the need for long-lived static cloud credentials.
Modern cloud environments are built on short-lived identity, dynamic infrastructure, and policy-driven access. Yet many secret distribution mechanisms still rely on long-lived static credentials to connect systems together.
Vault secret sync was designed to reduce secret sprawl by keeping secrets synchronized from Vault into cloud native secret stores such as AWS Secrets Manager, Azure Key Vault, and Google Secret Manager. With workload identity federation support in Vault Enterprise 2.0, secret sync becomes fully cloud native and replaces static credentials with short-lived federated identity tokens.
This integration significantly reduces risk, simplifies operations, and aligns secret sync with modern identity-first security models.
The challenge with long-lived root credentials
Secret sync enables customers to securely distribute secrets from Vault to cloud provider secret stores, helping standardize secret management and reduce fragmentation across platforms.
Until now, configuring cloud provider destinations required static credentials such as:
AWS IAM access keys
Azure service principal secrets
GCP service account keys
While functional, these credentials introduce both security and operational risk:
Long-lived credentials increase the blast radius if leaked
Manual rotation is required
Expiration can cause silent sync failures
Credentials tend to sprawl across systems and teams
This is particularly concerning because cloud provider credentials often grant access to critical infrastructure. A leaked or expired cloud credential does not just break synchronization. It can expose sensitive infrastructure resources.
For security conscious organizations, this model increasingly conflicts with internal policies that mandate short-lived identity and federated authentication.
Workload identity federation as the industry standard
Workload identity federation has become the modern standard for machine-to-machine authentication because it significantly reduces the risks associated with long-lived credentials.
Traditional integrations often rely on static credentials such as API keys, service account keys, or service principal secrets. These credentials must be stored, distributed, and periodically rotated. If leaked or misconfigured, they can provide persistent access to critical infrastructure resources.
Workload identity federation addresses this risk by replacing long-lived credentials with short-lived, identity-based access.
Instead of storing credentials, systems:
Present a trusted identity token, typically a signed JWT
Exchange it with a cloud provider
Receive a short-lived and scoped access token
Each cloud provider implements this model slightly differently:
AWS uses IAM roles with web identity
Azure uses federated credentials
GCP uses workload identity pools
Despite these differences, the underlying model is consistent. No static secrets are stored. Access is granted through a short-lived token exchange based on an established trust relationship.
This approach:
Minimizes credential exposure
Eliminates manual rotation
Reduces the blast radius of credential compromise
Aligns with zero trust principles
Reduces operational overhead
Provides auditable and policy-driven access
Vault already supports workload identity federation for securing modern workloads. Now secret sync extends this identity-first model to cloud secret distribution.
Extending secret sync to non-human identities and agentic AI
This shift is especially important as organizations adopt non-human identities (NHIs) and agentic workflows powered by automation and AI. These systems operate at high velocity, often creating and consuming secrets dynamically across environments, which makes long-lived credentials both impractical and risky. By leveraging workload identity federation in secret sync, NHIs and autonomous agents can securely access cloud-native secret stores using short-lived, identity-based tokens instead of embedded credentials. This enables a more scalable and secure model for machine-to-machine access, where identity, policy, and context govern access in real time. As agentic systems become more prevalent, this approach ensures that secret distribution keeps pace and reduces credential sprawl, enforces least privilege, and strengthens the overall security posture without slowing down innovation.
What is new in Vault secret sync
With workload identity federation support for cloud provider destinations, Vault can now:
Generate or use a trusted identity token
Exchange that token with AWS, Azure, or GCP
Obtain a short-lived cloud access token
Use that token to synchronize secrets
Automatically refresh tokens as needed
What is eliminated:
Long-lived IAM access keys
Service principal passwords
Service account key files
Manual credential rotation processes
What is gained:
Short-lived, automatically refreshed credentials
Reduced credential sprawl
Lower blast radius
Cloud-native authentication
Stronger alignment with enterprise security policies
Secret sync not only reduces secret sprawl. It now distributes secrets without introducing new credential risk.
Simplifying security with secret sync
For Vault administrators, security requirements are only one part of the equation. Operational efficiency and reliability are equally important when managing secrets across multiple cloud platforms.
Many organizations now enforce strict security policies that require:
No new static cloud credentials
No long-lived IAM access keys
Mandatory use of federated identity
Strong auditability and centralized identity governance
Previously, enabling secret sync required introducing static credentials into an otherwise modern security posture. These credentials had to be stored, rotated, and monitored, creating additional operational overhead and potential risk.
With workload identity federation support, Vault admins can now enable secret sync without relying on static cloud credentials. This approach reduces the need to manage credential lifecycles while aligning with organizational security standards.
Vault admins can now:
Enable secret sync without violating security policy
Remove legacy static credentials from their environment
Reduce credential management overhead
Improve operational efficiency and reliability
Strengthen compliance and auditability
By combining stronger security with simpler credential management, secret sync now aligns with zero trust and identity-first cloud security architectures while making operations easier for platform teams.
Stronger security with simpler operations
Workload identity federation improves both the security and operational reliability of secret synchronization.
Static credentials introduce risk because they are long-lived and must be stored, rotated, and monitored. If leaked, they can be reused until revoked and often provide broad access to cloud infrastructure.
With workload identity federation, Vault exchanges trusted identity tokens for short-lived cloud access tokens. These tokens are automatically refreshed and tightly scoped, which reduces the impact of credential exposure and minimizes the attack surface.
This model also improves operational reliability. Static credentials can expire unexpectedly and cause synchronization failures that require manual intervention. Federated identity removes this dependency by relying on short-lived tokens that follow the cloud provider’s native authentication model.
As a result, secret sync becomes both more secure and more resilient, while reducing the operational burden of managing cloud credentials.
A more secure cloud-native future
Cloud providers have made it clear that federated identity is the future of authentication.
By integrating workload identity federation into Vault secret sync, one of the remaining static credential dependencies in cloud secret distribution workflows is eliminated. The result is:
More secure
More compliant
More reliable
More cloud native
For platform and engineering teams, this removes the need for policy exceptions and strengthens the overall security posture of secret synchronization workflows.
Getting started
As organizations continue to adopt cloud-native architectures, the shift away from static credentials is no longer optional, but foundational to reducing risk and operating at scale. By bringing workload identity federation to secret sync, Vault Enterprise 2.0 eliminates one of the last sources of long-lived credentials in cloud secret distribution, helping teams strengthen security while simplifying operations. The result is a more resilient, compliant, and truly cloud-native approach to managing secrets across environments.
Ready to eliminate static credentials and modernize your secret distribution workflows? Upgrade to Vault Enterprise 2.0 and enable workload identity federation for secret sync today.
from HashiCorp Blog https://ift.tt/dqbRfLZ
via IFTTT
