GlassWorm Malware Takedown Disrupts Developer Supply Chain Attack Infrastructure

CrowdStrike, in partnership with Google and the Shadowserver Foundation, has announced the simultaneous disruption of all command-and-control (C2) channels associated with GlassWorm, a persistent software chain campaign targeting software developers through malicious packages and extensions.

"Since at least early 2025, GlassWorm operators have systematically targeted software developers, a population with access to source code repositories, cloud platforms, CI/CD pipelines, and package registries," CrowdStrike said.

The development comes as developers have increasingly become lucrative targets for pulling off software supply chain attacks, enabling attackers to leverage a single compromised workstation to impact thousands of downstream organizations and users at once.

GlassWorm, since its emergence last year, has conducted a "multi-pronged campaign" using trojanized VS Code extensions published on both the Microsoft VS Code Marketplace and Open VSX, thereby making it possible to target users of VS Code forks like Cursor, Positron, Windsurf, and VSCodium.

The campaign is also known to have introduced malicious code through compromised npm and Python packages. The end goal of the attacks is to deliver a data-theft framework with credential harvesting, cryptocurrency wallet exfiltration, and system profiling capabilities.

Subsequent iterations of GlassWorm have been found to deploy a Websocket-based JavaScript RAT called GlassWormRAT to steal web browser data and run arbitrary code, including installing a Google Chrome extension that, in turn, collects sensitive data, including screenshots, keystrokes, and clipboard content, from the infected system.

"Once active, the malware searches the host for developer credentials (GitHub, NPM, OpenVSX tokens, crypto wallets), enabling further compromise of repositories and package uploads," Endor Labs researcher Kiran Raj said.

"Infected hosts are converted into covert infrastructure: SOCKS proxies, hidden VNC (HVNC) servers, and remote execution nodes (via WebRTC or spawned Node.js processes). That gives attackers anonymized network access into corporate and personal networks and a platform to propagate further."

Cumulatively, the malicious activity is said to have poisoned more than 300 GitHub repositories using stolen developer credentials. What made the operation notable was its use of four distinct C2 channels for improved resilience -

"The combination of blockchain, peer-to-peer, and legitimate web services as resolution layers was designed to be resilient against takedowns - a dynamic front protecting the actual C2 servers behind multiple layers of indirection," CrowdStrike said.

As a result of the takedown, all four channels have been neutralized simultaneously in a coordinated effort so that infected machines can no longer receive new instructions or payloads.

Describing the GlassWorm operators as "well-resourced and persistent," the cybersecurity company attributed the activity to likely Russia-based cybercriminals given that the malware terminates execution on systems located in the Commonwealth of Independent States (CIS) countries and contains Russian-language comments.

"The software supply chain remains one of the most consequential attack surfaces in modern computing," CrowdStrike concluded. "Adversaries are turning an organization's dependencies on tools, updates, and libraries into weaponized delivery mechanisms and force multipliers."

"The barrier to poisoning a package or extension is low; the potential blast radius is enormous. As long as developer environments, build pipelines, and code repositories remain under-protected, every organization that consumes software inherits the risk of everyone who produces it. GlassWorm demonstrates that attackers know this and are investing in resilient infrastructure to maintain persistent access to developer ecosystems."

from The Hacker News https://ift.tt/zuSnR1k
via IFTTT

5 Steps to Managing Shadow AI Tools Without Slowing Down Employees

When an employee installs an AI writing assistant, connects a coding copilot to their IDE, or starts summarizing meetings with a new browser tool, they are doing exactly what a productive employee should do: finding faster ways to work.

Across most organizations today, employees are running three to five AI tools on any given day. Most were never reviewed by IT. A significant portion connects to corporate data through OAuth tokens or browser sessions, giving them access to shared drives, emails, and internal documents the employee never specifically intended to expose. Security teams often have no visibility into any of it.

This is the shadow AI gap, and it is widening fast. Most security tools were built to monitor email and network traffic flowing through the corporate network. A browser-based AI tool that connects to company data through a quick login approval bypasses those controls entirely, because it never passes through the corporate network at all. According to Gartner, 69% of organizations suspect or have confirmed that employees are using prohibited AI tools at work, and only 37% have an AI governance policy in place. The result is a growing disconnect between how employees work and what security teams can see.

A program that channels AI adoption into a safe, visible, approved path gives security teams the visibility they need and employees the tools they want. The five steps below show exactly how to build one.

Step 1: Build a Full Picture of What's Running

A security program can only manage what it can see. The first step is discovering which AI tools are in use across the organization, and most security teams will find the answer surprising.

Three areas account for the majority of shadow AI activity.

• OAuth connections. Most AI tools request access to Google Workspace or Microsoft 365 through OAuth, which grants them read or write permissions to corporate data. A quarterly audit of connected third-party apps, sorted by permission scope, usually surfaces dozens of tools the security team never reviewed.
• Browser extensions. Many AI tools run as browser extensions and never touch the operating system, so traditional endpoint management tools miss them entirely. A browser management solution or a lightweight agent installed on employee devices can scan for and identify which extensions are active across the organization.
• AI features bundled inside already-approved tools. Microsoft Copilot, Google Gemini, and Salesforce Einstein are examples of AI capabilities that may have been introduced after the original vendor review, often without a separate security evaluation.

A simple employee survey is also worth running. A survey framed around helping employees work more safely tends to get candid responses. Many shadow tools surface through surveys that automated discovery misses entirely.

The goal of this step is a current, accurate inventory: every AI tool in use, who is using it, and what data it has access to.

Step 2: Write a Policy That Works With Employees

Most AI acceptable use policies stall for the same reason: they give employees a list of prohibited tools with no guidance on what the approved path looks like. A policy designed as a practical guide, one that identifies approved tools and provides a clear process for requesting new ones, is the foundation employees need to make good decisions.

An effective AI governance policy covers five things.

• A current list of approved tools and where to find them.
• Clear data classification rules specifying which categories of data, including customer records, source code, and financial information, should never be entered into any AI tool.
• A verified data training opt-out status for each approved tool. Many AI tools use company inputs to improve their models by default unless enterprise settings are explicitly configured otherwise. Approval should require a confirmed opt-out for any tool that handles sensitive data.
• A defined process for requesting new tools, with a target turnaround time.
• A plain-language explanation of why the guidelines exist.

That last element matters more than it might seem. Employees who understand why OAuth connections carry data exposure risk apply that reasoning to every tool decision they make. Policy becomes a form of education when the reasoning is included.

Shadow AI grows fastest in organizations where the official approval process cannot keep pace with the rate of AI product releases. An employee who needs a tool today and faces a six-week security review will find a workaround within days. The goal of this step is to remove that friction.

• Most AI tool requests do not warrant a full procurement review. A structured intake form with defined evaluation criteria is enough for the majority of lower-risk tools.
• A structured intake form and a defined set of evaluation criteria make faster decisions possible. For tools with limited data access, many organizations find a shorter turnaround feasible once evaluation criteria are documented and consistently applied.
• The evaluation criteria should cover data access scope, vendor security practices, data training opt-out status, compliance certifications, and whether the tool already has a functional equivalent on the approved list.

Security teams that publish their approved tool list openly and keep it current typically see a meaningful reduction in shadow AI usage. When employees know where to find the right tools, they use them.

Step 4: Use Monitoring as a Shared Safety Layer

Continuous visibility into AI tool usage across an organization serves two groups simultaneously.

• Security teams get the real-time picture they need to identify and address exposure before it becomes an incident.
• Employees get a form of protection they often do not have on their own: a signal when a tool they are using may be putting their credentials or company data at risk.

A browser-native monitoring approach gives security teams visibility into AI activity without rerouting employee web traffic or adding friction to daily work. The signals it captures feed into each employee's broader risk profile, sitting alongside their phishing simulation results and training completion data in one place.

That combined view matters because risky behaviors compound. An employee who clicks phishing links, skips training, and runs unapproved AI tools with access to sensitive data presents a much higher risk than any single behavior would indicate. Seeing the full picture in one place helps security teams focus on the employees who need attention most.

Step 5: Make Good Security Behavior Easy

Security programs that make the secure choice the easiest choice are the ones employees follow. In the context of AI governance, two things drive that: just-in-time coaching and training that explains the reasoning behind the rules.

Just-in-time coaching delivers a brief, contextual prompt at the moment an employee attempts to use an unsanctioned tool. This is more effective than quarterly training modules, because the intervention happens at the point of decision. A well-designed prompt tells the employee what the concern is, directs them to an approved alternative, and takes less than thirty seconds to read.

Training that explains the reasoning behind AI governance policies builds the kind of judgment employees can apply across any situation they encounter, including tools and threats that emerge long after the training itself. The AI tool landscape is changing fast enough that no training program can anticipate every specific case. An employee who understands that OAuth connections to corporate Google Workspace can expose the entire shared drive to a third-party vendor will apply that understanding to tools that did not exist six months ago.

Building a Security Program Based on How Teams Work

AI adoption is a signal of productive teams doing their jobs well. Companies that build practical programs around that momentum, with clear paths to approved tools and real-time visibility for security teams, tend to handle it best.

Security teams that close that gap find that shadow AI usage declines organically over time. Browser-native visibility, clear paths to approved tools, and just-in-time coaching at the moment of risk are what make that possible. When employees have access to effective, approved tools and a fast, transparent path to get new ones reviewed, the incentive to work around the system largely disappears.

Adaptive Security's AI Governance product gives security teams real-time visibility into every AI tool and shadow app running across their organization, with automated policies and just-in-time employee coaching built in. Learn more at adaptivesecurity.com.

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/0pqmM1T
via IFTTT

Gitea Vulnerability Exposes Private Container Images without Authentication

Cybersecurity researchers have disclosed a security flaw in Gitea, an open-source, self-hosted platform for version control, that allows unauthenticated remote attackers to pull private container images from Gitea deployments without requiring an account, password, or other credentials.

The vulnerability, tracked as CVE-2026-27771 (CVSS score: N/A), affects all versions of Gitea prior to 1.26.2, which addresses the issue.

According to Noscope, the security defect likely impacts more than 30,000 deployments across over 30 countries and went undetected for close to four years. The vast majority of the exposures are in China, the U.S., Germany, France, and the U.K. Affected organizations span healthcare providers, aerospace manufacturers, retail infrastructure, and internet service providers.

"On affected versions, the private designation on a container repository did not deliver the protection operators reasonably expected it to," Noscope said.

"Gitea's container registry has allowed any person on the internet, with no account, no password, and no prior access, to pull what would be considered private container images at first glance from affected instances as if they were public."

The U.K.-based security company also pointed out any fork of Gitea should be treated as potentially impacted by the vulnerability until it's been independently verified by the respective maintainers. In its own testing, Forgejo has been confirmed to be impacted. No additional technical details are currently available.

Gitea users are advised to update to version 1.6.2 for optimal protection. If patching is not an immediate option, a temporary workaround is to set [service].REQUIRE_SIGNIN_VIEW=true in the Gitea configuration. However, it's worth noting that this approach isn't ideal if some containers are meant to be intentionally exposed publicly.

from The Hacker News https://ift.tt/qZytWDK
via IFTTT

Introducing EvidenceForge: Synthetic security logs that don’t look (as) fake

• Security teams need high-quality, labeled datasets to train threat hunters and incident responders, validate detection logic, and develop robust analytic models. 
• EvidenceForge helps teams overcome the limitations of anonymized or stale public datasets, while avoiding the cost and complexity of setting up real infrastructure and performing manual attack simulations to create their own.
• The tool incorporates sophisticated timing models and assigns specific roles to users and systems, generating realistic malicious activity, background noise, and “red herrings” to optimize data realism. 
• The tool generates correlated logs across 20+ Windows, Linux, and network monitoring formats using a canonical event model that ensures causal and temporal consistency.

---

Good data is hard to find... and to create

A lot of important work in security depends on having realistic log data to work with, and a lot of that work gets blocked, watered down, or quietly skipped because the data just isn’t available. The use cases come up constantly: teaching threat hunters, incident responders, and detection engineers with datasets that have known ground truth; validating that a detection fires on the right activity without drowning in false positives; and training ML models that need labeled, balanced, multi-source telemetry at scale.

These are different problems with the same root cause. You need realistic, labeled security logs and you can’t get them easily. The options are limited:

• Real production telemetry is a compliance problem. Public datasets are often so heavily anonymized they no longer resemble the original log sources. The LANL dataset and OpTC are well-known examples of data scrubbed to the point of being generic event representations rather than actual telemetry. What isn’t anonymized is stale, narrow, and over-recycled.
• You can generate data yourself using attack simulation frameworks like Atomic Red Team or MITRE Caldera, but that requires real infrastructure, is time-consuming to operate, and scales poorly when you need variety. 
• You can hire a red team, which trades complexity for money but still takes weeks and produces only the specific scenario they ran. 

Synthetic generators seem like an obvious solution and many existing ones are genuinely useful tools, but they share a common architectural limitation: They generate events independently, one format at a time, with no shared state across log sources. The result is datasets where events don’t tell a coherent story. For example, a process in Sysmon doesn’t connect to the same process in standard Windows logs, or a network logon doesn’t leave a consistent connection trace. More capable tools support attack chains and MITRE ATT&CK mapping, but even then, they generate individual events rather than simulating something that happened, with all the prerequisite and consequent evidence that real activity would produce. Realistic background noise is largely absent.

What analysts detect when they call data synthetic is the absence of a coherent causal story. The logs don’t line up because they emit each log entry independently from the others, and they are not modeling a series of connected events.

The answer: A new kind of synthetic data

EvidenceForge is a new open-source project from Cisco Talos that approaches the problem differently. It features a single canonical event model, causal ordering, realistic background noise, and AI-assisted scenario authoring. The result is a synchronized dataset across 20+ log formats (Windows, Linux, network, and endpoint detection and response [EDR] telemetry), complete with ground truth documentation and an analyst briefing.

One honest note: No purely synthetic dataset will fool a seasoned analyst in every case, but that’s okay. The goal is fidelity that’s good enough to be useful, not something that’s indistinguishable from production.

The core idea: One event, many formats 

Most synthetic log generators are a collection of independent emitters. Each one knows how to produce its own format but doesn’t share state with the others. You can see the seams the moment you cross-reference across sources. 

EvidenceForge inverts that. Every piece of evidence flows from a single canonical SecurityEvent object. That object carries a timestamp and event type, plus over 30 composable context objects populated as needed: ProcessContext (PID, parent PID, image, command line), NetworkContext (src/dst IP and port, Zeek UID, shared across Zeek, EDR, and SNORT®), AuthContext (username, LogonID, logon type, result), DnsContext and HttpContext (protocol-layer detail that fans out into the corresponding Zeek log types), and many more. Emitters read only the fields relevant to their format.

The consequence of shared contexts is that emitters cannot disagree. There is one PID, one LogonID, one timestamp, and one Zeek UID. The engine is also OS-aware: Windows hosts produce Security Events and Sysmon while Linux hosts produce syslog and bash history, each according to the OS assigned to each host in the scenario. 

All of this is driven by a scenario configuration file: a YAML document describing the environment (hosts, users, network topology) and an optional attack storyline. The engine reads that file and produces the correlated dataset. 

What the engine produces 

From a single scenario, EvidenceForge generates several correlated log formats:  

• Windows Security Events (30 event IDs covering authentication, process lifecycle, Kerberos, persistence, account management, and more) 
• Sysmon (10 event IDs) 
• EDR/XDR telemetry 
• Linux syslog 
• bash history 
• Zeek logs in JSON format 
• Snort IDS alerts 
• Firewall logs 
• Web server access logs 
• Forward HTTP proxy logs 

The exact output logs depend on a combination of the components in the simulated environment, and which log sources you may have opted to disable. 

Every attack scenario also produces two companion documents.  

• “ENVIRONMENT.md” is an analyst briefing consisting of organizational context, network layout, user roles, naming conventions — everything an analyst would need before diving into the logs, with zero information about the attack itself.  
• “GROUND_TRUTH.md” documents exactly what happened including a narrative, a timeline, and key IOCs. 

Causality, not just sequence 

Real logs are both temporally and causally ordered. Before a domain logon, there’s a Kerberos TGT, then a TGS. Before a TCP connection to a hostname, there’s a DNS query. This is the physics of how the protocols work.

EvidenceForge ships with a composable rule engine that auto-generates prerequisite events with realistic timing offsets so that each event sits exactly where an analyst would expect to pivot to it: 

• A logon in the scenario expands to the Kerberos exchange that made it possible. 
• A connection to a named host gets the DNS resolution inserted beforehand. 
• A privileged admin command generates downstream audit events. 

Network visibility is a first-class concept 

Most synthetic generators are too visible, meaning that every connection gets a log, regardless of whether a sensor would have seen it. Real networks don’t work that way. Traffic between hosts on the same VLAN may never cross a SPAN port. East-west traffic in a segmented network may be invisible to perimeter sensors. A TAP at the internet edge sees outbound traffic but nothing internal. 

EvidenceForge lets you declare sensor placement in the scenario: SPAN or TAP, monitored segments, and direction. The engine determines which connections each sensor could realistically observe and only emits network logs where they’d actually appear. If your environment has a monitoring gap, the generated data has that same gap, which is exactly the kind of thing analysts need to learn to reason about.

AI co-develops the story; a script generates the evidence 

The hard part of realistic synthetic data is scenario design, not generation. Describing a coherent attack lifecycle with the right tactics, techniques, and procedures (TTPs); realistic sequencing; and plausible actor behavior requires research and protocol knowledge most people don’t carry in their heads.

EvidenceForge addresses this with Claude/Codex skills. You bring intent (an attack type, an environment, a training objective), the AI brings research and technical scaffolding (a guided interview, MITRE ATT&CK TTP research), and together you collaboratively develop the attack narrative, resulting in a validated YAML scenario file.

The YAML is version-controllable, shareable, and editable. Once it exists, generation is entirely deterministic: a Python script reads the config and produces all the correlated log evidence.

This separation is the optimal balance of what each technology is good at. AI excels in narrative coherence, TTP research, and protocol knowledge. A deterministic script excels at the thousands of cross-referenced field values, causal prerequisite chains, and inter-format consistency checks that make up a realistic dataset. This would overwhelm even a capable LLM at scale, and hallucinated field values or subtle inconsistencies would undermine the whole point.

A typical scenario costs pennies in API calls to co-develop, and the data generates in seconds or minutes rather than the hours or days an LLM-based approach would require. EvidenceForge also produces identical output every run because randomness is seeded. Built-in validation checks the scenario for schema correctness and cross-reference integrity before generation runs, and the AI can automatically fix most errors it finds.

Making the background convincing 

Attack events are only useful if analysts have to work to find them. Noise quality matters as much as signal quality. 

EvidenceForge’s baseline engine generates several types of realistic background noise, including: 

• Legitimate lateral movement patterns (backup agents, monitoring tools, AD replication, application-to-database traffic) 
• User and application-driven network activity (web browsing, SMB file share access, RDP sessions, scheduled service polling) 
• Per-user diversified command pools, depending on user role 
• Red herrings (suspicious-looking events or patterns that are benign) 

Timing is just as important as content. Volume-level realism without burst-level texture still looks synthetic. EvidenceForge uses three complementary timing models:

• A Hawkes process for user activity, a self-exciting model where each event makes the next more likely for a short window, then decays, matching how people actually work in bursts
• A periodic envelope for large-scale structure (Monday login storms, Friday drop-off, and near-zero weekends)
• Periodic intervals plus jitter for modelling recurring automated events like scheduled tasks, background updates, and other system and service traffic 

Most timing details are exposed in the scenario or engine config files, so you can tweak them to make them as realistic as you like for your simulated environment. 

Getting started 

EvidenceForge is available on GitHub. Clone the repo and follow the install instructions in the README. 

The core experience is a guided conversation. Start the /eforge:scenario command and describe what you want. You can be as specific or as vague as you like. Bring a fully formed scenario and the AI helps translate it into a valid configuration; bring a rough idea and it asks the right questions, fills in the gaps, and makes suggestions until you have something technically coherent and satisfyingly realistic. From there, the skill leads you through validation, generation, and a brief automated data quality evaluation. You come out the other end with a complete, correlated dataset and companion documents. A full CLI is also available for scripted workflows.

What will you build? 

EvidenceForge removes the data bottleneck. The question becomes what you do with that. The following are just a few examples: 

• Build a SOC analyst training program with scenarios tailored to your environment. 
• Test detections against controlled, labeled datasets before they go near production. See whether they fire on the attack and how they behave against realistic noise.
• Generate the labeled training data your ML model needs.  
• Stress-test a new SIEM or detection pipeline against volume and variety you control. 
• Create repeatable practice exercises that can be regenerated on demand after tuning.

The scenarios themselves are shareable artifacts. A scenario developed for one team can be shared, adapted, or built on by others. The right mental model is high-fidelity training and testing data — not a production telemetry substitute — but within that framing, the use cases are broad.

from Cisco Talos Blog https://ift.tt/PVBXh1I
via IFTTT

AI Chatbot Recommendations Redirect Users to Cryptojacking Malware Sites

Microsoft has warned of an active cryptojacking campaign that makes use of artificial intelligence (AI) chatbot interactions as a mechanism for surfacing malicious download sites.

"This emerging delivery technique extends social engineering beyond conventional search results and increases the visibility of malicious software recommendations," Microsoft Defender Experts and the Microsoft Defender Security Research Team said in a report published Tuesday.

The activity, per the tech giant, impersonates legitimate system utilities like CrystalDiskInfo, HWMonitor, Display Driver Uninstaller, FurMark, K-Lite Codec Pack, and PDFgear, likely in an attempt to target users who own high-performance GPUs. The idea is to focus on compromising systems with higher mining value than indiscriminately infecting a large number of machines, it added.

The goals of the campaign are not merely financially motivated. The threat actors have also been found to establish persistent remote access to compromised hosts through ScreenConnect deployments, which could then be leveraged for follow-on activity, such as data theft, lateral movement, or ransomware.

The attack chain is more deliberate than other typical cryptocurrency mining efforts, strategically opting for endpoints that help maximize GPU mining yield per compromised device. The Windows maker said it detected and blocked activity associated with the campaign.

It all begins when users search for trusted system utilities and hardware-monitoring software on search engines, which surface malicious sites that have been gamed via techniques like search engine optimization (SEO) poisoning. Subsequent iterations observed in April 2026 indicate that users are being directed to these sites not through search engine results, but rather via interactions with large language model (LLM)-based tools.

"In these cases, users querying AI chatbots for software download recommendations were presented with links to attacker-controlled domains within generated responses," Microsoft said. "While this behavior is based on observed patterns and correlated data sources, it's consistent with emerging techniques in AI search result poisoning, representing an extension of traditional SEO poisoning beyond conventional search engines."

Each of these sites contains a prominent download button that retrieves a ZIP archive from a campaign-specific subdomain of gleeze[.]com, which is hosted by infrastructure associated with Dynu, a dynamic DNS provider frequently used by threat actors. More than 150 malicious domains have been identified serving the malicious tools.

The downloaded ZIP file contains a legitimate executable along with a rogue DLL ("autorun.dll") that's sideloaded when the binary is launched by the user. The DLL is designed to install a second malicious DLL named "vcredist_x64.dll" using "msiexec.exe." The file is a packaged installer for ScreenConnect software.

Once ScreenConnect is installed, the client continuously attempts to establish contact with an attacker-controlled server located at "193.42.11[.]108." The ScreenConnect session then serves as a conduit for an executable called "SimpleRunPE.exe."

The binary is responsible for establishing persistence on the host using Registry Run keys and scheduled tasks, configuring Microsoft Defender exclusions, running anti-analysis checks, and employing process hollowing to launch the mining code under a trusted Microsoft-signed binary.

In select compromises, instead of relying on ScreenConnect's file transfer functionality to drop the binary, a PowerShell script is used to fetch the binary from a remote drive, store it locally as "vlc.exe" to fly under the radar, create a scheduled task to launch it, and then delete itself.

The hollowed binary, for its part, communicates with the attacker's server, transmits extensive host information, downloads the appropriate miner archive at runtime, and executes it. Three miner programs are supported by the malware: gminer, lolMiner, and SRBMiner-MULTI.

In addition, the binary recreates the persistence artifacts to ensure continued presence and re-configures Defender exclusions in the event they are removed. It also keeps an eye out for running processes, and proceeds to immediately terminate the miner if any of the following processes are detected -

• taskmgr.exe (Windows Task Manager)
• processhacker.exe, processhacker2.exe (Process Hacker)
• procexp.exe, procexp64.exe (Process Explorer)
• systeminformer.exe (System Informer)

"This combination of AI-assisted delivery, software impersonation, and persistent access highlights how threat actors are adapting social engineering and monetization strategies to modern user behavior," Microsoft said.

The disclosure comes days after Microsoft detailed how an unknown threat actor compromised an internet-facing F5 BIG-IP firewall appliance and abused trusted relationships to pivot to an internal Linux host, highlighting the continued exploitation of internet-facing edge appliances as initial access points.

The Linux host, the company said, enabled the attacker to perform comprehensive reconnaissance and laterally move to a vulnerable Atlassian Confluence server, although attempts to execute remote code through unpatched security flaws in the software were unsuccessful.

As a way of getting around these restrictions, the threat actor is said to have set up an FTP server on the initial Linux host using Python's ftplib module to transfer a custom scanning tool to the Confluence server and then obtained credentials for subsequent authentication against Windows infrastructure. This was followed by Kerberos relay attacks and the exploitation of CVE-2025-33073.

"From there, the threat actor compromised a vulnerable SaaS application and leveraged its credentials to conduct relay-style authentication attacks against Active Directory," it said.

"In this incident, the threat actor authenticated to a Linux server over SSH using a privileged account. The threat actor maintained this level of access throughout the observed activity without establishing explicit persistence mechanisms, underscoring the risk posed by over-privileged identities with sudo rights."

Earlier this month, Microsoft also shed light on another intrusion in which attackers abused trusted operational relationships and authentication processes to establish durable access, leveraging a compromised third-party IT services provider and legitimate IT management tools to orchestrate a covert campaign focused on long-term access and credential theft.

"Third-party service providers and integrated management tools can become enforcement gaps when visibility is limited or validation is assumed. Threat actors understand this," Redmond said. "They leverage legitimate components, trusted update paths, and approved integrations to anchor themselves inside environments that appear compliant on the surface."

"Defenders should adopt a posture of deliberate verification. Trust your vendors and tooling, but validate their behavior within your environment. Organizations operating in sensitive sectors should assume that threat actors with this level of tradecraft will continue refining third party abuse, credential interception, and stealthy persistence mechanisms to maintain strategic access."

from The Hacker News https://ift.tt/wYr65mV
via IFTTT

CloudStack European User Group Reaching New Milestones in The Hague

Last week, the CloudStack European User Group took place in The Hague. With a record number of attendees, it officially became the largest CloudStack User Group event to date.

Hosted by CBS – Statistics Netherlands, and supported by ShapeBlue and Cyso Group, the event brought together cloud experts, researchers, technology providers, and many professionals attending their very first CloudStack community event.

The day was packed with technical sessions, insightful discussions, and opportunities for collaboration across the open-source cloud ecosystem.

 

Welcome to the CloudStack European User Group – Ivet Petrova, ShapeBlue

Ivet Petrova opened the event with an introduction to the Apache CloudStack community, highlighting the platform’s growth, goals, and future direction.

The session focused on fostering collaboration around cloud technologies, including hypervisors, storage solutions, and ecosystem integrations, while showcasing the strength of the CloudStack community.

 

CBS Digital Sovereignty Strategy – Erik Logtenberg, CBS

Representing Statistics Netherlands, Erik Logtenberg shared how digital sovereignty is becoming a strategic priority for public sector organizations.

Attendees gained insight into how the Dutch national statistics office approaches cloud independence, resilience, and long-term infrastructure control, while reducing dependency on external vendors without compromising flexibility or performance.

What’s New in Apache CloudStack – Release and Features Overview – Boris Stoyanov, ShapeBlue

Boris Stoyanov explored the latest Apache CloudStack 4.23 release and its newest features and enhancements.

The session highlighted improvements in performance, usability, and scalability, and provided practical guidance on applying these updates in real-world environments to maximise the value of CloudStack deployments.

 

A Deep Dive into the Integration of CloudStack and Ceph Primary Storage – Wido den Hollander, Your.Online

Wido den Hollander delivered a deep dive into integrating Apache CloudStack with Ceph as primary storage — widely regarded as a gold standard for organisations building reliable, open-source IaaS platforms.

The session covered architecture, deployment patterns, and key design considerations for building scalable and resilient cloud environments. Attendees also gained practical insights into performance optimisation, high availability, and operational best practices, supported by lessons learned from more than a decade of hands-on experience with both technologies.

Digital Sovereignty in Practice: Building a High-Performance Cloud Without Vendor Lock-In – Swen Brüseke, ProIO

Swen Brüseke explored why digital sovereignty has evolved from a buzzword into a critical strategy for enterprises.

The presentation focused on how ProIO has relied on Apache CloudStack since 2013 to build high-performance, cost-effective private cloud platforms free from vendor lock-in. Swen also shared technical insights into their infrastructure stack, from LINBIT-based hyperconverged infrastructure (HCI) to the company’s strategic partnership with ShapeBlue.

LINSTOR as CloudStack Primary Storage: From Theory to Production War Stories – Rene Peinthor, LINBIT

Rene Peinthor introduced LINSTOR-SDS before diving into real-world production challenges, operational lessons, and practical strategies for avoiding common pitfalls when deploying LINSTOR with CloudStack.

Kubernetes Is Not the New VM: Choosing the Right Abstraction for Modern Infrastructure – Stoil Sotilov, StorPool Storage

In this session, Stoil Sotilov challenged the common assumption that Kubernetes replaces virtual machines.

Instead, the talk presented a practical framework for deciding when to use Kubernetes and when virtual machines remain the better choice — particularly in CloudStack environments. The session explored differences in isolation, lifecycle management, networking, and operational complexity, while highlighting real-world scenarios where each technology performs best.

Safeguarding Apache CloudStack – Data Protection & Recovery Powered by Commvault – Marc De Schepper, Commvault

Marc De Schepper demonstrated how Commvault enhances Apache CloudStack with enterprise-grade data protection and recovery capabilities.

The session provided insight into Commvault’s broader portfolio while showcasing strategies for building cyber resilience through practical implementation blueprints and live demonstrations.

CloudStack Multisite Networking – Noa Omer, Cyso Group

Noa Omer presented how Cyso Cloud deploys Apache CloudStack to establish multisite networking across two geographically distributed regions.

The presentation covered cross-region zone interconnectivity, network fabric design, and routing configuration, alongside an honest discussion of operational complexities, challenges, and outcomes.

From VMware to CloudStack/KVM: A Structured Migration Strategy with Minimal Downtime – Ingo Jochim & Prashanth Reddy, ShapeBlue

Ingo Jochim and Prashanth Reddy presented a practical and structured approach to migrating from VMware to Apache CloudStack with KVM.

As organisations increasingly look to reduce vendor lock-in and regain infrastructure control, the session explored the full migration lifecycle — from environment discovery and planning to testing and large-scale execution.

A key focus was minimising downtime through techniques such as warm migration, pre-staged bulk data transfer, and short cutover windows using delta synchronisation.

 

CBS – Our CloudStack Journey – Abdurrahman Ali & Perry Smolenaars, CBS

The event concluded with Abdurrahman Ali and Perry Smolenaars sharing the CloudStack journey of Statistics Netherlands.

They discussed when and why CBS decided to adopt Apache CloudStack, the challenges encountered along the way, and the benefits the organization has achieved through its open-source cloud strategy.

Session recordings will be available soon.

Continuing Our Commitment

At ShapeBlue, we are proud to once again stand alongside the Apache CloudStack community as both sponsors and contributors. Events like the CloudStack European User Group demonstrate the strength of open collaboration and the value of openly sharing expertise and innovation.

Together with our partners, we remain committed to supporting the global growth and adoption of Apache CloudStack.

We would like to thank all speakers, sponsors, and attendees for making this event such a success. We look forward to the next opportunity to come together as a community.

The next major event is the CloudStack Collaboration Conference — the largest annual CloudStack event — taking place from 18–20 November in Edinburgh. Don’t miss it.

Register Now

 

A gallery from the event in The Hague:

The post CloudStack European User Group Reaching New Milestones in The Hague appeared first on ShapeBlue.

from CloudStack Consultancy & CloudStack... https://ift.tt/7AWZ0Lo
via IFTTT

The Untrusted Autonomous Workload: How AI Coding Agents Reshape What Isolation Has to Do

Earlier this year I mass-migrated my blog to Astro using Claude Code. 146 posts. 6,024 images. Canonical URLs, JSON-LD markup, sitemap generation, the whole stack. I’d spent hours writing a skills file to teach the agent about my blog’s architecture, how deployment worked, what not to touch. And it worked. Claude Code rewrote components, fixed trailing-slash mismatches across hundreds of pages, added BreadcrumbList structured data to hundreds of routes. Lighthouse scores hit 97 on performance. The blog looked better than it ever had.

The problem was that I had stopped understanding my own codebase.

Not completely. I could still read the files. But somewhere around the third round of “fix the error that the last fix introduced,” I caught myself copy-pasting stack traces back into Claude and trusting whatever came back. The agent would make a change, something else would break, I’d ask the agent to fix that too, and a few cycles later the blog worked again. I couldn’t have told you what was actually in the PostCSS config or why the GA4 integration was wired up the way it was. It worked. It looked great. My confidence in what was underneath had quietly evaporated.

That feeling (it works, thank god, let’s not touch it) is the feeling of having given an autonomous agent real access to your codebase. Every developer using these tools knows it. Nobody writes about it in vendor blog posts. And it’s what made me understand, on a level deeper than reading documentation, why Docker had to build Sandboxes.

Because here’s what I hadn’t thought about: while Claude Code was rewriting my Astro components and fixing image CLS across hundreds of files, every npm install it ran happened on my laptop. Same for every file it modified and every package it pulled. My user privileges, no boundary in sight. If the agent had decided to modify a Git hook or rewrite a CI workflow, I would not have noticed. I wasn’t reviewing individual file changes at that point. I was reviewing outcomes. And reviewing outcomes while skipping changes is not a security model. It’s a prayer.

Docker Sandboxes exists to close that gap.

The container model and why it doesn’t stretch here

Containers were never the wrong abstraction. They were the right abstraction for a world where you knew what was inside them. For twelve years that world held: you wrote the code, you reviewed it, you put it in a Dockerfile, and the container gave it a clean room to run in. Shared kernel was fine because the threat model was bugs in your own software, not surprises from a tenant you’d just invited in.

AI coding agents don’t fit. They aren’t bugs in your software because they aren’t your software. They’re a new kind of tenant, one that’s autonomous and privileged in ways that would make any security engineer nervous. The agent installs packages you didn’t pick and runs commands you didn’t script. It makes network calls you’d never have predicted, to endpoints you didn’t know were in your dependency tree. The trust profile is code being written right now, by something that won’t pause to ask permission. Containers were built for a different kind of code.

This isn’t hypothetical. On March 19, 2026, attackers force-pushed 76 of the 77 version tags in aquasecurity/trivy-action and published a malicious Trivy v0.69.4 binary to GitHub Releases. The exposure window was about 12 hours. The compromised code scraped CI runner memory for secrets, cloud credentials, SSH keys, and Kubernetes tokens, exfiltrating them to a typosquatted domain. Every pipeline that referenced trivy-action by version tag during that window ran code nobody on the receiving end had reviewed.

What gets me about Trivy: the weaponized tool was a vulnerability scanner. The thing organizations deployed to find malicious code became the malicious code. The maintainers didn’t write the bad binary; a compromised CI workflow with too much access and not enough containment did. Substitute “compromised CI workflow” with “AI agent in permissive mode” and you have the same threat model, running all day on every developer machine.

Containers were the right answer to “I trust this code, I want to run it cleanly.” They were never going to be the right answer to “I don’t fully trust this code, and I want to give it real work to do anyway.” That’s the gap microVMs fill.

What Docker built, and why each piece is there

First choice: don’t patch containers. There’s a long tradition in our industry of making a familiar abstraction handle a new problem by adding flags to it. Privileged mode, capability dropping, seccomp profiles, gVisor in front of runc. All of those have their place. None of them solved the specific issue that an autonomous agent needs its own Docker daemon. Docker-in-Docker either compromises the isolation (privileged mode, host socket mounting) or creates a nested complexity that becomes its own attack surface. The Docker docs are blunt about this. Containers, they say, share the host kernel and “can’t safely isolate something that needs its own Docker daemon.”

Once you accept that, you end up at a VM. Not a heavyweight one (booting Ubuntu Server for every coding session would be absurd) but a microVM: light enough to start in seconds, with just enough kernel to run the agent’s containers.

Docker Sandboxes uses a custom VMM, not Firecracker. If you’ve read the Firecracker spec and you’re thinking “boots in 125ms with under 5MB of overhead,” those are Firecracker’s numbers, not Docker’s. Different microVM implementations have different cost profiles. Platform specifics: Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows, KVM on Linux.

Caption: The Sandbox architecture. Each microVM runs its own kernel and its own Docker Engine. Credentials never cross the VM boundary.

Inside each microVM, the sandbox runs a complete Docker Engine. When the agent runs docker build, that command goes to a private daemon that doesn’t know your host containers exist. When it pulls an image, the image lives inside the sandbox VM. When you delete the sandbox, the entire image cache goes with it. Multiple sandboxes don’t share layers. Wasteful. Worth it.

The first time I looked inside a running sandbox, the agent was running as root with sudo and full Docker Engine access inside the VM. My reflex was that this had to be wrong. You don’t give root to untrusted code. But the design is right: the isolation model doesn’t constrain what the agent does inside the boundary. It constrains where the consequences land. Inside the VM, the agent can do whatever it wants. Outside? Nothing. Trying to lock the agent down with capability dropping inside the VM would be solving the wrong problem. The agent legitimately needs to install packages and run docker build. What it doesn’t need is for any of that to touch your laptop.

Caption: From the host, sandboxes don’t show up in docker ps because they aren’t containers; sbx ls is how you see them.

The network layer is where it gets interesting, because it doubles as the credential boundary.

Outbound HTTP/HTTPS traffic routes through a proxy on the host, accessible from inside the VM at host.docker.internal:3128. UDP and ICMP are blocked at the network layer and can’t be allowed by policy. Non-HTTP TCP (like SSH) needs explicit IP+port rules. DNS resolution goes through the proxy. If a request can’t go through the proxy, it doesn’t leave. The proxy terminates TLS, inspects the host header, applies your policy, and re-encrypts with its own certificate authority that the sandbox trusts. Man-in-the-middle by design. Docker uses that exact framing in the documentation.

MITM is what makes credential injection work. Agents need API keys: for the AI provider, for registries, sometimes for cloud accounts. Naive answer is to pass those credentials in as environment variables, where they sit inside the VM and follow it everywhere. Docker instead keeps credentials on the host, in your OS keychain, and has the proxy inject them into outbound requests transparently. The agent sees requests that just work, and the VM never had the secrets to begin with. The docs don’t hedge on this: credential values are never stored inside the VM. A compromised sandbox can’t exfiltrate your API keys because your API keys were never in there.

Docker tells you what won’t work

Sandboxes documentation has a quality that’s rare in security architecture docs: it tells you what the system doesn’t protect against. Most of these documents are written to make a product look strong. Docker’s docs surface the limits. Two of them matter.

The first one is about the network policy.

At first sbx login, you pick one of three default policies. Open allows everything except blocked CIDR ranges (private networks, link-local addresses, cloud metadata endpoints). Balanced denies by default but pre-allows common dev domains. Locked Down denies everything until you explicitly allow. Locked Down is the strictest option, the deny-by-default mode you’d want if you were paranoid. But even with Locked Down and a curated allowlist, the proxy filters by domain, not by content.

Here’s the exact language from the docs: allowing broad domains like github.com permits access to any content on that domain, “and agents could use these as channels for data exfiltration.” Security vendors don’t usually say this about their own products. If github.com is on your allowlist (and it almost certainly is, because the agent needs to clone repos), the proxy knows the request is going to github.com. It does not know whether the agent is reading documentation, cloning a repository, or creating a public gist with the contents of your .env file. All three look identical at the domain level. Same goes for every allowlist entry that includes user-generated content: Discord webhooks, Notion pages. “The domain is allowed” doesn’t mean “only safe content lives there.”

Caption: Under a deny policy, non-allowlisted domains are blocked. Allowlisted domains succeed, including domains that host arbitrary user-generated content.

Docs also acknowledge domain fronting as an inherent limitation of HTTPS proxying. Proxy sees which domain a request claims to be going to; it cannot always prevent the request from being routed elsewhere through that allowed CDN.

The microVM boundary is the primary isolation. Network proxy is a useful additional control, especially for blocking accidental access to internal networks. It is not a hermetic seal, and Docker doesn’t claim it is. “The agent is on a deny policy” is not the same thing as “the agent cannot send data anywhere.”

The workspace is always shared

Network policy is the smaller honest limit. Workspace sharing is the bigger one.

The microVM boundary is strong everywhere except for one path that crosses it on purpose: the workspace directory.

The whole point of running an agent in a Sandbox is for the agent to do real work in your real codebase. Docker shares the workspace between the host and the sandbox at the same absolute path. When the agent edits a file inside the sandbox, the file changes on your host. When you pull a new commit on your host, the agent sees it. This is the design. It’s exactly what you want from a developer tool.

It’s also a covert channel that the agent has legitimate write access to.

Docker security documentation spells out what “the same files” includes, and this is what matters: files that execute implicitly during normal development. Git hooks. CI configurations. IDE task definitions. Makefile targets. package.json scripts. Pre-commit configs. Anything that runs when you do something that feels like just “using your tools.”

Simplest version of the attack: an agent inside the sandbox writes a malicious post-commit hook to .git/hooks/post-commit. Git hooks don’t appear in git diff. They live in .git/, which most developers never open. Next time you commit on your host, the hook runs on your host with your user privileges. Sandbox boundary doesn’t matter, because the boundary ended at the workspace, and the workspace was always shared.

Which brought me back to my own Astro migration, uncomfortably. I’d let Claude Code rewrite hundreds of files across my blog. I’d reviewed the outcomes (Lighthouse scores, visual appearance, build success) but I had not audited every file it touched. Had not checked .git/hooks/. I’d never opened that directory in my life. Had not read every package.json script before running npm install. I’d been doing exactly the thing the documentation warns about: treating the agent’s output as reviewed code when it was unreviewed code that I was about to execute on my machine.

It would be easy to read this as “Sandboxes are broken.” That’s not what I mean. The microVM does exactly what microVMs are supposed to do: it contains the consequences of arbitrary code execution behind a hardware boundary. What it cannot do is make the workspace contents safe, because the workspace contents are how the agent does its job. The agent has to be able to write files. You have to be able to read them. Shared region is necessary, and the shared region is where the threat model gets interesting.

Mitigation isn’t more isolation. The microVM is doing its job. Mitigation is discipline: treat the workspace contents the way you’d treat a pull request from a contributor you don’t know yet. Diff .git/hooks/ after agent sessions. Read package.json scripts before running npm install. Use the --branch flag, which creates a Git worktree so the agent works in an isolated branch you can review before merging. None of this is exotic. It’s just the practice of not treating autonomous-agent output as trusted code. Because it isn’t.

I’m spending this much space on it because it’s the part most people get wrong. Hypervisor boundary makes you feel safe, but you aren’t. Not completely. Both things have to be true at once for the product to work, and the Docker team built it that way on purpose. Good security architectures document their gaps and make sure the user knows what they’re signing up for.

What it actually costs

Hypervisor isolation isn’t free, and you can’t pretend otherwise. I tested this against my own production codebase, the same Astro blog I mentioned at the top, because synthetic benchmarks for sandboxed agent workloads don’t tell you much. You want to know what it feels like to do real work.

Caption: The same docker build --no-cache against the same Astro codebase. Host: 1:44.62. Sandbox microVM: 1:28.58. The isolation boundary is invisible to the workload. On this run, the sandbox actually finished faster.

I ran docker build --no-cache against the same Dockerfile and the same codebase, once on the host and once inside the sandbox. Host finished in 1:44.62. Sandbox finished in 1:28.58, actually faster, within noise across runs. The Docker Engine inside the sandbox is running on its own kernel with its own block device, completely isolated from the host, and the build doesn’t care. The microVM adds essentially zero overhead to the actual build.

One real-world caveat from running this on Apple Silicon: a Rust dependency in my Astro pipeline ships jemalloc that assumes 4K page sizes, which fails on sandbox VMs (16K pages). The build itself completed correctly. All 354 pages rendered, dist generated, but a teardown step exited non-zero. The fix was a one-line guard in the Dockerfile that checks for valid build output before exiting. Took 30 minutes to track down. Worth knowing about before you ship sandbox-aware Dockerfiles on Apple Silicon, because the symptom looks like a build failure when the build actually succeeded.

Verdict: for session-based agent work (a few hours on a project), the overhead disappears. For high-frequency sandbox creation (dozens per minute for short tasks), cold-start cost adds up. For the workload Sandboxes is designed for, which is giving an agent a real environment for a real session, the trade is sound.

Matching isolation to trust

Most discussions of containers versus VMs treat it as a binary, and that’s the wrong frame. The frame I’ve found useful, both for my own work and in conversations with engineering leaders who ask “do we really need microVMs for this?”, is a spectrum.

Caption: The Trust Spectrum. Match isolation strength to the trust profile of the workload.

On one end you have code you wrote yourself. Your team reviewed it, your CI tested it, your production runs it. A standard container is the right answer. Kernel is shared, daemon is shared, and none of that matters because the workload is known.

One step removed from that are CI/CD pipelines running your team’s code plus dependencies from registries you mostly trust. Mostly known, but the inputs are more variable. You add seccomp profiles, drop capabilities, write network policies.

Further along, supervised AI agents: tools that suggest code while a developer reviews each step. Human in the loop, so hardened containers with strict policies still work.

At the far end are autonomous AI agents. Nobody reviewing each command. Agents making decisions on your behalf, each one potentially different from the last. The trust profile isn’t “I trust this code” because there’s no fixed code to trust. It’s “I’m letting something operate on my system without supervision, and I want the failure mode to be ‘contained to a disposable VM’ rather than ‘on my laptop.'” That’s the workload that needs a microVM.

This is not a declaration that containers are obsolete. It’s the opposite. Containers are the right answer for everything on the left side of that spectrum, which is most of what runs in production today. MicroVMs extend the spectrum to the right, where containers were never going to be the right tool. The four isolation layers in Sandboxes (hypervisor, network, Docker Engine, credential proxy) are additive. They wrap containers in additional protection rather than replacing them. Inside every Sandbox is a microVM that runs containers. Containers haven’t gone anywhere, they’ve moved one level deeper in the trust stack.

“MicroVMs for AI agents, containers for everything else” is too crude. “Match the isolation to the trust profile of the workload” is the one that holds up.

Why everyone is converging here

Docker isn’t the only company that arrived at this answer, and the convergence tells you something.

Firecracker powers AWS Lambda and Fly.io’s microVM platform. gVisor intercepts syscalls in a user-space kernel. Kata Containers provides VM isolation behind a container-compatible interface. Modal runs serverless agent workloads on gVisor. E2B offers Firecracker-based sandboxes as a managed cloud service. Northflank ships Kata-based isolation for production AI workloads. All adopted at the same time, for the same reasons. Architecture everywhere looks the same: containers on the inside (because that’s how developers think), VM on the outside (because that’s where the boundary needs to be).

Docker Sandboxes is the local-first version. Most alternatives are cloud services where you pay per execution and your code runs on someone else’s machines. Docker put the same architecture on the developer’s laptop. CLI supports eight agents natively (Claude Code, Codex, Copilot, Gemini CLI, Kiro, OpenCode, Docker Agent, and Droid), plus a Shell mode for custom tooling. A standalone sbx CLI runs without Docker Desktop, so the architecture isn’t locked to a commercial product. MicroVM layer has an HTTP API that the open-source community has already started building on.

That’s a runtime. And Docker is positioning it to become the standard way to run autonomous coding agents, the way docker run became the standard way to run microservices ten years ago.

One more thing. Hardened Images and sandboxes address different layers of the same problem: Hardened Images for the supply chain (where binaries come from), sandboxes for runtime isolation (what those binaries can touch). Both exist because the assumption that “code from a trusted publisher is safe” stopped being reliable.

Looking back, looking forward

I’ve watched the industry rebuild its trust model three times in twenty years.

Bare metal to virtual machines, because we needed to put multiple workloads on the same hardware safely.

Virtual machines to containers, because we needed faster startup, lower overhead, and a packaging model that matched how developers actually ship code.

Now, containers to a different kind of virtual machine, because the workload changed and the kernel namespace stopped being enough. Not because containers were wrong, but because the new tenant needs more, and more looks like a hypervisor again.

Each of these transitions felt obvious in hindsight and contested at the time. I remember the arguments about whether containers were really secure enough for multi-tenant workloads. (They mostly weren’t, which is why we ended up with namespaced clusters and per-tenant VMs and gVisor and now microVMs for agents.) I expect the microVM argument to follow the same arc: contested for about a year, obvious within three.

My Astro migration taught me what it feels like to work alongside an autonomous agent that has real access to your system. More productive than doing it by hand, and more unsettling than I expected, once I realized how much I’d stopped tracking. Sandboxes don’t make the agent trustworthy. It just makes sure that when the agent does something you didn’t expect, the damage stays inside a box you can throw away. Workspace still requires your attention. Your skepticism. That combination (strong boundaries where you can enforce them, disciplined review where you can’t) is the model for working with autonomous code, and it’s probably going to stay that way for a while.

If you’ve been holding back on running AI coding agents because of permission prompts, accidental file changes, or just a feeling that something about the whole arrangement isn’t quite safe: that feeling was correct. Containers were the wrong fit for the workload. Sandboxes is the right one. Try it on a project you actually care about. That’s the only test that matters.

Get started with Docker Sandboxes →

from Docker https://ift.tt/E8gdHNm
via IFTTT

Microsoft Patches SharePoint RCE Flaw CVE-2026-45659 Across Server Versions

Microsoft has rolled out updates to fix a remote code execution vulnerability impacting SharePoint that could be exploited by bad actors in attacks without requiring any specialized conditions to be met.

The vulnerability, tracked as CVE-2026-45659, carries a CVSS score of 8.8. It has been assigned an important severity.

"Deserialization of untrusted data in Microsoft Office SharePoint allows an authorized attacker to execute code over a network," Microsoft said in an advisory released last week.

Microsoft noted that the vulnerability could be triggered by any authenticated attacker, and that it does not require administrator or other elevated privileges.

"In a network-based attack, an authenticated attacker, who has a minimum of Site Member permissions (PR:L), could execute code remotely on the SharePoint Server," the Windows maker added.

Microsoft credited a researcher named MEOW for discovering and reporting the flaw. Updates have been released for the following versions -

Last month, Microsoft issued fixes for a spoofing vulnerability impacting Microsoft SharePoint Server (CVE-2026-32201, CVSS score: 6.5) that it said has been exploited in the wild.

Although the tech giant notes that CVE-2026-45659 is less likely to be exploited, it's essential that users apply the necessary fixes for optimal protection, particularly when considering the fact that several flaws in the collaborative platform have been repeatedly weaponized by attackers over the years.

from The Hacker News https://ift.tt/DhqiPvu
via IFTTT

MFA Prompt Bombing: Why Your Second Factor Isn't Saving You

Multi-factor authentication (MFA) was supposed to close a critical gap in identity security. It meant that, even if an attacker possessed the account credentials, they couldn't log in without the second factor. While that logic was sound, attackers have now figured out that they don't need to steal the second factor: they just need the user to hand it over.

If your workforce authenticates with push-based MFA, this attack is a live threat to your organization today. Tools like Specops Secure Access are built specifically to close that gap, but before getting into the fix, it's worth understanding how this technique works.

How MFA prompt bombing works

The attack requires three key elements to work:

• Valid account credentials, usually sourced from breached password dumps on the dark web
• A login portal that uses push-based MFA (such as a VPN, Microsoft 365, Okta, or Duo)
• A victim who is alerted every time the attacker tries the login

Attackers repeatedly trigger the prompt, attempting to trick the target or wear them down to approve the request. Sometimes, attackers will pair prompt bombing with a vishing call pretending to be from IT, where they will try to socially engineer the target. The danger is that these methods only need to work once.

If the prompt is approved, the attacker is logged in as that user. Security systems typically won't be alerted, as the login looks entirely legitimate.

The Cisco breach

The 2022 Cisco breach is a key example of how effective this technique is against even mature security programs. An attacker linked to the Yanluowang ransomware group compromised a Cisco employee's personal Google account, which was syncing browser-stored credentials, including the employee's Cisco VPN password.

From there, the attacker pushed MFA prompts to the employee's phone. That initially didn't work, so they began using vishing calls posing as trusted support organizations, speaking in various accents, and eventually convincing the employee to accept a push notification.

Once accepted, the attacker had VPN access as the employee. They then enrolled their own devices for MFA to maintain persistence, escalated to administrative privileges, reached Citrix servers and domain controllers, and exfiltrated around 2.8GB of data before being evicted. The fact that prompt bombing worked against a company like Cisco, which is far from having a weak security posture, highlights just how dangerous and effective the attack has become.

Why push MFA doesn't eliminate risk

The issue with push-based MFA is that users are asked to approve or deny a login with very little to go on. There's no clear indication of where the request originated, what device is being used, or whether the login attempt was initiated by the user at all. In isolation, that might be manageable. But when prompts start arriving repeatedly, it's easy to assume something's misfiring rather than recognizing it as a potential attack.

If that's paired with a well-timed phone call from someone posing as IT support, the situation becomes even harder to assess. At that point, the user isn't acting carelessly, but responding to a scenario designed to feel routine and legitimate, using credentials the attacker already has.

3 ways organizations can prevent prompt bombing

1. Use fatigue and phishing-resistant MFA factors

Push notifications are the weakest common form of MFA. Phishing-resistant factors such as FIDO2 security keys, hardware tokens like YubiKey, or number-matching codes from authenticator apps are harder to abuse.

Specops Secure Access supports more than 15 identity providers and includes these fatigue-resistant options for Windows logon, RDP, and VPN connections, so organizations can retire push-only MFA for high-risk access points.

Specops Secure Access

2. Block compromised passwords at the source

Prompt bombing is only made possible when the attacker already has a valid password. Scanning Active Directory (AD) continuously against a live database of breached passwords, and forcing a reset when a match appears, removes the fuel for the attack. Relying on default AD password policies won't catch reused, incremental, or breached passwords. If you don't know where you stand today, Specops Password Auditor is a free, read-only scan of your AD that flags vulnerabilities like compromised passwords or inactive admin accounts.

Specops Password Auditor

3. Add risk signals to the login

Conditional access policies that factor in geography, device posture, and login times can block or step up authentication before a prompt is ever sent to the user's phone. This reduces reliance on user behaviour alone and introduces real-time context to stop suspicious logins before they escalate into successful account compromise.

MFA still matters

MFA prompt bombing isn't a reason to move away from MFA, but it does highlight where some factors fall short. When approval requests can be triggered repeatedly with no meaningful context, the control becomes easier to influence than intended.

If push is still your default second factor, it's worth revisiting that decision. Number matching or phishing-resistant methods strengthen the MFA method itself, while scanning for compromised passwords limits the risk of attackers possessing the first authentication step. If you're looking to evolve your identity security with more robust MFA, talk to Specops.

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/n92qmBw
via IFTTT